- Bird-users - Mailing Lists

Bird v3 BGP route selection
by Nigel Kukard 25 Feb '25

25 Feb '25

Hi there, I'm wondering if someone can point out how the best path is being selected below in Bird 3.0.1? In Bird v2 the route via 100.201.0.2 was selected. With the exact same configuration in Bird v3, the route via 100.201.0.4 is being selected. In this case R1 is connected to R2. Both with the same ASN. The below table is the table I have facing R2. In terms of my routing tables... - originate4 =exports to=> bgp4 - static4 =exports to=> master4 - master4 <=exports/imports=> bgp4 - bgp4 <=exports/imports=> t_bgp4_AS65000_r2_peer (below) 1007-Table t_bgp4_AS65000_r2_peer: 0.0.0.0/0 unicast [bgp_originate4 2025-02-24 23:21:13] * (200) via 100.201.0.4 on eth2 1012- preference: 200 source: static bgp_local_pref: 930 bgp_large_community: (65000, 3, 1) 1008- Internal route handling values: 0L 24G 0S id 1 1007- unicast [static4 2025-02-24 23:21:13] (200) via 100.201.0.2 on eth2 1012- preference: 200 source: static bgp_local_pref: 940 bgp_large_community: (65000, 3, 1) (65000, 5000, 1) 1008- Internal route handling values: 0L 22G 0S id 6 Kind Regards Nigel

2 3

How to filter VPN4 address using route-map
by Ramanathan Selvamani 24 Feb '25

24 Feb '25

Hi Team, I would like to filter a VPN4 address using route-map. For example, I have the below VPN4 address learnt through BGP neighbor on "L2VPN EVPN" channel. Table vpntab4: 1:222 90.0.0.0/24 unicast [EVPN_4_4_4_4 2025-02-21] * (160) 1:100 60.0.0.0/24 unicast [BGP_4_4_4_4 17:45:37.617 from 4.4.4.4] * E (156/1) [AS400?] 4.4.4.4:222 70.0.0.0/24 unicast [BGP_4_4_4_4 17:45:37.617 from 4.4.4.4] * E (156/1) [AS400?] 1:111 151.1.1.0/24 unicast [EVPN_4_4_4_4 2025-02-21] * (160) I want to create a route-map to accept only 1:100 60.0.0.0/24 and reject all the rest. When I tried the below configuration in route-map, I got a syntax error on the below line. if(net ~ [1:100 60.0.0.0/24]) then { return 2;} Similarly, is there any way to filter the VPN4 address using its RD value ? Thanks, Ramanathan

3 2

IPv6 prefix is not stored to kernel when multipath is enabled in 1.6.8
by Jimmy Lim 20 Feb '25

20 Feb '25

Hi guys, I have multipath enabled on bird6 running in old 1.6.8. I discovered that the IPv6 prefix failed to be installed properly in the kernel with more than 1 path and when multipath is enabled. syslog message: > Feb 9 23:54:31 x40-n bird6: kernel1 < replaced fcdf::/16 multipath > Feb 9 23:54:53 x40-n bird6: kernel1: fcdf::/16: reinstalling > Feb 9 23:55:53 x40-n bird6: kernel1: fcdf::/16: reinstalling > Feb 9 23:56:53 x40-n bird6: kernel1: fcdf::/16: reinstalling The IPv6 prefix is installed properly if I remove multipath in bird6: > # merge paths on; But then it means the path won't be shared with the rest of the path. syslog message: > Feb 9 23:57:15 x40-n bird6: kernel1 < added fcdf::/16 dev wg2 > Feb 9 23:57:15 x40-n bird6: kernel1: fcdf::/16: reinstalling > Feb 9 23:58:15 x40-n bird6: kernel1: fcdf::/16: seen > Feb 9 23:59:16 x40-n bird6: kernel1: fcdf::/16: seen Do you guys encounter this issue or is there any other configuration needed? The multipath works well in IPv4/bird. Thanks, Jimmy

5 10

[PATCH] OSPF: Fix inverted path comparison for external
by Mantas Mikulėnas 18 Feb '25

18 Feb '25

