The Cisco maximum-paths command determines how many eligible equal-cost routes a routing protocol may install for the same destination. It is the control-plane permission that allows multiple next hops to reach the routing table and forwarding table. It does not independently decide whether traffic is distributed per session, per flow, or per packet. That forwarding decision is normally performed by Cisco Express Forwarding, or CEF.
The short answer
In a Cisco environment, the following command does not mean that every route automatically uses two paths:
maximum-paths 2
It means:
For a destination that has multiple paths meeting the routing protocol’s multipath eligibility rules, install as many as two of those paths into the routing table and forwarding table.
Likewise:
maximum-paths 4
allows as many as four eligible paths to be installed.
The command is therefore a maximum, not a guarantee. If only one path qualifies, only one path is installed. If six paths qualify and the command is set to four, only four can be installed for that prefix.
The control plane and data plane have different jobs
BGP, OSPF, EIGRP, IS-IS, or static routing
Subject to metric, path attributes, and maximum-paths
The routing table represents the usable paths
A hash maps traffic to one of the installed next hops
| Component | Primary responsibility | What it does not decide |
|---|---|---|
| Routing protocol | Learns routes, compares candidates, and identifies eligible paths | Which individual production packet uses which path |
| maximum-paths | Limits how many eligible paths may be installed | The hashing fields or forwarding algorithm |
| RIB | Maintains the selected routing entries and next hops | High-speed packet switching |
| CEF and hardware forwarding | Programs the forwarding state and maps traffic to next hops | Whether a BGP path qualifies as a multipath |
What changes between maximum-paths 2 and maximum-paths 4?
The number changes the largest ECMP set the routing process may install for a destination.
Increasing the value does not automatically increase throughput. Additional paths provide more forwarding choices only when:
- The routing protocol has multiple qualifying paths
- The platform supports the requested ECMP width
- The routes resolve to usable and distinct next hops
- The traffic contains enough independent flows to spread across those next hops
- No policy or path attribute makes the routes unequal
Is Cisco ECMP per session, per flow, or per packet?
In most modern Cisco enterprise deployments, ECMP forwarding is per flow. The forwarding hardware calculates a deterministic hash from selected packet-header fields and maps the resulting hash to one member of the ECMP set.
The exact fields depend on the platform, software release, address family, tunnel type, and configured load-balancing mode. Common inputs include:
- Source IP address
- Destination IP address
- IP protocol
- Source transport port
- Destination transport port
- Additional entropy from labels, tunnel fields, or inner headers when supported
- A platform-specific or device-specific hash seed
Practical interpretation: packets belonging to the same TCP or UDP conversation normally remain on the same next hop, while different conversations may be assigned to different next hops.
What does “per session” really mean?
Engineers often say that ECMP is “per session.” That is generally acceptable shorthand, but per flow is more precise.
A routing platform does not usually understand an application session in the same way that a stateful firewall does. Instead, it identifies a flow through header fields such as the source and destination addresses, protocol, and transport ports.
Example TCP flow Source IP: 10.10.10.25 Destination IP: 172.16.50.20 Protocol: TCP Source port: 51842 Destination port: 443 Hash result ---> ECMP path 2
Every packet with the same relevant tuple normally produces the same hash result and follows the same path while the ECMP set remains unchanged.
Why per-flow forwarding is normally preferred
Per-flow forwarding helps preserve packet order. This is important because parallel links can have different queue depth, serialization delay, congestion, and latency.
If consecutive packets from the same TCP flow are sprayed across multiple paths, they can arrive out of order. The receiver may generate duplicate acknowledgments, TCP may infer packet loss, and performance can degrade even when no packet was actually dropped.
Does Cisco support per-packet load sharing?
Some Cisco software and platforms support a CEF per-packet load-sharing mode. In classic Cisco documentation, per-packet CEF load sharing uses a round-robin approach that sends successive packets over different paths.
That does not make per-packet forwarding the standard enterprise recommendation. It is generally avoided across paths that can differ in latency or congestion because packet reordering may be more damaging than an uneven traffic split.
Do not assume the same command, behavior, or hardware support across IOS, IOS-XE, NX-OS, Catalyst ASICs, and Cisco router forwarding platforms. Verify the exact platform and release before attempting to change the forwarding mode.
How the hashing algorithm works
The platform combines selected header fields into a hash input. The hash function produces a value, and that value is mapped into an ECMP bucket or next-hop group.
Packet header fields
source IP + destination IP + protocol + ports
|
v
Hash calculation
|
v
ECMP bucket selection
|
+-------------+-------------+
| | |
v v v
Path 1 Path 2 Path 3 ...
The exact proprietary implementation can differ, but the operational goals are consistent:
- Keep packets from the same flow on one path
- Distribute different flows across available next hops
- Perform the decision efficiently in hardware
- Avoid every router producing identical polarization patterns where possible
Universal hashing and polarization
Cisco platforms have historically used variations of CEF load-balancing algorithms, including a universal algorithm that incorporates a router-specific value or seed. The purpose is to reduce traffic polarization, where several routers repeatedly hash the same flows onto the same relative links.
Consider a leaf-spine fabric in which each hop has four equal paths. If every router used identical input fields and an identical hash function with no device-specific variation, a flow assigned to link 1 at one layer could repeatedly be assigned to link 1 at the next layer. That can concentrate traffic even though several links exist.
A device-specific seed helps different forwarding devices make different bucket assignments for the same flow.
Why traffic is rarely a perfect 50/50 or 25/25/25/25
There is no universal pass/fail utilization percentage. A 30/70 split may also be legitimate when the traffic population contains only a few flows or one dominant elephant flow. Evaluate the number, size, and duration of flows before treating unequal link counters as a fault.
ECMP hashes flows, not bytes. Flows are not equal in size or duration.
| Traffic pattern | Likely result |
|---|---|
| Thousands of similar flows | Distribution may approach the expected ratio over time |
| A few large elephant flows | One path may carry substantially more traffic than another |
| One large TCP transfer | The transfer normally uses one ECMP path |
| Many short web transactions | Each connection may hash independently, producing better aggregate spread |
| Limited hash fields | Flows sharing the same address pair may concentrate on one path |
Two equal 10 Gbps paths provide 20 Gbps of aggregate forwarding capacity, but they do not normally provide a single ordinary TCP flow with 20 Gbps of throughput.
BGP maximum-paths
BGP installs one best path by default in many Cisco implementations. The BGP maximum-paths command permits additional eligible BGP paths to be installed for multipath forwarding.
router bgp 65000 address-family ipv4 maximum-paths 2
In a typical IOS-XE BGP context, this commonly enables as many as two eligible eBGP paths for a prefix. iBGP and mixed eBGP/iBGP multipath behavior may require different command forms or additional features depending on the software and design.
BGP still chooses one best path
Multipath does not eliminate the BGP best-path process. Cisco BGP still identifies one path as the best path for protocol purposes, including advertisement behavior. Additional qualifying paths may then be installed alongside it for forwarding.
BGP table Path A: best, multipath Path B: multipath Path C: valid but not multipath Routing table and CEF Next hop A Next hop B
This distinction matters during troubleshooting. Seeing several paths in the BGP table does not prove that all of them are installed in the RIB or used by CEF.
What makes BGP paths eligible for multipath?
Related but separate feature: When candidate eBGP routes have different AS-path sequences, bgp bestpath as-path multipath-relax may be required before they can qualify. That command changes BGP path eligibility; it does not control the number of installed paths or the CEF hashing behavior discussed in this article.
The exact rules depend on platform, release, address family, and configured BGP features. At a high level, candidate paths generally need to be equivalent through the relevant stages of the BGP best-path comparison.
Common attributes that can prevent two paths from becoming multipaths include:
- Different weight
- Different local preference
- Different locally originated status
- Different AS path length
- Different origin code
- Different MED where MED is compared
- Different path type or unsupported eBGP/iBGP combination
- Unresolvable or unusable next hop
- Policy that intentionally makes one path more preferred
The paths do not necessarily need identical next-hop IP addresses. In fact, usable ECMP normally requires distinct forwarding next hops.
OSPF maximum-paths
OSPF calculates shortest paths using interface cost. When several next hops provide the same total OSPF cost to a destination, OSPF can install multiple equal-cost routes up to the configured maximum.
router ospf 100 maximum-paths 4
For OSPF, the command does not cause unequal-cost paths to become equal. The paths must already have the same calculated cost.
EIGRP and unequal-cost load sharing
EIGRP is different because it can support unequal-cost load sharing with the variance command, subject to EIGRP feasibility requirements. The maximum-paths value still limits the number of installed paths, while variance controls which feasible unequal-metric paths may qualify.
router eigrp 100 maximum-paths 4 variance 2
This does not mean BGP or OSPF automatically gain unequal-cost forwarding by using the same syntax. Protocol behavior is distinct.
What happens when one ECMP path fails?
When an installed path becomes unusable, the routing protocol, next-hop tracking process, BFD session, physical interface state, or another detection mechanism removes that path from the routing and forwarding state.
Flows that were already mapped to surviving paths may remain there. Flows mapped to the failed path must be redirected. Depending on the platform and resilient hashing capabilities, removing one member may cause limited or broader flow remapping.
Traditional hashing versus resilient hashing
With a simple modulo-based scheme, changing the number of available next hops can cause many hash results to map differently. That means flows using healthy paths may also move after one member is removed.
Platforms that support resilient hashing attempt to preserve existing flow-to-member assignments and remap primarily the flows associated with the failed member. This reduces unnecessary disruption and packet reordering.
The feature name, availability, defaults, and limits vary across Cisco product families. Nexus data center platforms, Catalyst switches, and IOS-XE routers should not be assumed to behave identically.
Does maximum-paths provide active-active forwarding?
It can, but only when multiple paths are actually eligible and installed.
| Routing state | Forwarding result |
|---|---|
| Two equal paths, maximum-paths 2 | Both can be active forwarding next hops |
| Two unequal paths, maximum-paths 2 | Normally only the preferred path is installed for ECMP |
| Four equal paths, maximum-paths 2 | Only two can be installed as multipaths |
| Four equal paths, maximum-paths 4 | All four can be active if the platform and protocol support them |
Does increasing maximum-paths make convergence faster?
Not by itself.
The command can improve availability because alternate paths are already installed and available for forwarding. However, actual convergence time depends on:
- Physical link-state detection
- BFD timers and behavior
- BGP, OSPF, EIGRP, or IS-IS failure detection
- Next-hop tracking
- RIB and FIB update time
- Hardware ECMP group programming
- PIC or fast-reroute capabilities
- Upstream and downstream convergence
An already-installed ECMP path can reduce the amount of route calculation required after a failure, but maximum-paths should not be confused with BFD, Prefix Independent Convergence, or an IP fast-reroute feature.
Common BGP examples
Two eBGP paths
router bgp 65000 neighbor 192.0.2.1 remote-as 65100 neighbor 192.0.2.5 remote-as 65100 ! address-family ipv4 neighbor 192.0.2.1 activate neighbor 192.0.2.5 activate maximum-paths 2
iBGP multipath
router bgp 65000 address-family ipv4 maximum-paths ibgp 2
Syntax and support vary. On some Cisco operating systems, address families, and newer feature implementations, the available command forms differ. Always use the command reference for the exact platform and release.
How to verify the routing table
The routing table should show multiple next hops for the same prefix.
show ip route 203.0.113.0 Routing entry for 203.0.113.0/24 Known via "bgp 65000" * 192.0.2.1 * 192.0.2.5
Depending on platform and release, useful commands include:
show ip route <prefix>show ip route bgpshow bgp ipv4 unicast <prefix>show bgp ipv4 unicastshow ip cef <prefix> detailshow ip cef exact-route <source> <destination>- Platform-specific hardware forwarding and ECMP-group commands
How to verify the CEF path for a flow
On supported IOS or IOS-XE platforms, show ip cef exact-route can help determine the next hop selected for a source and destination pair.
show ip cef exact-route 10.10.10.25 172.16.50.20
This is useful, but it may not reproduce every hardware hash field. A platform using Layer 4 ports, tunnel entropy, or ASIC-specific fields may require platform-specific commands or traffic testing for complete validation.
How to test ECMP correctly
A single ping, traceroute, or TCP session is not enough to prove ECMP distribution.
A stronger validation uses:
- Many independent source and destination pairs
- Multiple TCP or UDP source ports
- Interface counters collected over the same test window
- Flow telemetry such as NetFlow or IPFIX
- CEF and hardware forwarding verification
- A controlled failure of one member
- Application continuity and packet-loss measurement during convergence
For throughput tests, multiple parallel iPerf streams are more likely to exercise multiple ECMP paths than one stream:
iperf3 -c 172.16.50.20 -P 8 -t 60
Even with eight streams, the hash can place several streams on the same path. The test increases flow diversity but does not guarantee an even assignment.
Common misconceptions
When maximum-paths 2 is appropriate
- Two equivalent WAN or cloud connections should be active simultaneously
- Two routed uplinks connect a distribution switch to the core
- A router has two equivalent eBGP peers toward the same routing domain
- The design requires dual-path redundancy without installing additional candidates
- The platform or topology naturally provides only two independent next hops
When maximum-paths 4 is appropriate
- A leaf switch has four equal-cost spine next hops
- A WAN edge has four policy-equivalent paths to the same destination set
- A data center fabric is designed for four-way ECMP
- Four cloud or provider adjacencies are intentionally equal
- Capacity planning and flow diversity justify using all four paths
When not to use all available paths
Not every physical connection should be active ECMP.
A path should generally remain outside the ECMP set when it has:
- Meaningfully different latency
- Lower bandwidth that the platform cannot weight appropriately
- Higher cost or metered usage
- A less trusted provider or failure domain
- Different security inspection behavior
- Asymmetric-routing consequences
- Different MTU or fragmentation behavior
- A policy role intended only for backup
In those cases, local preference, metric, AS-path prepending, administrative distance, route policy, or another design mechanism should maintain the intended primary and backup relationship.
Design checklist
| Area | Validate |
|---|---|
| Protocol eligibility | Metrics, BGP attributes, next-hop resolution, and multipath rules |
| Platform scale | Maximum ECMP width, FIB scale, adjacency scale, and hardware limitations |
| Hash inputs | Layer 3, Layer 4, tunnel, label, and inner-header support |
| Path equivalence | Bandwidth, latency, MTU, security services, and policy |
| Failure detection | Interface state, BFD, protocol timers, next-hop tracking, and upstream convergence |
| Flow behavior | Elephant flows, traffic diversity, polarization, and expected imbalance |
| Operations | Per-link monitoring, telemetry, alerting, test method, and rollback |
Recommended implementation sequence
The conclusion
The Cisco maximum-paths command is often misunderstood because it appears to be a load-balancing command. More precisely, it is a routing control that defines how many eligible paths may be installed for a destination.
The complete forwarding process is:
Routing protocol learns multiple paths
|
v
Best-path and multipath rules determine eligibility
|
v
maximum-paths limits how many may be installed
|
v
RIB and FIB contain multiple next hops
|
v
CEF hashes each flow onto one next hop
maximum-paths 2 permits as many as two eligible forwarding paths. maximum-paths 4 permits as many as four. Neither command guarantees equal utilization, combines link bandwidth for one ordinary flow, changes unequal routes into equal routes, or determines the failure-detection timer.
In most enterprise Cisco designs, CEF distributes traffic per flow rather than per packet. This preserves packet order and provides stable application forwarding, but it also means that link utilization may be uneven when the traffic consists of a small number of large flows.
The command enables path diversity; CEF turns that diversity into forwarding. A successful ECMP design therefore depends on correct route eligibility, appropriate hash behavior, equivalent paths, sufficient flow diversity, fast failure detection, hardware support, and disciplined verification of the RIB and FIB.
References
- Cisco IOS-XE 17.x IP Routing Configuration Guide: BGP Multipath
- Cisco: BGP Multipath Load Sharing for eBGP and iBGP
- Cisco Express Forwarding Load-Balancing Configuration Guide
- Cisco Nexus 9000 NX-OS 10.5(x): BGP and ECMP
- Cisco IOS BGP Command Reference: maximum-paths
// qualify the routes. install the next hops. hash the flows. verify the forwarding.