Bird 3 asynchronous processing and ospf delays

[Robert Story]

Hello,

We noticed a change from bird2 to bird3where route processing happens in a
very different order.

We’re running bird on a load balancer, and for us this change results in
traffic drops for 1-2 minutes because our production service prefix is
announced before we can reply because OSPF to the backends for the service
address happens much later than before.

We’re hoping to get feedback on if this change in bird3 is a bug, or if we
should be using bird differently.

The scenario is:

   transit-providers --- load-balancer w/bird --- several back-end servers

- The balancer runs BGP to the transit and OSFP to the backends.
- We get full routing tables from 3 transit providers.

Bird OSPF configuration snippets are included at the end of this message.

With bird1 and bird2, ospf would come up and both the local link addresses
and the service addresses (on a stub dummy0 interface on the backends) would
be exchanged within 5-10 seconds, before or shortly after BGP sessions with
peers start.

With bird3, ospf processes local link addresses, then starts BGP (including
announcing service prefix to peers), and ospf processing of the dummy0 stub
interface for the route to the service address doesn’t happen until BGP peers
have sent their full BGP tables.

So our questions are:

- is there is a setting to make bird 3 use the old synchronous behavior?
- is there a way to tweak ospf config to get dummy0 service address earlier
    (ie before or shortly after firewall announces static routes)?
- is there a way to tweak bird config to delay static route announcement until after
    ospf gets service address (or after all peers have sent initial full
    tables)?
- should we drop static service routes in the firewall, and drop
    ospf and just use BGP between backends and firewalls so that production
    route isn’t announced until at least one backend is available?

Any other suggestions welcomed as well.

The relevant snippets of setup which works with bird1/bird2 but not bird3 is:

- relevant firewall/load balancer config:

protocol ospf v3 ospfv6 {
ecmp yes;
area 0 { interface “eno*” { hello 1; dead 5; }; };
}

protocol static sv4master {
ipv4;
route a.b.c.0/24 blackhole; # service prefix
}

- relevant backends config:

protocol ospf v2 ospfv4 {
ipv4; # service address a.b.c.N on dummy0 interface
area 0 {
interface “dummy0” { stub yes; };
interface “eno1” { hello 1; dead 5; }; };
}
protocol ospf v3 ospfv6 {
ipv6;
area 0 {
interface “dummy0” { stub yes; };
interface “eno1” { hello 1; dead 5; }; };
}
protocol device { scan time 10; }

Regards,
Robert