From: Mantas Mikulėnas <grawity(a)gmail.com> For an ordinary E1 or E2 route exported by another Bird2 router in the same area, it was consistently choosing a 10000+ metric path through another area, despite having a direct 10-metric path to the origin in the same backbone area. It seems that this was because the rule 16.2 metric comparison was backwards and always chose highest metric. Note - the patch is probably *not* 100% right; I am not very sure whether both checks are backwards or only the orta_pref() one. It's merely my first successful attempt at fixing the issue (which only affected Bird, not any other OSPFv2 implementation I have here). Regardless, it did happen to fix the issue I was having, and now Bird2 chooses the path I expect it to choose: Before: Table master4: 172.20.0.0/14 unicast [ospf4 10:09:35.865] * E2 (150/10080/100) [31.220.42.129] via 10.147.255.10 on homegw Type: OSPF-E2 univ OSPF.metric1: 10080 OSPF.metric2: 100 OSPF.tag: 0x00000000 OSPF.router_id: 31.220.42.129 After: Table master4: 172.20.0.0/14 unicast [ospf4 12:48:02.452] * E2 (150/30/100) [31.220.42.129] via 10.147.240.122 on gre-land Type: OSPF-E2 univ OSPF.metric1: 30 OSPF.metric2: 100 OSPF.tag: 0x00000000 OSPF.router_id: 31.220.42.129 --- proto/ospf/rt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proto/ospf/rt.c b/proto/ospf/rt.c index d7753ce0a..c6bf5699e 100644 --- a/proto/ospf/rt.c +++ b/proto/ospf/rt.c @@ -200,7 +200,7 @@ orta_compare_asbr(const struct ospf_proto *p, const orta *new, const orta *old) if (!p->rfc1583) { - r = epath_preferred(new) - epath_preferred(old); + r = epath_preferred(old) - epath_preferred(new); if (r) return r; } @@ -242,7 +242,7 @@ orta_compare_ext(const struct ospf_proto *p, const orta *new, const orta *old) /* 16.4 (6c) - if not RFC1583, prefer routes with preferred ASBR/next_hop */ if (!p->rfc1583) { - r = orta_pref(new) - orta_pref(old); + r = orta_pref(old) - orta_pref(new); if (r) return r; } -- 2.48.1

2 3

No `hostname` within `protocol`?
by Bernd Naumann 12 Feb '25

12 Feb '25

Hey! I wanted to set `hostname "foo";` within `template bgp ... { ... };` and got `syntax error, unexpected HOSTNAME`. As a workaround I can set the hostname on the global level but I would like to see that's possible to set hostname on a protocol level. My use-case (that's why I stumbled upon it) is that I've been connected to dn42 and wanted to announce `cpe.bernd.dn42` on my peers and not just the systems `cpe`, or it's unhelpful fqdn `cpe.home.arpa`.[1] I'm running BIRD version 2.15.1 on OpenWrt 23.05.5. Thanks! Bernd [1] Yes, I do really like `home.arpa.`.

2 2

Several crashes in 3.0.1
by Yureka 10 Feb '25

10 Feb '25

After deploying bird 3.0.1, the bird process keeps crashing on several of my routers, which had never crashed before on bird 2.x. Within ~5min, I've seen the bird process crash with SIGABRT 27 times: 16x `Withdrawn route never seen before` 8x `Assertion '!rt_export_feed_active(&c->reimporter)' failed at nest/proto.c:756` 2x `Assertion 'rt_export_get_state(&c->out_req) == TES_DOWN' failed at nest/proto.c:755` 1x `Assertion '!old' failed at nest/rt-table.c:1510` My config is using a mix of Babel with RTT extensions, OSPF, iBGP and eBGP. "withdrawn route never seen before" sure sounds like one of my peers is misbehaving but 1) this should not crash bird 2) it should provide more information about which peer is misbehaving I can not judge which of the other assertions are errors about the bird-internal state which should never happen in the first place, or which are caused by bad peer behaviour (which, again, should not crash bird). Best regards, Yureka

2 1

How to upgrade version Bird to 2.15.1
by Nguyen Van Nhan 02 Feb '25

