Debugging PPP

[no] debug ppp {packet | negotiation | error | authentication | compression | cbcp}

packet

Causes the debug ppp command to display PPP packets being sent and received. (This command displays low-level packet dumps.)

negotiation

Causes the debug ppp command to display PPP packets transmitted during PPP startup, where PPP options are negotiated

error

Causes the debug ppp command to display protocol errors and error statistics associated with PPP connection negotiation and operation.

authentication

Causes the debug ppp command to display authentication protocol messages, including Challenge Authentication Protocol (CHAP) packet exchanges and Password Authentication Protocol (PAP) exchanges.

compression

Causes the debug ppp command to display 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

Causes the debug ppp command to display protocol errors and statistics associated with PPP connection negotiations using MSCB.

© 2001, Cisco Systems, Inc. All rights reserved. Cisco CCIE Prep v1.0—Module 3-88

© 2001, Cisco Systems, Inc. All rights reserved. Cisco CCIE Prep v1.0—Module 3-88

Use the debug ppp EXEC command to display information on traffic and exchanges in an internetwork implementing the Point-to-Point Protocol (PPP). The no form of this command disables debugging output.

Usage Guidelines

Use the debug ppp commands when trying to find the following:

■ The Network Control Protocols (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 sc-0 .com sc-0 .com ppp ppp ppp ppp sending CONFREQ, type = 4 (CI_QUALITYTYPE), value = C025/3E8 sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = 3D56CAC received config for type = 4 (QUALITYTYPE) acked received config for type = 5 (MAGICNUMBER) value = 3D567F8 acked (ok)

PPP Bri0/0 s state = ACKSENT fsm_rconfack(C021)s rcvd id 5

ppps config ACK received, type = 4 (CI_QUALITYTYPE), value = C025

ppps config ACK received, type = 5 (CI_MAGICNUMBER), value = 3D56CAC ppps ipcp_reqcis returning CONFACK.

PPP Bri0/0 s state = ACKSENT fsm_rconfack(8021)s rcvd id 4

• Determines if a client is passing the PPP negotiation phase

Cisco CCIE Prep v1.0—Module 3-8!

rights reser^

Use the debug ppp negotiation command to see if a client is passing PPP negotiation. This command is useful for verifying address negotiation.

The sample output shown is from the debug ppp negotiation command. This is a normal negotiation, where both sides agree on Network Control Program (NCP) parameters. In this case, protocol type IP is proposed and acknowledged.

The following table describes significant fields in the output. Table 3-5: Interpreting debug ppp negotiation Output

debug ppp negotiation Field Descriptions

Description

PPP

This is PPP debugging output.

sending CONFREQ

The router sent a configuration request.

type = 4 (CI_QUALITYTYPE)

The type of LCP configuration option that is being negotiated and a descriptor. A type value of 4 indicates Quality Protocol negotiation; a type value of 5 indicates Magic Number negotiation.

value = C025/3E8

For Quality Protocol negotiation, indicates NCP type and reporting period. In the example, C025 indicates LQM; 3E8 is a hexadecimal value translating to about 10 seconds (in hundredths of a second).

value = 3D56CAC

For Magic Number negotiation, indicates the Magic Number being negotiated.

received config

The receiving node has received the proposed option negotiation for the indicated option type.

acked

Acknowledgment and acceptance of options.

state = ACKSENT

Specific PPP state in the negotiation process.

debug ppp negotiation Field Descriptions

Description

ipcp reqci

IPCP notification message; sending CONFACK.

fsm rconfack (8021)

The procedure fsm rconfack processes received CONFACKs, and the protocol (8021) is IP.

The following two lines of syntax indicate that the router is trying to bring up LCP and will use the indicated negotiation options (Quality Protocol and Magic Number). The value fields are the values of the options themselves. C025/3E8 translates to Quality Protocol LQM. 3E8 is the reporting period (in hundredths of a second). 3D56CAC is the value of the Magic Number for the router.

ppp: sending CONFREQ, type = 4 (CI_QUALITYTYPE), value = C025/3E8 ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = 3D56CAC

The next two lines indicate that the other side negotiated for options 4 and 5 as requested and acknowledged both. If the responding end does not support the options, a CONFREJ is sent by the responding node. If the responding end does not accept the value of the option, a CONFNAK is sent with the value field modified.

ppp: received config for type = 4 (QUALITYTYPE) acked ppp: received config for type = 5 (MAGICNUMBER) value = 3D567F8 acked (ok)

The next three lines indicate that the router received a CONFACK from the responding side and displays accepted option values. Use the rcvd id field to verify that the CONFREQ and CONFACK have the same id field.

PPP Bri0/0: state = ACKSENT fsm_rconfack(C021): rcvd id 5

ppp: config ACK received, type = 4 (CI_QUALITYTYPE), value = C025

ppp: config ACK received, type = 5 (CI_MAGICNUMBER), value = 3D5 6CAC

The next line indicates that the router has IP routing enabled on this interface and that the IPCP NCP negotiated successfully:

ppp: ipcp_reqci: returning CONFACK.

In the last line, the router's state is listed as ACKSENT. PPP Bri0/0: state = ACKSENT fsm_rconfack(C021): rcvd id 5\

BriO/O BriO/O BriO/O BriO/O

Unable to authenticate. No name received from peer

Unable to validate CHAP response. USERNAME pioneer not found.

Unable to validate CHAP response. No password defined for USERNAME pioneer

Failed CHAP authentication with remote.

Remote message is Unknown :

BriO/O BriO/O BriO/O

remote passed CHAP authentication. Passed CHAP authentication with remote. CHAP input code = 4 id = 3 len = 48

Monitors PPP authentication process

Cisco CCIE Prep v1.0—Module 3-91

rights reserv

Shown here is sample output from the debug ppp authentication command. Use this command to determine why authentication is failing between two peer routers.

In general, these messages are self-explanatory. Fields that can show optional output are outlined in the following table.

Table 3-6: Interpreting debug ppp authentication Output

debug ppp authentication Field Descriptions Field

Description

BriO/O

Interface number associated with this debugging information and CHAP access session in question

USERNAME pioneer not found.

The name pioneer in this example is the name received in the CHAP response. The router looks up this name in the list of usernames that are configured for the router

Remote message is Unknown name

The following messages can appear: No name received to authenticate Unknown name No secret for given name Short MD5 response received MD compare failed

debug ppp authentication Field Descriptions Field

Description

code = 4

Specific CHAP type packet detected. Possible values are as follows:

1 = Challenge

2 = Response

3 = Success

4 = Failure

0 0

Post a comment