BGP next-hop-self

What Is next-hop-self?

next-hop-self rewrites the NEXT_HOP attribute to the router’s own address when advertising to an iBGP peer. iBGP leaves NEXT_HOP unchanged by default, so an address outside the AS propagates into it, and a router that cannot reach that address does not use the route.

The setting goes on the AS-border router R2 only, and it takes effect only when R2 advertises to its iBGP peer R1 (the bracket in the figure). eBGP rewrites NEXT_HOP to the advertising router’s own address, so there is no such setting on the R2 - R3 segment. eBGP does have an exception, though: on a shared subnet the address of another router may be passed on unchanged as NEXT_HOP (a third-party next hop), covered in BGP NEXT_HOP Attribute.

Why the Problem Occurs

RFC 4271 section 5.1.3 says that when advertising to an iBGP peer a speaker SHOULD NOT modify NEXT_HOP for a route it did not originate, “unless it has been explicitly configured to announce its own IP address as the NEXT_HOP”. That explicit configuration is next-hop-self. So a route the AS-border router R2 learned over eBGP propagates into the AS with NEXT_HOP still set to the address of a router outside the AS (R3’s 10.2.3.3).

The receiving router R1 looks up NEXT_HOP in its own routing table (normally an IGP route) to decide where to forward (recursive resolution). Routes that cannot be resolved SHOULD be excluded from best-path selection (RFC 4271 section 9.1.2.1). In show bgp the > disappears leaving only *, and the detailed output marks NEXT_HOP as (inaccessible). The route is not installed in the routing table either, so traffic to that destination cannot be forwarded.

This decision is made inside R1 alone. Even when 10.2.3.0/24 disappears from the IGP, R2 keeps advertising the same route with the same NEXT_HOP and sends no UPDATE.

Two Ways to Solve It

Method	What it does	Recursive resolution on R1	Caveat
`next-hop-self`	The AS-border router rewrites `NEXT_HOP` to its own address (usually a loopback) when advertising to iBGP peers	Resolves R2’s loopback (`10.0.0.2`) via the IGP	Must be configured on every AS-border router
Advertise the external link in the IGP	The AS-border router carries the link used for the eBGP peering (`10.2.3.0/24` in the example below) in the IGP	Resolves the external link (`10.2.3.0/24`) via the IGP	Routes for externally facing links enter the AS-internal IGP. More external links mean more routes and more to manage

Either way, the final forwarding decision on R1 is the same (the interface toward R2); what differs is which IGP route the recursive resolution uses. next-hop-self is the usual choice: the IGP handles only internal reachability and BGP handles connectivity outside the AS. With next-hop-self, R1 can forward to external destinations while still unable to reach 10.2.3.3.

Configuration

On IOS XR it goes under the address family of the iBGP neighbor.

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

The rewrite happens only when advertising to an iBGP peer; the NEXT_HOP in the configured router’s own BGP table does not change.

Verification on Real Devices

Four XRd 26.1.1 routers in three ASes: R1 - R2 is iBGP, R2 - R3 and R3 - R4 are eBGP.

Router	AS	Role	Advertised network
R1	65001	iBGP only (inside the AS)	192.168.1.0/24
R2	65001	AS border (eBGP with R3)	192.168.2.0/24
R3	65002	AS border (eBGP with R2 and R4)	192.168.3.0/24
R4	65003	-	192.168.4.0/24

AS 65001 runs OSPF area 0, and the iBGP session is between the Loopback0s. In the initial state R2 advertises its link to R3 (10.2.3.0/24) as an OSPF passive interface. Only R2 is changed, and in every STEP R1 sends 50 pings each to 192.168.3.1 and 192.168.4.1.

STEP	Change on R2	What to check
0	None (`10.2.3.0/24` advertised in OSPF)	The routes are valid without any rewrite. R1 resolves `10.2.3.3` through an OSPF route
1	Remove `GigabitEthernet0/0/0/1` from OSPF	On R1 the routes become `(inaccessible)` and the pings fail. R2 sends no UPDATE
2	Configure `next-hop-self`	The UPDATE carries `NEXT_HOP` `10.0.0.2`, which R1 resolves through an OSPF route. R2’s own table is unchanged
3	Remove `next-hop-self` and put `GigabitEthernet0/0/0/1` back into OSPF (final state)	`NEXT_HOP` returns to `10.2.3.3` and the resolution is the same as STEP 0

