June 2023 - Bird-users - Mailing Lists

Bird does not prefer older eBGP route - RFC5004 and "older prefer on"
by Mazur, Dariusz 03 Jul '23

03 Jul '23

Hello Bird users, Have you ever use RFC 5004 and “older prefer” knob. I am trying to use it but it seems not to work: 1.Router learns the same route from different ebgp peers, it prefers route from r01a and this route is exported to BGP peers 172.232.160.0/19 unicast [192.168.196.129__r01a.tor106 2023-06-14] * (100) [AS4250627481?] via 192.168.196.129 on vlan.201 unicast [192.168.196.131__r01b.tor106 2023-06-14] (100) [AS4250627481?] via 192.168.196.131 on vlan.202 unicast [192.168.196.133__r02a.tor106 2023-06-14] (100) [AS4250627482?] via 192.168.196.133 on vlan.203 2.Once we lose links to r01a and r01b route from r02a is preferred and exported to BGP peers. It is expected 172.232.160.0/19 unicast [192.168.196.133__r02a.tor106 2023-06-14] * (100) [AS4250627482?] via 192.168.196.133 on vlan.203 3.When links to r01a and r01b. are again online route, route from r01a is pricked as primary and exported to BGP. It causes route oscillation 172.232.160.0/19 unicast [192.168.196.129__r01a.tor106 09:14:19.982] * (100) [AS4250627481?] via 192.168.196.129 on vlan.201 unicast [192.168.196.131__r01b.tor106 09:14:19.896] (100) [AS4250627481?] via 192.168.196.131 on vlan.202 unicast [192.168.196.133__r02a.tor106 2023-06-14] (100) [AS4250627482?] via 192.168.196.133 on vlan.203 4.I believe it is default behavior not to prefer older path. According to documentation RFC 5004 and "prefer older on" should fix my problem, but it does not work. Bird doc says: prefer older switch Standard route selection algorithm breaks ties by comparing router IDs. This changes the behavior to prefer older routes (when both are external and from different peer). For details, see RFC 5004. Default: off. 5. According to documentation RFC 5004 and "prefer older on" should fix my problem, but it does not work. a) added "prefer older on", bgp flapped and routes were re-learnt 172.232.160.0/19 unicast [192.168.196.129__r01a.tor106 09:22:12.949] * (100) [AS4250627481?] via 192.168.196.129 on vlan.201 unicast [192.168.196.131__r01b.tor106 09:22:13.527] (100) [AS4250627481?] via 192.168.196.131 on vlan.202 unicast [192.168.196.133__r02a.tor106 09:22:12.683] (100) [AS4250627482?] via 192.168.196.133 on vlan.203 b) shut links to r01a and r01b 172.232.160.0/19 unicast [192.168.196.133__r02a.tor106 09:22:12.683] * (100) [AS4250627482?] via 192.168.196.133 on vlan.203 c) unshut links to r01a and r01b, route from r01a is again preferred, so looks like "older" knob does not work 172.232.160.0/19 unicast [192.168.196.129__r01a.tor106 09:27:55.841] * (100) [AS4250627481?] via 192.168.196.129 on vlan.201 unicast [192.168.196.131__r01b.tor106 09:27:54.448] (100) [AS4250627481?] via 192.168.196.131 on vlan.202 unicast [192.168.196.133__r02a.tor106 09:22:12.683] (100) [AS4250627482?]. ---> this route is older via 192.168.196.133 on vlan.203 Thanks, Dariusz

2 3

typo in the documentation
by Alexander Zubkov 30 Jun '23

30 Jun '23

Hello, I've found a typo in the documenation. The problem is the "/" symbol in the prefix mask that finishes the formatting definition. The patch is attached. Best regards, Alexander Zubkov

2 1

RE: [PATCH] IPv4 over IPv6 nexthop support on FreeBSD
by Alexander Chernikov 24 Jun '23

24 Jun '23

