All, somehow related topic I see.. Would worth implementing https://datatracker.ietf.org/doc/html/draft-white-linklocal-capability for Bird (FRRouting already has it), which might also be a step forward.
Thanks! On Tue, Jan 28, 2025 at 3:29 PM Ponikierski, Grzegorz via Bird-users < bird-users@network.cz> wrote: > I see I missed one detail which can be confusing. Problem is with sending > link-local address from Bird to BGP speaker on remote side and this > link-local doesn’t make sense for remote side because they don’t share > common subnet. Belove how it looks like from FRR perspective. > > > > FRR: 2025/01/17 23:27:48 BGP: [PS8NX-WWXPH] 23.33.236.254 sent a v6 LL > next-hop and there's no peer interface information. Hence, withdrawing > > FRR: 2025/01/17 23:27:48 BGP: [RWQFK-BA2JR][EC 33554488] 23.33.236.254: > Attribute MP_REACH_NLRI, parse error - treating as withdrawal > > FRR: 2025/01/17 23:27:48 BGP: [QWG8G-NT6EJ][EC 33554455] > 23.33.236.254(Unknown) rcvd UPDATE with errors in attr(s)!! Withdrawing > route. > > FRR: 2025/01/17 23:27:48 BGP: [XC334-3GAQ8][EC 33554455] 23.33.236.254 > [Error] Update packet error (wrong prefix length 64 for afi 1) > > FRR: 2025/01/17 23:27:48 BGP: [HJP7M-20X19][EC 33554455] 23.33.236.254 > [Error] Error parsing NLRI > > FRR: 2025/01/17 23:27:48 BGP: [HZN6M-XRM1G] %NOTIFICATION: sent to > neighbor 23.33.236.254 3/10 (UPDATE Message Error/Invalid Network Field) 0 > bytes > > > > Regards, > > Grzegorz > > > > *From: *"Brandon Z." <bran...@huize.asia> > *Date: *Tuesday, 28 January 2025 at 01:58 > *To: *"Ponikierski, Grzegorz" <gponi...@akamai.com> > *Cc: *bird-users <bird-users@network.cz> > *Subject: *Re: link-local IPv6 address in BGP.next_hop > > > > Hi Grzegorz, I don’t quite understand what you mean, but maybe someone > else can. It seems like it announced a non-existent local-link address to > another router? Best, Brandon Z. HUIZE LTD www. huize. asia | www. ixp. su > | Twitter This e-mail and > > ZjQcmQRYFpfptBannerStart > > *This Message Is From an Untrusted Sender * > > You have not previously corresponded with this sender. > > ZjQcmQRYFpfptBannerEnd > > Hi Grzegorz, > > > > I don’t quite understand what you mean, but maybe someone else can. It > seems like it announced a non-existent local-link address to another router? > > > Best, > > *Brandon Z.* > > HUIZE LTD > > www.huize.asia > <https://urldefense.com/v3/__https:/huize.asia/__;!!GjvTz_vk!XyivVwgDc3QoWIOFFzClG1jQBYTYBXjPwglViKFx1CYU9iKVGrPgPRPToOkKRYoLldMsfMchRyjWkXIqjQ$> > | www.ixp.su > <https://urldefense.com/v3/__https:/www.ixp.su/__;!!GjvTz_vk!XyivVwgDc3QoWIOFFzClG1jQBYTYBXjPwglViKFx1CYU9iKVGrPgPRPToOkKRYoLldMsfMchRyg1_-iFlg$> > | Twitter > > [image: Image removed by sender.] > > This e-mail and any attachments or any reproduction of this e-mail in > whatever manner are confidential and for the use of the addressee(s) only. > HUIZE LTD can’t take any liability and guarantee of the text of the email > message and virus. > > > > > > On Tue, 28 Jan 2025 at 01:44, Ponikierski, Grzegorz via Bird-users < > bird-users@network.cz> wrote: > > 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 > > -- Donatas
