BGP NEXT_HOP Attribute

What NEXT_HOP Is

NEXT_HOP (Type code 3) is the well-known mandatory path attribute that carries the IP address of the router a packet is handed to next (BGP Path Attributes and Best Path Selection). It is not necessarily the address of the router that advertised the route; it is where to forward packets, and the case where the two diverge is third-party next hop (below).

Item	Description
Type code	3
Classification	Well-known mandatory (every implementation understands it, and it is always in an UPDATE)
Value	A 4-byte IPv4 address (for IPv6, the Next hop field inside MP_REACH_NLRI)
Definition	RFC 4271 section 5.1.3

How NEXT_HOP Is Set

The advertising router decides the value per peer (RFC 4271 section 5.1.3).

Advertised to	Route	Behavior
iBGP peer	Learned from another peer	`NEXT_HOP` is not rewritten (the received value is passed through unchanged)
iBGP peer	Locally originated	The address of the interface through which that network is reachable is used. If the network is directly connected (or that address would be the peer’s own address), its own address is used
eBGP peer	—	By default, `NEXT_HOP` becomes its own address (the address of the interface used to reach that peer)

A learned route is not rewritten on iBGP because the IGP is assumed to know how to reach the exit point. The reachability problem this causes is covered in BGP next-hop-self.

The value for an eBGP peer is decided by four cases, and “its own address” above is the default that applies when none of the others do. The other three all allow an address that shares a common subnet with the peer being advertised to, which is what the third-party next hop below is.

For an eBGP peer several IP hops away (multihop eBGP), the default is the speaker’s own address, and it can be configured to propagate the received NEXT_HOP instead (RFC 4271 section 5.1.3, case 3). That is the form an IX route server uses, but this article’s verification does not cover it.

Third-Party Next Hop on a Shared Segment

RFC 4271 section 5.1.3 allows a router advertising to an eBGP peer to use the address of a forwarding router that sits on the same subnet as that peer as the NEXT_HOP. This is third-party next hop, and it appears when three or more routers share one L2 segment but only two pairs are BGP peers. The rule comes in two forms, and this article covers the latter.

Origin of the route	Address usable as `NEXT_HOP`
Learned from an iBGP peer, or locally originated	The interface address of the internal router through which that network is reachable
Learned from an eBGP peer	The address of an adjacent router known from the received `NEXT_HOP`

R1, R2 and R3 are on the same segment
The BGP peers are only R1 - R2 and R2 - R3 (R1 and R3 are not peers)
R2 relays a route originated by R3 to R1

If R2 rewrote NEXT_HOP to itself, packets from R1 would cross the same segment twice. So R2 hands R1 the address of R3, letting R1 send directly.

Value of `NEXT_HOP`	Packet flow as seen from R1
R2’s address	R1 → R2 → R3 (crosses the same segment twice)
R3’s address (third party)	R1 → R3 (crosses it once)

The same section also says a router must not advertise a route it originates with the peer’s own address as NEXT_HOP, and must not install a route with itself as the next hop. IOS XR replaces the NEXT_HOP with its own address for received routes too whenever it would be the receiving peer’s own address (R1’s route returned to R1, for example). Because this is decided per peer, the same route can carry a different NEXT_HOP depending on who receives it.

The same section 5.1.3 makes the ability to turn third-party next hops off a mandatory requirement: a BGP speaker “MUST be able to support the disabling advertisement of third party NEXT_HOP attributes” in order to handle imperfectly bridged media. The next-hop-self described below is that mechanism.

Third-party next hop applies only when the BGP peers share the same subnet; it never occurs on point-to-point links.

Recursive Lookup and NEXT_HOP Reachability

A BGP route is usable only once its NEXT_HOP resolves in the routing table (the recursive lookup of RFC 4271 section 5.1.3). If it does not, the route is invalid: the > disappears in show bgp and the detail shows (inaccessible). When it does resolve, the actual forwarding target is the NEXT_HOP itself if the entry is an attached subnet with no next-hop address, or that next-hop address if the entry specifies one. If several equal-cost entries exist, one is selected. A third-party next hop is a directly connected address on the shared segment, so the receiving router resolves it, but once the route is distributed into the AS over iBGP the other routers must be able to reach the shared segment too. In the verification R4 has that route from OSPF.

Two Ways to Rewrite NEXT_HOP

IOS XR offers two ways to control NEXT_HOP explicitly, differing in granularity.

