EIGRP For The CCNA: Creating And Troubleshooting Adjacencies
In the first two parts of this tutorial, we covered EIGRP fundamentals and took a look at successors and feasible successors. Now it’s time to see theory in action on live Cisco routers! We’ll use the following hub-and-spoke network, with R1 serving as the hub. Gentle reminder: All spoke-to-spoke traffic must go through the hub.
We’re using the 22.214.171.124 /24 network for this lab, and the address of the Serial interface (the only ones we’re using right now) will have the router number for its 4th octet. R1’s Serial interface is 126.96.36.199 /24, etc.
We’ll enable EIGRP on each router with the network command. Unlike OSPF’s version of this same command, EIGRP does not require a wildcard mask to be set with EIGRP along with the network number. I strongly recommend you use wildcard masks when possible, especially in real-world networking, but for your exams it’s a good idea to remember that it’s not a requirement. I’ll use IOS Help to demonstrate that the network command is legal in EIGRP without the wildcard mask — the <cr> indicates that you have a legal command.
I also disabled something called “auto-summary” on all three routers. Must be important, right? Right! We’re going to come back to that command later in this lab. Right now, let’s concentrate on the adjacencies. Just a few seconds after enabling EIGRP on all three routers, this console message appears on R1:
Looks good, but we always verify — and we’ll do that here with show ip eigrp neighbor.
From left to right, the key values are the IP addresses of the EIGRP AS 100 neighbors, the local interface upon which each was discovered, and the uptime of the adjacency.
We have our adjacencies in place, but what of our routes? Will there be any routes in the EIGRP routing table? Let’s have a look via show ip route eigrp.
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 only subnet in our lab (188.8.131.52 /24) is on a directly connected interface on R1. Therefore, this route shows as a directly connected route in our IP routing table. It can’t be an EIGRP route since EIGRP was not used to discover it. By the way, you can use show ip route connected to display only the connected routes on a given router, just like this:
Let’s get some EIGRP routes going by adding a loopback interface to each router. We’ll use the router number for each octet in the address for each loopback, along with a /32 mask. However, we’re going to introduce these subnets to EIGRP with a 0.0.0.255 wildcard mask. I’m doing that simply to point out that the wildcard mask you choose in the network command does not have to match the IP address mask on the associated interfaces.
We didn’t create any new adjacencies, so let’s head right to the EIGRP route table on each router and see what we can see.
Curious. R1 is showing the two EIGRP routes we expect to see, one to R2’s loopback and the other to R3’s loopback. Each of our spoke routers is only seeing the hub router’s loopback. Neither spoke has a route entry for the other spoke’s loopback.
That’s due to a tricky little EIGRP default behavior called split horizon. Click that link and we’ll hit a lab showing you just how that feature works.