Hi,
Generally, BIRD should not try to use an address before it notices that
the address is available/active. If BIRD tries to bind the socket before
that, then it is a bug.
This seems to be a common pattern for services that are started when
network is supposedly ready, but it really isn't (see many discussions
around network.target vs. network-online.target).
Which BIRD version it is? It is an IPv6 address? Which protocol caused
the BFD session or it is static one? I would suspect that the issue
is related to IPv6 DAD.
Unfortunately, that's not the case; we have BFD enabled only for IPv4
protocol bfd bfd_internal {
neighbor 192.168.1.2;
(...)
neighbor 192.168.1.10;
};
We're running bird 1.6.3-3 (Ubuntu Bionic).
The error I've seen when the BFD sessions didn't come up was this:
<ERR> bfd_internal: Socket error: bind: Cannot assign requested address
Since the listeners on ports 3784 and 4784 are wildcard binds, those
shouldn't generate the error. However, there's a tx socket for
communication with BFD peers on a random port (192.168.1.1:38164 as of
today :) which I believe is the reason for the error message. Since the
interface in question is a vlan on top of a bond (with multiple NICs
involved), my working theory has been that upon reboot bird tried
binding to 192.168.1.1:0 but since this interface wasn't fully
available, got EADDRNOTAVAIL returned and BFD broke as a result. Note
that I was able to restart the protocol later (birdc restart
bfd_internal) which immediately made things work.
I added some debug code to the sections where the BFD protocol binds
sockets to catch when the bind happens and the error occurs (to support
my theory), however I haven't been able to replicate the problem yet.
Regards,
J.