Method	Granularity	Purpose
`next-hop-self`	Per neighbor	Set `NEXT_HOP` to the local address for every route advertised to that peer
`set next-hop` in a route policy	Per prefix	Set `NEXT_HOP` to a given value only for routes matching a condition

IOS XR next-hop-self configuration (per neighbor)
router bgp <AS number>
 neighbor <peer address>
  address-family ipv4 unicast
   next-hop-self

IOS XR set next-hop configuration via a route policy (per prefix)
prefix-set <prefix set name>
  <prefix>
end-set
!
route-policy <policy name>
  if destination in <prefix set name> then
    set next-hop <address>
  endif
  pass
end-policy
!
router bgp <AS number>
 neighbor <peer address>
  address-family ipv4 unicast
   route-policy <policy name> out

These cancel third-party next hop when you deliberately want traffic to pass through yourself (for measurement or filtering).

Verification on Real Hardware

Four XRd 26.1.1 routers and one L2 switch confirm the following.

Third-party next hop occurs on a shared segment
The same route carries a different NEXT_HOP depending on the peer
next-hop-self cancels it (per neighbour)
set next-hop in a route policy cancels it as well (per prefix)

NEXT_HOP verification topology. R1 (AS 65001), R2 (AS 65002) and R3 (AS 65003) attach to the shared segment 10.0.123.0/24 through one L2 switch, and the only eBGP peerings are R1-R2 and R2-R3. R1 and R4 are connected inside AS 65001 by iBGP and OSPF

R1, R2 and R3 attach to the shared segment 10.0.123.0/24
The only eBGP peerings are R1 - R2 and R2 - R3; R1 and R3 are not peers
R3 advertises 192.168.3.0/24, and we follow its NEXT_HOP as it reaches R1 via R2
R4 in AS 65001 peers with R1 over iBGP and OSPF, to see how it propagates into the AS

Router	AS	Address on the shared segment	Advertised network
R1	65001	10.0.123.1	192.168.1.0/24
R2	65002	10.0.123.2	192.168.2.0/24
R3	65003	10.0.123.3	192.168.3.0/24
R4	65001	(not attached; point-to-point with R1)	192.168.4.0/24

STEP	Operation	What it shows
0	Initial state (the policies only contain `pass`)	A third-party next hop appears (R1 sees `10.0.123.3` as the `NEXT_HOP` for `192.168.3.0/24`). R1 reaches R3 in one hop. On R4, only the locally originated `192.168.1.0/24` has R1’s Lo0 as its `NEXT_HOP`
1	`next-hop-self` on R2 toward R1	The third party can be turned off (the disabling that the RFC makes mandatory). R1’s path to R3 now includes R2 as one more hop
2	Removing `next-hop-self`	Back to the third-party next hop
3	`set next-hop` on R2 toward R1 (only for `192.168.3.0/24`)	It can be turned off per prefix; `192.168.2.0/24` is unaffected
4	Returning the route policy body to `pass`	Back again
5	`next-hop-self` on R1 toward R4 (the iBGP side)	The `NEXT_HOP` distributed inside the AS becomes R1’s Lo0
6	Removing the shared segment from OSPF on R1	With `next-hop-self` in place, R4 is unaffected
7	Removing `next-hop-self` on R1	R4 can no longer resolve the `NEXT_HOP`, so it shows `(inaccessible)` and forwarding stops
8	Restoring `next-hop-self` on R1 (final state)	It recovers

Captures were taken per STEP on four links: R1 - switch, R2 - switch, R3 - switch and R1 - R4.

STEP 0: A Third-Party Next Hop on the Shared Segment

Of the two routes R2 advertises to R1, only 192.168.3.0/24, which originates from R3, has R3’s address as its Next Hop. R2’s own 192.168.2.0/24 carries R2’s address.

Routes R2 advertises to R1 (STEP 0)
RP/0/RP0/CPU0:R2#show bgp neighbors 10.0.123.1 advertised-routes
<snip>
Network            Next Hop        From            AS Path
192.168.2.0/24     10.0.123.2      Local           65002i
192.168.3.0/24     10.0.123.3      10.0.123.3      65002 65003i
<snip>
Processed 2 prefixes, 2 paths

R1 sees the same thing: the NEXT_HOP of 192.168.3.0/24 is 10.0.123.3 while the router that advertised it is 10.0.123.2. That gap between the two is the third-party next hop.

