Holy cow, it works in bird3. I tried with 50k routes. Thanks Maria.

QQ, how are you sending millions of routes? populate the static protocol in the conf file with those routes and let bgp export those? Just checking to see if there are other ways to pump these routes other than generating a conf file with them already present.

Neighbor        V    AS    MsgRcvd    MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.0.0.2        4 65000         84         19    11948    0    0 00:00:01 50000

Attaching to module 1 ...
To exit type 'exit', to abort type '$.'
module-1# sh hardware internal s1hal dchal l3 event-history trace | grep -i received
module-1#
module-1#
module-1# sh hardware internal s1hal dchal l3 event-history trace | grep -i received
2026-04-08T18:43:11.234661000+00:00 [M 1] [s1hal] E_DEBUG [L3:TRACE l3_route.cpp: :hal_sone_l3_route_update_internal:4468] Received route add for VRF 0x1, pfx 50.0.196.80/32, route_flags 0x0 src_lif 0x0(Lo: 'FALSE') ecmp_id 0x0 adj_i
d: 0x40000 myip 0 attr_cnt 1 mpls_ppfx 0 vrf_redir: 0
2026-04-08T18:43:11.234658000+00:00 [M 1] [s1hal] E_DEBUG [L3:TRACE l3_route.cpp: :hal_sone_l3_route_update_internal:4468] Received route add for VRF 0x1, pfx 50.0.196.79/32, route_flags 0x0 src_lif 0x0(Lo: 'FALSE') ecmp_id 0x0 adj_i
d: 0x40000 myip 0 attr_cnt 1 mpls_ppfx 0 vrf_redir: 0
2026-04-08T18:43:11.234654000+00:00 [M 1] [s1hal] E_DEBUG [L3:TRACE l3_route.cpp: :hal_sone_l3_route_update_internal:4468] Received route add for VRF 0x1, pfx 50.0.196.78/32, route_flags 0x0 src_lif 0x0(Lo: 'FALSE') ecmp_id 0x0 adj_i
d: 0x40000 myip 0 attr_cnt 1 mpls_ppfx 0 vrf_redir: 0
2026-04-08T18:43:11.234651000+00:00 [M 1] [s1hal] E_DEBUG [L3:TRACE l3_route.cpp: :hal_sone_l3_route_update_internal:4468] Received route add for VRF 0x1, pfx 50.0.196.77/32, route_flags 0x0 src_lif 0x0(Lo: 'FALSE') ecmp_id 0x0 adj_i
d: 0x40000 myip 0 attr_cnt 1 mpls_ppfx 0 vrf_redir: 0
2026-04-08T18:43:11.234648000+00:00 [M 1] [s1hal] E_DEBUG [L3:TRACE l3_route.cpp: :hal_sone_l3_route_update_internal:4468] Received route add for VRF 0x1, pfx 50.0.196.76/32, route_flags 0x0 src_lif 0x0(Lo: 'FALSE') ecmp_id 0x0 adj_i
d: 0x40000 myip 0 attr_cnt 1 mpls_ppfx 0 vrf_redir: 0
2026-04-08T18:43:11.234644000+00:00 [M 1] [s1hal] E_DEBUG [L3:TRACE l3_route.cpp: :hal_sone_l3_route_update_internal:4468] Received route add for VRF 0x1, pfx 50.0.196.75/32, route_flags 0x0 src_lif 0x0(Lo: 'FALSE') ecmp_id 0x0 adj_i
d: 0x40000 myip 0 attr_cnt 1 mpls_ppfx 0 vrf_redir: 0
2026-04-08T18:43:11.234640000+00:00 [M 1] [s1hal] E_DEBUG [L3:TRACE l3_route.cpp: :hal_sone_l3_route_update_internal:4468] Received route add for VRF 0x1, pfx 50.0.196.74/32, route_flags 0x0 src_lif 0x0(Lo: 'FALSE') ecmp_id 0x0 adj_i
d: 0x40000 myip 0 attr_cnt 1 mpls_ppfx 0 vrf_redir: 0
2026-04-08T18:43:11.234637000+00:00 [M 1] [s1hal] E_DEBUG [L3:TRACE l3_route.cpp: :hal_sone_l3_route_update_internal:4468] Received route add for VRF 0x1, pfx 50.0.196.73/32, route_flags 0x0 src_lif 0x0(Lo: 'FALSE') ecmp_id 0x0 adj_i
d: 0x40000 myip 0 attr_cnt 1 mpls_ppfx 0 vrf_redir: 0
2026-04-08T18:43:11.234633000+00:00 [M 1] [s1hal] E_DEBUG [L3:TRACE l3_route.cpp: :hal_sone_l3_route_update_internal:4468] Received route add for VRF 0x1, pfx 50.0.196.72/32, route_flags 0x0 src_lif 0x0(Lo: 'FALSE') ecmp_id 0x0 adj_i
d: 0x40000 myip 0 attr_cnt 1 mpls_ppfx 0 vrf_redir: 0
2026-04-08T18:43:11.234630000+00:00 [M 1] [s1hal] E_DEBUG [L3:TRACE l3_route.cpp: :hal_sone_l3_route_update_internal:4468] Received route add for VRF 0x1, pfx 50.0.196.71/32, route_flags 0x0 src_lif 0x0(Lo: 'FALSE') ecmp_id 0x0 adj_i
d: 0x40000 myip 0 attr_cnt 1 mpls_ppfx 0 vrf_redir: 0
2026-04-08T18:43:11.234626000+00:00 [M 1] [s1hal] E_DEBUG [L3:TRACE l3_route.cpp: :hal_sone_l3_route_update_internal:4468] Received route add for VRF 0x1, pfx 50.0.196.70/32, route_flags 0x0 src_lif 0x0(Lo: 'FALSE') ecmp_id 0x0 adj_i
d: 0x40000 myip 0 attr_cnt 1 mpls_ppfx 0 vrf_redir: 0
2026-04-08T18:43:11.234622000+00:00 [M 1] [s1hal] E_DEBUG [L3:TRACE l3_route.cpp: :hal_sone_l3_route_update_internal:4468] Received route add for VRF 0x1, pfx 50.0.196.69/32, route_flags 0x0 src_lif 0x0(Lo: 'FALSE') ecmp_id 0x0 adj_i
d: 0x40000 myip 0 attr_cnt 1 mpls_ppfx 0 vrf_redir: 0

