- Bird-users - Mailing Lists

[PATCH] bgp: Implement RFC 9234
by Eugene Bogomazov 12 Jul '22

12 Jul '22

Hello, RFC 9234 provides a new mechanism for route leak detection and prevention. In the attachment you can find a patch which introduces this functionality for BIRD 2.0.9.

4 12

BIRD 3.0-alpha0
by Ondrej Filip 11 Jul '22

11 Jul '22

Dear BURD users, We have something special for you today. We're releasing a multi-threaded BIRD version 3.0-alpha0 for public testing. Protocols BGP, RPKI and Pipe got their own channels which promises faster convergence and better usage of system resources. Version 3.0-alpha0 is based on the previous 2.0.8 version and some enhancements from 2.0.9 will make it into the multi-threaded branch later on. There is also a blogpost about performance comparison we have recently done between 3.0-alpha0 and 2.0.8 (the previous single-threaded version) and you can read there also other articles about the multi-threaded version. We do not recommend running this version in production setups, yet we deeply appreciate any bugreports, including memory footprint problems. You can download the tgz package at the following URLs: https://bird.network.cz/?download&tdir=3.0pre/ ftp://bird.network.cz/pub/bird/3.0pre/ Main credits goes to Maria! Thank you! Ondrej Version 3.0-alpha0 (2022-02-07) o Removal of fixed protocol-specific route attributes o Asynchronous route export o Explicit table import / export hooks o Partially lockless route attribute cache o Thread-safe resource management o Thread-safe interface notifications o Thread-safe protocol API o Adoption of BFD IO loop for general use o Parallel Pipe protocol o Parallel RPKI protocol o Parallel BGP protocol o Lots of refactoring o Bugfixes and improvements as they came along

8 17

Bird performance issue with many PPPOE interfaces and a large routing table.
by LU 07 Jul '22

07 Jul '22

Hi, I have a setup that looks like this: upstream1 upstream2 upstream3 upstream4 | | | | +------------------+ +-----------------+ | bgp1 rr | | bgp2 rr | | ebgp to upstreams |ebgp to upstreams| | ibgp to bgp2 | |ibgp to bgp1 | +------------------+ +-----------------+ | | +-----------+ +-----------+ | location a| ------------- | location b| +---switch--+ +---switch--+ | | | | +-------------------+ +-----------------------+ | pppoe serv 1 | | pppoe serv 2 | | rr client of bgp1 | | rr client of bgp1 | | rr client of bgp2 | | rr client of bgp2 | - +-------------------+ +-----------------------+ BGP1 and BGP2 are ebgp peering with upstream providers. BGP1 and BGP2 are ibgp peering between themselves to exchange routes and act as route reflectors towards PPPOE SERV 1 and PPPOE SERV 2. There is an area 0 in ospf with broadcast between BGP1/BGP2/PPPOE SERV1/SERV2. On PPPOE SERV1/SERV2 Bird is used to redistribute pppoe /32 addresses of clients. I put everything in the single routing table but mark prefixes with communites to know where they come from and to filter based on that. By default PPPOE SERV1/2 receives only a default route from both BGP1 and BGP2. With such multipath default route, a packet on PPPOE SERV1 destined for UPSTREAM 1 can end up at BGP2 (depends how it is hashed) where it is routed then to BGP1. I wanted to optimize this by feeding routes from BGP1/BGP2 to PPPOE SERV1/ SERV2. Now such unnecessary jumping back and forth between BGP1/BGP2 of packets from PPPOE SERVERS would be kept to a minimum. However with the following setup, where I now feed /24 and lower routes from a combination of the upstream providers to PPPOE Servers (about 800k routes) I face performance issues that causes a mild packet loss on the PPPOE Servers (which is not present if only default routes are used). To give an example: PPPOE SERV1 has about 2000 PPPOE interfaces of the form: 1535: subpppoe.1423: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc htb state UNKNOWN mode DEFAULT group default qlen 3 link/ppp and is using ACCEL-PPP software for the PPPOE client termination. The server has an 8 core cpu. The network card has 6 RSS queues that are pinned to CPU 0,1,2,3,4,5,7 via /proc/irq/XXX/snmp_affinity_list. Bird is pinned to the last unused CPU via: taskset -cp 8 $(pgrep bird) The ACCEL-PPP termination software is using 6 threads internally and I have pinned the entire process to the first 7 CPUs: taskset -cp 0-7 $(pgrep accel-pppd) In essence Bird should have its own CPU to perform route calculations without affecting any packet routing. When the 800k routes are fed to the server from the BGP route reflectors, on CPU 8; Bird is periodically jumping to 100% cpu usage for a brief moment (that is expected, calculating routes), but at the same time, the ACCEL-PPPD daemon process is also jumping to very high values (about 80%ish). This causes a brief packet loss on the PPPOE client interfaces. I wonder, is there anything I can do to prevent this from happening or is this a combination of route calculation/interface scanning that causes some sort of brief lockup in processing on the PPPOE daemon? By sticking to default routes on the PPPOE SERVERs, Bird does ocassionally jump to a high CPU usage, but the PPPOE daemon doesn't and I can't detect any packet loss on the PPPOE Servers. Any suggestion appreciated. Thank you. -- I have included some sample Bird configs from the machines: BGP1 to BGP2 config sample: protocol static myas_routes { ipv4; route 1.2.3.4.0/24 blackhole { preference = 1; }; route 4.3.2.1.0/24 blackhole { preference = 1; }; } protocol bgp ibgp_from_bgp1_to_bgp2 { local as 1111; neighbor <loopback ip of bgp2> as 1111; source address <loopback ip of bgp1>; rr cluster id 0.0.0.1; ipv4 { next hop self; export filter { /* exports only RTS_BGP routes and "myas_routes" object */ } import filter { /* imports all but sets a lower preference to routes that originate from BGP2's rr clients */ } }; } Sample config of BGP1 to PPPOE SERV1: protocol bgp rr_bgp1_to_pppoe_serv1 { disabled no; local as 1111; neighbor <loopback ip of pppoe serv 1> as 1111; source address <loopback ip of bgp1> ; rr client; rr cluster id 0.0.0.1; ipv4 { next hop self ebgp; export filter { <exports /24 and lower routes from ebgp upstream 1,2,3,4> }; import filter { <imports /32 pppoe client addresses from pppoe serv1> }; }; }; } Sample config of PPPOE SERV1 to BGP1: protocol kernel { merge paths yes; learn yes; ipv4 { import all; export all; }; } protocol device { } protocol direct { ipv4; } protocol bgp rr_pppoe_serv1_to_bgp1 { local as 1111; neighbor <loopback ip of bgp1> as 1111; source address <loopback ip of pppoe serv 1>; ipv4 { next hop self; export filter { if source = RTS_DEVICE || source = RTS_STATIC_DEVICE || source = RTS_STATIC || source = RTS_INHERIT then { accept; } reject; }; import all; }; }

