Hello,I'm trying to use bird to replace ospfd on OpenBSD, but it seems tohave a strange effect on the networking stack :(I've tried multiple times, from OpenBSD 6.6 to 6.9, with bird2 (2.0.8now)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 defaultipv4; # Connect to default IPv4 tableipv6; # ... and to default IPv6 table}protocol kernel {ipv4 { # Connect protocol to IPv4 table bychannelexport all; # Export to protocol. default is exportnone};}protocol kernel {ipv6 { export all; };}protocol static {ipv4; # Again, IPv4 channel with defaultoptions}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,AUTOCONF6> mtu 1500lladdr 08:00:27:d6:6e:ddindex 1 priority 0 llprio 3groups: egressmedia: Ethernet autoselect (1000baseT full-duplex)status: activeinet6 fe80::a00:27ff:fed6:6edd%em0 prefixlen 64 scopeid 0x1inet 10.42.42.69 netmask 0xffffff00 broadcast 10.42.42.255Before starting bird, I have a simple routing table :openbsd-test# route -n show -inetRouting tablesInternet:Destination Gateway Flags Refs Use Mtu PrioIfacedefault 10.42.42.1 UGS 6 12 - 8em0224/4 127.0.0.1 URS 0 0 32768 8lo010.42.42/24 10.42.42.69 UCn 2 0 - 4em010.42.42.1 40:62:31:07:55:11 UHLch 1 2 - 3em010.42.42.21 00:25:22:1e:0b:b7 UHLc 0 1 - 3em010.42.42.69 08:00:27:d6:6e:dd UHLl 0 4 - 1em010.42.42.255 10.42.42.69 UHb 0 0 - 1em0127/8 127.0.0.1 UGRS 0 0 32768 8lo0127.0.0.1 127.0.0.1 UHhl 1 2 32768 1lo0When bird is started, it inserts routes as intended:openbsd-test# route -n show -inetRouting tablesInternet:Destination Gateway Flags Refs Use Mtu PrioIfacedefault 10.42.42.1 UGS 5 314 - 8em0default 10.42.42.1 UG1 0 0 - 56em0224/4 127.0.0.1 URS 0 19 32768 8lo05.39.65.35 10.42.42.1 UGH1 0 0 - 56em010.0.42.21 10.42.42.21 UGH1 0 0 - 56em010.2.0/24 10.42.42.1 UG1 0 0 - 56em010.42.0/24 10.42.42.1 UG1 0 0 - 56em010.42.1.56/30 10.42.42.21 UG1 0 0 - 56em010.42.1.64/30 10.42.42.21 UG1 0 0 - 56em010.42.7.6 10.42.42.21 UGH1 0 0 - 56em010.42.7.7 10.42.42.21 UGH1 0 0 - 56em010.42.7.53 10.42.42.21 UGH1 0 0 - 56em010.42.42/24 10.42.42.69 U1h 66 193 - 56em010.42.42.69 08:00:27:d6:6e:dd UHLl 0 104 - 1em010.42.42.255 10.42.42.69 UHb 0 13 - 1em010.60.77.5 10.42.42.1 UGH1 0 0 - 56em0[...]But after that, the box cannot join anythin with IPv4. Establishedconnections (eg. ssh) over IPv4 fails. Even the gateway is unreachable:openbsd-test# ping 10.42.42.1PING 10.42.42.1 (10.42.42.1): 56 data bytesping: sendmsg: Invalid argumentping: wrote 10.42.42.1 64 chars, ret=-1ping: sendmsg: Invalid argumentping: 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 lossWith no ospfv3 configured, ipv6 connections are not lostdmesg returns theses messages :arp_rtrequest: bad gateway value: em0arpresolve: 10.42.42.1: route contains no arp informationarpresolve: 10.42.42.0: route contains no arp informationarpresolve: 10.42.42.1: route contains no arp informationThe last ones beeing flooded when the box tries to send packetsWhatever bird makes to the networking stack persists even if bird isshut down. A reboot is necessary to recover.On OpenBSD mailing list, someone said the problem may be birdoverwriting the 10.42.42/24 route (which was directly connected) byanother (the flags changed from UCn to U1h)After stopping bird, flags and prios are not restored (10.42.42/24 getsU1 / prio 56), and the default route kept is the one bird insertedopenbsd-test# route -n show -inetRouting tablesInternet:Destination Gateway Flags Refs Use Mtu PrioIfacedefault 10.42.42.1 UG1 2 2 - 56em0224/4 127.0.0.1 URS 0 13 32768 8lo010.42.42/24 10.42.42.69 U1 0 76 - 56em010.42.42.69 08:00:27:d6:6e:dd UHLl 0 23 - 1em010.42.42.255 10.42.42.69 UHb 0 6 - 1em0127/8 127.0.0.1 UGRS 0 0 32768 8lo0127.0.0.1 127.0.0.1 UHhl 1 2 32768 1lo0Do you know how to prevent that ?Thanks,--Bastien