- Bird-users - Mailing Lists

When router becomes ABR, ospf is restarted
by Senthil Kumar Nagappan 06 Sep '21

06 Sep '21

Hi, While adding an area and if the router becomesABR, entire ospf protocol is restarted which deletes all the neighbors and adjacencies. can we not do this gracefully with the minimum disturbance toprotocol, like resending the router lsa with B bit enabled, redoing summary-lsasand route calculation? Thanks and Regards,Senthil

5 8

BFD and Juniper SRX inter-op issue
by Justin Cattle 02 Sep '21

02 Sep '21

Hi, I have encountered what seems to be a bug of sorts in the Juniper implementation of BFD in at least their SRX340. We have no issues with the QFX series, where BFD seems to work as expected with bird. I'm wondering if there is anything we can do to handle this issue on the bird side, or if anyone has any insight that may shed some light on the behaviour we are seeing. Here is the issue summary: - BFD timers are set quite conservatively - interval 4000 ms - multiplier 6 - A BFD session between a bird endpoint and a juniper endpoint is up and running at the start - all fine - If the you stop bird on the server, after the Detection time [ currently 24 secs ], the BFD messages from the Juniper show status as Down with the Diagnostic message Control Detection Time Expired. You can then start bird on the server again, and the two sides will agree session info and BFD status goes Up. - This is expected. - However, if you stop bird, but start it again before the Detection time [ currently 24 secs ], like for a service restart, the BFD messages from the Juniper never show as Down, and the two sides never agree on a BFD session and BFD remains Down on the server but Up on the Juniper. - Should a new session be established at this point ? - Once the Juniper gets stuck in the BFD status Up state, then you can stop the bird for a long time [ over an hour at least ] , and the Juniper never seems to notice [ the BFD packets still show state Up ]. - This seems to be a bug n the juniper end - why should it never go Down in this state ? - If the BFD session info is reset on the Juniper side, then the two sides will agree session info and BFD status goes Up. Does anyone have any thoughts ? Is there a packet bird can send, gratuitous or not, that can make the juniper end realise it MUST reinitialize ? Any config that can be tweaked to help ? Cheers, Just -- Notice: This email is confidential and may contain copyright material of members of the Ocado Group. Opinions and views expressed in this message may not necessarily reflect the opinions and views of the members of the Ocado Group. If you are not the intended recipient, please notify us immediately and delete all copies of this message. Please note that it is your responsibility to scan this message for viruses. References to the "Ocado Group" are to Ocado Group plc (registered in England and Wales with number 7098618) and its subsidiary undertakings (as that expression is defined in the Companies Act 2006) from time to time. The registered office of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.

3 4

Weird behavior on Bird 2.0.8 with Wireguard PtP links and OSPFv3
by Skyler Mäntysaari 31 Aug '21

31 Aug '21

Hi there, I'm not sure if anyone else has seen this issue but I have been getting this issue repeatably today, where OSPFv3 just stops working due to "bad DBDES packet from nbr", I haven't changed anything and it has been working fine for months. What's the best way to troubleshoot this? The neighbor starting with 193. is a Debian 10 machine, 185 and 192.168.2.1 are EdgeOS running Bird 2.0.8. 2021-08-31 17:23:53 <RMT> ospfv3_v4: Bad DBDES packet from nbr 192.168.2.1 on wg0 - I-bit mismatch (7) 2021-08-31 17:23:53 <RMT> ospfv3_v6: Bad DBDES packet from nbr 193.xxx.xxx.223 on wg1 - I-bit mismatch (7) 2021-08-31 20:38:41 <RMT> ospfv3_v6: Bad DBDES packet from nbr 185.xxx.xxx.130 on wg0 - too late for DD exchange (7) OSPF3 configuration: ------------------------------------------------------------------------------------------------- protocol ospf v3 ospfv3_v4 { ipv4 { import filter internel_prefixes; export filter internel_prefixes; #export where (source = RTS_STATIC) || (source = RTS_DEVICE); }; area 0.0.0.0 { interface "lo*" { stub; }; interface "tun0" { type ptp; cost 10; stub no; }; interface "wg0" { type ptp; cost 20; stub no; }; interface "wg1" { type ptp; cost 30; stub no; }; }; } protocol ospf v3 ospfv3_v6 { ipv6 { import filter internel_prefixes; export filter internel_prefixes; #export where (source = RTS_STATIC) || (source = RTS_DEVICE); }; area 0.0.0.0 { interface "lo*" { stub; }; interface "tun0" { type ptp; cost 10; stub no; }; interface "wg0" { type ptp; cost 20; stub no; }; interface "wg1" { type ptp; cost 30; stub no; }; }; } --------------------------------------------------------------------------------------------------------

1 0

latest blog post on bgp stack performance this time with Internet!
by Justin Pietsch 30 Aug '21

30 Aug '21

my latest blog post, this time playing back MRT data with full internet tables. https://elegantnetwork.github.io/posts/comparing-open-source-bgp-internet-r… . If anybody has suggestions on other bgp performance test tools or test results, I'd love to know about those. thanks, JUstin

1 0

RE: [EXT] Re: Troubleshooting BIRD as flowspec manager
by Noris Rogers 29 Aug '21

29 Aug '21

Sure! r1, r2, and r3 are FRR clients. BGP relationships are successfully formed and BGP routes are exchanged, but no flowspec is seen on the clients. I am currently analyzing packet captures, but still haven’t completely understood where in the packet header the flowspec is/should be. log syslog all; router id 4.4.4.4; protocol device { scan time 10; } flow4 table flowtab4; protocol static flowspec4{ flow4 { import all; export all; }; route flow4 { dst 172.16.0.1/32; }{ bgp_ext_community.add((generic, 0x80060000, 0x0)); }; } template bgp bgp_fs_temp { local as 4; ipv4 { import all; export all; }; flow4 { table flowtab4; import none; export all; }; } protocol bgp r1 from bgp_fs_temp { neighbor 172.16.4.2 as 1; } protocol bgp r2 from bgp_fs_temp { neighbor 172.16.4.6 as 2; } protocol bgp r3 from bgp_fs_temp { neighbor 172.16.4.10 as 3; Thank you! Noris From: 彭勇 <ppyy(a)pubyun.com> Sent: Thursday, August 26, 2021 11:17 PM To: Noris Rogers <nrogers(a)mitre.org> Cc: bird-users(a)network.cz Subject: [EXT] Re: Troubleshooting BIRD as flowspec manager can you share your config file to let us check? On Wed, Aug 25, 2021 at 4:23 AM Noris Rogers <nrogers(a)mitre.org<mailto:nrogers@mitre.org>> wrote: 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 -- 彭勇 (Peng Yong) 江苏网擎信息技术有限公司地址：常州市关河西路119号银苑大厦1406室电话：+86.519.68887168 传真：+86.519.68887169 手机：+86.18915883399 邮箱：ppyy@pubyun.com<mailto:ppyy@pubyun.com>

1 0

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