BGP strict bind socket error

[Ben Tremblay]

Hi all,

I have encountered a problem with how BIRD opens the listening socket for strict bind BGP.

In particular, BIRD sometimes tries to open the listening socket for the protocol when the configured local IP is not yet present on the interface. It seems that BIRD will try to bind the BGP socket to the configured IP if any address exists on the protocol interface that can be used to reach the neighbor. Let me give an example to clarify.

I have a minimal reproducible example with the following BGP configuration:

    router id 192.168.0.1;

    protocol device {
        scan time 10;
    }

    protocol bgp bgp_01 {
            ipv4 {
                    import all;
                    export all;
            };
            debug all;
            local 192.168.0.1 port 179 as 1;
            neighbor 192.168.0.2 port 179 as 1;
            interface "host1";
            direct;
            strict bind yes;
    }

Given this configuration, I can reproduce the problem behaviour by starting the protocol with no addressing on the host1 interface and then adding an address which includes the neighbor IP in its subnet, e.g. 192.168.0.3/24. Once this address/route is added, BIRD logs the following:

    Jan 07 12:09:31 router03 bird[57497]: bgp_01: Neighbor ready
    Jan 07 12:09:31 router03 bird[57497]: bgp_01: Socket error: bind: Cannot assign requested address
    Jan 07 12:09:31 router03 bird[57497]: bgp_01: Cannot open listening socket

And the protocol enters an error state:

    BIRD 2.0.6 ready.
    Name       Proto      Table      State  Since         Info
    device1    Device     ---        up     11:55:51.049
    bgp_01     BGP        ---        down   12:09:31.264  Error: No listening socket

The reason this error is so problematic for me is that the protocol cannot recover from this state without administrative intervention (e.g. configuring bird or restarting the protocol).

So, I have two questions:

    1. Is this correct behaviour?
    2. Can I configure BIRD so that my protocol is able to recover after suffering a socket error like this?

I should also mention I can actually observe this socket error occur when adding the 'correct' address to the protocol interface, but only in the context of a larger application and only some of the time.

Thanks,
Ben