Kernel routes missed in case of no gateway IP address

[vgrebenschikov]

Describe the bug
[x] Did you check if this is a duplicate issue?
[x] Did you test it on the latest FRRouting/frr master branch?

To Reproduce
Kernel routes are not added into zebra list if route has device as gateway:

before:

srv# show ip route kernel
...
K>* 172.22.4.0/24 [0/0] via 172.22.4.2, 00:04:42
K>* 172.23.0.0/16 [0/0] via 172.22.4.2, 00:04:42
K>* 172.24.0.0/23 [0/0] via 172.22.4.2, 00:04:42
srv#

Then add route (in fact it is as wireguard scripts add it):

# route add 172.22.9.0/24 -iface wg0
add net 172.22.9.0: gateway wg0

And it is pretty usual for ptp/tunnel interfaces to add route just to interface, not on gateway IP

After that - nothing changed, route did not appeared:

srv# show ip route kernel
...
K>* 172.22.4.0/24 [0/0] via 172.22.4.2, 00:07:47
K>* 172.23.0.0/16 [0/0] via 172.22.4.2, 00:07:47
K>* 172.24.0.0/23 [0/0] via 172.22.4.2, 00:07:47
srv#

While that route monitor shows route message:

#  route -n monitor

got message of size 240 on Mon Jul 26 16:24:03 2021
RTM_ADD: Add Route: len 240, pid: 4356, seq 1, errno 0, flags:<UP,DONE,STATIC>
locks:  inits:
sockaddrs: <DST,GATEWAY,NETMASK>
 172.22.9.0 wg0 255.255.255.0 

One can notice that interface name (wg0) is sent in GATEWAY part of message

If we take a look at https://github.com/FRRouting/frr/blob/master/zebra/kernel_socket.c#L778
It is clear that for gateway we expect here only IP address, not interface name

Expected behavior
Route appeared as kernel and then available for redistribution

Versions

• FRR: frr7-7.5.1_1
• OS: FreeBSD 12.2-STABLE r369379 amd64
• Kernel: 12.2-STABLE r369379 amd64

Additional context
Pretty basic PR which fixes the problem in Quagga
Quagga/quagga#5

[donaldsharp]

This is day 1 behavior :( ( I am not saying this is correct )

^718e37441 (paul               2002-12-13 20:15:29 +0000 1039)  /* This is connected route. */
^718e37441 (paul               2002-12-13 20:15:29 +0000 1040)  if (!(flags & RTF_GATEWAY))
^718e37441 (paul               2002-12-13 20:15:29 +0000 1041)          return;

looking at it real quick to see if there is a way I can tell what kind of route it is

[vgrebenschikov]

This is day 1 behavior :( ( I am not saying this is correct )

^718e37441 (paul               2002-12-13 20:15:29 +0000 1039)  /* This is connected route. */
^718e37441 (paul               2002-12-13 20:15:29 +0000 1040)  if (!(flags & RTF_GATEWAY))
^718e37441 (paul               2002-12-13 20:15:29 +0000 1041)          return;

looking at it real quick to see if there is a way I can tell what kind of route it is

Yes, and that is wrong, IMHO,
It assumes that routes added on interface "connected" and they are just skipped
So no any way to propagate such routes to OSPF or like

In fact - connected routes (assigned on interfaces) arrived with other RTM messages, not RTM_ADD

Idea to propagate routes across network once client connected to VPN (wireguard/openvpn/etc)

[vgrebenschikov]

A bit more information:

debug zebra kernel
debug zebra rip  


Jul 26 16:59:05 srv zebra[18471]: Kernel: Len: 240 Type: RTM_ADD
Jul 26 16:59:05 srv zebra[18471]: Kernel: Len: 240 Type: RTM_ADD
Jul 26 16:59:05 srv zebra[18471]: Kernel: UP DONE STATIC
Jul 26 16:59:05 srv zebra[18471]: Kernel: UP DONE STATIC
Jul 26 16:59:05 srv zebra[18471]: Kernel: message seq 1
Jul 26 16:59:05 srv zebra[18471]: Kernel: message seq 1
Jul 26 16:59:05 srv zebra[18471]: Kernel: pid 19178, rtm_addrs {DST,GATEWAY,NETMASK}
Jul 26 16:59:05 srv zebra[18471]: Kernel: pid 19178, rtm_addrs {DST,GATEWAY,NETMASK}
Jul 26 16:59:05 srv zebra[18471]: rtm_read: got rtm of type 1 (RTM_ADD) addrs {DST,GATEWAY,NETMASK}
Jul 26 16:59:05 srv zebra[18471]: rtm_read: got rtm of type 1 (RTM_ADD) addrs {DST,GATEWAY,NETMASK}

[vgrebenschikov]

Some initial fix provided in PR above, but worth to not install kernel routes that was already added as Connected.

after fix:

srv# show ip route
...
K>* 172.22.4.1/32 [0/0] is directly connected, lo0, 00:16:03
K * 172.22.4.2/32 [0/0] is directly connected, tun0, 00:16:03
C>* 172.22.4.2/32 [0/1] is directly connected, tun0, 00:16:03
K * 172.22.4.192/32 [0/0] is directly connected, wg0, 00:16:03
C>* 172.22.4.192/32 [0/1] is directly connected, wg0, 00:16:03
K>* 172.22.4.194/32 [0/0] is directly connected, wg0, 00:16:03
K>* 172.22.9.0/24 [0/0] is directly connected, wg0, 00:14:59
K * 172.22.17.18/32 [0/0] is directly connected, re0, 00:16:03
C>* 172.22.17.18/32 [0/1] is directly connected, re0, 00:16:03
K>* 172.23.0.0/16 [0/0] via 172.22.4.2, tun0, 00:16:03
K>* 172.24.0.0/23 [0/0] via 172.22.4.2, tun0, 00:16:03
srv#

[vgrebenschikov]

Probably, a bit related #3937

[github-actions]

This issue is stale because it has been open 180 days with no activity. Comment or remove the autoclose label in order to avoid having this issue closed.

[frrbot]

This issue will be automatically closed in the specified period unless there is further activity.

[vgrebenschikov]

After recent update to FRR8 I can confirm that,
issue still actual, and that is a pity that there are no activity to fix it, and it get auto-closed.
Especially, keeping in mind that I've provided PR with fix.

[vgrebenschikov]

Not sure how to properly reopen it

[vgrebenschikov]

problem still here in FRR8 (and master now) - a place where such routes skipped in code:
https://github.com/FRRouting/frr/blob/master/zebra/kernel_socket.c#L1035