We’re about to add that Fast Ethernet segment between R2 and R3 to our EIGRP deployment.
You see here we’ve already got the loopbacks in, we have the NBMA network. I’ve already checked connectivity over the Fast Ethernet interfaces that haven’t added it to EIGRP yet. We’re getting ready to do that.
Want to show you one change though that I made during the break and that is setting the bandwidth to 1544 on the serial interfaces. Same way we did it with OSPF
we had one old setting from a previous lab and that’s why the metrics were even bigger than this.
So we’re going to go ahead and add that segment between R2 and R3 (172.12.23.0/27). Now what will be the accompanying wildcard mask here?
We have a subnet mask with 27 ones and five zeroes then you just invert every bit, and that’s a fancy way of saying the ones become zeros the zeros become ones.
So we would have a wildcard mask beginning with 27 zeros and ending with 5 ones and what would that be? Answer: 0.0.0.31
So we’re go and put it on three as well.
Dual neighbor change and that’s the diffusing update algorithm by the way.
DUAL stands for dual update updating algorithm.
We’ll go ahead check our neighbor adiacency:
we’ve got our neighbor relationship with R1 through the cloud through the serial interface and with R2 through the Fast ethernet interface. And you can see the uptime there is 19 seconds so it just came up as would expect and we’ll just go ahead and make sure we’ve got the same settings here on R1:
We’ve got neighbor relationships with R2 & R3 through the serial interface. On R2:
We’ve got exactly what we expect (adjacency with R1 through the cloud and with R3 through the fast ethernet interface).
So now let’s start checking the route tables but before we look at the routing table:
R1 has two paths to get to the 172.12.23.0/27 network. But it also has two paths to get to each of the loopbacks. One might not be as good as the other (might be a little longer), but to reach R2’s loopback, R1 could go through the cloud, down to R2, and you’re there. But it could also send packets down to R3 which would then go through the Fast Ethernet segment and then arrive at R2.
So let’s see what our routing table tells us with ‘show IP route eigrp’ ( you can do ‘show irp route’ as well but it would be more shooloogh pooloogh and fills up with different kinds of routes it can be a little harder to spot exactly the one route type you want)
We can see all the routes here on R1 that EIGRP has discovered.
So we see one entry for each of the loopbacks on R2 and R3 respectively. And then we have two entries for the 23.0 network. And why is that?
EIGRP performs equal costs load balancing by default, and with a metric like this when they get those long, you might think well how often do you see these be exactly alike?(red)
Not too often! but it does happen in here. R1 is just saying “hey when I want to reach that Ethernet segment, if I go through 123.2 or I go through 123.3, the metric is exactly the same. So I’m going to put both entries in my routing table. Both of those routes are considered successors. Because when you describe what a successor route is, the best of the loop free paths to a given destination, It makes it sound like you’re always just going to have one. But that’s not true. You can have more than one successor route, and that’s actually what we have right here. Because when you run ‘show IP route eigrp’, What are you really looking at? You’re looking at all the successors. There are no feasible successors in this table. None! They are in another table. We’re going to have a look at that with ‘show ip eigrp top’ (and that is short for topology and you can type the whole thing if you want to)
We have good information here about what AS you’re running and there’s an ID that’s the EIGRP RID (router ID). We’ve got entries for the network three, network two, two successor’s for the one we were looking at which is 23.0/27.
So you can have more than two successors and the reason we have two successors here is that this value(2172416) which is the feasible distance is exactly the same for each one of the routes.
Now what’s a little bit interesting here is that in the routing table(previous pic), we have one entry for the subnet 2.2.2.2 and we have one entry for R3’s loopback. But if we go to the topology table, we have two entries for each one of those routes.
So why do I have two entries in my typology table for each one of those but only one in the routing table? Answer: Let’s take R3’s loopback first.(blue) and EIGRP has determined there is one successor… there is one best route to get there and it’s through R3 and that’s what we’d expect just by eyeballing it.
Now I know we can always tell that way but just with the lab we’ve built so far we could look to that and said okay it’s fine if we’re going to lookback three we’re going to send the packets straight to R3. what EIGRP has also determined, is that there’s another path (The other path that we talked about to get to R3’s loop back) and that is through R2 and the metric is just a little bit higher.(yellow)
But EIGRP has looked at this and said “okay this path is valid through R2. This path is loop free. so we’re going to go ahead and put it in the typology table and this is a feasible successor.”
Notice that it doesn’t say that, but we know it is. Because it’s not the best route. This is the successor right here.(green)
And you can always tell because this FD (feasible distance) is going to match this value(pink).
But this second one that’s listed 123.2 (yellow) is a feasible successor because EIGRP says here’s the metric. It’s a good metric. It’s a loop free path. But the metric here is not as good as the other path.
So for each one of the loopbacks we have one successor and then we have one feasible successor. Same deal here with two.
From Feasible Successor To Successor
Time to put or feasible successors to the, test and the feasible successor we’ll be testing here is the one for R2’s loopback. We’re going to make sure that becomes a successor when the actual successor route leaves the table.
Before we do that, we’re going to hurry the timing up a little bit here as far as the hello and hold times for EIGRP. It could be a little tricky to find EIGRP command sometimes. Let’s go to our interface here on R1. Now when we were working with OSPF, we changed several things. We changed the priority, the hello time, the dead time and the command always started with ‘ip ospf’.
Now even though I’m not running OSPF on this router, the interface level commands are still available.
So when I ran ‘ip ospf’ we used Hello interval, Dead interval and priority.
Well when you go in here, you say “OK I want to change the hello and dead times or hello and hold time specifically for EIGRP.”
So I’ll just go in and I’ll just do ‘ip eigrp’
We get unrecognized command! How can this be unrecognized when I’m running EIGRP? The syntax is a little bit different. You have to go with Hello here (and its Hello interval) and then EIGRP would be an option. Then we’ll choose 100 as a the AS number.
And then finally the seconds between the hello transmissions. So what I’m going to do, is shorten this down to five seconds for our serial interfaces and then I’m going to set the whole time to 10 seconds. I want you to see exactly where we set these commands because that’s a pretty odd looking command there.
And what we’re doing here is hold time
So to help you remember, we’re going to do that on all three of our interfaces here.
So let’s run ‘show IP eigrp neighbor’ up on R1. Make sure we’ve got our adjacencies and that they stay there.
Do you see the whole time for the serial link is way down now and it shouldn’t go below 5.
So everything is fine here.
What we’ll do is on R2 we’ll actually shut that interface down.
And at that point, the path we’re using to 2.2.2.2 right now will be gone and we expect the feasible successor to go ahead and step right in.
Everything is fine right now let’s go to R2 and make things not so fine shutting that interface down.
You know we should see that adjacency go pretty fast.
So now when I run ‘show ip eigrp neighbor’ the only one I have, is point 3 now over there and R3 because the other one has already dropped. And you see the “holding time expired” is the message we’re getting there. Let’s go ahead and do ‘show IP route eigrp’
You can see this route’s already been in the table for 20 seconds(red). Here’s the route for 2.2.2.2. But now it’s going through R3 and again by the time I ran ‘show IP route eigrp’, that route had already been in there for 20 seconds. That’s how fast the cut over is.
Now can we still ping that destination? yes we can(ping 2.2.2.2).
So now if we run ‘show IP eigrp top’,
we’ll see for R2 that we have one successor, the loopback on R2, and also about the paths to router 3, we’re down to one path there Because R2 is shut down.
So we’re seeing exactly what we expect to see. Everything is going through R3. You’ll also notice now for the Ethernet segment 23.0/27, we only have one successor because R2 is shut down. So let’s go ahead and reopen that interference, and then run ‘show ip route eigrp’
After a little bit of waiting , we’ll see the message about the adjacency comimg back up.
And I run ‘show ip route eigrp’ again immediately after I got the neighbor change message,
You’ll see that we’ve already switched back over to 123.2 to get to R2’s loopback and the route had already been there for five seconds.
Also notice that we have our two paths once again to 23.0/ 27. If we send a ping 2.2.2.2, we’ll see that we’re in great shape.
So again those feasible successors waiting for us on the topology table is a fantastic thing because those routes can be made successors immediately when that first successor goes missing.
So let’s go and run the topology table again here.
And this is when you might want to do a little bit of tweaking because equal cost load balancing is on by default with EIGRP but unequal is not. And we’d expect that. We don’t really want unequal cost load balancing unless the network admins going to make that happen.
On our toplogy table here, is these metrics are so close. You know here are two possible paths to R2’s loopback at those metrics are pretty close. R3’s metrics pretty close from R3’s loopback from R1.(red)
So maybe we’d like to do a little unequal cost load balancing. If we had a lot of data going to either R2’s loopback or R3’s loopback, maybe we’d like to use both of these paths. Since the metric is not exactly the same, EIGRP isn’t going to do that by default. So you and I are going to go in and do it not by default. We’re going to manually configure it.
