DEV Community: Kim Li

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

Kim Li — Tue, 06 Jan 2026 09:50:37 +0000

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

Missing Routes in the Table? Check Split Horizon. Do you need a Route Reflector?
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.

Why "Active" State Actually Means You Failed

Kim Li — Tue, 09 Dec 2025 03:59:01 +0000

Welcome to Route/Switch & Sleep Deprivation: A CCIE Diary.

If you are reading this, you probably enjoy pain. Or, like me, you decided that knowing "a little bit about networking" wasn't enough, and you wanted to chase the holy grail of network certifications: the CCIE.

I am currently in the trenches of studying for the CCIE Enterprise Infrastructure. My coffee consumption has tripled, and my dreams are now exclusively about packet headers.

Today, we are starting with the protocol that runs the world (and occasionally breaks Facebook): BGP (Border Gateway Protocol).

Specifically, I want to talk about that magical, frustrating moment when you try to get two routers to talk to each other.

The Protocol of "Trust No One"

Unlike OSPF or EIGRP, which are like friendly neighbors shouting "Here I am! Let's be friends!" over the fence (Multicast), BGP is a grumpy old man.

BGP doesn't discover neighbors automatically. You have to explicitly introduce them. You have to manually type in the IP address of the peer and say, "Trust this guy." It’s a TCP-based protocol (Port 179), which means before any routing information is exchanged, we need a solid TCP handshake.

It sounds simple. But in the lab, "simple" is a trap.

The Topology: Keep It Simple (For Now)

Let's look at the setup I’m running in GNS3 today. It’s the "Hello World" of BGP.

R1: AS 65001 (Interface Gi0/0: 192.168.12.1)
R2: AS 65002 (Interface Gi0/0: 192.168.12.2)

This is eBGP (External BGP) because the Autonomous System (AS) numbers are different.

The Config: Where Typos Go to Die

Here is the config on R1. It looks innocent enough:

R1(config)# router bgp 65001
R1(config-router)# bgp router-id 1.1.1.1
R1(config-router)# neighbor 192.168.12.2 remote-as 65002

And on R2:

R2(config)# router bgp 65002
R2(config-router)# bgp router-id 2.2.2.2
R2(config-router)# neighbor 192.168.12.1 remote-as 65001

I hit enter. I wait.

In the world of OSPF, I’d see a console message immediately. FULL adjacency! Success!
In BGP, silence is common. BGP is slow by design. It doesn't want to flap (connect/disconnect) constantly.

The "Active" Trap

I ran the verification command that every network engineer types 500 times a day:

R1# show ip bgp summary

The output showed the state as Active.

Now, if you are new to networking, "Active" sounds good, right? Active means working! Active means energetic!

Wrong.

In BGP land, Active means "I am actively trying to find my friend, but he is ignoring me." It means failure. It means you are screaming into the void.

What we want is Established.

Troubleshooting My Own Stupidity

Why was it stuck in Active?

Layer 1/2 Issue? Can I ping 192.168.12.2?
- Result: Yes. Ping works. So the cable isn't broken.
TCP Port 179? Is an Access Control List (ACL) blocking port 179?
- Result: No ACLs on these raw routers.
The Typos.

I looked closer at R2's config.

R2(config-router)# neighbor 192.168.21.1 remote-as 65001

Do you see it?
I typed 21.1 instead of 12.1.

BGP didn't warn me. It didn't say "Hey, that IP doesn't exist on this subnet." It just accepted the command and sat there, waiting for a ghost neighbor at 192.168.21.1 to say hello. Meanwhile, R1 was knocking on the door of 192.168.12.2, but R2 didn't recognize R1's IP as a configured friend, so it slammed the door (sent a TCP RST).

The Fix and The Lesson

I corrected the IP on R2.

R1# show ip bgp summary
BGP router identifier 1.1.1.1, local AS number 65001
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.168.12.2    4        65002       5       6        1    0    0 00:00:03        0

State/PfxRcd shows a number (0). This implies the state is Established. The "0" just means we haven't learned any routes yet, which is fine—we haven't advertised any networks.

Takeaway for the CCIE Lab:
Fast typing is great, but precise typing saves you 20 minutes of troubleshooting. When BGP is stuck in "Idle" or "Active," check Layer 3 connectivity first, then check your neighbor statements for dyslexia-induced typos.

Next Time...

We have a connection. But right now, R1 and R2 are just staring at each other. They aren't sharing any juicy routing data.

In Part 2, we will dive into advertising networks, manipulating the BGP table, and why next-hop-self is the command you will forget most often.

Until then, keep your packets flowing.

(P.S. If you are also studying for the CCIE, connect with me! Let’s suffer together.)