What Is EBGP Multihop in Networking?

Imagine you work in a large office building and you need to pass a note to a colleague on a different floor. The simplest way is to hand it directly to them if they are next to you. If they are on another floor, you might have to give the note to a messenger who walks it through several hallways and up stairs.

That is a direct one-step handoff versus a multistep journey. EBGP Multihop is like allowing the note to be passed through multiple messengers, as long as the final colleague is reached. In networking, EBGP (External Border Gateway Protocol) is used to exchange routing information between different autonomous systems, like different companies or different parts of the internet.

Normally, EBGP requires the two routers to be directly connected by a cable so they can talk immediately. But with EBGP Multihop, you tell the routers: It is okay to talk even if there are other routers in between. Think of it like a long-distance phone call.

You and your friend can talk even though your voices travel through many telephone poles and switching stations. The phone system handles the middle part for you. In the same way, EBGP Multihop uses the underlying IP routing of the network to deliver BGP messages across multiple hops, so the two routers can become neighbors without a direct wire.

The key point is that the BGP session itself is logically direct, but physically it travels through intermediate routers. The intermediate routers do not need to know anything about BGP; they simply forward the BGP packets like any other IP traffic. This gives network engineers flexibility to place BGP routers anywhere in the topology, not just at the end of a direct link.

EBGP Multihop is a configuration parameter used in Border Gateway Protocol (BGP) to establish an External BGP (EBGP) peering session between two routers that are not directly connected at Layer 2. In standard BGP operation, an EBGP session requires that the two peers be directly connected via a single Layer 2 link (for example, a point-to-point Ethernet cable or a serial line). The IP addresses used for the peering must be on the same subnet, and the Time-to-Live (TTL) value in the BGP packet header is set to 1 by default.

This TTL of 1 ensures that the packet cannot traverse any router; it must reach the neighbor within one hop. EBGP Multihop modifies this behavior by allowing the administrator to increase the TTL value to a higher number, typically 2 or more, enabling the BGP packets to pass through intermediate routers. The configuration command in Cisco IOS is "neighbor <ip-address> ebgp-multihop <hops>", where <hops> specifies the maximum number of Layer 3 hops the BGP packets are allowed to traverse.

The intermediate routers forward the BGP packets based on their IP routing tables; they do not process the BGP information themselves. This allows EBGP peering over an existing routed network, such as across a service provider backbone or a multi-router enterprise core. EBGP Multihop is often used in scenarios where a router needs to peer with a loopback interface of a remote router for redundancy.

For example, if a router has two upstream connections to two different providers, peering to the remote loopback address using multihop ensures that if one physical link fails, the BGP session can still be maintained over the other path. The BGP update source is often configured to use the loopback interface as the source IP for the TCP connection, which further enhances resilience. In terms of security and best practices, EBGP Multihop should be used with caution because it bypasses the direct connectivity requirement.

It can expose the BGP session to potential spoofing or denial of service attacks if not protected with features like TTL Security (GTSM) or MD5 authentication. In Cisco IOS, the "neighbor <ip-address> ttl-security hops <number>" command can restrict the allowed TTL range to prevent spoofed packets from outside the expected hop count. EBGP Multihop is also commonly used in MPLS L3VPN environments where provider edge (PE) routers need to peer with each other across the MPLS core.

The core routers forward the BGP packets transparently. Another important consideration is the maximum transmission unit (MTU) because BGP packets carrying large routing tables may be fragmented across multiple hops if the path MTU is not consistent. Network engineers must verify that the entire path supports the required MTU for BGP messages.

EBGP Multihop matters because it gives network engineers flexibility and resilience in designing BGP peering relationships. In real IT work, especially in large enterprise networks, service provider networks, and data centers, you cannot always connect two BGP routers with a direct cable. Sometimes they are separated by a core network or a wide area network (WAN) with multiple routers in between.

Without multihop, you would need a direct link for every EBGP session, which is expensive, inefficient, and sometimes impossible. Multihop allows you to establish BGP sessions across an existing network infrastructure. This is critical for implementing BGP-based redundancy.

For example, if an enterprise has two connections to the internet from two different providers, the edge routers often use EBGP Multihop to peer with the provider routers using loopback interfaces. If one physical link goes down, the BGP session does not drop because the loopback is still reachable through the other provider or a backup link. This maintains routing stability and prevents traffic loss.

Multihop also enables route reflectors and BGP confederations in scenarios where EBGP peers are not directly connected. In cloud environments, virtual routers and software-defined networking (SDN) controllers often use multihop to establish EBGP sessions across overlay networks. Security is another reason why multihop matters.

By allowing BGP sessions over multiple hops, you can place BGP speakers in more secure locations, such as a dedicated management network, rather than exposing them directly to untrusted links. However, this also introduces security risks; if an attacker can inject packets into the path, they might hijack the BGP session. That is why features like TTL security and authentication are important companions to multihop.

For certification exams like the CCNP Enterprise (ENCOR), understanding EBGP Multihop is essential because it is a common configuration tweak that appears in troubleshooting scenarios and design questions. Knowing when to use it and when not to use it shows a deeper grasp of BGP behavior. Without multihop, many modern network designs would be far more rigid and less resilient.

