August 2021 - Bird-users

route reflector setup problem
by SC SCx 28 Aug '21

28 Aug '21

Hi, I am trying to setup two route reflectors (that also pass traffic) that peer with ebgp (and exchange routes via ibgp between themselves). So something like. as100 as200 | | | | ebgp ebgp | | | | RR1(as999)--- ibgp --- RR2(as999) | \ / | | \ / | | \ / | | \ / | | \ / | | \ / | | \ / | | X | | / \ | | / \ | | / \ | | / \ | | / \ | rr client 1 rr client 2 I came up with a config like this (for simplicity's sake I will only show RR1's side since it's the equivalent for RR2 with just slightly different parameters like ip addresses, etc.) # ebgp from RR1 to as100 protocol bgp ebgp_as100 { local as 1000; neighbor 100.100.100.100 as 100; export filter { if PREFIXES_TO_EXPORT() then accept; reject; } import filter { if PREFIXES_TO_IMPORT_LTE_24() then accept; reject; } } # ibgp from RR1 to RR2 protocol bgp ibgp { local as 999; neighbor 10.0.0.2 as 999; source address 10.1.0.1; next hop self; rr cluster id 0.0.0.1; } # RR1 to rr client 1 (also has one for rr client 2) protocol bgp rr_client1{ local as 999; neighbor 10.0.0.3 as 999; source address 10.1.0.1; rr client; rr cluster id 0.0.0.1; # next hop self #??? export filter { if PREFIXES_TO_EXPORT() then accept; reject; }; import filter { if PREFIXES_TO_IMPORT() then accept; reject; }; } ########################################################## # on rr client 1 to RR1 (also has one for RR2) protocol bgp rr1_ibgp { local as 999; neighbor 10.0.0.1 as 999; source address 10.1.0.3; next hop self; export all; import all; } This works, but with some problems. Prefixes learned from AS100 and AS200 that get exported to RR clients are unreachable unless they passed through the IBGP connection between RR1 and RR2. Makes sense, since the IBGP connection between RRs is defined with next hop self, and the RR client connections aren't. So, I went in, and added "next top self" to the connections between RRs and RR clients. It has fixed the unreachable problem but caused another one. Now prefixes that are exported on RR clients to RRs have their next hop changed which is not what I want. I want to leave them intact. (e.g. RR clients can export some private ip ranges which I don't want to be routable on the RRs) So I *think* that I need a way on the RRs to only change next hop of EBGP prefixes that get exported from RRs to RR clients but leave other prefixes unaffected. Is my thinking correct? How can this be achieved? Thanks.

2 3

Bird 2.0.7 not accepting BGP connections in a VRF
by William 27 Aug '21

27 Aug '21

Hi All, I have a Debian 11 host (5.10.0-8-amd64 kernel) with Bird 2.0.7. There is a VRF set up called CORE. Originally VRF and route table ID were high (>100000000) but everything seemed fine apart from the fact that even though Bird was listening for BGP connections in the VRf, nothing was actually being received by the daemon. I have since dropped the VRF ID and routing table down to 32, but no change. bond0.64 is in the VRF, with 198.18.64.254/30 as its IP. Neighbour device has 198.18.64.253, and the can ping each other happily. No firewall is configured. Bird listening on the VRF interface (with SSH in MGMT VRF which works fine): # ss -tuplne --cgroup --tipcinfo Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process tcp LISTEN 0 8 198.18.64.254%CORE:179 0.0.0.0:* users:(("bird",pid=3807,fd=6)) uid:106 ino:62370 sk:102a cgroup:/system.slice/bird.service <-> cgroup:/system.slice/bird.service tcp LISTEN 0 128 0.0.0.0%MGMT:22 0.0.0.0:* users:(("sshd",pid=824,fd=3)) ino:12780 sk:1025 cgroup:/system.slice/ssh.service/vrf/MGMT <-> cgroup:/system.slice/ssh.service/vrf/MGMT tcp LISTEN 0 128 [::]%MGMT:22 [::]:* users:(("sshd",pid=824,fd=4)) ino:12790 sk:1026 cgroup:/system.slice/ssh.service/vrf/MGMT v6only:1 <-> cgroup:/system.slice/ssh.service/vrf/MGMT # Normally Bird is not started inside the VRF, but even when it does, I get no change. I have tried changing the interface that the BGP protocol is listening on, no change there. Here is the template that the BGP session is initiated from: template bgp CORE_RTR_BGP4_TMPL { # Will use IP of interface neighbour is connected to as IP is not set. # Override with "source address <ip>" in protocol definition or # 'interface "string"' for IPv6. See Bird docs, section 6.3.4 local 198.18.64.254 as CORE_my_asn; # vrf "CORE"; ipv4 { import filter CORE_bgp_import4; export filter CORE_bgp_export4; table CORE_Routes4; next hop self; }; vrf CORE_vrf; # interface "bond0.64"; # interface "CORE"; # direct; strict bind on; } and here is the protocol def itself: protocol bgp CORE_LabRTR2_BGP4 from CORE_RTR_BGP4_TMPL { description "IPv4 BGP to LabRTR2"; neighbor 198.18.64.253 as CORE_rcore_asn; # disabled; passive; } I have tried all variants of interface & launching inside and outside the VRF with no change. If I connected locally inside the vrf I can connect to the daemon: # ip vrf exec CORE telnet -b 198.18.64.254 198.18.64.254 179 Trying 198.18.64.254... Connected to 198.18.64.254. Escape character is '^]'. Connection closed by foreign host. # The same command run from the other node (binding IP changed of course), no connection. Packet dump shows the TCP SYNs coming in, but no change. # tcpdump -enni bond0.64 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on bond0.64, link-type EN10MB (Ethernet), snapshot length 262144 bytes 12:41:46.465300 02:c0:7e:18:79:d3 > 02:c0:7e:4a:57:e6, ethertype IPv4 (0x0800), length 74: 198.18.64.253.34525 > 198.18.64.254.179: Flags [S], seq 2959174086, win 64240, options [mss 1460,sackOK,TS val 658554227 ecr 0,nop,wscale 7], length 0 12:41:47.495032 02:c0:7e:18:79:d3 > 02:c0:7e:4a:57:e6, ethertype IPv4 (0x0800), length 74: 198.18.64.253.34525 > 198.18.64.254.179: Flags [S], seq 2959174086, win 64240, options [mss 1460,sackOK,TS val 658555257 ecr 0,nop,wscale 7], length 0 12:41:49.511037 02:c0:7e:18:79:d3 > 02:c0:7e:4a:57:e6, ethertype IPv4 (0x0800), length 74: 198.18.64.253.34525 > 198.18.64.254.179: Flags [S], seq 2959174086, win 64240, options [mss 1460,sackOK,TS val 658557273 ecr 0,nop,wscale 7], length 0 12:41:53.639028 02:c0:7e:18:79:d3 > 02:c0:7e:4a:57:e6, ethertype IPv4 (0x0800), length 74: 198.18.64.253.34525 > 198.18.64.254.179: Flags [S], seq 2959174086, win 64240, options [mss 1460,sackOK,TS val 658561401 ecr 0,nop,wscale 7], length 0 ^C 4 packets captured 4 packets received by filter 0 packets dropped by kernel # I tried re-arranging the vrf multi-layer routing rules then adding more specific rules, no change: # ip rule 64: from all oif bond0.64 lookup CORE 64: from all iif bond0.64 lookup CORE 1000: from all lookup [l3mdev-table] 32765: from all lookup local 32766: from all lookup main 32767: from all lookup default VRF routing table: # ip r s t CORE broadcast 198.18.64.252 dev bond0.64 proto kernel scope link src 198.18.64.254 198.18.64.252/30 dev bond0.64 proto kernel scope link src 198.18.64.254 198.18.64.252/30 dev bond0.64 proto bird scope link metric 32 local 198.18.64.254 dev bond0.64 proto kernel scope host src 198.18.64.254 broadcast 198.18.64.255 dev bond0.64 proto kernel scope link src 198.18.64.254 broadcast 198.19.64.0 dev CORE_IP proto kernel scope link src 198.19.64.1 198.19.64.0/24 dev CORE_IP proto kernel scope link src 198.19.64.1 198.19.64.0/24 dev CORE_IP proto bird scope link metric 32 local 198.19.64.1 dev CORE_IP proto kernel scope host src 198.19.64.1 broadcast 198.19.64.255 dev CORE_IP proto kernel scope link src 198.19.64.1 # CORE_IP is a dummy interface in the VRF to hold an extra subnets to advertise to the other node. I've seriously run out of ideas. I started an instance of sshd in the VRF too and I'm getting the same thing, but can't figure out why, might be related, might not be. I don't think I've missed anything. As a last resort I even used strace and attached to the bird process. Nothing was showing as being received by the Bird process, but connecting locally did. I have also set rp_filter=0 on related interfaces. Anyone got any other thoughts/experiences/hacks? I am stumped why sshd in the MGMT vrf works, but not in the CORE VRF too, but that might be something else (or it might not be). Thanks. Regards, William

3 4

Troubleshooting BIRD as flowspec manager
by Noris Rogers 27 Aug '21

27 Aug '21

Hello, I am seeking to setup BIRD as a flowspec manager to send messages to FRR acting as a flowspec client. However, upon successful configuration of BGP relationships and advertising BGP routes, FRR is not able to see any flowspec rules. Is there a way to check to make sure BIRD is actually sending the flowspec rules with the BGP advertisements? Thanks! Noris

3 2

comparing open source BGP stacks performance
by Justin Pietsch 26 Aug '21

26 Aug '21

Hi all, because I couldn't find many results of performance tests of open source routing stacks, I did some tests and wrote up https://elegantnetwork.github.io/posts/comparing-open-source-bgp-stacks/. It compares BIRD, FRRouting and GoBGP. Justin

7 7

IPv6 BGP & kernel 4.19
by Robert Sander 25 Aug '21

25 Aug '21

Hi, our routers run on Debian stretch with bird 1.6.4 from bird.network.cz/debian. Yesterday I tried kernel 4.19 from backports.debian.org and ran into a weird issue with IPv6 BGP sessions: All Peerings reported "Error: Hold timer expired" ca. every 40 minutes. IPv6 forwarding was flapping all the time. After rebooting into kernel 4.9 everything worked again. IPv4 BGP was not affected and also OSPF (v4 and v6). I could disable all IPv6 BGP peerings on this router and then it forwarded to another router learned via OSPF for IPv6 without issues. Has anyone seen such a behaviour? Regards -- Robert Sander Heinlein Support GmbH Schwedter Str. 8/9b, 10119 Berlin https://www.heinlein-support.de Tel: 030 / 405051-43 Fax: 030 / 405051-19 Amtsgericht Berlin-Charlottenburg - HRB 93818 B Geschäftsführer: Peer Heinlein - Sitz: Berlin

13 39

Routes imported from BGP doesn't have proper gateways
by Ooth Gray 23 Aug '21

23 Aug '21

Hi I'm having troubles in BIRD configuration, and I'm pretty sure it's just a trivial wrong configure issue but I really tried my best >_< Let me give you some background. 1. There are 2 hosts connected by wire (so that they are L2 reachable), one with IPv4 10.22.12.88, and another is 10.22.12.44. Here's one the arp record from "ip neigh sh": > 10.22.12.88 dev bond0 lladdr f8:6e:ee:8b:cf:90 REACHABLE > 2. Both 2 hosts have some KVM virtual machines, with corresponding routes from host to vm, here's one of the routes from "ip r": > 10.233.25.178 dev yap35caa1e88854 scope link src 10.22.12.44 The 10.233.25.178 is the address of a VM, and the dev yap35caa1e88854 is a tap device connecting eth0 inside the VM. What I want to do is to build routes between these 2 hosts, in order to let VMs on host A be able to connect VMs on host B. Hope I make myself clear. So I'm using BIRD 2.0.3 on Ubuntu 16.04, with the config file as follows: log syslog all; > router id 10.22.12.44; > > protocol device { > debug { states }; > scan time 2;} > > protocol kernel { > learn; > persist; > scan time 10; > ipv4 { > import all; > export all; > };} > > protocol bgp { > debug { states }; > local as 65000; > neighbor 10.22.12.88 as 65000; > source address 10.22.12.44; > multihop; > ipv4 { > export filter { > if ( net ~ 10.233.0.0/16 ) then { > accept; > } > reject; > }; > import all; > next hop self on; > gateway recursive; > add paths on; > };} > > But this doesn't work well, the peer BIRD show the info as follows: bird> show route protocol bgp1 > Table master4:10.233.25.178/32 unicast [bgp1 18:47:32.910 from 10.22.12.44] * (100/?) [i] > via 10.22.12.1 on enp2s0f0 onlink > bird> show route export kernel1 > Table master4:10.233.25.178/32 unicast [bgp1 18:47:32.910 from 10.22.12.44] * (100/?) [i] > via 10.22.12.1 on enp2s0f0 onlink > > The problem happened on the gateway, I was hoping the routes should have "via 10.22.12.44" instead of "via 10.22.12.1"; 10.22.12.1 came from the host default gateway: > default via 10.22.12.1 dev bond0 onlink But I have no idea how to prevent BIRD from using it. The other information may be helpful is included below: bird> show protocols all bgp1 > Name Proto Table State Since Info > bgp1 BGP --- up 18:28:46.888 Established > BGP state: Established > Neighbor address: 10.22.12.88 > Neighbor AS: 65000 > Neighbor ID: 10.22.12.88 > Local capabilities > Multiprotocol > AF announced: ipv4 > Route refresh > Graceful restart > 4-octet AS numbers > ADD-PATH RX: ipv4 TX: ipv4 > Enhanced refresh > Long-lived graceful restart > Neighbor capabilities > Multiprotocol > AF announced: ipv4 > Route refresh > Graceful restart > 4-octet AS numbers > Enhanced refresh > Long-lived graceful restart Session: internal multihop AS4 > Source address: 10.22.12.44 > Hold timer: 117.086/240 > Keepalive timer: 52.520/80 > Channel ipv4 State: UP Table: master4 Preference: 100 > Input filter: ACCEPT > Output filter: (unnamed) Routes: 2 imported, 20 exported > Route change stats: received rejected filtered ignored accepted > Import updates: 2 0 0 0 2 > Import withdraws: 0 0 --- 0 0 > Export updates: 49 6 23 --- 20 > Export withdraws: 0 --- --- --- 4 > BGP Next hop: 10.22.12.44 > IGP IPv4 table: master4 > > bird> show route export bgp1 > Table master4:10.233.25.178/32 unicast [kernel1 18:04:09.483] (10) > dev yap35caa1e88854 > > Please enlighten me with some advice, and I'll appreciate that very much. Thank you!

2 2

bird-2.0.8 in Debian experimental
by Jakub Ružička 23 Aug '21

23 Aug '21

Hello Community, I've finally managed to upload bird2-2.0.8 into Debian experimental \o/ If you're waiting for official Debian BIRD packages, please consider testing the experimental version and letting me know whether it worked for you as expected. tl;dr HOWTO test on Debian unstable (sid): echo "deb http://deb.debian.org/debian experimental main" >> /etc/apt/sources.list apt update apt -t experimental install bird2 # TEST ALL THE THINGS As I'm new to BIRD Debian packaging, I've also CCd the friendly Debian Developer Marco who offered help - if he or anyone else with Debian knowledge could validate my BIRD package changes, that would be great: https://salsa.debian.org/debian/bird2/-/commits/experimental I've also enabled Salsa CI which is currently red only due to an unrelated lintian/debhelper issue #992469. If all is good, I'd like to submit 2.0.8 for unstable/testing and perhaps bullseye-backports eventually. Cheers, Jakub Ružička CZ.NIC packager 📦

1 0

prefix can't be export by BGP
by 智慧雨泽 17 Aug '21

17 Aug '21

Hi, bird user It seems that the image attachment cannot be seen by others, so I resend it ( I want to export 2602:feda:ab4::/48. I wrote 「if bgp_export() then accept」 in the BGP template, but it was not exported to BGP correctly. But bgp_export() outputs 2602:feda:ab4::/48. I can't find the BGP in the bird document under what circumstances will not export prefix, please tell me, thanks! bird> show route export Hurricane_Electric_LLC Table master6: 2a10:cc44:100::/44 unicast [UNM_Exch_RS2 2021-08-13 from 2602:ffb1:200:0:192:34:27:253] * (100) [AS38281i] via 2602:ffb1:200:0:192:34:27:6 on ens19 2a10:cc44:109::/48 unicast [LL_IX 15:22:24.526] * (100) [AS38281i] via 2602:feda:ab2:5247:5247:5247:5247:5247 on ll_ix 2001:df6:9f80::/48 unicast [EVIX_RS1 2021-08-13 from 2602:fed2:fff:ffff::1] * (100) [AS38281i] via 2602:fed2:fff:ffff::107 on ens20 2602:feda:ab2::/48 unicast [LL_IX 2021-08-15] * (100) [AS141011i] via 2602:feda:ab2:5247:5247:5247:5247:5247 on ll_ix bird> bird> show route where bgp_export() all Table master6: 2602:feda:ab2::/48 unicast [LL_IX 2021-08-15] * (100) [AS141011i] via 2602:feda:ab2:5247:5247:5247:5247:5247 on ll_ix Type: BGP univ BGP.origin: IGP BGP.as_path: 141011 BGP.next_hop: 2602:feda:ab2:5247:5247:5247:5247:5247 fe80::200:5efe:5bd:ff6b BGP.local_pref: 100 2602:feda:ab4::/48 unreachable [BGP_Prefix 2021-08-13] (200) Type: static univ bird> template bgp tpl_bgp { graceful restart on; local as LOCAL_ASN; ipv6 { next hop self; import filter peer_in_v6; #export where bgp_export(); export filter{ #if my_opt_prefix() then bgp_path.prepend(LOCAL_ASN); if bgp_export() then accept; if bgp_export_downstream() then accept; else reject; }; }; }

2 2

Couldn't announce the prefix
by 智慧雨泽 16 Aug '21

16 Aug '21

Hi, bird user I want to export 2602:feda:ab4::/48. I wrote 「if bgp_export() then accept」 in the BGP template, but it was not exported to BGP correctly. But bgp_export() outputs 2602:feda:ab4::/48, Please see the picture below. [image: image.png] [image: image.png] [image: image.png] Also what kind of case BGP will not export the prefix? I couldn't find it in the documentation.

1 0

Debian 11 (Bullseye) Repository
by Peter Potvin 16 Aug '21

16 Aug '21

Good evening, With the official release of Debian 11 (Bullseye) Stable occurring less than 48 hours ago, it would be nice to know of the timeline for which BIRD 2.0.8 will be added to the official Debian repository or a reputable third-party repository. Regards, Peter

5 5