So now that we've covered neighborship establishment,
let's move on and talk about EIGRP neighbors.
EIGRP has two different primary timers, a hello timer and a hold timer.
The hello timer indicates how often an EIGRP device will send a
hello packet out its configured interfaces.
This hello packet is used for a number of different things.
It is used to discover new neighbors.
It is used as a keepalive to let existing neighbors know
that the local device is operating.
It is used to notify neighbors of the local device's
current K values and hello timer,
and it used to acknowledge other EIGRP packet types
when required to ensure reliability.
In most situations, the EIGRP hello timer is set to 5 seconds,
meaning every 5 seconds a device will send out a new hello packet.
The hold timer is used to determine when a neighbor
goes down or is hard to reach.
By default, the hold timer is three times the current hello timer,
so by default, it would be set to 15 seconds.
What this means is that if a neighbor doesn't receive a
hello packet before this hold timer expires,
then the neighbor is considered down and EIGRP will remove it from its
tables and try to find another route to the destinations that were
previously forwarded through that neighbor.
An important distinction to point out with EIGRP is that the
timers between neighbors don't need to be the same.
This differs from other routing protocols like OSPF.
Each device will take the hold time value that is advertised from a neighbor
and use it to determine when the neighbor is considered down.
So with this explanation out of the way,
let's see what happens in the lab when the hold timer expires.
Let's move back to R1 real quick for this lab.
And let's take a look at the configured EIGRP timers
on the interface between R1 and R2.
In this case, the hello interval timer, or hello timer,
is set to 5 seconds, and the hold timer is set to 15 seconds.
Now if you remember, whenever they're exchanging traffic,
one of the things that's exchanged as part of the hello timer and the
other packets is the K values and the hold time.
And as I noted in that slide there,
this hold time is used for whatever specific neighbor you're configured for.
So, if R1 is configured, as we note here,
with a hello timer of 5 seconds and a hold timer of 15 seconds,
but R2 is configured say with a hold time of 30 seconds,
R2 would advertise that my hold time is 30 seconds,
so don't consider me down unless 30 seconds goes by
before you receive a hello packet from me.
Let's move back into the lab into R2.
And just to clarify here,
we will show that R2 is initially configured with the defaults.
So let's go onto R2's interface and connect it to R1.
Set hold timer to 30 seconds.
We sit here for a second.
You'll notice that this neighborship doesn't go down.
And that's because EIGRP does not require that the
devices have the same timers between them.
Now, yes,
generally it is recommended that the timers are the
same between all of the devices.
Unlike other routing protocols like OSPF,
these timers do not need to be the same for the
neighborship to form in the first place.
So if we show this advertising,
let's move back into the capture window for a second and look
at the packet that goes between R2 and R1,
and you'll see in that hello, they're advertising the K values.
And in this case, it changed this hold time to 30.
So if we move over to R1,
this value that's shown on this command is my hold time,
not the remote hold time.
But in this case, if I look at the neighbor,
you will see that for only this entry, which is between R1 and R2,
this hold timer, if we just keep an eye here,
this will start at 30.
And you'll notice if you look at the one between R1 and R3, it resets at 15.
And this is because we configured on R2 that its hold
time on that interface was 30 seconds.
So R1 will take that advertised information from R2 and change the way that
it considers that neighborship down between R1 and R2.
So as long as R1 continues to get hello packet within that 30-second window,
it will keep that neighborship up.
Now if we go to R2 for a second and purposefully set the
hello timer to something that's above that,
which in normal practice makes no sense,
but this means that we're configuring R2 to only send
a hello packet every 40 seconds, but with a hold time of 30 seconds,
which means if we watch this, you'll see that R1 continues.
That hold timer goes down.
But since R2 only sends a hello packet every 40 seconds,
this hold timer will eventually expire.
And R1 will bring down that interface here in about a second.
Now if we wait another 10 seconds, you'll notice that that comes right back up.
So this will cycle and go back down again.
Now remember,
this is an important thing to remember whenever you're troubleshooting EIGRP,
because this will show that that neighborship,
the EIGRP neighborship, is flapping back and forth.
And the reason it's doing that is because R2 is
sending a hello packet every 40 seconds,
but it's also sending a hold timer that's saying,
hey R1, I'm going to,
consider me down if you do not receive a hello packet in the 30-second window.
But I'm also configuring it on purpose here to show the example that I'm
not going to send a hello packet every 40 seconds.
Now what happens if there is a link problem and for some
reason a hello packet is not getting through,
or maybe one's only getting through every so many seconds?
If three hellos are dropped on the link, then the neighborship will come down.
But it receives one.
So if it dropped three, the neighborship would drop and it gets one,
and then the neighborship comes back up.
And say it drops another three and the neighborship comes down.
What you're going to see is this sort of flapping behavior.
The same thing will happen if there are mismatched timers
where one is paying attention to hello,
and the hello timer's sort of mismatched in such a way
that I expect you to send a hello in this amount of time
and that amount of time passes.
That's what happens if there's mismatched timers,
or especially badly mismatched timers.
The general point that I'm trying to make here,
two things,
one thing is that they don't necessarily have to match with
EIGRP in order to form a neighborship, however,
it is a good idea in design and general best practice on every
network that I've ever been on that they are the same.
They may change from their default depending on the link speeds,
but they usually are set to the same values.
So with that covered, I'm going to change these back here in the middle,
and we are going to move on to a section talking about
the structure of the EIGRP packet, the different fields that are in the EIGRP packet and what they are used for.