Cisco BGP normally selects one best path for each prefix. Even when multiple routes have the same local preference, AS-path length, origin, MED, and other major attributes, BGP may refuse to install them as equal-cost paths when their actual AS sequences are different. The command bgp bestpath as-path multipath-relax changes that specific multipath eligibility rule.
The short answer
Where this command fits
bgp bestpath as-path multipath-relax changes only one BGP control-plane rule: whether otherwise-compatible paths with different but equal-length AS sequences may be treated as multipath candidates.
| Function | Responsible feature |
|---|---|
| Permit different equal-length AS sequences to qualify | bgp bestpath as-path multipath-relax |
| Set how many eligible routes may be installed | maximum-paths, covered separately |
| Distribute traffic across installed next hops | CEF and platform forwarding behavior, covered separately |
This article stops at BGP path eligibility. It does not use multipath relax to explain hashing, link percentages, per-flow forwarding, or ECMP utilization.
bgp bestpath as-path multipath-relax allows Cisco BGP to consider paths with different AS-path contents as multipath candidates when their AS-path lengths are equal and the other required BGP attributes are compatible.
It is commonly used when a router learns the same prefix from different external autonomous systems and you want both routes installed for ECMP.
ISP A path: 64510 64496 ISP B path: 64520 64496 Both paths contain two AS hops. The AS sequences are different. Default behavior: One path is normally selected for forwarding. With multipath relax and maximum-paths 2: Both paths may be installed as BGP multipaths.
The command relaxes the AS-path equality requirement for multipath selection. It does not disable the BGP best-path algorithm, ignore AS-path length, remove loop prevention, or automatically guarantee that multiple paths will be installed.
What problem does the command solve?
Assume an enterprise router receives the same destination from two providers:
Enterprise router AS 65000 Provider A: AS 64510 Provider B: AS 64520 Prefix 203.0.113.0/24 arrives as: Path A: 64510 64496 Path B: 64520 64496
The paths may match on:
- Weight
- Local preference
- Locally originated status
- AS-path length
- Origin code
- MED, where applicable
- eBGP versus iBGP status
- Reachable next hop
However, the complete AS sequences are not identical. One route traverses AS 64510 and the other traverses AS 64520. Under traditional BGP multipath rules, this difference may prevent both routes from being installed as equal paths.
Multipath relax permits BGP to treat the equal-length AS paths as multipath candidates despite their different AS numbers.
Default behavior versus relaxed behavior
| Condition | Default multipath behavior | With multipath relax |
|---|---|---|
Same AS sequence64510 6449664510 64496 |
Can qualify if other attributes match | Can qualify |
Different AS sequence, same length64510 6449664520 64496 |
Normally not accepted as equivalent multipaths | May qualify if other requirements match |
Different AS-path length64510 6449664520 64530 64496 |
Shorter path wins | Shorter path still wins |
| Different local preference | Higher local preference wins | Higher local preference still wins |
| Different weight | Higher weight wins | Higher weight still wins |
The command does not ignore AS-path length
This is the most important misconception to eliminate.
Path A: 64510 64496 AS-path length: 2 Path B: 64520 64530 64496 AS-path length: 3
Multipath relax does not make these paths equal. The shorter AS path remains preferred unless another earlier attribute already determines the result.
Multipath relax means different AS numbers may be accepted. It does not mean different AS-path lengths are treated as equal.
The basic Cisco configuration
router bgp 65000 bgp bestpath as-path multipath-relax address-family ipv4 maximum-paths 2 exit-address-family
Depending on the platform, software release, and configuration style, both commands may appear under the BGP process or address-family hierarchy. Always verify the syntax supported by the exact IOS, IOS-XE, NX-OS, or IOS XR release.
Why maximum-paths is still required
Multipath relax only changes which routes can be considered equivalent for multipath purposes. BGP still requires permission to install more than its default number of forwarding paths.
bgp bestpath as-path multipath-relax Changes: Which equal-length AS paths may qualify maximum-paths 2 Changes: How many qualifying eBGP paths may be installed
Configuring only multipath relax may leave the router with one installed forwarding path. Configuring only maximum-paths 2 may also leave one installed path if the two AS sequences do not meet the default multipath comparison.
What attributes must still align?
Multipath eligibility varies by Cisco operating system and feature set, but routes generally need to agree on the major decision attributes used before the multipath comparison.
| Attribute or condition | Typical expectation | Engineering note |
|---|---|---|
| Weight | Equal | Cisco-specific weight is evaluated early |
| Local preference | Equal | Different values intentionally create primary and backup paths |
| Locally originated state | Compatible | A locally originated path is normally preferred |
| AS-path length | Equal | The AS numbers may differ after relaxation |
| Origin code | Equal | IGP, EGP, and incomplete remain distinct |
| MED | Equal when compared | MED comparison across different neighboring ASes requires careful design |
| eBGP or iBGP type | Normally the same class | Mixed eBGP and iBGP multipath uses additional platform-specific features |
| Next-hop reachability | All next hops reachable | An unresolved next hop cannot forward traffic |
Do not reduce BGP multipath design to one command. Always inspect the complete path attributes for the exact prefix and confirm why each path was or was not accepted.
Example: two different ISPs advertising a default route
AS 64510
0.0.0.0/0
AS 64520
0.0.0.0/0
AS 65000
router bgp 65000 bgp bestpath as-path multipath-relax neighbor 192.0.2.1 remote-as 64510 neighbor 198.51.100.1 remote-as 64520 ! address-family ipv4 neighbor 192.0.2.1 activate neighbor 198.51.100.1 activate maximum-paths 2 exit-address-family
If both default routes have compatible attributes and equal AS-path length, the router may install both next hops. CEF can then distribute flows across them.
Multipath relax does not alter loop prevention
BGP still checks the AS path for the local autonomous system. If the local AS appears in a received route and no intentional exception applies, the route is rejected to prevent an interdomain routing loop.
The command also does not:
- Remove AS numbers from advertisements
- Rewrite AS paths
- Disable local-AS loop checks
- Replace
allowas-in - Replace
as-override - Change outbound advertisements by itself
Multipath relax does not advertise all installed paths
A router may install multiple paths locally but still advertise only the selected best path to a neighbor. Local ECMP installation and BGP path advertisement are separate functions.
Advertising additional paths may require features such as BGP Add-Path or other platform-specific capabilities. Do not assume that a downstream router learns every path simply because the upstream router displays multiple installed next hops.
The MED complication
MED is commonly compared among paths received from the same neighboring AS. When paths arrive from different provider ASes, MED may not be compared by default.
This matters because multipath relax is frequently used precisely when the neighboring AS numbers differ.
router bgp 65000 bgp always-compare-med bgp bestpath as-path multipath-relax
Using bgp always-compare-med changes BGP best-path behavior beyond multipath relax. It should not be added casually. If MED values differ, normalize them through policy or confirm that cross-provider MED comparison is explicitly part of the routing design.
Do not paste bgp always-compare-med merely because it appears beside multipath relax in an example. It changes how MED participates in route selection across neighboring autonomous systems.
When multipath relax is useful
When it may be the wrong design
Do not enable multipath relax simply because multiple circuits exist. It may be inappropriate when:
- One provider is intentionally primary and another is backup
- The paths have materially different latency or loss characteristics
- Stateful firewalls or NAT devices require deterministic symmetry
- Different providers have different security or compliance roles
- Billing models make active-active traffic undesirable
- The return path cannot be influenced sufficiently
- The routes are not truly equivalent under the intended policy
Outbound ECMP does not guarantee inbound ECMP
This command affects how the local router chooses and installs paths for traffic leaving through that router. It does not force remote networks to send traffic back through both links.
| Direction | Primary control |
|---|---|
| Enterprise to Internet or cloud | Local best-path policy, multipath eligibility, maximum paths, and CEF |
| Internet or cloud back to enterprise | Remote routing policy, advertised attributes, provider behavior, communities, prepending, and topology |
A design can therefore send outbound flows across two providers while inbound traffic strongly prefers one provider.
Stateful services and asymmetric routing
Multipath forwarding can expose stateful middleboxes to asymmetric paths. Before enabling active-active ECMP, identify:
- Firewalls
- NAT gateways
- Intrusion prevention systems
- WAN optimization appliances
- Stateful load balancers
- Encrypted tunnels
If both paths traverse the same stateful cluster or a synchronized multichassis design, asymmetry may be acceptable. If each path traverses an independent state table, sessions may fail even though the routing table is technically correct.
Verification workflow
Step 1: Confirm the configuration
show running-config | section router bgp show running-config | include multipath-relax|maximum-paths
Step 2: Inspect the exact BGP prefix
show bgp ipv4 unicast 203.0.113.0/24 Older syntax: show ip bgp 203.0.113.0/24
Verify:
- The number of available paths
- The AS path for every candidate
- AS-path length
- Weight and local preference
- Origin
- MED
- Next-hop reachability
- Best and multipath indicators
Step 3: Confirm multiple next hops in the routing table
show ip route 203.0.113.0 255.255.255.0 Or: show ip route 203.0.113.0
What the BGP output should show
BGP routing table entry for 203.0.113.0/24
Paths: (2 available, best #1)
Multipath: eBGP
Path 1:
64510 64496
valid, external, multipath, best
Path 2:
64520 64496
valid, external, multipath
The exact output varies by software release. The objective is to confirm that more than one path is marked for multipath use and that the RIB and CEF contain the corresponding next hops.
Common troubleshooting scenarios
| Symptom | Likely cause | What to check |
|---|---|---|
| Only one route in the RIB | Maximum paths not configured or path attributes differ | Configuration and exact prefix output |
| AS paths have different lengths | Multipath relax does not override path length | Prepending and route policy |
| Both routes in BGP but one in CEF | One path may not be installed or next hop is unresolved | RIB, recursive next-hop resolution, adjacency state |
| Sessions fail intermittently | Stateful asymmetry, MTU difference, or inconsistent policy | Return path, firewall state, NAT, MTU, ACLs |
| Paths still differ after normalization | Origin, MED, eBGP/iBGP class, or another attribute differs | Full BGP attribute comparison |
Common mistakes
Recommended implementation sequence
Change validation checklist
| Validation area | Confirm |
|---|---|
| Routing intent | The paths are intended to be active-active rather than primary-backup |
| Path attributes | Weight, local preference, AS-path length, origin, and MED behavior are compatible |
| Path capacity | Each path can carry additional traffic after a failure |
| Stateful services | Firewalls, NAT, and encrypted tunnels tolerate the path model |
| RIB and FIB | The expected number of next hops is installed |
| Traffic testing | Multiple flows use the intended paths without expecting perfect byte equality |
| Failure testing | Path withdrawal, CEF remapping, packet loss, and recovery meet requirements |
| Rollback | Removing multipath relax and restoring the prior maximum-paths behavior is documented |
The final architecture
Multiple BGP routes for the same prefix
|
v
Normal BGP best-path comparisons
weight, local preference, local origin,
AS-path length, origin, MED, and other checks
|
v
bgp bestpath as-path multipath-relax
allows different equal-length AS sequences
|
v
Eligible multipath candidates remain available
for the separate maximum-paths decision
The conclusion
bgp bestpath as-path multipath-relax is a targeted BGP multipath command. It allows Cisco BGP to install otherwise-equivalent paths whose AS-path sequences contain different AS numbers, provided their AS-path lengths and the other required attributes remain compatible.
bgp bestpath as-path multipath-relax does not install multiple routes by itself. When multiple-path installation is required, an appropriate maximum-paths value must be configured separately and the resulting BGP and routing-table state must be verified.
The command expands the eligible ECMP set. It does not erase BGP policy. The design still depends on attribute consistency, routing intent, next-hop reachability, CEF behavior, path capacity, failure convergence, and stateful-service compatibility.
References
- Cisco IOS XE Qualified Command Reference: BGP Commands
- Cisco: Select BGP Best Path Algorithm
- Cisco IOS XE 17.x IP Routing Configuration Guide: BGP Multipath
- Cisco: iBGP Multipath Load Sharing
// compare the AS-path length. relax the AS sequence. preserve the rest of BGP policy.