160
frame-relay interface-dlci 160
!
Content 4.5 Troubleshooting Frame Relay 4.5.7 Reconfiguring a subinterface Once a specific type of subinterface has been created, it cannot be changed without a reload. For example, subinterface serial0.2 multipoint cannot be changed to subinterface serial0.2 point-to-point. To make a change, either reload the router or create another subinterface. This is the way the Frame Relay code works in Cisco IOSŪ software.
Content 4.6 PPP and Layer 2 Considerations for Routed and Routing Protocols 4.6.1 Link Control Protocol PPP has become the protocol of choice for dial-up, leased lines, and many other point-to-point WAN applications. The reasons for its popularity include multiprotocol support, multilink, address negotiation and compression. The PPP protocol is broken down into a Layer 2 component called Link Control Protocol (LCP) and a Layer 3 component called the Network Control Protocol (NCP). The PPP LCP provides a method of establishing, configuring, maintaining, and terminating the point-to-point connection. LCP goes through four distinct phases. First, link establishment and configuration negotiation occur. Before any network layer datagrams such as IP can be exchanged, LCP first must open the connection and negotiate configuration parameters. This phase is complete when a configuration-acknowledgment frame has been both sent and received. This is followed by link quality determination. LCP allows an optional link quality determination phase following the link-establishment and configuration-negotiation phase. In this phase, the link is tested to determine whether the link quality is sufficient to bring up network layer protocols. This phase is optional. LCP can delay transmission of network layer protocol information until this phase is complete. At this point, network layer protocol configuration negotiation occurs. After LCP has finished the link quality determination phase, network layer protocols can be configured separately by the appropriate NCP and can be brought up and taken down at any time. If LCP closes the link, it informs the network layer protocols so that the protocols can take appropriate action. Finally, link termination occurs. LCP can terminate the link at any time. This usually is done at the request of a user, but can happen because of a physical event such as the loss of carrier or the expiration of an idle-period timer. Most of the problems that occur with PPP involve the link negotiation. Typically the problems can be classified as follows: The first step in troubleshooting a PPP problem is to check that the appropriate encapsulation is in use with the show interfaces serial command. Assuming that the correct encapsulation is in use, the next step is to confirm that the LCP negotiations have succeeded by checking the output for LCP Open. Finally, the Layer 3 component can be verified by checking for Open:IPCP or whatever other Layer 3 protocol is expected. If one of these elements does not appear correct, obtain a detailed debug of the negotiation process using the command debug ppp negotiation. Figure explains in detail each step in a successful PPP link establishment. One of the most likely problems with bringing up a link is an authentication failure. This will be covered in the next sections.
Content 4.6 PPP and Layer 2 Considerations for Routed and Routing Protocols 4.6.2 Troubleshooting PPP authentication PAP Point-to-Point Protocol (PPP) currently supports two authentication protocols: Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP). Both are specified in RFC 1334 and are supported on synchronous and asynchronous interfaces. PAP provides a simple method for a remote node to establish its identity using a two-way handshake. After the PPP link establishment phase is complete, a username and password pair is repeatedly sent by the remote node across the link (in clear text) until authentication is acknowledged, or until the connection is terminated. PAP is not a secure authentication protocol. Passwords are sent across the link in clear text and there is no protection from playback or trail-and-error attacks. Another important consideration is that the remote node is in control of the frequency and timing of the login attempts. Despite its shortcomings, PAP may be used in the following environments: As with most types of authentication, PAP supports bi-directional, two way, and unidirectional, one way, authentication. With unidirectional authentication, only the side receiving the call authenticates the remote side (client). The remote client does not authenticate the server. With bi-directional authentication, each side independently sends an Authenticate-Request (AUTH-REQ) and receives either an Authenticate-Acknowledge (AUTH-ACK) or Authenticate-Not Acknowledged (AUTH-NAK). These can be seen with the debug ppp authentication command. In the debug output, the authentication was bi-directional. However if unidirectional authentication had been configured, only the first two debug lines would be shown. Use the global configuration command username <username> password <password> to match a remote host. This is the username and password used by the local router to authenticate the PPP peer. When the peer sends its PAP username and password, the local router will check whether that username and password are configured locally. If there is a successful match, the peer is authenticated. The function of the username command for PAP is different than its function for CHAP. With CHAP, this username and password are used to generate the response to the challenge, but PAP only uses it to verify that an incoming username and password are valid. For one-way authentication, this command is only required on the called router. For two-way authentication this command is necessary on both sides. Use the global configuration command PPP pap sent-username <username> password <password> to enable outbound PAP authentication. The local router uses the username and password specified by the ppp pap sent-username command to authenticate itself to a remote device. The other router must have this same username and password configured using the username command described above. If one-way authentication is used, the command is only necessary on the router initiating the call. For two-way authentication this command must be configured on both sides. To debug a PPP PAP issue use the debug ppp negotiation and debug ppp authentication commands. There are two main issues that must be considered: Refer to the debugs in Figures and for an annotated, successful debug from the client and server side. In certain configurations it may observed that the two sides do not agree on PAP as the authentication protocol, or instead agree on CHAP when PAP was desired. Use the following steps to troubleshoot these issues. Verify that the router receiving the call has one of the following authentication commands: Verify that the router making the call has ppp authentication pap callin configured when uni-directional authentication is desired. Verify that the calling side has the command ppp pap sent-username username password password correctly configured. The username and password must match the