Hi Ondrej, Could you please consider merging IPv4 over IPv6 support for FreeBSD Netlink as well? It seems like the patch slipped through the cracks :-( Sorry for not replying to the thread, it got purged by my email client. The original message: https://bird.network.cz/pipermail/bird-users/2023-April/016857.html /Alexander

3 6

BFD Intermittent Issues
by Richard Laager 23 Jun '23

23 Jun '23

MICE (IXP in Minneapolis, MN, USA) has had a couple reports of participants seeing BFD issues. For the most recent example, the participant's router is sending BFD to the route server (confirmed via a packet capture on the route server), but BIRD simply did not respond. Both their IPv4 and IPv6 sessions to rs1 (the first route server) were acting this way, while both of their sessions to rs2 were fine. I compared the route servers and found two other inconsistencies: one network with IPv4 and one network with IPv6. Here's what the packet capture shows: BFD Control message 001. .... = Protocol Version: 1 ...0 0011 = Diagnostic Code: Neighbor Signaled Session Down (0x03) 01.. .... = Session State: Down (0x1) Message Flags: 0x48, Control Plane Independent: Set 0... .. = Poll: Not set .0.. .. = Final: Not set ..1. .. = Control Plane Independent: Set ...0 .. = Authentication Present: Not set .... 0. = Demand: Not set .... .0 = Multipoint: Not set Detect Time Multiplier: 3 (= 6000 ms Detection time) Message Length: 24 bytes My Discriminator: 0x0000024d Your Discriminator: 0x0c764401 Desired Min TX Interval: 2000 ms (2000000 us) Required Min RX Interval: 2000 ms (2000000 us) Required Min Echo Interval: 0 ms (0 us) This may have started when rs1 was rebooted for patching, or it might have been due to a fiber cut that disconnected this participant from the fabric. We are not sure exactly on the timing. The participant reset their BGP sessions. This caused the BFD session to come up. We are running BIRD 2.0.8 from Ubuntu's repository on Ubuntu 22.04. Note that this BIRD setup is using the IXP Manager templates to generate the config, so there are separate BIRD processes for IPv4 vs IPv6. A different participant noted they had seen BFD issues in the past. They noted this happened in March. That would have been the prior route servers, which were BIRD 1.x (I believe) on FreeBSD. Note that BFD is configured as passive (i.e. the participant has to initiate it). Relevant config bits: protocol bfd { accept ipv4 direct; interface "en*" { passive on; multiplier 3; min rx interval 500ms; min tx interval 500ms; }; } ... protocol bgp pb_0138_as18451 from tb_rsclient { description "AS18451 - LES.NET"; neighbor 206.108.255.175 as 18451; ipv4 { import limit 120 action restart; import filter f_import_as18451; table t_0138_as18451; export filter f_export_as18451; }; bfd on; } Are there interesting fixes since 2.0.8? I looked at the git commit log and I see this (but it doesn't seem like it would apply): commit 99872676df45f1a490d3d63f43081afb41477040 Author: Ondrej Zajicek <santiago(a)crfreenet.org> Date: Sun Jan 22 23:42:08 2023 +0100 BFD: Improve incoming packet matching For active sessions, ignore received packets with zero local id and mismatched remote id. That forces a session timeout instead of an immediate session restart. It makes BFD sessions more resilient to packet spoofing. Thanks to André Grüneberg for the suggestion. The discussion was here: https://lists.iphouse.net/cgi-bin/wa?A2=ind2306&L=MICE-DISCUSS&T=0&F=&S=&P=… <https://lists.iphouse.net/cgi-bin/wa?A2=ind2306&L=MICE-DISCUSS&T=0&F=&S=&P=…> -- Richard

1 0

BIRD 2.13.1 released
by Ondrej Filip 22 Jun '23

22 Jun '23

Dear BIRD users, we're releasing a bugfix version, 2.13.1. When a case statement in filter had an empty branch, it crashed BIRD. This bug applies to versions 2.13 and 2.0.12. Version 2.0.11 is not affected. Also we fixed a bug in BGP Roles manifesting when the other party sent no capabilities at all. Thanks to Kobayashi_Bairuo <noc(a)tohunet.com> for reporting. Ondrej

1 0

Bird routing daemon memory segfault issue submission
by noc＠tohunet.com 22 Jun '23

22 Jun '23

Hello Bird Development Team: We are AS140731, aka TOHUNET, we use bird as our routing program, we have a problem that may be related to the memory address of bird. Here are the problem details: We designed a function for anycast to balance the unequal length ASPATH between different upstreams and different nodes, it has this structure: function anycast(int AS;int Region;int Country;int NodeID) { if net ~ [2406:840:eb8c::/48] then { case NodeID { 1: { case AS { 6939: {bgp_path.prepend(140731);bgp_path.prepend(140731);} } } } } } Among them, AS represents the peer AS of this session, and NodeID represents the ID of this node. After the conditional statement in the case matches the peer AS, as you can see, it will execute bgp_path.prepend, and it works well when the curly braces of the conditional statement are not empty. But the aspath of some of our nodes is long enough that they don't need to be prepend, so we have the following configuration: function anycast(int AS;int Region;int Country;int NodeID) { if net ~ [2406:840:eb8c::/48] then { case NodeID { 1: { case AS { 6939: {} } } } } } Then the problem occurred. In our example, when the Session at 6939 was established, the conditional statement matched 6939, but the content in the curly braces was empty. At this time, bird will be automatically killed and restarted by Linux due to a memory segment fault. The following is the information we get in journalctl: kernel: bird[11433]: segfault at 0 ip 0000559bb2900c28 sp 00007ffcd21d1fc0 error 4 in bird[559bb2886000+9d000] kernel: Code: 8b 7b 04 83 03 01 41 8d 4f ff 0f 1f 84 00 00 00 00 00 89 cd 48 8d 44 6d 00 48 8d 14 c3 4c 8b a2 08 80 01 00 8b 82 10 80 01 00 <41> 3b 04 24 0f > systemd[1]: bird.service: Main process exited, code=killed, status=11/SEGV The version number we are currently using is: v2.13-5-gf8ba8280 debian11, but we have tried to roll back to v2.13 and update to v2.13-10-gf8bcb037, these problems still exist.

