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:
- Authentication
- Incorrect encapsulation at the far
end
- Conflicting PPP parameters
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:
- A large installed base of client applications that do
not support CHAP.
- Incompatibilities between different
vendor implementations of CHAP.
- Situations where a
plaintext password must be available to simulate a login at the
remote host.
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: - Do both sides agree that PAP is
the method of authentication?
- If so, does the PAP
authentication succeed?
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: - ppp authentication pap
- ppp authentication pap chap
- ppp authentication chap pap
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