|
0:00:14
|
In our next section here, we're gonna talk
|
|
0:00:19
|
And some of the additional features that it adds
|
|
0:00:22
|
when we're running it over
|
|
0:00:26
|
like Ethernet or Frame-Relay or
|
|
0:00:30
|
as opposed to what the underlying
|
|
0:00:36
|
Now, the key advantage of running PPP is that
|
|
0:00:43
|
and it's a very light weight encapsulation as well.
|
|
0:00:46
|
So, for Ethernet, for example, Ethernet doesn't
|
|
0:00:53
|
or multi-link of different interfaces together outside
|
|
0:01:00
|
But with PPP, we technically could take an Ethernet interface
|
|
0:01:07
|
and Multi-link, all of them together by using
|
|
0:01:15
|
that ride between your physical framing
|
|
0:01:23
|
So, this is not gonne be as large of a topic domain
|
|
0:01:29
|
Especially since the legacy dial technologies like Analog
|
|
0:01:38
|
During those revisions, PPP was highly tested with
|
|
0:01:44
|
It's not gonna be as big of a scope nowadays.
|
|
0:01:51
|
So, the basics about how PPP works,
|
|
0:01:56
|
the protocol is gonna go through what's known
|
|
0:02:03
|
to negotiate basic options like the authentication,
|
|
0:02:09
|
And then what are the upper layer protocols
|
|
0:02:15
|
The upper layer negotiations then have
|
|
0:02:20
|
like the IPCP for IPv4 control protocol,
|
|
0:02:29
|
and on, and on, and on.
|
|
0:02:31
|
Each of this sub-control protocols have
|
|
0:02:37
|
that we can use for things like address
|
|
0:02:42
|
We can also use this for
|
|
0:02:46
|
when potentially the two end points of the
|
|
0:02:52
|
This comes from a legacy analog dial scenario where
|
|
0:03:00
|
but being assigned addresses
|
|
0:03:03
|
that is not part of the access server itself.
|
|
0:03:09
|
So for example, the situation would be that if
|
|
0:03:19
|
that are talking to the dial and access server,
|
|
0:03:25
|
But maybe, one of these clients is dialing into
|
|
0:03:33
|
But from the vocal point of presence,
|
|
0:03:35
|
it's the same access server that is
|
|
0:03:39
|
Both AOL and AT&T is dialled polls.
|
|
0:03:42
|
In this case, what would typically
|
|
0:03:47
|
they're gonna get some address that
|
|
0:03:53
|
Then likewise, when AT&T comes in, they're
|
|
0:04:01
|
So, we end up in this case
|
|
0:04:06
|
between the access server and the client,
|
|
0:04:09
|
these devices end up being not in the same subnet.
|
|
0:04:13
|
Or maybe the access server
|
|
0:04:17
|
the AOL client has 20.0.0.1 and
|
|
0:04:25
|
So, we'll see one of the features
|
|
0:04:30
|
is that once the PPP session is established,
|
|
0:04:33
|
the neighbors exchange what addresess that
|
|
0:04:39
|
The access server would then sasy, "I know
|
|
0:04:49
|
and the address 30.0.01/32. And I know what
|
|
0:04:59
|
This feature was also known as
|
|
0:05:04
|
And there are some interesting routing designs
|
|
0:05:09
|
as opposed to other encapsulations
|
|
0:05:16
|
So, some of these, we'll come back and talk
|
|
0:05:20
|
But, we'll take a look at some basic details of PPP here
|
|
0:05:37
|
Now, during this process, when we are negotiating
|
|
0:05:44
|
we can see the details behind what's going on
|
|
0:05:47
|
by looking at the debug PPP negotiation.
|
|
0:05:50
|
This would tell us if there's any problems
|
|
0:05:53
|
in the authentication mechanism
|
|
0:05:56
|
The MTU that the different devices support
|
|
0:06:03
|
that's gonna show us all the details behind that.
|
|
0:06:06
|
So, first, let's look at a very basic configuration
|
|
0:06:11
|
where we have router 1 and router 3
|
|
0:06:22
|
In this case, from router 1, this is serial 0/1.
|
|
0:06:25
|
On router 3, this is serial 1/2.
|
|
0:06:30
|
Normally, the default encapsulation
|
|
0:06:35
|
We're simply gonna say, "Encapsulation PPP"
|
|
0:06:38
|
It's gonna change it to
|
|
0:06:45
|
So, our first step on router 1, let's look at
|
|
0:06:52
|
to start, we have just the default configuration.
|
|
0:06:56
|
So, on router 1, we'll say that
|
|
0:07:04
|
And that we are running PPP.
|
|
0:07:09
|
Encapsulation PPP.
|
|
0:07:15
|
On router 3,
|
|
0:07:23
|
I need the clocking for the link,
|
|
0:07:28
|
I'll have the IP address 13.0.0.3 and then
|
|
0:07:41
|
Ideally, at this point, the line
|
|
0:07:45
|
Which would indicate that the
|
|
0:07:50
|
If I try to send packets to router 1,
|
|
0:07:55
|
we see the connectivity over the interface is fine.
|
|
0:08:00
|
Now, if we were to look at the
|
|
0:08:05
|
We see that PPP by default will learn the
|
|
0:08:12
|
And put an exact match host route into the
|
|
0:08:21
|
So, this would allow router 1 and
|
|
0:08:26
|
but then have exact match to each other
|
|
0:08:33
|
So, it's basically an automatic hack that
|
|
0:08:39
|
If we look at the debug PPP negotiation,
|
|
0:08:53
|
we should see the individual process that the neighbor
|
|
0:08:59
|
And you'll see the debug
|
|
0:09:03
|
So, if you were to do this in the exam,
|
|
0:09:05
|
you would be better up sending this to the
|
|
0:09:11
|
So, if you're doing, let's say PPP over
|
|
0:09:15
|
and you have an error in your configuration.
|
|
0:09:18
|
When you issue the debug,
|
|
0:09:20
|
you may see that the negotiation happens
|
|
0:09:24
|
and overruns the console buffer then you
|
|
0:09:30
|
So, ideally, what you would wanna do
|
|
0:09:35
|
So, we're not sending debug
|
|
0:09:39
|
but instead we're logging
|
|
0:09:44
|
And we may also wanna increase the buffer size
|
|
0:09:49
|
so that we don't have to age
|
|
0:09:52
|
So, just give it some high value here.
|
|
0:10:00
|
Next, I'll clear the log.
|
|
0:10:03
|
Debug PPP Negotiation.
|
|
0:10:07
|
Then, shut the link down
|
|
0:10:15
|
Now, since I'm logging at
|
|
0:10:19
|
it means that I'm still gonna get
|
|
0:10:23
|
Like the link up-down, the protocol up-down,
|
|
0:10:26
|
I may wanna see those regular
|
|
0:10:31
|
but just not the debug messages to the console.
|
|
0:10:36
|
Now, if I want to see the debugs,
|
|
0:10:42
|
And we should see...
|
|
0:10:45
|
the negotiation between them.
|
|
0:10:49
|
So first, we see that the link comes up.
|
|
0:10:53
|
PPP says that this is a dedicated line.
|
|
0:10:56
|
So, this means that there is no call direction.
|
|
0:10:59
|
It either count it as an inbound call or an
|
|
0:11:06
|
For analogue dial or ISDN dial,
|
|
0:11:09
|
it would matter who initiates the session,
|
|
0:11:12
|
because we can do different types of authentication
|
|
0:11:17
|
or the call is going outbound.
|
|
0:11:18
|
We could do things like caller ID to accept
|
|
0:11:24
|
or where the session is going to,
|
|
0:11:26
|
but of course, that stuff is no longer gonna be
|
|
0:11:31
|
So, from our point of view with PPP,
|
|
0:11:35
|
Direction is always gonna be a dedicated line.
|
|
0:11:40
|
Okay, next, it says we go to the open...
|
|
0:11:43
|
state of PPP, and we start out
|
|
0:11:48
|
In here, the first thing we'll see...
|
|
0:11:52
|
is that the routers negotiate a sequence number
|
|
0:11:59
|
Router 3 is sending an outbound
|
|
0:12:04
|
saying to router 1, "I wanna use
|
|
0:12:09
|
Router 1 then replies with an inbound
|
|
0:12:14
|
saying, "Go ahead. You can
|
|
0:12:17
|
Then likewise, router 1 says...
|
|
0:12:20
|
that "I wanna use...
|
|
0:12:23
|
this sequence number."
|
|
0:12:26
|
Router 3 is replying outbound configuration acknowledgement
|
|
0:12:32
|
This would also be where we see...
|
|
0:12:34
|
any of the authentication
|
|
0:12:39
|
So, if one router wants to use PAP authentication,
|
|
0:12:43
|
but a different one wants to use CHAP,
|
|
0:12:45
|
we would see that they would not proceed...
|
|
0:12:49
|
on to the next phase, which
|
|
0:12:53
|
whatever upper layer protocols that we are
|
|
0:13:01
|
But at this stage, it says that everything is fine.
|
|
0:13:09
|
after link control protocol,
|
|
0:13:12
|
now we go to the upper layer protocols.
|
|
0:13:14
|
Router 3 says, "I'm running IP."
|
|
0:13:18
|
So, I'm gonna send an outbound
|
|
0:13:22
|
This is the address I have assigned."
|
|
0:13:26
|
Router 1 likewise does the same thing.
|
|
0:13:31
|
This is my address."
|
|
0:13:33
|
Router 3 is acknowledging 1.
|
|
0:13:36
|
1 is acknowledging...
|
|
0:13:40
|
3 as well, the inbound configuration
|
|
0:13:49
|
We see they have successfully negotiated IPv4.
|
|
0:13:53
|
Router 3 says, "I'm gonna install
|
|
0:13:58
|
So at this point, PPP negotiation is done.
|
|
0:14:01
|
The line protocol of the interface comes up.
|
|
0:14:05
|
If we were doing any advanced configuration
|
|
0:14:10
|
or authentication, or multilink,
|
|
0:14:12
|
we would see all of those negotiated here
|
|
0:14:15
|
in the single Debug PPP Negotiation Output,
|
|
0:14:18
|
and that could be potentially use for troubleshooting
|
|
0:14:27
|
So next, let's look at a case where router 1
|
|
0:14:34
|
So on router 3, I'm gonna
|
|
0:14:39
|
And I'll clear out the log buffer, so it's gonna
|
|
0:14:45
|
And then, it'll be replaced by the new one
|
|
0:14:50
|
Now, on the serial interface,
|
|
0:14:55
|
Instead what I'll do is configure a loopback
|
|
0:14:58
|
that has the address 3.3.3.3/32
|
|
0:15:05
|
Now, the subnet mask of this could be
|
|
0:15:09
|
In this case,I'm just doing it as a host route.
|
|
0:15:13
|
At the PPP interface, I'm now going to
|
|
0:15:20
|
So, the idea behind this is that if I have a
|
|
0:15:26
|
I don't have to give them separate addresses.
|
|
0:15:28
|
I could unnumber them to just a /32,
|
|
0:15:32
|
then, the PPP host route is gonna tell us where I
|
|
0:15:41
|
Then, on router 1, we'll do the same thing.
|
|
0:15:44
|
So, on loopback 0,
|
|
0:15:48
|
we'll say the address is 1.1.1.1.
|
|
0:15:52
|
Then, on serial 0/0, we have IP
|
|
0:16:01
|
I'll also add router 2 to the connection here.
|
|
0:16:06
|
Which would then be on...
|
|
0:16:08
|
router 3 serial 1/3.
|
|
0:16:12
|
Which is router 2's serial 0/1.
|
|
0:16:21
|
On router 2, we'll do the same type of
|
|
0:16:25
|
That is 2.2.2.2.
|
|
0:16:30
|
On the serial link, we're going to
|
|
0:16:34
|
And we're running PPP.
|
|
0:16:42
|
Then, router 3's...
|
|
0:16:45
|
serial 1/3 configuration...
|
|
0:16:49
|
is essentially gonna be the same as the...
|
|
0:16:54
|
serial 1/2.
|
|
0:17:04
|
So now, on router 1, if we
|
|
0:17:08
|
router 1's link is up.
|
|
0:17:12
|
Or actually, it's not up, but it's not shutdown.
|
|
0:17:15
|
So, it's down-down because router 3 is shutdown.
|
|
0:17:18
|
Router 2 should see the same thing,
|
|
0:17:24
|
okay, the link is at least connected physically.
|
|
0:17:29
|
So now, on router 3, let's look at the new debug.
|
|
0:17:35
|
So now, I will see the debug output.
|
|
0:17:39
|
Then, on these two links, we'll say, No Shutdown.
|
|
0:17:55
|
We have the negotiation to router 1 complete.
|
|
0:18:01
|
And we should...
|
|
0:18:05
|
I didn't take that config. I must have
|
|
0:18:11
|
Okay, so in that interface as well,
|
|
0:18:13
|
Encap...
|
|
0:18:17
|
PPP. Actually, I'll put the IP address
|
|
0:18:21
|
Then, Encapsulation PPP.
|
|
0:18:24
|
And the clock rate.
|
|
0:18:37
|
Now, if we look at the negotiation
|
|
0:18:41
|
it's basically the same that we had before...
|
|
0:18:44
|
with the difference being that router 3 says,
|
|
0:18:49
|
Router 1 says, "My address is 1.1.1.1."
|
|
0:18:54
|
Once IPCP negotiation is complete,
|
|
0:18:57
|
router 3 says, "I will then
|
|
0:19:02
|
And router 1 likewise should be
|
|
0:19:06
|
So, if we look at the routing table on router 3,
|
|
0:19:12
|
we have the two serial interfaces...
|
|
0:19:16
|
where it says, "Router 1 is connected on serial 1/2.
|
|
0:19:22
|
And router 2 is connected on serial 1/3."
|
|
0:19:26
|
Notice that the serial interfaces
|
|
0:19:29
|
It's coming from the loopback
|
|
0:19:33
|
But since I have the exact
|
|
0:19:37
|
I should still be able to send
|
|
0:19:46
|
If we look at the Layer 3 debug
|
|
0:19:51
|
and I'll do a ping to... Let's say
|
|
0:19:58
|
notice that 3 is generating the frame...
|
|
0:20:01
|
from the loopback where the unnumbering is coming from.
|
|
0:20:05
|
Then, it's going out serial 1/3 to 2.2.2.2.
|
|
0:20:14
|
So, the idea behind this configuration...
|
|
0:20:17
|
is that with PPP, the devices do not
|
|
0:20:22
|
because with the IPCP negotiation,
|
|
0:20:25
|
we will automatically install the /32
|
|
0:20:31
|
Now, you can disable that feature, we could go to
|
|
0:20:39
|
Where's it? No... No Peer Neighbor Route.
|
|
0:20:47
|
Then, if we were to shut this link down,
|
|
0:20:55
|
and bring it back up,
|
|
0:20:59
|
once the link is active and the line protocol is up,
|
|
0:21:02
|
the result is that we would not
|
|
0:21:06
|
Because now, router 3 says...
|
|
0:21:09
|
"I don't know what interfaces the
|
|
0:21:14
|
We could see this from the own routable
|
|
0:21:20
|
We could fix then in ourselves by
|
|
0:21:25
|
I could say, "To reach router 1
|
|
0:21:33
|
So, this will work, but there's really no
|
|
0:21:37
|
So, what I'm doing here with the...
|
|
0:21:39
|
with the static route is essentially what PPP was doing
|
|
0:21:53
|
So, to get to this destination,
|
|
0:21:58
|
I wouldn't be able to put a next hop value here
|
|
0:22:02
|
It has an unnumbered address.
|
|
0:22:05
|
Then, the No Peer Neighbor Route, this is what's
|
|
0:22:13
|
So, it's kind of a stupid router trick. It works, but there's
|
|
0:22:19
|
Okay, that you would remove the Peer Neighbor Route,
|
|
0:22:42
|
Next, let's look at the authentication.
|
|
0:22:45
|
We'll take a look at the variations of clear text
|
|
0:22:51
|
And the MD-5 version which is Challenge
|
|
0:22:57
|
There are a lot of other minor variations
|
|
0:23:02
|
or the Extensible Authentication
|
|
0:23:06
|
but the vast majority of them
|
|
0:23:09
|
So, the most common ones are PAP and CHAP.
|
|
0:23:12
|
You do it the other options though.
|
|
0:23:13
|
If you look at the command reference, you could
|
|
0:23:21
|
Now, with the PAP authentication,
|
|
0:23:24
|
both the username and password
|
|
0:23:29
|
which means that whatever
|
|
0:23:32
|
can be completely independent on
|
|
0:23:37
|
Now, the authentication is always
|
|
0:23:42
|
It's the authentication request,
|
|
0:23:45
|
the authentication response, and then, either
|
|
0:23:52
|
Where this can get confusing
|
|
0:23:55
|
is that the vast majority of examples show
|
|
0:24:01
|
configured in both directions.
|
|
0:24:04
|
So, if we were to look at the topology we
|
|
0:24:12
|
if router 1 wants to authenticate 3 with PAP,
|
|
0:24:18
|
the first thing router 1 says is PPP...
|
|
0:24:22
|
Authentication PAP.
|
|
0:24:27
|
This tells router 1 to send the request.
|
|
0:24:32
|
Router 3 will then send the response
|
|
0:24:39
|
by using PPP...
|
|
0:24:42
|
PAP.
|
|
0:24:44
|
Sent username,
|
|
0:24:47
|
and password.
|
|
0:24:49
|
So, this is just whatever the login
|
|
0:24:53
|
Now, once router 1 gets the response, it needs
|
|
0:24:58
|
It could be the local database,
|
|
0:25:02
|
like Radius or Tacacs or Window's Active Directory.
|
|
0:25:07
|
Within the scope of routing and switching,
|
|
0:25:10
|
I would assume we're not gonna need
|
|
0:25:13
|
So, we will cover it in a little bit when
|
|
0:25:20
|
but we're not gonna deal a lot with the
|
|
0:25:24
|
So, for this example, we'll use just
|
|
0:25:29
|
So, router 1 would then also have globally...
|
|
0:25:32
|
a username and password command
|
|
0:25:36
|
that matches whatever router 3
|
|
0:25:41
|
If the username and password matches,
|
|
0:25:47
|
with basically the acknowledgment saying,
|
|
0:25:50
|
we can then proceed on to the
|
|
0:25:57
|
Now, where this gets confusing
|
|
0:26:00
|
both of the routers are saying either PPP
|
|
0:26:07
|
which means that this one way process
|
|
0:26:15
|
So, the PPP Authentication
|
|
0:26:17
|
is independent of the PPP Authentication
|
|
0:26:22
|
You don't necessarily need to do it on both sides.
|
|
0:26:26
|
Likewise, we could do some
|
|
0:26:29
|
where router 1 is authenticating 3 with PAP,
|
|
0:26:32
|
while 3 is authenticating 1 with CHAP,
|
|
0:26:37
|
There's no limit to the variations that you can use.
|
|
0:26:43
|
As long as this is successful in
|
|
0:26:48
|
thats really the key that we are looking for.
|
|
0:26:55
|
So again, with the PAP Authentication,
|
|
0:26:58
|
first is we have the authentication request.
|
|
0:27:03
|
By default, the router will have the No PPP PAP Refuse
|
|
0:27:13
|
So, these are default options. You're
|
|
0:27:16
|
It basically just means that if someone
|
|
0:27:23
|
The response then, we need to
|
|
0:27:27
|
which is the PPP PAP sent username password.
|
|
0:27:31
|
Then, lastly, the other side is gonna have some sort of
|
|
0:27:43
|
So next, let's look at...
|
|
0:27:46
|
router 1.
|
|
0:27:49
|
And we'll configure router 1 with the...
|
|
0:27:55
|
PPP Authentication PAP.
|
|
0:28:01
|
If we look at router 3,
|
|
0:28:05
|
and for simplicity, I'm gonna take this
|
|
0:28:09
|
So, the static route, I'll remove.
|
|
0:28:13
|
And then, I'll put the Peer Neighbor Route back.
|
|
0:28:20
|
We'll shut down the interface and we'll gonna
|
|
0:28:25
|
So, Do Debug PPP Negotiation.
|
|
0:28:30
|
And I'm gonna log to the buffer level 7.
|
|
0:28:35
|
Log to the console at level 6.
|
|
0:28:37
|
Because at this point, I know I only have
|
|
0:28:42
|
So, when they fail the authentication, they gonna keep
|
|
0:28:50
|
If you look at the result to
|
|
0:28:57
|
we'll see over and over and over,
|
|
0:29:00
|
there is an inbound configuration request...
|
|
0:29:05
|
where router 1 is saying, "This is my sequence
|
|
0:29:10
|
And I want to authenticate you with PAP.
|
|
0:29:14
|
Router 3 at this point does not
|
|
0:29:18
|
so it responses with an outbound
|
|
0:29:23
|
saying, "I will not be authenticated with PAP."
|
|
0:29:27
|
The problem is if we look at this log, it's gonna
|
|
0:29:34
|
So, if I were logging this to the console,
|
|
0:29:36
|
it could quickly overrun the buffer and then I
|
|
0:29:47
|
So next, let's go to the link and shut it down,
|
|
0:29:49
|
and we'll completely authentication response.
|
|
0:29:53
|
So, router 3 is gonna say, "My PPP PAP...
|
|
0:29:57
|
sent username...
|
|
0:30:01
|
is..
|
|
0:30:03
|
anything "BOB" password CISCO.
|
|
0:30:10
|
Router 1 is then gonna need to validate this.
|
|
0:30:13
|
By default, Triple A will be off, which means
|
|
0:30:19
|
So, router 1 now needs to know about
|
|
0:30:29
|
On 3, if we clear the log, and then, bring the interface up,
|
|
0:30:38
|
we should see that the full authentication
|
|
0:30:42
|
So, if we look at the log output,
|
|
0:30:48
|
router 1 said...
|
|
0:30:50
|
"I wanna authenticate you with PAP."
|
|
0:30:54
|
Router 3 is acknowledging this saying,
|
|
0:30:59
|
Now, we go to the actual authentication phase.
|
|
0:31:07
|
Router 3 is saying, "My username is Bob."
|
|
0:31:10
|
And it doesn't show the password here,
|
|
0:31:15
|
you would see in clear text
|
|
0:31:19
|
Then, we have the inbound
|
|
0:31:22
|
This is router 1 saying, "Your username
|
|
0:31:26
|
So, if I saw an inbound Authentication...
|
|
0:31:34
|
Not Acknowledgment, which is a NACK,
|
|
0:31:38
|
then, this would mean that the authentication failed.
|
|
0:31:43
|
But if authentication fails, you cannot go to
|
|
0:31:48
|
So, you would never see the IPCP, the CDCP,
|
|
0:31:51
|
or whatever other Layer 3 and above
|
|
0:32:03
|
There's a question here, "What does the PPP
|
|
0:32:09
|
The key with that is that it's
|
|
0:32:13
|
In this case, since this is a dedicated line,
|
|
0:32:18
|
there is no call direction.
|
|
0:32:20
|
It's treated as a dedicated line.
|
|
0:32:22
|
If this were actually an analogue
|
|
0:32:27
|
whoever initiated the call from their perspective,
|
|
0:32:35
|
and the person receiving the
|
|
0:32:40
|
So, we can configure authentication to say,
|
|
0:32:46
|
but I'm not gonna authenticate if I call them."
|
|
0:32:51
|
In our particular case, it's not gonna matter though,
|
|
0:32:55
|
It's only when you're doing an actual dial
|
|
0:33:06
|
So, let's look at our full configuration now.
|
|
0:33:10
|
On router 3,
|
|
0:33:12
|
notice that we did not have the
|
|
0:33:16
|
Because router 3 is not the one
|
|
0:33:19
|
It's just the one who is doing the response.
|
|
0:33:24
|
On router 1,
|
|
0:33:28
|
router 1 is doing the initiation with
|
|
0:33:33
|
When the response comes back in,
|
|
0:33:37
|
router 1 is checking the local database.
|
|
0:33:40
|
It found username Bob password CISCO.
|
|
0:33:47
|
Now, I could go to router 3 and say,
|
|
0:33:52
|
which would then mean on router 1,
|
|
0:33:55
|
I need the PPP PAP sent username,
|
|
0:33:58
|
and then on router 3, I would need
|
|
0:34:03
|
So, you can do it in both directions.
|
|
0:34:06
|
but technically, you don't have to.
|
|
0:34:08
|
So,it's an unrelated one way process.
|
|
0:34:13
|
the other router sending the response,
|
|
0:34:15
|
and then the originating router either saying,
|
|
0:34:29
|
Now, for the PAP configuration,
|
|
0:34:34
|
because we're clearly defining what the
|
|
0:34:39
|
but with the CHAP Authentication,
|
|
0:34:43
|
because we're not actually sending
|
|
0:34:47
|
and there's a bunch of different
|
|
0:34:51
|
with either using the global username,
|
|
0:34:56
|
the global password, or the interface password.
|
|
0:35:00
|
And we'll see, not all of these
|
|
0:35:03
|
It depends on who is originating the challenge.
|
|
0:35:08
|
If I am originating the challenge,
|
|
0:35:11
|
there's certain configurations that will work
|
|
0:35:22
|
In either case, just like PAP,
|
|
0:35:25
|
to initiate the authentication request,
|
|
0:35:30
|
So, let's now do this in the other direction.
|
|
0:35:36
|
On router 1, we'll Debug PPP Negotiation.
|
|
0:35:42
|
And we could also say, Debug PPP Authentication.
|
|
0:35:46
|
This will tell us a little bit more about the process,
|
|
0:35:49
|
but the vast majority of stuff we can see
|
|
0:35:56
|
So next, I'll log to the buffer at level 7
|
|
0:36:02
|
So again, I don't wanna
|
|
0:36:11
|
On router 3, we already are debugging.
|
|
0:36:14
|
So right now, I'll shutdown the interface.
|
|
0:36:17
|
And clear out the old log information.
|
|
0:36:21
|
Now, router 3 is going to initiate the challenge.
|
|
0:36:25
|
We'll say PPP Authentication...
|
|
0:36:27
|
is CHAP.
|
|
0:36:32
|
When the interface comes back up,
|
|
0:36:34
|
we know that this is not gonna be successful, because
|
|
0:36:40
|
So, router 3 is asking 1 to authenticate.
|
|
0:36:48
|
So, router 3 is saying...
|
|
0:36:51
|
that...
|
|
0:37:05
|
3 is saying, "I wanna authenticate you with CHAP."
|
|
0:37:09
|
Router 1 says, "Okay, that's fine.
|
|
0:37:14
|
but once we go down into the
|
|
0:37:19
|
router 1 doesn't know what
|
|
0:37:23
|
So, this is gonna happen over and over and over
|
|
0:37:27
|
that the link control protocol phase
|
|
0:37:35
|
because router 1 is not configured
|
|
0:37:40
|
If we look at this output on router 1,
|
|
0:37:41
|
and Show Log.
|
|
0:37:51
|
Router 1 says, "I received an inbound challenge...
|
|
0:37:57
|
that is coming from..." Where did that go?
|
|
0:38:09
|
"--inbound challenge received from router 3."
|
|
0:38:13
|
So, this is the host name that router 3
|
|
0:38:18
|
So, when router 3 is generating the request,
|
|
0:38:21
|
it's sending its username,
|
|
0:38:23
|
which is equal to the host name
|
|
0:38:28
|
Router 1 then says, "I'm trying to send a response,
|
|
0:38:35
|
So, the response is failing."
|
|
0:38:49
|
And I thought there was another log here that said...
|
|
0:38:56
|
There! "Unable to authenticate the peer."
|
|
0:38:59
|
This is a specific PPP Authentication Debug.
|
|
0:39:02
|
So, router 1 doesn't know what to respond with,
|
|
0:39:05
|
because it hasn't been configured...
|
|
0:39:08
|
for this particular username for what response to send.
|
|
0:39:15
|
And this is the key difference between the
|
|
0:39:20
|
Router 1 is receiving the request
|
|
0:39:25
|
This now means that router 1 needs
|
|
0:39:30
|
and whatever shared password that they have.
|
|
0:39:39
|
So, we'll say that the password
|
|
0:39:43
|
Now, on router 3,
|
|
0:39:45
|
when we look at the debug again,
|
|
0:39:49
|
and we'll also Debug PPP Authentication.
|
|
0:40:00
|
Router 3 should see the response
|
|
0:40:10
|
So it says, "An inbound response came from the
|
|
0:40:21
|
But we don't have an entry for them.
|
|
0:40:24
|
So, authentication is failing.
|
|
0:40:27
|
Now, the key difference here is that since
|
|
0:40:32
|
it's not sent in clear text.
|
|
0:40:35
|
We need to make sure that both router 1
|
|
0:40:41
|
to make sure that they end up
|
|
0:40:47
|
So, with CHAP Authentication, you have
|
|
0:40:51
|
With PAP Authentication,
|
|
0:40:54
|
because that information is sent in clear text.
|
|
0:40:58
|
So, this now means on router 3,
|
|
0:41:00
|
we would need to use what command?
|
|
0:41:03
|
We want to validate router 1's response...
|
|
0:41:09
|
with our own hash value of the password.
|
|
0:41:13
|
So, we need to say,
|
|
0:41:19
|
create a hash value of the SHAREDSECRET,
|
|
0:41:24
|
and see if it matches.
|
|
0:41:27
|
If my hash of that matches with 1 sent,
|
|
0:41:30
|
then authentication is successful.
|
|
0:41:33
|
Which in this case, we see that it is, because now,
|
|
0:41:39
|
And if now, I ping router 1,
|
|
0:41:41
|
I can reach them.
|
|
0:41:44
|
If we look at the log for the final result,
|
|
0:41:56
|
router 3 is generating the outbound challenge.
|
|
0:41:59
|
It came from its own global host name.
|
|
0:42:03
|
Router 1 is then responding
|
|
0:42:07
|
and we should see that the
|
|
0:42:12
|
So, we're replying back to router 1
|
|
0:42:18
|
Authentication is successful, now, we
|
|
0:42:25
|
So, if we look at the full configuration,
|
|
0:42:28
|
it's actually really straightforward here.
|
|
0:42:30
|
On router 3,
|
|
0:42:33
|
at the interface level,
|
|
0:42:36
|
we said PPP Authentication...
|
|
0:42:39
|
CHAP.
|
|
0:42:41
|
Router 1 says that "Someone
|
|
0:42:47
|
I'm responding back with
|
|
0:42:51
|
Router 3 would then need to validate that against
|
|
0:42:57
|
with the same value.
|
|
0:43:02
|
Now, in either case, regardless of
|
|
0:43:07
|
the passwords always have to be the same.
|
|
0:43:12
|
This would also imply that the way that the
|
|
0:43:18
|
must be some sort of reversible encryption.
|
|
0:43:22
|
So, either in clear text or type 7 encryption,
|
|
0:43:29
|
this configuration here, if I were to say,
|
|
0:43:36
|
this would not be supported.
|
|
0:43:39
|
Because router 1 takes ABC
|
|
0:43:44
|
Then, what actually happens in the
|
|
0:43:48
|
put it into MD-5 again.
|
|
0:43:52
|
The second result of that is not gonna
|
|
0:43:58
|
So, with CHAP Authentication,
|
|
0:44:01
|
It has to be Username Password.
|
|
0:44:08
|
Now there's a question, "So, the username
|
|
0:44:11
|
It doesn't have to be the host name.
|
|
0:44:17
|
So, if we don't tell the router what
|
|
0:44:22
|
then, it's gonna default to whatever
|
|
0:44:25
|
Now, we can tell it to use a different value.
|
|
0:44:28
|
This is what we have at the interface level
|
|
0:44:31
|
with the PPP CHAP Host Name
|
|
0:44:37
|
Now, if we look at router 1,
|
|
0:44:40
|
and we'll go to the link level,
|
|
0:44:44
|
we'll say that PPP CHAP Host Name is...
|
|
0:44:51
|
ROUTER1. Instead of R1.
|
|
0:44:55
|
If we look at router 3 now,
|
|
0:45:00
|
I'll shut the interface down and bring it back up.
|
|
0:45:14
|
Router 3 is now receiving the response
|
|
0:45:19
|
with the string router 1 instead of R1,
|
|
0:45:24
|
in this case, router 3 doesn't have a
|
|
0:45:29
|
So now, authentication is failing because it doesn't
|
|
0:45:36
|
Now, this configuration is valid for
|
|
0:45:40
|
There's nothing wrong with that.
|
|
0:45:41
|
We just need to make sure that router 3
|
|
0:45:44
|
So, if we say Username Router 1,
|
|
0:45:51
|
Now, authentication should be correct,
|
|
0:45:55
|
because...
|
|
0:45:57
|
router 3 matches this username's response
|
|
0:46:08
|
Likewise, router 3 could change
|
|
0:46:13
|
which would then mean that router 1...
|
|
0:46:19
|
would need to change what
|
|
0:46:23
|
So, instead of username R3, it would be
|
|
0:46:30
|
The other option here...
|
|
0:46:32
|
would be to use a default username and password,
|
|
0:46:37
|
A default password.
|
|
0:46:40
|
So on router 1,
|
|
0:46:41
|
I'm gonna get rid of this particular user.
|
|
0:46:46
|
Instead at the link level,
|
|
0:46:49
|
I'm gonna say, "The PPP CHAP
|
|
0:46:57
|
This now means that no matter
|
|
0:47:03
|
I'm always going to reply
|
|
0:47:07
|
Or more specifically, the MD-5
|
|
0:47:12
|
So, if we look at the log here,
|
|
0:47:18
|
Then shut the link down and bring it back up.
|
|
0:47:32
|
And look at the Show Log.
|
|
0:47:43
|
It says, "The challenge came in from...
|
|
0:47:46
|
the user router 3.
|
|
0:47:49
|
We're using just the default
|
|
0:47:55
|
The only case that this would not be used...
|
|
0:47:58
|
is if we did have a more specific match for that
|
|
0:48:05
|
So, we could have a configuration
|
|
0:48:08
|
that at the interface level,
|
|
0:48:13
|
PPP CHAP Password that is my...
|
|
0:48:18
|
default password.
|
|
0:48:20
|
But I have a more specific username entry
|
|
0:48:27
|
This would mean that if R3 challenged us,
|
|
0:48:32
|
we would respond with the hash value of this.
|
|
0:48:35
|
But if anyone else challenge us, we're gonna
|
|
0:48:42
|
The key that is not as well
|
|
0:48:46
|
is that the PPP CHAP Password
|
|
0:48:50
|
It cannot be used for a
|
|
0:48:55
|
This means that in this particular case,
|
|
0:49:01
|
by saying PPP Authentication CHAP.
|
|
0:49:03
|
We would not be able to use the PPP
|
|
0:49:11
|
So, this is only for a response.
|
|
0:49:22
|
So, here's our first most basic variation.
|
|
0:49:29
|
The second would be if...
|
|
0:49:32
|
router 3 said, "My PPP CHAP host name is...
|
|
0:49:38
|
EFG.
|
|
0:49:40
|
Then, router 1 would say
|
|
0:49:47
|
If router 3 said...
|
|
0:49:52
|
Or not router 3, router 1 could say,
|
|
0:49:57
|
the PPP CHAP password is ABC.
|
|
0:50:03
|
Then, this is the default password that's used...
|
|
0:50:06
|
regardless where the challenge comes from.
|
|
0:50:11
|
Then, if we were to use the PPP
|
|
0:50:17
|
this command is not gonna do anything then.
|
|
0:50:19
|
So, you can only use PPP CHAP Password
|
|
0:50:25
|
not when you are the person who is actually
|
