Link Control Protocol (LCP) configuration options

Link control protocol (LCP) offers different PPP encapsulation options, including the following:

• Authentication: This option tells the calling side of the link to send information that can identify the user. The two methods are PAP and CHAP.
• Compression: This is used to increase the throughput of PPP connections by compressing the data or payload prior to transmission. PPP decompresses the data frame on the receiving end.
• Error Detection: PPP uses Quality and Magic number options to ensure a reliable, loop-free data link.
• Multilink: Starting with IOS version 11.1, multilink is supported on PPP links with Cisco routers. This option makes several separate physical paths appear to be one logical path at layer 3. For example, two T1s running multilink PPP would show up as a single 3 Mbps path to a layer 3 routing protocol.
• PPP callback: PPP can be configured to call back after successful authentication. PPP callback can be a good thing for you because you can keep track of usage-based upon access charges, accounting records, and a bunch of other reasons. With callback enabled, a calling router (client) will contact a remote router (server) and authenticate as we described earlier.  (know that both routers have to be configured for the callback feature for this to work.) Once authentication is completed, the remote router will terminate the connection and then re-initiate a connection to the calling router from the remote router.

PPP session Establishment

When PPP connections are started, the links go through three phases of session establishment, as shown in the picture below.

• Link Establishment phase: LCP packets are sent by each PPP device to configure and test the link. These packets contain a field called the configuration option that allows each device to see the size of the data, compression, and authentication. If no configuration option field is present, then the default configuration will be used.
• Authentication phase: If required, either CHAP or PAP can be used to authenticate a link. Authentication takes place before Network layer protocol information is read. And it’s possible that link-quality determination will occur simultaneously.
• Network Layer Protocol Phase: PPP uses the Network Control Protocol (NCP) to allow multiple network layer protocols to be encapsulated and sent over a PPP data link. Each network layer protocol (e.g. IP, IPX, AppleTalk, which are routed protocols) establishes service with NCP.

PPP authentication methods

There are two methods of authentication that can be used with PPP links:

• Password Authentication Protocol (PAP): The password authentication protocol (PAP) is the less secure of the two methods. Passwords are sent in clear text, and PAP is only performed upon the initial link establishment. When the PPP link is first established, the remote node sends the username and password back to the originating router until authentication is acknowledged.
• Challenge Handshake Authentication Protocol (CHAP): The challenge Handshake Authentication Protocol (CHAP) is used at the initial startup of a link and at periodic checks up on the link to make sure the router is still communicating with the same host.

After PPP finishes its initial link-establishment phase, the local router sends a challenge request to the remote device. The remote device sends a value calculated using a one-way hash function called MD5 the local router checks this hash value to make sure it matches. If the values don’t match, the link is immediately terminated.

Configuring PPP on Cisco Routers

Configuring PPP encapsulation on an interface is really pretty straightforward. To configure it  from the CLI, follow these simple router commands:

Router#config t
Enter configuration commands, one per line. End with CNTL/Z.
Router (config)#int s0
Router(config-if)#encapsulation PPP
Router(config-if)#^Z
Router#

Of course, PPP encapsulation has to enable on both interfaces connected to a serial line in order to work, and there are several additional configuration options available to you via the help command.

Configuring PPP Authentication

After you configure your serial interface to support PPP encapsulation, you can configure authentication using PPP between routers. First, you need to set the hostname of the router, if it’s not already. Then you set the username and password for the remote router that will be connecting to your router.

Here’s an example:

Router#config t
Enter configuration commands, one per line. End with CNTL/Z
Router(config)#hostname RouterA
RouterA(config)#username RouterB password cisco

When using the hostname command, remember that the username is the hostname of the remote router that’s connecting to your router. And it’s case sensitive too. Also, the password on both routers must be the same. It’s a plain-text password that you can see with a show run command; you can encrypt the password by using the command service password-encryption. You must have a username and password configured for each remote system you plan to connect to. The remote routers must also be configured with usernames and passwords.

Now, after you’ve set the hostname, usernames, and passwords, choose the authentication type, either CHAP or PAP:

routerA#config t
enter configuration commands, one per line. End with CNTL/Z
routerA(config)#int s0
routerA(config-if)#PPP authentication chap pap
routerA(config-if)#^Z
routerA#

