<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>