Troubleshoot PPP

Similar to other protocols implemented on a router, troubleshooting PPP involves a combination of debug and show commands. This section discusses how to use these commands to troubleshoot PPP negotiation and authentication.

Troubleshooting PPP Serial Encapsulation

Recall that the debug command is used for troubleshooting and is accessed from privileged EXEC mode of the command-line interface. A debug output displays information about various router operations, related traffic generated or received by the router, and any error messages. It can consume a significant amount of resources, and the router is forced to process-switch the packets being debugged. The debug command must not be used as a monitoring tool; rather, it is meant to be used for a short period of time for troubleshooting.

Use the debug ppp command to display information about the operation of PPP.

Router# debug ppp {packet | negotiation | error | authentication | compression |
   cbcp}

Table 3-8 shows the command syntax. Use the no form of this command to disable debugging output.

Table 3-8 debug ppp Command Parameters

Parameter Usage
packet Displays PPP packets being sent and received. (This command displays low-level packet dumps.)
negotiation Displays PPP packets transmitted during PPP startup, where PPP options are negotiated.
error Displays protocol errors and error statistics associated connection negotiation and operation.
authentication Displays authentication protocol messages, including Challenge Authentication Protocol (CHAP) packet exchanges and Password Authentication Protocol (PAP) exchanges.
compression Displays information specific to the exchange of PPP connections using MPPC. This command is useful for obtaining incorrect packet sequence number information where MPPC compression is enabled.
cbcp Displays protocol errors and statistics associated with PPP connection negotiations using MSCB.

Use the debug ppp command when trying to search the following:

  • NCPs that are supported on either end of a PPP connection
  • Any loops that might exist in a PPP internetwork
  • Nodes that are (or are not) properly negotiating PPP connections
  • Errors that have occurred over the PPP connection
  • Causes for CHAP session failures
  • Causes for PAP session failures
  • Information specific to the exchange of PPP connections using the Callback Control Protocol (CBCP), used by Microsoft clients
  • Incorrect packet sequence number information where MPPC compression is enabled

Debug PPP

In addition to the debug ppp command, there are other commands that are available for troubleshooting a PPP connection.

A good command to use when troubleshooting serial interface encapsulation is the debug ppp packet command, as shown in Example 3-5. The example depicts packet exchanges under normal PPP operation, including LCP state, LQM procedures, and the LCP magic number.

Example 3-5 Output of debug ppp packet Command

R1# debug ppp packet
PPP packet display debugging is on
R1#
*Apr  1 16:15:17.471: Se0/0/0 LQM: O state Open magic 0x1EFC37C3 len 48
*Apr  1 16:15:17.471: Se0/0/0 LQM:    LastOutLQRs 70 LastOutPackets/Octets 194/9735
*Apr  1 16:15:17.471: Se0/0/0 LQM:    PeerInLQRs 70 PeerInPackets/Discards/Errors/Octets 0/0/0/0
*Apr  1 16:15:17.471: Se0/0/0 LQM:    PeerOutLQRs 71 PeerOutPackets/Octets 197/9839
*Apr  1 16:15:17.487: Se0/0/0 PPP: I pkt type 0xC025, datagramsize 52 link[ppp]
*Apr  1 16:15:17.487: Se0/0/0 LQM: I state Open magic 0xFE83D624 len 48
*Apr  1 16:15:17.487: Se0/0/0 LQM:    LastOutLQRs 71 LastOutPackets/Octets 197/9839
*Apr  1 16:15:17.487: Se0/0/0 LQM:    PeerInLQRs 71 PeerInPackets/Discards/Errors/Octets 0/0/0/0
*Apr  1 16:15:17.487: Se0/0/0 LQM:    PeerOutLQRs 71 PeerOutPackets/Octets 196/9809
*Apr  1 16:15:17.535: Se0/0/0 LCP: O ECHOREQ [Open] id 36 len 12 magic 0x1EFC37C3
*Apr  1 16:15:17.539: Se0/0/0 LCP-FS: I ECHOREP [Open] id 36 len 12 magic 0xFE83D624
*Apr  1 16:15:17.539: Se0/0/0 LCP-FS: Received id 36, sent id 36, line up
R1# undebug all

The debug ppp error command is used to display protocol errors and error statistics associated with PPP connection negotiation and operation, as shown in Example 3-7. These messages might appear when the Quality Protocol option is enabled on an interface that is already running PPP.

Example 3-7 Output of debug ppp error Command

 

R1# debug ppp error

PPP Serial3(i): rlqr receive failure. successes = 15
PPP: myrcvdiffp = 159 peerxmitdiffp = 41091
PPP: myrcvdiffo = 2183 peerxmitdiffo = 1714439
PPP: threshold = 25
PPP Serial4(i): rlqr transmit failure. successes = 15
PPP: myxmitdiffp = 41091 peerrcvdiffp = 159
PPP: myxmitdiffo = 1714439 peerrcvdiffo = 2183
PPP: l->OutLQRs = 1 LastOutLQRs = 1
PPP: threshold = 25
PPP Serial3(i): lqr_protrej() Stop sending LQRs.
PPP Serial3(i): The link appears to be looped back.
Troubleshooting a PPP Configuration with Authentication

Authentication is a feature that needs to be implemented correctly or the security of your serial connection may be compromised. Always verify your configuration with the show interfaces serial command, in the same way as you did without authentication.

Example 3-8 shows an example output of the debug ppp authentication command.

Example 3-8 Troubleshooting a PPP Configuration with Authentication
R2# debug ppp authentication

Serial0/0/0: Unable to authenticate. No name received from peer
Serial0/0/0: Unable to validate CHAP response. USERNAME pioneer not found.
Serial0/0/0: Unable to validate CHAP response. No password defined for USERNAME pio-
  neer
Serial0/0/0: Failed CHAP authentication with remote.
Remote message is Unknown name
Serial0/0/0: remote passed CHAP authentication.
Serial0/0/0: Passed CHAP authentication with remote.
Serial0/0/0: CHAP input code = 4 id = 3 len = 48

The following is an interpretation of the output:

Line 1 says that the router is unable to authenticate on interface Serial0/0/0 because the peer did not send a name.

Line 2 says the router was unable to validate the CHAP response because username pioneer was not found.

Line 3 says no password was found for pioneer. Other possible responses at this line might have been no name received to authenticate, unknown name, no secret for given name, short MD5 response received, or MD5 compare failed.

In the last line, the code 4 means that a failure has occurred. Other code values are as follows:

  • 1: Challenge.
  • 2: Response.
  • 3: Success.
  • 4: Failure.
  • id: 3 is the ID number per LCP packet format.
  • len: 48 is the packet length without the header.
Reference:

Understanding debug PPP negotiation output: http://www.cisco.com/c/en/us/support/docs/wan/point-to-point-protocol-ppp/25440-debug-ppp-negotiation.html?referring_site=bodynav

Troubleshooting PPP authentication: http://www.cisco.com/c/en/us/support/docs/wan/point-to-point-protocol-ppp/25646-ppp-authen-ts-fl.html