R1: 192.168.3.0/24 (STEP 0)
RP/0/RP0/CPU0:R1#show bgp 192.168.3.0/24
<snip>
Paths: (1 available, best #1)
<snip>
  Path #1: Received by speaker 0
<snip>
  65002 65003, (received & used)
    10.0.123.3 from 10.0.123.2 (10.0.0.2)
      Origin IGP, localpref 100, valid, external, best, group-best

Packets from R1 to R3 cross the shared segment only once.

traceroute from R1 to 192.168.3.1 (STEP 0)
RP/0/RP0/CPU0:R1#traceroute 192.168.3.1 source 192.168.1.1 probe 3 timeout 1 maxttl 5
<snip>
Type escape sequence to abort.
Tracing the route to 192.168.3.1
<snip>
 1  10.0.123.3 8 msec  *  8 msec 

The NEXT_HOP reaches R4 inside the AS unchanged. On the other hand, 192.168.1.0/24, which R1 originates itself, has been rewritten to R1’s Loopback0 (10.0.0.1). Even over iBGP, a locally originated route carries the speaker’s own address.

R4: show bgp (STEP 0)
RP/0/RP0/CPU0:R4#show bgp
<snip>
   Network            Next Hop            Metric LocPrf Weight Path
*>i192.168.1.0/24     10.0.0.1                 0    100      0 i
*>i192.168.2.0/24     10.0.123.2               0    100      0 65002 i
*>i192.168.3.0/24     10.0.123.3                    100      0 65002 65003 i
<snip>
Processed 4 prefixes, 4 paths

R4: 192.168.3.0/24 (STEP 0)
RP/0/RP0/CPU0:R4#show bgp 192.168.3.0/24
<snip>
Paths: (1 available, best #1)
<snip>
  Path #1: Received by speaker 0
<snip>
  65002 65003, (received & used)
    10.0.123.3 (metric 2) from 10.0.0.1 (10.0.0.1)
      Origin IGP, localpref 100, valid, internal, best, group-best

R4: 192.168.1.0/24, originated by R1 (STEP 0)
RP/0/RP0/CPU0:R4#show bgp 192.168.1.0/24
<snip>
Paths: (1 available, best #1)
<snip>
  Path #1: Received by speaker 0
<snip>
  Local, (received & used)
    10.0.0.1 (metric 2) from 10.0.0.1 (10.0.0.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best, group-best

The NEXT_HOP is resolved recursively. R4 resolves 10.0.123.3 through the shared-segment route it learned from OSPF.

Recursive resolution on R4 (STEP 0)
RP/0/RP0/CPU0:R4#show cef 192.168.3.0/24
<snip>
192.168.3.0/24, version 12, internal 0x5000001 0x40 (ptr 0x8851b4d0) [1], 0x0 (0x0), 0x0 (0x0)
<snip>
   via 10.0.123.3/32, 3 dependencies, recursive [flags 0x6000]
<snip>
    next hop 10.0.123.3/32 via 10.0.123.0/24

Confirming It in the Packets

Within a single frame, R2 advertises two prefixes with different NEXT_HOP values: 10.0.123.3 (R3) for 192.168.3.0/24 and 10.0.123.2 for its own 192.168.2.0/24.

The STEP 0 capture does not contain this UPDATE, because the session was already established before STEP 0 began and the advertisement had finished earlier. The output below is the re-advertisement that happened in STEP 2 when next-hop-self was removed; the NEXT_HOP is the same as in STEP 0.

STEP 2, No.1 (R2 to R1), tshark -V
Border Gateway Protocol - UPDATE Message
<snip>
        Path Attribute - MP_REACH_NLRI
<snip>
            Next hop: 10.0.123.3
<snip>
                    MP Reach NLRI IPv4 prefix: 192.168.3.0
<snip>
        Path Attribute - AS_PATH: 65002 65003 

Download the pcap of the packet in the tshark output above (No.1 UPDATE)

STEP 1: Pinning It to the Local Address with next-hop-self

Add next-hop-self to R2’s neighbor toward R1. This is the mechanism behind the requirement in RFC 4271 section 5.1.3 that a speaker must be able to disable the advertisement of third-party next hops.

Configuration committed on R2 in STEP 1
RP/0/RP0/CPU0:R2#show configuration commit changes last 1
Sun Oct  4 13:12:02.032 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router bgp 65002
 neighbor 10.0.123.1
  address-family ipv4 unicast
   next-hop-self
  !
 !
!
end

The NEXT_HOP of 192.168.3.0/24 changes to R2’s address.

R1: 192.168.3.0/24 (STEP 1)
RP/0/RP0/CPU0:R1#show bgp 192.168.3.0/24
<snip>
Paths: (1 available, best #1)
<snip>
  Path #1: Received by speaker 0
<snip>
  65002 65003, (received & used)
    10.0.123.2 from 10.0.123.2 (10.0.0.2)
      Origin IGP, localpref 100, valid, external, best, group-best

Forwarding changes with it: packets from R1 to R3 now go through R2 and cross the shared segment twice.

traceroute from R1 to 192.168.3.1 (STEP 1)
RP/0/RP0/CPU0:R1#traceroute 192.168.3.1 source 192.168.1.1 probe 3 timeout 1 maxttl 5
<snip>
Type escape sequence to abort.
Tracing the route to 192.168.3.1
<snip>
 1  10.0.123.2 59 msec  7 msec  6 msec 
 2  10.0.123.3 9 msec  *  9 msec 

STEP 2: Removing next-hop-self

Returning the configuration to the state of STEP 0 brings the third-party NEXT_HOP back.

Configuration committed on R2 in STEP 2
RP/0/RP0/CPU0:R2#show configuration commit changes last 1
Sun Oct  4 13:17:47.074 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router bgp 65002
 neighbor 10.0.123.1
  address-family ipv4 unicast
   no next-hop-self
  !
 !
!
end

R1: 192.168.3.0/24 (STEP 2)
RP/0/RP0/CPU0:R1#show bgp 192.168.3.0/24
<snip>
Paths: (1 available, best #1)
<snip>
  Path #1: Received by speaker 0
<snip>
  65002 65003, (received & used)
    10.0.123.3 from 10.0.123.2 (10.0.0.2)
      Origin IGP, localpref 100, valid, external, best, group-best

STEP 3: Rewriting Per Prefix with a Route Policy

A prefix-set selects only 192.168.3.0/24, and set next-hop points it at R2’s address.

Configuration committed on R2 in STEP 3
RP/0/RP0/CPU0:R2#show configuration commit changes last 1
Sun Oct  4 13:23:32.337 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
prefix-set NH-TARGET
  192.168.3.0/24
end-set
!
route-policy TO-R1
  if destination in NH-TARGET then
    set next-hop 10.0.123.2
  endif
  pass
end-policy
!
end

The result is the same as next-hop-self, but the scope is limited to the routes the policy matches. The From column shows that 192.168.3.0/24 is still the route received from R3 while its Next Hop is now R2.

Routes R2 advertises to R1 (STEP 3)
RP/0/RP0/CPU0:R2#show bgp neighbors 10.0.123.1 advertised-routes
<snip>
Network            Next Hop        From            AS Path
192.168.2.0/24     10.0.123.2      Local           65002i
192.168.3.0/24     10.0.123.2      10.0.123.3      65002 65003i
<snip>
Processed 2 prefixes, 2 paths

192.168.3.0/24 is the only route that becomes a third party in this topology, so the output cannot show that the other routes are unaffected (192.168.2.0/24 is R2’s own route, and its NEXT_HOP is R2’s address either way). The per-prefix scope is read from the prefix-set condition above.

STEP 4: Removing the Route Policy

Returning the policy body to pass brings the third party back.

Configuration committed on R2 in STEP 4
RP/0/RP0/CPU0:R2#show configuration commit changes last 1
Sun Oct  4 13:29:17.233 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
route-policy TO-R1
  pass
end-policy
!
end

R1: 192.168.3.0/24 (STEP 4)
RP/0/RP0/CPU0:R1#show bgp 192.168.3.0/24
<snip>
Paths: (1 available, best #1)
<snip>
  Path #1: Received by speaker 0
<snip>
  65002 65003, (received & used)
    10.0.123.3 from 10.0.123.2 (10.0.0.2)
      Origin IGP, localpref 100, valid, external, best, group-best

STEP 5: Cancelling the Third Party on the iBGP Side

Everything so far concerns the eBGP session between R2 and R1. R1 decides the NEXT_HOP that is distributed inside the AS. Add next-hop-self to R1’s neighbor toward R4.

Configuration committed on R1 in STEP 5
RP/0/RP0/CPU0:R1#show configuration commit changes last 1
Sun Oct  4 13:35:03.446 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router bgp 65001
 neighbor 10.0.0.4
  address-family ipv4 unicast
   next-hop-self
  !
 !
!
end

What R1 itself sees is still 10.0.123.3; only the value R4 receives becomes R1’s Loopback0.

R1: 192.168.3.0/24 (STEP 5)
RP/0/RP0/CPU0:R1#show bgp 192.168.3.0/24
<snip>
Paths: (1 available, best #1)
<snip>
  Path #1: Received by speaker 0
<snip>
  65002 65003, (received & used)
    10.0.123.3 from 10.0.123.2 (10.0.0.2)
      Origin IGP, localpref 100, valid, external, best, group-best

R4: 192.168.3.0/24 (STEP 5)
RP/0/RP0/CPU0:R4#show bgp 192.168.3.0/24
<snip>
Paths: (1 available, best #1)
<snip>
  Path #1: Received by speaker 0
<snip>
  65002 65003, (received & used)
    10.0.0.1 (metric 2) from 10.0.0.1 (10.0.0.1)
      Origin IGP, localpref 100, valid, internal, best, group-best

STEP 6: Removing the Shared Segment from OSPF

Remove R1’s shared-segment interface from OSPF. The other routers in the AS no longer know 10.0.123.0/24.

Configuration committed on R1 in STEP 6
RP/0/RP0/CPU0:R1#show configuration commit changes last 1
Sun Oct  4 13:40:43.318 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router ospf 1
 area 0
  no interface GigabitEthernet0/0/0/0
 !
!
end

With next-hop-self in place, R4 is unaffected. The NEXT_HOP it receives is R1’s Loopback0, which OSPF can resolve.

R4: 192.168.3.0/24 (STEP 6)
RP/0/RP0/CPU0:R4#show bgp 192.168.3.0/24
<snip>
Paths: (1 available, best #1)
<snip>
  Path #1: Received by speaker 0
<snip>
  65002 65003, (received & used)
    10.0.0.1 (metric 2) from 10.0.0.1 (10.0.0.1)
      Origin IGP, localpref 100, valid, internal, best, group-best

Reachability from R4 to 192.168.3.1 (STEP 6)
RP/0/RP0/CPU0:R4#ping 192.168.3.1 source 192.168.4.1 count 50 timeout 1
<snip>
Type escape sequence to abort.
<snip>
Success rate is 100 percent (50/50), round-trip min/avg/max = 7/8/26 ms

STEP 7: Removing next-hop-self Makes the Route Unusable

Remove next-hop-self from R1. The NEXT_HOP R4 receives returns to the third-party 10.0.123.3, but R4 cannot resolve it because the shared segment is no longer in OSPF.

Configuration committed on R1 in STEP 7
RP/0/RP0/CPU0:R1#show configuration commit changes last 1
Sun Oct  4 13:46:25.158 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router bgp 65001
 neighbor 10.0.0.4
  address-family ipv4 unicast
   no next-hop-self
  !
 !
!
end

The route becomes (inaccessible) and drops out of the best path.

R4: 192.168.3.0/24 (STEP 7)
RP/0/RP0/CPU0:R4#show bgp 192.168.3.0/24
<snip>
Paths: (1 available, no best path)
<snip>
  Path #1: Received by speaker 0
<snip>
  65002 65003, (received & used)
    10.0.123.3 (inaccessible) from 10.0.0.1 (10.0.0.1)
      Origin IGP, localpref 100, valid, internal

Forwarding stops as well.

Reachability from R4 to 192.168.3.1 (STEP 7)
RP/0/RP0/CPU0:R4#ping 192.168.3.1 source 192.168.4.1 count 50 timeout 1
<snip>
Type escape sequence to abort.
<snip>
Success rate is 0 percent (0/50)

This is why next-hop-self is used where several eBGP peers share one segment, such as at an IX. A third-party NEXT_HOP is an address on that segment, so it is only usable if every router in the AS has a route to the segment. Replacing it with the speaker’s own address leaves the AS with addresses the IGP can resolve.

STEP 8: Restoring next-hop-self

Restoring it makes the route resolvable again and forwarding recovers. This is the final state.

Configuration committed on R1 in STEP 8
RP/0/RP0/CPU0:R1#show configuration commit changes last 1
Sun Oct  4 13:53:44.515 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router bgp 65001
 neighbor 10.0.0.4
  address-family ipv4 unicast
   next-hop-self
  !
 !
!
end

R4: 192.168.3.0/24 (final state)
RP/0/RP0/CPU0:R4#show bgp 192.168.3.0/24
<snip>
Paths: (1 available, best #1)
<snip>
  Path #1: Received by speaker 0
<snip>
  65002 65003, (received & used)
    10.0.0.1 (metric 2) from 10.0.0.1 (10.0.0.1)
      Origin IGP, localpref 100, valid, internal, best, group-best

Reachability from R4 to 192.168.3.1 (final state)
RP/0/RP0/CPU0:R4#ping 192.168.3.1 source 192.168.4.1 count 50 timeout 1
<snip>
Type escape sequence to abort.
<snip>
Success rate is 100 percent (50/50), round-trip min/avg/max = 7/10/49 ms

Verification Configs and show Output

For every STEP, the following files were collected from all four routers, split per router. The verification configs are these ..._run.txt files (the final state is the one from the last STEP).

File	Contents
`..._show.txt`	`show version` / `show interface description` / `show route` plus the full BGP and OSPF state (including `show bgp nexthops`, `advertised-routes` / `routes` / `received routes` per neighbor, and `show cef`)
`..._log.txt`	`show logging` limited to that STEP
`..._run.txt`	`show running-config` at that STEP (that is, the verification config for the STEP)
`..._ping.txt`	`ping` and `traceroute` results for that STEP
`..._trace.txt`	`show bgp trace neighbor` / `show bgp trace error`
`..._commit.cfg`	Only the configuration actually committed in that STEP (routers whose configuration changed)

STEP 0: Initial state (the policies only contain pass)

Router	show	syslog	running-config	ping	trace	commit
R1	show	log	run	ping	trace	—
R2	show	log	run	—	trace	—
R3	show	log	run	ping	trace	—
R4	show	log	run	ping	trace	—

STEP 1: next-hop-self on R2 toward R1

Router	show	syslog	running-config	ping	trace	commit
R1	show	log	run	ping	trace	—
R2	show	log	run	—	trace	commit
R3	show	log	run	ping	trace	—
R4	show	log	run	ping	trace	—

STEP 2: Removing next-hop-self (back to the configuration of STEP 0)

Router	show	syslog	running-config	ping	trace	commit
R1	show	log	run	ping	trace	—
R2	show	log	run	—	trace	commit
R3	show	log	run	ping	trace	—
R4	show	log	run	ping	trace	—

STEP 3: set next-hop on R2 toward R1 (only for 192.168.3.0/24)

Router	show	syslog	running-config	ping	trace	commit
R1	show	log	run	ping	trace	—
R2	show	log	run	—	trace	commit
R3	show	log	run	ping	trace	—
R4	show	log	run	ping	trace	—

STEP 4: Returning the route policy body to pass

Router	show	syslog	running-config	ping	trace	commit
R1	show	log	run	ping	trace	—
R2	show	log	run	—	trace	commit
R3	show	log	run	ping	trace	—
R4	show	log	run	ping	trace	—

STEP 5: next-hop-self on R1 toward R4 (the iBGP side)

Router	show	syslog	running-config	ping	trace	commit
R1	show	log	run	ping	trace	commit
R2	show	log	run	—	trace	—
R3	show	log	run	ping	trace	—
R4	show	log	run	ping	trace	—

STEP 6: Removing the shared segment from OSPF on R1

Router	show	syslog	running-config	ping	trace	commit
R1	show	log	run	ping	trace	commit
R2	show	log	run	—	trace	—
R3	show	log	run	ping	trace	—
R4	show	log	run	ping	trace	—

STEP 7: Removing next-hop-self on R1 (the NEXT_HOP can no longer be resolved)

Router	show	syslog	running-config	ping	trace	commit
R1	show	log	run	ping	trace	commit
R2	show	log	run	—	trace	—
R3	show	log	run	ping	trace	—
R4	show	log	run	ping	trace	—

STEP 8: Restoring next-hop-self on R1 (final state)

Router	show	syslog	running-config	ping	trace	commit
R1	show	log	run	ping	trace	commit
R2	show	log	run	—	trace	—
R3	show	log	run	ping	trace	—
R4	show	log	run	ping	trace	—

Packet captures were taken per STEP on four links.

STEP	R1 - switch	R2 - switch	R3 - switch	R1 - R4
0	pcap	pcap	pcap	pcap
1	pcap	pcap	pcap	pcap
2	pcap	pcap	pcap	pcap
3	pcap	pcap	pcap	pcap
4	pcap	pcap	pcap	pcap
5	pcap	pcap	pcap	pcap
6	pcap	pcap	pcap	pcap
7	pcap	pcap	pcap	pcap
8	pcap	pcap	pcap	pcap

References

RFC 4271 - A Border Gateway Protocol 4 (BGP-4) section 5.1.3 (how NEXT_HOP is set, third-party next hop, recursive lookup)