STEP 0: The External Link Is Advertised in the IGP

R1 learns 10.2.3.0/24 via OSPF.

R1 show route 10.2.3.3 (STEP 0)
RP/0/RP0/CPU0:R1#show route 10.2.3.3
Tue Sep 22 15:31:54.715 UTC

Routing entry for 10.2.3.0/24
  Known via "ospf 1", distance 110, metric 2, type intra area
  Installed Sep 22 15:19:09.072 for 00:12:45
  Routing Descriptor Blocks
    10.1.2.2, from 10.0.0.2, via GigabitEthernet0/0/0/0
      Route metric is 2
  No advertising protos. 

Although NEXT_HOP is still 10.2.3.3, every route is *>.

R1 show bgp (STEP 0)
RP/0/RP0/CPU0:R1#show bgp
Tue Sep 22 15:31:49.417 UTC
BGP router identifier 10.0.0.1, local AS number 65001
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000   RD version: 6
BGP main routing table version 6
BGP NSR Initial initsync version 3 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs

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 paths

show cef shows the forwarding entry: 192.168.3.0/24 is a recursive route via 10.2.3.3 and finally leaves through GigabitEthernet0/0/0/0 (R2, 10.1.2.2).

R1 show cef 192.168.3.0/24 (STEP 0)
RP/0/RP0/CPU0:R1#show cef 192.168.3.0/24
Tue Sep 22 15:31:54.373 UTC
192.168.3.0/24, version 11, internal 0x5000001 0x40 (ptr 0x8851b310) [1], 0x0 (0x0), 0x0 (0x0)
 Updated Sep 22 15:20:12.868 
 local adjacency to GigabitEthernet0/0/0/0

 Prefix Len 24, traffic index 0, precedence n/a, priority 4
  gateway array (0x895d88d0) reference count 2, flags 0x2010, source rib (7), 0 backups
                [1 type 3 flags 0x48501 (0x8967bcf8) ext 0x0 (0x0) (collapsed)]
  LW-LDI[type=0, refc=0, ptr=0x0, sh-ldi=0x0]
  gateway array update type-time 1 Sep 22 15:20:12.867
 LDI Update time Sep 22 15:20:12.867
   via 10.2.3.3/32, 2 dependencies, recursive [flags 0x6000]
    path-idx 0 NHID 0x0 [0x8851b5b0 0x0]
    next hop 10.2.3.3/32 via 10.2.3.0/24

    Load distribution: 0 (refcount 1)

    Hash  OK  Interface                 Address
    0     Y   GigabitEthernet0/0/0/0    10.1.2.2       

All pings succeed, and traceroute reaches R4 through R2 and R3.

R1 ping / traceroute (STEP 0)
RP/0/RP0/CPU0:R1#ping 192.168.4.1 source 192.168.1.1 count 50 timeout 1
Tue Sep 22 15:31:33.314 UTC
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 192.168.4.1 timeout is 1 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (50/50), round-trip min/avg/max = 9/12/63 ms
RP/0/RP0/CPU0:R1#traceroute 192.168.4.1 source 192.168.1.1 probe 3 timeout 1 maxttl 6
Tue Sep 22 15:31:41.091 UTC

Type escape sequence to abort.
Tracing the route to 192.168.4.1

 1  10.1.2.2 7 msec  7 msec  5 msec 
 2  10.2.3.3 10 msec  8 msec  9 msec 
 3  10.3.4.4 21 msec  *  16 msec 

STEP 1: Making NEXT_HOP Unreachable

The 10.2.3.0/24 interface is removed from R2’s OSPF (R2’s commit).

R2 removing the external link from OSPF (STEP 1, R2 commit)
RP/0/RP0/CPU0:R2#show configuration commit changes last 1
Tue Sep 22 15:34:49.281 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router ospf 1
 area 0
  no interface GigabitEthernet0/0/0/1
 !
!
end

10.2.3.0/24 disappears from R1’s routing table, and the two routes via R3 lose their >.

R1 show route 10.2.3.3 (STEP 1)
RP/0/RP0/CPU0:R1#show route 10.2.3.3
Tue Sep 22 15:38:26.396 UTC

% Network not in table

R1 show bgp (STEP 1)
RP/0/RP0/CPU0:R1#show bgp
Tue Sep 22 15:38:20.878 UTC
BGP router identifier 10.0.0.1, local AS number 65001
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000   RD version: 8
BGP main routing table version 8
BGP NSR Initial initsync version 3 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs

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 paths

