06 eBGP Peering & TTL
eBGP has a built-in expectation that peers are directly connected, enforced through the TTL of its packets. Two special behaviors, and their two override commands, all trace back to this single design choice.
The TTL 1 rule
By default, eBGP sets TTL = 1 on the packets it sends toward an external neighbor. A TTL of 1 means the packet can cross exactly one hop before being discarded, which forces the eBGP peer to be directly connected (one hop away).
Because of this, eBGP peers are normally configured using the IP addresses of their directly connected interfaces, and those addresses must belong to a shared, directly connected logical network.
Connected-check
Separate from the TTL rule, eBGP also performs a connected-check: it verifies that the neighbor’s IP is on a directly connected subnet. This matters when peering eBGP between loopback interfaces, which are not directly connected to each other. In that case the connected-check fails and must be disabled.
This is done with disable-connected-check. It only turns off the directly-connected subnet verification; it does not change the TTL.
eBGP Multihop
When eBGP peers are not directly connected (more than one hop apart), the default TTL of 1 makes the session impossible, because packets die at the first intermediate hop. eBGP Multihop raises the TTL to allow the session across multiple hops.
The command is ebgp-multihop <value>, where the value sets the maximum TTL, meaning the number of hops the session may cross. For peers two hops apart, at least ebgp-multihop 2 is required; three hops needs 3, and so on. If the value is omitted on IOS, the default is 255.
Multihop must be configured on both ends
TTL applies to each router’s outgoing packets. If only one side raises its TTL, its packets arrive, but the other side (still at TTL 1) has its packets discarded at the first intermediate hop, and the session never establishes in both directions.
Two similar commands that are not the same
These two are often confused. They solve different problems:
| Command | Problem it solves | Effect on TTL |
|---|---|---|
disable-connected-check | Peers are one hop apart but peering loopback-to-loopback | None |
ebgp-multihop <n> | Peers are more than one hop apart | Raises TTL to n |
Using the wrong one is a classic mistake: a loopback peering between directly connected routers needs disable-connected-check, not ebgp-multihop.
Load balancing with loopbacks
A common use of loopback-based eBGP is load balancing between two directly connected routers joined by multiple physical links. Because a loopback is reachable over several physical paths, peering to the loopback lets traffic spread across those links. This requires static routes (or an IGP) toward the peer’s loopback over each link, plus update-source loopback so the session originates from the loopback, and disable-connected-check because the loopbacks are not on a directly connected subnet.
Self-check
Q1 — What is the default TTL of eBGP packets, and what does it enforce?
A) 255 — multi-hop peering by default
B) 1 — the peer must be directly connected
C) 64 — up to 64 hops
D) 0 — packets never leave the router
Respuesta
B is correct. eBGP sets TTL = 1 by default, forcing the peer to be exactly one hop away (directly connected).
- A) False — 255 is what
ebgp-multihopraises it to, not the default.- C) False — 64 is a common host default, not eBGP’s.
- D) False — TTL 0 would mean packets are discarded immediately; eBGP uses 1.
Q2 — Which command is needed to peer eBGP loopback-to-loopback between two directly connected routers?
A)
ebgp-multihop 2
B)disable-connected-check
C)next-hop-self
D)synchronization
Respuesta
B is correct. The routers are one hop apart, so TTL is not the issue; the connected-check fails because loopbacks are not on a directly connected subnet, so it must be disabled.
- A) False — multihop raises TTL, which is not the problem for one-hop loopback peering.
- C) False — next-hop-self is an iBGP next-hop fix, unrelated here.
- D) False — synchronization is a legacy iBGP/IGP rule.
Q3 — For eBGP peers three hops apart, what is required?
A)
disable-connected-check
B)ebgp-multihop 3(at least) on both ends
C)ebgp-multihop 3on one end only
D) Nothing; eBGP is multi-hop by default
Respuesta
B is correct. Multihop must raise the TTL to at least the hop count, and it must be configured on both ends because TTL applies to each router’s outgoing packets.
- A) False — connected-check is for one-hop loopback peering, not multi-hop.
- C) False — one-sided config lets one direction fail; both ends are needed.
- D) False — eBGP defaults to TTL 1, so multi-hop is not automatic.
Q4 — What does
disable-connected-checkchange?A) It raises the TTL to 255
B) It turns off the directly-connected subnet verification, without changing TTL
C) It rewrites the next-hop to the local loopback
D) It disables loop prevention
Respuesta
B is correct. It only disables the check that the neighbor is on a directly connected subnet; it does not touch the TTL.
- A) False — raising TTL is what multihop does.
- C) False — rewriting the next-hop is
next-hop-self.- D) False — it has nothing to do with loop prevention.