e, because we had locations that had no access to DSL or cable Internet. While VPN is rapidly taking over the backup roles in most locations, ISDN is still out there. Two-way authentication. With two-way authentication, the callin keyword is not neces- sary. Because the authentication is done in both directions, both routers must be Basic (Non-AAA) Authentication configured with usernames/passwords and the ppp pap sent-username command. The end result is that both sides are configured the same way: Calling side: username Bob password 0 ILikePie interface BRI1/0 encapsulation ppp ppp authentication pap ppp pap sent-username Bob password 0 ILikePie Called side: username Bob password 0 ILikePie interface BRI1/0 encapsulation ppp ppp authentication pap ppp pap sent-username Bob password 0 ILikePie Debugging PPP authentication. You debug PPP authentication with the debug ppp authen tication command. The results are usually quite specific and easy to understand. Here, the password being sent from the calling router is incorrect. The debug was run on the called router: 8w4d: BR1/0:1 PPP: Using dialer call direction 8w4d: BR1/0:1 PPP: Treating connection as a callin 8w4d: BR1/0:1 PAP: I AUTH-REQ id 4 len 18 from "Bob" 8w4d: BR1/0:1 PAP: Authenticating peer Bob 8w4d: BR1/0:1 PAP: 0 AUTH-NAK id 4 len 27 msg is "Authentication failure" Bad password defined for username Bob In the next example, two-way authentication has succeeded. Notice that additional requests have been made. First, the called router receives the authorization request (AUTH-REQ) from the calling router. The called router then sends an authorization acknowledgment (AUTH-ACK) and an AUTH-REQ of its own back to the calling router. The final line in bold shows the AUTH-ACK returned by the calling router, completing the two-way authentication. The I and O before the AUTH-ACK and AUTH-REQ entries indicate the direction of the message (In or Out): 00:00:41: %LINK-3-UPDOWN: Interface BRI1/0:1, changed state to up 00:00:41: BR1/0:1 PPP: Using dialer call direction