Wednesday 13 November 2019

PPP Troubleshooting

PPP Troubleshooting

This article explains PPP Troubleshooting and how to use the show and debug commands to solve PPP problems .

TROUBLESHOOTING THE SERIAL PPP ENCAPSULATION

Remember that, for troubleshooting, the debug command is used , which is accessed in the privileged EXEC mode of the command line interface.
The debug result shows information about different router operations, related to the traffic generated or received by the router, and any error message. This can consume a considerable amount of resources, and the router is forced to apply the switching of processes to the packets that are purged.
The debug command should not be used as a control tool; instead, it is designed to be used for a brief period for troubleshooting.
Use the debug ppp command to display information about how PPP works.
debug ppp { packet | negotiation | error | authentication | compression | cbcp }
The following table shows the command syntax. Use version no of this command to disable the debug result.

THE DEBUG PPP COMMAND

Debug PPP command.
ParameterDescription
packetShows the PPP packets sent and received. (This command shows the downloads of the low level packages).
negotiationDisplays PPP packets sent during PPP startup, when PPP options are negotiated.
errorIt shows the protocol errors and error statistics related to the negotiation and operation of the PPP connection.
authenticationDisplays authentication protocol messages, including packet exchanges of the signal authentication protocol (CHAP, Challenge Authentication Protocol) and password authentication protocol (PAP).
compressionShows specific information for exchanging PPP connections using MPPC. This command is useful for obtaining information about the sequence numbers of the incorrect packets when MPPC compression is enabled.
cbcpIt shows the protocol errors and statistics related to PPP connection negotiations through the use of MSCB.
Use the debug ppp command when trying to find the following:
  • The NCP protocols that are supported at any end of a PPP connection
  • Any loop that could exist in a PPP internetwork
  • Nodes that negotiate PPP connections correctly (or not)
  • The errors that occurred in the PPP connection
  • Causes for CHAP session failures
  • Causes for PAP session failures
  • Specific information on the exchange of PPP connections using the callback protocol (CBCP), used by Microsoft clients
  • Incorrect packet sequence number information where MPPC compression is enabled

PPP DEBUGGING

In addition to the debug ppp command , there are other commands for troubleshooting a PPP connection.
A good command to use during troubleshooting serial interface encapsulation is the debug ppp packet command , as shown in Image.
In the example in the illustration, packet exchanges are represented during normal PPP operation, including the LCP status, the LQM procedures and the LCP magic number.
Below is the result of the debug ppp negotiation command in a normal negotiation, where both sides agree on the NCP parameters. In this case, the IPv4 and IPv6 protocol types are proposed and confirmed.


The debug ppp negotiation command allows the network administrator to view PPP negotiation transactions, identify the problem or stage at which the error occurs, and develop a solution. The result includes LCP negotiation, authentication, and NCP negotiation.
The debug ppp error command is used to display protocol errors and error statistics regarding the negotiation and operation of PPP connections, as shown in Image.

These messages may appear when the quality protocol option is enabled on an interface that is already running PPP.

TROUBLESHOOTING PPP CONFIGURATION WITH AUTHENTICATION

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

In the illustration, an example result of the debug ppp authentication command is shown . The following is an interpretation of the result:
  • The first line indicates that the router cannot authenticate on the Serial0 interface because the peer did not send any names.
  • Line 2 indicates that the router could not validate the CHAP response because the pioneer USER NAME was not found .
  • Line 3 indicates that no password was found for pioneer . Other possible responses in this line could be that no name was received to authenticate, that the name is unknown, that there is no secret for the given name, that the MD5 response received is short or that the MD5 comparison failed.
Finally, in the last line, code 4 means that a fault occurred. The following are other code values:
  • 1 challenge
  • 2 answer
  • 3, successful connection
  • 4 fails
  • id - 3 is the ID number per LCP packet format
  • len - 48 is the length of the package without the header

No comments:

Post a Comment