Bird 3 asynchronous processing and ospf delays

[Robert Story]

Hi David,

responses inline below..

On Fri 2025-10-17 15:54:10+0200 David wrote:
> generally you should not depend on the order of start up of the 
> protocols in BIRD, because it is an implementation detail and might be 
> changed if needed, even in BIRD v2. There is no setting to make it 
> behave like in v2, but you could make the order explicit by having the 
> protocols Static or BGP disabled and then enable it later with birdc.  

We did think about that, but couldn't figure out how to specify that a
protocol be disabled at startup.

> With that said the increase from 10-15 seconds to 1-2 minutes is very 
> SUSpicious and might hint at you encountering some different behavior 
> then previously in OSPF (e.g. with regards to the designated router 
> selection etc.) or possibly hint at a bug in BIRD.
> 
> Could you enable the `debug protocols all; debug channels all; debug 
> tables all;` on both sides on v2 as well as on v3 and sent it to us, so 
> we can see what is taking so long?
> Full config might also help us.  

We're working on trying to reproduce this on our testbed, but with bird2
working it's a good ways down the priority list.

> Is the issue happening only on start up or repeatedly while running as 
> well?  

Only at startup. Once we get the address routes to the backends from OSPF,
they're stable.

> Also what exactly are you trying to achieve? We might be able to help 
> you more if we know more about the desired outcome.  

We just need to have the routes to the backends before our static routes to
the prefixes are announced. What we probably should be doing is droping
static routes from the firewall config and switching from OSPF to BGP between
backends and firewalls so that the production route isn’t announced until at
least one backend is available.

Regards,
Robert

> On 10/16/25 23:06, Robert Story wrote:
> > 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