Next_Hop

Unlike the Next_Hop attribute in an IGP, the Next_Hop attribute in BGP is not necessarily the IP address of a neighboring device. In most cases, the Next_Hop attribute in BGP complies with the following rules:

When advertising a route to an EBGP peer, a BGP speaker sets the Next_Hop of the route to the address of the local interface through which the BGP peer relationship is established.
When advertising a locally generated route to an IBGP peer, a BGP speaker sets the Next_Hop of the route to the address of the local interface through which the BGP peer relationship is established.
When advertising a route learned from an EBGP peer to an IBGP peer, the BGP speaker does not modify the Next_Hop of the route.

Modifying the Next_Hop

In some scenarios, the Next_Hop needs to be modified. Table 1 describes whether the Next_Hop needs to be modified in specific scenarios.

**Table 1** Next_Hop processing
Objectives	Command	Usage Scenarios	Remarks
To enable an ASBR to modify the Next_Hops of the routes to be advertised to IBGP peers.	peer { group-name \| ipv4-address \| ipv6-address } next-hop-local	By default, when an ASBR forwards a route learned from an EBGP peer to its IBGP peers, the ASBR does not change the Next_Hop of the route. Therefore, the Next_Hop address of the route remains the EBGP peer IP address. After being forwarded to the IBGP peers, the route cannot become active as the Next_Hop is unreachable. To address this issue, configure the ASBR to modify the Next_Hop of the route to the local IP address before advertising the route to IBGP peers. After being forwarded to the IBGP peers, the route can be active because the Next_Hop is reachable (an IGP is configured in the AS).	If BGP load balancing has been configured using the maximum load-balancing number command, the switch modifies the Next_Hop of each route to the local IP address through which the IBGP peer relationship is established before it advertises the route to IBGP peers, regardless of whether the peer next-hop-local command is configured.
To prevent a device from modifying the Next_Hops of the routes imported from an IGP before advertising the routes to IBGP peers.	peer { ipv4-address \| group-name } next-hop-invariable	-	By default, a device modifies the Next_Hops of the routes imported from an IGP to the local IP address before advertising the routes to IBGP peers.
To prevent a device from modifying the Next_Hops of routes before advertising the routes to EBGP peers.	peer { ipv4-address \| group-name } next-hop-invariable	In an inter-AS VPN Option C scenario where an RR is used, the peer next-hop-invariable command needs to be run on the RR to prevent the RR from modifying the Next_Hops of routes before advertising the routes to EBGP peers. This ensures that the remote PE iterates routes to the LSP destined for the local PE during traffic transmission.	By default, a device modifies the Next_Hops of routes to the local IP address before advertising the routes to EBGP peers. In addition, a device does not modify the Next_Hops of non-labeled routes if the routes are learned from EBGP peers and are to be advertised to IBGP peers; the device sets its interface IP address as the Next_Hops of labeled routes if the routes are learned from EBGP peers and are to be advertised to IBGP peers.
To configure BGP Next_Hop iteration based on a route-policy.	nexthop recursive-lookup route-policy route-policy-name	To enable a device to iterate only desired routes, configure Next_Hop iteration based on a specified route-policy so that only the routes that match the route-policy are iterated.	By default, Next_Hop iteration based on a specified route-policy is not configured.
To enable a device to modify the Next_Hops of BGP routes using a route-policy.	apply ip-address next-hop{ ipv4-address \| peer-address }	The Next_Hops of BGP routes can be modified using a route-policy in the following situations: For IBGP peers, the route-policy can be an import or export policy. Even if the next hop address configured in the route-policy is unreachable, the IBGP peers still add the routes whose next hop addresses have been changed to the address configured in the route-policy to the BGP routing table. However, the routes are invalid. For EBGP peers, the route-policy can only be an import policy in most cases. If the route-policy is configured as an export policy, the routes whose next hop addresses have been changed to the address configured in the route-policy are discarded by the EBGP peers because the next hop address is unreachable.	If a route-policy has been specified in the import-route or network command, the apply clause configured for the route-policy using the apply ip-address next-hop command does not take effect.

Obtaining a Reachable Next Hop

