- Bird-users - Mailing Lists

New RIP MD5 interface option to avoid sequence check
by Olivier Benghozi 14 Oct '22

14 Oct '22

Hello, I'm currently using RIP/Ripng with md5 auth with some Cisco/Juniper and Quagga gears. I'm looking to switch from quagga to Bird(2). I would have a feature request about the RIP MD5 sequence number check (RFC rule, implemented by BIRD, is: accept only increasing sequence numbers, or accept lower only if restarting at 0). In our current usecase, end-to-end interfaces are not contiguous, and it happens that some various cases (like powercuts at one end) can lead to a situation when one dead RIP speaker comes back to life before full end to end connectivity is restored BUT before route expiration at the other side: therefore the received seqnumber starts at something higher than 0 but lower than the previous known one, so the routing will just fail. Quagga doesn't check seqnumbers at all, Cisco gears don't seem to, and Juniper gears have a hidden option to disable this check (no-check-sequence). So we would have use/need for a config option (probably at the interface level), to avoid the received crypto sequence number check (therefore md5 is just a way to avoid transmitting the clear password on the wire). Apart for the new option definition, the actual check is in master/proto/rip/packets.c, I guess that the check in current line 391 would have to include an additional «&& new_option_isnt_defined» to avoid yelling about a sequence number too low... line 391: if ((rcv_csn < n->csn) && (rcv_csn || n->uc)) What about such an additional feature ? Thank you, Olivier -- *Ce message et toutes les pièces jointes (ci-après le "message") sont établis à l’intention exclusive des destinataires désignés. Il contient des informations confidentielles et pouvant être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de détruire le message. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse de l'émetteur*

2 2

Notification on network update (BABEL)
by Martin Vystrčil 14 Oct '22

14 Oct '22

Good morning, is there any possibility to be notified on network update. We are using bird to manage BABEL in our product (embedded system). Main usage would be to send SNMP notification on BABEL network update. Prefered would be to execute any shell script, but any other method would be appreciated. Best Regards, Martin

4 3

Bird 2.07: BFD with multiple BIRD processes
by Mihai 13 Oct '22

13 Oct '22

Hi, On the same server I am running two BIRD processes each configured with OSPF and iBGP (toward the same neighbors, using different local addresses). Should BFD for iBGP work on both processes? In my case all BFD sessions on the first processes are dropped when the second BIRD processes starts. In the documentation there is the "strict bind" option for BFD but I am not really sure how/where it should be configured as the configuration check fails when added under protocol bfd. Thanks!

2 2

Bird 2.0.10: ipv6 static onlink route updates after each scan time
by Saklak, Marcin 12 Oct '22

12 Oct '22

