<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 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?</div><div><br></div><div>Thanks,</div><div>Mark<br></div></div>