BGP NEXT_HOP Attribute

What NEXT_HOP Is

NEXT_HOP (Type code 3) is the path attribute that carries the IP address of the router a packet should be handed to next on its way to the destination. As covered in BGP Path Attributes and Best Path Selection, it is classified as well-known mandatory and is always present in an UPDATE.

What makes it confusing is that NEXT_HOP is not necessarily “the address of the router that advertised the route.” It points at where to forward packets, and it matches the advertising router only because the two usually happen to be the same. The case where they diverge is third-party next hop (below), and that is the subject of this article.

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. There are two basic rules.

Advertised to	Behavior
eBGP peer	Rewrite `NEXT_HOP` to its own address (the address of the interface used to reach that peer)
iBGP peer	Do not rewrite `NEXT_HOP` (pass the received value through unchanged)

It is not rewritten on iBGP because no AS boundary has been crossed. Within an AS the IGP is assumed to know how to reach the exit point, so the design preserves the information about “where the route leaves the AS.” The reachability problem this design causes, and how to solve it, is covered in BGP next-hop-self.

On top of that, the eBGP side has the following exception.

Third-Party Next Hop on a Shared Segment

RFC 4271 section 5.1.3 states that when advertising to an eBGP peer, if a more appropriate forwarder sits on the same subnet as that peer, its address may be passed through as is. This is third-party next hop. “Third party” refers to a router that is neither the one advertising (second party) nor the one receiving (first party).

Concretely, it appears when three or more routers share one L2 segment but only two pairs among them are BGP peers.

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 its own address here, packets from R1 would traverse the same segment twice as “R1 → R2 → R3.” Since R1 can talk to R3 directly, that is wasteful. So R2 hands R1 the NEXT_HOP of R3 unchanged, letting R1 send directly to R3.

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 5.1.3 has a rule in the other direction as well: if NEXT_HOP would be the address of the peer being advertised to, it must be replaced with the advertising router’s own address. Otherwise, when R2 returns a route learned from R1 back to R1, leaving NEXT_HOP as R1 would tell R1 to forward to itself.

Because these two rules are evaluated per peer, the same route can carry a different NEXT_HOP depending on who receives it. In the verification below, we observe R2 sending different NEXT_HOP values to R1 and R3 at the same moment on real hardware.

Third-party next hop only applies when the BGP peers share the same subnet. In a topology where routers are connected point-to-point one to one, there is no third router on the same segment, so it never occurs.

Recursive Lookup and NEXT_HOP Reachability

A BGP route is usable only once the NEXT_HOP address can be resolved in the routing table. BGP looks up a route toward the NEXT_HOP, then borrows that route’s outgoing interface and forwarding address to do the actual forwarding. This is called a recursive lookup.

If the lookup fails, the route is treated as invalid: it is not selected as the best path and does not enter the routing table. In show bgp the > (best) marker disappears, and the detailed output shows (inaccessible) next to the NEXT_HOP.

With third-party next hop, the NEXT_HOP is a directly connected address on the shared segment, so the receiving router resolves it via a connected route. The problem arises when that route is then distributed further into the AS over iBGP. Since NEXT_HOP is not rewritten, it propagates through the AS unchanged, so other routers in the AS must also be able to reach the shared segment. In the verification, R4 inside AS 65001 is in exactly this position and resolves it because OSPF gives it a route to the shared segment.

Two Ways to Rewrite NEXT_HOP

IOS XR offers two ways to control NEXT_HOP explicitly. They differ in the granularity they apply to.

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

Third-party next hop is an optimization that makes traffic go straight to another router on the same segment, so these are what you use to cancel it when you deliberately want the traffic to pass through yourself (to measure it, to run it through a filter, and so on).

Verification on Real Hardware

Using a lab of four XRd (IOS XR 26.1.1) routers and one L2 switch, we confirm the following four points.

That third-party next hop actually occurs on a shared segment
That the same route carries a different NEXT_HOP depending on the peer it is advertised to
That next-hop-self cancels it (per neighbor)
That 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

The key points of the setup are as follows.

