Configuring the Next_Hop Attribute

Configuring the Next_Hop attribute allows for flexible control of BGP route selection.

Procedure

Configure a device to change the next hop address of a route when the device advertises the route to an IBGP peer.
By default, a device does not change the next hop address of a route learned from an EBGP peer before forwarding the route to IBGP peers. The next hop address of a route advertised by an EBGP peer to this device is the peer address of the EBGP peer. After being forwarded to IBGP peers in the local AS, this route is not active because the next hop is unreachable. To address this problem, the relevant ASBR needs to be configured to change the Next_Hop of the route learned from an EBGP peer to the ASBR's own address before the ASBR advertises the route to an IBGP peer. As an IGP runs within the AS, the next hop of the route is reachable to the IBGP peer. As such, the route received by the IBGP peer is active.
1. Run system-view
  The system view is displayed.
2. Run bgp { as-number-plain | as-number-dot }
  The BGP view is displayed.
3. Run ipv4-family unicast
  The IPv4 unicast address family view is displayed.
4. Run peer { ipv4-address | group-name } next-hop-local
  The device is configured to change the next hop address of a route to its own address before advertising it.
  
  If BGP load balancing is configured, the local router changes the next hop address of a route to its own address when advertising the route to an IBGP peer or peer group, regardless of whether the peer next-hop-local command is run.
5. Run commit
  The configuration is committed.
Prevent a device from changing the next hop address of a route imported from an IGP when the device advertises the route to an IBGP peer.
1. Run system-view
  The system view is displayed.
2. Run bgp { as-number-plain | as-number-dot }
  The BGP view is displayed.
3. Run ipv4-family unicast
  The IPv4 unicast address family view is displayed.
4. Run the peer { ipv4-address | group-name } next-hop-invariable command to configure the device not to change the next hop address of each imported IGP route when advertising the route or run the peer { ipv4-address | group-name } next-hop-invariable [ include-static-route | include-unicast-route ]^* command.
  If the peer next-hop-invariable include-static-route command is run, the BGP speaker retains the original next hop address of an imported public network static route when advertising the route to an IBGP peer under the condition that the original next hop address is valid; if the original next hop address of the public network static route is invalid, the next hop of the public network static route belongs to a VPN instance, or the public network static route is imported from a VPN instance, the BGP speaker uses its interface address as the next hop of the route.
  
  If the peer next-hop-invariable include-unicast-route command is run, the BGP speaker does not change the next hop address when advertising to an EBGP peer the unicast routes learned from another peer.
5. Run commit
  The configuration is committed.
Prevent an ASBR from changing the next hop address of a route when the ASBR advertises the route to an EBGP peer.
1. Run system-view
  The system view is displayed.
2. Run bgp { as-number-plain | as-number-dot }
  The BGP view is displayed.
3. Run ipv4-family vpnv4 [ unicast ]
  The BGP-VPNv4 address family view is displayed.
4. Run peer { group-name | ipv4-address } next-hop-invariable
  The device is configured not to change the next hop address of a route before advertising it to an EBGP peer.
  
  In an inter-AS VPN Option C scenario where RRs are deployed, the peer next-hop-invariable command needs to be run on the RRs to prevent them from changing the next hop address of a route before they advertises the route to an EBGP peer. This ensures that the remote PE can implement recursion to the BGP LSP to the local PE during traffic transmission.
  
  On the network shown in Figure 1, a BGP LSP is established between PE1 and PE2. VPNv4 routes are exchanged through BGP-VPNv4 peer relationships established between PE1 and RR1, between RR1 and RR2, and between RR2 and PE2.
  Figure 1 Inter-AS VPN Option C networking with RRs deployed
  If PE1 needs to advertise a VPNv4 route to PE2, the following process is implemented:
  1. PE1 advertises the route to RR1, and the route next hop is PE1.
  2. After receiving the route, RR1 changes the next hop to RR1 and advertises the route to RR2 through the EBGP peer relationship.
  3. Upon receipt, RR2 advertises the route to PE2 through the IBGP peer relationship. By default, the router changes the next hop address of a labeled route received from an EBGP peer before advertising the labeled route to an IBGP peer. Therefore, RR2 changes the next hop address of the route to be advertised to PE2 to its own address before route advertisement.
  Therefore, the next hop of the VPNv4 route on PE2 is RR2, but the destination address of the BGP LSP is PE1. As a result, the VPNv4 route on PE2 cannot recurse to the BGP LSP, causing a forwarding failure.
  To solve the preceding problem, run the peer next-hop-invariable command on RR1 to ensure that RR1 does not change the next hop when advertising routes to RR2. In addition, run the peer next-hop-invariable command on RR2 to ensure that RR2 does not change the next hop when advertising routes to PE2. In this way, the next hop of the route received by PE2 is PE1, and the VPNv4 route on PE2 can recurse to the BGP LSP properly.
  
  Similar to the preceding process, if PE2 also needs to advertise a VPNv4 route to PE1, run the peer next-hop-invariable command on both RR2 and RR1 so that RR2 does not change the route next hop before advertising the route to RR1 and RR1 does not change the route next hop before advertising the route to PE1. In this way, the next hop of the route received by PE1 is PE2, and the VPNv4 route on PE1 can recurse to the BGP LSP properly.
