So now that we have covered the basics of EIGRP routing concepts,
in this module, we will move on and begin a discussion about EIGRP neighborships.
EIGRP uses neighborships just like link- state routing protocols to form a
trusted bond between two similarly configured devices.
Once this neighborship is established between devices,
they are able to communicate their learned information with each other.
There are a number of different requirements that must be met
before an EIGRP neighborship will form.
These include matching autonomous system numbers,
metric K values, authentication parameters,
and if using IPv4, the devices must be in the same IP subnet.
Of course,
the assumption here is that devices are able to receive traffic from each other.
Normally,
neighborship establishment is automatic and is done with
the use of multicast hello packets using either the 224.0
.0 .10 or FF02::A addresses.
In cases where multicast communications are not possible,
then each of the devices must be statically configured with a
unicast address or addresses of their prospective neighbors
along with the connecting interface.
It is important to note that even when multicast is used for
neighbor establishment and maintenance,
unicast is still often used when devices exchange route entry information.
To show how this works a little closer,
let's move into the lab and see what it looks like when
we enable EIGRP between two devices.
Okay, so for this lab,
we are going to start with two different devices that
connect together via a single interface.
In this case,
R1 and R2 will be used from the topology that we were using in module one,
and they are connected via both of their GB 0/1 interfaces.
Currently, they are configured with IP addressing information,
but they are not configured for EIGRP yet.
(Typing) What we're going to do on R1 is we're
configure EIGRP for use on this interface.
In this case, it's the 10.10 .10 .0 /30 network.
On R2, we're going to do the opposite.
You'll notice here that the only interface that we actually
have up is the one between R1 and R2, and that is on the same network.
(Typing) Now we see that the adjacency, or the neighborship,
has come up between R1 and R2, we see that on R2 here and R1.
Now what I want to show here is if we move over here,
I have a packet capture running in the background.
Then we'll move over here, and if I just stop this for a minute,
we'll see that right in here somewhere,
you will see here on R1 is when we configured EIGRP,
and it starts to send out hello packets using a
multicast address at 224.0 .0 .10 address.
Let's see, it's EIGRP, we see it's a hello packet.
The only thing that's in here is the software version,
but more importantly here are the K values,
and we'll talk about that more in the next section here.
Now if we go up to this conversation, you'll see R1 keeps trying,
and then at this point we configured R2 to enable EIGRP.
And at that point, they see each other and R1 requests an update,
which is saying, oh, okay, we're connected,
I see you, you see me.
Could you send me your information?
The specific packet types and how they communicate will be
covered much more thoroughly in the next module.
In this case,
we're just doing a simple walkthrough of how the neighborship
forms using both unicast and multicast.
In this case, you will see that he sends out an update.
R2 is still sending hellos out.
Here's R2 with the same message back.
So this is R1 saying, please give me your information.
This is R2 saying the same information.
This is an End-of-Table, so I've sent you all the information in this message,
and here's all the information I know.
In this case, the only information I know is the link between them.
They are not connected to any other networks.
This is R2 doing the same.
He doesn't have any other information.
So basically, they're saying I don't know anything,
but we can communicate together so we can still form a neighborship.
They both ack each other.
And an acknowledgement in EIGRP is essentially a hello packet,
but with no data on it.
And then at that point, they've completely converged on each other.
They know about all of each other's networks.
And at that point, they would just go back to a simple hello,
hello, hello back and forth.
And they will remain doing this every 5 seconds until there is a problem,
there is an interface problem, there is a network change,
a different network comes up.
Any of those different things would show here,
and they would immediately update each other with that information.
Now we're back.
I've restarted this capture.
So this is just showing the communications back and forth with the hellos.
And at this point,
what I'm going to do is I'm going to enable R2 to have access to the rest of
the topology that we had covered in the previous module,
so it connects to the rest of the network.
There are a total of six different nodes.
In this case, all of them are configured with the EIGRP,
so all of them are familiar with all of the destinations
that each one of them is connected to.
If I configure on R2 to enable EIGRP on all of the interfaces,
as soon as I enable these interfaces, if you watch this capture,
you'll see R2 does a whole bunch of updating to R1 to say,
oh, I've got some additional information here.
We're going to see a whole bunch of updates come in here.
There's an update, update, and then R1 each time acknowledges coming back saying,
okay, I've got that information, I've got that information.
Now here's the final one.
Let's look and see what R2 is advertising.
This is the final update after I brought up all the other devices.
You see now R2 is saying to R1,
I now have access and these are all the routes that I'm being told
about and that I can put into my routing table.
If you remember from the last module,
it would not re-advertise any routes that were not
feasible from R2's perspective.
So this is all the routing information that I know about
if I just focus in on one of these.
Let's look at that 10 network that we were talking about in the last one.
This is saying, I can reach this 100.100 .100 .0 /24 network.
And if you remember from the last module, this is one that's located off of R6.
It's an internal route.
This is the RouterID of the originating router, so this is the RouterID of R6.
And NextHop is 0.0 .0 .0, so which means I can get to this, so send it to me.
So this is just sort of a quick look at how this
information is exchanged between the two.
As I noted earlier,
more specifics as to what each one of the fields is
actually doing will be covered in a minute.
Now the next thing I'm going to show you here is EIGRP actually
supports not only dynamic neighborship establishment,
but it also supports static neighborship establishment.
And this is used whenever a specific link or a
device does not support multicast.
Typically,
this comes up with certain linked topologies that don't support multicast.
And if you need to have EIGRP running between the two,
you need to alter the way that you configure EIGRP.
We move on to R1 here and take a look at our EIGRP configuration.
Currently, we have it configured for only one network.
So the first thing we need to do is we would need to put a
neighborship statement in here that would be for the network
that goes between R1 and R3,
which is the one we were going to use for static configuration.
And that interface uses the 10.10 .10 .4 /30 network.
And in addition to this, we need to put in another statement here that would say,
this is the IP address of the remote neighbor that I
want to establish a neighborship with,
and this is the interface that I connect to them with.
Whenever you do this,
the EIGRP will stop sending multicast traffic out that specific
interface and only send traffic out using unicast with the
destination of the address that you just configured.
We jump over to R3.
R3 is already configured to enable EIGRP on all of its interfaces,
but as you can see here,
it doesn't have a neighborship establishment with R1 yet,
which is on its g0/1 interface.
On its g 0/1 interface,
you can see that it's configured with the 10.10 .10 .6 IP address that
we had configured previously on R1 as its neighbor.
So all we need to do on this device is use this neighbor
command that we did on the last one.
We use R1's address here, and R3 is connected to R1 via its g0/1 interface.
And when we do this, we should see the neighborship establish.
There we are.
Now see that on R3's g0/1 interface,
it is configured with the neighborship from R3 to R1.
Now if we look more specifically at that neighbor,
you'll see that it specifically notes this is a static neighbor.
Now just like with the dynamic one, let's take a look and move over to a capture.
And on this capture, we can see this is on the link between R1 and R3.
And if I move up here a little bit, it will show,
this is around the time,
right here is around the time that R1 and R3 were
configured to support static neighborships.
And we'll see there are no packets here using a multicast address.
They are specifically unicast packets that are going only to the
other device that was configured in that command.
And as we see, here's a Hello.
Right here's the Hellos, and there's an update from R1 to R3.
Here is Hello, oh, there's an R3 from R3 to R6 saying, send me your stuff.
Yes, okay, so this is R1 sending R3, see here, all of this information.
This is R1 telling R3 that I have routing information
to all of these different networks,
and here's the configuration parameters for them.
You go in here, it'll tell you what their metric information was: Priority,
Bandwidth,
really the only things as we know in the last module that
are used are the Bandwidth and the Delay,
but here's how to get to all of these.
Now remember that for this neighborship to form in the first place,
there are a couple different things that need to match between the devices.
And while we're looking at a capture, let's just take a look at that real quick.
Whenever we're starting our initial hellos,
one of the things that we're sending is the K values.
And remember from our earlier slide that these K values must
match between the different neighbors that are trying to form
an adjacency with one another.
And if you remember from the last module,
K1 and K3, by default, are set to 1, and all the other K values are set to 0.
These must match for an adjacency to form between two devices.
So if we wanted to just illustrate that one real quick,
we can go back, let's see, let's move back to R1,
and let's go and change.
So this is how you would change the K values on a Cisco device.
K1 value, K2 value, K3 value, and so on.
What if I just put a 1 here for K4?
As soon as we do that between R1 and R3,
and then between R1 and R2, you will see that all of the neighborships drop.
So from R1's perspective,
it had a neighborship between itself and R1 and itself and R3.
And you'll see on a Cisco device specifically,
and I'm guessing on a lot of other here,
it will give you a really obvious message on the console that says,
I don't match.
And if we jump over to the capture real quick,
you will see that right now you'll see R1 and R3
sending out hellos towards each other.
But they aren't going any further than this because their K values don't match.
This is R1 sending out and saying this is my K1, and here's this extra 1 on K4.
Whereas in R2, let's see here,
it is still advertising the default values of 1 and 1.
Let's move back to R1 real quick.
And let's just take that off.
The values will revert, and the neighborships will come back up.
The same is true if neighbors are configured on different autonomous systems.
In this case, I just used autonomous system 10, eigrp 10.
These must match, same result,
as well as if you had configured any authentication,
neighborship authentication, that information must match,
and we'll show that in the next module.
As well as if you are running IPv4 with the EIGRP,
both neighbors must be on the same IPv4 subnet for them to
be able to communicate with one another.
Now that is sort of basic IPv4 knowledge,
but the confusing thing to some people is that if you are running IPv6,
or the IPv6 version of EIGRP, which is the same version,
it just carries the IPv6 traffic, in that case,
EIGRP uses link local addresses for neighborship communications.
And in that case,
it does not use the configured address that you have on
there that may be a global IPv6 address.
It only uses the link locals.
So in that case, it doesn't matter if they're on the same subnet.
It will still form an adjacency, so that requirement is only with IPv4 networks.
So now with this covered and this lab sort of reviewed, let's move on and talk about EIGRP timers.