So let's start out our demo section here with a neighbor establishment lab.
In this case, what we're going to do, now let's take a look at the typology here.
We're going to take a look and we're just going to set up
the neighborship between R1 and R2.
As of right now, neighborships exist everywhere else,
but we just wanted to take a closer look into the captures,
and then we can look into the packets and what packets are
sent back and forth and review the information that we just
went over in the previous sections.
So let's move into the lab.
Let's start with R1.
See here the Gigabit 0/1 interface is currently connected to R2,
and currently the EIGRP configuration does exist,
but only going between R1 and R3.
By putting this command in,
we're going to enable the EIGRP on the interface between R1 and R2.
Jump to R2.
(Working) R2 is configured the same way where it's
configured for EIGRP everywhere else, but not between that interface.
(Working) Once we do that,
we see that the neighborship comes up between R1 and R2.
And if we look at the neighborships table,
we'll see that that interface has come up.
Go back to R1, we'll see the neighborship come up.
And tables come up.
So while I was doing this, I have an active capture going on at the same time.
So let's move back, move back, move into the capture window here.
So, here's the capture window between R1 and R2.
And here's where we configured R1 to begin these first eight packets or so,
or after we configured R1 for EIGRP.
And then at this point, we configured R2 for EIGRP,
and then we'll notice that the conversation will begin between the two of them.
First, let's take a look here at the two TLVs that are included in the message.
But let's just use, let's see, use this, one of these hellos from R1 to R2.
The two different TLVs that we mentioned about the hellos was a parameter TLV,
which is this one, and a software version TLV,
which is the second one right here.
Look a little bit closer, we'll see the Type: Parameters TLV 0001.
Software Version: TLV 0004 as we noted in the previous slides.
The parameter 1 is used to let any neighbors know of
R1's currently configured K values.
In this case, we have K1 and K3 being set,
and it's also advertising R1's hold timer over to its neighbor,
in this case, will be R2.
Software Version: EIGRP version 23.
This is coming from a Cisco 15.6 device.
And the TLV version is 2.0.
So the TLV version, as I noted on the slides,
changed between an older version, the older specification version of EIGRP,
which is considerably old at this point,
and now.
So as long as everybody has a compatible TLV version,
they can communicate and they can become neighbors and work as expected.
So this is the hellos that are going back and forth.
As soon as they see each other, R1 will send the update packet over to R2.
This packet says n1.1 to .2.
When you look in here, we'll see this is an Update packet with an Opcode of 1.
See here, flags, we covered the flags that were talked about.
We said there are four different flags that are
typically used with an update packet, INIT,
Conditional Receive, Restart, and End of Table.
In this case, as we noted,
one of the initial flags that's sent between neighbors is the INIT flag.
This is used both to make sure that bidirectional
communication exists between the two devices,
because in a second we'll see that there's a packet coming
back from R2 basically syncing this, or acknowledging this,
and this also tells R2, okay, I'm initiating communications with you.
I would like you to send over all of the information that you
have in your tables and I will do the same.
Here in a second, we'll see that exchange.
Okay, so in one other thing I noticed here is my sequence number is 24.
If we chase this down a little bit, skip these other packets for a second.
If we go down to this packet, hello acknowledgement.
This is a hello packet that's empty except that it acknowledges a packet.
If we look back at this update packet we first looked at,
the sequence number was 24.
If we look at this acknowledgement packet from R2 to R1, acknowledge 24.
So the only purpose in this packet is to acknowledge that
update packet that's about five up here.
This says, I've got it, we're good.
And the other thing it does in the middle here is it'll send,
this is the update packet from R2 to R1 basically saying the same thing.
This INIT flag is open and the sequence number of 39.
So this is basically R1, R2 having that same conversation back to R1 saying,
okay, I want to initialize an update from you.
Please send over your tables to me.
This is two things; this is a set,
usually whenever there is an initial conversation going back and forth,
there are two update packets that go back and forth between the two.
One of them has an acknowledgement packet of 0 and one of them has an
acknowledgement packet of whatever that other one was.
So in this case, this packet does two things.
The first thing it does is it just sends another update packet that says,
again, I want to initialize with you, and I want you to send me your information.
And the second thing it does is it sends an acknowledgement flag with
the sequence number of the previous packet from R2.
So what that does in effect is that's where the verification of
bidirectional communications exist between the two devices.
Two then sends out, in this case to the multicast address, this whole table.
These are the networks that, remember,
R2 was configured with EIGRP to all the other devices in the network,
except R1.
So in this case, it knows the reachability of the rest of the network,
so it's going to send them a large table.
So this is all the routes that are in R2's topology table
that currently has successors to them.
On top of that, these are all different TLVs.
If we look into them, well, first thing let's look at the flags.
The flag is an End Of Table flag,
which means all of the routes that R2 owns can fit
within one update packet size.
And because of that, this is the end of the table.
We don't need to send multiples of this.
If this was an empty flag and it had routes in it,
there's a large table of information that would be sent and then
you would see multiple update packets updating all of the
different routes that exist within it.
In this case, the total length is rather small compared to what's allowed,
and I can fit all of my routing information in one packet,
so I can use the End of Table field.
The second thing I want you to notice about this is if you
remember from the very last couple slides from the TLV section
is the iOS versions that I'm using, in this case for 15.6,
and you'll see in here we are using the multi-protocol TLV.
I this case it's 0602, so this is an internal route.
Part of that multi- protocol TLV,
which we did not go into deeper because it's a bit out of scope,
is there are fields within that TLV that tell you what
type of protocol that is running.
It's not a specific TLV that's only supposed to be used for a specific protocol.
So like the older devices would send a specific TLV like,
in this case, this is an IPv4 internal route,
it would be a 0102 TLV,
and it wouldn't be as big as this because it doesn't have to have fields
that indicate what protocol it is because it's assumed.
In this case it also allows room for a wide metric,
which we didn't talk about here.
There actually is sort of a legacy metric which we discussed,
which is used in a lot of different places,
mainly on smaller,
lower-speed networks that don't have 10 or 40 or
higher gigabit per second interfaces.
But there is a wide metric that's available that supports metrics that
are a larger size metric that allows it to differentiate between
interfaces that are faster than a gigabit correctly.
In this case we're not using those fields,
we're only using the ones that we discussed,
which was Reliability load, Delay, and Bandwidth.
And then from here, the RouterID,
this is the router ID of the initial advertiser,
and this is the network it's advertising.
And up here, Prefix Length, this is the subnet mask of the prefix length.
Now all these are basically the same.
All these are internal routes.
We're going to show in a future demo here what happens
whenever you do an external route.
So let's follow this conversation back a little bit.
This is me sending you everything.
And sequence number 43, and you should see here,
right here a couple packets down, this was the update and this is 43.
This is R1 acknowledging the packet back,
that update that we had just looked at, saying,
okay, I've got it, we're good.
From this point,
R2 now knows that he had sent his update packet and R1 has correctly received,
reliably, all the routing information that he had gotten.
At this point,
R2 is fine and he no longer needs to send any additional packets back out,
unless anything updates.
On occasion, you'll see here, link the metric is infinity,
so in this case, he sent the main table that he knew,
then he exchanged information with R1, and when he did that,
he found out that his route to some of the networks
that R1 now has better routes for.
He sort of,
he's talking back and forth with R1 and finding out
whether R1 has a better route than he does,
and then he's automatically sending out a poison route for these two networks.
So for the 4 network and for the 20 network,
he's poisoning these both with the infinite delay.
So those networks, he's saying that R1 has a better route to those destinations,
and previously, he would have thought that he had a route back on the other side,
on the other three interfaces that connected to the rest of the network. And in this case, he would use R1 to go in that direction.