Joe Maimon wrote:
Hey All,
However, all ospf routes are marked inactive.
I have found that this is the case for so long as the NHRP routes (individually as /32) are installed.
The workaround is to prevent those routes from being installed (I do this by returning a result=reject from the event handler), but clearly that is not right.
Running 7.4 git clone local debian 10 packaged.
So I have tried two different code fixes both in zebra_nhg.c nexthop_active(). Each one works, and ospf routes are installed. Fix#1 - if (!match) { + (!match | match->type == ZEBRA_ROUTE_NHRP) { Fix#2 - if (match->type == ZEBRA_ROUTE_CONNECT) + if (match->type == ZEBRA_ROUTE_CONNECT || match->type == ZEBRA_ROUTE_NHRP) { But then, on to the next problem. Sometime after those routes are learned, NHRP stops working, OSPF goes down, and the difference in logging suggests that the interface name gets lost from the route, possibly because the previously learned OSPF route overwrote it somehow, even though it was not installed due to admin distance? Logs before OSPF routes: Mar 22 11:43:01 debian67 nhrpd[786]: Recv Registration-Request(3) 192.168.241.131 -> 192.168.241.129 Mar 22 11:43:01 debian67 nhrpd[786]: lookup 192.168.241.129/32: zebra route dev t67 Mar 22 11:43:01 debian67 nhrpd[786]: lookup 0.0.0.0/32: zebra route dev ens3 Mar 22 11:43:01 debian67 nhrpd[786]: Parsing and replying to Registration Req Logs after OSPF routes: Mar 22 12:27:39 debian67 nhrpd[786]: Recv Registration-Request(3) 192.168.241.131 -> 192.168.241.129 Mar 22 12:27:39 debian67 nhrpd[786]: lookup 192.168.241.129/32: zebra route dev t67 Mar 22 12:27:39 debian67 nhrpd[786]: lookup 0.0.0.0/32: zebra route dev (none) Mar 22 12:27:39 debian67 nhrpd[786]: lookup 209.54.140.80/32: zebra route dev (none) Mar 22 12:27:39 debian67 nhrpd[786]: lookup 1.0.0.0/32: zebra route dev (none) The workaround is still the same, using event manager, I do not accept the NHRP requests (I send a result=reject but thats actually superfluous as the event manager code is default deny) even as the script installs the nhrp kernel neighbor entries. OSPF neighbors stay up, even as nhrpd accept no registrations and its cache is empty. Clearly this is non-optimal, but I am not currently able to make heads or tails of how and where the same routes that worked previously are losing their ifp in nhrp_route_get_nexthop() and dont work anymore for nhrp. Any help or advice appreciated. Best, Joe