Introduction
Throughout this BGP series, I’ve covered numerous attributes that influence which single path BGP selects as best:
- Weight, Local Preference: Control outbound path selection
- AS-Path, MED: Influence path decisions
- Communities: Signal routing policies
But all of these mechanisms follow the same fundamental principle: BGP selects one best path per prefix. Even if you have multiple equal-cost paths to a destination, by default, BGP picks one and discards the rest.
That’s where BGP Multipath comes in.
Multipath allows BGP to install multiple equal-cost paths into the routing table simultaneously, enabling load balancing across multiple links. Instead of leaving backup paths idle, you can utilize all available bandwidth.
This post covers three multipath scenarios:
- eBGP multipath: Load balance across multiple eBGP neighbors
- iBGP multipath: Load balance across multiple iBGP neighbors
- eiBGP multipath: Load balance across BOTH eBGP and iBGP neighbors (mixed)
Understanding BGP’s Single Best Path Behavior
Default BGP Path Selection
By default, BGP follows a strict single-path paradigm:
BGP Best Path Algorithm:
1. Weight (highest)
2. Local Preference (highest)
3. Locally originated
4. AS-Path length (shortest)
5. Origin type
6. MED (lowest)
7. eBGP > iBGP
8. IGP metric to next-hop (lowest)
9. Oldest route
10. Lowest router-ID
Result: ONE best path selected, installed in routing table
ALL other paths discarded (kept in BGP table as backup only)
The Problem with Single Path
Consider this scenario:
R10 has two links to reach the internet:
- Link via R1: 1 Gbps
- Link via R2: 1 Gbps
Total available bandwidth: 2 Gbps
BGP default behavior:
- Selects ONE path (say, via R1)
- Installs only that path in routing table
- Traffic uses only R1 link (1 Gbps utilized)
- R2 link sits idle (0 Gbps utilized)
Result: 50% bandwidth utilization, R2 link wasted
Multipath solves this by installing BOTH paths.
What is BGP Multipath?
Multipath allows BGP to install multiple equal-cost paths:
Without multipath:
BGP table: Path 1 (best), Path 2 (backup)
Routing table: Path 1 only
With multipath:
BGP table: Path 1 (best), Path 2 (multipath)
Routing table: Path 1 AND Path 2
Traffic: Load balanced across both
The key is that paths must be equal-cost – they must tie at the point in the best-path algorithm where multipath evaluation occurs.
Lab Topology
Same topology from previous BGP posts:
- AS 100: R10 (connected to R1 and R2 in AS 12)
- AS 12: R1, R2 (iBGP full mesh within AS 12)
- AS 1000: R3, R4 (connected to AS 12 and AS 2000)
- AS 2000: R7, R8, R9 (iBGP mesh, R9 is route reflector)
We’ll use three different scenarios:
- R10: Load balance across R1 and R2 (both eBGP)
- R9: Load balance across R7 and R8 (both iBGP)
- R3: Load balance across R1 (eBGP) and R4 (iBGP) - mixed
Example 1: eBGP Multipath
Requirement
R10 needs to be configured to use both R1 and R2 to reach the rest of the network. Configure R10 such that it load balances between R1 and R2. R1 and R2 are eBGP neighbors.
Translation:
- R10 has two eBGP peers: R1 and R2 (both in AS 12)
- Both paths should be active simultaneously
- Traffic should load balance across both links
Initial State (Before Multipath)
R10’s BGP table:
R10#sh ip bgp
Network Next Hop Metric LocPrf Weight Path
* 1.0.0.0 192.1.120.2 0 12 i
*> 192.1.110.1 0 0 12 i
* 2.0.0.0 192.1.120.2 0 0 12 i
*> 192.1.110.1 0 12 i
R10 has two paths for each network:
- Via 192.1.120.2 (R2): Marked with
*(valid, not best) - Via 192.1.110.1 (R1): Marked with
*>(valid and best)
Why is R1 chosen? Looking at the paths:
- Network 1.0.0.0 via R1: MED=0
- Network 1.0.0.0 via R2: MED is blank (missing)
- Network 2.0.0.0 via R1: MED is blank
- Network 2.0.0.0 via R2: MED=0
The tie-breaking goes down the algorithm. Since both paths are eBGP with the same AS-Path, it likely comes down to IGP metric to next-hop or router-ID. R1 wins consistently.
R10’s routing table:
R10#sh ip route bgp
[Only R1's path installed - R2's path unused]
Only ONE path per prefix in the routing table. R2’s link is idle.
Configuration
Enable eBGP multipath on R10:
router bgp 100
maximum-paths 2
That’s it! One command enables multipath for eBGP neighbors.
Syntax:
maximum-paths <1-32>
Default: 1 (single path only)
Range: 1-32 paths (platform dependent, often limited to 16)
Results After Multipath Configuration
R10’s BGP table:
R10#sh ip bgp
Network Next Hop Metric LocPrf Weight Path
*m 1.0.0.0 192.1.120.2 0 12 i
*> 192.1.110.1 0 0 12 i
*m 2.0.0.0 192.1.120.2 0 0 12 i
*> 192.1.110.1 0 12 i
Key changes:
- Path via R2 now marked with
*m(valid, multipath) - Path via R1 still marked with
*>(valid, best) - Both paths are now active!
The m flag indicates multipath – this path is selected as an additional equal-cost path alongside the best path.
R10’s routing table:
R10#sh ip route bgp
B 1.0.0.0/8 [20/0] via 192.1.120.2, 00:02:45
[20/0] via 192.1.110.1, 00:02:45
B 2.0.0.0/8 [20/0] via 192.1.120.2, 00:02:45
[20/0] via 192.1.110.1, 00:02:45
Perfect! Both next-hops are installed for each prefix:
- 1.0.0.0/8: via 192.1.120.2 (R2) AND via 192.1.110.1 (R1)
- 2.0.0.0/8: via 192.1.120.2 (R2) AND via 192.1.110.1 (R1)
Traffic to these networks will now load balance across both R1 and R2 links.
Load Balancing Behavior
How does the router actually distribute traffic?
Per-destination load balancing (default):
Hash inputs: Source IP, Destination IP, Protocol, Source Port, Destination Port
Flow to 1.0.0.1 → Hash result → Use R1
Flow to 1.0.0.2 → Hash result → Use R2
Flow to 1.0.0.1 again → Same hash → Use R1 (consistent)
This is per-flow load balancing:
- Individual flows are sticky to one path
- Different flows may use different paths
- Prevents packet reordering within a flow
Result: Traffic distributes across both links, roughly 50/50 over time.
Example 2: iBGP Multipath
Requirement
R9 needs to be configured to use both R7 and R8 to reach the rest of the network. Configure R9 such that it load balances between R7 and R8. R7 and R8 are iBGP neighbors.
Translation:
- R9 has two iBGP peers: R7 and R8 (all in AS 2000)
- Both paths should be active simultaneously
- Traffic should load balance across both links
Initial State (Before Multipath)
R9’s BGP table:
R9#sh ip bgp
Network Next Hop Metric LocPrf Weight Path
* i 1.0.0.0 10.8.8.8 0 100 0 1000 12 i
*>i 10.7.7.7 0 100 0 1000 12 i
* i 2.0.0.0 10.8.8.8 0 100 0 1000 12 i
*>i 10.7.7.7 0 100 0 1000 12 i
R9 has two paths for each network:
- Via 10.8.8.8 (R8): Marked with
*i(valid, internal, not best) - Via 10.7.7.7 (R7): Marked with
*>i(valid, internal, best)
Both paths are iBGP. The tie-breaking goes through the best-path algorithm, and R7 wins (likely due to IGP metric to next-hop or router-ID).
R9’s routing table:
R9#sh ip route bgp
[Only R7's path installed - R8's path unused]
Configuration
Enable iBGP multipath on R9:
router bgp 2000
maximum-paths ibgp 2
Critical difference: For iBGP multipath, use the ibgp keyword.
Syntax:
maximum-paths ibgp <1-32>
Note: Separate from eBGP multipath configuration
Results After Multipath Configuration
R9’s BGP table:
R9#sh ip bgp
Network Next Hop Metric LocPrf Weight Path
*mi 1.0.0.0 10.8.8.8 0 100 0 1000 12 i
*>i 10.7.7.7 0 100 0 1000 12 i
*mi 2.0.0.0 10.8.8.8 0 100 0 1000 12 i
*>i 10.7.7.7 0 100 0 1000 12 i
Key changes:
- Path via R8 now marked with
*mi(valid, multipath, internal) - Path via R7 still marked with
*>i(valid, best, internal) - Both iBGP paths are now active!
R9’s routing table:
R9#sh ip route bgp
B 1.0.0.0/8 [200/0] via 10.8.8.8, 00:01:23
[200/0] via 10.7.7.7, 00:01:23
B 2.0.0.0/8 [200/0] via 10.8.8.8, 00:01:23
[200/0] via 10.7.7.7, 00:01:23
Perfect! Both iBGP next-hops are installed:
- Administrative distance: 200 (iBGP)
- Next-hops: 10.8.8.8 (R8) and 10.7.7.7 (R7)
Traffic now load balances across both R7 and R8 links.
iBGP Multipath Considerations
Split-horizon warning: In iBGP full mesh, R9 may receive the same route from multiple iBGP peers, but iBGP split-horizon rules prevent R9 from advertising routes learned via iBGP to other iBGP peers.
Route reflector compatibility: If R9 is a route reflector (as in our topology), iBGP multipath works normally. If R9 is a route reflector client, ensure the RR is configured to reflect multiple paths.
Example 3: eiBGP Multipath (Mixed eBGP and iBGP)
Requirement
R3 needs to be configured to use both R1 and R4 to reach the rest of the network. Configure R3 such that it load balances between R1 and R4. R1 is an eBGP neighbor and R4 is an iBGP neighbor.
Translation:
- R3 has one eBGP peer: R1 (AS 12)
- R3 has one iBGP peer: R4 (both in AS 1000)
- Load balance across BOTH eBGP and iBGP paths simultaneously
This is the tricky scenario – mixing eBGP and iBGP paths.
Initial State (Before Multipath)
R3’s BGP table:
R3#sh ip bgp
Network Next Hop Metric LocPrf Weight Path
* i 1.0.0.0 192.168.34.4 0 100 0 12 i
*> 192.1.13.1 0 0 12 i
*> 2.0.0.0 192.1.13.1 0 12 i
* i 192.168.34.4 0 100 0 12 i
R3 has two paths for each network:
- Via 192.168.34.4 (R4): iBGP path, marked with
*i - Via 192.1.13.1 (R1): eBGP path, marked with
*>
Why does eBGP win? Step 7 in the best-path algorithm: eBGP is preferred over iBGP. Even though both paths have the same Weight, Local Preference, AS-Path length, etc., the eBGP path wins by default.
R3’s routing table:
R3#sh ip route bgp
[Only eBGP path via R1 installed - iBGP path via R4 unused]
Configuration
Enable eiBGP multipath on R3:
router bgp 1000
maximum-paths eibgp 2
Critical keyword: eibgp (not ibgp, not the default)
Syntax:
maximum-paths eibgp <1-32>
Enables multipath across BOTH eBGP and iBGP paths
Warning: Can create routing loops if misconfigured
The Loop Warning
When you configure eibgp, Cisco IOS displays a warning:
R3(config-router)#maximum-paths eibgp 2
%BGP: This may cause traffic loop if not used properly (command accepted)
%BGP-4-MULTIPATH_LOOP: This may cause traffic loop if not used properly (command accepted).
Why the warning?
If R4 (iBGP peer) also has multipath configured and learns routes from R3, you can create a loop:
R3 learns route from R1 (eBGP) and R4 (iBGP)
R3 installs both paths via multipath
R3's traffic to R4 may use iBGP path → goes to R4
R4 learns route from R3 (iBGP) and external source
R4 installs both paths via multipath
R4's traffic back may use iBGP path → goes to R3
Result: R3 ↔ R4 loop for some traffic
Solution: Ensure your IGP metrics and AS topology prevent loops. Typically, this works safely when:
- eBGP paths are genuinely external (not via iBGP peers)
- Proper route reflector hierarchy exists
- You’re not creating transit scenarios through iBGP
Results After Multipath Configuration
R3’s BGP table:
R3#sh ip bgp
Network Next Hop Metric LocPrf Weight Path
*mi 1.0.0.0 192.168.34.4 0 100 0 12 i
*> 192.1.13.1 0 0 12 i
*> 2.0.0.0 192.1.13.1 0 12 i
*mi 192.168.34.4 0 100 0 12 i
Key changes:
- iBGP path via R4 now marked with
*mi(valid, multipath, internal) - eBGP path via R1 still marked with
*>(valid, best) - Mixed eBGP and iBGP paths are both active!
R3’s routing table:
R3#sh ip route bgp
B 1.0.0.0/8 [20/0] via 192.168.34.4, 00:01:41
[20/0] via 192.1.13.1, 00:01:41
B 2.0.0.0/8 [20/0] via 192.168.34.4, 00:01:41
[20/0] via 192.1.13.1, 00:01:41
Interesting! Both next-hops installed:
- 192.168.34.4 (R4, iBGP) – AD 20 shown (but actually learned via iBGP with AD 200)
- 192.1.13.1 (R1, eBGP) – AD 20 (eBGP)
The display shows AD 20 for both because CEF load balances based on the best path’s AD. Both are treated equally for forwarding purposes.
Traffic now load balances across both eBGP (R1) and iBGP (R4) links.
Requirements for Multipath Selection
For BGP to install multiple paths via multipath, the paths must be equal at the point where multipath evaluation occurs. Specifically:
Equal-Cost Requirements
Paths must tie through these best-path steps:
- ✓ Weight (must be equal)
- ✓ Local Preference (must be equal)
- ✓ Locally originated (both or neither)
- ✓ AS-Path length (must be equal)
- ✓ Origin type (must be equal)
- ✓ MED (must be equal for same-AS paths)
- ← Multipath evaluation happens here
If paths are equal through step 6, they’re candidates for multipath. The evaluation at step 7 (eBGP vs iBGP) depends on the multipath type:
maximum-paths <n> → Only eBGP paths (step 7: all must be eBGP)
maximum-paths ibgp <n> → Only iBGP paths (step 7: all must be iBGP)
maximum-paths eibgp <n> → Mixed (step 7: can be eBGP or iBGP)
What Breaks Multipath?
Different AS-Path lengths:
Path 1: AS-Path = 200 100 (length 2)
Path 2: AS-Path = 200 100 100 (length 3)
Result: NOT equal-cost (step 4 differs)
Only shortest path installed
Different Local Preferences:
Path 1: Local Preference = 200
Path 2: Local Preference = 100
Result: NOT equal-cost (step 2 differs)
Only highest LP path installed
Different MEDs (when comparing same AS):
Path 1 from AS 200: MED = 50
Path 2 from AS 200: MED = 100
Result: NOT equal-cost (step 6 differs)
Only lowest MED path installed
Mixed eBGP/iBGP without eibgp:
Path 1: eBGP
Path 2: iBGP
Config: maximum-paths 2 (eBGP only)
Result: Only eBGP path installed (step 7)
Multipath Configuration Matrix
Here’s a complete reference for all multipath scenarios:
| Scenario | Command | Effect | Use Case |
|---|---|---|---|
| eBGP only | maximum-paths 2 |
Load balance across eBGP peers | Dual ISP, dual peering |
| iBGP only | maximum-paths ibgp 2 |
Load balance across iBGP peers | Internal backbone links |
| Mixed eBGP+iBGP | maximum-paths eibgp 2 |
Load balance across both | Complex topologies (use carefully) |
| eBGP and iBGP separately | maximum-paths 2maximum-paths ibgp 2 |
Independent limits | Different path counts |