BGP ECMP Configuration: Cisco, Juniper and Arista

BGP Equal-Cost Multi-Path (ECMP) turns idle parallel links into active capacity: traffic spreads across multiple equal-cost paths, improving utilization and resilience. But every platform implements it differently, and small mistakes silently break load balancing. This tutorial covers BGP ECMP configuration on Cisco IOS, Juniper Junos and Arista EOS with the exact commands, the conditions a path must satisfy to be eligible, the hashing behaviour you are actually relying on, common pitfalls, and the operational habits that keep ECMP healthy.

Why BGP ECMP Matters

Without ECMP, BGP installs a single best path and all other equal-cost paths sit unused. With ECMP, the router installs multiple next-hops for the same prefix and load-balances across them — better resource utilization, faster convergence on link failure, and no wasted bandwidth on redundant uplinks.

The convergence argument is often more valuable than the capacity argument. When a router holds two ECMP next-hops for a prefix and one link fails, the forwarding entry simply loses that next-hop; the remaining path is already installed and no BGP update has to be processed before traffic resumes. Prefix-independent convergence, not raw throughput, is why ECMP shows up in tightly tuned data center and WAN designs. On the capacity side, the win depends entirely on how many distinct flows you have: ECMP balances flows, not bits, so a single elephant flow will not be split across paths on any mainstream platform unless per-packet load balancing is explicitly enabled.

What Makes Paths Equal Cost in BGP

A path becomes eligible for multipath only after the best-path algorithm has compared it against the winner and found no difference. In practice this means the following attributes must match on every candidate path:

• Weight and local preference — the first two tie-breakers, evaluated before anything platform-specific.
• AS_PATH length — paths with different AS_PATH lengths are not equal cost unless your platform has an explicit "multipath relax" option.
• Origin (IGP, EGP or incomplete), and the MED when comparing paths learned from the same neighbouring AS.
• eBGP versus iBGP — usually you cannot mix them into one ECMP set without additional-path support.
• The IGP metric to the next-hop, because BGP next-hops are resolved recursively. If one next-hop is three IGP hops away and another is two, their recursive best paths are not equal cost and the first will not be selected for multipath.
• Next-hop diversity — two paths that resolve to the same outgoing interface are not a multipath set, however many appear in show ip bgp.

Notice that AS_PATH length is in the list. That is the reason ECMP between two different upstream providers is not automatic: the two providers will normally advertise slightly different AS_PATH lengths, so only one path survives best-path selection. Cisco and Arista solve it with bgp bestpath as-path multipath-relax, Juniper with multipath multiple-as, both discussed below.

Cisco: maximum-paths in the BGP Process

router bgp YOUR-ASN
 neighbor 192.168.1.1 remote-as 100
 neighbor 192.168.1.2 remote-as 100
 maximum-paths 4

After configuring neighbors, maximum-paths 4 allows up to four parallel paths. Tune the number to your hardware's ECMP capability and network requirements.

Two adjustments are worth knowing. First, maximum-paths ibgp 4 raises the limit for iBGP-learned prefixes — the eBGP and iBGP limits are separate. Second, on modern IOS and IOS-XE you can relax the AS_PATH comparison so that paths from different neighbouring ASes with the same AS_PATH length are still considered multipath candidates:

router bgp 65001
 bgp router-id 10.0.0.1
 no bgp default ipv4-unicast
 neighbor 192.0.2.1 remote-as 65010
 neighbor 192.0.2.2 remote-as 65020
 address-family ipv4 unicast
  neighbor 192.0.2.1 activate
  neighbor 192.0.2.2 activate
  maximum-paths 4
  maximum-paths ibgp 4
  bgp bestpath as-path multipath-relax

Cisco load-balances in CEF, not in BGP, so verify in the FIB. Platform hash behaviour is tunable with ip cef load-sharing algorithm (universal, original, tunnel, or a numbered variant) — useful when two routers in the same path hash identically and produce polarized, unbalanced traffic:

show ip bgp 203.0.113.0/24
show ip route 203.0.113.0
show ip cef 203.0.113.0 detail
show ip cef exact-route 10.1.1.1 203.0.113.10

show ip bgp proves the paths are marked valid and best with multiple next-hops. show ip cef exact-route is the honest test: it tells you which next-hop a given source/destination pair would use, so you can walk several source ports and confirm the traffic really is spread.

Juniper: Policy-Driven Load Balancing

set routing-options forwarding-table export ECMP-RULE
set policy-options policy-statement ECMP-RULE term 1 from protocol bgp
set policy-options policy-statement ECMP-RULE term 1 then load-balance per-packet

Junos does not have a simple maximum-paths knob — ECMP is driven by a forwarding-table export policy that matches BGP routes and applies load balancing. Apply it per routing instance/VRF where needed.

Junos additionally gates multipath eligibility inside the BGP session configuration. iBGP-learned prefixes form ECMP sets when the attributes tie, but for eBGP you must tell the protocol that paths from different neighbouring autonomous systems may be treated as equal cost:

set protocols bgp group EBGP type external
set protocols bgp group EBGP peer-as 65010
set protocols bgp group EBGP neighbor 192.0.2.1
set protocols bgp group EBGP multipath multiple-as
set protocols bgp group EBGP neighbor 192.0.2.2
set protocols bgp group EBGP multipath multiple-as

