I've got a couple of questions about nexthop-tracking in zebra - these are
a bit down in the details, but I thought I'd ask if any of the folks on the
list have some insight...
1. the nht code makes a copy (mostly) of the route_entry that satisfies
some client registration. the code copies all of the nexthops - even the
recursive ones, even ones that are not ACTIVE. the code that sends
nexthops to the nht client(s) has an rnh_nexthop_valid() function that is
pretty strict about what will actually be sent. would it be reasonable to
have the nht code capture only a list of the nexthops that are actually
valid, that actually will be sent to the clients?
2. the show command for nht, ‘sho ip nht’, only shows the top-level
nexthops - not the actual installed nexthops that, again, will be sent to
the clients. would it be ok to change that, to try to have the show command
show what will actually be sent to clients?
3. the route-map filtering in there also operates only on the top-level
nexthops, not the exact ones that are "valid" and will be sent to clients.
is that intentional, or should the route-map get a shot at the nexthops
that the nht code would try to send?
Thanks,
Mark
