PPP Negotiation
The Point-to-Point Protocol (PPP) is key to the success of the connectivity for DSL. If the ATM configuration and encapsulation have been found to be properly configured and trained, the PPP connectivity is the next item on the troubleshooting list. PPP connections go through three distinct phases during negotiation:
■ Link Control Protocol (LCP) phase—Parameters related to establishing, configuring, and testing the connection are negotiated. This phase is mandatory.
■ Authentication phase—User authentication is performed according to the methodology negotiated in the LCP phase. This phase is optional.
■ Network Control Protocol (NCP) phase—Network layer protocol negotiation is performed to set up individual control protocols for each Layer 3 protocol to be transported. This phase is mandatory.
The most useful commands in monitoring these phases include debug ppp negotiation and debug ppp authentication. In the output in Example 7-7, both commands are used in tandem for a more complete picture.
Example 7-7 Monitoring PPP Negotiation Phases
Router#debug ppp negotiation
PPP protocol negotiation debugging is on Router#debug ppp authentication
PPP authentication debugging is on
06:36:03: ATM0 PPP: Treating connection as a callout
06:36:03: ATM0 PPP: Phase is ESTABLISHING, Active Open [0 sess, 1 load]
06:36:03: ATM0 PPP: No remote authentication for call-out
06:36:03: ATM0 LCP: O CONFREQ [Closed] id 1 len 10
!-- "O" indicates an outbound packet; in this, case a request.
06:36:03: ATM0 LCP: MagicNumber 0X03013D43 (0X050603013D43)
06:36:03: ATM0 LCP: I CONFACK [REQsent] id 1 len 10
|
!-06 06 |
"I" 36:03 36:05 |
mdicates ATM0 LCP ATM0 LCP |
jn inbound packet; in this case, an acknowledgement MagicNumber 0X03013D43 (0X050603013D43) I CONFREQ [ACKrcvd] id 2 len 15 |
|
06 |
36:05 |
ATM0 LCP |
AuthProto CHAP (0X0305C22305) |
|
!-06 06 06 06 |
Authe 36:05 36:05 36:05 36:05 |
jntication ATM0 LCP ATM0 LCP ATM0 LCP ATM0 LCP |
protocol is CHAP MagicNumber 0X65E315E5 (0X050665E315E5) O CONFACK [ACKrcvd] id 2 len 15 AuthProto CHAP (0X0305C22305) MagicNumber 0X65E315E5 (0X050665E315E5) |
|
06 |
36:05 |
ATM0 LCP |
State is Open |
!-- PPP Successfully negotiated because state is "Open"
06:36:05: ATM0 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 1 load] 06:36:05: ATM0 CHAP: I CHALLENGE id 9 len 26 from "nrp-b" 06:36:05: ATM0 CHAP: Using alternate hostname client1 06:36:05: ATM0 CHAP: Username nrp-b not found
!-- Router hostname (nrp-b) is not the CHAP username; client1 is the CHAP username
06:36:05: ATM0 CHAP: Using default password
06:36:05: ATM0 CHAP: O RESPONSE id 9 len 28 from "client1"
06:36:05: ATM0 CHAP: I SUCCESS id 9 len 4
!-- Authentication succeeds
|
06 |
36 |
05: |
ATM0 |
PPP: |
Phase is FORWARDING [0 sess, 1 load] |
|
06 |
36 |
05: |
ATM0 |
PPP: |
Phase is AUTHENTICATING [0 sess, 1 load] |
|
06 |
36 |
05: |
ATM0 |
PPP: |
Phase is UP [0 sess, 1 load] |
|
06 |
36 |
05: |
ATM0 |
IPCP |
O CONFREQ [Closed] id 1 len 10 |
!-- Outbound request for IP Control Protocol initialization
06:36:05: ATM0 IPCP: Address 0.0.0.0 (0x030600000000) 06:36:05: ATM0 CDPCP: O CONFREQ [Closed] id 1 len 4 !-- Outbound request for CDP Control Protocol initialization
06:36:05: ATM0 IPCP: I CONFREQ [REQsent] id 1 len 10
06:36:05: ATM0 IPCP: Address 8.8.8.1 (0x030608080801)
06:36:05: ATM0 IPCP: Address 8.8.8.1 (0x030608080801)
Example 7-7 Monitoring PPP Negotiation Phases (Continued)
|
06 |
36 |
05 |
ATM0 |
IPCP |
Address 9.9.9.2 (0x030609090902) |
|
06 |
36 |
05 |
ATM0 |
IPCP |
O CONFREQ [ACKsent] id 2 len 10 |
|
06 |
36 |
05 |
ATM0 |
IPCP |
Address 9.9.9.2 (0x030609090902) |
|
06 |
36 |
05 |
ATM0 |
LCP: |
I PROTREJ [Open] id 3 len 10 protocol CDPCP (0x820701010004) |
|
06 |
36 |
05 |
ATM0 |
CDPCP: State is Closed |
|
|
06 |
36 |
05 |
ATM0 |
IPCP: |
I CONFACK [ACKsent] id 2 len 10 |
|
06 |
36 |
05 |
ATM0 |
IPCP: |
Address 9.9.9.2 (0x030609090902) |
|
06 |
36 |
05 |
ATM0 |
IPCP: |
State is Open |
|
06 |
36 |
05 |
ATM0 |
IPCP: |
Install negotiated IP interface address 9.9.9.2 |
|
06 |
36 |
05 |
ATM0 |
IPCP: |
Install route to 8.8.8.1 |
|
!- |
IP Address |
assigned and default route installed |
|||
06:36:06: %LINEPROTO-5-UPDOWN: Line protocol on Interface ATM0, changed state to up
06:36:06: %LINEPROTO-5-UPDOWN: Line protocol on Interface ATM0, changed state to up
As evident from the output, the connectivity begins with an establishing phase as part of the negotiation. In the negotiation, the decision of which authentication type to be used can be seen.
In the authentication phase, the negotiated type is used and user-specific information is exchanged. With successful completion of authentication, the IP Control Protocol (IPCP) and CDP Control Protocol (CDPCP) can be seen initializing. An IP address is negotiated with the far-end server and a default route is established to provide routing connectivity for off-net traffic. Key lines of the output are highlighted for clarity.
At times, the authentication will fail. Whether by misconfiguration of the username or the password, the result is a failed connection. In Example 7-7, the name nrp-b was attempted but failed. Then the name of clientl was attempted and succeeded. In the next example, there is no entry for clientl. Example 7-8 shows an example of the authentication failure. This output is from the authenticating router rather than the router requesting a connection.
Example 7-8 PPP Authentication Failure at the Provider Router
ATM0 CHAP: I RESPONSE id 18 len 33 from "npr-b"
! -- Incoming CHAP response to our challenge.
! -- The username used in the response is npr-b.
ATM0 CHAP: Unable to validate Response. Username npr-b not found
! -- The username supplied by the peer is not configured on the router.
ATM0 CHAP: O FAILURE id 18 len 26 msg is "Authentication failure"
! -- Outgoing CHAP failure message.
ATM0 PPP: Phase is TERMINATING [0 sess, 0 load]
In the example, the configured hostname was not found or was mistyped. A username mismatch is the result of one the following:
■ The peer did not supply the username expected by the target router or authentication server.
■ The target router or authentication server does not have a username configured for the subscriber.
In either event, the provider should be engaged to assist in sorting out the username and password issues associated with the authentication failure.
If the ATM circuit is up, it is reasonable to assume that the router configuration is correct. If PPP still cannot establish a connection, the provider will need to be engaged to find the particular issue causing the failure.
Once the IPCP is open and the IP address is assigned, initiate a ping to the router's next-hop gateway, in this case the aggregation router. If the ping is successful, but no traffic goes beyond it on subsequent pings to Internet locations, initiate a traceroute to ensure that the lack of response is not due to the destination being specifically configured to ignore ICMP Echo Request packets. Many providers and companies today are disabling ICMP functions on their Internet-facing devices.
If the trace does not go beyond the aggregation router, once again the provider must be engaged for troubleshooting purposes.
Continue reading here: Mpls Wan Connectivity
Was this article helpful?