ccie blog

LCP, CHAP, and PPP

This post will discuss Link Control Protocol (LCP),  Challenge Handshake Authentication Protocol (CHAP), and Point-to-Point Protocol (PPP).

Link Control Protocol (LCP) deals with the the negotiation parameters of PPP.  In summary it is responsible for:

  • Bringing up the link line-protocol between the two endpoints (i.e. so the link goes UP and UP)
  • Negotiating which authentication protocol will be used across the link, such as CHAP or PAP (CHAP in our case).  LCP can also use a bunch of Network Control Protocols (NCP’s) such as IPCP (IP Control Protocol) or as IPv6CP that can be used to negotiate an IP or IPv6 address over LCP.
  • Maintaining or terminating the link between two PPP endpoints.

There are a bunch of phases LCP goes through in order to bring up the link, as shown below.

  • Down
  • Establishing
  • Authenticating. This is optional, but if it’s configured then both end points must pass the authentication stage before LCP can bring up the link. Once any configured authentication is completed, then the LCP state is considered open.
  • Network. LCP then continues with NCP (Network Control Protocol) negotiation of upper layer protocols such as IP Control Protocol (IPCP). Once everything has been agreed between the two endpoints, the NCP state is considered “Open”. Note here, that NCP is not a protocol, it’s just an abbreviation to describe that network layer protocol’s will be negotiated during the network phase in LCP.
  • Terminate

In summary here, providing that the layer 1 path between endpoints is good/working, we should be able to get straight to the authentication stage in LCP. If we don’t then it usually indicates a layer 1 problem or hardware compatibility between endpoints. In my experience, I’ve seen this where I was using PPPoA on a DSL connection & I had an incompatibility between my routers WIC and the DSLAM at the exchange, therefore the LCP connection never reached the “authenticating” state. Anyways, if layer 1 is good, LCP will reach the authenticating phase and it will negotiate what type of authentication it will use across the link (if any at all).  The most common authentication used for PPP sessions today is over DSL, where we authenticate using CHAP. There are many alternatives such as MS-CHAP, PAP, EAP etc. But for the sake of the CCIE R&Sv5 course, I believe we only have to learn CHAP. So I have shown the CHAP 3-way handshake below.

CHAP Challenge

 

To put this into a real life example, I’ve put a very basic PPP configuration below, that uses the CHAP 3-way handshake shown in the diagram above.   R1 is going to be the router that will authenticate R2.

 

CHAP Initial Diagram

 

R1(config)#username test password test
R1(config)#!
R1(config)#interface Serial1/0
R1(config-if)#encapsulation ppp
R1(config-if)#ppp authentication chap
R2(config)#interface Serial1/0
R2(config-if)#encapsulation ppp
R2(config-if)#ppp chap hostname test
R2(config-if)#ppp chap password test

 

Ok, so since R1 is going to authenticate R2, the #ppp authentication chap command is required on R1 since he is dictating the terms and conditions for other routers to connect to him via ppp.

  1. Assuming that the physical layer 1 connectivity between R1 and R2 is fine, when you #no shut the interface on both sides LCP will move into the Established state. Since one of the routers, R1 in this case, is configured with #ppp authentication chap, LCP then sends a CONFREQ (configuration request) over to R2 indicating that he will need use CHAP on this link before it can be possible to make LCP bring the link to the UP/UP state. R2 sees the challenge and agrees to use CHAP by replying with a CONFACK (configuration acknowledgement). R1 then sends a CHAP challenge over to R2.
  2. R2 replies with a CHAP response, containing the the credentials configured on the interface connecting to R1 (see the config above). What actually happens here, is that R2 sends the hostname in plain text, but sends a hash of the configured password over to R1
  3. R1 then sees the hostname and hashed password sent from R2 , and looks in his database for an entry that matches the CHAP hostname provided by R2. On R1 this can be seen in the configuration “username test password test” (remember the hostname test was not hashed, so that is how R1 can find the entry).  R1 then takes a hash of this locally stored password and compares it against the hash that was sent by R2.  If the two hash values match, then a CHAP Success message is sent to R2.

Now that R1 has authenticated R2, LCP needs to complete the NCP negotiation. In this stage, other upper layer protocols such as IP or IPv6 are negotiated. So if I were to configure an IP address on both ends of the link now, IPCP (IP Control Protocol) would negotiate that IP needs to be used on the link. So what happens is literally, IPCP uses the CONFREQ and CONFACK messages again to state IP needs to be used over the link & then sends the IP address configured on each routers serial interface. At this point, you would see that IPCP has reached the “open” state.

So for your verification, the fastest way to see if it’s working is just to do a #show interface command and check if LCP has reached the “open”state, and also check what NCP’s have reached the “open” state. So for example, in the output below, we can see that LCP has reached the open state, and IPCP and CDPCP were the NCP’s that reached the open state.

R2#sh int s1/0
Serial1/0 is up, line protocol is up
Hardware is M4T
Internet address is 2.2.2.2/30
MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation PPP, LCP Open
Open: IPCP, CDPCP

For more detailed information you can just use a #debug ppp negotiation and #debug ppp authentication command and watch what happens when you bring the link up.

Leave a comment

Your comment