Hi, I have an issue with onlink static routes bird constantly remove and add them to kernel. Is this expected behavior that for ipv6 onlink route bird after each scan time remove and add route? for other static routes bird update kernel once My setup: protocol kernel { scan time 2; ipv4 { export all; }; merge paths on; } protocol kernel { scan time 2; ipv6 { export all; }; merge paths on; } protocol device { scan time 2; } protocol static { ipv4 { preference 50; }; } protocol static { ipv6 { preference 50; }; route 2600:1408:c400::1234/128 via "eth-1_1_39_1" onlink; #update after each scan time by remove and add route 2600:1408:c400::4444/128 via "eth-1_1_39_1"; #update once } protocol direct { ipv4; ipv6; interface "eth*"; } I would expect single update similar to other static routes this cause changes in kernel in each kernel scan time. Best regards, Marcin

2 2

Link local vs global v6 next hop for BGP rotuer
by Mazur, Dariusz 10 Oct '22

10 Oct '22

Hello, In my setup I have iBGP session with peer , and I learn v6 route. It is iBGP so we have 2 next hops global and link-local. By default bird uses link-local when route is exported to kernel. Is there any command to change this behavior and use global v6 address as BGP next hop when we export routes to kernel ? Table master6: fc00:2001:100:12::/64 unicast [2001:4878:c225::1:3:2__r02.ien.labkrk01.sdn 12:57:29.076] * (100) [i] via 2001:4878:c225::1:3:2 on eth-1\1\4 Type: BGP univ BGP.origin: IGP BGP.as_path: BGP.next_hop: 2001:4878:c225::1:3:2 fe80::1:3:2 BGP.local_pref: 400 BGP.community: (20940,550) Thanks, Dariusz

4 6

Missing IPv6 default route on protocol kernel and table master6
by Bernd Naumann 10 Oct '22

10 Oct '22

Hey *, I do not see a default route for IPv6 on the `kernel` protocol (or `table master6`), like with IPv4, therefor I'm unable to export it via `ospf`. I'm running bird 2.0.8 on OpenWRT 21.02, Kernel 5.4.154. At first I thought it's because I had `pppoe-wan` not covered in `proto device` and `direct`, but `proto kernel` uses `learn yes` and with IPv4 it makes `bird` aware of the default route, but not so with IPv6. (At least I assume so. Please correct me on possible misconceptions.) ``` root@cpe:~# birdc show route for 0.0.0.0 BIRD 2.0.8 ready. Table master4: 0.0.0.0/0 unicast [kernel_ipv4 08:16:19.473] * (10) via 62.155.247.X on pppoe-wan root@cpe:~# birdc show route for ::/0 BIRD 2.0.8 ready. Network not found root@cpe:~# ip -6 route show default default from 2003:e4:bf24:XX00::/56 via fe80::f6cc:55ff:fe42:1a94 dev pppoe-wan proto static metric 512 pref medium default from 2003:e4:bfff:XXXX::/64 via fe80::f6cc:55ff:fe42:1a94 dev pppoe-wan proto static metric 512 pref medium default from fde6:a09a:b373:f0::/64 dev pppoe-wan metric 1024 pref medium default from fde6:a09a:b373:ff::/64 dev pppoe-wan metric 1024 pref medium ``` I have now: * `pppoe-wan` covered in `device` and `direct` * `kernel` with - `learn yes`, and - `import all`, and - `export filter { accept; };` * `ospf` even has `interface "pppoe-wan" { stub yes; };` and `export all`. But still ::/0 is not present in `bird`. Am I missing something (obvious) here? Thanks for advice and help. Bernd PS: Can I show/filter routes on `protocol kernel` which are "learned" and not "imported"?

2 8

Wrong BGP NH metric
by Mihai 07 Oct '22

07 Oct '22

Hello, First I would like to thank you for this amazing software! I am running Bird 2.0.7 as RR for L3VPNs and on one RR the OSPF metric for the BGP NH is different than what's seen in BGP as shown below. BGP PREF/METRIC = (100/61580) , OSPF_METRIC = 61480. bird> sh route 10:10 94.207.96.0/19 all primary Table vpntab4: 10:10 94.207.96.0/19 unicast [ROUTER1 2022-09-28 00:10:09 from 10.100.186.1] * (100/61580) [AS15802i] Type: BGP univ BGP.origin: IGP BGP.as_path: 15802 BGP.next_hop: 10.100.184.8 bird> sh route 10.100.184.8/32 Table master4: 10.100.184.8/32 unicast [OSPF 2022-09-29 12:33:35] IA (150/61480) [10.100.186.5] After restarting the BIRD OSPF adjancency the BGP metric changed to 61480. Any help in understanding the issue would be much appreciated. Thank you!

3 4

bgp keepalive and expired issues on bird 1.6.8
by 안상혁 04 Oct '22

04 Oct '22

Hello, we have encountered some issues using bird 1.6.8 there are two issues : 1) sometimes bird looks like doesn't handle neighbor's bgp keepalive messages. when we get bgp hold timer exprired issue, on tcpdump there are keepalive packets that neighbor physical router sent and the server replied. but there is no "Got KEEPALIVE" messages on bird.log and bgp session closed after "Error: Hold timer expired" message. 2) bgp session exprired less than bgp hold timer value. we set BGP hold timer to 9 seconds, but bgp expired in 7 seconds In logs got it: 2022-08-28 10:25:55 <TRACE> as1: Got KEEPALIVE <- 10:25:56 ( got keepalived from as1 neighbor on tcpdump but not on bird.log ) <- 10:25:59 ( got keepalived from as1 neighbor on tcpdump but not on bird.log ) 2022-08-28 10:26:02 <RMT> as1: Error: Hold timer expired 2022-08-28 10:26:02 <TRACE> as1: BGP session closed bgp neighbor is physical router. have you got reported this cases? or we should upgrade to bird 2? Thank you and best regards, ted

4 4

EBGP ECMP w/o add paths capability
by Milovancevic, Nemanja 04 Oct '22

04 Oct '22

Dear all, Since some of our customers have devices which are not supporting EBGP add-path capability, I was wondering would there be an option that BIRD announces also other “not only best” paths, since it looks like that now only the best one elected, based on (router-id) RID is announced to the other customers (customers have normally 2 devices connected and announce the same prefixes) RID would be tie breaker as all the other attributes are the same. BGP RS Best Path Selection: * Prefer route with the highest Local Preference attribute. * Prefer route with the shortest AS path. * Prefer IGP origin over EGP and EGP origin over incomplete. * Prefer the lowest value of the Multiple Exit Discriminator. * Prefer routes received via eBGP over ones received via iBGP. * Prefer routes with lower internal distance to a boundary router. * Prefer the route with the lowest value of router ID of the advertising router. I don’t know if there would be something like Cisco based command: bgp bestpath as-path multipath-relax Thanks. Best regards, Nemanja Milovancevic