Sincerely
Gautham

On Tue, Apr 7, 2026 at 4:22 PM Maria Matejka <maria.matejka@nic.cz> wrote:

Hello,

On Tue, Apr 07, 2026 at 02:14:40PM -0700, gautham devalapalli wrote:

When advertising the routes from BGP to an nxos switch, we are noticing the routes come in random order instead of sequential order.

That’s expected.

Using bird 2.0.8 version.

That’s very old.

Is there a way to force an order of routes like how Ixia traffic generator does this.

There is literally no way. We may think of some hacks and quirks how to immitate that but there is no actual guarantee, and it will work only in very limited scenarios.

I expect that you wanna use this for traffic-blasting other BGP implementations, and that is something not really expected from BIRD. While I admit that I’m using myself a custom-modified BIRD 3 to blast another BIRD 3 with millions of routes to measure performance, it’s not an officially supported use-case for now.

We are not opposed to implementing traffic-blasting extensions into our BGP. However, even keeping the send order is hard, and the TX routines belong to the most complicated parts of BGP. I would expect that there would be much more one could desire here, and all of that carries quite some maintenance burden which only grows over time.

In other words, money can fix this.

Until then, you may try starting the static protocol disabled and enabling it after startup, that should help. But if you wanna get full-speed blast, you are screwed. Also, you may wanna try the same scenario with BIRD 3, you may get, paradoxically, more stable results.

Happy route-blasting! Maria

–
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.