October 2022 - Bird-users

refresh bgp routes with import table enabled
by Alexander Zubkov 18 Oct '22

18 Oct '22

Hi, When import table is enabled for bgp, "reload in" uses the table and one cannot force refresh from the peer. I suggest to add refresh functions to reload routes on a protocol level, and "reload receive" command to call them. I used "reload receive" not to add additional keywords and it seems descriptive too. Pathches are attached.

2 1

add documentation for show route (import|export) table
by Alexander Zubkov 18 Oct '22

18 Oct '22

Hi, I found out that one can "show route" for import and export tables. But that syntax is not documented. Patch is attached.

2 1

how can i dynamically change the gateway?
by Michele Salerno 16 Oct '22

16 Oct '22

Hi, I have this script that configures routes for me between different routers and servers. I have a few routers that have down in the wan and connect with the mesh network. How can I dynamically change the gateway? Example: if the wan drops, use the mesh as the gateway. # Configure logging log syslog all; log "/var/log/bird.log" all; log stderr all; router id from "br-lan"; # Sync bird routing table with kernel protocol kernel kernel4 { description "Kernel protocol for IPv4"; metric 50; ipv4 { table master4; export filter { if proto = "lan" then reject; accept; }; import all; }; }; protocol kernel kernel6 { description "Kernel protocol for IPv6"; metric 300; ipv6 { table master6; export filter { if proto = "lan" then reject; accept; }; import all; }; }; protocol device { description "Device protocol"; }; protocol direct lan { description "LAN protocol"; ipv4; ipv6; interface "br-lan"; check link; } protocol babel ninux { description "Babel protocol for NINUX network"; ipv4 { export where (source = RTS_DEVICE) || (source = RTS_BABEL); }; ipv6 { export where (source = RTS_DEVICE) || (source = RTS_BABEL); }; interface "vpnbas" { check link; }; ## Used to connect with other neighbours on the same layer 2 network. ## Decomment the config to use it, not this comments of course! ## Use the correct name interface, not the logical openwrt/(l)uci one. ## You can define more interfaces maches using * in regex (like "ifnet*") ## or "ifnet1", "ifnet2", "ifnetN", "otherifnetnames" form. ## You can also define more interfaces with other parameters, please refer to: ##https://bird.network.cz/?get_doc&v=20&f=bird-6.html#ss6.1 ## After, reload the bird daemon with: /etc/init.d/bird reload ## or if you perefer, reastart with: /etc/init.d/bird restart interface "mesh" { type wireless; # or wired check link; }; }

2 2

bird-1.6.8: Withdrawals during an enhanced route-refresh process
by Garri Djavadyan 15 Oct '22

15 Oct '22

