Replies: 1 comment
-
I understand that SR Linux does things a bit differently, and I have no problem with that, but that's not how most other platforms work, and I will not go digging through the code (again) to fine-tune it to a particular implementation behavior while trying to keep everything else working. Doing it once was enough. While it's technically true that unnumbered EBGP sessions using RFC 8950 require IPv6 LLA, platforms that support them in a sane way (as opposed to Nexus OS where you're supposed to configure an EBGP neighbor with IPv6 LLA) enable IPv6 by default. There's also absolutely no need to have IPv6 enabled on loopback interface or even have IPv6 packet forwarding configured. All you need is IPv6 LLA. In any case, if an interface accepts incoming IPv4 packets, or is sending IPv4 packets, but does not have a dedicated IPv4 address, it's by definition an unnumbered IPv4 interface. I'd say this needs to be solved with a SR Linux quirk -- either set IPv6 to True if an interface has an EBGP session with ipv4_rfc8950 flag set, or raise an error if an interface has IPv4 set to True but does not have an associated EBGP session. |
Beta Was this translation helpful? Give feedback.
-
I tried the BGP/Unnumbered example under netlab-examples, and it doesn't work on SR Linux because it is ipv4-only; the
ipv4_rfc8950
flag gets set, but no ipv6 is enabledStrictly speaking SR Linux does not support ipv4 unnumbered (in the sense of the interface being associated with a system interface, like more traditional platforms). But if I set ipv4 unnumbered support to 'False', the other BGP v6-unnumbered cases stop working
ipv4_rfc8950
flag should not get set. Only when ipv6 is True or unnumbered is True AND ipv6 is enabled on loopbackBeta Was this translation helpful? Give feedback.
All reactions