if both methods are configured on the same line, as shown here, then only the first method will be used during link negotiations the second acts as a backup just in case the first method fails.

Verifying PPP encapsulation

Okay now that PPP encapsulation is enabled, let us show you how to verify that it’s up and running. First, let’s take a look at a figure of a sample network. The following picture shows to routers connected with either a point-to-point serial or ISDN connection.

You can start verifying the configuration with show interface command:

Pod1R1#sh int s0/0
Serial0/0 is up, line protocol is up
Hardware is power QUICC serial internet address is 10.0.1.1/24
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
Reliability 239/255, txload 1/255, rxload 1/255
Encapsulating PPP
Loopback not set Keepalive
Set (10 sec)
LCP open
Open: IPCP, CDPCP
[output cut]

Notice that the sixth line lists encapsulation as PPP and the eighth line shows that the LCP is open. This means that it has negotiated the session establishment and all is good! The ninth line tells us that NCP is listening for the protocols IP and CDP. But what will you see if everything isn’t perfect?

We’re going to type in the configuration shown in the picture below and find out.

Okay, what’s wrong here? Take a look at the usernames and passwords. Do you see the problem now? That’s right, the C is capitalized on the Pod1R2 username and password found in the configuration of the router Pod1R1. This is wrong because the usernames and passwords are case sensitive, remember? Let’s take a look at the show interface command and see what happens:

Pod1R1#sh int s0/0
Serial0/0 is up, line protocol is down
Hardware is PowerQUICC serial internet address is 10.0.1.1/24
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
Reliability 243/255, txload 1/255, rxload 1/255
Encapsulation PPP, loopback not set
Keepalive set (10 sec)
LCP closed
Closed: IPCP, CDPCP

First, notice in the first line of output that serial0/0 is up, line protocol is down. This is because there are no keepalives coming from the remote router. Next, notice that the LCP is closed because the authentication failed.

Debugging PPP Authentication

To display the CHAP authentication process as it occurs between two routers in the network, just use the command debug PPP authentication.

If your PPP encapsulation and authentication are set up correctly on both routers, and your usernames and passwords are all good, then the debug PPP authentication command will display an output that looks like this:

1d16h: Se0/0 PPP: Using default call direction
1d16h: Se0/0 PPP: Treating connection as a dedicated line
1d16h: Se0/0 CHAP: O CHALLENGE id 219 len 27 from “Pod1R1”
1d16h: Se0/0 CHAP: I CHALLENGE id 208 len 27 from “Pod1R2”
1d16h: Se0/0 CHAP: O RESPONSE id 208 len 27 from “Pod1R1”
1d16h: Se0/0 CHAP: I RESPONSE id 219 len 27 from “Pod1R2”
1d16h: Se0/0 CHAP: O SUCCESS id 219 len 4
1d16h: Se0/0 CHAP: I SUCCESS id 208 len 4

But if you have the username wrong, as we did previously in the PPP authentication failure example above, the output would look something like this:

1d16h: Se0/0 PPP: Using default call direction
1d16h: Se0/0 PPP: Treating connection as a dedicated line
1d16h: %SYS-5-CONFIG_I: configured from console by console
1d16h: Se0/0 CHAP: O CHALLENGE id 220 len 27 from “Pod1R1”
1d16h: Se0/0 CHAP: I CHALLENGE id 209 len 27 from “Pod1R2”
1d16h: Se0/0 CHAP: O RESPONSE id 209 len 27 from “Pod1R1”
1d16h: Se0/0 CHAP: I RESPONSE id 220 len 27 from “Pod1R2”
1d16h: Se0/0 CHAP: O FAILURE id 220 len 25 msg is “MD/DES compare failed”

PPP with CHAP authentication is a three-way authentication, and if the username and password are not configured exactly the way they should be, then the authentication will fail and the link will be down.

Mismatched WAN encapsulations

If you have a point-to-point link but the encapsulations aren’t the same, the link will never come up. The following picture shows one link with PPP and one with HDLC.

Look at router Pod1R1 in this output:

