Header
Home | Set as homepage | Add to favorites
  Search the Site     » Advanced Search
Sections
Syndication


Blogroll:

||||| ALL Cisco-Network ARTICLES |||||  
CCIE Journey,
The CCIE Journey,


Debugging Dial Backup

Jul 21,2008 by admin

image

Debugging Dial Backup Problem Your dial backup is not behaving properly and you want to debug it to isolate and resolve the problem. Solution The most common reasons for failed dial backup calls are incorrect dial strings and PPP authentication problems. You can easily diagnose both of these problems with this command: Router1#debug ppp authentication Here is another useful command for diagnosing problems with dialer configurations: Router1#debug dialer Discussion When you use CHAP authentication with PPP, as we have done throughout this chapter, it is relatively easy to debug most common problems. We like to use the debug ppp authentication command because it pinpoints the most frequent problems: Jun 28 14:04:05.211: BR0/0:1 PPP: Phase is AUTHENTICATING, by both Jun 28 14:04:05.211: BR0/0:1 CHAP: O CHALLENGE id 1 len 33 from "Router1" Jun 28 14:04:05.211: BR0/0:1 AUTH: Started process 0 pid 60 Jun 28 14:04:05.235: BR0/0:1 CHAP: I CHALLENGE id 35 len 33 from "dialhost" Jun 28 14:04:05.235: BR0/0:1 CHAP: O RESPONSE id 35 len 33 from "Router1" Jun 28 14:04:05.267: BR0/0:1 CHAP: I SUCCESS id 35 len 4 Jun 28 14:04:05.271: BR0/0:1 CHAP: I RESPONSE id 1 len 33 from "dialhost" Jun 28 14:04:05.271: BR0/0:1 CHAP: O SUCCESS id 1 len 4 This output shows the PPP Authentication challenge and response handshake between two routers. This is one of the first places to look when you have dialup sessions that refuse to connect. In this particular trace, the router Router1 has dialed to dialhost. Upon connection, both routers present a password challenge. In this case, you can see that both routers responded correctly and authentication was successful. You should see a similar trace on both routers if everything is working properly. If you enable this debug command and you see nothing, then you know that the routers are not reaching this point. So there is a problem at a lower layer. It would then be a good idea to start by making sure that you have the correct dial string, which you can verify by simply looking at the state of the dial interface on the receiving end to see if it picks up the phone when you call from the other end. Another useful command to see if your router is dialing appropriately is debug dialer: Jun 28 14:04:02.691: BR0/0 DDR: rotor dialout [priority] Jun 28 14:04:02.691: BR0/0 DDR: Dialing cause ip (s=10.1.99.55, d=10.1.99.1) Jun 28 14:04:02.691: BR0/0 DDR: Attempting to dial 95551212 Jun 28 14:04:05.311: Di1 DDR: dialer protocol up Here you can see that the router is dialing because of an IP packet, and the output shows the source and destination IP addresses of this packet. It also shows the dial string, the interface, and the fact that it connected successfully.
174 times read

Related news

» Using Dialer Watch
by admin posted on Jul 21,2008
» Using an Async Modem on the AUX Port
by admin posted on Jul 21,2008
» Using Backup Interfaces
by admin posted on Jul 21,2008
» Debugging OSPF
by admin posted on Jul 21,2008
» Automating Dial Backup
by admin posted on Jul 21,2008
Did you enjoy this article?
(total 0 votes)

comment Comments (0 posted) 

More Top News
CCSP-Cisco Certified Security Professional
Most Popular
Most Commented
Featured Author