PPP in brief

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol packets over point-to-point links between two peers.

In order to establish a communication link between two peers, each end of the PPP link must first send LCP packets to configure and test the data link. After the link has been established, the peer may be authenticated (optional). Then, PPP must send NCP packets to choose and configure one or more network-layer protocols. Once each of the chosen network-layer protocols has been configured, datagrams from each network-layer protocol can be sent over the link.

The link will remain configured for communications until explicit LCP or NCP packets close the link down, or until some external event occurs. RFC 1661

PPP negotiation phases:

Link Control Protocol (LCP phase): is responsible for establishing, negotiating the configuration, mantinance and termination of the link. If this phase is successfuly completed the router may proceed to the optional authentication phase then NCP phase.

Authentication phase: This is an optional states in which peers can authenticate each other using different methods. In LCP phase the peers will negotiate the authentication protocol if they agree a series of authentication messages are exchanged to authenticate the identity of the remote side.PPP defines two authentication protocols PAP and CHAP.

Network Control Protocol (NCP phase): LCP invokes the network control protocol phase that is specific for each layer three protocol. NCP negotaiates parameters that are unique to that layer 3 protocol. The routers exchange IPCP messages to negotiate the Internet Protocol specific options.

Each PPP peer sends the IP address of its interface as a /32 route during the IPCP negotiations to its neighbor.

PPP supports a lot of features including data compression, Multilink PPP or MLPPP, loop back detection and link quality monitoring. For more information check out RFC

Basic PPP configuration:

Router1 is directly connected to Router2 using a back to back serial link.

R1 configuration:

int s1/1
encapsulation ppp
clock rate 128000
ip address 192.168.12.1 255.255.255.0
no shut

R2 configuration:

int s1/1
encapsulation ppp
ip address 192.168.12.2 255.255.255.0
no shut

Verification and troubleshooting:

R1#show interface s1/1 

Serial1/1 is up, line protocol is up
Hardware is M4T
Internet address is 192.168.12.1/24
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation PPP, LCP Open
Open: CDPCP, IPCP, crc 16, loopback not set

! -- output omitted--

R1(config-if)#do sh ip route
Gateway of last resort is not set
! -- output omitted--
192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks
C       192.168.12.0/24 is directly connected, Serial1/1
C       192.168.12.2/32 is directly connected, Serial1/1

R2(config-if)#do sh ip route
! -- output omitted--
Gateway of last resort is not set

192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks
C       192.168.12.0/24 is directly connected, Serial1/2
C       192.168.12.1/32 is directly connected, Serial1/2

This is the output of the command debug ppp negotiation on R1, showing all PPP stages completed successfuly:

*Mar  2 00:50:28.205: Se1/1 PPP: Outbound cdp packet dropped
*Mar  2 00:50:28.265: Se1/1 PPP: Outbound cdp packet dropped
*Mar  2 00:50:28.329: Se1/1 PPP: Outbound cdp packet dropped
*Mar  2 00:50:29.889: %LINK-3-UPDOWN: Interface Serial1/1, changed state to up
*Mar  2 00:50:29.901: Se1/1 PPP: Using default call direction
*Mar  2 00:50:29.905: Se1/1 PPP: Treating connection as a dedicated line
*Mar  2 00:50:29.909: Se1/1 PPP: Session handle[F9000002] Session id[2]
*Mar  2 00:50:29.913: Se1/1 PPP: Phase is ESTABLISHING, Active Open
*Mar  2 00:50:29.917: Se1/1 LCP: O CONFREQ [Closed] id 42 len 10
*Mar  2 00:50:29.925: Se1/1 LCP:    MagicNumber 0x05613817 (0x050605613817)
*Mar  2 00:50:30.349: Se1/1 LCP: I CONFREQ [REQsent] id 3 len 10
*Mar  2 00:50:30.349: Se1/1 LCP:    MagicNumber 0x0219B40C (0x05060219B40C)
*Mar  2 00:50:30.353: Se1/1 LCP: O CONFACK [REQsent] id 3 len 10
*Mar  2 00:50:30.357: Se1/1 LCP:    MagicNumber 0x0219B40C (0x05060219B40C)
*Mar  2 00:50:30.361: Se1/1 LCP: I CONFACK [ACKsent] id 42 len 10
*Mar  2 00:50:30.365: Se1/1 LCP:    MagicNumber 0x05613817 (0x050605613817)
*Mar  2 00:50:30.369: Se1/1 LCP: State is Open
*Mar  2 00:50:30.373: Se1/1 PPP: Phase is FORWARDING, Attempting Forward
*Mar  2 00:50:30.381: Se1/1 PPP: Phase is ESTABLISHING, Finish LCP
*Mar  2 00:50:30.389: Se1/1 PPP: Phase is UP
*Mar  2 00:50:30.389: Se1/1 IPCP: O CONFREQ [Closed] id 1 len 10
*Mar  2 00:50:30.393: Se1/1 IPCP:    Address 192.168.12.1 (0x0306C0A80C01)
*Mar  2 00:50:30.397: Se1/1 CDPCP: O CONFREQ [Closed] id 1 len 4
*Mar  2 00:50:30.405: Se1/1 PPP: Process pending ncp packets
*Mar  2 00:50:30.417: Se1/1 IPCP: I CONFREQ [REQsent] id 1 len 10
*Mar  2 00:50:30.421: Se1/1 IPCP:    Address 192.168.12.2 (0x0306C0A80C02)
*Mar  2 00:50:30.425: Se1/1 IPCP: O CONFACK [REQsent] id 1 len 10
*Mar  2 00:50:30.425: Se1/1 IPCP:    Address 192.168.12.2 (0x0306C0A80C02)
*Mar  2 00:50:30.429: Se1/1 IPCP: I CONFACK [ACKsent] id 1 len 10
*Mar  2 00:50:30.433: Se1/1 IPCP:    Address 192.168.12.1 (0x0306C0A80C01)
*Mar  2 00:50:30.433: Se1/1 IPCP: State is Open
*Mar  2 00:50:30.449: Se1/1 IPCP: Install route to 192.168.12.2
*Mar  2 00:50:30.465: Se1/1 IPCP: Add link info for cef entry 192.168.12.2
*Mar  2 00:50:30.485: Se1/1 CDPCP: I CONFREQ [REQsent] id 1 len 4
*Mar  2 00:50:30.489: Se1/1 CDPCP: O CONFACK [REQsent] id 1 len 4
*Mar  2 00:50:30.493: Se1/1 CDPCP: I CONFACK [ACKsent] id 1 len 4
*Mar  2 00:50:30.493: Se1/1 CDPCP: State is Open

You can check the following link to get more information about PPP negotiation and how to understand the debug output.

We are going to discuss more about PPP features and advanced configuration in upcoming posts.


No related posts.


You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

AddThis Social Bookmark Button

3 Responses to “PPP in brief”

  1. Mohamed Kamal Says:

    Hi Wael,

    I’m very pleased to find this resource of network information maintained by three of experts for free! God give you strength and patience to be able to keep it running.

    I have two questions regarding the PPP on serial links.

    1- Why don’t we use a /31 prefix masks? I did a little search and I found it can be used (although there no host addresses)! So is it possible? and why wouldn’t we use it to conserve our address pool?

    2- For PPP, Does it support an Error Correction? or Error Detection only and the correction are kept to the higher layer TCP to be handled?

    Actually, Some books says that it’s an error correction protocol but not by default, and others state that PPP never handles error correction!

    Thanks in advance.

    Note: I’ll write down the questions that I failed to find answers for under every category if it won’t bother you.

  2. Hi Mohamed,

    Thanks for you nice words, I just want to say that we are not yet experts we are just trying to be :)

    For PPP we can use /31 addresses and even unnumbered interfaces for better conservation of the address pool. check out this post for more information http://networkers-online.com/blog/?p=23

    Check this document for more information about using /31 address for PPP connections http://www.cisco.com/en/US/docs/ios/12_2t/12_2t2/feature/guide/ft31addr.html

    For the second question as I know PPP is providing error detection only and not error correction. The correction function is left to the upper layer protocols. PPP will only drop the corrupted frames and will not try to make any corrections.

    I hope this answered your questions…

  3. Mohamed Kamal Says:

    Dear Wael,

    Thanks for your answer, and yup I’ve read the Cisco document before but I was unsure about it’s validity in real life.

Leave a Reply