The Metric Weighs
EIGRP uses the metric weights to determine how much importance to give a particular value when calculating route metrics. The k-values, in order:
K1: bandwidth
K2: load
K3: delay
K4: reliability
K5: MTU
By default, EIGRP takes bandwidth and delay into consideration (equally) when calculating route metrics and ignores the other values. You’re much more likely to run into a k-value mismatch in an exam or a lab environment than in a real-world network. Most of the time, real-world networks use the default k-values.
(Note: While the MTU is advertised, it’s not actually used in the route calculation.)
There are only five k-values, but the metric weights command requires six values. The first one is the Type Of Service value for EIGRP packets. We’re given a range of 0 – 8, but the router will only accept zero! After that, just enter the k-weights that you want.
And here we’ve got our adjacency from the previous section between R1 & R2. Nothing’s changed there.
And you can spot the metric weights in ‘show IP protocols’
notice that K1 is set to 1 by default as is K3, and K2, K4 and K5 are all set to zero. And also notice that this doesn’t tell you what K1 is! which is why I did recommend that you have that list memorized (bldrm like oldromboldrom)
So again bandwidth and delay are always going to be set to 1 by default.
Now if I wanted it to give twice as much value to bandwidth as I did delay, and then I still wanted the other values to not be considered, I could go with 2 for bandwidth and then set delay to 1.
But the thing is when you do this:
Notice you have to specify them all. You can’t just put in K1! you got to put them all.
So again we know that the K values actually start with the second number here in this particular command. And I’ll just go ahead and hit enter. And I have lost my adjacency.
So we’re going to see all kinds of messages here. What I’m going to do very quickly is fix that so we don’t have to look at that
Let’s go ahead and verify that change will show IP protocols
You can see that the metric weights have been set back. And boy it did not take long for that adjacency to drop right?
This is a value that has to agree between potential EIGRP neighbors and existing EIGRP neighbors.
Now you’ll notice the first dual message that we received about a neighbor change(three pics back) and there is that dual neighbor change information(red) and the neighbor is down and ‘metric changed’. And then we started getting a little something about these value mismatches(green) and you know what’s going on there. That’s a k-value mismatch.
And it’s just that simple they have to match between existing neighbors, they have to match between potential neighbors or you’re going to lose them.
You also notice that with the metric weights command there is no partial way to apply that.
You can’t apply it to one neighbor or one particular link that kind of thing. It’s an all or nothing deal.
And there’s our adjacency back up (after couple of minutes!)
“Goodbye Messages”
EIGRP sends a goodbye message when EIGRP will no longer be functioning between two neighbors, but the link itself is still up. (For instance, removing the network statement from one neighbor.)
You may see GOODBYE in the console message; you may see PEER-TERMINATION. This EIGRP graceful shutdown allows for a more orderly end to the adjacency and to let that peer know the network has changed, rather than wait for hold timers to expire.
Let’s look at the network: (very familiar)
172.12.123.0 over the cloud, and then our Ethernet segment running between R2 & R3 down there on 172.12.23.0/27.
I’ve already got the network commands in place, and we take a look at R1
and you can see that we are load balancing to get to 23.0/27, and the next hops are .2 and .3 just as we would expect. And the neighbor relationships are taken right along.
With a graceful shut down, on our broadcast segment if an adjacency is lost, the EIGRP reaction is pretty quick, because the hello and hold times aren’t particularly big.
The problem is with a serial interface if something happens to R2 right now, it’s going to take somewhere between two and three minutes for R1 to realize the adjacency is gone.
So right now that whole time is in 128 seconds you can see we just got a hello that refreshed it up to 178. So again it’s going to be two to three minutes before R1 reacts to it.
Let’s make that happen. We’re going to go down a R2 and we’re actually going to shut the interface down (the serial interface) and we’ll see how R1 reacts to that.
So we shut it down. I zipped up to R1 to catch any messages we might be getting. And I don’t see any messages! because now that the hellos are not coming in, the neighbor relationship is not going to be renewed.
But the problem is as you can see it’s going to take a 138 seconds for R1 to realize it I lost that adjacency. And meanwhile especially in a larger network and especially in a production network you might be sending packets in a direction that they actually can’t go, because right now one of our equal-costs load balancing entries for 23.0 is 123.2. But literally we can’t ping that address
We just shut the interface down! something happened physically to it! And when that happens we know that we’re not going to get any kind of graceful shutdown here because R1 doesn’t even know R2’s gone yet.
(as a reminder, that escape sequence to stop your pings is control+shift+6 twice)
So let’s go ahead and reopen that interface.
The adjacency is now back up… let’s check everything just in case.
And you see the adjacencies back up… that’s been up for about 27 seconds and of course with ‘show ip route eigrp’, the table is going to be the same.
So you see the issue there (especially with a serial link)… and this is where a graceful shutdown comes in.
Again it’s only going to occur when EIGRP stops functioning and appears going to be terminated. But the physical link is still up.
So to do that down on R2 what we’ll need to do is either remove the network statement for 123 cloud network or we could just take EIGRP off…
Here you the goodbye is received and here are the two great things about that:
You’ll notice that we’re not load balancing anymore(red), and you notice the adjacency to R2 is already gone(yellow).
So that’s what a graceful shutdown is all about. It allows the router that’s receiving that goodbye message, to immediately see that change. Basically it’s a notification which says “hey a change has occurred and you need to adapt to it really quickly”.
For example, we know the hold time for the R1 – R2 adjacency is 180 seconds.
If R2 leaves the EIGRP AS, graceful shutdown allows for an immediate notification to be sent to R1.
Note: This notification takes the form of a Hello packet with every K-value set to 255.
In short, a goodbye message means “Things have changed in the network.”
