Explainer October 3, 2026 BGPFabric design

BGP unnumbered, explained without the hand-waving

How leaf-spine fabrics run BGP over links with no IPv4 addresses, why AI back-ends rely on it, and what actually happens in the routing table.

A 2,048-GPU back-end has more than two thousand leaf-to-spine links. Give each one a /31 and you have thousands of subnets to plan, configure on both ends, document and keep correct forever. BGP unnumbered makes all of them disappear.

The picture first

Think of two neighbors talking over a garden fence. They never exchange postal addresses; they don’t need to. The fence is the link, and the voice over it is the IPv6 link-local address every interface creates automatically.

What actually happens

Four standard mechanisms combine:

  1. Link-local addresses. Every IPv6-enabled interface has an fe80:: address, unique on that link, with zero configuration.
  2. Router advertisements. Each side learns its neighbor’s link-local address and MAC address.
  3. A BGP session over link-local. Because the switch discovered its peer, the configuration needs only the interface name.
  4. IPv4 routes with an IPv6 next hop. The extended next-hop capability (RFC 8950, which replaced RFC 5549) lets BGP advertise IPv4 prefixes whose next hop is the peer’s IPv6 link-local address.

The Linux kernel cannot use an IPv6 address as the next hop of an IPv4 route, so FRR installs the route with a placeholder next hop, 169.254.0.1, marked onlink on the interface, plus a permanent neighbor entry that maps it to the peer’s MAC address. Forwarding works exactly as if a real next hop existed.

Configuration on Cumulus Linux

nv set vrf default router bgp neighbor swp51 remote-as external
nv set vrf default router bgp neighbor swp52 remote-as external
nv config apply

Verify:

sudo vtysh -c "show bgp summary"            # neighbors listed by interface
sudo vtysh -c "show bgp neighbors swp51"    # extended next hop capability
ip route show 10.10.10.2                    # via 169.254.0.1 dev swp51 ... onlink

Why AI fabrics love it

  • No address planning for thousands of fabric links.
  • Identical configuration on every switch, which makes templates simpler and generated configurations safer.
  • Cabling mistakes don’t create address mismatches, because there are no addresses to mismatch.

The limits

Unnumbered peering is for directly connected neighbors. Sessions to route reflectors or firewalls several hops away still need real addresses. IPv6 must be enabled on the fabric interfaces, and troubleshooting shifts from addresses to interface names, so LLDP becomes your best friend.

Design principle: remove whole categories of configuration rather than managing them carefully. Every value that does not exist is a value that cannot be wrong.

Configurations are illustrative; validate them in a lab against the documentation for your software release.

Want to go deeper?

Download the free sample of Building the AI Factory: the opening chapter, the CCDE Practical decision checklist and the CCDE AI Infrastructure topic map.