- Bird-users - Mailing Lists

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

BIRD 3.0.1 Ignoring GW Attribute
by Hutchinson, Peter 21 Jan '25

21 Jan '25

It seems that BIRD 3.0.1 is ignoring the GW attribute, after upgrading from BIRD 2.16.1 to 3.0.1 all routes are showing as unreachable as shown below. The BGP peers are 3 hops away from BIRD within the same AS hence the need for the GW. Note I did not modify the BIRD configuration in between upgrading from 2.16.1 to 3.0.1. birdc 'show route all for 1.1.1.1' BIRD 2.16.1 ready. Table master4: 1.1.1.0/24 unicast [wel_core30 2025-01-16 from 203.14.14.10] * (100/?) [AS13335i] via 203.41.0.5 on ens3 Type: BGP univ BGP.origin: IGP BGP.as_path: 13335 BGP.next_hop: 203.14.14.65 BGP.local_pref: 100 BGP.aggregator: 172.68.0.1 AS13335 BGP.community: (1221,110) (13335,10084) BGP.originator_id: 203.14.14.65 BGP.cluster_list: 203.14.14.10 unicast [pie_core30 2025-01-16 from 203.14.14.11] (100/?) [AS13335i] via 203.41.0.5 on ens3 Type: BGP univ BGP.origin: IGP BGP.as_path: 13335 BGP.next_hop: 203.14.14.65 BGP.local_pref: 100 BGP.aggregator: 172.68.0.1 AS13335 BGP.community: (1221,110) (13335,10084) BGP.originator_id: 203.14.14.65 BGP.cluster_list: 203.14.14.11 birdc 'show route all for 1.1.1.1' BIRD 3.0.1 ready. Table master4: 1.1.1.0/24 unreachable [wel_core30 11:21:09.045 from 203.14.14.10] * (100) [AS13335i] hostentry: via 203.14.14.65 table master4 preference: 100 igp_metric: 0 from: 203.14.14.10 source: BGP bgp_origin: IGP bgp_path: 13335 bgp_next_hop: 203.14.14.65 bgp_local_pref: 100 bgp_aggregator: 172.68.0.1 AS13335 bgp_community: (1221,110) (13335,10084) bgp_originator_id: 203.14.14.65 bgp_cluster_list: 203.14.14.10 Internal route handling values: 0L 11G 0S id 417853 unreachable [pie_core30 11:21:13.738 from 203.14.14.11] (100) [AS13335i] hostentry: via 203.14.14.65 table master4 preference: 100 igp_metric: 0 from: 203.14.14.11 source: BGP bgp_origin: IGP bgp_path: 13335 bgp_next_hop: 203.14.14.65 bgp_local_pref: 100 bgp_aggregator: 172.68.0.1 AS13335 bgp_community: (1221,110) (13335,10084) bgp_originator_id: 203.14.14.65 bgp_cluster_list: 203.14.14.11 Internal route handling values: 0L 9G 0S id 1516013 The BIRD configuration used is shown below. log syslog all; router id 203.41.0.6; roa4 table roa_v4; roa6 table roa_v6; #Inbound route policy filter rpl_in { gw = 203.41.0.5; accept; } #BGP IPv4 neighbor config template template bgp CORE_PEERS { local as 1221; neighbor as 1221; password REDACTED; ipv4 { import filter rpl_in; export none; }; } #BGP IPv6 neighbor config template template bgp CORE_PEERS_V6 { local as 1221; neighbor as 1221; password REDACTED; ipv6 { import filter rpl_in; export none; }; } #Import device routes for TID interface protocol device { scan time 10; interface "ens3"; } #Import directly connected routes for TID interface protocol direct { ipv4; ipv6; interface "ens3"; } #BGP IPv4 core peer 1 protocol bgp wel_core30 from CORE_PEERS { neighbor 203.14.14.10; } #BGP IPv4 core peer 2 protocol bgp pie_core30 from CORE_PEERS { neighbor 203.14.14.11; } #BGP IPv6 core peer 1 protocol bgp wel_core30_v6 from CORE_PEERS_V6 { neighbor 2001:8000::70:101; } #BGP IPv6 core peer 2 protocol bgp pie_core30_v6 from CORE_PEERS_V6 { neighbor 2001:8000::70:201; } #RPKI cache server 1 protocol rpki rpki_cache_1{ roa4 { table roa_v4; }; roa6 { table roa_v6; }; remote REDACTED port 8323; transport tcp; refresh 300; expire keep 3600; } #RPKI cache server 2 protocol rpki rpki_cache_2{ roa4 { table roa_v4; }; roa6 { table roa_v6; }; remote REDACTED port 8323; transport tcp; refresh 300; expire keep 3600; } Regards, Peter Hutchinson TID Core Internet Edge & Core Global Networks & Technology, Transport & IP [cid:1dfbd70b-26ae-414d-aa87-8a8e859368d7] 0490338570 peter.hutchinson(a)team.telstra.com<mailto:peter.hutchinson@team.telstra.com> www.telstra.com<http://www.telstra.com/> This email may contain confidential information. If I've sent it to you by accident, please delete it immediately. General

1 0

third (?) bug in 3.0.0
by Marek Zarychta 14 Jan '25

14 Jan '25

I tried BIRD 3 on FreeBSD, seems to build fine including both flavors: netlink and rtsock. Only the netlink flavor was tested in runtime. In small, testing scenario with OSPF and BGP it seems to run fine. When deployed in production setup with dual-stack and 2x full-view the daemon crashes almost immediately with SIGSEGV. It was non-debug built, so cores will not be much useful, though I can share them. Cheers -- Marek Zarychta

2 3