The detailed output shows no best path and (inaccessible): the path is still valid, only best is gone.

R1 show bgp 192.168.3.0/24 (STEP 1)
RP/0/RP0/CPU0:R1#show bgp 192.168.3.0/24
Tue Sep 22 15:38:22.168 UTC
BGP routing table entry for 192.168.3.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                  7            7
Last Modified: Sep 22 15:34:52.023 for 00:03:30
Paths: (1 available, no best path)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  65002, (received & used)
    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 0

Only R2’s own 192.168.2.0/24 remains in the routing table, and not a single ping gets through. The !N in the traceroute means R1 itself has no route to the destination.

R1 show route bgp (STEP 1)
RP/0/RP0/CPU0:R1#show route bgp
Tue Sep 22 15:38:21.216 UTC

B    192.168.2.0/24 [200/0] via 10.0.0.2, 00:18:09

R1 ping / traceroute (STEP 1)
RP/0/RP0/CPU0:R1#ping 192.168.3.1 source 192.168.1.1 count 50 timeout 1
Tue Sep 22 15:36:24.308 UTC
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 192.168.3.1 timeout is 1 seconds:
..................................................
Success rate is 0 percent (0/50)
RP/0/RP0/CPU0:R1#ping 192.168.4.1 source 192.168.1.1 count 50 timeout 1
Tue Sep 22 15:37:15.565 UTC
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 192.168.4.1 timeout is 1 seconds:
..................................................
Success rate is 0 percent (0/50)
RP/0/RP0/CPU0:R1#traceroute 192.168.4.1 source 192.168.1.1 probe 3 timeout 1 maxttl 6
Tue Sep 22 15:38:12.857 UTC

Type escape sequence to abort.
Tracing the route to 192.168.4.1

 1  192.168.1.1 !N  *  !N 

Nothing changes on R2: it keeps advertising 10.2.3.3 as NEXT_HOP.

R2 show bgp neighbors 10.0.0.1 advertised-routes (STEP 1)
RP/0/RP0/CPU0:R2#show bgp neighbors 10.0.0.1 advertised-routes
Tue Sep 22 15:39:16.046 UTC
Network            Next Hop        From            AS Path
192.168.2.0/24     10.0.0.2        Local           i
192.168.3.0/24     10.2.3.3        10.2.3.3        65002i
192.168.4.0/24     10.2.3.3        10.2.3.3        65002 65003i

Processed 3 prefixes, 3 paths

The R1 - R2 capture confirms it: in this STEP only R2’s OSPF LS Update (the Router-LSA without 10.2.3.0/24) and BGP KEEPALIVEs were exchanged, with no BGP UPDATE at all.

R1 - R2 packet capture (STEP 1, OSPF LS Update and BGP, first 5)
 5.539208     10.1.2.2 → 224.0.0.5    OSPF 122 LS Update
28.296888     10.0.0.1 → 10.0.0.2     BGP 73 KEEPALIVE Message
59.797170     10.0.0.2 → 10.0.0.1     BGP 73 KEEPALIVE Message
88.297284     10.0.0.1 → 10.0.0.2     BGP 73 KEEPALIVE Message
119.797783     10.0.0.2 → 10.0.0.1     BGP 73 KEEPALIVE Message

STEP 2: Solving It with next-hop-self

next-hop-self is configured on R2’s iBGP neighbor (R2’s commit).

R2 configuring next-hop-self (STEP 2, R2 commit)
RP/0/RP0/CPU0:R2#show configuration commit changes last 1
Tue Sep 22 15:42:22.048 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router bgp 65001
 neighbor 10.0.0.1
  address-family ipv4 unicast
   next-hop-self
  !
 !
!
end

The Next Hop that R2 advertises to R1 becomes 10.0.0.2 (R2’s Loopback0) for all three routes.

R2 show bgp neighbors 10.0.0.1 advertised-routes (STEP 2)
RP/0/RP0/CPU0:R2#show bgp neighbors 10.0.0.1 advertised-routes
Tue Sep 22 15:45:09.426 UTC
Network            Next Hop        From            AS Path
192.168.2.0/24     10.0.0.2        Local           i
192.168.3.0/24     10.0.0.2        10.2.3.3        65002i
192.168.4.0/24     10.0.0.2        10.2.3.3        65002 65003i

Processed 3 prefixes, 3 paths

