<div dir="ltr">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...<br><br>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?<br><br>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?<br><br><div>3. the route-map filtering 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?</div><div><br></div><div>Thanks,</div><div>Mark</div><div><br></div></div>