EIGRP is the enhanced version of the Interior Gateway Routing Protocol (IGRP). IGRP is no longer supported by Cisco and isn’t on the exams, but EIGRP is one of the most popular routing protocols in today’s real-world networks
Over the years, EIGRP has been called 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 the initial exchange of all 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 contain every EIGRP route known to the sender.
EIGRP brings major benefits to our network, especially when compared to RIP:
- Rapid convergence when a change in the network is detected, since 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
- EIGRP considers bandwidth and delay when calculating routes, rather than the rather primitive “hop count” of RIP.
- EIGRP is no longer Cisco-proprietary, meaning it can be a run in the dreaded “multivendor environment” – a network with non-Cisco devices. (Horrors!)
Those benefits can’t benefit us until adjacencies form between our EIGRP-speaking routers. EIGRP uses Hello packets (multicast to 224.0.0.10) to establish and maintain neighbour 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 neighbours.
Other factors that must match for an EIGRP adjacency:
- If EIGRP authentication (NOT ON EXAM) is present, it must be active on both potential neighbours, and naturally the password must be agreed upon.
- The routers must be on the same subnet.
- A little something called “k-values” must match; since these are rarely changed, there’s usually not a problem here.
A big difference between OSPF and EIGRP is that EIGRP hello and dead timers need not much in order for an adjacency to form. A mismatch with EIGRP timers can cause other issues, as we’ll see later in one of our labs.
Once the adjacency is formed, it’s kept alive by a steady flow of Hello packets from the neighbour. 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.
The neighbour table keeps exactly what you’d think it would keep – information on the router’s EIGRP neighbours.
They 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.
The benefit here with the EIGRP is that if the path 1 to 4 is lost (either the link between 1 and 2 or 2 and 4 goes down), like this:
there is no real recalculation needed because R1 says “hey I have a backup path over here in the typology table and I’ll just make that backup path the primary path to get to R4.”
So then we have a new successor route and R3 would be the next hop. When that link is repaired between R1 and R2, if everything else has stayed the same, then 1-2-4 would again become the successor and 1-3-4 would be the back up.
NBMA Network Build
We are getting ready to configure our first EIGRP network. We’re going to be adding this as we go along. when we are configuring over an NBMA network, (R1 is our hub, R2 & R3 are the spokes) we know the deal. Anything that goes from one spoke to another, has to go through the hub of the hub and spoke config. With OSPF, we had to put neighbor commands on the hub (which is R1) and also we wanted to make sure the hub was the DR and that there was no BDR. That’s a good review because frankly in EIGRP we have none of these concerns! We don’t have a DR or a BDR nor is R1 going to need neighbors statements.
So let’s go ahead and get our lab started. I just checked our activity there and we’re good. So I’ve got ‘router eigrp’ . A couple of things I want to mention about it. First off, ‘router eigrp’ by itself is not a legal command. You’ve got to put an autonomous system number.
I personally have always just called this “AS” number and nothing wrong with that
We’re going to put 100 there and we don’t have any other options. So we’re going to go straight to the network command. We use it in the same fashion as we did with OSPF.
It’s going to be the word ‘network’ followed by the network you want to be advertised by EIGRP. The interfaces on this router belong into the network we specify. We run EIGRP and we don’t have any areas.
We do have one little odd gotcha here that I want to show you. And sometimes it’ll bite you.
Most of the time it won’t. But I want you to be aware of it. When I put my network number in here:
It even says ‘EIGRP wild card bits’ is up next.
But notice that here we’ve got the letters <CR> which means that network 172.12.123.0 is a legal command. Wild Card bits are not required with EIGRP. We use them so often (of course with OSPF they are required) that people tend to think “oh yeah you’re gonna have wildcard bits with your network statement”. No you don’t!! Most of the time you will, and I’m about to tell you why. Because there’s one little oddity that happens when you don’t use the wildcard bits. And the thing is the router doesn’t tell you about it.
What happens is the ios is going to take the network that you entered here (and in this case 172.12.123.0) and it’s going to put it in the ios in its classful form!
So what do we mean by that? What class network is 172.12.123.0? It’s a Class B network.
What does a class-B network have for a network mask ? 255.255.0.0. So that information is helpful. It comes up every once in a while, and it’s definitely coming up here, because then if you put the command in as I have it right now, that means that every interface that begins with 172.12.0.0 (their IP addresses) that means all of those interfaces went into being advertised by EIGRP.
Now maybe you don’t care about that in this situation. It really wouldn’t matter because these are the only interfaces we have on the router. But what happens if we put in network 172.12.123.0 by itself, the router takes it, but takes it as network 172.12.0.0?! because in effect this is what the router is going to do with it if we don’t put the wildcard bits. So what happens later if you come back and you open up a Fast Ethernet interface 172.12.1.0/24 and you don’t want it advertised by EIGRP? guess what! it’s going to be advertised by EIGRP.
So production networks and labs I would always use wildcard bits. I don’t remember the last time for any reason that I did not use wildcard bits here. For your EXAM, I would be very aware of the actual effect that it has. (I’ll show you later)
So for our purposes we’re going to put 0.0.0.255 here and that’s it. We don’t have to put the number in again. We don’t have to put the word EIGRP in again
So it’s go to R2 and see if we can get our adjacencies to come up.
So we saw a neighbor adjacency already come up and let’s finish up over here
and we’ve already got both our neighbors up
This is the first of the three tables that we were talking about earlier with ‘show ip eigrp neighbor’ and I will go over all of these in more detail later. Frankly there are only a couple that you generally pay attention to. At the very end, that is sequence number.
But what we are most concerned about of course is the address (who are our neighbors and how long have they been neighbors).
This is a good value to keep in mind and to keep an eye on if you start having some adjacency issues. Because sometimes adjacencies will reset and then other times they will actually have to be created again. We’ll bump into a situation like that later where they’re actually just reset and the up time should not be interrupted.
But for now we’re looking pretty good. So what routes should I expect to see in the EIGRP routing table right now?
If you said “nothing” you’re absolutely right. Absolutely nothing.
We don’t see anything because we don’t have any routes that have been discovered by EIGRP yet. The only network we’re even working with is 172.12.123 0 and those are directly connected to each of our routers (R1 & R2 & R3)
So they’re not going to show up as any kind of EIGRP discovered router.
The Spoke-To-Spoke Dilemma
Let’s get our loopbacks added to our EIGRP deployment and we’ll start on R1 since we’re there.
I just checked the routing table (which of course still has nothing in it) and our neighbor adjacencies first
So let’s go ahead with EIGRP 100. If I want to add only this one particular IP address(1.1.1.1), what wild card mask do I use right now? Answer: All zeros…
and no options at all. And that should be it.
Let’s good to R2:
See the whole table on this one but you also notice there’s our address 1 1 1 1 and 1 entry and we can ping 1.1.1.1 with no problem.
We’ll come back to the letter D here and the numbers in the brackets. Let’s first finish our network commands:
Then we go to R1 and make sure R1 sees it.
It does. All as well. And let’s check out R3’s EIGRP table:
R3 sees R1’s loopback right now but doesn’t see R2’s. So lets go ahead and add the loopback here on R3.
If we run ‘show ip route eigrp’ again, we’ll still see that R3 does not see R2’s loopback. Let’s go to R1 and see what’s going on.
R2 see both of the other router’s loopbacks…makes sense. And we can ping 2.2.2.2 and 3.3.3.3 and no problem at all.
So if we check our network here there is a little bit of a pattern.
It’s not like the network commands aren’t working correctly because each loopback is being seen by at least one other router. And in the case of the hub R1, that route is present on both spokes. So what the heck is going on here?
This is one of the distance vector protocol behaviors that EIGRP has, and it’s actually on by default. It’s called split horizon.
It was actually originally designed to prevent routing loops and it did a really good job in its day. But mostly it just gets in the way right now and that’s kind of what’s happening right now.
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 its serial interface, (that’s the only interface we really have ouside the loopbacks) so R1 can’t advertise that same network out that same interface. Therefore, R2 can’t learn about that network. (R1 has absolutely no trouble seeing 3.3.3.3 and communicating with it)
That’s why R2 doesn’t have it, because it can’t send the ad for R3’s lookback back out serial1/0. And why does R3 not have R2’s loopback? Exact same reason!
R2 sends the update, comes in to R1 serial interface, puts it in the table. No problem! we just saw it a moment ago(R2’s Loopback) and we can ping it with no problem. But again R3 is not going to see R2’s loopback. It only sees R1’s and this is exactly why. Because split horizon is getting in the way. To fix this issue, we are not going to go under the EIGRP though, this is an interface deal and we’ve got to go at the interface.
Where do we want to disable split horizon? This one’s pretty obvious. The one place that we need to disable split horizon is on R1 and on the serial 1/ 0 interface.
The reason I asked that is that you have to get used to that kind of thinking about how few interfaces can I configure here to make things right. Not because it’s going to take an enormous amount of time to go all three routers and put no IP split horizon, but the problem is, a question on an exam or job interview may well say “what’s the minimum”… They want to know that you know what’s going on. In here, the problem with split horizon is on your hub. So we’re going to do that again on R1
We’re not quite done because we want to disable it for EIGRP. And any time you put EIGRP it seems that you got to put that AS number in
and there you go… So we’ll see the results when we hit this.
And this is why I like using the real thing whenever you can, because you’re going to see console messages that simulators may not show you.
Here we have ‘dual-5-neighbor change’. Dual refers to the EIGRP routing algorithm. That’s actually what is creating the Routes and what’s calculating the routes. It’s the equivalent of what SPF does for OSPF. Dual belongs to EIGRP, and that’s why we’re going to see ‘dual’ here at the beginning of a lot of our console messages.
Now here you’ll notice it says ‘resynced’, and this is a huge advantage over what used to happen (and what can still happen on some older ios’s) is that when you disable split horizon your adjacencies are going to come down.
So when you disable split horizon it actually resyncs, and if we do a ‘show IP eigrp neighbor’:
You can see that the adjacencies never actually go down because here is your up time (white area)
Now we need to go to the Spokes and have a look around
The spokes are going to see each other’s routes, and we should have connectivity (we can ping 3.3.3.3 to check it). And no problem there.
So our routes have reappeared.
Why does it say “D” for EIGRP? Well the thing is the letter “E” actually belongs to EGP.
So just watch that on your exams. Really easy to fall for.
Now I’m sure you’ve also noticed that one of the numbers are brackets. These are just a little bit larger than OSPF costs we were looking at (will talk about them later)
That first number in the bracket is the administrative distance. That first number is always going to be the AD of that particular route. Internal EIGRP routes (the ones that are learned via the network command) are always going to have an AD of 90 and they will be marked simply with a “D”.
Sometimes they’re called native EIGRP routes. Generally the term is internal.
If you see DEX here, (and now I promise you you’ll see it here) your AD is going to be 170.