Pod1R1#sh int s0/0
Serial0/0 is up, line protocol is down
Hardware is PowerQUICC serial internet address is 10.0.1.1/24
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
Reliability 254/255, txload 1/255, rxload 1/255
Encapsulation PPP, loopback not set
Keepalive set (10 sec)
LCP REQsent
Closed: IPCP, CDPCP

The serial interface is down and LCP is sending requests but will never receive any responses because router Pod1R2 is using the HDLC encapsulation. To fix this problem, you would have to go to router Pod1R2 and configure the PPP encapsulation on the serial interface. One more thing even though the user names are configured and they’re wrong, it does not matter because the command PPP authentication chap isn’t used under the serial interface configuration and the username command isn’t relevant in this example.

Mismatched IP addresses

A tricky problem to spot is if you have HDLC or PPP configured on your serial interface but your IP addresses are wrong. Things seem to be just fine because the interfaces will show that they are up. Take a look at the picture below and see if you can see what we mean the two routers are connected with different subnets router Pod1R1 with 10.0.1.1/24 and router Pod1R2 with 10.2.1.2/24.

This will never work. But as we said, take a look at the output:

Pod1R1#sh int s0/0
Serial0/0 is up, line protocol is up
Hardware is PowerQUICC serial Internet address is 10.0.1.1/24
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
Reliability 255/255, txload 1/255, rxload 1/255
Encapsulation PPP, loopback not set
Keepalive set (10 sec)
LCP open
Open: IPCP, CDPCP

See that? The IP addresses between the routers are wrong but the link looks like it’s working fine. This is because PPP, like HDLC and frame relay, is a layer 2 WAN encapsulation and doesn’t care about IP addresses at all. So yes, the link is up, but you can’t use IP across this link since it’s misconfigured.

To find and fix this problem, you can use the show running-config or the show interfaces command on each router, or you can use what you can learn from the Foundation Of Cisco IOS operations the show cdp neighbors details command:

Pod1R1#sh cdp neighbors detail
-------------------------------------
Entry address (es):
IP address: 10.2.1.2

You can view and verify the directly connected neighbor’s IP address and then solve your problem.

Okay before we move onto the Frame Relay, let’s take a look at PPPoE.

PPPoE configuration

If you have a router with an interface that supports PPPoE and the router is connected to a DSL modem, you can configure the router to be a PPPoE client well, assuming your ISP has provided you with the authentication information, that is.

Let’s take a look at configuring a PPPoE client on a router. Here’s what it looks like under the physical interface:

R1(config)#int f0/0
R1(config-if)#p ?
Pppoe                   pppoe-client     priority-group
R1(config-if)#pppoe ?
Enable                  Enable pppoe
Max-sessions    maximum PPPoE sessions
R1(config-if)#pppoe enable ?
Group                   attach a BBA group
<cr>
R1(config-if)#pppoe enable group ?
WORD                  BBA group name
Global                  attach global PPPoE group
R1(config-if)#pppoe enable group global
R1(config-if)#pppoe-client dial-pool-number ?
<1-255>                Dialer pool number
R1(config-if)#pppoe-client dial-pool-number 1
 !
Interface FastEthernet 4
Description $ETH-WAN$ no ip address
Duplex                                 auto
Speed                   auto
Pppoe                   enable group global
Pppoe-client dial-pool-number                1
!

After all that, there really are only two commands needed under the physical interface the pppoe enable command and the pppoe-client command. And both of them reference the logical interface we haven’t created yet.

In order to add a PPPoE connection to your router, you need to also create a dialer interface. This is a logical interface, and under it, we are going to add the ip address negotiated command so as a DHCP address can be received and configured on the interface. And by the way, if you’re using private IP addresses between the DSL modem and your router, you can easily add a static IP address on this interface. Take a look:

!
Interface Dialer()
Ip address negotiated
Ip mtu 1452
Encapsulation ppp
Dialer pool 1
Dialer-group 1
Ppp authentication chap callin
Ppp chap hostname Todd
Ppp chap password 0 lammle
!

Take special notice of how the logical interface associates itself to the physical interface with both the dial pool 1 command and the dialer-group 1 command.

Last, under the dialer interface, the PPP authentication is set using the ppp authentication and ppp chap commands. Using the CLI, we provided these commands at global configuration mode, but in this setup, we’ll configure the command directly under the logical interface instead.