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 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<mailto: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

Reply via email to