[RFC] Automatic MP peering with IPv6 link local peers
Good morning^2, as virtually all parts in our datacenters have become IPv6 only, I was wondering if it was easy to add a feature to bird to automatically BGP peer with all alive link local neighbours? Motivation and situation ------------------------ Every node has an IPv6 link local address on every network interface. Bird already supports dynamic peers, including whitelisting of ranges. Instead of specifying specific ranges, it would be great if two or more routers could be placed in the same layer 2 segment and would automatically BGP peer with each other, thus removing any configuration needs. OSPF does a similar job already, however it is not suitable for transferring the BGP attributes. Implementation sketch -------------------------------------------------------------------------------- The idea would be for each router have something on the line of protocol bgp fe80auto { local as 65532; neighbor range fe80::/12 as 65534; dynamic name "link_local_"; # New option, similar to the OSPF option auto_fe80_interfaces "eth1.*"; ipv6 { }; ipv4 { }; } If bird had the stanza auto_fe80_interfaces in it, it would a) ping ff02::2 and record all results b) For each result, excluding our own address, connect to the other nodes c) On expiry or regular interal, go back to (a) and clear peers -------------------------------------------------------------------------------- Maybe this is already possible in current bird, but I haven't found a direct way to dynamically solve this. Looking forward to your thoughts, Nico -- Sustainable and modern Infrastructures by ungleich.ch
On Sat, Jul 09, 2022 at 10:53:28AM +0200, Nico Schottelius wrote:
Good morning^2,
as virtually all parts in our datacenters have become IPv6 only, I was wondering if it was easy to add a feature to bird to automatically BGP peer with all alive link local neighbours?
Motivation and situation ------------------------
Every node has an IPv6 link local address on every network interface. Bird already supports dynamic peers, including whitelisting of ranges.
Instead of specifying specific ranges, it would be great if two or more routers could be placed in the same layer 2 segment and would automatically BGP peer with each other, thus removing any configuration needs.
Hello It would be easy to add support for interface specification instead of just IP range (if that is not there already). The main issue is that dynamic range works primarily as passive, as there is no neighbor discovery. I think there is some RFC draft for BGP neighbor discovery, will look for it. Using ping seems like too hacky. -- 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 Jul 14, Ondrej Zajicek <santiago@crfreenet.org> wrote:
The main issue is that dynamic range works primarily as passive, as there is no neighbor discovery. I think there is some RFC draft for BGP neighbor discovery, will look for it. Using ping seems like too hacky. RFC 8950 is what has been implemented in Cumulus.
-- ciao, Marco
On Thu, Jul 14, 2022 at 05:17:25PM +0200, Marco d'Itri wrote:
On Jul 14, Ondrej Zajicek <santiago@crfreenet.org> wrote:
The main issue is that dynamic range works primarily as passive, as there is no neighbor discovery. I think there is some RFC draft for BGP neighbor discovery, will look for it. Using ping seems like too hacky.
RFC 8950 is what has been implemented in Cumulus.
Not sure how that is relevant, RFC 8950 is just IPv6 next hop for IPv4 routes, it does not handle BGP neighbor discovery. -- 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 Jul 14, Ondrej Zajicek <santiago@crfreenet.org> wrote:
RFC 8950 is what has been implemented in Cumulus. Not sure how that is relevant, RFC 8950 is just IPv6 next hop for IPv4 routes, it does not handle BGP neighbor discovery. Discovery is just looking at Router Advertisements for the link, then you need RFC 8950.
https://www.theasciiconstruct.com/post/cumulus-basics-part-v-bgp-unnumbered/ https://www.theasciiconstruct.com/post/junos-bgp-and-bgp-unnumbered/#bgp-unn... -- ciao, Marco
On Thu, Jul 14, 2022 at 05:36:20PM +0200, Marco d'Itri wrote:
On Jul 14, Ondrej Zajicek <santiago@crfreenet.org> wrote:
RFC 8950 is what has been implemented in Cumulus. Not sure how that is relevant, RFC 8950 is just IPv6 next hop for IPv4 routes, it does not handle BGP neighbor discovery. Discovery is just looking at Router Advertisements for the link, then you need RFC 8950.
Hmm, using Router Advertisements for BGP neighbor discovery is an interesting idea, especially when it is already implemented by other vendors. We already have support for extended next hop (RFC 5549, where RFC 8950 is just a minor update). -- 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."
...especially when it is already implemented by other vendors.
Cisco NXOS does similar, yea: https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/93x/u...
You can configure BGP Interface Peering via IPv6 Link-Local for IPv4 and IPv6 Address Families for automatic BGP neighbor discovery using unnumbered interfaces. Doing so allows you to set up BGP sessions using an interface name as a BGP peer (rather than interface-scoped addresses). ***This feature relies on ICMPv6 neighbor discovery (ND) route advertisement (RA) for automatic neighbor discovery and on RFC 5549 for sending IPv4 routes with IPv6 next hop.***
On Thu, Jul 14, 2022 at 9:09 AM Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Thu, Jul 14, 2022 at 05:36:20PM +0200, Marco d'Itri wrote:
On Jul 14, Ondrej Zajicek <santiago@crfreenet.org> wrote:
RFC 8950 is what has been implemented in Cumulus. Not sure how that is relevant, RFC 8950 is just IPv6 next hop for IPv4 routes, it does not handle BGP neighbor discovery. Discovery is just looking at Router Advertisements for the link, then you need RFC 8950.
Hmm, using Router Advertisements for BGP neighbor discovery is an interesting idea, especially when it is already implemented by other vendors.
We already have support for extended next hop (RFC 5549, where RFC 8950 is just a minor update).
-- Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net <https://isolate-menlo.menlosecurity.com/0/eJyrViotylGyUsooKSmw0tcvLy_PTq0s1itIL9DLSy1R0lEqyleyMtRRKslMAaoyNFWqBQCs2g_C> ) "To err is human -- to blame it on a computer is even more so."
This thread reminded me of something I saw these days about using BGP unnumbered in Hypervisors for EVPN/VXLAN. I confess that I was completely stunned to see how beautiful it was! - The 4 ports of each Server became a CLOS L3 topology. - The complexities of Multichassis-LAG no longer exist. - The establishment of neighborhoods was almost automatic. - And the ToR switches became only simple L3 routers, without even knowing of the existence of Overlay. Which made them much cheaper and simpler to operate. Em qui., 14 de jul. de 2022 às 12:40, Marco d'Itri <md@linux.it> escreveu:
On Jul 14, Ondrej Zajicek <santiago@crfreenet.org> wrote:
RFC 8950 is what has been implemented in Cumulus. Not sure how that is relevant, RFC 8950 is just IPv6 next hop for IPv4 routes, it does not handle BGP neighbor discovery. Discovery is just looking at Router Advertisements for the link, then you need RFC 8950.
https://www.theasciiconstruct.com/post/cumulus-basics-part-v-bgp-unnumbered/
https://www.theasciiconstruct.com/post/junos-bgp-and-bgp-unnumbered/#bgp-unn...
-- ciao, Marco
-- Douglas Fernando Fischer Engº de Controle e Automação
We did similar at a previous gig, though the switches did not support BGP unnumbered so there was an initial DHCP bootstrap to hit a couple of microservices to retrieve identity info (upsert local server's ASN; retrieve switch peer ASNs), but then turned up peering and off you go. But I digress: It would be fantastic if BIRD could support interface-specified unnumbered BGP over IPv6 LL with an RA bootstrap and 5549-based 4-over-6. On Thu, Jul 14, 2022 at 2:42 PM Douglas Fischer <fischerdouglas@gmail.com> wrote:
This thread reminded me of something I saw these days about using BGP unnumbered in Hypervisors for EVPN/VXLAN.
I confess that I was completely stunned to see how beautiful it was!
- The 4 ports of each Server became a CLOS L3 topology. - The complexities of Multichassis-LAG no longer exist. - The establishment of neighborhoods was almost automatic. - And the ToR switches became only simple L3 routers, without even knowing of the existence of Overlay. Which made them much cheaper and simpler to operate.
Em qui., 14 de jul. de 2022 às 12:40, Marco d'Itri <md@linux.it> escreveu:
On Jul 14, Ondrej Zajicek <santiago@crfreenet.org> wrote:
RFC 8950 is what has been implemented in Cumulus. Not sure how that is relevant, RFC 8950 is just IPv6 next hop for IPv4 routes, it does not handle BGP neighbor discovery. Discovery is just looking at Router Advertisements for the link, then you need RFC 8950.
https://www.theasciiconstruct.com/post/cumulus-basics-part-v-bgp-unnumbered/ <https://isolate-menlo.menlosecurity.com/0/eJwNzDkOhDAMAMC_uMZYFDT5TWIiiEQO-SDFav8O84D5gcsNAS6zoYFozrnalaNyKdybmjjbyr3S6GrEXv12xRS1sOKIYvhgOgd6a15TlnwQLCAdwraAleO7tx3-L-LkJKs>
https://www.theasciiconstruct.com/post/junos-bgp-and-bgp-unnumbered/#bgp-unn... <https://isolate-menlo.menlosecurity.com/0/eJxVjrsOgzAMRf_FXQkRQ5f8DXmIGIEdxXYzVP13Kjp1ujpHZ7hvsH5AgKraJHg_xpi1llUSYmIS7ZZ0Tnz6xqJ-N2JxcWtupXyvEdkZSy_ZP_75l5myyyiJX7ejgluN3AUm6AxhmUAxfw8sT_hciJ4ytg>
-- ciao, Marco
-- Douglas Fernando Fischer Engº de Controle e Automação
So if I read this thread correctly, the "only feature" to be added to bird would be to allow peer detection based on router advertisements, as the rest is already present. Am I correct in this summary? -- Sustainable and modern Infrastructures by ungleich.ch
participants (6)
-
Douglas Fischer -
Hugo Slabbert -
Marco d'Itri -
Marco d'Itri
-
Nico Schottelius -
Ondrej Zajicek