PPP Troubleshooting Flowchart
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Contents
Introduction
This flowchart helps you to troubleshoot Point-to-Point Protocol (PPP), which is widely used for multiple Access technology solutions.
In the flowcharts and sample output shown below, we have set up an Integrated Services Digital Network (ISDN) basic rate interface (BRI) PPP connection to another using Legacy Dialer-on-Demand Routing (DDR). However, the same troubleshooting steps apply to connections to other routers (such as branch offices) with PPP connections when using Dialer Rotary-Group, Dialer Profile, or PPP over serial links.
For further information on Point-to-Point Protocol, and its supported features in Cisco IOS® software, refer to Cisco Learning Connection (registered customers only) and search using the keyword ppp in the Search for training field.
For a detailed explanation of the different phases of PPP negotiation and the output of debug ppp negotiation, refer to Configuring and Troubleshooting PPP Password Authentication Protocol (PAP).
Prerequisites
Requirements
Make sure you meet these prerequisites:
Enable debug ppp negotiation and debug ppp authentication.
You must read and understand the debug ppp negotiation output. Refer to Understanding debug ppp negotiation Output for more information.
The PPP authentication phase does not begin until the Link Control Protocol (LCP) phase is complete and is in "open" state. If debug ppp negotiation does not indicate that LCP is open, troubleshoot this issue before you proceed.
Components Used
This document is not restricted to specific software and hardware versions.
Terminology
Local machine (or local router): This is the system the debugging session is currently being run on. As you move the debug session from one router to the other, apply the term "local machine" to the other router.
Peer: The other end of the point-to-point link. Therefore, this device is not the local machine.
For example, if you run the debug ppp negotiation command on RouterA, this is the local machine, and RouterB is the peer. However, if you shift the debugging over to RouterB, then it becomes the local machine and RouterA becomes the peer.
Note: The terms local machine and peer do not imply a client-server relationship. Depending on where the debug session is run, the dialin client could be the local machine or peer.
Conventions
Refer to Cisco Technical Tips Conventions for more information on document conventions.
Troubleshooting Flowcharts
This document includes some flowcharts to assist in troubleshooting.
Note: In order to troubleshoot successfully, do not skip any of the steps shown in these flowcharts.
PPP Link Control Protocol (LCP) Phase
Asynchronous Modems used for PPP Connectivity
This section explains how Asynchronous Modems can be used for PPP connectivity. Outgoing LCP frames are seen on the local router, but there are no incoming LCP frames.
In this case, the problem could be due to one of two possibilities:
The modems of both the local router and the remote router train up, but PPP does not start on the remote router. To troubleshoot this problem, refer to the Modems do train up okay, but PPP does not start section in the Troubleshooting Modems document.
The modems of both the local and remote routers do train up okay, and PPP starts on both routers, but the call immediately drops. This destroys any chance of receiving incoming LCP frames from remote routers. To troubleshoot this problem, refer to the Modems do train up okay, PPP starts, but the call later drops section in the Troubleshooting Modems document.
For more detailed information on modem troubleshooting, refer to Troubleshooting Modems.
PPP Outgoing LCP Options
The flowchart below highlights several of the most common PPP LCP parameters that can be negotiated during the LCP phase. This flowchart helps you to locate which LCP parameters your PPP local machine is not negotiating with the PPP remote peer.
PPP Authentication Phase
Point-to-Point Protocol provides an optional phase which guarantees the network user a secured data transmission to enhance network security. On some links it may be desirable to require a PPP peer to authenticate itself before allowing network-layer protocol packets to be exchanged. For any PPP implementation, the authentication phase is optional by default. If a PPP network administrator wants the PPP peer to use a specific authentication protocol, he must request the use of that authentication protocol during the PPP LCP phase. That is, the authentication protocol used must be one of the negotiated PPP LCP options between both PPP peers.
At this stage, only PPP LCP, authentication protocol, and link quality monitoring packets are allowed during authentication phase. Ensure that there are no problems at this stage with any PPP LCP-negotiated parameters before following the troubleshooting steps in this section.
For detailed troubleshooting information for PPP authentication phase problems, refer to the Troubleshooting PPP (CHAP or PAP) Authentication flowchart.
PPP NCP Negotiations
While different Network Control Protocols (NCPs) vary greatly in the data being negotiated, the overall structure of the conversation is similar no matter what protocols are being used. This section only covers IP (IPCP) NCP protocol negotiation.
The output below shows the debug output for a successful IP negotiation during PPP NCP negotiation:
IPCP Does Not go Into Open State in NCP Negotiation Phase
PPP Link Stability Problems
As stated in the flowchart below, at this point, the link is up and passing packets, but it is not behaving as it should.
Cannot Route Packets Over an IP PPP Link
The output below shows the show caller user and show ip interface brief command output when a call is terminated successfully and IP packets can be sent to the remote peer over the PPP connection.
Debugging PPP
Causes the debug ppp command to display protocol errors and error statistics associated with PPP connection negotiation and operation.
Causes the debug ppp command to display authentication protocol messages, including Challenge Authentication Protocol (CHAP) packet exchanges and Password Authentication Protocol (PAP) exchanges.
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.
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.
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!
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
This is PPP debugging output.
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.
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).
For Magic Number negotiation, indicates the Magic Number being negotiated.
The receiving node has received the proposed option negotiation for the indicated option type.
Acknowledgment and acceptance of options.
Specific PPP state in the negotiation process.
debug ppp negotiation Field Descriptions
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
Remote message is Unknown :
BriO/O BriO/O BriO/O
remote passed CHAP authentication. Passed CHAP authentication with remote. CHAP input code = 4 len = 48
Monitors PPP authentication process
Cisco CCIE Prep v1.0—Module 3-91
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.
debug ppp authentication Field Descriptions Field
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
Networking Bodges
There are are essentially a handful of stages involved in bringing up a PPPoE client session on a Cisco router, each of which could fail for a distinct set of reasons. This guide takes a walk through the entire process, step by step, highlighting the most common causes of problems at each stage.
Routing
Even though PPP itself is peer to peer, PPPoE is inherently client-server. That means that the connection has to be originated by the client and, in most cases, the client will only do that when it has some traffic to send over PPPoE. Therefore, the router must know the dialer as its next hop interface for some destination, i.e. it must have a route. It sounds trivial but it’s surprising how often people go to all the trouble of putting in a perfectly good PPPoE config, then forget to put a default route in for the traffic!
More broadly, though, there are other things that could stop a route from being installed. For example, if you configure a dialer as a backup interface to another interface then there are some gotchas. Shutting down the primary will usually not enable its backup, also you still need a (static) route pointing traffic towards the dialer in order to make it dial — a step which is often forgotten. It’s usually best to remove the backup interface configuration while testing the dialer, then re-apply it when that has been proven to work.
Dialer
Once traffic hits the dialer interface, the router will only attempt to bring up a PPPoE session if its dialer becomes activated. If a route exists but the dialer is not trying to connect then enable dialer debugging as follows:
Client#debug dialer packet
Dial on demand packets debugging is on
Client#debug dialer event
Dial on demand events debugging is on
Now generate some traffic that should bring up the link, for example by sending a ping:
Client#ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
*Nov 5 21:44:34.147: Di0 DDR: ip (s=10.10.10.10, d=8.8.8.8), 100 bytes, outgoing interesting (ip PERMIT)
*Nov 5 21:44:34.151: Di0 DDR: Cannot place call, no dialer string set.
*Nov 5 21:44:41.491: %DIALER-6-BIND: Interface Vi2 bound to profile Di0
*Nov 5 21:44:41.503: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to up
*Nov 5 21:44:41.503: Vi2 DDR: Dialer statechange to up
Client#
*Nov 5 21:44:42.195: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to up
Client#
*Nov 5 21:44:42.371: Vi2 DDR: dialer protocol up
- If no debug messages are generated at all:
- Verify that traffic is being routed towards the dialer interface
- Verify that the dialer-list is configured correctly and referenced by the dialer
- Verify that the dialer’s encapsulation is configured to ppp
- Appears to be spurious, no dialer string is required for PPPoE and it dials anyway
- Exactly what it says — dialer is not associated with a dialer list. Ensure a dialer-list is configured and is referred to by the dialer with the » dialer-group x » command.
- Again, exactly what it says. The dialer is associated with a non-existent dialer-list. Either re-point the dialer using the » dialer-group x » command or create a new dialer-list with the appropriate number.
- Repeated interesting traffic lines but no dialling can occur if the dialer references an empty dialer pool — ensure your PPPoE interface is configured with both «pppoe enable» and «pppoe-client dial-pool-number x» . Also ensure that the interface is admin up.
- Could also be due to PPPoE discovery phase failing, see below.
PPPoE Discovery
In order to bring up a PPP session over Ethernet, a PPPoE session must be set up to create a point-to-point connection over a broadcast Ethernet network. This is established using PPPoE Auto-Discovery, where the PPPoE client (our router) searches for a PPPoE access concentrator which is willing to terminate its connection. This phase should operate as follows:
PPPoE Discovery Phase The client sends a PPPoE Auto Discovery Initiate (PADI) frame, asking any available access concentrators to make themselves known. The access concentrator(s) then respond(s) with a PADO (offer) frame to indicate its availability. The client then sends a PADR (request) frame to its chosen access concentrator which, all being well, will respond with a PADS (session) message to indicate that the PPPoE session is now up. At any time either device may issue a PADT to close the PPPoE session.
To see what is happening at this stage, run the following command:
Client#debug pppoe packet
*Nov 5 20:38:52.107: pppoe_send_ padi :
contiguous pak, size 60
FF FF FF FF FF FF 00 01 02 03 04 05 88 63 11 09
00 00 00 10 01 01 00 00 01 03 00 08 2A 00 00 01
00 00 06 CD 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00
*Nov 5 20:38:52.143: PPPoE 0: I PADO R:0011.2233.4455 L:0001.0203.0405 Fa0/0
contiguous pak, size 66
00 01 02 03 04 05 00 11 22 33 44 55 88 63 11 07
00 00 00 2E 01 01 00 00 01 03 00 08 2A 00 00 01
00 00 06 CD 01 02 00 06 4C 61 62 2D 41 43 01 04
00 10 D5 60 38 B8 05 81 B6 69 29 1B 5E 82 77 A0
5E 91
*Nov 5 20:38:54.155: OUT PADR from PPPoE Session
contiguous pak, size 66
00 11 22 33 44 55 00 01 02 03 04 05 88 63 11 19
00 00 00 2E 01 03 00 08 2A 00 00 01 00 00 06 CD
01 02 00 06 4C 61 62 2D 41 43 01 04 00 10 D5 60
38 B8 05 81 B6 69 29 1B 5E 82 77 A0 5E 91 01 01
00 00
*Nov 5 20:38:54.355: PPPoE 14: I PADS R:0011.2233.4455 L:0001.0203.0405 Fa0/0
contiguous pak, size 66
00 01 02 03 04 05 00 11 22 33 44 55 88 63 11 65
00 0E 00 2E 01 03 00 08 2A 00 00 01 00 00 06 CD
01 02 00 06 4C 61 62 2D 41 43 01 04 00 10 D5 60
38 B8 05 81 B6 69 29 1B 5E 82 77 A0 5E 91 01 01
00 00
*Nov 5 20:38:54.363: [0]PPPoE 0: O PADT R:0000.0000.0000 L:0000.0000.0000 Fa0/0
contiguous pak, size 60
00 00 00 00 00 00 00 01 02 03 04 05 88 63 11 A7
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00The mark of a successful PPPoE Discovery phase is that a PADS packet is received — at this point the PPPoE session is up and troubleshooting focus should shift to the PPP stage.
- Only PADI seen:
- Layer 1 or 2 issue between client and server
- PPPoE traffic being filtered between client and server, max sessions per MAC exceeded
- Sometimes possible even if interface is admin down!
- Restrictions on Access Concentrator (e.g. max sessions per MAC exceeded)
- Generally a problem further up the stack, continue troubleshooting
PPP Negotiation (LCP)
With the PPPoE session up, Link Control Protocol (LCP) will attempt to negotiate the parameters for the actual PPP session. These include useful parameters such as the MRU and authentication type, plus potentially many less applicable parameters such as callback, compression or PPP multilink.
The process is that each side will send proposals (CONFiguration REQuests or CONFREQs) to the other indicating its preferred settings. The opposite device can then respond in one of the following ways:
- Send a CONFiguration ACKnowledgement (CONFACK) to indicate agreement to the proposal
- Send a CONFiguration Negative AcKnowledgement (CONFNAK) to indicate a particular setting should be changed and providing a suggested alternative value. If multiple values need to change, there will be multiple CONFNAKs.
- Send a CONFiguration REJect (CONFREJ) to indicate that either the type or the value of the parameter proposed is completely unacceptable.
Only once all the parameters are agreed between the two peers can the connection be established and higher layer protocols be negotiated. Bear in mind that PPP is inherently peer to peer, so both sides will play the roles of both requester and approver / rejecter.
To see what is happening at this stage, run the following command:
Client#debug ppp negotiation
PPP protocol negotiation debugging is on
*Nov 5 22:11:39.191: %DIALER-6-BIND: Interface Vi2 bound to profile Di0
*Nov 5 22:11:39.207: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to up
*Nov 5 22:11:39.211: Vi2 PPP: Sending cstate UP notification
*Nov 5 22:11:39.219: Vi2 PPP: Processing CstateUp message
*Nov 5 22:11:39.251: PPP: Alloc Context [670153F8]
*Nov 5 22:11:39.255: ppp22 PPP: Phase is ESTABLISHING
*Nov 5 22:11:39.259: Vi2 PPP: Using dialer call direction
*Nov 5 22:11:39.259: Vi2 PPP: Treating connection as a callout
*Nov 5 22:11:39.263: Vi2 PPP: Session handle[F4000016] Session id[22]
*Nov 5 22:11:39.263: Vi2 LCP: Event[OPEN] State[Initial to Starting]
*Nov 5 22:11:39.267: Vi2 PPP: No remote authentication for call-out
*Nov 5 22:11:39.267: Vi2 LCP: O CONFREQ [Starting] id 1 len 10
*Nov 5 22:11:39.271: Vi2 LCP: MagicNumber 0x03BD43E3 (0x050603BD43E3)
*Nov 5 22:11:39.271: Vi2 LCP: Event[UP] State[Start ing to REQsent]
*Nov 5 22:11:39.323: Vi2 LCP: I CONFREQ [REQsent] id 1 len 19
*Nov 5 22:11:39.323: Vi2 LCP: MRU 1492 (0x010405D4)
*Nov 5 22:11:39.327: Vi2 LCP: AuthProto CHAP (0x0305C22305)
*Nov 5 22:11:39.327: Vi2 LCP: MagicNumber 0x02C2DFB3 (0x050602C2DFB3)
*Nov 5 22:11:39.331: Vi2 LCP: O CONFNAK [REQsent] id 1 len 8
*Nov 5 22:11:39.331: Vi2 LCP: MRU 1500 (0x010405DC)
*Nov 5 22:11:39.335: Vi2 LCP: Event[Receive ConfReq-] State[REQsent to REQsent]
*Nov 5 22:11:39.395: Vi2 LCP: I CONFACK [REQsent] id 1 len 10
*Nov 5 22:11:39.395: Vi2 LCP: MagicNumber 0x03BD43E3 (0x050603BD43E3)
*Nov 5 22:11:39.399: Vi2 LCP: Event[Receive ConfAck] State[REQsent to ACKrcvd]
*Nov 5 22:11:39.439: Vi2 LCP: I CONFREQ [ACKrcvd] id 2 len 19
*Nov 5 22:11:39.439: Vi2 LCP: MRU 1500 (0x010405DC)
*Nov 5 22:11:39.443: Vi2 LCP: AuthProto CHAP (0x0305C22305)
*Nov 5 22:11:39.443: Vi2 LCP: MagicNumber 0x02C2DFB3 (0x050602C2DFB3)
*Nov 5 22:11:39.447: Vi2 LCP: O CONFA CK [ACKrcvd] id 2 len 19
*Nov 5 22:11:39.447: Vi2 LCP: MRU 1500 (0x010405DC)
*Nov 5 22:11:39.451: Vi2 LCP: AuthProto CHAP (0x0305C22305)
*Nov 5 22:11:39.451: Vi2 LCP: MagicNumber 0x02C2DFB3 (0x050602C2DFB3)
*Nov 5 22:11:39.455: Vi2 LCP: Event[Receive ConfReq+] State[ACKrcvd to Open ]
*Nov 5 22:11:39.467: Vi2 PPP: Phase is AUTHENTICATING, by the peer
*Nov 5 22:11:39.467: Vi2 LCP: State is Open
Client#To explain the above transaction, I have highlighted the two conversations in different colours. «O» indicates an outbound frame, «I» an inbound frame.
The blue conversation is what we (the client) are proposing to the access concentrator. The client sends an essentially empty proposal with only a magic number (used for loop detection). The access concentrator responds with an acknowledgement, after all there’s nothing to argue about!
The red conversation (where the access concentrator is proposing settings) is slightly more interesting. The first proposal contains a proposed maximum receive unit (MRU) size of 1492 and a proposal to use CHAP authentication. In the next frame our client sends a NAK message to indicate it would prefer the access concentrator used an MRU of 1500. Following that, the access concentrator sends a new proposal with an MRU of 1500 and CHAP authentication, which our client then acknowledges.
Now that both sides are in agreement, the state changes to «Open», which is PPP talk for «up».
- MRU mismatch — many access concentrators are strictly RFC 2516 compliant and allow a maximum MRU of 1492. This is because 1492 bytes IP + 6 bytes PPPoE + 2 bytes PPP is the largest that can fit inside a standard 1500 byte Ethernet payload. It may be necessary to tweak the MTU on the Ethernet interface using the «pppoe-client ppp-max-payload xxxx» command.
- Authentication type mismatch — if one peer is set for CHAP only while the other is set to PAP only or no authentication, they are not going to talk. A common mistake is forgetting the authentication callin option, which means that the client asks the server to authenticate itself — this is almost invariably not.
PPP Authentication
PPP has the ability to authenticate either, both or neither of the peers. In a typical deployment, the access concentrator will require the client to authenticate, but will refuse to authenticate itself to the client. This is typically done using CHAP as in the example below (output from «debug ppp negotiation» ):
*Nov 5 22:11:39.259: Vi2 PPP: Treating connection as a callout
*Nov 5 22:11:39.263: Vi2 PPP: Session handle[F4000016] Session id[22]
*Nov 5 22:11:39.263: Vi2 LCP: Event[OPEN] State[Initial to Starting]
*Nov 5 22:11:39.267: Vi2 PPP: No remote authentication for call-out
— SNIP —
*Nov 5 22:11:39.467: Vi2 PPP: Phase is AUTHENTICATING, by the peer
*Nov 5 22:11:39.527: Vi2 CHAP: I CHALLENGE id 1 len 27 from «Lab-AC»
*Nov 5 22:11:39.543: Vi2 CHAP: Using hostname from interface CHAP
*Nov 5 22:11:39.543: Vi2 CHAP: Using password from interface CHAP
*Nov 5 22:11:39.543: Vi2 CHAP: O RESPONSE id 1 len 30 from «pppoeuser»
*Nov 5 22:11:39.835: Vi2 CHAP: I SUCCESS id 1 len 4
*Nov 5 22:11:39.839: Vi2 PPP: Phase is FORWARDING, Attempting ForwardThe output clearly shows that this connection is considered to be a «callout», i.e. we are the initiating party. Next, the debug informs us that we do not require the remote party to authenticate.
Following that, the peer (the access concentrator) asks us to authenticate. It sends us a «CHALLENGE», we send a «RESPONSE», then it sends us a «SUCCESS» message, indicating that our credentials were accepted.
All Cisco-Network Study Notes
works, including LCP and the higher protocols. The higher protocols consist of IPCP (IP) and
CDPCP (CDP), among others.
The following output shows the messages that might appear when using the debug ppp
negotiation command:Router#debug ppp negotiation
PPP protocol negotiation debugging is on
Router#ping 10.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
00:22:28: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
00:22:28: BR0:1 PPP: Treating connection as a callout
00:22:28: BR0:1 PPP: Phase is ESTABLISHING, Active Open
00:22:28: BR0:1 LCP: O CONFREQ [Closed] id 3 len 10
00:22:28: BR0:1 LCP: MagicNumber 0x50239604
(0x050650239604)
00:22:28: BR0:1 LCP: I CONFREQ [REQsent] id 13 len 10
00:22:28: BR0:1 LCP: MagicNumber 0x5023961F
(0x05065023961F)
00:22:28: BR0:1 LCP: O CONFACK [REQsent] id 13 len 10
00:22:28: BR0:1 LCP: MagicNumber 0x5.023961F
(0x05065023961F)
00:22:28: BR0:1 LCP: I CONFACK [ACKsent] id 3 len 10
00:22:28: BR0:1 LCP: MagicNumber 0x50239604
(0x050650239604)
00:22:28: BR0:1 LCP: State is Open
00:22:28: BR0:1 PPP: Phase is UP
00:22:28: BR0:1 CDPCP: O CONFREQ [Closed] id 3 len 4
00:22:28: BR0:1 IPCP: O CONFREQ [Closed] id 3 len 10
00:22:28: BR0:1 IPCP: Address 10.1.1.2 (0x03060A010102)
00:22:28: BR0:1 CDPCP: I CONFREQ [REQsent] id 3 len 4
00:22:28: BR0:1 CDPCP: O CONFACK [REQsent] id 3 len 4
00:22:28: BR0:1 IPCP: I CONFREQ [REQsent] id 3 len 10
00:22:28: BR0:1 IPCP: Address 10.1.1.1 (0x03060A010101)
00:22:28: BR0:1 IPCP: O CONFACK [REQsent] id 3 len 10
00:22:28: BR0:1 IPCP: Address 10.1.1.1 (0x03060A010101)
00:22:28: BR0:1 CDPCP: I CONFACK [ACKsent] id 3 len 4
00:22:28: BR0:1 CDPCP: State is Open
00:22:28: BR0:1 IPCP: I CONFACK [ACKsent] id 3 len 10
00:22:28: BR0:1 IPCP: Address 10.1.1.2 (0x03060A010102)
00:22:28: BR0:1 IPCP: State is Open
00:22:28: BR0 IPCP: Install route to 10.1.1.1Router#.
Success rate is 60 percent (3/5), round-trip min/avg/max = 32/38/48 ms
00:22:29: %LINEPROTO-5-UPDOWN: Line protocol on Interface
BRI0:1, changed state to up
00:22:29: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up
00:22:29: BR0:2 PPP: Treating connection as a callin
00:22:29: BR0:2 PPP: Phase is ESTABLISHING, Passive Open
00:22:29: BR0:2 LCP: State is Listen
00:22:30: BR0:2 LCP: I CONFREQ [Listen] id 3 len 10
00:22:30: BR0:2 LCP: MagicNumber 0x50239CC8
(0x050650239CC8)
00:22:30: BR0:2 LCP: O CONFREQ [Listen] id 3 len 10
00:22:30: BR0:2 LCP: MagicNumber 0x50239CDA
(0x050650239CDA)
00:22:30: BR0:2 LCP: O CONFACK [Listen] id 3 len 10
00:22:30: BR0:2 LCP: MagicNumber 0x50239CC8
(0x050650239CC8)
00:22:30: BR0:2 LCP: I CONFACK [ACKsent] id 3 len 10
00:22:30: BR0:2 LCP: MagicNumber 0x50239CDA
(0x050650239CDA) 00:22:30: BR0:2 LCP: State is Open
00:22:30: BR0:2 PPP: Phase is UP
00:22:30: BR0:2 CDPCP: O CONFREQ [Closed] id 3 len 4
00:22:30: BR0:2 IPCP: O CONFREQ [Closed] id 3 len 10
00:22:30: BR0:2 IPCP: Address 10.1.1.2 (0x03060A010102)
00:22:30: BR0:2 CDPCP: I CONFREQ [REQsent] id 3 len 4
00:22:30: BR0:2 CDPCP: O CONFACK [REQsent] id 3 len 4
00:22:30: BR0:2 IPCP: I CONFREQ [REQsent] id 3 len 10
00:22:30: BR0:2 IPCP: Address 10.1.1.1 (0x03060A010101)
00:22:30: BR0:2 IPCP: O CONFACK [REQsent] id 3 len 10
00:22:30: BR0:2 IPCP: Address 10.1.1.1 (0x03060A010101)
00:22:30: BR0:2 CDPCP: I CONFACK [ACKsent] id 3 len 4
00:22:30: BR0:2 CDPCP: State is Open
00:22:30: BR0:2 IPCP: I CONFACK [ACKsent] id 3 len 10
00:22:30: BR0:2 IPCP: Address 10.1.1.2 (0x03060A010102)
00:22:30: BR0:2 IPCP: State is Open
00:22:31: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:2, changed state
to up
00:22:32: BR0:1 LCP: O ECHOREQ [Open] id 12 len 12 magic
0x5020C645
00:22:32: BR0:1 LCP: echo_cnt 1, sent id 12, line up
00:22:32: BR0:1 PPP: I pkt type 0xC021, datagramsize 16
00:22:32: BR0:1 LCP: I ECHOREP [Open] id 12 len 12 magic0x5020C654
00:22:32: BR0:1 LCP: Received id 12, sent id 12, line up
00:22:32: BR0:2 LCP: O ECHOREQ [Open] id 12 len 12 magic
0x5020CD1B
00:22:32: BR0:2 LCP: echo_cnt 1, sent id 12, line up
00:22:32: BR0:2 PPP: I pkt type 0xC021, datagramsize 16
00:22:32: BR0:2 LCP: I ECHOREP [Open] id 12 len 12 magic
0x5020CD0D
00:22:32: BR0:2 LCP: Received id 12, sent id 12, line up
00:22:33: BR0:1 PPP: I pkt type 0xC021, datagramsize 16
00:22:33: BR0:1 LCP: I ECHOREQ [Open] id 12 len 12 magic
0x5020C654
00:22:33: BR0:1 LCP: O ECHOREP [Open] id 12 len 12 magic
0x5020C64500:21:23: BR0:2 PPP: I pkt type 0xC021, datagramsize 16
00:22:33: BR0:2 LCP: I ECHOREQ [Open] id 12 len 12 magic
0x5020CD0D
00:22:33: BR0:2 LCP: O ECHOREP [Open] id 12 len 12 magic
0x5020CD1B
00:22:34: BR0:2 PPP: I pkt type 0x0207, datagramsize 15
00:22:35: BR0:2 PPP: I pkt type 0x0207, datagramsize 312
00:24:28: %ISDN-6-DISCONNECT: Interface BRI0:1 disconnected
from 18008358661 To p, call lasted 120 seconds
00:24:28: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
00:24:10: %ISDN-6-DISCONNECT: Interface BRI0:2 disconnected from 8358663, call
lasted 120 seconds
00:24:28: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down
00:24:29: %LINEPROTO-5-UPDOWN: Line protocol on Interface
BRI0:1, changed state to down
00:24:29: %LINEPROTO-5-UPDOWN: Line protocol on Interface
BRI0:2, changed state to down
Notice that in this output, the first two ICMP packets (pings) failed due to the delay in bringing
up the ISDN BRI. Although faster than asynchronous connections, ISDN still introduces connection
delay, which can impact user applications. In addition, the output from the debug ppp
negotiation command shows the process by which a PPP session is activated.
This output does not use CHAP, compression, or multilink. Instead, as you can see, PPP
starts and then LCP is activated. After this occurs, the NCP negotiations begin, starting with
CDPCP and followed by IPCP. Cisco Discovery Protocol (CDP) is a proprietary advertisement
protocol that sends router and switch information between Cisco devices. It operates over any
physical media that supports Subnetwork Access Protocol (SNAP) (except ATM) and is independent
of IP. The IP Control Protocol (IPCP) was started to transport the ICMP pings that
were sent from the router.Remember that PPP sessions must undergo a negotiation process and that the debug ppp
negotiation command will display upper level protocols such as IPCP, along with LCP and PPP.