5. Run commit
  The configuration is committed.
Configure route-policy-based next hop recursion.
1. Run system-view
  The system view is displayed.
2. Run bgp { as-number-plain | as-number-dot }
  The BGP view is displayed.
3. Run ipv4-family unicast
  The IPv4 unicast address family view is displayed.
4. Run nexthop recursive-lookup { route-policy route-policy-name | route-filter route-filter-name }
  Route-policy-based next hop recursion is configured.
  
  Route-policy-based next hop recursion helps flexibly control the recursion result based on specific conditions. If a route does not match the specified route-policy, the route fails to recurse.
5. Run commit
  The configuration is committed.
Prevent the device from changing the next hop address of a route to ensure that traffic is transmitted along the optimal route when the device advertises the route to a peer in the following scenarios:
- The route is learned from a directly connected peer and is to be advertised to a directly connected EBGP peer, the original next hop of the route resides on the same network segment as the local interface that is used to establish the BGP peer relationship with the EBGP peer, and all directly connected interfaces are broadcast interfaces.
- The route is locally imported and is to be advertised to a directly connected IBGP or EBGP peer, the next hop to which the route recurses resides on the same network segment as the local interface that is used to establish the BGP peer relationship with the IBGP or EBGP peer, and all directly connected interfaces are broadcast interfaces.
1. Run system-view
  The system view is displayed.
2. Run bgp { as-number-plain | as-number-dot }
  The BGP view is displayed.
3. Run ipv4-family unicast
  The IPv4 unicast address family view is displayed.
4. Run nexthop third-party
  The device is prevented from changing the next hop address of a route when the device advertises the route to a peer in the specified scenarios.
5. Run commit
  The configuration is committed.
On the network shown in Figure 2, DeviceA establishes EBGP peer relationships with DeviceB and DeviceC, but DeviceB and DeviceC do not establish a peer relationship with each other.
Figure 2 Network diagram of Layer 2 transparent transmission
Assume that DeviceA receives an EBGP route 1.1.1.1 from DeviceB. If the nexthop third-party command is not run, the next hop address of the route is changed as follows:
1. Before DeviceB advertises the route 1.1.1.1 to DeviceA, DeviceB changes the next hop to 192.168.10.1.
2. Before DeviceA advertises the route 1.1.1.1 to DeviceC, DeviceA changes the next hop to 192.168.10.2.
When traffic is transmitted from DeviceC to DeviceB, the traffic passes through DeviceA.
After the nexthop third-party command is run on DeviceA, the next hop address of the route 1.1.1.1 is changed as follows:
1. Before DeviceB advertises the route 1.1.1.1 to DeviceA, DeviceB changes the route next hop to 192.168.10.1.
2. Before DeviceA advertises the route to DeviceC, DeviceA detects that the address (192.168.10.2) of its local interface that is used to establish the BGP peer relationship with DeviceC belongs to the same network segment as the original next hop address 192.168.10.1 of the route. Therefore, DeviceA does not change the next hop address of the route. As a result, the next hop address of the BGP route 1.1.1.1 received by DeviceC remains 192.168.10.1.
In this way, traffic from DeviceC can be directly forwarded to DeviceB, without passing through DeviceA.