[FROG] ospf on nhrp interface routes are inactive

[Joe Maimon]

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