Hey All, Thanks to the event manager working properly, NHRP spokes are up and running. kernel neighbor routes are installed and pinging is working. I have gotten ospf neighbors to come up by configuring the interface as non-broadcast, as nhrp multicast does not appear to be supported at this time. (There seems to be some difficulty there, debug shows lots of duplicates and neighbors take quite a while to transition into Full/DR-whatever state) 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. Any assistance would be greatly appreciated. For example: O>* 10.7.255.8/32 [110/20] via 192.168.241.130, t67, 16:48:28 O>* 10.7.255.14/32 [110/20] via 192.168.241.130, t67, 16:48:28 O>* 10.10.11.32/32 [110/20] via 192.168.241.130, t67, 16:48:28 O>* 10.34.34.0/30 [110/20] via 192.168.241.130, t67, 16:48:28 O>* 10.99.255.9/32 [110/20] via 192.168.241.130, t67, 16:48:28 O>* 38.32.100.169/32 [110/20] via 192.168.241.130, t67, 16:48:28 .....more.... debian67# sh ip route nhrp debian67# Now, I send result=accept to evmgr debian67(config)# int t67 debian67(config-if)# shutdown debian67(config-if)# no shutdown debian67(config-if)# end debian67# sh ip route Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR, f - OpenFabric, > - selected route, * - FIB route, q - queued route, r - rejected route K>* 0.0.0.0/0 [0/0] via 45.77.146.1, ens3, 17:00:22 C>* 45.77.146.0/23 is directly connected, ens3, 17:00:22 K>* 169.254.169.254/32 [0/0] via 45.77.146.1, ens3, 17:00:22 O 192.168.241.128/27 [110/500] is directly connected, t67, 00:01:56 C>* 192.168.241.128/27 is directly connected, t67, 00:01:56 N>* 192.168.241.130/32 [10/0] is directly connected, t67, 00:00:12 N>* 192.168.241.131/32 [10/0] is directly connected, t67, 00:00:01 N>* 192.168.241.132/32 [10/0] is directly connected, t67, 00:00:01 debian67# sh ip os ne Neighbor ID Pri State Dead Time Address Interface RXmtL RqstL DBsmL 216.222.156.3 1 Full/DR 1m49s 192.168.241.130 t67:192.168.241.129 0 0 0 209.54.134.5 1 Full/DROther 1m54s 192.168.241.131 t67:192.168.241.129 0 0 0 209.54.140.100 1 Full/DROther 1m59s 192.168.241.132 t67:192.168.241.129 0 0 0 debian67# sh ip route ospf Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR, f - OpenFabric, > - selected route, * - FIB route, q - queued route, r - rejected route O 0.0.0.0/0 [110/100] via 192.168.241.130, t67 inactive, 00:00:47 O 10.7.255.8/32 [110/20] via 192.168.241.130, t67 inactive, 00:00:47 O 10.7.255.14/32 [110/20] via 192.168.241.130, t67 inactive, 00:00:47 O 10.10.11.32/32 [110/20] via 192.168.241.130, t67 inactive, 00:00:47 O 10.34.34.0/30 [110/20] via 192.168.241.130, t67 inactive, 00:00:47 O 10.99.255.9/32 [110/20] via 192.168.241.130, t67 inactive, 00:00:47 ----more----
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
participants (1)
-
Joe Maimon