BFD socket bind error upon reboot

[J. Kendzorra]

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.