2 1

Debian armel test fail blocking transition to testing
by Jakub Ružička 28 Jun '22

28 Jun '22

Hello, bird-2.0.10 builds fine on most of Debian archs, but on armel, hppa, and riscv64 there is a failing test: obj/filter/trie_test: t_trie_walk: Timeout expired obj/filter/trie_test: t_trie_walk 5.010453063s [FAIL] obj/filter/trie_test 12.572917503s [FAIL] make[1]: *** [Makefile:180: obj/filter/trie_test.ok] Error 1 make[1]: *** Waiting for unfinished jobs.... make[1]: Leaving directory '/<<PKGBUILDDIR>>' dh_auto_test: error: make -j4 test "TESTSUITEFLAGS=-j4 --verbose" VERBOSE=1 returned exit code 2 make: *** [debian/rules:21: build-arch] Error 25 Nice overview including log tails here: https://buildd.debian.org/status/package.php?p=bird2 As these tests are run as part of build, failing tests result in FTBFS and armel FTBFS is blocking transition to testing as seen here: https://tracker.debian.org/pkg/bird2 armel refers to older ARM 32-bit HW - if you have access to the arch, could you please test/fix this? Cheers, Jakub Ružička

4 4

BIRD version 2.0.10
by Ondrej Filip 27 Jun '22

27 Jun '22

Dear users, We just released a second stable version of BIRD this year. Many thanks to my great colleagues and namely Santiago. Here is a list of the main improvements: Version 2.0.10 o BGP performance improvements o BFD: New 'strict bind' option o RPKI: VRF support o Allow use of 240.0.0.0/4 as a private range o BIRD client uses exit status to report errors o Important bugfixes Enjoy! Ondrej

1 0

OSPF & merge external on
by Mikhail Mayorov 26 Jun '22

26 Jun '22

