So let's get into our final demo section and talk about
authentication and how it's configured.
Now the highlight here is not going to be specifically how
it's configured because we're trying to make this course as
vendor neutral as possible,
but it's important to look at the different messages and how the
configuration of authentication changes how information is exchanged
between devices or whether it does at all.
So let's look at the topology again.
What we're going to do in this case is we're just going to
configure authentication between R1 and R2.
Whenever you configure authentication for EIGRP,
it is an interface specific thing.
You can use the same keys on several different interfaces,
but it is interface specific in that you can put a
different key on each interface if you wish.
So let's move from the typology here and get into the lab.
Now all we're going to do here is configure.
And Cisco is done with the keychain and other devices and other
vendor's equipment may be done differently.
Alright, we have left the debug on so we can see how it works here.
In this case, we enabled authentication only on R1,
and that caused the adjacency between R1 and R2 to go down,
so the authentication, let's see,
this message shows the authentication mode changed,
and all the rest of this is the EIGRP process doing housekeeping and
basically rerouting everything through its other neighbor.
In this case, R1 still has a neighborship through R3,
so everything's just going to be moved over to that interface until we
configure R3 with authentication and bring the link back up.
I'm sorry, R2, with authentication and bring that link up.
Now we see,
as soon as we configured R2 with authentication on that link between R1 and R2,
that adjacency immediately came back up.
Now if we run back to R1,
we'll see that EIGRP on that device is doing its
housekeeping again because that link came back up.
Now all of a sudden, all of its previous routes through R2 will be repopulated.
Now keep in mind, as I noted,
this is just configuring authentication between R1 and R2.
It doesn't do anything for any of the other links in the network.
So between R2 and R3, and R2 and R4, and R5,
and so on, every other link, it's not configured authentication.
So as you generally have probably guessed,
this is something that if you're going to configure,
and it is a good idea to configure something like this if you're not
encrypting your links with some other technology,
is to do this on every single link.
There are different modes of thought on this as to what type of
passwords and how to change them and all that stuff,
but at this point, just understand that anything is better than nothing,
and you never really want to have a source on your network that can change how
your whole network routes traffic to a specific destination.
If you don't have authentication on here,
I can stick the cheapest router I can buy that
supports EIGRP on any given network.
And say I can reach networks X, Y, and Z,
and if you're not authenticating,
all the devices are going to assume that you are correct,
and it will reroute all those destinations out however you tell it to go.
And, of course, if you did that on any size network,
that's going to cause massive reachability problems.
So it's not something that you want to leave open.
And yes,
I have been on networks that publicly broadcast and allow
people to form neighborships with them on links that go out to
customers from service providers.
So, it does happen.
So, keep a keen eye on this one if you're ever coming into a network.
And the next thing we're going to take a look at is
how does this change the capture?
So we run over to the capture between R1 and R2.
Previously, this was what like a normal packet would look like.
We had your normal hello packet with parameters and software version TLVs.
And if we run down here a couple, we'll see when authentication was configured.
There it is.
Now at this point, we configured authentication onto R2,
or sorry, we configured authentication onto R1,
but not R2.
And notice that there is an additional TLV that's
included with the hello message.
That's the authentication TLV that we had discussed earlier.
Specifically in this case, we are using the MD5 mechanism.
We had the EIGRP.
RFC has support for MD5 and SHA-256.
Specific support will depend on the platform,
but it enables authentication and this digest here is the
MD5 hash of the password I gave you.
In this case, the password was password.
It's not like it's an overly confusing password.
But MD5 creates a hash out of whatever string you give it,
and then this string needs to match on both sides in order for
it to allow communication between the two.
Now MD5 in and of itself isn't the most secure mechanism,
so that's something that you need to either learn about,
which hash mechanisms are the most secure,
or talk to your network security guru guy consultant or senior
person to find out what the best option is.
If I can look at the messages that come back from R2,
at this point, they didn't include that.
Then we can see this is why the neighborship came down.
They can see back and forth, back and forth, back and forth, back and forth.
Now eventually, down here a couple packets as I jump to it here,
we finally got R2 configured with authentication.
And at that point, they can start updating each other again.
Now this is an update packet.
Notice that before authentication was configured,
obviously this TLV wouldn't be here, but everything else would be almost exactly,
well, actually everything else would be exactly the same.
But it adds this little authentication TLV to the end.
And this hangs around on every packet.
So, this is the update coming back from R2 to R1.
These are the update packets where we get the End of Table flags,
and this is R1 telling R2 about all of the networks it can reach,
including that external network that we picked up on the previous demo.
Remember what I said.
The acknowledgement, sorry,
the authentication TLV is included on all packet
types except an acknowledgement.
In this case, this is an acknowledgement from R1 to R2,
so that's 102, so it's for that packet right there,
but it doesn't include that authentication TLV.
But the update from R2 to R1 with its End of Table and all its
routes all includes that authentication hash and TLV.
Always use something like this on a production network,
unless there are some other controls that you're using.
Whether you're encrypting the traffic that goes over the links or
there's some other mechanism that's used for security.
So with that, that ends our fourth demo in this module and the module itself. In the next module, we're going to move on to EIGRP advanced topics.