<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">Hi, it looks like the problem is a /32 route directed to the gateway installed by the DHCP client (systemd-networkd). `show ip route` from vtysh shows:</span><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""> […]</span><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""> C>* 10.8.10.0/24 [0/1024] is directly connected, public, 02:27:44</span><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""> K>* 10.8.10.1/32 [0/1024] is directly connected, public, 02:27:44</span><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""> […]</span><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""> O 192.168.65.0/24 [110/200] via 10.8.10.1, public inactive, weight 1, 02:27:29</span><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""> […]</span><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">If I manually remove that /32 route from the routing table and restart FRR, the buggy route (192.168.65.0/24) get installed correctly</span><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">and 'nexthop_active: Route Type ospf has not turned on recursion’ does not show up in the logs.</span><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">I could manually remove that route (which is completely useful AFAICT) manually before starting FRR with a script, but I still wonder</span><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">why FRR fails to use 10.8.10.1 as a valid nexthop, considering that from the above output it sees 10.8.10.1 as `directly connected` just</span><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">like the route above. Why does one get a ‘C’ and the other gets a ‘K’? I think that’s the only difference and therefore the only thing that</span><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">could be causing the problem.</span><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">Thanks,</span><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">Tito</span>
<div><br class=""><blockquote type="cite" class=""><div class="">On 19 Aug 2022, at 23:33, Tito Sacchi via frog <<a href="mailto:frog@lists.frrouting.org" class="">frog@lists.frrouting.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class=""><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(127, 127, 127, 1.0);" class=""><b class="">From: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class="">Tito Sacchi <<a href="mailto:tito+mailinglists@tilde.team" class="">tito+mailinglists@tilde.team</a>><br class=""></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(127, 127, 127, 1.0);" class=""><b class="">Subject: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class=""><b class="">Re: [FROG] Change default zebra routing table</b><br class=""></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(127, 127, 127, 1.0);" class=""><b class="">Date: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class="">19 August 2022 at 23:33:08 CEST<br class=""></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(127, 127, 127, 1.0);" class=""><b class="">To: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class="">Donald Sharp <<a href="mailto:donaldsharp72@gmail.com" class="">donaldsharp72@gmail.com</a>><br class=""></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(127, 127, 127, 1.0);" class=""><b class="">Cc: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class="">FRRouting Operator Group - Users List <<a href="mailto:frog@lists.frrouting.org" class="">frog@lists.frrouting.org</a>><br class=""></span></div><br class=""><br class="">Hi Donald, thanks for your reply.<br class=""><br class="">I made Zebra dump diagnostics information and it produced a *lot* of debugging information in the logs. A relevant extract of the detailed log can be found at <br class=""><a href="https://bhh.sh/6gm" class="">https://bhh.sh/6gm</a> (pastebin).<br class=""><br class="">I think the lines responsible for the 192.168.65.0/24 route not being installed are the following:<br class=""><br class=""> 2022/08/19 15:49:55 ZEBRA: [ZJVZ4-XEGPF] default(0:254):192.168.65.0/24: Examine re 0x557c9e4eb100 (ospf) status: Changed flags: None dist 110 metric 200<br class=""> 2022/08/19 15:49:55 ZEBRA: [GG8QH-195KE] nexthop_active_update: re 0x557c9e4eb100 nhe 0x557c9e4eb240 (547), curr_nhe 0x557c9e4eb7d0<br class=""> 2022/08/19 15:49:55 ZEBRA: [T9JWA-N8HM5] nexthop_active_check: re 0x557c9e4eb100, nexthop 10.8.10.1, via public<br class=""> 2022/08/19 15:49:55 ZEBRA: [M7EN1-55BTH] nexthop_active: Route Type ospf has not turned on recursion<br class=""> 2022/08/19 15:49:55 ZEBRA: [HJ48M-MB610] nexthop_active_check: Unable to find active nexthop<br class=""> 2022/08/19 15:49:55 ZEBRA: [ZG85Y-SBJH3] nexthop_active_update: re 0x557c9e4eb100 curr_active 0<br class=""> 2022/08/19 15:49:55 ZEBRA: [G6MN6-TB7HQ] zebra_nhg_free: nhe 0x557c9e4eb7d0 (0), refcnt 0, NH 10.8.10.1, via public<br class=""><br class="">However, 10.8.10.1 is a perfectly valid nexthop directly connected to the host via the ‘public’ interface.<br class="">`ip -4 neigh` yields:<br class=""><br class=""> […]<br class=""> id 541 via 10.8.10.1 dev public scope link proto zebra <br class=""> […]<br class=""><br class="">`show nexthop-groups rip` from vtysh:<br class=""><br class=""> [...]<br class=""> ID: 597 (zebra)<br class=""> RefCnt: 1<br class=""> Uptime: 00:14:31<br class=""> VRF: default<br class=""> Interface Index: 9<br class=""> via 10.8.10.1, public (vrf default) inactive, weight 1<br class=""> [...]<br class=""> ID: 541 (zebra)<br class=""> RefCnt: 1<br class=""> Uptime: 00:14:40<br class=""> VRF: default<br class=""> Valid, Installed<br class=""> Interface Index: 9<br class=""> via 10.8.10.1, public (vrf default), src 10.8.10.198<br class=""> [...]<br class=""><br class="">So apparently Zebra keeps two differentt nexthops directed to 10.8.10.1 on interface ‘public’. Why is one of them kept inactive? I think the issue lies there.<br class="">The thing that I can’t really understand is why (as you can see from the above pastebin) other routes to other nexthops (such as 10.8.10.135) directly attached to the ‘public’ interface are correctly installed. Why doesn’t Zebra consider 10.8.10.1 a nexthop just like 10.8.10.135?<br class=""><br class="">Thanks for your time,<br class="">Tito<br class=""><br class=""><blockquote type="cite" class="">On 19 Aug 2022, at 13:37, Donald Sharp <<a href="mailto:donaldsharp72@gmail.com" class="">donaldsharp72@gmail.com</a>> wrote:<br class=""><br class="">table was removed from FRR because it was a broken command and as such no-one could be using it:<br class=""><br class="">commit c447ad08b2c880d5f3ef35af2e4055fcbc970961 (origin/pr/4256)<br class="">Author: Donald Sharp <<a href="mailto:sharpd@cumulusnetworks.com" class="">sharpd@cumulusnetworks.com</a>><br class="">Date: Fri May 3 20:54:20 2019 -0400<br class=""><br class=""> doc, zebra: Remove "table X" command<br class=""><br class=""> This command is broken and has been broken since the introduction<br class=""> of vrf's. Since no-one has complained it is safe to assume that<br class=""> there is no call for this specialized linux command. Remove<br class=""> from the system with extreme prejudice.<br class=""><br class=""><br class=""><br class="">An `inactive` route has failed to be installed for a different reason. Not for the reason you have stated. Can we see the output of `show ip route 10.8.10.1` ? Also turn on `debug zebra rib detail` and `debug zebra nexthop detail` and cause the ospf route to be reinstalled. Let's see what the logs spit out.<br class=""><br class="">Finally have you looked at FRR's version of PBR? Why wouldn't that work for you?<br class=""><br class="">donald<br class=""><br class=""><br class="">On Fri, Aug 19, 2022 at 3:35 AM Tito Sacchi via frog <<a href="mailto:frog@lists.frrouting.org" class="">frog@lists.frrouting.org</a>> wrote:<br class=""><br class=""><br class=""><br class="">---------- Forwarded message ----------<br class="">From: Tito Sacchi <<a href="mailto:tito+mailinglists@tilde.team" class="">tito+mailinglists@tilde.team</a>><br class="">To: <a href="mailto:frog@lists.frrouting.org" class="">frog@lists.frrouting.org</a><br class="">Cc: <br class="">Bcc: <br class="">Date: Fri, 19 Aug 2022 08:25:49 +0200<br class="">Subject: Change default zebra routing table<br class="">Hi everyone,<br class=""><br class="">Quagga has a command called ’table’ that can be used to specify which table Zebra should install dynamic routes in.<br class="">Is there anything similar in FRR?<br class="">By default, routes are installed in table 254 (‘main’). But I have a complex PBR setup and Zebra fails to install some routes<br class="">because they are covered by a default route already present in table 254. But because of PBR, packets do not follow that default route and the subnet that comes<br class="">from OSPF and that I expect Zebra to install is not reachable:<br class=""><br class=""> K>* 0.0.0.0/0 [0/1024] via 10.8.10.1, eth0, src 10.8.10.135, 06:50:14<br class=""> [...]<br class=""> O 192.168.65.0/24 [110/110] via 10.8.10.1, eth0 inactive, weight 1, 06:50:09<br class=""><br class="">I think the last route is not installed (kept ‘inactive’) because it is covered by the default route at the top.<br class=""><br class="">How can I tell zebra to consider another routing table? I would like to avoid enslaving all my interfaces to a VRF device.<br class="">If it cannot be done with a simple ’table’ command, should I use route maps? They support the `set table` action but according to the manual it has to do with BGP and it does not do what I want.<br class=""><br class="">Thanks,<br class="">Tito<br class=""><br class="">— — —<br class=""><a href="https://tilde.team/~tito/" class="">https://tilde.team/~tito/</a><br class=""><br class="">PGP key: 0x6BED3002CF25C4D2 (4096R)<br class="">(https://keys.openpgp.org/search?q=0x6BED3002CF25C4D2)<br class=""><br class="">Keybase: @tauroh<br class="">(https://keybase.io/tauroh)<br class=""><br class=""><br class=""><br class=""><br class=""><br class="">---------- Forwarded message ----------<br class="">From: Tito Sacchi via frog <frog@lists.frrouting.org><br class="">To: frog@lists.frrouting.org<br class="">Cc: <br class="">Bcc: <br class="">Date: Fri, 19 Aug 2022 08:25:49 +0200<br class="">Subject: [FROG] Change default zebra routing table<br class="">_______________________________________________<br class="">frog mailing list<br class="">frog@lists.frrouting.org<br class="">https://lists.frrouting.org/listinfo/frog<br class=""></blockquote><br class=""><br class=""><br class=""><br class="">_______________________________________________<br class="">frog mailing list<br class=""><a href="mailto:frog@lists.frrouting.org" class="">frog@lists.frrouting.org</a><br class="">https://lists.frrouting.org/listinfo/frog<br class=""></div></blockquote></div><br class=""></body></html>