July 2022 - Bird-users - Mailing Lists

[RFC] Automatic MP peering with IPv6 link local peers
by Nico Schottelius 15 Jul '22

15 Jul '22

Good morning^2, as virtually all parts in our datacenters have become IPv6 only, I was wondering if it was easy to add a feature to bird to automatically BGP peer with all alive link local neighbours? Motivation and situation ------------------------ Every node has an IPv6 link local address on every network interface. Bird already supports dynamic peers, including whitelisting of ranges. Instead of specifying specific ranges, it would be great if two or more routers could be placed in the same layer 2 segment and would automatically BGP peer with each other, thus removing any configuration needs. OSPF does a similar job already, however it is not suitable for transferring the BGP attributes. Implementation sketch -------------------------------------------------------------------------------- The idea would be for each router have something on the line of protocol bgp fe80auto { local as 65532; neighbor range fe80::/12 as 65534; dynamic name "link_local_"; # New option, similar to the OSPF option auto_fe80_interfaces "eth1.*"; ipv6 { }; ipv4 { }; } If bird had the stanza auto_fe80_interfaces in it, it would a) ping ff02::2 and record all results b) For each result, excluding our own address, connect to the other nodes c) On expiry or regular interal, go back to (a) and clear peers -------------------------------------------------------------------------------- Maybe this is already possible in current bird, but I haven't found a direct way to dynamically solve this. Looking forward to your thoughts, Nico -- Sustainable and modern Infrastructures by ungleich.ch

6 9

Dynamic reconfigurations of bird - how?
by Nico Schottelius 14 Jul '22

14 Jul '22

Good morning fellow bird users, I was wondering how you handle "dynamic reconfigurations" such as rerouting, adding filters, changing the priority of routes in case of attacks? In particular I wonder if there is a "good way" to tell bird to lower or raise a certain route temporarily, i.e. something that would be reset on a reload? Or to tell bird to forget about specific routes that you want to filter for blackholing certain parts? So far in case of attacks we usually edit bird.conf, reload bird and after the attacks are done, purge/overwrite the config with our config management (cdist in our case). This works, but has a bit of a write-reload instead of a set-and-forget behaviour, and I was more looking to something like "set on a switch, but don't issue the write command"-mode. Any thoughts on this? Best regards, Nico -- Sustainable and modern Infrastructures by ungleich.ch

3 2

[PATCH] Free interfaces in shutdown state
by Lorenz Brun 13 Jul '22

13 Jul '22

When interfaces are created and destroyed by automated systems, a potentially unbounded amount of interfaces exist. This results in bird consuming ever-increasing amounts of memory and CPU time for the list of known interfaces. This change frees the interface after it is in shutdown state and all notifications for it have been processed. --- nest/iface.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/nest/iface.c b/nest/iface.c index 682340c5..b4c65512 100644 --- a/nest/iface.c +++ b/nest/iface.c @@ -324,7 +324,7 @@ if_update(struct iface *new) if_copy(i, new); if (c) if_notify_change(c, i); - + i->flags |= IF_UPDATED; return i; } @@ -365,10 +365,10 @@ if_end_partial_update(struct iface *i) void if_end_update(void) { - struct iface *i; + struct iface *i, *x; struct ifa *a, *b; - WALK_LIST(i, iface_list) + WALK_LIST_DELSAFE(i, x, iface_list) { if (!(i->flags & IF_UPDATED)) if_change_flags(i, (i->flags & ~IF_ADMIN_UP) | IF_SHUTDOWN); @@ -379,6 +379,11 @@ if_end_update(void) ifa_delete(a); if_end_partial_update(i); } + if ((i->flags & IF_SHUTDOWN)) { + WALK_LIST_DELSAFE(a, b, i->addrs) + ifa_delete(a); + rem_node(&i->n); + } } } -- 2.36.1

2 2

Let packets from different BGP go to different routing tables
by Brandon Zhi 13 Jul '22

13 Jul '22

Hello fellow birdies, I'm having some difficulty connecting the nodes. Our network provides free IP Transit service so we need to carry downstream. We use OpenVPN/Wireguard connection between our nodes. We plan to use VLAN on OpenVPN or use GRE on Wireguard. This way, we have 2 interfaces tunnel1 and tunnel2 between each node. We created a bgp_v6 (IBGP) session on tunnel1 that allows downstream BGP sessions like HE(Hurricane Electric) and put the routing table into table 147. Create bgp_v6_own(IBGP) on tunnel2 to transmit those routing tables from BGP that cannot carry downstream to Table 247 Then we use ip rule Direct traffic to the correct routing table based on the interface. My English is not very good so I drew a picture for a description. link : https://i.postimg.cc/dtBDC4kh/photo-2022-07-12-12-54-28.jpg [image: image.png] The problem I'm having is that in IXP all BGP sessions differ only by IP or MAC. For instance: We have only one interface for BGP: ens18 And our IP Address is: 2a0f:5707:ffe3::57 AS141011 Our customers assume is: 2a0f:5707:ffe3::1 AS1 Our upstream which allowed downstream:2a0f:5707:ffe3::30 AS6939 Therefore we have a BGP session with AS1 and a BGP session with AS6939 AS6939 > Table 147 How should we get traffic from our downstream AS1 into Table 147? We have discussed using VLANs, but VLANs are usually not allowed in IXPs. The second solution is to use the ip rule to put every prefix from the downstream into Table 147, which is very inefficient. Do you have a better solution? Thanks -- *Brandon Zhi* HUIZE LTD www.huize.asia <https://huize.asia/>| www.ixp.su | Twitter <https://twitter.com/zhihuiyuze> This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee the text of the email message and virus.

2 3

[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