Right after the change R2 re-sends its UPDATEs to R1. No.4 in the capture is a TCP segment carrying three UPDATEs; in the one for 192.168.3.0/24 the Next hop of MP_REACH_NLRI is 10.0.0.2.

STEP 2 R1 - R2 No.4 UPDATE (R2 to R1, 192.168.3.0/24) tshark -V (excerpt)
Border Gateway Protocol - UPDATE Message
<snip>
        Path Attribute - MP_REACH_NLRI
<snip>
            Next hop: 10.0.0.2
                IPv4 Address: 10.0.0.2
<snip>
                192.168.3.0/24
<snip>
        Path Attribute - ORIGIN: IGP
<snip>
        Path Attribute - AS_PATH: 65002 
<snip>
                AS4: 65002
        Path Attribute - MULTI_EXIT_DISC: 0
<snip>
        Path Attribute - LOCAL_PREF: 100

Download the pcap of the packet in the tshark output above (STEP 2 No.4 UPDATE)

In the extracted file this packet appears as No.1. The same UPDATEs are sent again two seconds later as No.6.

On R1 the NEXT_HOP becomes 10.0.0.2 and everything is *> again. The (metric 2) in the detailed output shows that 10.0.0.2 was resolved via OSPF (metric 2).

R1 show bgp (STEP 2)
RP/0/RP0/CPU0:R1#show bgp
Tue Sep 22 15:44:14.131 UTC
BGP router identifier 10.0.0.1, local AS number 65001
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000   RD version: 10
BGP main routing table version 10
BGP NSR Initial initsync version 3 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs

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 paths