02 Feb '25

Dear Bird Community, I have installed BIRD and tested the configurations related to the operation of this application. I have some questions during the BIRD deployment process, I hope you will give me specific instructions for editing and optimizing in operation. I am installing the default Bird version 2.0.8 on Ubuntu LTS 22.04 operating system 1. Can you provide me with detailed instructions to upgrade Bird to the latest version 2.15.1? I have tried to upgrade but when performing the operation in birdc, it still shows that it is at version 2.0.8. 2. Does Bird support BMP protocol in the latest version? We are researching to use BMP on Bird to get monitoring data via OpenBMP. Is it possible? Thanks and best regards, Nhan Nguyen Email: nhannv(a)vnnic.vn<mailto:nhannv@vnnic.vn> Mobile: +84 905 674 854

2 1

link-local IPv6 address in BGP.next_hop
by Ponikierski, Grzegorz 29 Jan '25

29 Jan '25

Hello all! I have an interesting case of link-local IPv6 address in BGP.next_hop and I would like to know your opinion about that because I cannot tell with 100% confidence if it’s a bug or a feature. Existence of these link-local addresses causes issues of interoperability between Bird and FRR. I have separate discussion about that with FRR folks. Here I would like to now a Bird perspective. Details below. On single router with Bird 2.15 I have multiple IPv4 and IPv6 eBGP sessions, which receives prefixes from the Internet, and IPv4 iBGP session, which forwards these prefixes to BGP collector with FRR, which is separate server somewhere in the Internet many hops away in separate ASN. Session with BGP collector uses both ipv4 and ipv6 channels to send both IPv4 and IPv6 prefixes. IPv6 prefixes received via eBGP have both global IPv6 address and link-local IPv6 address like in an example below: ::/0 unicast [2600:1488:6080::8__r01.fra03.ien 2024-12-06] * (100) [AS3356i] via 2600:1488:6080::8 on ae2 Type: BGP univ BGP.origin: IGP BGP.as_path: 3356 BGP.next_hop: 2600:1488:6080::8 fe80::7a4f:9bff:fed1:2e0d BGP.med: 4294967294 BGP.local_pref: 60 BGP.community: (3356,2) (3356,501) (3356,601) (3356,2065) (20940,30403) (65502,3356) However, prefixes forwarded via iBGP to BGP collector also have both global and link-local addresses like below: ::/0 unicast [2600:1488:6080::8__r01.fra03.ien 2024-12-06] * (100) [AS3356i] via 2600:1488:6080::8 on ae2 Type: BGP univ BGP.origin: IGP BGP.as_path: 3356 BGP.next_hop: 2600:1488:6080::8 fe80::7a4f:9bff:fed1:2e0d BGP.med: 4294967294 BGP.local_pref: 60 BGP.community: (3356,2) (3356,501) (3356,601) (3356,2065) (20940,30403) (65502,3356) (21357,600) On one hand, as per RFC 4271 NEXT_HOP is not changed when prefix is passed from eBGP to iBGP so what we see above it expected. But on the other hand, as per RFC 2545 link-local address must not be there because both sides of iBGP doesn’t share the same IPv6 subnet: “”” The link-local address shall be included in the Next Hop field if and only if the BGP speaker shares a common subnet with the entity identified by the global IPv6 address carried in the Network Address of Next Hop field and the peer the route is being advertised to. In all other cases a BGP speaker shall advertise to its peer in the Network Address field only the global IPv6 address of the next hop (the value of the Length of Network Address of Next Hop field shall be set to 16). “”” Who is right here? As far I know, both documents are still current standards, and both are implemented by Bird. I don’t see any clear guidelines how to make a clear judgement here. Personally, I would tell that RFC 4271 should be treated as general rule and RFC 2545 as more specific rule so in the end link-local should be removed. After all, link-local addresses do not make sense for multihop sessions. However, these documents don’t refer to each other and I don’t know if authors of these documents knew about each other statements. What do you think? Anyway, when BGP collector with FRR 8.5.2 receives BGP UPDATE for route like presented above, then FRR rejects such UPDATE with treat-as-withdrawn approach but also triggers additional error about invalid prefix length for AFI 1, which finally causes NOTIFICATION (UPDATE Message Error/Invalid Network Field) and session goes down. I cannot rule out implementation bug in FRR version that I use, and I discuss it with FRR folks already. Working workaround that I tested is to apply `next hop self` on Bird side. Probably `bgp_next_hop = bgp_next_hop` in Bird’s export policy will also work but I must test it yet. What do you think? It’s a bug or a feature? Regards, Grzegorz

