The Border Gateway Protocol (BGP) is an IP reachability protocol that you can use to exchange IP prefixes. Traditionally, one of the nuisances of configuring BGP is that if you want to exchange IPv4 prefixes you have to configure an IPv4 address for each BGP peer. In a large network, this can consume a lot of your address space, requiring a separate IP address for each peer-facing interface.
BGP Over IPv4 Interfaces
To understand where BGP unnumbered fits in, it helps to understand how BGP has historically worked over IPv4. Peers connect via IPv4 over TCP port 179. Once they’ve established a session, they exchange prefixes. When a BGP peer advertises an IPv4 prefix, it must include an IPv4 next hop address, which is usually the address of the advertising router. This requires, of course, that each BGP peer has an IPv4 address.
As a simple example, using the Cumulus Reference Topology, let’s configure BGP peerings as follows:
Between spine01 (AS 65020, 10.1.0.0/31) and leaf01 (AS 65011, 10.1.0.1/31)
Between spine01 (10.1.0.4/31) and leaf02 (AS 65012, 10.1.0.5/31)
Leaf01 will advertise the prefix 192.0.2.1/32 and leaf02 will advertise the prefix 192.0.2.2/32. Let’s set it up:
Now let’s take a look at the BGP RIB to see if spine01 has learned the 192.0.2.1/32 and 192.0.2.2/32 prefixes:
It has! And notice that the Next Hop address for each is the interface IPv4 address of the respective neighbor. The requirement that each prefix has a Next Hop address is the reason we historically had to configure IPv4 addresses on all of our BGP-speaking interfaces.
Enabling BGP Unnumbered
The BGP unnumbered standard, laid out in RFC 5549, no longer requires an IPv4 prefix to be advertised along with an IPv4 next hop. That means you can set up BGP peering among your Cumulus Linux switches and exchange IPv4 prefixes without having to configure an IPv4 address on each switch. In other words, the interfaces used by BGP are unnumbered, at least when it comes to IPv4. So next, let’s remove those interface IPv4 addresses and set up BGP unnumbered.
The BGP session with leaf01 and leaf02 will immediately drop and spine01 will remove the two prefixes it learned. Let’s verify this:
Next, we’ll reconfigure BGP to use the IPv6 link-local addresses of leaf01 and leaf02, instead of their IPv4 addresses.
There’s a new command we need to issue for each interface: the capability extended-nexthop command is what actually enables BGP Unnumbered:
We’ll do the same thing on leaf01:
Now let’s jump back to spine01 and see if we have a BGP session established with leaf01 and leaf02.
Notice that the Next Hop for each prefix is no longer an address, but an interface – swp1 and swp2. Let’s take a closer look at the RIB to see what these interfaces resolve to.
The next hop address for each prefix is an IPv6 link-local address, which is assigned automatically to each interface. By using the IPv6 link-local address as a next hop instead of an IPv4 unicast address, BGP Unnumbered saves you from having to configure IPv4 addresses on each interface!
Finally, the ultimate test is whether leaf01 and leaf02 have IP reachability to each other. Let’s run a traceroute from leaf01 to leaf02.
The packets move from leaf01 through spine01 and finally to leaf02. Even though spine01 has no interface IPv4 addresses configured, and even though each BGP session is running over IPv6, they’re all still able to exchange IPv4 routes and pass IPv4 traffic.
And that’s BGP Unnumbered.
Looking for more technical resources? Read all of our latest blogs here.