R1, R2 and R3 attach to one shared segment 10.0.123.0/24. All three sit on the same L2 segment behind the switch
The only eBGP peerings are R1 - R2 and R2 - R3. R1 and R3 are on the same segment but are not BGP peers
R3 advertises 192.168.3.0/24. We follow the NEXT_HOP of this route as it reaches R1 by way of R2
R4 is placed in AS 65001, connected to R1 by iBGP (Loopback0 to Loopback0) and OSPF area 0, so we can see how third-party next hop propagates into the AS over iBGP

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

Here is what changes in each STEP. Only R2 is reconfigured.

STEP	Operation on R2
0	Only the `PASS-ALL` policy (initial state)
1	`next-hop-self` on the neighbor toward R1
2	Remove `next-hop-self` (the configuration returns to exactly STEP 0)
3	Route policy `NH-OVERRIDE` toward R1 (`set next-hop 10.0.123.2` for `192.168.3.0/24` only)
4	Remove the route policy (the configuration returns to exactly STEP 0)

Packet captures are taken on the R1 - switch link and the R3 - switch link (tcp port 179).

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

These are the routes R2 advertises to R1. Only 192.168.3.0/24 has a Next Hop of 10.0.123.3 (R3). The other three carry R2’s own 10.0.123.2.

R2 (AS 65002): show bgp neighbors 10.0.123.1 advertised-routes
Network            Next Hop        From            AS Path
192.168.1.0/24     10.0.123.2      10.0.123.1      65002 65001i
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
192.168.4.0/24     10.0.123.2      10.0.123.1      65002 65001i

Processed 4 prefixes, 4 paths

At the same moment, this is what R2 advertises to R3. The Next Hop of 192.168.3.0/24 has become 10.0.123.2 (R2 itself), while 192.168.1.0/24 and 192.168.4.0/24 now carry 10.0.123.1 (R1) instead.

R2: show bgp neighbors 10.0.123.3 advertised-routes
Network            Next Hop        From            AS Path
192.168.1.0/24     10.0.123.1      10.0.123.1      65002 65001i
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
192.168.4.0/24     10.0.123.1      10.0.123.1      65002 65001i

Processed 4 prefixes, 4 paths

Putting the two side by side shows that R2 decides NEXT_HOP per peer.

Prefix	Advertised to R1	Advertised to R3	Rule applied
192.168.3.0/24 (from R3)	`10.0.123.3`	`10.0.123.2`	To R1, hand over the third party R3. To R3 it would be “the peer’s own address,” so replace it with self
192.168.1.0/24 (from R1)	`10.0.123.2`	`10.0.123.1`	To R3, hand over the third party R1. To R1 it would be “the peer’s own address,” so replace it with self
192.168.2.0/24 (from R2)	`10.0.123.2`	`10.0.123.2`	R2 originates it, so it is always its own address

Here is R1’s view. 192.168.3.0/24 was advertised by 10.0.123.2 (R2), but the NEXT_HOP is 10.0.123.3 (R3). The address shown just before from is the NEXT_HOP; the one after from is the advertiser.

