sorted route advertisements from bird bgp session.
Hello, When advertising the routes from BGP to an nxos switch, we are noticing the routes come in random order instead of sequential order. I tried using `sorted` option but doesnt seem to work. Using bird 2.0.8 version. Is there a way to force an order of routes like how Ixia traffic generator does this. ipv4 table ebgp1 sorted;; protocol bgp ebgp_1_node01 { local 10.0.0.2 as 65000; neighbor 10.0.0.1 as 100; ipv4 { table ebgp1; import none; export where source = RTS_STATIC; }; } protocol static v4static{ ipv4 { table ebgp1; }; route 50.0.1.1/32 via 10.0.0.2; route 50.0.1.2/32 via 10.0.0.2; route 50.0.1.3/32 via 10.0.0.2; route 50.0.1.4/32 via 10.0.0.2; route 50.0.1.5/32 via 10.0.0.2; route 50.0.1.6/32 via 10.0.0.2; } E_DEBUG [L3:TRACE l3_route.cpp: :hal_sone_l3_route_update_internal:4466] Received route add for VRF 0x1, pfx 50.0.1.1/32, route_flags 0x0 src_lif 0x0(Lo: 'FALSE') ecmp_id 0x0 adj_id: 0x40000 myip 0 attr_cnt 1 mpls_ppfx 0 vrf_redir: 0 E_DEBUG [L3:TRACE l3_route.cpp: :hal_sone_l3_route_update_internal:4466] Received route add for VRF 0x1, pfx 50.0.1.5/32, route_flags 0x0 src_lif 0x0(Lo: 'FALSE') ecmp_id 0x0 adj_id: 0x40000 myip 0 attr_cnt 1 mpls_ppfx 0 vrf_redir: 0 E_DEBUG [L3:TRACE l3_route.cpp: :hal_sone_l3_route_update_internal:4466] Received route add for VRF 0x1, pfx 50.0.1.2/32, route_flags 0x0 src_lif 0x0(Lo: 'FALSE') ecmp_id 0x0 adj_id: 0x40000 myip 0 attr_cnt 1 mpls_ppfx 0 vrf_redir: 0 E_DEBUG [L3:TRACE l3_route.cpp: :hal_sone_l3_route_update_internal:4466] Received route add for VRF 0x1, pfx 50.0.1.6/32, route_flags 0x0 src_lif 0x0(Lo: 'FALSE') ecmp_id 0x0 adj_id: 0x40000 myip 0 attr_cnt 1 mpls_ppfx 0 vrf_redir: 0 E_DEBUG [L3:TRACE l3_route.cpp: :hal_sone_l3_route_update_internal:4466] Received route add for VRF 0x1, pfx 50.0.1.3/32, route_flags 0x0 src_lif 0x0(Lo: 'FALSE') ecmp_id 0x0 adj_id: 0x40000 myip 0 attr_cnt 1 mpls_ppfx 0 vrf_redir: 0 E_DEBUG [L3:TRACE l3_route.cpp: :hal_sone_l3_route_update_internal:4466] Received route add for VRF 0x1, pfx 50.0.1.4/32, route_flags 0x0 src_lif 0x0(Lo: 'FALSE') ecmp_id 0x0 adj_id: 0x40000 myip 0 attr_cnt 1 mpls_ppfx 0 vrf_redir: 0 Sincerely Gautham
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.
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.
On Wed, Apr 08, 2026 at 12:14:57PM -0700, gautham devalapalli wrote:
Holy cow, it works in bird3. I tried with 50k routes. Thanks Maria.
huh crazy, well done then … next step 500k ;e)
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.
some statics and pipes, there is actually a whole perl bowl of spaghetti generating that … the testbed starts for like 5 minutes, eats 25G of memory, opens 30k passive BGP connections and is able to serve and consume about half a gigabit of BGP stream on something over 30 threads there is quite some fiddling with that and virtually no documentation to the performance testbed, and also probably some crude hacks have never left the testbed machines but i still feel impressed by the sheer flow of valid BGP which is BIRD 3 able to serve, whenever i run any perf test -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
participants (2)
-
gautham devalapalli -
Maria Matejka