Bird 3 asynchronous processing and ospf delays

[David Petera]

Hello Robert,

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.

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.

Is the issue happening only on start up or repeatedly while running as 
well?
Also what exactly are you trying to achieve? We might be able to help 
you more if we know more about the desired outcome.

Note that this is exactly the type of question for our commercial 
support at bird-support at network.cz.
If you depend on BIRD in your daily operations or use it in non-standard 
way, consider contacting our sales department at bird-partner at nic.cz, so 
we can discuss contract that would work for your organization.

Hope this helps you and have a nice weekend!
David

David Petera (he/him) | BIRD Tech Support | CZ.NIC, z.s.p.o.

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
>