Bug 941231 – net-misc/frr and sys-apps/iproute2 rt_protos mismatch

• Product: Gentoo Linux
• Status: CONFIRMED ---

[Description Jaco Kroon 2024-10-10 09:31:44 UTC]

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

[Comment 1 Alarig Le Lay 2024-10-10 09:39:36 UTC]

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.

[Comment 2 Jaco Kroon 2024-10-10 09:50:46 UTC]

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.

[Comment 3 Jaco Kroon 2024-10-10 09:52:24 UTC]

(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?