Day 12 — BGP NEXT_HOP: Reachability, iBGP Preservation and `next-hop-self`
Learning objective
Predict common NEXT_HOP behavior across eBGP and iBGP, prove whether a received next hop is recursively reachable, and correct an iBGP path that is unusable because the external next hop was preserved.
 |
| BGP NEXT_HOP: Reachability, iBGP Preservation and `next-hop-self` |
1. Opening — a route can be learned correctly and still be unusable
BGP may know the destination, prefer the path attributes and still refuse to use the route because the next hop cannot be resolved.
This is one of the most important boundaries between the BGP control plane and the rest of the routing system.
Imagine three routers:
- R1 is an external peer.
- R2 learns a service prefix from R1 with eBGP.
- R2 advertises that route to R3 with iBGP.
By default, iBGP commonly preserves the BGP NEXT_HOP of an externally learned route. If R3 has no route to that external next-hop address, the route can become unusable even though the R2–R3 iBGP session is perfectly Established.
The fix may be next-hop-self—but only after proving that next-hop reachability is the actual cause.
2. NEXT_HOP is a path attribute
RFC 4271 defines NEXT_HOP as a well-known mandatory path attribute in the base IPv4-unicast model.
Its purpose is to identify the next-hop IP address used to reach the destinations described by the associated NLRI.
This means BGP path selection cannot be understood only by reading AS_PATH or LOCAL_PREF. The forwarding system must be able to resolve the next hop.
Cisco's IOS XE 17.18.x BGP documentation explicitly notes that a path with an inaccessible next hop is not eligible to proceed normally through selection/use.
3. Common eBGP behavior
On directly connected eBGP sessions, Cisco normally advertises itself as the next hop for routes it sends to the external neighbor.
That is why a route learned from one eBGP hop usually points to the peer's directly reachable interface address.
However, BGP standards and implementations also support scenarios involving third-party next hops and explicit next-hop-unchanged behavior. Do not reduce the protocol to the slogan “eBGP always changes next hop.”
The safe operational wording is:
> Direct eBGP on Cisco normally changes the advertised next hop to the sending router, unless a specific design/feature causes different behavior.
4. Common iBGP behavior
When a router advertises an eBGP-learned route to an iBGP peer, the external NEXT_HOP is commonly preserved.
That design makes sense when the internal routing system knows how to reach external-facing next hops. Service-provider and large enterprise networks often intentionally carry those next-hop addresses in an IGP.
But a small enterprise design may not do that.
If R3 receives:
203.0.113.0/24 via NEXT_HOP 192.0.2.1and has no route to 192.0.2.1, the BGP path is not operationally usable.
5. next-hop-self changes the dependency
Cisco's neighbor next-hop-self command makes the local BGP speaker advertise itself as the next hop toward the selected neighbor for the applicable routes/behavior.
In our three-router example, R2 can tell R3:
203.0.113.0/24 via NEXT_HOP 198.51.100.1where 198.51.100.1 is R2's directly connected internal address toward R3.
Now R3 can resolve the next hop without learning the R1–R2 external transit subnet.
This is a design choice, not a universal requirement.
6. Alternative design: carry the external next hop in the IGP
Instead of changing NEXT_HOP, an AS can make the existing next-hop address reachable through its IGP or another internal routing mechanism.
That may be preferable in networks where:
- preserving edge next-hop identity matters;
- multiple exits exist;
- route reflectors must not become forwarding hops;
- BGP PIC or other convergence designs depend on particular next-hop architecture.
The correct solution therefore depends on the intended control-plane and forwarding architecture.
next-hop-self is not a substitute for design.
7. Route-reflector caveat
Cisco documentation contains an important warning: using ordinary neighbor next-hop-self on a route reflector does not rewrite the next hop of all reflected client routes in the way an inexperienced operator might expect.
For route-reflector designs, Cisco documents route-map-based approaches for specific reflected-route next-hop changes and warns that incorrect attribute rewriting can create loops or loss of connectivity.
That advanced case belongs in the route-reflector module.
For Day 12, R2 is a normal iBGP speaker, not a route reflector.
8. Scenario — Ridge Internal Next-Hop Failure
Illustrative lab — not a real incident.
Topology
 |
