When two devices are first turned on, there is no active link-layer connection between them. Once the physical connection is made, the devices can begin establishing a PPP (Point-to-Point Protocol) session. There are three phases to establishing a PPP session:
Phase 1: Link establishment and configuration negotiation
Before PPP exchanges any network layer datagrams, such as IP, the Link Control Protocol (LCP) must first perform the basic setup of the link. The initiating device (Device A) sends an LCP Configure-Request to the receiving device (Device B). Device B receives the configuration request message over the physical link, containing the parameters Device A wishes to use.
If Device B agrees with the parameters, it replies with a Configure-Ack; otherwise it sends a Configure-Nak or Configure-Reject. In the case of a Nak or Reject, the sending device tries different parameters with a new request. This phase is complete when negotiation between both devices succeeds. After Phase 1 completes successfully, the LCP status moves to “open,” and, if authentication has been configured on the link, the session proceeds to an authentication phase (typically PAP or CHAP) before moving on to Phase 3. See our guide to configuring CHAP authentication for a detailed walkthrough of this optional authentication step.
Phase 2: Link quality determination
Link quality determination is the second phase of PPP session establishment. It is an optional phase. LCP checks the link quality to determine whether the link is sufficient to bring up network-layer protocols. LCP can delay handing off to network-layer protocol information until this phase completes.
Phase 3: Network layer protocol configuration negotiation
After link quality determination (and authentication, if configured), the specific configuration of the appropriate network-layer protocol is performed by invoking the suitable NCP (Network Control Protocol), such as IPCP for IPv4 or IPv6CP for IPv6. If LCP terminates the link, it informs the network-layer protocols so they can take appropriate action. More than one NCP can run on a single PPP link simultaneously, and each NCP can be terminated independently when it is no longer needed. The PPP link remains configured for communication until explicit LCP or NCP frames terminate the link, or until some outside event forces closure.
LCP Operation
Link Control Protocol (LCP) is the core control mechanism of a PPP session, responsible for establishing, configuring, and testing the data-link connection. It operates at the Data Link layer of the OSI model. LCP automatically negotiates the encapsulation format, packet sizes, detects a looped-back link, and identifies common misconfiguration errors. It is also responsible for orderly connection termination. LCP operation uses three classes of frames to accomplish the work of each phase:
- Link-establishment frames
- Link-maintenance frames
- Link-termination frames
Link Establishment
Link establishment is the first phase of LCP operation and must complete successfully before any network-layer packets are exchanged. During link establishment, LCP opens the connection and negotiates configuration parameters. The initiating device begins by sending a Configure-Request frame to the responder, containing a variable number of configuration options for how it wants the link created, including protocol or authentication parameters.
The responder processes the request. If the options are unsuitable or unrecognized, the responder sends a Configure-Nak or Configure-Reject, and the initiator must restart the process with new options. If the options are suitable and acceptable, the responder replies with a Configure-Ack, and the process moves to the next stage, NCP operation (following authentication, if configured). Once NCP has completed configuration and any required authentication has succeeded, the line is available for data transfer, and LCP transitions into the link maintenance phase.
Link Maintenance
Once the link is in the maintenance phase, LCP can test it using dedicated test and feedback message types:
- Test Message Frames: Echo-Request, Echo-Reply, and Discard-Request are used to actively test the link’s health.
- Feedback Message Frames: Code-Reject and Protocol-Reject frame types provide feedback when a device receives an invalid frame due to an unrecognized LCP code or an unrecognized protocol identifier. A Code-Reject packet is sent in response, and the original sending device typically resends the packet with a corrected value.
Link Termination
The link remains open until LCP terminates it. If LCP terminates the link before NCP does, the associated NCP session is also terminated; NCP itself only terminates the network-layer configuration, not the underlying LCP link. PPP can terminate the link at any time, for reasons including loss of the physical carrier, authentication failure, link quality failure, expiration of an idle-period timer, or an administrator manually closing the link. To close the link in an orderly fashion, LCP exchanges Terminate packets.
The device initiating shutdown sends a Terminate-Request. The other device replies with a Terminate-Ack. As the link closes, PPP informs the network-layer protocols so they can take appropriate action, such as tearing down their own NCP sessions cleanly.
LCP Packet Structure
Every LCP packet shares the same basic structure:
| Field | Size | Description |
|---|---|---|
| Code | 8 bits (1 byte) | Identifies the type of LCP packet |
| Identifier | 8 bits (1 byte) | Matches packet requests with their corresponding replies |
| Length | 16 bits (2 bytes) | Total length of the LCP packet, including all fields |
| Data | Variable (0 or more bytes) | Content determined by the Code field — may contain configuration options, frame information, or rejected data |
Each LCP packet is a complete message: a Code, an Identifier, a Length, and type-specific Data. The Code field determines exactly how the receiving device should interpret and process the packet.
LCP Packet Types (Code Field Values)
| Code (Hex) | Code (Decimal) | Frame Type | Purpose |
|---|---|---|---|
| 0x01 | 1 | Configure-Request | Opens or resets a PPP connection; contains a list of LCP options with proposed changes to default values |
| 0x02 | 2 | Configure-Ack | Sent when every value in the last Configure-Request is recognized and acceptable; LCP negotiation is complete once both peers send and receive a Configure-Ack |
| 0x03 | 3 | Configure-Nak | Sent when some LCP options are unacceptable while others are fine; includes the mismatching options and their acceptable values |
| 0x04 | 4 | Configure-Reject | Sent when an LCP option is unrecognized or entirely non-negotiable; includes the rejected option(s) |
| 0x05 | 5 | Terminate-Request | Optionally sent to begin closing a PPP session |
| 0x06 | 6 | Terminate-Ack | Sent in response to a Terminate-Request |
| 0x07 | 7 | Code-Reject | Sent when a received LCP code is unknown; includes the rejected LCP packet |
| 0x08 | 8 | Protocol-Reject | Sent when a PPP frame includes an unknown protocol ID; includes the rejected packet |
| 0x09 | 9 | Echo-Request | Optionally sent to test the PPP connection |
| 0x0a | 10 | Echo-Reply | Sent in response to an Echo-Request |
| 0x0b | 11 | Discard-Request | Optionally sent to exercise the link in the outbound direction |
Important distinction: PPP’s Echo-Request and Echo-Reply frames are entirely unrelated to ICMP’s Echo-Request and Echo-Reply messages (the ones used by ping). PPP echo operates at the Data Link layer as part of LCP’s own link-testing mechanism, while ICMP echo operates at the Network layer for end-to-end reachability testing. They share terminology but serve completely different purposes at completely different layers.
Configuring and Verifying PPP on Cisco IOS
Basic Configuration
Router(config)# interface Serial0/0/0
Router(config-if)# encapsulation ppp
Router(config-if)# no shutdownBoth ends of the serial link must be configured with encapsulation ppp; a mismatch (one end HDLC, the other PPP) prevents the link from coming up.
Watching LCP Negotiation in Real Time
The debug ppp negotiation command lets you observe the exact LCP phases described above as they actually happen on a live link:
Router# debug ppp negotiationSample output during a successful negotiation:
Se0/0/0 PPP: Treating connection as a dedicated line
Se0/0/0 LCP: O CONFREQ [Closed] id 1 len 15
Se0/0/0 LCP: I CONFREQ [REQsent] id 1 len 15
Se0/0/0 LCP: O CONFACK [REQsent] id 1 len 15
Se0/0/0 LCP: I CONFACK [ACKsent] id 1 len 15
Se0/0/0 LCP: State is Open
Se0/0/0 PPP: Phase is AUTHENTICATING
Se0/0/0 IPCP: O CONFREQ [Closed] id 1 len 10
Se0/0/0 IPCP: I CONFREQ [REQsent] id 1 len 10
Se0/0/0 IPCP: O CONFACK [REQsent] id 1 len 10
Se0/0/0 IPCP: I CONFACK [ACKsent] id 1 len 10
Se0/0/0 IPCP: State is OpenO indicates an outbound packet, I an inbound packet. Note the direct correlation to the phases covered earlier: CONFREQ/CONFACK exchanges at the LCP level (Phase 1), followed by “Phase is AUTHENTICATING” if authentication is configured, followed by the same CONFREQ/CONFACK pattern at the IPCP level (Phase 3, network-layer configuration). “LCP: State is Open” confirms Phase 1 completed successfully; “IPCP: State is Open” confirms the network-layer protocol is now configured and the link is ready for data.
Always disable debugging after use:
Router# undebug allAdditional Verification
Router# show interfaces serial0/0/0Look for Encapsulation PPP and LCP Open in the output, confirming both the correct encapsulation and successful LCP negotiation.
CCNA Exam Pointers
- Three PPP phases: Link Establishment (LCP) → Link Quality Determination (optional) → Network Layer Configuration (NCP)
- Authentication (PAP or CHAP), if configured, occurs after LCP negotiation completes and before NCP configuration
- LCP operates at the Data Link layer; NCP (e.g., IPCP) configures the Network layer
- Three LCP frame classes: establishment, maintenance, termination
- LCP packet structure: Code (8 bits) + Identifier (8 bits) + Length (16 bits) + Data (variable)
- Configure-Ack from both peers = LCP negotiation complete
- PPP Echo-Request/Reply are unrelated to ICMP Echo-Request/Reply — different layers, different purposes, same terminology
encapsulation ppp— enables PPP on a serial interface; must match on both endsdebug ppp negotiation— shows live LCP and IPCP CONFREQ/CONFACK exchange; always follow withundebug allshow interfaces [id]— confirmsEncapsulation PPPandLCP Openstatus
Conclusion
A PPP session establishes through a precise, three-phase sequence: LCP negotiates and opens the link, an optional link quality check confirms it’s healthy enough for traffic, and NCP (such as IPCP) configures the actual network-layer protocol before data can flow. LCP’s own packet structure and eleven defined frame types, Configure-Request through Discard-Request, give it the tools to negotiate parameters, test the link, and terminate cleanly when needed. Watching this entire sequence unfold in real time with debug ppp negotiation is the most direct way to connect this RFC-level theory to what actually happens on a live Cisco serial link.
Frequently Asked Questions
What are the three phases of a PPP session?
The three phases are Link Establishment, where LCP negotiates and opens the basic link; Link Quality Determination, an optional phase where LCP checks whether the link is healthy enough to carry network-layer traffic; and Network Layer Protocol Configuration, where the appropriate NCP (such as IPCP for IPv4) configures the actual network-layer protocol before data transfer begins. If authentication is configured on the link, it occurs between Link Establishment and Network Layer Configuration, after LCP successfully opens but before NCP configures the network layer.
What is the difference between LCP and NCP in PPP?
LCP (Link Control Protocol) operates at the Data Link layer and is responsible for establishing, configuring, testing, and terminating the PPP link itself, independent of whatever network-layer protocol will eventually run over it. NCP (Network Control Protocol) is actually a family of protocols, one per network-layer protocol in use, such as IPCP for IPv4 or IPv6CP for IPv6, and each NCP configures and manages its specific network-layer protocol’s parameters over the link that LCP has already established. A single PPP link can run multiple NCPs simultaneously, and each can be independently terminated without necessarily tearing down the underlying LCP-established link.
How can I see the LCP negotiation process happening on a Cisco router?
Use debug ppp negotiation on a router with a PPP-encapsulated interface to watch the live exchange of Configure-Request (CONFREQ) and Configure-Ack (CONFACK) packets at both the LCP and IPCP level in real time. The output will show “LCP: State is Open” once Phase 1 completes, an “AUTHENTICATING” phase message if PAP or CHAP is configured, and “IPCP: State is Open” once Phase 3 completes and the link is ready for actual data traffic. Always disable the debug output afterward with undebug all, since debug commands can generate significant CPU load on a busy interface.
Are PPP Echo-Request and Echo-Reply the same as ping?
No, despite sharing similar terminology, they are unrelated protocols operating at different layers. PPP’s Echo-Request and Echo-Reply are LCP frame types (Code values 0x09 and 0x0a) used specifically to test the health of an established PPP link at the Data Link layer, as part of LCP’s link maintenance phase. ICMP’s Echo-Request and Echo-Reply, the messages behind the ping command, operate at the Network layer and test end-to-end reachability between any two IP-addressable devices, regardless of what Data Link layer protocol is running underneath. The two mechanisms serve genuinely different diagnostic purposes despite the naming overlap.
What happens if LCP negotiation fails?
If the responding device finds the proposed configuration options unsuitable or unrecognized, it replies with a Configure-Nak (some options acceptable, others need different values) or a Configure-Reject (some options entirely unrecognized or non-negotiable) instead of a Configure-Ack. The initiating device must then restart the negotiation with revised options based on the feedback received. If negotiation continues to fail entirely, no Configure-Ack is ever exchanged, LCP never reaches the “Open” state, and the PPP session cannot progress to the authentication or network-layer configuration phases, meaning no data can be transferred over the link.