Hello! I would like use ECMP for 0.0.0.0/0. This route announced on 10.10.97.33, 10.10.97.72, 10.10.97.73 as LSA5. Below I have given the output of the command on the router 10.10.97.67. I expected to see a default route through 2 interfaces C3 to D1, but next hops not merge. Maybe I misunderstand the work "merge external on". I expected that the bird would combine routes from different routers for the same destination although OSPF.metric1 or OSPF.metric2. bird>show route for10.10.97.73 table igpcoret4 all Table igpcoret4: 10.10.97.73/32unicast [igpcore4 20:05:45]*E2 (150/310/10000)[10.10.97.73] via 10.112.0.14 on C3 weight 40 via 10.112.0.28 on D1 weight 40 Type:OSPF-E2 univ OSPF.metric1:310 OSPF.metric2:10000 OSPF.tag:0x00000000 OSPF.router_id:10.10.97.73 bird>show route for10.10.97.72 table igpcoret4 all Table igpcoret4: 10.10.97.72/32unicast [igpcore4 20:05:45]*E2 (150/2300/10000)[10.10.97.72] via 10.112.0.14 on C3 Type:OSPF-E2 univ OSPF.metric1:2300 OSPF.metric2:10000 OSPF.tag:0x00000000 OSPF.router_id:10.10.97.72 bird>show route for10.10.97.33 table igpcoret4 all Table igpcoret4: 10.10.97.33/32unicast [igpcore4 20:05:45]*E2 (150/300/10000)[10.10.97.33] via 10.112.0.14 on C3 Type:OSPF-E2 univ OSPF.metric1:300 OSPF.metric2:10000 OSPF.tag:0x00000000 OSPF.router_id:10.10.97.33 bird>show route for0.0.0.0/24table igpcoret4 all Table igpcoret4: 0.0.0.0/0unicast [igpcore4 20:05:45]*E2 (150/300/10000)[10.10.97.33] via 10.112.0.14 on C3 Type:OSPF-E2 univ OSPF.metric1:300 OSPF.metric2:10000 OSPF.tag:0x00000000 OSPF.router_id:10.10.97.33 bird> >showospf state all igpcore4 area 0.0.0.0 router 10.10.97.33 distance 300 router 10.10.97.72metric 2000 router 10.10.97.72metric 2000 router 10.10.97.72metric 2000 router 10.10.97.72metric 2000 router 10.10.97.73metric 10 router 10.10.97.67metric 300 router 10.10.97.66metric 300 router 10.10.97.68metric 65535 stubnet 10.112.0.0/31metric 2000 stubnet 10.112.0.2/31metric 2000 stubnet 10.112.0.4/31metric 2000 stubnet 10.112.0.6/31metric 2000 stubnet 10.112.0.12/31metric 10 stubnet 10.112.0.14/31metric 300 stubnet 10.112.0.18/31metric 300 stubnet 10.112.0.22/31metric 65535 external 0.0.0.0/0metric2 10000 external 10.112.0.0/31metric2 10000 external 10.112.0.2/31metric2 10000 external 10.112.0.4/31metric2 10000 external 10.112.0.6/31metric2 10000 external 10.112.0.12/31metric2 10000 external 10.112.0.14/31metric2 10000 external 10.112.0.18/31metric2 10000 external 10.112.0.22/31metric2 10000 external 87.245.238.204/31metric2 10000 external 10.10.8.0/21metric2 10000 external 10.10.97.33/32metric2 10000 router 10.10.97.66 distance 10 router 10.10.97.73metric 300 router 10.10.97.33metric 300 router 10.10.97.69metric 65535 router 10.10.97.67metric 10 stubnet 10.112.0.16/31metric 300 stubnet 10.112.0.18/31metric 300 stubnet 10.112.0.24/31metric 65535 stubnet 10.112.0.28/31metric 10 external 10.112.0.16/31metric2 10000 external 10.112.0.18/31metric2 10000 external 10.112.0.24/31metric2 10000 external 10.112.0.28/31metric2 10000 external 10.10.0.0/21metric2 10000 external 10.10.97.66/32metric2 10000 router 10.10.97.67 distance 0 router 10.10.97.33metric 300 router 10.10.97.66metric 10 router 10.10.97.69metric 65535 stubnet 10.112.0.14/31metric 300 stubnet 10.112.0.28/31metric 10 stubnet 10.112.0.26/31metric 65535 external 10.112.0.14/31metric2 10000 external 10.112.0.26/31metric2 10000 external 10.112.0.28/31metric2 10000 external 10.10.0.0/21metric2 10000 external 10.10.97.67/32metric2 10000 router 10.10.97.68 distance 65835 router 10.10.97.73metric 65535 router 10.10.97.33metric 65535 stubnet 10.112.0.20/31metric 65535 stubnet 10.112.0.22/31metric 65535 external 10.112.0.20/31metric2 10000 external 10.112.0.22/31metric2 10000 external 10.10.97.68/32metric2 10000 router 10.10.97.69 distance 65535 router 10.10.97.66metric 65535 router 10.10.97.67metric 65535 stubnet 10.112.0.24/31metric 65535 stubnet 10.112.0.26/31metric 65535 external 10.112.0.24/31metric2 10000 external 10.112.0.26/31metric2 10000 external 10.10.97.69/32metric2 10000 router 10.10.97.72 distance 2300 router 10.10.97.33metric 2000 router 10.10.97.33metric 2000 router 10.10.97.33metric 2000 router 10.10.97.33metric 2000 router 10.10.97.73metric 2000 router 10.10.97.73metric 2000 stubnet 10.112.0.0/31metric 2000 stubnet 10.112.0.2/31metric 2000 stubnet 10.112.0.4/31metric 2000 stubnet 10.112.0.6/31metric 2000 stubnet 10.112.0.8/31metric 2000 stubnet 10.112.0.10/31metric 2000 external 0.0.0.0/0metric2 10000 external 10.112.0.0/31metric2 10000 external 10.112.0.2/31metric2 10000 external 10.112.0.4/31metric2 10000 external 10.112.0.6/31metric2 10000 external 10.112.0.8/31metric2 10000 external 10.112.0.10/31metric2 10000 external 10.10.97.72/32metric2 10000 external 100.105.99.0/30metric2 10000 router 10.10.97.73 distance 310 router 10.10.97.72metric 2000 router 10.10.97.72metric 2000 router 10.10.97.33metric 10 router 10.10.97.66metric 300 router 10.10.97.68metric 65535 stubnet 10.112.0.8/31metric 2000 stubnet 10.112.0.10/31metric 2000 stubnet 10.112.0.12/31metric 10 stubnet 10.112.0.16/31metric 300 stubnet 10.112.0.20/31metric 65535 external 0.0.0.0/0metric2 10000 external 10.112.0.8/31metric2 10000 external 10.112.0.10/31metric2 10000 external 10.112.0.12/31metric2 10000 external 10.112.0.16/31metric2 10000 external 10.112.0.20/31metric2 10000 external 10.10.8.0/21metric2 10000 external 10.10.97.73/32metric2 10000 external 188.170.160.52/30metric2 10000 -- Regards, Mikhail V. Majorov

