Problem: When frr installs *static* (ip route ?????/?? gateway) routes it's does so with proto number 196, where iproute2 uses the number 4 for static. There are seemingly other similar cases. For example: kerberos [11:19:48] ~ # vtysh -c "sh ip route 154.73.33.0/24" Routing entry for 154.73.33.0/24 Known via "static", distance 1, metric 0, best Last update 17:12:18 ago * directly connected, bond0.13, weight 1 kerberos [11:19:56] ~ # ip ro sh 154.73.33.0/24 154.73.33.0/24 nhid 614343 dev bond0.13 proto 196 src 154.73.32.1 metric 20 This is a minor issue, and just seems weird, so would be nice to fix, but not critical. FRR seems to be using hard-coded rt_protos values from it's rt_netlink.h in zebra/. Most of this is a reminder to myself as to possible options. These values are (comments added): #define RTPROT_BGP 186 #define RTPROT_ISIS 187 #define RTPROT_OSPF 188 #define RTPROT_RIP 189 #define RTPROT_RIPNG 190 /* missing */ #define RTPROT_BABEL 42 #define RTPROT_NHRP 191 /* missing */ #define RTPROT_EIGRP 192 #define RTPROT_LDP 193 /* missing */ #define RTPROT_SHARP 194 /* missing */ #define RTPROT_PBR 195 /* missing */ #define RTPROT_ZSTATIC 196 /* mismatch, 4 on iproute2 side */ #define RTPROT_OPENFABRIC 197 /* missing */ #define RTPROT_SRTE 198 /* missing */ Whereas iproute2 installed rt_protos contains: 0 unspec 1 redirect 2 kernel 3 boot 4 static 8 gated 9 ra 10 mrt 11 zebra 12 bird 13 dnrouted 14 xorp 15 ntk 16 dhcp 18 keepalived 42 babel 99 openr 186 bgp 187 isis 188 ospf 189 rip 192 eigrp Spotted this whilst troubleshooting an unrelated issue when dumping some routes: 154.73.33.0/24 nhid 614343 dev bond0.13 proto 196 src 154.73.32.1 metric 20 Where I'd expect "proto static". It's plain that proto static is mismatched, and it's plain that not all preferred options for frr is contained in iproute2. Possible Solution 1: In FRR repository: ./tools/etc/iproute2/rt_protos.d/frr.conf Seems to hint that we can install additional rt_protos files into a rt_protos.d folder, and rt_names.c in iproute2 seems to confirm. If that works I would suggest that iproute2 only installs the most basic of rt_protos values, and that we can then install additional files into eg rt_protos.d from example frr. Load order on iproute2 side is (assuming the massive code duplication is consistent this holds for all mapping tables, not only rt_protos): /etc/iproute2 /usr/share/iproute2 /usr/share/iproute2/???.d/ (in *readdir* order, ie, unsorted). /etc/iproute2/rt_protos.d Possible Solution 2: Adjust values in iproute2 package. Possible Solution 3: Adjust values in frr to match iproute2, and add our own variant of rt_protos.d/frr.conf which won't duplicate that from iproute2 (which will suffer problems similar to my "in the meantime" reference below. Possible Solution 4: Patch iproute2 to expose some library to perform name/number resolution (getent equivalent), possibly libnetlink addition, then patch frr to use that if available. Possibly some combinations of the above. Additonal info: mkdir -p /etc/iproute2 echo -e "196\t\tstatic" >> /etc/iproute2/rt_protos Solves the display issue when running ip ro sh, but won't get the reverse right when doing "ip ro sh proto static" for example. kerberos [10:59:49] ~ # ip ro sh 154.73.33.0/24 154.73.33.0/24 nhid 614343 dev bond0.13 proto static src 154.73.32.1 metric 20 kerberos [11:00:35] ~ # ip ro sh proto static kerberos [11:00:43] ~ # ip ro sh proto 196 154.73.32.6 nhid 614446 dev bond0.100 src 154.73.32.1 metric 20 154.73.33.0/24 nhid 614343 dev bond0.13 src 154.73.32.1 metric 20 blackhole 192.0.2.1 metric 20 Moving the /etc/ file into /etc/iproute2/rt_protos.d/frr.conf does not solve the mapping problem, so I'm assuming that existing entries aren't overwritten, but rather than first seen takes priority. Reproducible: Always
Quick thought, Isn’t proto 4 supposed to be used for routes added with `ip route add $foo via $bar`? With static routes inside frr, that not actually a kernel static route, but a zebra static route. So for me, we should re-use that zstatic keyword instead of just static.
Would appreciate input from base-system team as well as to their preference, thereafter you're most welcome to drop the CC, happy to handle and push relevant PRs as directed (obviously easier if fix is only in one package rather than two). I'm currently thinking: Patch frr to: 1. Include a separate .h file containing the RTPROT_* defines (.patch file). 2. Auto generate that file based on contents of /usr/share/iproute2/rt_protos (scripted). 3. Create a rt_protos.d/frr.conf for any values that's missing from iproute2. 2 and 3 will probably be a basic loop iterating either the original rt_netlink.h file, or frr's shipped rt_protos.d/frr.conf file ..., and dispatching into the rt_netlink_protos.h and rt_protos.d/frr.conf file as needed. This way frr should end up using proto 4 for static, and all the missing values just get added to rt_protos.d/frr.conf to be installed (marked /* missing */ above). The one thing here is that RTPROT_ZSTATIC vs static route - everything else is just a case difference. This is my challenge.
(In reply to Alarig Le Lay from comment #1) > Quick thought, > > Isn’t proto 4 supposed to be used for routes added with `ip route add $foo > via $bar`? > With static routes inside frr, that not actually a kernel static route, but > a zebra static route. So for me, we should re-use that zstatic keyword > instead of just static. plastiekpoot [11:51:26] ~ # ip ro ad 10.0.0.0/24 via 192.168.42.1 plastiekpoot [11:51:38] ~ # ip ro sh 10.0.0.0/24 10.0.0.0/24 via 192.168.42.1 dev wlp2s0 So no, I don't think so. But yea, static vs zstatic could make sense, ie, we have frr still use 196, and we just add it as a zstatic proto for iproute2?