2 1

BIRD Crashes
by Ian Chilton 04 Oct '22

04 Oct '22

Hi, We are an IXP running 2x route servers with BIRD, each running separate daemons for IPv4 and IPv6. We are running BIRD 2.0.8-1 on Debian 10 and have around 250 peers, ~150k routes on v4 and ~50k routes on v6. Since upgrading to BIRD 2 nearly 3 years ago, it was really stable until May this year. Since then we've had 3 crashes of the daemon for v4 on one of the servers. The v6 daemon on that server has been fine, as has the second route server, running the same, with the same peers and therefore in theory, the same routes. The first two of these crashes happened a week apart, after which I rebooted the VM to ensure everything was clean and it was fine for 90 days, but then did the same yesterday. Our BIRD configuration is generated by IXP Manager and updated hourly. We then run a "bird re-validate" cron job every hour (at twenty past the hour): /usr/sbin/birdc -s /run/bird-ipv6.ctl reload in all > /dev/null ; /usr/sbin/birdc -s /run/bird-ipv4.ctl reload in all Interestingly all 3 crashes have happened at just after twenty past the hour, i.e soon after this cron job has run. It looks like the following in the logs: Aug 17 17:20:01 rs1 CRON[29229]: (root) CMD (/usr/sbin/birdc -s /run/bird-ipv6.ctl reload in all > /dev/null ; /usr/sbin/birdc -s /run/bird-ipv4.ctl reload in all > /dev/null) Aug 17 17:20:01 rs1 bird: Reloading protocol device1 Aug 17 17:20:01 rs1 bird: Reloading protocol pp_0121_asxx ..etc.. Aug 17 17:20:01 rs1 bird: Reloading protocol pp_1082_asxxxxxx Aug 17 17:20:01 rs1 bird: Reloading protocol pb_1082_asxxxxxx Aug 17 17:20:01 rs1 bird: Tagging invalid ROA 2001:xxxx:xxxx::/48 for ASN xxxxx ..etc.. Aug 17 17:21:17 rs1 bird: Tagging invalid ROA x.x.x.x/23 for ASN xxxx Aug 17 17:21:19 rs1 kernel: [7811815.959943] bird[586]: segfault at f30021 ip 000055a1bf450fc3 sp 00007ffe64f3da98 error 4 in bird[55a1bf42a000+d8000] Aug 17 17:21:19 rs1 kernel: [7811815.966760] Code: 95 78 01 00 00 5b 5d 41 5c c3 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 48 85 ff b8 01 00 00 00 74 15 48 85 f6 0f 84 a6 00 00 00 <0f> b6 46 21 0f b6 57 21 29 d0 74 11 f3 c3 0f 1f 44 00 00 66 2e 0f Aug 17 17:21:19 rs1 systemd[1]: bird-ipv4.service: Main process exited, code=killed, status=11/SEGV Aug 17 17:21:19 rs1 systemd[1]: bird-ipv4.service: Failed with result 'signal'. Aug 17 17:21:19 rs1 systemd[1]: bird-ipv4.service: Service RestartSec=100ms expired, scheduling restart. Aug 17 17:21:19 rs1 systemd[1]: bird-ipv4.service: Scheduled restart job, restart counter is at 1. Aug 17 17:21:19 rs1 systemd[1]: Stopped BIRD - ipv4. Aug 17 17:21:19 rs1 systemd[1]: Starting BIRD - ipv4... Aug 17 17:21:22 rs1 systemd[1]: Started BIRD - ipv4. Aug 17 17:21:22 rs1 bird: Started When the second crash happened, we happened to be at RIPE84 so we chatted to Maria in person. She said that it was possible to debug it, but would need a core dump. After looking in to this, I did: ulimit -S -c unlimited and installed the systemd-coredump package. ...which was supposed to dump a core file if a process crashed. I tested this by killing a sleep command from the shell with kill -s 6 and it worked. When the crash happened again yesterday, I hoped to have a core file to send, but there is no sign of it having generated one :( Testing on a test server, killing sleep generates a core file, but not killing bird. So two things - has anyone experienced similar crashes or have any ideas why we might be seeing this? Can anyone advise how to reliably get a core dump if bird crashes? Thanks! Ian

5 9