2 2

routes, "strange next-hop" and p2p interfaces
by Eugene M. Zheganin 25 Jun '22

25 Jun '22

Hello, I have a peculiar VPN client that I want to redistributes the routes from. Technically it creates a tun0 interface and attaches all the routes it's connected to as it's own on-interface routes pointing to it's own IP (yeah, I know it's la me, but seems like it's written by Windows 98 addicts, so it's still pretty normal for them). This confuses bird and it 's complaining with usual ===Cut=== Jun 7 15:10:43 vipnet bird[28752]: KRT: Received route 1.2.3.4/26 with strange next-hop 5.6.7.8 ===Cut=== However: ===Cut=== [root@host ~]# ip addr show tun0 4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500 link/none inet 5.6.7.8/32 scope global tun0 valid_lft forever preferred_lft forever inet6 fe80::6d6d:315d:3deb:6ae0/64 scope link stable-privacy valid_lft forever preferred_lft forever ===Cut=== So far I'm reexporting these routes as static, but is there any way to do thsi automatically ? Thanks.

2 1

Scaling BFD support
by Douglas Fischer 24 Jun '22

24 Jun '22

The question raised by colleague Irene reminded me of a topic that may or may not be the focus of BIRD's development. I imagine that the biggest supporters of SMP/Multi-Core/Thread-Safe evolution on BIRD are Operators of Route-Servers of large IXPs, and operators of large-scale Route-Reflectors. Although BFD has its greatest use in the transport network and Underlay, it is increasingly common to see the use of BFD in BGP Internet. I'm personally overly excited about what BIRD version 3 is demonstrating in terms of vertical scalability. But I keep imagining that, even having scalability in the BGP engine, it is almost prohibitive to use BFD in a scenario with a thousand BGP Peers. Is there any view from the IBRD development team for this matter? Or even... Is there any open project focused on BFD that can address this? And going a little further... In a quick Brainstorming... What would be the techniques that could help a Route-Server or Route-Reflector with a thousand BGP Peers to also support a thousand BFD sessions effectively and efficiently? Perhaps resort to some hardware-based off-loading method? Would eBPF help this in any way? -- Douglas Fernando Fischer Engº de Controle e Automação

