CCNP ROUTE Tutorial: EIGRP Lab #1 — Fundamentals and Split Horizon
Two quick things before we start…
- This EIGRP lab and the ones that follow are for you future CCENTs and CCNAs, too!
- This entire whopping EIGRP tutorial section is straight from my CCNP ROUTE Study Guide, available only on Amazon. Check it out when you’re done here!
Now, let’s get started with a quick review of important EIGRP fundamentals before we dive into the lab work!
EIGRP is the enhanced version of the Interior Gateway Routing Protocol (IGRP). IGRP is long gone; it’s no longer supported by Cisco and isn’t on the CCNA or CCNP exams. EIGRP is known as a hybrid protocol, since it officially has characteristics of link state and distance vector protocols. As you’ll see, EIGRP acts much more like an LS protocol than a DV protocol. The main DV behavior shown by EIGRP is the initial exchange of full routing tables between EIGRP neighbors.
After that initial exchange of full tables, an EIGRP router will send an update only when there’s a change in the network. That update will reflect only those changes and will not consist of a full routing table.
EIGRP brings several major benefits to our network:
- Rapid convergence when a change in the network is detected; backup routes (“feasible successors”) are calculated before they’re actually needed due to the loss of a primary route (“successors”).
- Multiprotocol support, including IP, IPX, and Appletalk
- Support for VLSM and CIDR
Those benefits can’t benefit us until adjacencies form between our EIGRP-speaking routers. Actually, nothing can happen between our EIGRP routers until adjacencies form, so let’s spend some time with the packet that makes these happen.
EIGRP uses Hello packets (multicast to 224.0.0.10) to establish and maintain neighbor relationships. The Reliable Transport Protocol (RTP) is used to handle the transport of messages between EIGRP-enabled routers.
EIGRP uses autonomous systems (AS) to identify routers that belong to the same logical group. EIGRP speakers that are in separate ASes cannot become neighbors.
Once the adjacency is formed, it’s kept alive by a steady flow of Hello packets from the neighbor. If those Hellos stop coming, the adjacency is eventually dropped.
The Successor and Feasible Successor
EIGRP keeps three important tables. The route table stores the best route to each remote network the router knows of. The topology table keeps all known valid, loop-free routes to those same networks. Finally, the neighbor table keeps exactly what you’d think it would keep – information on the router’s EIGRP neighbors.
The route and topology tables play a vital role in EIGRP’s rapid recovery from a lost route. Here, R1 has two paths to R4. EIGRP has determined the path through R2 is the best. That route will be placed into both the route and topology tables. The route through R3 is valid and has been determined by EIGRP to be free of routing loops, so that route (a feasible successor) is placed into the topology table.
Should the primary route (the successor) be lost, EIGRP doesn’t need to calculate a new route. EIGRP would then name the route through R3 as the successor, and routing goes on.
Let’s start our first lab right now by configuring and verifying EIGRP adjacencies on the following network! This is a hub-and-spoke network, with R1 serving as the hub and (you guessed it!) R2 and R3 serving as spokes. Any traffic that goes from R2 to R3, and vice versa, will pass through R1.
Each router’s Serial 0/1/0 interface is connected to the frame relay network, and we’re using the 172.12.123.0 /24 subnet for IP addressing. The router numbers are used for the 4th octet of the address – R1’s Serial 0/1/0 interface is 172.12.123.1, and so forth.
We’ll use the network command to enable EIGRP. The command network 172.12.123.0 0.0.0.255 enables EIGRP on any interface in the 172.12.123.0 /24 subnet. The use of wildcard masks is optional, but you’ll see them in 99% of real-world EIGRP deployments. Watch that detail on your CCNP ROUTE and TSHOOT exams. EIGRP and OSPF both use wildcard masks, but they’re required only in OSPF. The network 172.12.123.0 command is legal in EIGRP, as verified by IOS Help on R1.
I disabled something called “auto-summary” on all three routers before I even put in the network command, so it must be important! More on this later, but for now note that EIGRP has autosummarization on by default.
Just a few seconds after enabling EIGRP on all three routers, this console message appeared on R1.
EIGRP hello packets have discovered two potential neighbors, and all must have been well, because those potential neighbors quickly became actual neighbors! We’ll verify with show ip eigrp neighbors.
From left to right, the key values are the IP addresses of the EIGRP AS 100 neighbors, the local interface upon which they were discovered, and the uptime of the adjacency.
We have EIGRP adjacencies, but do we have any EIGRP routes? Let’s check via show ip route eigrp. (The code tables have been removed from the following command outputs for clarity’s sake.)
When a show command drops you right back at the enable prompt, that means there’s nothing to show you! We have no EIGRP routes because an address from the 172.12.123.0 /24 subnet is on a directly connected interface on each router.
Let’s get some EIGRP routes into our lab by adding a loopback to each router. We’ll use the router number for each octet in the address along with a /24 mask.
Let’s have a look at our EIGRP routing tables.
Curious! 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., especially when we have a hub-and-spoke network like this one.
There is no direct connection between our spoke routers, 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 that network.
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!
Split horizon can be disabled, and in a lab environment doing so doesn’t worry me (mostly). 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 in this command. That’s pretty much the rule with EIGRP-related commands — you gotta tell the router what AS you’re working with (again).
A few seconds later, I received these console messages:
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 didn’t come all the way down. Had the adjacencies been lost, the uptime would show just a few seconds rather than over 100 minutes.
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, you gotta trust me there), so we’re good to go!
This is a great lab to get started, but to fully illustrate successor and feasible successor routes (along with other EIGRP features), we need a bigger network. We’ll start EIGRP Lab 2 by adding a broadcast segment to our network…
… and then we’ll see what kind of trouble we might just bump into! See you Wednesday, March 7 with the next lab!