| BGP NEXT_HOP: Reachability, iBGP Preservation and `next-hop-self` |
203.0.113.0/24
|
R1
AS65010
192.0.2.1/30
|
| eBGP
|
192.0.2.2/30
R2 ---------------- R3
AS65020 AS65020
198.51.100.1/30 198.51.100.2/30
<--------- iBGP --------->Objective
- R1 originates
203.0.113.0/24. - R2 learns it through eBGP.
- R2 advertises it to R3 through iBGP.
- R3 initially has no route to
192.0.2.1, the preserved external next hop. - We prove the next-hop failure, then configure
next-hop-selfon R2 toward R3.
9. Prerequisites
- Three IOS XE-capable nodes.
- IOS XE 17.18.x documentation baseline.
- Direct eBGP R1–R2.
- Direct iBGP R2–R3.
- No IGP/static route on R3 to the R1–R2 transit subnet initially.
- Console access.
10. Baseline configuration
R1 — AS 65010
hostname R1
interface GigabitEthernet0/0
ip address 192.0.2.1 255.255.255.252
no shutdown
!
ip route 203.0.113.0 255.255.255.0 Null0
!
router bgp 65010
bgp router-id 10.10.10.1
neighbor 192.0.2.2 remote-as 65020
address-family ipv4 unicast
network 203.0.113.0 mask 255.255.255.0
neighbor 192.0.2.2 activate
exit-address-familyR2 — AS 65020
hostname R2
interface GigabitEthernet0/0
ip address 192.0.2.2 255.255.255.252
no shutdown
interface GigabitEthernet0/1
ip address 198.51.100.1 255.255.255.252
no shutdown
!
router bgp 65020
bgp router-id 10.20.20.2
neighbor 192.0.2.1 remote-as 65010
neighbor 198.51.100.2 remote-as 65020
address-family ipv4 unicast
neighbor 192.0.2.1 activate
neighbor 198.51.100.2 activate
exit-address-familyR3 — AS 65020
hostname R3
interface GigabitEthernet0/0
ip address 198.51.100.2 255.255.255.252
no shutdown
!
router bgp 65020
bgp router-id 10.20.20.3
neighbor 198.51.100.1 remote-as 65020
address-family ipv4 unicast
neighbor 198.51.100.1 activate
exit-address-familyCritically, R3 has no static or IGP route to 192.0.2.0/30.
11. Verification before modification
R2
show ip bgp 203.0.113.0
show ip route 192.0.2.1
show ip bgp neighbors 198.51.100.2 advertised-routesR2 should be able to resolve 192.0.2.1 because that external neighbor is directly connected.
R3
show ip bgp 203.0.113.0
show ip route 192.0.2.1
show ip route 203.0.113.0
show ip bgp summaryEvidence expectation
The route can be visible in R3's BGP information while failing eligibility/installation because the NEXT_HOP cannot be resolved.
Use the selected image's actual output to document the status. Do not fabricate the exact code/wording that marks the path inaccessible.
12. Fault injection
Illustrative lab — not a real incident.
Lab name
Ridge Internal Next-Hop Failure
Fault
The baseline itself is the fault: R2 advertises the eBGP-learned route to R3 without rewriting NEXT_HOP, and R3 has no route to the external next-hop address.
Symptom
- iBGP is Established;
- the destination may appear in BGP detail;
- the route is not usable/installed as expected;
- forwarding to the service prefix fails from R3.
Misleading conclusion to avoid
“The iBGP session is up, so the route must be good.”
13. Step-by-step troubleshooting
- Confirm the exact destination prefix.
- Confirm R2 learned it from R1.
- Confirm R2 advertises it toward R3.
- Inspect the NEXT_HOP value at R3.
- Perform a route lookup for that next-hop address on R3.
- Distinguish destination reachability from next-hop reachability.
- Confirm no policy intentionally rewrites NEXT_HOP.
- Decide whether the design should carry the external transit subnet internally or rewrite next hop at R2.
- Apply the smallest design-correct fix.
- Verify RIB/FIB and forwarding after correction.
The decisive command in this lab is not a neighbor reset. It is a route lookup for the BGP next hop.
14. Controlled modification — set next hop to R2
On R2:
configure terminal
router bgp 65020
address-family ipv4 unicast
neighbor 198.51.100.2 next-hop-self
endIf the selected IOS XE image uses the command in router scope rather than address-family scope, follow the exact release/platform command reference. Do not silently blend syntax.
Use a safe outbound refresh/re-advertisement if needed so R3 receives the updated attribute.
15. Expected result
R3 should now receive the route with R2 as the BGP NEXT_HOP for the relevant advertisement.
Because R2's 198.51.100.1 address is directly connected to R3, next-hop resolution succeeds.
Expected pipeline:
BGP NLRI present
|
NEXT_HOP = 198.51.100.1
|
R3 RIB resolves 198.51.100.1 as connected
|
BGP path becomes usable
|
Route can be installed subject to remaining policy/selection rules16. Root cause and correction
Root cause
R3 learned the destination through iBGP with a preserved external NEXT_HOP (192.0.2.1) that was absent from R3's routing table.
Correction
R2 rewrites the next hop toward R3 with next-hop-self.
Why it works
The change removes R3's dependency on reachability to the external R1–R2 transit address and replaces it with a directly reachable internal next hop: R2.
17. Post-fix verification
On R3:
show ip bgp 203.0.113.0
show ip route 198.51.100.1
show ip route 203.0.113.0On R2:
show ip bgp neighbors 198.51.100.2 advertised-routes
show ip bgp 203.0.113.0Positive test
Use a reachable test endpoint if you want end-to-end forwarding validation. The lab's Null0-backed service prefix is primarily a control-plane example, so do not claim application success from it.
Negative test
Remove next-hop-self again and verify that the route returns to the unreachable-next-hop condition if no alternate next-hop reachability exists.
18. Rollback
router bgp 65020
address-family ipv4 unicast
no neighbor 198.51.100.2 next-hop-selfRollback is safe only if the original design intentionally provides next-hop reachability another way. Otherwise removing the command recreates the fault.
Preserve:
- route details before and after;
- R3 route lookup for the old and new next hops;
- advertised-route evidence from R2;
- relevant configuration.
19. Production design considerations
Do not hide IGP design problems blindly
If a large network is supposed to carry BGP next hops in its IGP, adding next-hop-self everywhere may conceal the real architecture failure.
Do not make route reflectors forwarding dependencies accidentally
Route-reflector next-hop rewriting requires separate design analysis. Cisco specifically warns about ordinary next-hop-self behavior on reflected routes.
Monitor recursive reachability
BGP peer-state monitoring does not detect every next-hop failure. Next-hop tracking and RIB/FIB monitoring are essential for convergence and forwarding assurance.
Separate control-plane visibility from forwarding usability
A route can appear in BGP detail and still fail to install or forward.
20. Production lessons
Protocol lesson
NEXT_HOP is not cosmetic metadata; it links BGP reachability to the underlying routing system.
Troubleshooting lesson
When a route is present in BGP but not usable, perform a route lookup for the next hop before manipulating preference attributes.
Design lesson
Choose intentionally between preserving external next hops internally and rewriting them with next-hop-self.
Change-management lesson
Changing NEXT_HOP can redirect large amounts of traffic. Verify capacity and forwarding before applying it broadly.
Security lesson
Uncontrolled next-hop manipulation can create loops, blackholes or unintended forwarding paths. Treat it as a high-impact attribute change.
21. Knowledge check
Q1
Why can an iBGP-learned route be visible but unusable?
Answer: Its BGP NEXT_HOP may be unreachable in the receiving router's RIB, preventing the path from becoming a usable route.
Q2
What does next-hop-self change in this lab?
Answer: R2 advertises itself as the next hop toward R3, replacing the preserved external R1 next hop with an address R3 can resolve directly.
Q3
Is next-hop-self always the correct solution?
Answer: No. Some designs intentionally preserve BGP next hops and carry them in the IGP or another internal reachability mechanism. The correct solution depends on the architecture.
22. Sources
- RFC 4271 — *A Border Gateway Protocol 4 (BGP-4)* — NEXT_HOP attribute and route-processing behavior.
- Cisco — *IP Routing Configuration Guide, Cisco IOS XE 17.18.x: Configuring BGP* — inaccessible next-hop handling and BGP path processing.
- Cisco — *Cisco IOS IP Routing: BGP Command Reference* —
neighbor next-hop-selfandneighbor next-hop-unchanged. - Cisco — *IP Routing Configuration Guide, Cisco IOS XE 17.x: BGP Next Hop Unchanged* — common eBGP next-hop behavior and explicit unchanged behavior.
- Cisco — *Configuring Internal BGP Features* — route-reflector next-hop caveats.
Accessed: 2026-08-11.