For routes that come from protocols with no native multipath support — static routes, aggregates, some LDP/RSVP-derived entries — you can allow multipath with a policy attached at routing-options multipath. And because the forwarding path, not the routing table, does the hashing, widen the hash input where the platform supports it: on MX-class hardware with forwarding-options hash-key family inet layer-4, and on QFX switches with the enhanced hash key settings, so that TCP/UDP ports participate in the flow hash instead of only source and destination address.

show route 203.0.113.0/24 detail
show route 203.0.113.0/24 extensive
show route forwarding-table destination 203.0.113.0/24

The forwarding-table command is the definitive check: it lists one entry per usable next-hop for the prefix. A route that shows two paths in show route but one next-hop in the forwarding table is not load-balancing, whatever the routing table says.

Arista: maximum-paths with ECMP Tuning

configure terminal
router bgp YOUR-ASN
 neighbor IP-ADDRESS remote-as PEER-ASN
 maximum-paths 4

EOS supports the same maximum-paths command plus deep ECMP control: bgp bestpath ecmp-fast (ignore arrival order in ECMP evaluation), tie-breakers like bgp bestpath tie-break router-id, and rib fib fec ecmp ordered for deterministic next-hop ordering. Verify with show ip bgp — ECMP paths are marked ECMP head / ECMP contributor.

A complete edge example also relaxes the AS_PATH comparison, because in most EOS deployments the two ECMP paths come from two different transit providers:

router bgp 64500
   router-id 10.0.0.1
   maximum-paths 8
   bgp bestpath as-path multipath-relax
   bgp bestpath ecmp-fast
   bgp bestpath tie-break router-id
   neighbor PG-TRANSIT peer group
   neighbor PG-TRANSIT remote-as 65010
   neighbor 192.0.2.1 peer group PG-TRANSIT
   neighbor 192.0.2.2 remote-as 65020
   neighbor 192.0.2.2 peer group PG-TRANSIT
   !
   address-family ipv4
      neighbor PG-TRANSIT activate

Before you raise maximum-paths to a large number, check what the hardware can actually programme: many fixed-form switches store ECMP next-hop sets in a FEC table with a per-prefix width limit, and exceeding it makes the platform fall back to fewer paths or to a shared group, which is invisible in the BGP table but very visible in traffic graphs. Test with the real prefix and confirm with show ip route that all intended next-hops are present.

How ECMP Behaves in Practice

Once the FIB holds several next-hops, distribution is decided by a hash of packet header fields — a flow hash, not a per-packet round robin. Five things routinely break the picture:

• Flow granularity. Two heavy flows that hash to the same bucket land on the same link; ten thousand small flows balance beautifully. Utilization skew of 20–30% between "equal" links is normal on flow-hashed ECMP.
• Hash polarization. If two routers in series use the same algorithm over the same header fields, the second router's hash correlates with the first and traffic that arrived on two links can leave on one. Change the hash seed or algorithm on one of them (ip cef load-sharing algorithm universal with a different ID on Cisco, per-platform hash settings elsewhere).
• Missing layer-4 information. Fragments after the first carry no TCP/UDP header; loops and tunnels can hide them. The result is one bucket taking all fragment traffic.
• Encapsulation. With VXLAN, GRE or MPLS the outer header may be the only thing hashed, so every flow between two VTEPs uses one link unless the platform supports inner-header hashing.
• Asymmetric return paths. ECMP is per-direction and per-prefix; the return traffic may take a completely different set of links, which matters for firewalls and stateful devices in the path.

Verification: Prove the Traffic Is Spread

Configuration is only half the job; ECMP fails silently when a policy or a hardware limit drops a path. Run this checklist after every change:

# Cisco
show ip bgp 203.0.113.0/24
show ip cef 203.0.113.0 internal
show ip cef exact-route 10.1.1.1 203.0.113.10

# Juniper
show route forwarding-table destination 203.0.113.0/24
show route 203.0.113.0/24 extensive

# Arista
show ip bgp 203.0.113.0/24
show ip route 203.0.113.0/24

Then compare interface counters and, better, per-flow telemetry (NetFlow/IPFIX, sFlow, or streaming telemetry) across the member links. If one link carries everything, the fault is almost always one of: no multipath policy, unequal IGP cost to the next-hop, unequal MED/AS_PATH, or a hardware ECMP limit.

Common Mistakes and Best Practices

• Inconsistent routing policies across paths cause asymmetric routing or flapping — keep policies uniform.
• Verify ECMP at the forwarding level, not just the BGP table; a missing load-balance policy on Junos leaves all traffic on one path.
• Document configurations and audit regularly; ECMP breaks subtly during firmware upgrades if capabilities change.
• Monitor per-path utilization — imbalance usually signals a hash or policy issue.
• Forgetting the AS_PATH relaxation: without multipath-relax on IOS/EOS or multipath multiple-as on Junos, two paths from different providers will never be equal cost, no matter what maximum-paths says.
• Assuming the IGP metric to each next-hop is equal. Check the recursive resolution explicitly — an unequal IGP cost silently reduces the ECMP set to one path.
• Raising maximum-paths past the platform's hardware FEC width, which falls back without a warning in the BGP table.
• Leaving bgp deterministic-med out of your standard template when comparing paths from the same AS, then wondering why MED ordering (and therefore the multipath set) changes on every reload.

For adjacent topics see BGP neighbor flapping root causes, BGP in EVPN data center fabrics, BGP additional-path advertisement and the Arista EOS troubleshooting cookbook.

原文链接：https://netseccloud.com/configuring-bgp-ecmp-step-by-step-tutorial