Hello everyone, I noticed that the legacy Bird version behaves strangely while it is in an enhanced route-refreshing process, but I am not sure whether it is a known/expected behaviour for version 1.6.8. Namely, right after a 1.6.8 peers sends a BoRR message, it also sends withdrawals for the prefixes it received from that same peer. For example, below is the output from two Bird peers (1.6.8 and 2.0.10): # birdc show route BIRD 1.6.8 ready. 10.2.0.0/24 dev lo [direct1 21:09:14] * (240) 10.3.0.0/24 via 172.17.0.3 on eth0 [bird2 21:09:14] * (100) [AS65003i] # birdc reload out bird2 BIRD 1.6.8 ready. bird2: reloading Below is the debug output from the bird-2.0.10 peer: 2022-10-13 21:10:17.561 <TRACE> bird1: Got KEEPALIVE 2022-10-13 21:10:17.602 <TRACE> bird1: Got BEGIN-OF-RR 2022-10-13 21:10:17.602 <TRACE> bird1: Got UPDATE <=== this is a WD 2022-10-13 21:10:17.602 <TRACE> bird1: Got UPDATE 2022-10-13 21:10:17.602 <TRACE> bird1.ipv4 > ignored 10.2.0.0/24 unicast 2022-10-13 21:10:17.602 <TRACE> bird1: Got END-OF-RR Below is the packets content for that RR process: Frame 1: 89 bytes on wire (712 bits), 89 bytes captured (712 bits) Internet Protocol Version 4, Src: 172.17.0.2, Dst: 172.17.0.3 Border Gateway Protocol - ROUTE-REFRESH Message Marker: ffffffffffffffffffffffffffffffff Length: 23 Type: ROUTE-REFRESH Message (5) Address family identifier (AFI): IPv4 (1) Subtype: Demarcation of the beginning of a route refresh (1) Subsequent address family identifier (SAFI): Unicast (1) Frame 3: 93 bytes on wire (744 bits), 93 bytes captured (744 bits) Internet Protocol Version 4, Src: 172.17.0.2, Dst: 172.17.0.3 Border Gateway Protocol - UPDATE Message Marker: ffffffffffffffffffffffffffffffff Length: 27 Type: UPDATE Message (2) Withdrawn Routes Length: 4 Withdrawn Routes 10.3.0.0/24 Total Path Attribute Length: 0 Frame 5: 113 bytes on wire (904 bits), 113 bytes captured (904 bits) Internet Protocol Version 4, Src: 172.17.0.2, Dst: 172.17.0.3 Border Gateway Protocol - UPDATE Message Marker: ffffffffffffffffffffffffffffffff Length: 47 Type: UPDATE Message (2) Withdrawn Routes Length: 0 Total Path Attribute Length: 20 Path attributes Network Layer Reachability Information (NLRI) 10.2.0.0/24 Frame 7: 89 bytes on wire (712 bits), 89 bytes captured (712 bits) Internet Protocol Version 4, Src: 172.17.0.2, Dst: 172.17.0.3 Border Gateway Protocol - ROUTE-REFRESH Message Marker: ffffffffffffffffffffffffffffffff Length: 23 Type: ROUTE-REFRESH Message (5) Address family identifier (AFI): IPv4 (1) Subtype: Demarcation of the ending of a route refresh (2) Subsequent address family identifier (SAFI): Unicast (1) Interestingly, bird-2.0.10 does not do that. For example: # birdc show route BIRD 2.0.10 ready. Table master4: 10.3.0.0/24 unicast [direct1 21:05:38.768] * (240) dev lo 10.2.0.0/24 unicast [bird1 21:09:15.455] * (100) [AS65002i] via 172.17.0.2 on eth0 # birdc reload out bird1 BIRD 2.0.10 ready. bird1: reloading There is only one BGP update in the debug output of bird-1.6.8: 2022-10-13 22:05:30 <TRACE> bird2: Got BEGIN-OF-RR 2022-10-13 22:05:30 <TRACE> bird2: Got UPDATE 2022-10-13 22:05:30 <TRACE> bird2 > ignored 10.3.0.0/24 via 172.17.0.3 on eth0 2022-10-13 22:05:30 <TRACE> bird2: Got END-OF-RR No withdrawals in the packet capture: Frame 1: 89 bytes on wire (712 bits), 89 bytes captured (712 bits) Internet Protocol Version 4, Src: 172.17.0.3, Dst: 172.17.0.2 Border Gateway Protocol - ROUTE-REFRESH Message Marker: ffffffffffffffffffffffffffffffff Length: 23 Type: ROUTE-REFRESH Message (5) Address family identifier (AFI): IPv4 (1) Subtype: Demarcation of the beginning of a route refresh (1) Subsequent address family identifier (SAFI): Unicast (1) Frame 3: 113 bytes on wire (904 bits), 113 bytes captured (904 bits) Internet Protocol Version 4, Src: 172.17.0.3, Dst: 172.17.0.2 Border Gateway Protocol - UPDATE Message Marker: ffffffffffffffffffffffffffffffff Length: 47 Type: UPDATE Message (2) Withdrawn Routes Length: 0 Total Path Attribute Length: 20 Path attributes Network Layer Reachability Information (NLRI) 10.3.0.0/24 Frame 5: 89 bytes on wire (712 bits), 89 bytes captured (712 bits) Internet Protocol Version 4, Src: 172.17.0.3, Dst: 172.17.0.2 Border Gateway Protocol - ROUTE-REFRESH Message Marker: ffffffffffffffffffffffffffffffff Length: 23 Type: ROUTE-REFRESH Message (5) Address family identifier (AFI): IPv4 (1) Subtype: Demarcation of the ending of a route refresh (2) Subsequent address family identifier (SAFI): Unicast (1) Below is the Bird configuration for both daemons: bird-1.6.8: # grep '^[^#]' /etc/bird/bird.conf log "/var/log/bird.log" all; debug protocols all; router id 172.17.0.2; protocol kernel { scan time 60; import none; export all; # Actually insert routes into the kernel routing table } protocol device { scan time 60; } protocol direct { interface "lo"; } protocol bgp bird2 { local as 65002; neighbor 172.17.0.3 as 65003; import all; export all; } bird-2.0.10: # grep '^[^#]' /etc/bird/bird.conf log "/var/log/bird.log" all; router id 172.17.0.3; debug protocols all; protocol device { } protocol direct { ipv4; # Connect to default IPv4 table interface "lo"; } protocol kernel { ipv4 { # Connect protocol to IPv4 table by channel export all; # Export to protocol. default is export none }; } protocol bgp bird1 { local as 65003; neighbor 172.17.0.2 as 65002; ipv4 { import all; export all; }; } So, I am just curious if it is a bug or some architectural limitation of Bird-1.6. If I understand correctly, there are two problems here: - bird-1.6 sends a withdrawal for a prefix it never advertised before - there is no need to explicitly send withdrawals during an enhanced RR process as RR receivers must implicitly remove stale prefixes associated with the RR sender right after EoRR message per RFC 7313. Thank you. Garri Djavadyan

2 2

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