EIGRP For The CCNA: Split Horizon

At the end of the previous EIGRP tutorial, we noticed that only R1 has an entry for both loopbacks in its routing table.  Both spokes can see R1’s loopback, but neither R2 nor R3 has an entry for the other’s loopback.   A quick review of our network topology and router table entries:

Loopbacks added to lab

Each router's EIGRP route table

R1 is showing the EIGRP routes we’d expect, but neither spoke router can see the loopback network on the other spoke router.   That’s due to split horizon, an important routing loop prevention behavior that can on occasion play havoc with your routing tables.   This is one of those occasions!

There is no direct connection between R2 and R3.  Any traffic sent by one of those routers to the other must pass through the hub router (R1), and that’s where split horizon comes in.  The rule of split horizon dictates that a router cannot advertise a route back out the same interface upon which it was originally learned.   R1 is learning about R3’s loopback network via an EIGRP update received on Serial 0/1/0, so R1 can’t advertise that same network out that same interface.  Therefore, R2 can’t learn about R3’s loopback.

EIGRP Split Horizon

R1 is learning about R2’s loopback network via an update received on Serial 0/1/0 as well, so R1 can’t advertise that network via that same interface.  R3 is left out in the cold!

More EIGRP Split Horizon

Split horizon can be disabled, and in a lab environment doing so doesn’t worry me.  In a production network, I’d be very careful about doing so.  While you may get the result you want, you might get other results that you don’t want.

Note that SH is disabled at the interface level and that the AS must be specified.

Split Horizon For EIGRP Configuration

Note that SH is disabled at the interface level and that the AS must be specified.

A few seconds later, I received these console messages:

EIGRP Adjacencies Reset

In the past, disabling or enabling split horizon resulted in the temporary loss of EIGRP adjacencies.  The messages here mention the neighbor being “resynced” instead of lost.  The uptime from show ip eigrp neighbor verifies the adjacencies were not actually lost:

show ip eigrp neighbor

Had the adjacencies been lost, the uptime would show just a few seconds rather than over 100 minutes.

Let’s have a look at the spoke routers’ EIGRP route tables:

Spoke Router EIGRP Tables

Disabling SH on the hub router’s Serial interface has the desired result, as R2 and R3 now see each other’s loopbacks.  I’ve also pinged every interface from every router with 100% success (ping results not shown), so we’re good to go!

Coming up next, we’ll add an Ethernet segment to our growing network and work with equal-cost and unequal-cost load balancing.

EIGRP CCNA Lab:  Equal-Cost Load Balancing

Chris B.