one configured on the receiving router. Use the
interface configuration command ppp chap refuse on the
calling router. By default, Cisco routers will accept CHAP as
the authentication protocol. In a situation where the client
wishes to do PAP but the access server can do PAP or CHAP, the
ppp chap refuse command can be used to force the client
to accept PAP as the authentication protocol.
Router(config)#interface BRI 0/0
Router(config-if)#ppp chap refuse If the two sides agree
on PAP as the authentication protocol but the PAP connection
fails, it is most likely a username and password issue: Verify
that the calling side has the command ppp pap sent-username
username password password correctly
configured, where the username and password match the one
configured on the receiving router. For two-way authentication,
verify that the receiving side has the command ppp pap
sent-username username password password
correctly configured, where the username and password match the
one configured on the calling router. When doing two-way
authentication, if the command ppp pap sent-username
username password password were not present
on the receiving router and the PPP client attempts to force
the server to authenticate remotely, the output of debug
ppp negotiation or debug ppp authentication would
indicate: *Jan 3 16:47:20.259: Se0:1 PAP: Failed request for
PAP credentials. Username maui-nas-06 This error message is an
indication of a configuration issue and not necessarily a
security breach. Verify that the username and password matches
the one configured in the command ppp pap sent-username
username password password on the peer. If
they do not match the following message will be output: *Jan 3
17:18:57.559: Se0:3 PAP: I AUTH-REQ id 25 Len 18 from
"PAPUSER"
*Jan 3 17:18:57.559: Se0:3 PPP: Phase
is FORWARDING
*Jan 3 17:18:57.559: Se0:3 PPP: Phase is
AUTHENTICATING
*Jan 3 17:18:57.559: Se0:3 PAP:
Authenticating peer PAPUSER
*Jan 3 17:18:57.559: Se0:3
PAP: O AUTH-NAK id 25 Len 32 msg is
"Password
validation failure" This is an outgoing AUTH-NAK. This
means that the mismatch occurred on this router. Verify that
the username and password configured locally is identical to
that on the peer.
Content 4.6 PPP and Layer 2
Considerations for Routed and Routing Protocols
4.6.3 Troubleshooting PPP authentication CHAP
Debugging CHAP is similar to debugging PAP. Use the debug
ppp authentication command to determine why an
authentication fails. The following are a description of each
of the debug fields in Figure , and their possible values:
- Interface number associated with this debugging
information and CHAP access session in question.
- 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.
- The
following messages can appear:
- No name
received to authenticate
- Unknown name
- No
secret for given name
- Short MD5 response received
- MD compare failed
- Specific CHAP
type packet detected. Possible values are as follows:
- 1 = Challenge
- 2 = Response
- 3
= Success
- 4 = Failure
- ID number
per Link Control Protocol (LCP) packet format.
- Packet
length without header.
A common CHAP error is
caused by a password mismatch. This could be caused by two
reasons: - The peer did not supply the password expected
by the local router. For example, the router expected (had
configured) the password LetmeIn, but the peer used the
password letmein. The administrator can either re-configure the
username and password sent by the peer or correct the peer with
the right username.
- The local router does not have
the password correctly configured. If the administrator has
verified that the password supplied by the peer is correct,
then reconfigure the local router.
To remove the
existing username and password entry use the command: no
username <username> where
<username> is replaced by the username in the
error message. Then configure the username and password using
the command: username <username> password
<password> The password must match the
password on the remote router.
Content 4.6 PPP
and Layer 2 Considerations for Routed and Routing
Protocols 4.6.4 IP split horizon checking
Split horizon dictates that a routing update received on an
interface cannot be retransmitted out of the same interface.
This rule holds even if the routing update was received on one
Frame Relay PVC and destined for retransmission onto another
Frame Relay PVC. With reference to Figure , this would mean
that Sites B and C can exchange routing information with Site
A, but would not be able to exchange routing information with
each other. Split horizon does not allow Site A to send routing
updates received from Site B on to Site C, and vice versa. The
concept of subinterfaces was originally created in order to
handle issues caused by split horizon over nonbroadcast
multiaccess (NBMA) networks and distance-vector-based routing
protocols. Frame Relay and X.25 are examples of NMBA networks
and IPX/SAP, RIP and Appletalk RTMP are examples of
distance-vector-based routing protocols. Note: For
TCP/IP, Cisco routers can disable split horizon on all Frame
Relay interfaces and multipoint subinterfaces and, in fact, do
this by default for most IP routing protocols. However, split
horizon cannot be disabled for other routing protocols, such as
those used with IPX and AppleTalk. These other protocols must
use subinterfaces if dynamic routing is desired. By dividing
the partially meshed Frame Relay network into numerous virtual,
point-to-point networks using subinterfaces, the split-horizon
problem can be overcome. Each new point-to-point subnetwork is
assigned its own network number. To the routed protocol, each
subnetwork now appears to be located on a separate interface.
Routing updates received from Site B on one logical
point-to-point subinterface can be forwarded to Site C on a
separate logical interface without violating split horizon.
Content 4.6 PPP and Layer 2 Considerations for
Routed and Routing Protocols 4.6.5 OSPF in an
NBMA environment Unless special consideration is given to
the operation of OSPF in a Non-Broadcast Multi-Access (NBMA)
environment such as Frame Relay, routing problems will occur.
This is because OSPF expects to be able to multicast all
routers within a subnet, or broadcast domain. In a Frame Relay
hub and spoke topology this will not be possible. Consequently,
some routers and routes will be inaccessible. The problem can
be solved by forcing RTB to become the designated router. This
is achieved by configuring an OSPF interface priority of 0 on
all the spoke routers. Recall that a priority of 0 makes it
impossible for a router to be elected as DR or a BDR for a
network. As long as RTB can exchange hellos with RTA and RTC it
can maintain a complete view of the network and pass this
routing information to both RTA and RTC. Alternatively,
subinterfaces could be used on the hub router making each link
a point to point link. Recall that no DR election occurs in a
point to point configuration. The downside to this technique is
the creation of a new subnet or network. Still another
technique to manage OSPF over hub and spoke NBMA networks is to
explicitly configure OSPF as a Point-to-multipoint network.
Point-to-multipoint networks have the following properties.
Adjacencies are established between all neighboring routers.
There is no DR or BDR for a point-to-multipoint network. When
originating a router LSA, the point-to-multipoint interface is
reported as a collection of point-to-point links to all the
interface's adjacent neighbors, together with a single stub