(Part 2) iBGP vs. eBGP: Split Horizon Explained by a Confused Engineer

Welcome back to Route/Switch & Sleep Deprivation.

In Part 1, we got two routers to shake hands. It was beautiful. It was "Established."
But a handshake is not a conversation. Just because your routers are friends doesn't mean they are gossiping about routes correctly.

Today, we tackle the split personality of BGP: Internal BGP (iBGP) versus External BGP (eBGP).

If you think they work the same way, prepare for your packets to disappear into the void.

The Tale of Two Protocols

Despite sharing the same name, iBGP and eBGP are like two different employees at a company:

• eBGP (External): The Salesman. He talks to people outside the company. He is loud, assumes everyone is far away (TTL=1), and changes the "Next Hop" address to himself because he knows the outside world doesn't know about our internal mess.
• iBGP (Internal): The Introverted Engineer. He talks to colleagues. He trusts them (TTL=255). But he has a very strict code of silence called Split Horizon.

Let's break the network to see how this works.

Trap #1: The "Next Hop" Lie

Imagine a classic topology:
R1 (ISP) -> R2 (Edge) -> R3 (Internal Core).

• R1 is in AS 100.
• R2 and R3 are in AS 200.
• R1 sends a route (e.g., 8.8.8.8/32) to R2 via eBGP.

R2 learns it. R2 is happy. R2 installs it in the routing table.
Now, R2 sends this route to R3 via iBGP.

R3 receives the update. You check show ip bgp on R3. The route is there!
But R3 cannot ping 8.8.8.8.

Why?
Look closely at the BGP table on R3:

R3# show ip bgp 8.8.8.8
BGP routing table entry for 8.8.8.8/32, version 2
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  100
    192.168.12.1 (inaccessible) from 192.168.23.2 (2.2.2.2)

See that? 192.168.12.1 (inaccessible).

The Rule: When eBGP passes a route to iBGP, it does NOT change the Next Hop address.
R2 told R3: "Hey, to get to Google, go to R1 (192.168.12.1)."
R3 said: "Who is R1? I don't have a route to that external link. I only know you, R2."

The Fix:
You must force R2 to be the middleman.

! On R2 (The Edge Router)
router bgp 200
 neighbor 3.3.3.3 next-hop-self

Now R2 says: "To get to Google, come to ME." R3 knows how to reach R2. Traffic flows.

Trap #2: The Split Horizon Silence

Now let's add R4 behind R3.
R1 -> R2 -> R3 -> R4.
R2, R3, R4 are all in AS 200.

R2 tells R3 about the route.
R3 knows the route.
R3 will NOT tell R4.

Why?
This is the iBGP Split Horizon Rule:

"A router cannot advertise a route to an iBGP neighbor if it learned that route from another iBGP neighbor."

In eBGP, we use the AS-Path to prevent loops. In iBGP, the AS-Path doesn't change, so we have no loop prevention mechanism in the packet. So BGP just bans re-advertising entirely to be safe.

The Result: R4 is an island. It knows nothing.

How to Fix It (The "Full Mesh" Pain)

To make this work, R2 must peer directly with R4.
In fact, in a standard iBGP network, EVERY router must peer with EVERY other router.

If you have 5 routers, you need 10 connections.
If you have 20 routers, you need 190 connections.
If you have 100 routers... you quit your job.

The Real World Solution: Route Reflectors

Since we don't want to configure 190 neighbors, we use a Route Reflector (RR).
We make R3 the "Boss".
We tell R3: "It's okay to break the rules. You are special."

! On R3
router bgp 200
 neighbor 2.2.2.2 route-reflector-client
 neighbor 4.4.4.4 route-reflector-client

Now, when R2 tells R3 a secret, R3 reflects it to R4. The Full Mesh requirement is gone.

Summary for the Lab

1. Missing Routes in the Table? Check Split Horizon. Do you need a Route Reflector?
2. Route is there but "Inaccessible"? Check Next-Hop. Did you forget next-hop-self on the edge router?

BGP is a protocol that assumes you know exactly what you are doing. If you don't, it simply drops your traffic and stays silent.

In Part 3 (which creates a loop instead of a black hole), we will discuss Redistribution.

See you in the CLI.