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