4 9

OSPfv3 IPV4 over local link on freebds
by benoitc＠enki-multimedia.eu 26 Jan '25

26 Jan '25

Hi all, I am looking at reducing the number of IPv4s I am using but i'ms truggling to have loopback propagation over local link using OSPv3 on freebsd. Did someone tried it? Can you share your related configuration? when i setup the ip on lo1 and pass as stub in the OSPfV3 IPv4 iinstances, no ipv4 route is exported. any hint is welcome. Benoît

3 4

radvd lifetime question
by Nico Schottelius 23 Jan '25

23 Jan '25

Hello, we got a network in which clients using dhcpcd withdraw the router advertisements sent by bird too early: -------------------------------------------------------------------------------- Dec 19 06:33:15 bibimbap daemon.warn dhcpcd[18464]: wlan0: fe80::20d:b9ff:fe48:3bb8: router expired Dec 19 06:33:15 bibimbap daemon.warn dhcpcd[18464]: wlan0: part of a Router Advertisement expired Dec 19 06:38:22 bibimbap daemon.warn dhcpcd[18464]: wlan0: fe80::20d:b9ff:fe48:3bb8: router expired Dec 19 06:38:22 bibimbap daemon.warn dhcpcd[18464]: wlan0: part of a Router Advertisement expired Dec 19 06:39:30 bibimbap daemon.warn dhcpcd[18464]: wlan0: fe80::20d:b9ff:fe46:3bd4: router expired Dec 19 06:39:30 bibimbap daemon.warn dhcpcd[18464]: wlan0: part of a Router Advertisement expired -------------------------------------------------------------------------------- The config in bird is: -------------------------------------------------------------------------------- protocol radv { # Pods / bridge interface "eth0" { max ra interval 10; prefix 2a0a:5480::/64 { preferred lifetime 86400; }; prefix 2a0a:e5c0:13::/64 { skip; }; default preference high; }; rdnss { ns 2a0a:5480:0:a::a; ns 2a0a:5480:0:a::b; lifetime 86400; }; } -------------------------------------------------------------------------------- This causes RAs to be sent that look like this: -------------------------------------------------------------------------------- interface wlan0 { AdvSendAdvert on; # Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump AdvManagedFlag off; AdvOtherConfigFlag off; AdvReachableTime 0; AdvRetransTimer 0; AdvCurHopLimit 64; AdvDefaultLifetime 30; AdvHomeAgentFlag off; AdvDefaultPreference low; prefix 2a0a:5480::/64 { AdvValidLifetime 86400; AdvPreferredLifetime 86400; AdvOnLink on; AdvAutonomous on; AdvRouterAddr off; }; # End of prefix definition RDNSS 2a0a:5480:0:a::a 2a0a:5480:0:a::b { AdvRDNSSLifetime 86400; }; # End of RDNSS definition }; # End of interface definition -------------------------------------------------------------------------------- It seems that the "AdvDefaultLifetime 30;" is wrong. Trying to fix it using -------------------------------------------------------------------------------- interface "eth0" { default lifetime 86400; -------------------------------------------------------------------------------- fails as bird reports: -------------------------------------------------------------------------------- /bird/bird.conf:897:31 Default lifetime must be in range 0-9000 -------------------------------------------------------------------------------- I read in the manpage of radvd that indeed 9000 is the max (not sure why that limit is at 9k though...), but what I am wondering is what is the right approach to this? Or is this a bug in dhcpcd? BR, Nico p.s.: A low "max ra interval" allows us to run multiple, active routers in the same network and clients will quickly fall over to the second router, if one is not functioning correctly. -- Sustainable and modern Infrastructures by ungleich.ch

2 1