eBGP Underlay ECMP Collapse After OSPF Migration
After migrating a 16-leaf, 4-spine fabric from OSPF to eBGP, remote VTEP loopback reachability works but ECMP has collapsed. Each leaf has four equal-cost underlay paths to every remote leaf loopback, but show route 10.255.0.22/32 on leaf1 lists only one next-hop via spine2. The underlay uses eBGP: spine1 AS 65001, spine2 AS 65002, spine3 AS 65003, spine4 AS 65004; each leaf has a unique AS 65101-65116. The overlay is iBGP with the four spines acting as route reflectors in AS 65000. BFD is enabled on all underlay sessions, and all sessions are up. The design requires active-active forwarding across all spines for overlay traffic. A recent change added multipath under protocols bgp but did not change the result.
1. Explain why the underlay RIB may have four paths but only one is installed.
Read the worked answer
Junos will not install eBGP paths from different neighboring ASes as equal-cost next-hops unless multipath multiple-as is configured. The leaf sees four paths to 10.255.0.22/32, but their AS_PATHs differ because each spine uses a different AS: 65001 65122, 65002 65122, and so on. With only multipath, BGP may still treat them as non-equal because the first AS differs. The RIB can therefore show one best path, or show multiple paths that are not eligible for forwarding.
Check show route 10.255.0.22/32 detail for the path list and show configuration protocols bgp for multipath multiple-as. Also verify that the underlay group has family inet unicast and that no export policy is filtering the loopback. If show route forwarding-table destination 10.255.0.22/32 shows one next-hop, the control plane has not produced ECMP.
2. What is the effect on overlay traffic if underlay ECMP is broken, and why does overlay still work?
Read the worked answer
Overlay iBGP with spines as route reflectors preserves the remote leaf loopback as the next-hop, so VXLAN traffic recurses to the underlay route for that loopback. If the underlay installs only one path, all traffic to that VTEP uses one spine, creating a hot spot and losing resiliency, but the overlay still works because one path is enough for reachability. This is why pings and EVPN sessions stay up while performance and failover are degraded.
The spines are route reflectors for the control plane; data-plane traffic follows the underlay ECMP to the remote leaf. If the overlay were eBGP and the spines changed next-hop, the analysis would be different, but here the next-hop is unchanged. The fix must be in the underlay BGP multipath policy, not in EVPN.
3. Provide configuration and verification steps to restore ECMP without changing the ASN design.
Read the worked answer
Add multipath multiple-as to the underlay BGP configuration on every leaf, for example:
set protocols bgp group UNDERLAY multipath multiple-as
If the design uses a common spine AS, multipath alone is sufficient; with unique spine ASNs, multiple-as is required. Do not change the ASN plan just to avoid the knob.
After committing, clear the BGP sessions or wait for route refresh, then verify:
show route 10.255.0.22/32should list four next-hops and showMultipath.show route forwarding-table destination 10.255.0.22/32should show multiple next-hops.show bgp neighborshould confirm multipath support.
If paths still do not install, check for an export policy that sets a different local preference or MED on some spines, and remove it.