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