6 8

ECMP and merge routes from different routers/protocols for the same destination
by Mikhail Mayorov 24 Jun '22

24 Jun '22

Hello! I'm trying to increase the efficiency of ECMP on links between cities without static routes. On the same physical network (routers and links) I'm trying to run multiple independent OSPF protocols area 0 with different IDs (instance id). Example config file: protocol ospf v2 igpcore4 { ipv4 { table igpcoret4; import filter { ospf_metric1 = 100; accept; }; export all; }; ecmp on limit 12; merge external on; area 0.0.0.0 { interface "A2.1" { type pointopoint; bfd on; ecmp weight 10; cost 1000; }; interface "A2.2" { type pointopoint; bfd on; ecmp weight 10; cost 1000; }; interface "A3.1" { type pointopoint; bfd on; ecmp weight 10; cost 1000; }; interface "A3.2" { type pointopoint; bfd on; ecmp weight 10; cost 1000; }; interface "A1.1" { type pointopoint; bfd on; ecmp weight 10; cost 500; }; interface "A1.2" { type pointopoint; bfd on; ecmp weight 10; cost 500; }; }; }; protocol ospf v2 igpcore4_1 { ipv4 { table igpcoret4; import filter { ospf_metric1 = 100; accept; }; export all; }; ecmp on limit 12; merge external on; instance id 1; area 0.0.0.0 { interface "A2.1" { type pointopoint; bfd on; ecmp weight 10; cost 500; }; interface "A2.2" { type pointopoint; bfd on; ecmp weight 10; cost 500; }; interface "A3.1" { type pointopoint; bfd on; ecmp weight 10; cost 500; }; interface "A3.2" { type pointopoint; bfd on; ecmp weight 10; cost 500; }; interface "A1.1" { type pointopoint; bfd on; ecmp weight 10; cost 1000; }; interface "A1.2" { type pointopoint; bfd on; ecmp weight 10; cost 1000; }; }; }; I got this results area 0 instance 0 in protocol igpcore4 and area 0 instance 1 in protocol igpcore4_1 BIRD 2.0.9 ready. bird> show route for 10.10.97.33/32 all Table igpcoret4: 10.10.97.33/32 unicast [igpcore4_1 11:58:31] * E2 (150/100/10000) [10.10.97.33] via 10.112.0.1 on A2.1 weight 10 via 10.112.0.3 on A2.2 weight 10 via 10.112.0.5 on A3.1 weight 10 via 10.112.0.7 on A3.2 weight 10 Type: OSPF-E2 univ OSPF.metric1: 100 OSPF.metric2: 10000 OSPF.tag: 0x00000000 OSPF.router_id: 10.10.97.33 unicast [igpcore4 11:58:31] E2 (150/100/10000) [10.10.97.33] via 10.112.0.1 on A2.1 weight 10 via 10.112.0.3 on A2.2 weight 10 via 10.112.0.5 on A3.1 weight 10 via 10.112.0.7 on A3.2 weight 10 via 10.112.0.9 on A1.1 weight 10 via 10.112.0.11 on A1.2 weight 10 Type: OSPF-E2 univ OSPF.metric1: 100 OSPF.metric2: 10000 OSPF.tag: 0x00000000 OSPF.router_id: 10.10.97.33 How to megre these routes and get a single route with 6 next hops interfaces.... Maybe via pipe or other variants? -- Regards, Mikhail V. Majorov

1 0

BGP MSG Updates counters - Sent and Received per peer
by Douglas Fischer 21 Jun '22

21 Jun '22

I know it sounds stupid was it here but I'm feeling a bit dumb and impatient with this. On and environment with several(1000+) peers, I need to collect on a very simples and with less performance impact of the following information each 5-to-5 ou 1-to-1 minute: - Peer status - Number of Routes Received by peer - Number of Routes Sent by peer - BGP Msg Updates Received by Peer - BGP Msg Sent Sent by peer And I don't know what is the best way to get those informations. I saw something about birdwatcher. That sounds good, but I heard some about a bit os instability. I saw bird_exporter, that maybe can be a good tool. And the other "ugly" idea is to use Zabbix agent that will collect the routes via birdc and parse it. Any news about that? Any update.

1 0