Next-Hop Reachability in eBGP Multi-Hop Networks

Border Gateway Protocol (BGP) is traditionally considered an edge routing protocol, where eBGP peers are directly connected. However, in modern enterprise and service provider networks, BGP is no longer limited to just the internet edge. eBGP has become a common design pattern in use cases such as multi-hop data center interconnects, partner connectivity, MPLS backbones, and cloud integration.

When eBGP Multi-Hop is used, a crucial assumption is broken: that the next-hop IP address is directly reachable. This is where recursive next-hop lookup becomes necessary. In this article, we will explore how recursive lookup works in an eBGP multi-hop environment, the conditions under which it fails, and how a seemingly correct BGP setup can blackhole data-plane traffic.

eBGP Single-Hop vs eBGP Multi-Hop

Single-hop eBGP

• Peers are directly connected.
• Default TTL = 1.
• The next-hop IP is in the same subnet.
• Recursive lookup is practically invisible.

In this model, routing dependencies are minimal, therefore operational complexity is also reduced.

eBGP Multi-Hop

• Peers are not directly connected.
• Peering occurs between loopback interfaces.
• The TTL (Time To Live) value must be manually increased.
• Next-hop resolution depends on IGP or static routing.

This is where a similarity arises between eBGP multi-hop and iBGP—in both, recursive next-hop resolution becomes mandatory.

Related: eBGP vs iBGP

Recursive Lookup in eBGP Multi-Hop Networks

This figure illustrates how recursive next-hop lookup works in an eBGP multi-hop environment when BGP peers are not directly connected. In this topology, router R1 (AS65001) and router R3 (AS65002) establish an eBGP multi-hop session between their loopback interfaces 1.1.1.1/32 and 3.3.3.3/32. Router R2 acts as a transit router and does not participate in BGP; it simply provides IP reachability.

When R3 advertises routes to R1 via BGP, the next-hop address for the route is 3.3.3.3, which is not directly connected to R1. Therefore, R1 must perform a recursive lookup in its routing table to determine how to forward traffic to 3.3.3.3. This reachability is achieved through a static (or IGP-learned) route configured on R1, which resolves 3.3.3.3 via R2 at 192.168.12.2. Only when this next-hop resolution is successful does R1 install the BGP route in its routing table, and traffic is forwarded along the R1 → R2 → R3 path. This figure clearly demonstrates that in an eBGP multi-hop design, simply having the BGP session up is not sufficient; continuous next-hop reachability is essential for traffic forwarding.

eBGP multi-Hop configuration and Verification

R1 – BGP Configuration

R1#conf t
Enter configuration commands, one per line. END with CNTL/Z.
R1(config)#interface loopback0
R1(config-if)#ip address 1.1.1.1 255.255.255.255
R1(config-if)#exit
R1(config)#ip route 3.3.3.3 255.255.255.255 192.168.12.2
R1(config)#router bgp 65001
R1(config-router)#neighbor 3.3.3.3 remote-as 65002
R1(config-router)#neighbor 3.3.3.3 update-source loopback0
R1(config-router)#neighbor 3.3.3.3 ebgp-multihop 2
R1(config-router)#end
R1#

R3 – BGP Configuration

R3#conf t
Enter configuration commands, one per line. END with CNTL/Z.
R3(config)#interface loopback0
R3(config-if)#ip address 3.3.3.3 255.255.255.255
R3(config-if)#exit
R3(config)#ip route 1.1.1.1 255.255.255.255 192.168.23.2
R3(config)#router bgp 65002
R3(config-router)#neighbor 1.1.1.1 remote-as 65001
R3(config-router)#neighbor 1.1.1.1 update-source loopback0
R3(config-router)#network 10.10.10.0 mask 255.255.255.0
R3(config-router)#end
R3#

BGP Session Status (R1)

R1#show ip bgp summary

BGP router identifier 1.1.1.1, local AS number 65001
BGP table version is 7,main routing table version 7

Neighbor   V    AS     MsgRcvd   MsgSent  TblVer InQ  OutQ  State/PfxRcvd
3.3.3.3    4   65002   128       121       7      0    0     1

BGP Table (R1)

R1#show ip bgp

   Network           Next Hop       Path
*> 10.10.10.0/24     3.3.3.3        65002

Recursive Next-Hop Resolution

R1#show ip route 3.3.3.3
Routing entry for 3.3.3.3/32
    known via "static", distance 1, metric 0
    * 192.168.12.2

Routing Table Entry

R1#show ip route 10.10.10.0
Routing entry for 10.10.10.0/24
    known via "bgp 65001", distance 20, metric 0
    * 3.3.3.3, via GigabitEthernet0/0

Recursive Routing Failure in eBGP Multi-Hop

Now, let’s assume that due to a configuration change, maintenance, or a core routing issue, the static route from R1 to 3.3.3.3 is removed.

Here’s what happens next:

1. The BGP session remains UP. The eBGP multi-hop peering between R1 and R3 appears stable.

2. The route is still visible in the BGP table.

R1# show ip bgp
Network                      Next Hop
10.10.10.0/24                3.3.3.3

3. The recursive lookup fails at R1.

R1# show ip route 3.3.3.3
% Network not in table

4. Route not installed in the routing table.

R1# show ip route 10.10.10.10
% Network not in table

Why is this a Recursive Routing?

• BGP has successfully learned the route (the control plane is healthy).
• However, the next-hop IP address 3.3.3.3 is not reachable through the routing table.
• R1 is unable to resolve the next-hop in this way:

3.3.3.3 à via 192.168.12.2 à outgoing interface

• Therefore, the recursive lookup fails, and the BGP route is not installed in the RIB.

Operational Impact in Network

• Traffic is blackholed for 10.10.10.0/24.
• No BGP flaps or errors are observed.
• Monitoring tools show BGP as healthy.
• The real problem becomes apparent only when an application or user reports an issue.

ABOUT THE AUTHOR

Rashmi Bhardwaj

Founder of AAR TECHNOSOLUTIONS, Rashmi is an evangelist for IT and technology. With more than 12 years in the IT ecosystem, she has been supporting multi domain functions across IT & consultancy services, in addition to Technical content making.

You can learn more about her on her linkedin profile – Rashmi Bhardwaj