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:
  1. Interface number associated with this debugging information and CHAP access session in question.
  2. 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.
  3. The following messages can appear:
  1. Specific CHAP type packet detected. Possible values are as follows:
  1. ID number per Link Control Protocol (LCP) packet format.
  2. Packet length without header.
A common CHAP error is caused by a password mismatch. This could be caused by two reasons:
  1. 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.
  2. 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