BGP unnumbered is one of those data-center fabric features that looks almost too simple when it works: no per-link IPv4 addressing, a repeatable interface template, and eBGP sessions built over IPv6 link-local addresses. The operational catch is that the failure mode moves from “is this /31 correct?” to “is neighbor discovery, peer discovery, policy and next-hop resolution all aligned?”
This post is a practical checklist for building and troubleshooting a small leaf-spine fabric with BGP unnumbered. It is vendor-neutral in structure, with sample commands shown as patterns rather than copy-paste production configuration.
Related reading hubs: Start Here, Data Center Networking, BGP Table Watch, and AI Infrastructure & Automation.
The problem: BGP unnumbered reduces addressing, but hides different mistakes
Traditional routed fabrics use a small IPv4 subnet on every leaf-spine link. That is easy to reason about, but it creates allocation overhead and config drift: wrong /31, duplicate address, stale documentation, or a link patched to a different spine than expected.
BGP unnumbered removes most of that address management. Each routed interface forms a BGP adjacency using IPv6 link-local addressing while still advertising IPv4 and/or IPv6 prefixes. This is excellent for repeatable leaf-spine builds, especially in GPU, storage and virtualization fabrics where racks are added frequently.
The trade-off: your first troubleshooting question is no longer only “can I ping the peer IPv4 address?” You need a disciplined bottom-up workflow.
Design baseline: what must be consistent
1. Stable loopbacks and router IDs
Every switch still needs a stable loopback for the router ID, management reachability and overlay/control-plane anchoring. Keep loopback addressing documented and predictable even if fabric links are unnumbered.
spine1 loopback0 10.255.0.1/32
spine2 loopback0 10.255.0.2/32
leaf1 loopback0 10.255.1.1/32
leaf2 loopback0 10.255.1.2/322. A repeatable interface profile
Use one profile for leaf-spine routed ports: routed mode, MTU, FEC, LLDP, BGP discovery and telemetry tags. Avoid mixing one-off interface tweaks with generated configuration.
interface EthernetX/Y
description FABRIC uplink to spine
no switchport
mtu 9216
ipv6 enable
bgp unnumbered peer-group FABRIC-SPINES
lldp transmit
lldp receive3. Explicit routing policy
Unnumbered peering does not remove the need for policy. Advertise loopbacks, connected rack prefixes and service prefixes intentionally. Filter what should never leave a rack.
router bgp 65101
router-id 10.255.1.1
neighbor FABRIC-SPINES peer-group
neighbor FABRIC-SPINES remote-as external
address-family ipv4 unicast
network 10.255.1.1/32
redistribute connected route-map RACK-PREFIXES-ONLYImplementation workflow: build it in layers
- Cable and label first. Validate LLDP neighbors before worrying about BGP.
- Apply the same routed-port template to every leaf-spine interface.
- Bring up BGP discovery with minimal policy, then add import/export controls.
- Advertise loopbacks before rack networks. A missing loopback is an early signal that route policy is wrong.
- Check ECMP width from every leaf. A three-leaf/two-spine lab should not show a single path unless you intentionally constrained it.
Verification commands that catch most issues
Layer 1 and cabling
show interfaces status
show interfaces counters errors
show lldp neighbors
show interface EthernetX/Y transceiver detailsIf LLDP says a leaf uplink points to the wrong spine or wrong port, fix cabling or the source-of-truth first. BGP can still come up in a mis-cabled fabric, but the topology will not match your failure-domain assumptions.
IPv6 link-local and discovery
show ipv6 interface brief
show ipv6 neighbors
show bgp summary
show bgp neighbors interface EthernetX/YFor BGP unnumbered, the peer address may appear as a link-local IPv6 address with an interface scope. That is normal. What is not normal: no IPv6 link-local on the routed port, repeated neighbor flaps, or a peer associated with the wrong physical interface.
Routes and next hops
show bgp ipv4 unicast
show ip route 10.255.0.0/16
show ip route rack-prefix longer-prefixes
show forwarding route rack-prefix
traceroute source loopback0 destination-rack-ipDo not stop at “BGP is Established.” Confirm that routes are accepted, installed in the RIB/FIB and load-shared across the expected uplinks.
Troubleshooting: symptom to likely cause
| Symptom | Likely cause | First checks |
|---|---|---|
| No BGP neighbor at all | Interface down, no IPv6 LL, discovery not bound | Interface status, IPv6 interface, LLDP |
| Neighbor Active/Idle | ASN mismatch, peer-group issue, auth/timer mismatch | BGP neighbor detail, config diff |
| Established but no IPv4 routes | AFI not activated or route-map blocks prefixes | BGP AFI, received-routes, policy counters |
| Routes exist but traffic drops | FIB/ECMP, MTU, ACL, bad optic path | Forwarding table, counters, path-specific ping |
AI-assisted network automation angle
BGP unnumbered is a good candidate for AI-assisted checks because the desired state is highly patterned. A small validation job can compare source-of-truth intent, LLDP, BGP neighbors and route counts, then summarize likely failure domains for an engineer.
Validation inputs:
- expected fabric links from source of truth
- live LLDP neighbors
- BGP summary and neighbor detail
- route counts per leaf and per address-family
- interface error counters and MTU/FEC state
Useful output:
- links patched differently than intent
- ports with link-local but no BGP session
- peers established but receiving zero prefixes
- leaves with reduced ECMP widthThe important guardrail: let automation highlight evidence and propose the next check, not silently “fix” BGP policy in production. For more on this style of guarded workflow, see the AI Infrastructure & Automation hub and the Resources page.
Practical takeaways
- BGP unnumbered simplifies IP allocation, but it does not simplify operational discipline.
- Verify in order: physical link, LLDP, IPv6 link-local, BGP session, received routes, installed routes, forwarding path.
- Keep loopbacks and route policy explicit. Unnumbered fabric links are not an excuse for undocumented control-plane design.
- For AI/GPU or storage fabrics, test MTU, FEC and ECMP with real traffic, not only control-plane commands.
- Use automation to detect drift: cabling mismatches, missing peer-group binding, zero-prefix sessions and reduced ECMP width.
Post a Comment