- Objectives
- Key Terms
- Introduction (3.0.1.1)
- Serial Point-to-Point Overview (3.1)
- PPP Operation (3.2)
- Configure PPP (3.3)
- Troubleshoot WAN Connectivity (3.4)
- Summary (3.5)
- Practice
- Check Your Understanding Questions
This chapter is from the book
This chapter is from the book
This chapter is from the book
Troubleshoot WAN Connectivity (3.4)
Troubleshooting is an important component to understanding and implementing any technology. This section discusses troubleshooting WAN connectivity, specifically point-to-point serial communications using PPP.
Troubleshoot PPP (3.4.1)
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 (3.4.1.1)
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 (3.4.1.2)
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
Example 3-6 displays the debug ppp negotiation command in a normal negotiation, where both sides agree on NCP parameters. In this case, protocol types IPv4 and IPv6 are proposed and acknowledged. The debug ppp negotiation command enables the network administrator to view the PPP negotiation transactions, identify the problem or stage when the error occurs, and develop a resolution. The output includes the LCP negotiation, authentication, and NCP negotiation.
Example 3-6 Output of debug ppp negotiation Command
R1# debug ppp negotiation PPP protocol negotiation debugging is on R1# *Apr 1 18:42:29.831: %LINK-3-UPDOWN: Interface Serial0/0/0, changed state to up *Apr 1 18:42:29.831: Se0/0/0 PPP: Sending cstate UP notification *Apr 1 18:42:29.831: Se0/0/0 PPP: Processing CstateUp message *Apr 1 18:42:29.835: PPP: Alloc Context [66A27824] *Apr 1 18:42:29.835: ppp2 PPP: Phase is ESTABLISHING *Apr 1 18:42:29.835: Se0/0/0 PPP: Using default call direction *Apr 1 18:42:29.835: Se0/0/0 PPP: Treating connection as a dedicated line *Apr 1 18:42:29.835: Se0/0/0 PPP: Session handle[4000002] Session id[2] *Apr 1 18:42:29.835: Se0/0/0 LCP: Event[OPEN] State[Initial to Starting] *Apr 1 18:42:29.835: Se0/0/0 LCP: O CONFREQ [Starting] id 1 len 23 *Apr 1 18:42:29.835: Se0/0/0 LCP: AuthProto CHAP (0x0305C22305) *Apr 1 18:42:29.835: Se0/0/0 LCP: QualityType 0xC025 period 1000 (0x0408C025000003E8) *Apr 1 18:42:29.835: Se0/0/0 LCP: MagicNumber 0x1F887DD3 (0x05061F887DD3) <Output omitted> *Apr 1 18:42:29.855: Se0/0/0 PPP: Phase is AUTHENTICATING, by both *Apr 1 18:42:29.855: Se0/0/0 CHAP: O CHALLENGE id 1 len 23 from “R1” <Output omitted> *Apr 1 18:42:29.871: Se0/0/0 IPCP: Authorizing CP *Apr 1 18:42:29.871: Se0/0/0 IPCP: CP stalled on event[Authorize CP] *Apr 1 18:42:29.871: Se0/0/0 IPCP: CP unstall <Output omitted> *Apr 1 18:42:29.875: Se0/0/0 CHAP: O SUCCESS id 1 len 4 *Apr 1 18:42:29.879: Se0/0/0 CHAP: I SUCCESS id 1 len 4 *Apr 1 18:42:29.879: Se0/0/0 PPP: Phase is UP *Apr 1 18:42:29.879: Se0/0/0 IPCP: Protocol configured, start CP. state[Initial] *Apr 1 18:42:29.879: Se0/0/0 IPCP: Event[OPEN] State[Initial to Starting] *Apr 1 18:42:29.879: Se0/0/0 IPCP: O CONFREQ [Starting] id 1 len 10 *Apr 1 18:42:29.879: Se0/0/0 IPCP: Address 10.0.1.1 (0x03060A000101) *Apr 1 18:42:29.879: Se0/0/0 IPCP: Event[UP] State[Starting to REQsent] *Apr 1 18:42:29.879: Se0/0/0 IPV6CP: Protocol configured, start CP. state[Initial] *Apr 1 18:42:29.883: Se0/0/0 IPV6CP: Event[OPEN] State[Initial to Starting] *Apr 1 18:42:29.883: Se0/0/0 IPV6CP: Authorizing CP *Apr 1 18:42:29.883: Se0/0/0 IPV6CP: CP stalled on event[Authorize CP] <Output omitted> *Apr 1 18:42:29.919: Se0/0/0 IPCP: State is Open *Apr 1 18:42:29.919: Se0/0/0 IPV6CP: State is Open *Apr 1 18:42:29.919: Se0/0/0 CDPCP: State is Open *Apr 1 18:42:29.923: Se0/0/0 CCP: State is Open *Apr 1 18:42:29.927: Se0/0/0 Added to neighbor route AVL tree: topoid 0, address 10.0.1.2 *Apr 1 18:42:29.927: Se0/0/0 IPCP: Install route to 10.0.1.2 *Apr 1 18:42:39.871: Se0/0/0 LQM: O state Open magic 0x1F887DD3 len 48 *Apr 1 18:42:39.871: Se0/0/0 LQM: LastOutLQRs 0 LastOutPackets/Octets 0/0 *Apr 1 18:42:39.871: Se0/0/0 LQM: PeerInLQRs 0 PeerInPackets/Discards/Errors/ Octets 0/0/0/0 *Apr 1 18:42:39.871: Se0/0/0 LQM: PeerOutLQRs 1 PeerOutPackets/Octets 3907/155488 *Apr 1 18:42:39.879: Se0/0/0 LQM: I state Open magic 0xFF101A5B len 48 *Apr 1 18:42:39.879: Se0/0/0 LQM: LastOutLQRs 0 LastOutPackets/Octets 0/0 *Apr 1 18:42:39.879: Se0/0/0 LQM: PeerInLQRs 0 PeerInPackets/Discards/Errors/ Octets 0/0/0/0 *Apr 1 18:42:39.879: Se0/0/0 LQM: PeerOutLQRs 1 PeerOutPackets/Octets 3909/155225 <Output omitted>
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 (3.4.1.3)
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.
Packet Tracer Activity 3.4.1.4: Troubleshooting PPP with Authentication
Background/Scenario
The routers at your company were configured by an inexperienced network engineer. Several errors in the configuration have resulted in connectivity issues. Your boss has asked you to troubleshoot and correct the configuration errors and document your work. Using your knowledge of PPP and standard testing methods, find and correct the errors. Make sure that all of the serial links use PPP CHAP authentication, and that all of the networks are reachable. The passwords are cisco and class.
Lab 3.4.1.5: Troubleshooting Basic PPP with Authentication
In this lab, you will complete the following objectives:
Part 1: Build the Network and Load Device Configurations
Part 2: Troubleshoot the Data Link Layer
Part 3: Troubleshoot the Network Layer