R1 (AS 65001): show bgp 192.168.3.0/24
BGP routing table entry for 192.168.3.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                  6            6
Last Modified: Sep  7 14:41:33.774 for 00:01:47
Paths: (1 available, best #1)
  Advertised IPv4 Unicast paths to peers (in unique update groups):
    10.0.0.4        
  Path #1: Received by speaker 0
  Advertised IPv4 Unicast paths to peers (in unique update groups):
    10.0.0.4        
  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
      Received Path ID 0, Local Path ID 1, version 6
      Origin-AS validity: (disabled)

It also enters the routing table with 10.0.123.3.

R1: show route bgp
B    192.168.2.0/24 [20/0] via 10.0.123.2, 00:02:01
B    192.168.3.0/24 [20/0] via 10.0.123.3, 00:01:47
B    192.168.4.0/24 [200/0] via 10.0.0.4, 00:02:01

The traceroute reaches R3 directly without going through R2 — one hop.

R1: traceroute 192.168.3.1 source Loopback1
Type escape sequence to abort.
Tracing the route to 192.168.3.1

 1  10.0.123.3 23 msec  *  11 msec

Here is R4 inside AS 65001. It received the route from R1 over iBGP, and because iBGP does not rewrite NEXT_HOP, the value is still 10.0.123.3. R4 has an OSPF route to the shared segment 10.0.123.0/24, so the recursive lookup succeeds, as shown by (metric 2).

R4 (AS 65001): show bgp 192.168.3.0/24
BGP routing table entry for 192.168.3.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                  6            6
Last Modified: Sep  7 14:41:33.774 for 00:03:19
Paths: (1 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  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
      Received Path ID 0, Local Path ID 1, version 6

The traceroute from R4 does not go through R2 either. It passes R1 onto the shared segment and goes straight to R3.

R4: traceroute 192.168.3.1 source Loopback1
Type escape sequence to abort.
Tracing the route to 192.168.3.1

 1  10.1.4.1 6 msec  4 msec  4 msec 
 2  10.0.123.3 10 msec  *  11 msec

Confirming It in the Packets

No.40 in the R1 - switch capture (bgp-next-hop-r1sw.pcap) is the UPDATE sent from R2 to R1. A single TCP segment carries two UPDATEs, and each has a different NEXT_HOP. The output below is Wireshark’s tshark detail view, with the flag bit breakdown elided as <snip>.

The first one is 192.168.3.0/24, whose Next hop is 10.0.123.3 (R3).

No.40 R2 → R1 UPDATE (first, 192.168.3.0/24) tshark -V
Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 57
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 34
    Path attributes
        Path Attribute - MP_REACH_NLRI
            Flags: 0x90, Optional, Extended-Length, Non-transitive, Complete
<snip>
            Type Code: MP_REACH_NLRI (14)
            Length: 13
            Address family identifier (AFI): IPv4 (1)
            Subsequent address family identifier (SAFI): Unicast (1)
            Next hop: 10.0.123.3
                IPv4 Address: 10.0.123.3
            Number of Subnetwork points of attachment (SNPA): 0
            Network Layer Reachability Information (NLRI)
                192.168.3.0/24
                    MP Reach NLRI prefix length: 24
                    MP Reach NLRI IPv4 prefix: 192.168.3.0
        Path Attribute - ORIGIN: IGP
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: ORIGIN (1)
            Length: 1
            Origin: IGP (0)
        Path Attribute - AS_PATH: 65002 65003 
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: AS_PATH (2)
            Length: 10
            AS Path segment: 65002 65003
                Segment type: AS_SEQUENCE (2)
                Segment length (number of ASN): 2
                AS4: 65002
                AS4: 65003

The second one that follows is 192.168.1.0/24, whose Next hop is 10.0.123.2 (R2 itself). The two values are used differently within the same segment and even the same packet.

No.40 R2 → R1 UPDATE (second, 192.168.1.0/24) tshark -V
Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 57
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 34
    Path attributes
        Path Attribute - MP_REACH_NLRI
            Flags: 0x90, Optional, Extended-Length, Non-transitive, Complete
<snip>
            Type Code: MP_REACH_NLRI (14)
            Length: 13
            Address family identifier (AFI): IPv4 (1)
            Subsequent address family identifier (SAFI): Unicast (1)
            Next hop: 10.0.123.2
                IPv4 Address: 10.0.123.2
            Number of Subnetwork points of attachment (SNPA): 0
            Network Layer Reachability Information (NLRI)
                192.168.1.0/24
                    MP Reach NLRI prefix length: 24
                    MP Reach NLRI IPv4 prefix: 192.168.1.0
        Path Attribute - ORIGIN: IGP
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: ORIGIN (1)
            Length: 1
            Origin: IGP (0)
        Path Attribute - AS_PATH: 65002 65001 
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: AS_PATH (2)
            Length: 10
            AS Path segment: 65002 65001
                Segment type: AS_SEQUENCE (2)
                Segment length (number of ASN): 2
                AS4: 65002
                AS4: 65001

Download the pcap of the packet in the tshark output above (No.40, third-party next hop)

The R3 - switch capture (bgp-next-hop-r3sw.pcap) records the mirror image. No.18 is the UPDATE in which R2 advertises R1’s 192.168.1.0/24 to R3, and its Next hop is 10.0.123.1 (R1).

No.18 R2 → R3 UPDATE (192.168.1.0/24) tshark -V
Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 57
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 34
    Path attributes
        Path Attribute - MP_REACH_NLRI
            Flags: 0x90, Optional, Extended-Length, Non-transitive, Complete
<snip>
            Type Code: MP_REACH_NLRI (14)
            Length: 13
            Address family identifier (AFI): IPv4 (1)
            Subsequent address family identifier (SAFI): Unicast (1)
            Next hop: 10.0.123.1
                IPv4 Address: 10.0.123.1
            Number of Subnetwork points of attachment (SNPA): 0
            Network Layer Reachability Information (NLRI)
                192.168.1.0/24
                    MP Reach NLRI prefix length: 24
                    MP Reach NLRI IPv4 prefix: 192.168.1.0
        Path Attribute - ORIGIN: IGP
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: ORIGIN (1)
            Length: 1
            Origin: IGP (0)
        Path Attribute - AS_PATH: 65002 65001 
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: AS_PATH (2)
            Length: 10
            AS Path segment: 65002 65001
                Segment type: AS_SEQUENCE (2)
                Segment length (number of ASN): 2
                AS4: 65002
                AS4: 65001

Download the pcap of the packet in the tshark output above (No.18, third-party next hop in the other direction)

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

We add next-hop-self to R2’s neighbor toward R1.

R2: show running-config (the neighbor 10.0.123.1 part of router bgp 65002)
router bgp 65002
 bgp router-id 10.0.0.2
 address-family ipv4 unicast
  network 192.168.2.0/24
 !
 neighbor 10.0.123.1
  remote-as 65001
  description eBGP to R1 (shared segment)
  address-family ipv4 unicast
   next-hop-self
   route-policy PASS-ALL in
   route-policy PASS-ALL out
   soft-reconfiguration inbound always
  !
 !

NEXT_HOP is always this router now appears in show bgp neighbor.

R2: show bgp neighbor (the IPv4 Unicast part for 10.0.123.1)
 For Address Family: IPv4 Unicast
  BGP neighbor version 6
  BGP neighbor quick-withdraw version 6
  Update group: 0.1 Filter-group: 0.3  No Refresh request being processed
  Inbound soft reconfiguration allowed (override route-refresh)
  NEXT_HOP is always this router
  AF-dependent capabilities:
    Extended Nexthop Encoding: advertised and received
  Route refresh request: received 0, sent 0
  Policy for incoming advertisements is PASS-ALL
  Policy for outgoing advertisements is PASS-ALL

The Next Hop of 192.168.3.0/24 advertised to R1 has changed to 10.0.123.2 (R2 itself).

R2: show bgp neighbors 10.0.123.1 advertised-routes
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

Processed 2 prefixes, 2 paths

On R1 it is 10.0.123.2 as well, and the traceroute has grown to two hops. R1’s packets now cross the shared segment twice.

R1: show bgp 192.168.3.0/24 (relevant part)
  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
      Received Path ID 0, Local Path ID 1, version 7
      Origin-AS validity: (disabled)

R1: traceroute 192.168.3.1 source Loopback1
Type escape sequence to abort.
Tracing the route to 192.168.3.1

 1  10.0.123.2 25 msec  7 msec  6 msec 
 2  10.0.123.3 9 msec  *  11 msec

The packets confirm it too. No.58 is the UPDATE R2 sent to R1 right after next-hop-self was applied. The single TCP segment carries three UPDATEs; the second one, for 192.168.3.0/24, is shown here.

No.58 R2 → R1 UPDATE (second, 192.168.3.0/24, after next-hop-self) tshark -V
Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 57
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 34
    Path attributes
        Path Attribute - MP_REACH_NLRI
            Flags: 0x90, Optional, Extended-Length, Non-transitive, Complete
<snip>
            Type Code: MP_REACH_NLRI (14)
            Length: 13
            Address family identifier (AFI): IPv4 (1)
            Subsequent address family identifier (SAFI): Unicast (1)
            Next hop: 10.0.123.2
                IPv4 Address: 10.0.123.2
            Number of Subnetwork points of attachment (SNPA): 0
            Network Layer Reachability Information (NLRI)
                192.168.3.0/24
                    MP Reach NLRI prefix length: 24
                    MP Reach NLRI IPv4 prefix: 192.168.3.0
        Path Attribute - ORIGIN: IGP
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: ORIGIN (1)
            Length: 1
            Origin: IGP (0)
        Path Attribute - AS_PATH: 65002 65003 
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: AS_PATH (2)
            Length: 10
            AS Path segment: 65002 65003
                Segment type: AS_SEQUENCE (2)
                Segment length (number of ASN): 2
                AS4: 65002
                AS4: 65003

Download the pcap of the packet in the tshark output above (No.58, after next-hop-self)

STEP 2: Removing next-hop-self

We remove next-hop-self. R2’s running-config matches STEP 0 exactly.

The Next Hop of 192.168.3.0/24 advertised to R1 is back to 10.0.123.3.

R2: show bgp neighbors 10.0.123.1 advertised-routes
Network            Next Hop        From            AS Path
192.168.1.0/24     10.0.123.2      10.0.123.1      65002 65001i
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
192.168.4.0/24     10.0.123.2      10.0.123.1      65002 65001i

Processed 4 prefixes, 4 paths

The traceroute is back to one hop.

R1: traceroute 192.168.3.1 source Loopback1
Type escape sequence to abort.
Tracing the route to 192.168.3.1

 1  10.0.123.3 7 msec  *  8 msec

In the verification for BGP AS_PATH Attribute, removing the policy did not restore the best path on its own. There, the ranking between multiple paths came down to the “route age” tie-break. Rewriting NEXT_HOP changes an attribute in a situation where there is only one path, so it reverts the moment the configuration is removed.

STEP 3: Rewriting Per Prefix with a Route Policy

This time, instead of next-hop-self, we rewrite only 192.168.3.0/24 with a route policy. We configure the following on R2 and swap the outbound policy toward R1 from PASS-ALL to NH-OVERRIDE.

R2: show rpl prefix-set PS-FROM-R3
prefix-set PS-FROM-R3
  192.168.3.0/24
end-set
!

R2: show rpl route-policy NH-OVERRIDE
route-policy NH-OVERRIDE
  if destination in PS-FROM-R3 then
    set next-hop 10.0.123.2
  endif
  pass
end-policy
!

The outbound policy toward R1 has been swapped to NH-OVERRIDE.

R2: show running-config (the neighbor 10.0.123.1 part of router bgp 65002)
router bgp 65002
 bgp router-id 10.0.0.2
 address-family ipv4 unicast
  network 192.168.2.0/24
 !
 neighbor 10.0.123.1
  remote-as 65001
  description eBGP to R1 (shared segment)
  address-family ipv4 unicast
   route-policy PASS-ALL in
   route-policy NH-OVERRIDE out
   soft-reconfiguration inbound always
  !
 !

The result is the same as STEP 1: the Next Hop of 192.168.3.0/24 becomes 10.0.123.2.

R2: show bgp neighbors 10.0.123.1 advertised-routes
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

Processed 2 prefixes, 2 paths

R1: traceroute 192.168.3.1 source Loopback1
Type escape sequence to abort.
Tracing the route to 192.168.3.1

 1  10.0.123.2 8 msec  8 msec  6 msec 
 2  10.0.123.3 8 msec  *  11 msec

The packet contents are no different from STEP 1 either. The second UPDATE of No.100 is shown from the top down to Next hop (the attributes after that are identical to No.58).

No.100 R2 → R1 UPDATE (second, 192.168.3.0/24, after the route policy) tshark -V
Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 57
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 34
    Path attributes
        Path Attribute - MP_REACH_NLRI
            Flags: 0x90, Optional, Extended-Length, Non-transitive, Complete
<snip>
            Type Code: MP_REACH_NLRI (14)
            Length: 13
            Address family identifier (AFI): IPv4 (1)
            Subsequent address family identifier (SAFI): Unicast (1)
            Next hop: 10.0.123.2

Download the pcap of the packet in the tshark output above (No.100, after the route policy)

From R1’s point of view there is no way to tell whether the rewrite came from next-hop-self or from a route policy. The only difference is the scope on the sending side.

Method	`192.168.3.0/24`	`192.168.2.0/24`
`next-hop-self` (STEP 1)	Rewritten to `10.0.123.2`	`10.0.123.2` (its own address to begin with)
`NH-OVERRIDE` (STEP 3)	Rewritten to `10.0.123.2`	Passes through, since it does not match the policy condition

In this lab no route other than 192.168.3.0/24 carries a third party’s NEXT_HOP, so both produce the same result. Per-prefix control becomes useful when several ASes hang off a shared segment and you want only some of the routes to go through you.

STEP 4: Removing the Route Policy

We remove NH-OVERRIDE and PS-FROM-R3 and put the outbound policy toward R1 back to PASS-ALL. The running-config of all four routers matches STEP 0, and NEXT_HOP is back to 10.0.123.3.

R2: show bgp neighbors 10.0.123.1 advertised-routes
Network            Next Hop        From            AS Path
192.168.1.0/24     10.0.123.2      10.0.123.1      65002 65001i
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
192.168.4.0/24     10.0.123.2      10.0.123.1      65002 65001i

Processed 4 prefixes, 4 paths

R1: traceroute 192.168.3.1 source Loopback1
Type escape sequence to abort.
Tracing the route to 192.168.3.1

 1  10.0.123.3 8 msec  *  8 msec

Here is a summary of the results by STEP.

STEP	`NEXT_HOP` of `192.168.3.0/24` from R2 to R1	R1 traceroute	R4 traceroute
0	`10.0.123.3` (third party)	1 hop	2 hops
1	`10.0.123.2` (`next-hop-self`)	2 hops	3 hops
2	`10.0.123.3`	1 hop	2 hops
3	`10.0.123.2` (route policy)	2 hops	3 hops
4	`10.0.123.3`	1 hop	2 hops

Verification Configurations and show Output

For every STEP, the following three kinds of output were collected from all four routers, split per router. The verification configuration is 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` / `show route bgp` / `show bgp` / `show bgp summary` / `show bgp <prefix>` (for 4 prefixes) / `show bgp neighbor` / `show bgp neighbors <peer> advertised-routes` / `show bgp neighbors <peer> routes` / `show bgp neighbors <peer> received routes` / `show bgp update-group` / `show rpl route-policy` / `show rpl prefix-set` (R2 in STEP 3 only) / `show arp` (R1, R2 and R3 only) / `show ospf neighbor` (R1 and R4 only) / `traceroute` (R1, R3 and R4 only)
`..._log.txt`	`show logging` narrowed to that STEP’s range. A marker was inserted with `logmsg` at the start of each STEP, and its timestamp was passed to `show logging start`
`..._run.txt`	`show running-config` at that STEP (that is, the verification configuration for that STEP)

In the final state (STEP 4) the only policy is PASS-ALL, and the running-config of all four routers matches STEP 0.

STEP 0: initial state (third-party next hop in effect)

Router	show output	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run
R4	show	log	run

STEP 1: next-hop-self applied to R2’s neighbor toward R1

Router	show output	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run
R4	show	log	run

STEP 2: next-hop-self removed (configuration identical to STEP 0)

Router	show output	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run
R4	show	log	run

STEP 3: route policy NH-OVERRIDE applied

Router	show output	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run
R4	show	log	run

STEP 4: route policy removed (final state, configuration identical to STEP 0)

Router	show output	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run
R4	show	log	run

The full captures are below. They contain every UPDATE from STEP 0 through STEP 4.

Download the full capture on the R1 - switch link

Download the full capture on the R3 - switch link

References

Document	Title	Overview
RFC 4271	A Border Gateway Protocol 4 (BGP-4)	Section 5.1.3 defines the rules for setting `NEXT_HOP`, covering the use of a third party’s address on a shared segment and the prohibition on handing a peer its own address.
RFC 4760	Multiprotocol Extensions for BGP-4	Defines the `MP_REACH_NLRI` attribute. For address families other than IPv4, the next hop is carried inside this attribute.
RFC 7454	BGP Operations and Security	Operational recommendations, including design guidance for eBGP peering and the handling of `NEXT_HOP`.
IANA	Border Gateway Protocol (BGP) Parameters	The registry of path attribute type codes.