R1 show bgp 192.168.3.0/24 (STEP 2)
RP/0/RP0/CPU0:R1#show bgp 192.168.3.0/24
Tue Sep 22 15:44:14.998 UTC
BGP routing table entry for 192.168.3.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                 10           10
Last Modified: Sep 22 15:42:25.023 for 00:01:50
Paths: (1 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  65002, (received & used)
    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 10

R1 still cannot reach 10.2.3.3; instead it has learned 10.0.0.2 via OSPF.

R1 show route 10.2.3.3 (STEP 2)
RP/0/RP0/CPU0:R1#show route 10.2.3.3
Tue Sep 22 15:44:18.812 UTC

% Network not in table

R1 show route 10.0.0.2 (STEP 2)
RP/0/RP0/CPU0:R1#show route 10.0.0.2
Tue Sep 22 15:44:19.094 UTC

Routing entry for 10.0.0.2/32
  Known via "ospf 1", distance 110, metric 2, type intra area
  Installed Sep 22 15:19:09.071 for 00:25:10
  Routing Descriptor Blocks
    10.1.2.2, from 10.0.0.2, via GigabitEthernet0/0/0/0
      Route metric is 2
  No advertising protos. 

Comparing the forwarding entry with STEP 0, the recursive resolution now goes through 10.0.0.2 (via 10.0.0.2/32) instead of 10.2.3.3 (via 10.2.3.0/24), while the outgoing interface and neighbor address stay the same.

R1 show cef 192.168.3.0/24 (STEP 2)
RP/0/RP0/CPU0:R1#show cef 192.168.3.0/24
Tue Sep 22 15:44:18.622 UTC
192.168.3.0/24, version 16, internal 0x5000001 0x40 (ptr 0x8851b5b0) [1], 0x0 (0x0), 0x0 (0x0)
 Updated Sep 22 15:42:25.079 
 local adjacency to GigabitEthernet0/0/0/0

 Prefix Len 24, traffic index 0, precedence n/a, priority 4
  gateway array (0x895d7e80) reference count 3, flags 0x2010, source rib (7), 0 backups
                [1 type 3 flags 0x48501 (0x8967b930) ext 0x0 (0x0) (collapsed)]
  LW-LDI[type=0, refc=0, ptr=0x0, sh-ldi=0x0]
  gateway array update type-time 1 Sep 22 15:20:11.675
 LDI Update time Sep 22 15:20:11.675
   via 10.0.0.2/32, 2 dependencies, recursive [flags 0x6000]
    path-idx 0 NHID 0x0 [0x8851b690 0x0]
    next hop 10.0.0.2/32 via 10.0.0.2/32

    Load distribution: 0 (refcount 1)

    Hash  OK  Interface                 Address
    0     Y   GigabitEthernet0/0/0/0    10.1.2.2       

R1 show cef 192.168.3.0/24 (STEP 0)
RP/0/RP0/CPU0:R1#show cef 192.168.3.0/24
Tue Sep 22 15:31:54.373 UTC
192.168.3.0/24, version 11, internal 0x5000001 0x40 (ptr 0x8851b310) [1], 0x0 (0x0), 0x0 (0x0)
 Updated Sep 22 15:20:12.868 
 local adjacency to GigabitEthernet0/0/0/0

 Prefix Len 24, traffic index 0, precedence n/a, priority 4
  gateway array (0x895d88d0) reference count 2, flags 0x2010, source rib (7), 0 backups
                [1 type 3 flags 0x48501 (0x8967bcf8) ext 0x0 (0x0) (collapsed)]
  LW-LDI[type=0, refc=0, ptr=0x0, sh-ldi=0x0]
  gateway array update type-time 1 Sep 22 15:20:12.867
 LDI Update time Sep 22 15:20:12.867
   via 10.2.3.3/32, 2 dependencies, recursive [flags 0x6000]
    path-idx 0 NHID 0x0 [0x8851b5b0 0x0]
    next hop 10.2.3.3/32 via 10.2.3.0/24

    Load distribution: 0 (refcount 1)

    Hash  OK  Interface                 Address
    0     Y   GigabitEthernet0/0/0/0    10.1.2.2       

The pings get through again. 10.2.3.3 appears as the second traceroute hop because R3 replies from the address of its receiving interface; R1 does not need a route to that address.

R1 ping / traceroute (STEP 2)
RP/0/RP0/CPU0:R1#ping 192.168.4.1 source 192.168.1.1 count 50 timeout 1
Tue Sep 22 15:43:58.901 UTC
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 192.168.4.1 timeout is 1 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (50/50), round-trip min/avg/max = 10/17/78 ms
RP/0/RP0/CPU0:R1#traceroute 192.168.4.1 source 192.168.1.1 probe 3 timeout 1 maxttl 6
Tue Sep 22 15:44:06.776 UTC

Type escape sequence to abort.
Tracing the route to 192.168.4.1

 1  10.1.2.2 6 msec  5 msec  30 msec 
 2  10.2.3.3 9 msec  8 msec  8 msec 
 3  10.3.4.4 14 msec  *  14 msec 

Meanwhile, in the BGP table of R2 itself, where the setting was made, NEXT_HOP is still 10.2.3.3.

R2 show bgp 192.168.3.0/24 (STEP 2)
RP/0/RP0/CPU0:R2#show bgp 192.168.3.0/24
Tue Sep 22 15:45:07.288 UTC
BGP routing table entry for 192.168.3.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                  5            5
Last Modified: Sep 22 15:20:13.023 for 00:24:54
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, (received & used)
    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 5
      Origin-AS validity: (disabled)

STEP 3: Removing next-hop-self and Solving It in the IGP

next-hop-self is removed from R2 and GigabitEthernet0/0/0/1 goes back into OSPF instead (a single commit on R2).

R2 removing next-hop-self and restoring OSPF (STEP 3, R2 commit)
RP/0/RP0/CPU0:R2#show configuration commit changes last 1
Tue Sep 22 15:47:13.486 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router ospf 1
 area 0
  interface GigabitEthernet0/0/0/1
   passive enable
  !
 !
!
router bgp 65001
 neighbor 10.0.0.1
  address-family ipv4 unicast
   no next-hop-self
  !
 !
!
end

In the UPDATE R2 re-sends to R1 (No.7), Next hop is back to 10.2.3.3.

STEP 3 R1 - R2 No.7 UPDATE (R2 to R1, 192.168.3.0/24) tshark -V (excerpt)
Border Gateway Protocol - UPDATE Message
<snip>
        Path Attribute - MP_REACH_NLRI
<snip>
            Next hop: 10.2.3.3
                IPv4 Address: 10.2.3.3
<snip>
                192.168.3.0/24
<snip>
        Path Attribute - ORIGIN: IGP
<snip>
        Path Attribute - AS_PATH: 65002 
<snip>
                AS4: 65002
        Path Attribute - MULTI_EXIT_DISC: 0
<snip>
        Path Attribute - LOCAL_PREF: 100

Download the pcap of the packet in the tshark output above (STEP 3 No.7 UPDATE)

R1 can resolve 10.2.3.3 via OSPF, so the routes stay valid. The via in the routing table returns to 10.2.3.3, and the pings get through.

R1 show route bgp (STEP 3)
RP/0/RP0/CPU0:R1#show route bgp
Tue Sep 22 15:49:05.515 UTC

B    192.168.2.0/24 [200/0] via 10.0.0.2, 00:28:54
B    192.168.3.0/24 [200/0] via 10.2.3.3, 00:01:49
B    192.168.4.0/24 [200/0] via 10.2.3.3, 00:01:49

R1 show cef 192.168.3.0/24 (STEP 3)
RP/0/RP0/CPU0:R1#show cef 192.168.3.0/24
Tue Sep 22 15:49:09.873 UTC
192.168.3.0/24, version 20, internal 0x5000001 0x40 (ptr 0x8851b5b0) [1], 0x0 (0x0), 0x0 (0x0)
 Updated Sep 22 15:47:16.482 
 local adjacency to GigabitEthernet0/0/0/0

 Prefix Len 24, traffic index 0, precedence n/a, priority 4
  gateway array (0x895d88d0) reference count 2, flags 0x2010, source rib (7), 0 backups
                [1 type 3 flags 0x48501 (0x8967bcf8) ext 0x0 (0x0) (collapsed)]
  LW-LDI[type=0, refc=0, ptr=0x0, sh-ldi=0x0]
  gateway array update type-time 1 Sep 22 15:47:16.482
 LDI Update time Sep 22 15:47:16.482
   via 10.2.3.3/32, 2 dependencies, recursive [flags 0x6000]
    path-idx 0 NHID 0x0 [0x8851b230 0x0]
    next hop 10.2.3.3/32 via 10.2.3.0/24

    Load distribution: 0 (refcount 1)

    Hash  OK  Interface                 Address
    0     Y   GigabitEthernet0/0/0/0    10.1.2.2       

R1 ping (STEP 3)
RP/0/RP0/CPU0:R1#ping 192.168.4.1 source 192.168.1.1 count 50 timeout 1
Tue Sep 22 15:48:49.792 UTC
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 192.168.4.1 timeout is 1 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (50/50), round-trip min/avg/max = 10/12/31 ms

Verification Configs and show Output

Each STEP captures the following files from all four routers, one file per router and kind. The verification config is the ..._run.txt (final state: STEP 3).

File	Contents
`..._show.txt`	`show version` / `show interface description` / `show route` / `show bgp` / `show bgp summary` / `show route bgp` / `show bgp <prefix>` (four prefixes) / `show bgp neighbors` / per-peer `advertised-routes`, `routes` and `received routes` / `show bgp update-group` / `show bgp process` / `show rpl route-policy`. R1 and R2 also include `show ospf neighbor` / `show route ospf`; R1 also includes `show route 192.168.3.0/24` / `show cef 192.168.3.0/24` / `show route 10.2.3.3` / `show route 10.0.0.2`
`..._log.txt`	`show logging` limited to that STEP: a `logmsg` marker was placed at the start of each STEP and its time passed to `show logging start`
`..._run.txt`	`show running-config` at that STEP (the verification config for that STEP)
`..._ping.txt`	`ping` (50 packets) and `traceroute`: R1 to `192.168.3.1` and `192.168.4.1`, R2 to `192.168.4.1`, R4 to `192.168.1.1`. R1’s ping to `10.2.3.3` (source `10.0.0.1`) gets no reply in any STEP because R3 has no route to `10.0.0.1`
`..._trace.txt`	`show bgp trace neighbor` and `show bgp trace error` (events inside the BGP process)
`..._commit.cfg`	The configuration actually committed in that STEP (R2 only)

STEP 0: initial state (10.2.3.0/24 advertised in OSPF)

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

STEP 1: remove GigabitEthernet0/0/0/1 from OSPF

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

STEP 2: configure next-hop-self

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

STEP 3: remove next-hop-self and put GigabitEthernet0/0/0/1 back into OSPF (final state)

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

Packet captures were taken per STEP.

STEP	R1 - R2	R2 - R3
0	pcap	pcap
1	pcap	pcap
2	pcap	pcap
3	pcap	pcap

References

Source	Title	Summary
RFC 4271	A Border Gateway Protocol 4 (BGP-4)	The BGP-4 base specification. Section 5.1.3 defines how `NEXT_HOP` is handled for iBGP and eBGP, and section 9.1.2.1 how routes with an unresolvable `NEXT_HOP` are treated.
IANA	Border Gateway Protocol (BGP) Parameters	Registry of numbers used in BGP.