EBGP Multihop appears in multiple types of exam questions, including multiple-choice single answer, multiple-choice multiple answers, drag-and-drop, and simulation or lab-based questions. In multiple-choice questions, a common format is to present a network diagram with three routers: R1, R2, and R3 connected in series. R1 and R3 need to establish an EBGP session.

The question asks: What additional configuration is required beyond the basic BGP neighbor commands? The answer options might include 'set the TTL to 2 using ebgp-multihop', 'change the BGP AS number', 'enable BGP synchronization', or 'configure a route-map'. The correct answer is the ebgp-multihop command.

Another pattern is a troubleshooting scenario where the BGP session fails to establish. The output of show ip bgp summary shows the neighbor state as 'Idle' or 'Active'. The candidate is given several configuration snippets, one of which contains the ebgp-multihop command.

The question asks: Which configuration fix will resolve the issue? The correct answer is to add ebgp-multihop. In drag-and-drop questions, the candidate may need to match the correct BGP configuration commands to different scenarios.

One scenario might say 'BGP peers are not directly connected', and the candidate must drag the ebgp-multihop command into the correct box. Simulation questions on the exam (or in practice tools like Cisco Packet Tracer or EVE-NG) require the candidate to configure EBGP Multihop on two routers and then verify the neighbor state. The candidate must enter the correct router configuration mode, specify the neighbor IP address, and set the multihop value.

Follow-up verification questions may ask the candidate to check the output of show ip bgp neighbors or show ip route to confirm the session is established. In design-based questions, the candidate is given a high-level topology and asked to choose the best approach for EBGP peering between two remote sites connected via an MPLS WAN. The correct design would include EBGP Multihop with loopback interfaces for redundancy.

The exam may also present a scenario where a candidate incorrectly uses no ebgp-multihop and the session fails, leading to a troubleshooting question. The exam expects the candidate to understand that ebgp-multihop is required only when the neighbors are not on the same subnet. If the neighbors are on the same subnet but separated by a switch (Layer 2 only), then multihop is not needed because they are still directly connected at Layer 3.

Another tricky question: two routers are connected via a Layer 2 switch, but their IP addresses are in different subnets. In this case, even though they are physically connected through a switch, they are not on the same subnet, so EBGP Multihop is required. The exam may test this nuance.

EBGP Multihop is a configuration tool that every network engineer working with BGP should understand thoroughly. In practice, you will rarely have the luxury of directly connecting every BGP peer. Most enterprise networks have a core layer of routers and switches, and BGP speakers are often at the edge of the network, separated by several hops.

For example, consider a company that has two data centers in different cities. Each data center has a border router that connects to an internet service provider (ISP). The border routers need to exchange EBGP routes with each other for backup and load balancing.

They are connected through the company's WAN, which may involve multiple routers in between. Without EBGP Multihop, you would need a direct cross-connect between the two data centers just for BGP, which is expensive and wasteful. With EBGP Multihop, you can peer using loopback interfaces, making the session resilient to link failures.

When configuring, always remember to set the update-source to a loopback interface. This is critical because if the physical interface goes down but the loopback is still reachable via another path, the BGP session stays up. Another practical consideration is the TTL value.

Setting multihop to 255 is common, but be aware that this allows potential attackers from far away to send spoofed BGP packets if they can reach the router. Therefore, in production, it is safer to set the TTL to the exact number of hops in your path. For example, if the path between the two loopbacks is exactly 3 hops, set ebgp-multihop 4 to allow one extra hop for redundancy.

Also consider using the ttl-security command instead, which provides built-in protection by rejecting packets that do not have the expected TTL. For example, ttl-security hops 3 will accept only packets that arrive with TTL exactly 252 (if the default initial TTL is 255, then 255 - 252 = 3 hops). This prevents off-path attackers from injecting packets.

However, ttl-security and ebgp-multihop cannot be used together on the same neighbor in most Cisco platforms, so you must choose one based on your security needs. Additionally, when using EBGP Multihop, ensure that the intermediate routers have routes to the loopback addresses of the BGP peers. If the intermediate routers do not have routes to the loopback networks, the BGP packets will be dropped.

This often requires injecting the loopback routes into the IGP (like OSPF or EIGRP) or using static routes. In large networks, BGP multihop is also used for route reflection between confederation sub-ASes. In a BGP confederation, EBGP peering is used between sub-ASes, but those sub-AS routers are often not directly connected.

EBGP Multihop allows them to peer across the confederation backbone. A common mistake in labs is to forget that EBGP Multihop must be configured on both sides of the session. If only one side has the command, the side with the lower TTL will drop the packets.

Always verify the configuration on both routers. Finally, when troubleshooting, always check the TTL value in the BGP packets using a packet capture or debug ip bgp. You can also use extended ping with a specific TTL to test reachability of the neighbor loopback address.

If the ping succeeds with a specific TTL but fails with a lower TTL, that confirms the number of hops. This number can guide you in setting the multihop value precisely.