BGP: Add support for peering with link-local IPv6 addresses
Hi, the attached patch adds support for using link-local v6 addresses for BGP peerings by adding an interface attribute to the BGP protocol. It has been succesfully tested in a Bird<->Quagga configuration on Linux, and with Bird<->Bird using Linux<->Linux and Linux<->FreeBSD. I know the BGP RFCs (especially 2545) are a bit unclear if this should be allowed, but RFC 4659 suggests it should, and also describes how to set the NEXT_HOP attribute when no global addresses are used. Anyways, I'd love to see this patch included in Bird. It shouldn't make any difference when you don't use the interface attribute, so it won't have bad influence on people not using this feature, and it makes Bird an alternative to Quagga when you need link-local peering support. :-) Matthias Schiffer
On Sun, Dec 19, 2010 at 09:55:24AM +0100, Matthias Schiffer wrote:
Hi, the attached patch adds support for using link-local v6 addresses for BGP peerings by adding an interface attribute to the BGP protocol. It has been succesfully tested in a Bird<->Quagga configuration on Linux, and with Bird<->Bird using Linux<->Linux and Linux<->FreeBSD.
I know the BGP RFCs (especially 2545) are a bit unclear if this should be allowed, but RFC 4659 suggests it should, and also describes how to set the NEXT_HOP attribute when no global addresses are used.
Anyways, I'd love to see this patch included in Bird. It shouldn't make any difference when you don't use the interface attribute, so it won't have bad influence on people not using this feature, and it makes Bird an alternative to Quagga when you need link-local peering support. :-)
Thanks, i will merge that.
diff --git a/sysdep/bsd/krt-sock.c b/sysdep/bsd/krt-sock.c index 53b30ca..fc73be8 100644 --- a/sysdep/bsd/krt-sock.c +++ b/sysdep/bsd/krt-sock.c @@ -541,7 +541,7 @@ krt_read_addr(struct ks_msg *msg) _I0(ifa.ip) = 0xfe800000; #endif
- if (iface->flags & IF_MULTIACCESS) + if ((iface->flags & IF_MULTIACCESS) || ipa_has_link_scope(ifa.ip)) { ifa.prefix = ipa_and(ifa.ip, ipa_mkmask(masklen));
What is exactly that? Link-local addresses are broken (in BIRD) on non-multiaccess devices on *BSD? -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On 12/21/2010 01:21 AM, Ondrej Zajicek wrote:
diff --git a/sysdep/bsd/krt-sock.c b/sysdep/bsd/krt-sock.c
index 53b30ca..fc73be8 100644 --- a/sysdep/bsd/krt-sock.c +++ b/sysdep/bsd/krt-sock.c @@ -541,7 +541,7 @@ krt_read_addr(struct ks_msg *msg) _I0(ifa.ip) = 0xfe800000; #endif
- if (iface->flags & IF_MULTIACCESS) + if ((iface->flags & IF_MULTIACCESS) || ipa_has_link_scope(ifa.ip)) { ifa.prefix = ipa_and(ifa.ip, ipa_mkmask(masklen));
What is exactly that? Link-local addresses are broken (in BIRD) on non-multiaccess devices on *BSD?
Without that patch, on *BSD link-local addresses will be marked as unnumbered on pointopoint interfaces, while they are in fact /64. This breaks the is_connected() check that's called from neigh_find2(), as there is no opposite address. Matthias Schiffer
On Sun, Dec 19, 2010 at 09:55:24AM +0100, Matthias Schiffer wrote:
Anyways, I'd love to see this patch included in Bird. It shouldn't make any difference when you don't use the interface attribute, so it won't have bad influence on people not using this feature, and it makes Bird an alternative to Quagga when you need link-local peering support. :-)
I checked the patch and it seems that there are some issues with the neighbor cache - neigh_find2() really doesn't work with NEF_STICKY and link-local together, because the main purpose of sticky neighbors is to notify the protocol when the appropriate iface appears and is ready. If the iface is not found in bgp_start_locked(), (call if_find_by_name() returns NULL), the BGP session is never started (even if the interface later appears). I will look at that. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On 12/22/2010 06:45 PM, Ondrej Zajicek wrote:
On Sun, Dec 19, 2010 at 09:55:24AM +0100, Matthias Schiffer wrote:
Anyways, I'd love to see this patch included in Bird. It shouldn't make any difference when you don't use the interface attribute, so it won't have bad influence on people not using this feature, and it makes Bird an alternative to Quagga when you need link-local peering support. :-) I checked the patch and it seems that there are some issues with the neighbor cache - neigh_find2() really doesn't work with NEF_STICKY and link-local together, because the main purpose of sticky neighbors is to notify the protocol when the appropriate iface appears and is ready. If the iface is not found in bgp_start_locked(), (call if_find_by_name() returns NULL), the BGP session is never started (even if the interface later appears). I will look at that. NEF_STICKY doesn't seem to work for BGP at all. Even without my patch, the line with the message "Waiting for %I to become my neighbor" is never reached, as neigh_find sets the scope of the returned neighbor to 0 if the neighbor is not found, but as 0 is equivalent to SCOPE_HOST, the neighbor is declared invalid and the protocol will be disabled. I guess it's not intended to return SCOPE_HOST when the neighbor is not found...
Also, the neighbor cache won't notify the protocol if the neighbor becomes available by adding a new address to an up interface and the interface doesn't go down and up again afterwards. I think these problems have to be solved first... making NEF_STICKY work with link-local addresses should be as easy as saving the interface given to neigh_find2 in the neighbor entry and checking for it in neigh_if_up. Anyways, that problem applies to my code only when the given interface does exist, so it can be found by if_find_by_name, but that interface doesn't have a link-local address defined. When the given interface doesn't exist in the first place, neigh_find2 will never be called; an additional notification for up-coming interface for the BGP protocol would be necessary. Thanks for looking at my patch, and a merry christmas everyone, Matthias Schiffer
participants (2)
-
Matthias Schiffer -
Ondrej Zajicek