What Is next-hop-self?
next-hop-self is a setting that rewrites the NEXT_HOP attribute to the router’s own address when advertising routes to iBGP peers. Because iBGP does not change the NEXT_HOP by default, an address outside the AS is carried into the AS unchanged, and if the receiving router cannot reach that address the route goes unused. next-hop-self solves this.
For the NEXT_HOP and the differences between iBGP and eBGP, see Differences Between iBGP and eBGP; for the basics of BGP, see BGP (Border Gateway Protocol).
Why the Problem Occurs
When advertising a route, BGP rewrites the NEXT_HOP to its own address for eBGP peers but leaves it unchanged for iBGP peers, since no AS boundary is crossed.
As a result, when the AS border router (R2 in the diagram) relays a route it learned via eBGP into iBGP, the NEXT_HOP enters the AS still holding the address of a router outside the AS (R3’s 10.2.3.3). To R1, which receives it, that address lies outside its own AS.
If BGP cannot find a route to the NEXT_HOP in the routing table, it treats the route as invalid (the recursive lookup fails). An invalid route is never selected as the best path and never reaches the routing table. In show bgp the leading * (valid) disappears, and the detailed output marks the NEXT_HOP as (inaccessible).
Two Ways to Solve It
| Method | What it does | Advantage | Caveat |
|---|---|---|---|
next-hop-self | The AS border router rewrites the NEXT_HOP to its own address (usually a loopback) when advertising to iBGP peers | No need to carry external link routes in the internal IGP | Must be configured on every AS border router |
| Advertise the external link in the IGP | The AS border router puts the link to its eBGP peer (10.2.3.0/24 in the example below) into the IGP | No BGP configuration change needed | Routes for links facing outside the AS end up in the internal IGP, increasing the route count and the management burden as external links grow |
next-hop-self is generally preferred, because it keeps a clear division of labor: the internal IGP handles reachability inside the AS, and BGP handles connectivity to the outside.
Configuration
On IOS XR, next-hop-self is configured under the address family of the iBGP neighbor.
router bgp <AS number>
neighbor <iBGP peer address>
address-family ipv4 unicast
next-hop-selfnext-hop-self rewrites the value only when advertising to iBGP peers; the NEXT_HOP held in the configured router’s own BGP table does not change. In the verification below, R2’s own show bgp still shows 10.2.3.3.Verification on Real Devices
I use the same lab as in BGP (Border Gateway Protocol): four IOS XR (XRd) routers spread across three ASes. R1 - R2 within AS 65001 is an iBGP peering, and R2 - R3 and R3 - R4 between ASes are eBGP peerings.
In this lab, R2 advertises the link to its eBGP peer (10.2.3.0/24) into OSPF as a passive interface, so R1 can reach 10.2.3.3. That is the “advertise the external link in the IGP” approach described above.
RP/0/RP0/CPU0:R1#show route 10.2.3.3
Sat Sep 5 05:27:01.040 UTC
Routing entry for 10.2.3.0/24
Known via "ospf 1", distance 110, metric 2, type intra area
Installed Sep 5 03:09:53.399 for 02:17:07
Routing Descriptor Blocks
10.1.2.2, from 10.0.0.2, via GigabitEthernet0/0/0/0
Route metric is 2
No advertising protos.Even with the NEXT_HOP left at 10.2.3.3, every route is *> (valid and best).
RP/0/RP0/CPU0:R1#show bgp
<snip>
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 192.168.1.0/24 0.0.0.0 0 32768 i
*>i192.168.2.0/24 10.0.0.2 0 100 0 i
*>i192.168.3.0/24 10.2.3.3 0 100 0 65002 i
*>i192.168.4.0/24 10.2.3.3 100 0 65002 65003 i
Processed 4 prefixes, 4 pathsMaking the NEXT_HOP Unreachable
Remove the 10.2.3.0/24 interface from OSPF on R2 so that R1 can no longer reach the NEXT_HOP.
router ospf 1
area 0
no interface GigabitEthernet0/0/0/110.2.3.0/24 disappears from R1’s routing table.
RP/0/RP0/CPU0:R1#show route 10.2.3.3
Sat Sep 5 05:27:26.875 UTC
% Network not in tableIn the BGP table, the two routes learned through R3 have lost their > and show only *. With no valid path, no best path is selected.
RP/0/RP0/CPU0:R1#show bgp
<snip>
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 192.168.1.0/24 0.0.0.0 0 32768 i
*>i192.168.2.0/24 10.0.0.2 0 100 0 i
* i192.168.3.0/24 10.2.3.3 0 100 0 65002 i
* i192.168.4.0/24 10.2.3.3 100 0 65002 65003 i
Processed 4 prefixes, 4 pathsThe detailed output shows no best path and marks the NEXT_HOP as (inaccessible).
RP/0/RP0/CPU0:R1#show bgp 192.168.3.0/24
Sat Sep 5 05:27:38.830 UTC
BGP routing table entry for 192.168.3.0/24
Versions:
Process bRIB/RIB SendTblVer
Speaker 27 27
Last Modified: Sep 5 05:27:18.774 for 00:00:20
Paths: (1 available, no best path)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
65002
10.2.3.3 (inaccessible) from 10.0.0.2 (10.0.0.2)
Origin IGP, metric 0, localpref 100, valid, internal
Received Path ID 0, Local Path ID 0, version 0With no best path, nothing reaches the routing table. Only 192.168.2.0/24, learned from R2 itself, remains.
RP/0/RP0/CPU0:R1#show route bgp
Sat Sep 5 05:27:27.391 UTC
B 192.168.2.0/24 [200/0] via 10.0.0.2, 00:16:46Reachability fails as well.
RP/0/RP0/CPU0:R1#ping 192.168.3.1 source 192.168.1.1
Sat Sep 5 05:27:39.221 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.3.1 timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)Fixing It with next-hop-self
Configure next-hop-self on R2’s iBGP neighbor.
router bgp 65001
neighbor 10.0.0.1
address-family ipv4 unicast
next-hop-selfIn R1’s BGP table the NEXT_HOP is rewritten to 10.0.0.2 (R2’s Loopback0), and every route is *> again.
RP/0/RP0/CPU0:R1#show bgp
<snip>
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 192.168.1.0/24 0.0.0.0 0 32768 i
*>i192.168.2.0/24 10.0.0.2 0 100 0 i
*>i192.168.3.0/24 10.0.0.2 0 100 0 65002 i
*>i192.168.4.0/24 10.0.0.2 100 0 65002 65003 i
Processed 4 prefixes, 4 pathsThe detailed output no longer shows (inaccessible) and is marked best. Because 10.0.0.2 is learned via OSPF, it is shown as reachable with (metric 2).
RP/0/RP0/CPU0:R1#show bgp 192.168.3.0/24
Sat Sep 5 05:28:15.911 UTC
BGP routing table entry for 192.168.3.0/24
Versions:
Process bRIB/RIB SendTblVer
Speaker 30 30
Last Modified: Sep 5 05:28:08.774 for 00:00:07
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
65002
10.0.0.2 (metric 2) from 10.0.0.2 (10.0.0.2)
Origin IGP, metric 0, localpref 100, valid, internal, best, group-best
Received Path ID 0, Local Path ID 1, version 30Three routes are back in the routing table and reachability is restored.
RP/0/RP0/CPU0:R1#show route bgp
Sat Sep 5 05:28:16.088 UTC
B 192.168.2.0/24 [200/0] via 10.0.0.2, 00:17:35
B 192.168.3.0/24 [200/0] via 10.0.0.2, 00:00:07
B 192.168.4.0/24 [200/0] via 10.0.0.2, 00:00:07RP/0/RP0/CPU0:R1#ping 192.168.3.1 source 192.168.1.1
Sat Sep 5 05:28:16.213 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.3.1 timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/9/16 msThe Configured Router’s Own Table Is Unchanged
Looking at show bgp on R2 itself, where next-hop-self is configured, the NEXT_HOP is still 10.2.3.3.
RP/0/RP0/CPU0:R2#show bgp 192.168.3.0/24
Sat Sep 5 05:28:29.022 UTC
BGP routing table entry for 192.168.3.0/24
Versions:
Process bRIB/RIB SendTblVer
Speaker 19 19
Last Modified: Sep 5 04:54:22.774 for 00:34:06
Paths: (1 available, best #1)
Advertised IPv4 Unicast paths to peers (in unique update groups):
10.0.0.1
Path #1: Received by speaker 0
Advertised IPv4 Unicast paths to peers (in unique update groups):
10.0.0.1
65002
10.2.3.3 from 10.2.3.3 (10.0.0.3)
Origin IGP, metric 0, localpref 100, valid, external, best, group-best
Received Path ID 0, Local Path ID 1, version 19
Origin-AS validity: (disabled)This confirms that next-hop-self rewrites the value when advertising to iBGP peers and does not alter the route information the router itself holds.
Configuration Files
Download R1 config (r1_bgp-next-hop-self.cfg)
Download R2 config (r2_bgp-next-hop-self.cfg)
Download R3 config (r3_bgp-next-hop-self.cfg)
Download R4 config (r4_bgp-next-hop-self.cfg)
The configuration files show the state after next-hop-self was applied (only R2 carries next-hop-self).
Command Outputs
The output of show route, show bgp, show bgp <prefix> (for all four prefixes), show bgp summary, and show bgp neighbor, collected per router both before and after next-hop-self was configured.
Before configuring next-hop-self
Download R1 output (r1_bgp-next-hop-self_before_show.txt)
Download R2 output (r2_bgp-next-hop-self_before_show.txt)
Download R3 output (r3_bgp-next-hop-self_before_show.txt)
Download R4 output (r4_bgp-next-hop-self_before_show.txt)
After configuring next-hop-self
Download R1 output (r1_bgp-next-hop-self_after_show.txt)
Download R2 output (r2_bgp-next-hop-self_after_show.txt)
Download R3 output (r3_bgp-next-hop-self_after_show.txt)
Download R4 output (r4_bgp-next-hop-self_after_show.txt)
References
| Source | Title | Summary |
|---|---|---|
| RFC 4271 | A Border Gateway Protocol 4 (BGP-4) | The base specification of BGP-4, defining the NEXT_HOP attribute and its handling in iBGP and eBGP. |
| IANA | Border Gateway Protocol (BGP) Parameters | The registry of numbers used by BGP. |