BGP Next-Hop Troubleshooting: eBGP Transit Scenario

✍️ Written by: RJS Expert
A comprehensive troubleshooting guide examining BGP next-hop behavior in eBGP multi-AS transit scenarios with practical analysis and solutions.

Troubleshooting Scenario: BGP Next-Hop Behavior Across Multiple AS

🔍 The Question:

It's well known that when using eBGP, the next-hop is modified as it traverses different routers. But what exactly happens in a transit scenario where the advertising and receiving routers don't have direct connectivity?

Specific Scenario: Three routers in different autonomous systems. R1 peers with both R2 and R3, but R2 and R3 don't peer with each other. R2 advertises a 192-network to R1. What will the next-hop be when R1 advertises this to R3? Why?

Network Topology

    AS 65002                AS 65001                AS 65003
   ┌─────────┐            ┌─────────┐            ┌─────────┐
   │   R2    │────────────│   R1    │────────────│   R3    │
   │ (eBGP)  │            │(Transit)│            │ (eBGP)  │
   └─────────┘            └─────────┘            └─────────┘
192.51.100.2/24        192.51.100.1/24      192.51.100.1/24
                            (R1-R2 link)         (R1-R3 link)

   Advertises:
   192.0.2.0/24            NO DIRECT PEERING BETWEEN R2 and R3

Topology Details

Router	AS Number	BGP Peers	Role
R1	AS 65001	R2, R3	Transit AS
R2	AS 65002	R1 only	Origin - Advertises 192.0.2.0/24
R3	AS 65003	R1 only	Receiver - No direct path to R2

⚠️ Critical Constraint:

R2 and R3 do NOT peer with each other directly. R1 acts as the transit AS between them.

Understanding the Answer: Step-by-Step Analysis

Quick Answer

✅ Result:

When R1 advertises the 192.0.2.0/24 prefix to R3, the BGP NEXT_HOP will be R1's own IP address on the R1-R3 link (192.51.100.1).

Detailed Step-by-Step Reasoning

Step 1: R2 → R1 (eBGP Advertisement)

What Happens:

• R2 originates the prefix 192.0.2.0/24
• R2 advertises this prefix to its eBGP peer R1
• In eBGP, the advertising router sets NEXT_HOP = itself
• R2 sets the next-hop to its own interface IP address facing R1

Result at R1:

Prefix: 192.0.2.0/24
NEXT_HOP: 192.51.100.2 (R2's interface)
AS_PATH: 65002

Step 2: R1 → R3 (eBGP Advertisement)

What Happens:

• R1 needs to advertise the learned prefix to R3
• This is another eBGP session (different AS: 65001 → 65003)
• Default eBGP Behavior: When advertising to an eBGP peer, the router rewrites NEXT_HOP to itself
• R1 changes the next-hop from R2's address to its own interface facing R3

Result at R3:

Prefix: 192.0.2.0/24
NEXT_HOP: 192.51.100.1 (R1's interface facing R3)
AS_PATH: 65001 65002

Why Does eBGP Change the Next-Hop?

🎯 Core Principle: Reachability

The fundamental reason for next-hop modification in eBGP is to ensure route usability and reachability.

Scenario Analysis: What If Next-Hop Wasn't Changed?

Problem	Impact
R3 receives route with next-hop = R2's IP	R3 would have a next-hop address (192.51.100.2) that it cannot reach
No direct connectivity	R3 has no peering with R2 and no route to reach R2's IP
Unreachable next-hop	BGP would mark the route as unreachable and not install it in the routing table
Routing failure	R3 cannot forward traffic to 192.0.2.0/24 even though a valid path exists

Solution: R1 Changes Next-Hop to Itself

Benefit	Result
Reachable next-hop	R3 can reach R1 (192.51.100.1) because they have a direct peering connection
Route becomes usable	R3 can install the route in its routing table and forward traffic
Transit responsibility	R1 takes responsibility for forwarding traffic from R3 to R2
Traffic flow	Traffic flows: R3 → R1 → R2, with R1 acting as the transit AS

eBGP vs iBGP: Next-Hop Behavior Comparison

BGP Type	Next-Hop Behavior	Reasoning
eBGP	MODIFIED - Router changes next-hop to itself when advertising to eBGP peer	Crossing AS boundary - ensures reachability for receiving router
iBGP	PRESERVED - Next-hop is NOT changed by default (remains the original eBGP next-hop)	Within same AS - assumes IGP provides reachability to original next-hop
iBGP with next-hop-self	MODIFIED - Manually configured to change next-hop to advertising router	Used when IGP doesn't have route to original eBGP next-hop (common in MPLS VPNs)

Traffic Flow Visualization

Packet Flow: R3 → 192.0.2.0/24 Destination

┌─────────────────────────────────────────────────────────────────┐
│ 1. R3 Routing Decision                                          │
│    - Destination: 192.0.2.10                                    │
│    - Lookup in routing table                                    │
│    - Match: 192.0.2.0/24 via next-hop 192.51.100.1 (R1)       │
│    - Action: Forward packet to R1                               │
└─────────────────────────────────────────────────────────────────┘
                            |
                            v
┌─────────────────────────────────────────────────────────────────┐
│ 2. R1 Receives Packet                                           │
│    - Destination: 192.0.2.10                                    │
│    - Lookup in routing table                                    │
│    - Match: 192.0.2.0/24 via next-hop 192.51.100.2 (R2)       │
│    - Action: Forward packet to R2                               │
└─────────────────────────────────────────────────────────────────┘
                            |
                            v
┌─────────────────────────────────────────────────────────────────┐
│ 3. R2 Receives Packet                                           │
│    - Destination: 192.0.2.10                                    │
│    - This is a directly connected network on R2                 │
│    - Action: Deliver to destination host                        │
└─────────────────────────────────────────────────────────────────┘

Verification Commands

On R1 (Transit Router)

# Check BGP table - route learned from R2
R1# show ip bgp 192.0.2.0/24
BGP routing table entry for 192.0.2.0/24
Path: 65002
Next-hop: 192.51.100.2 (R2)

# Check what R1 advertises to R3
R1# show ip bgp neighbors 192.51.100.3 advertised-routes
Network Next Hop Metric LocPrf Path
*> 192.0.2.0/24 192.51.100.1 0 65002
^^^^^^^^^^^^ (R1 changes next-hop to itself)

On R3 (Receiving Router)

# Check BGP table - route received from R1
R3# show ip bgp 192.0.2.0/24
BGP routing table entry for 192.0.2.0/24
Path: 65001 65002
Next-hop: 192.51.100.1 (R1)
^^^^^^^^^^^^ Reachable via direct peering

# Verify route is installed in routing table
R3# show ip route 192.0.2.0
B 192.0.2.0/24 [20/0] via 192.51.100.1, 00:05:23

# Verify next-hop reachability
R3# show ip bgp nexthop
Next Hop Metric Reachable
192.51.100.1 0 Yes (Connected)

Common Troubleshooting Scenarios

Scenario 1: Route Not Installed in Routing Table

⚠️ Problem:

R3 receives the BGP route but doesn't install it in the routing table.

Diagnosis:

R3# show ip bgp 192.0.2.0/24
not advertised to any peer (next-hop unreachable)

Common Causes:

1. Unreachable next-hop: R3 doesn't have a route to the next-hop address
2. Interface down: The interface toward R1 is down
3. BGP synchronization: (Rarely enabled) Route not in IGP

Solution:

• Verify connectivity: ping 192.51.100.1 from R3
• Check interface status: show ip interface brief
• Verify peering: show ip bgp summary
• Check for static route or connected route to next-hop

Scenario 2: Next-Hop Not Changed (Misconfiguration)

⚠️ Problem:

R1 is configured with neighbor next-hop-unchanged, causing R3 to receive next-hop = R2's IP.

Configuration causing the issue:

R1(config)# router bgp 65001
R1(config-router)# neighbor 192.51.100.3 next-hop-unchanged
^^^^^^^^^ This prevents next-hop modification

Result at R3:

R3# show ip bgp 192.0.2.0/24
Next-hop: 192.51.100.2 (R2) ← Unreachable!

Solution:

R1(config)# router bgp 65001
R1(config-router)# no neighbor 192.51.100.3 next-hop-unchanged

Scenario 3: Asymmetric Routing Issues

💡 Understanding Traffic Flow:

Forward Path: R3 → R1 → R2

Return Path: R2 → R1 → R3

Potential Issue:

If R2 has an alternate path back to R3's networks (e.g., through a different AS), the return traffic might take a different path. This is normal in BGP but can affect:

• Stateful firewall policies
• Traffic accounting and monitoring
• Performance troubleshooting

Verification:

# From R3, trace route to destination
R3# traceroute 192.0.2.10
1 192.51.100.1 (R1)
2 192.51.100.2 (R2)
3 192.0.2.10

# From R2, check return path to R3's networks
R2# show ip bgp [R3's-prefix]
Path: 65001 65003
Next-hop: 192.51.100.1 (R1)

Advanced Concepts: Next-Hop-Self Configuration

🔧 When to Use next-hop-self:

The next-hop-self command is primarily used in iBGP scenarios where you want to manually force next-hop modification (which doesn't happen by default in iBGP).

iBGP Scenario Example

    AS 65001
┌─────────────────────────────────┐
│  R1 (iBGP) ←→ R2 (iBGP)         │  ←── R3 (AS 65002, eBGP with R1)
└─────────────────────────────────┘

Problem: R1 learns route from R3 (eBGP) with next-hop = R3's IP.
         When R1 advertises to R2 (iBGP), next-hop stays as R3's IP.
         If R2 can't reach R3's IP via IGP, route is unusable.

Solution: Configure next-hop-self on R1 for iBGP peer R2

# On R1 - Force next-hop modification for iBGP peer
R1(config)# router bgp 65001
R1(config-router)# neighbor 10.0.0.2 remote-as 65001
R1(config-router)# neighbor 10.0.0.2 next-hop-self
^^^^^^^^^^^^^^ Forces R1 to change next-hop to itself

eBGP vs iBGP Next-Hop Behavior Summary

Scenario	Default Behavior	Configuration
eBGP	Next-hop CHANGED automatically	No configuration needed (automatic)
iBGP	Next-hop PRESERVED (not changed)	Add next-hop-self to change it
eBGP with route-reflector	Next-hop CHANGED (eBGP behavior)	Can use next-hop-unchanged to preserve

Best Practices

✅ BGP Next-Hop Best Practices:

1. Verify next-hop reachability: Always ensure the receiving router can reach the next-hop address
2. Use next-hop-self for iBGP: When IGP doesn't provide reachability to eBGP next-hops
3. Monitor BGP state: Check for unreachable next-hops in BGP table
   • show ip bgp summary
   • show ip bgp nexthop
4. Document transit paths: Understand your AS's role (stub, transit, multi-homed)
5. Test failover scenarios: Verify routing behavior when primary paths fail
6. Use loopback addresses for iBGP: Provides more stable next-hop addresses
7. Avoid unnecessary next-hop changes: Only modify when required for reachability
8. Consider MPLS VPNs: In MPLS L3VPN scenarios, next-hop-self is typically required on PE routers

Key Takeaways

🎓 Summary:

• eBGP automatically changes next-hop when advertising routes to ensure reachability
• Transit AS responsibility: R1 changes next-hop to itself, taking responsibility for forwarding
• Reachability is key: Next-hop must be reachable; otherwise, route won't be installed
• Default behavior differs: eBGP changes next-hop; iBGP preserves it (unless configured)
• Traffic flow: R3 → R1 → R2 for forward path, with R1 acting as transit
• Verification essential: Always check BGP table and next-hop reachability
• Configuration options exist: next-hop-self and next-hop-unchanged provide control
• Troubleshooting approach: Start with next-hop reachability when routes aren't installing

Practice Scenario

🎯 Test Your Understanding:

Modified Scenario: What would happen if:

1. R1 and R2 were in the same AS (iBGP peering)?
2. R1 had next-hop-unchanged configured for R3?
3. R3 had multiple paths to reach R1's IP address?
4. R2 advertised the same prefix with a different AS_PATH through another neighbor?

Think about:

• How would next-hop behavior change?
• Would routes be reachable and usable?
• What configuration changes would be needed?
• How would best path selection work?

📚 Related Topics

• BGP Path Selection Algorithm
• BGP Route Reflectors and Next-Hop Processing
• MPLS VPN Next-Hop-Self Requirements
• BGP Next-Hop Tracking and Fast Convergence
• Multi-Protocol BGP (MP-BGP) Next-Hop Behavior
• BGP Confederations and Next-Hop Processing