During route selection, BGP first checks whether the next hop addresses of routes are reachable. Routes carrying unreachable next hop addresses are invalid and are not selected. Table 2 shows how to obtain a reachable next hop IP address or tunnel.

**Table 2** Unreachable next hop
Item	Description	Solutions
Unreachable next hop IP address	A next hop IP address is obtained through route iteration, but no active routes to the IP address are available in the IP routing table.	Common solutions are as follows: Configure static routes or an IGP. Run the import-route command. Run the network command. Alternatively, you can run the peer next-hop-local command to change the Next_Hop to the local IP address.
Unreachable next hop tunnel	Routes fail to be iterated to tunnels.	Configure a tunnel policy or a tunnel selector to ensure that the routes can be iterated to tunnels.
Unreachable next hop tunnel	A next hop tunnel is obtained through route iteration, but the tunnel is unavailable.	Ensure that the tunnel is correctly configured and is Up.

The following example shows how to obtain a reachable next hop IP address. In Figure 1, an IBGP peer relationship is established between Switch A and Switch B, and an EBGP peer relationship is established between Switch B and Switch C. Switch A imports the route 1.1.1.9/32, and Switch C imports the route 3.3.3.9/32.

Figure 1 Networking

# Display the BGP routing table of Switch A.

[HUAWEIA] display bgp routing-table

 BGP Local router ID is 10.1.1.1
 Status codes: * - valid, > - best, d - damped,
               h - history,  i - internal, s - suppressed, S - Stale
               Origin : i - IGP, e - EGP, ? - incomplete


 Total Number of Routes: 2
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

 *>   1.1.1.9/32         0.0.0.0         0                     0      i
   i  3.3.3.9/32         10.1.2.1        0          100        0      65001i

The preceding command output shows that no asterisk (*) is in front of the route 3.3.3.9/32, which indicates that the route is invalid.

# Display the IP routing table of Switch A.

[HUAWEIA] display ip routing-table

Route Flags: R - relay, D - download to fib, T - to vpn-instance
------------------------------------------------------------------------------
Routing Tables: Public
         Destinations : 5        Routes : 5

Destination/Mask    Proto   Pre  Cost      Flags NextHop         Interface

        1.1.1.9/32  Direct  0    0           D   127.0.0.1       LoopBack1
       10.1.1.0/30  Direct  0    0           D   10.1.1.1        GigabitEthernet0/0/0
       10.1.1.1/32  Direct  0    0           D   127.0.0.1       GigabitEthernet0/0/0
      127.0.0.0/8   Direct  0    0           D   127.0.0.1       InLoopBack0
      127.0.0.1/32  Direct  0    0           D   127.0.0.1       InLoopBack0

The preceding command output shows that the next hop IP address (10.1.2.1) of the route 3.3.3.9/32 is not in the IP routing table, which indicates that the route is not selected due to the unreachable next hop IP address. The following solutions can address this issue:

Configure a static route destined for 10.1.2.1/30 on Switch A.
Configure an IGP on Switch B and Switch C and configure BGP to import the route 10.1.2.1 on Switch B. This solution is not applicable to this specific scenario because Switch B and Switch C are located in different ASs.
Run the import-route direct command on Switch B. This solution is not optimal because unnecessary routes may be imported.
Run the network 10.1.2.0 30 command on Switch B to advertise the route 10.1.2.0/30 to Switch A.
Run the peer 10.1.1.1 next-hop-local command on Switch B to configure Switch B to modify the Next_Hop of the route 3.3.3.9/32 before advertising the route to Switch A.

In this example, the network 10.1.2.0 30 command is configured on Switch B. After the command is configured, check the BGP routing table of Switch A.

[HUAWEIA] display bgp routing-table

 BGP Local router ID is 10.1.1.1
 Status codes: * - valid, > - best, d - damped,
               h - history,  i - internal, s - suppressed, S - Stale
               Origin : i - IGP, e - EGP, ? - incomplete


 Total Number of Routes: 3
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

 *>   1.1.1.9/32         0.0.0.0         0                     0      i
 *>i  3.3.3.9/32         10.1.2.1        0          100        0      65001i
 *>i  10.1.2.0/30        10.1.1.2        0          100        0      i

The preceding command output shows that both * and > are in front of the route 3.3.3.9/32, which indicates that the route is valid and optimal.