On Wed, Sep 29, 2021 at 09:35:13AM +0200, Bastien Durel wrote:

Hello,

I'm trying to use bird to replace ospfd on OpenBSD, but it seems to have a strange effect on the networking stack :(

I've tried multiple times, from OpenBSD 6.6 to 6.9, with bird2 (2.0.8 now)

...

On OpenBSD mailing list, someone said the problem may be bird overwriting the 10.42.42/24 route (which was directly connected) by another (the flags changed from UCn to U1h)

Hello It is true, basic OSPF configuration rewrites direct routes. That is OK on Linux, as it allows multiple routes for same network, so kernel ones are also kept, but on BSD there is only one so they are removed. During our testing, it works on FreeBSD / NetBSD / OpenBSD at least while BIRD is running, but likely we have some old versions for testing that might behave differently. One thing that should work as a workaround is to have protocol direct, which generates direct routes more preferred than ones from OSPF, and then filter them out in kernel protocol, so they are not pused to kernel: protocol direct { ipv4; ipv6; } protocol kernel kernel4 { ipv4 { export where source != RTS_DEVICE; }; } But this is something we should improve in BIRD. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."

Hello, Another workaround might be setting a metric different from system's routes in kernel protocol to prevent system from rewriting existing routes. Zhang Xun From: Bastien Durel Date: 2021-09-29 15:35 To: bird-users Subject: OSPF on OpenBSD Hello, I'm trying to use bird to replace ospfd on OpenBSD, but it seems to have a strange effect on the networking stack :( I've tried multiple times, from OpenBSD 6.6 to 6.9, with bird2 (2.0.8 now) Here is my bird config: openbsd-test# cat /etc/bird.conf|grep -v ^#|grep -v '^$' log "/var/log/bird.log" { debug, trace, info, remote, warning, error, auth, fatal, bug }; router id 10.42.42.69; debug protocols all; protocol device { } protocol direct { disabled; # Disable by default ipv4; # Connect to default IPv4 table ipv6; # ... and to default IPv6 table } protocol kernel { ipv4 { # Connect protocol to IPv4 table by channel export all; # Export to protocol. default is export none }; } protocol kernel { ipv6 { export all; }; } protocol static { ipv4; # Again, IPv4 channel with default options } protocol ospf v2 ospfv2 { rfc1583compat yes; tick 2; ipv4 {}; area 0 { interface "em0" { cost 5; }; }; } And the em0 config: em0: flags=248843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,AUTOCONF6TEMP,AUTOC ONF6> mtu 1500 lladdr 08:00:27:d6:6e:dd index 1 priority 0 llprio 3 groups: egress media: Ethernet autoselect (1000baseT full-duplex) status: active inet6 fe80::a00:27ff:fed6:6edd%em0 prefixlen 64 scopeid 0x1 inet 10.42.42.69 netmask 0xffffff00 broadcast 10.42.42.255 Before starting bird, I have a simple routing table : openbsd-test# route -n show - inet Routing tables Internet: Destination Gateway Flags Refs Use Mtu Prio Iface default 10.42.42.1 UGS 6 12 - 8 em0 224/4 127.0.0.1 URS 0 0 32768 8 lo0 10.42.42/24 10.42.42.69 UCn 2 0 - 4 em0 10.42.42.1 40:62:31:07:55:11 UHLch 1 2 - 3 em0 10.42.42.21 00:25:22:1e:0b:b7 UHLc 0 1 - 3 em0 10.42.42.69 08:00:27:d6:6e:dd UHLl 0 4 - 1 em0 10.42.42.255 10.42.42.69 UHb 0 0 - 1 em0 127/8 127.0.0.1 UGRS 0 0 32768 8 lo0 127.0.0.1 127.0.0.1 UHhl 1 2 32768 1 lo0 When bird is started, it inserts routes as intended: openbsd-test# route -n show -inet Routing tables Internet: Destination Gateway Flags Refs Use Mtu Prio Iface default 10.42.42.1 UGS 5 314 - 8 em0 default 10.42.42.1 UG1 0 0 - 56 em0 224/4 127.0.0.1 URS 0 19 32768 8 lo0 5.39.65.35 10.42.42.1 UGH1 0 0 - 56 em0 10.0.42.21 10.42.42.21 UGH1 0 0 - 56 em0 10.2.0/24 10.42.42.1 UG1 0 0 - 56 em0 10.42.0/24 10.42.42.1 UG1 0 0 - 56 em0 10.42.1.56/30 10.42.42.21 UG1 0 0 - 56 em0 10.42.1.64/30 10.42.42.21 UG1 0 0 - 56 em0 10.42.7.6 10.42.42.21 UGH1 0 0 - 56 em0 10.42.7.7 10.42.42.21 UGH1 0 0 - 56 em0 10.42.7.53 10.42.42.21 UGH1 0 0 - 56 em0 10.42.42/24 10.42.42.69 U1h 66 193 - 56 em0 10.42.42.69 08:00:27:d6:6e:dd UHLl 0 104 - 1 em0 10.42.42.255 10.42.42.69 UHb 0 13 - 1 em0 10.60.77.5 10.42.42.1 UGH1 0 0 - 56 em0 [...] But after that, the box cannot join anythin with IPv4. Established connections (eg. ssh) over IPv4 fails. Even the gateway is unreachable: openbsd-test# ping 10.42.42.1 PING 10.42.42.1 (10.42.42.1): 56 data bytes ping: sendmsg: Invalid argument ping: wrote 10.42.42.1 64 chars, ret=-1 ping: sendmsg: Invalid argument ping: wrote 10.42.42.1 64 chars, ret=-1 ^C --- 10.42.42.1 ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss With no ospfv3 configured, ipv6 connections are not lost dmesg returns theses messages : arp_rtrequest: bad gateway value: em0 arpresolve: 10.42.42.1: route contains no arp information arpresolve: 10.42.42.0: route contains no arp information arpresolve: 10.42.42.1: route contains no arp information The last ones beeing flooded when the box tries to send packets Whatever bird makes to the networking stack persists even if bird is shut down. A reboot is necessary to recover. On OpenBSD mailing list, someone said the problem may be bird overwriting the 10.42.42/24 route (which was directly connected) by another (the flags changed from UCn to U1h) After stopping bird, flags and prios are not restored (10.42.42/24 gets U1 / prio 56), and the default route kept is the one bird inserted openbsd-test# route -n show -inet Routing tables Internet: Destination Gateway Flags Refs Use Mtu Prio Iface default 10.42.42.1 UG1 2 2 - 56 em0 224/4 127.0.0.1 URS 0 13 32768 8 lo0 10.42.42/24 10.42.42.69 U1 0 76 - 56 em0 10.42.42.69 08:00:27:d6:6e:dd UHLl 0 23 - 1 em0 10.42.42.255 10.42.42.69 UHb 0 6 - 1 em0 127/8 127.0.0.1 UGRS 0 0 32768 8 lo0 127.0.0.1 127.0.0.1 UHhl 1 2 32768 1 lo0 Do you know how to prevent that ? Thanks, -- Bastien