2 1

Different export route target for different prefixes of a same VRF
by Ramanathan Selvamani 22 Jun '23

22 Jun '23

Hi Team, I configured l3vpn in BIRD and I was able to see the routes are learnt and advertised based on RT. All the routes in this VRF are advertised with RT (1:11) to neighbors. I have a use case in which I want to apply different RT for different routes belonging to the same VRF. For example, I have the following prefixes in this VRF "vrf2". 101.1.1.0/24 103.1.1.0/24 105.1.1.0/24 I would like to add different "export route target" as below for routes belong to same VRF 101.1.1.0/24 : export RT 1:11 103.1.1.0/24 : export RT 1:20 105.1.1.0/24 : export RT 1:30 Please let me know if there is any way to achieve this with BIRD configuration. protocol l3vpn l3vpn2 { vrf "vrf2"; ipv4 { table vrf2v4; }; ipv6 { table vrf2v6; }; vpn4 { table vpntab4; }; vpn6 { table vpntab6; }; mpls { label policy aggregate; label range vrfrange; }; rd 1:11; import target [(rt, 1, 11)]; export target [(rt, 1, 11)]; } Thanks, Ramanathan

2 2

Best practice Route Reflector
by Oliver Seufer 20 Jun '23

20 Jun '23

Hello, I would like to gather some thoughts on whether I should use a Route Reflector or not, and if I do need one, what would be the best practice. Let's begin with the setup. I have four BGP routers located in two different data centers: * Each router (r1, r2, r3, r4) has an iBGP session established with the other BGP routers. * Two routers (r1 and r2) receive a full table from transit providers. * The other two routers (r3 and r4) receive the best routes (full table) from r1 and r2. * Additionally, r3 and r4 have peering connections with external parties and provide a default route via iBGP to other systems. Schematic representation of the setup data center 1 data center 2 r1 ------------------ r2 \ / ------------------ / \ r3 r4 Under normal conditions, I do not require a Route Reflector in this setup. However, there are situations where r3 can still reach r1 but not r2 and r4. Additionally, r1 can still reach r2. In this specific situation, r3 only receives the best route from r1 and not the learned routes from r2. I am aware that I can use a Route Reflector to address this issue, but I am not entirely certain if it is a suitable solution for my setup. Currently, my plan is to use r1 and r2 as the Route Reflector Cluster (with next hop self), while r3 and r4 would connect as non-Route Reflector clients to r1 and r2. So, the requirement is for r3 and r4 to always receive a full table. Regarding the approach, using a Route Reflector seems like a reasonable solution in this case. However, there might be alternative and potentially better solutions available. Thanks, Oliver

3 2

peering between route reflectors
by Benoit Chesneau 19 Jun '23

19 Jun '23

For redundancy I am thinking to have a router reflector per pop . Each route reflector would peer with each others. The issue is that since each POP has a transit, i have duplicate route and sometimes a loop is created. How can it be prevented?? I tried to put them in the same cluster but it doesn't seem to be enough. Any idea is welcome :) Benoît

3 4

AdminDown is tearing down BGP session
by Sunnat Samadov 19 Jun '23

19 Jun '23

Dear Birds, I am reaching out to seek assistance and guidance from the community regarding an issue we are facing with BIRD, specifically version 2.0.11, which we have been using in our network configuration. Our setup involves configuring BIRD with BGP+BFD, where BIRD initiates the BGP session establishment. However, we have observed an unexpected behavior: after the BIRD daemon successfully establishes the BGP connection, router sends a BFD Admin-down message and requests a new BFD session. This action by router leads to BIRD transitioning to a BFD down state and tearing down the previously established BGP session. According to RFC 5882, upon receiving BFD Admin down the BGP connection should not be terminated. If anyone has encountered a similar situation, your guidance would be invaluable in helping us address this problem. Any suggestions, recommendations, or workarounds would be highly appreciated. Best Regards, Sunnat Samadov

2 3