Notes4: Changes in my thinking, new information, corrections, etc.

Peter J. Welcher

Last Updated: 9/9/98.

ISDN Routing Correction

In doing a lab last week, I had my nose rubbed in the fact that interface routes are not much use with DDR (dial on demand routing). In particular, I cannot now recommend

ip route a.b.c.d 255.255.255.0 bri 0/0 200

The problem appears to be that ISDN is logically multipoint. So what's the next hop for packets using this route? (With or without the admin distance of 200). Lacking a next hop, how's the router to know what phone number to use?

The fix is simple. List a next hop address, the address of the ISDN router that is to be called.

Tips

I've seen two lab settings where you've got all sorts of debug turned on, and the router just sits there and refuses to dial. This can be a little hard to troubleshoot if you haven't experienced it before! If you're missing the switch type, or if you're missing a dialer-group command on the ISDN interface, when you do a PING or whatever you're using for testing, no dialing occurs (and little debug output). You pretty much have to remember this if you ever run into "why won't it dial"?

If EIGRP or OSPF routing updates aren't getting through, you might look to see if you forgot the keyword "broadcast" on your dialer map statements. Yes, I know both EIGRP and OSPF use multicast. The router uses the broadcast keyword to determine which peers receive copies of broadcasts or multicasts. An alternative is for you to dialer map 224.0.0.5, 6, or 10, but that really isn't the best way to do things!

Debugging ISDN Dial

There are copious debug and show commands for examining what's going on. The following is a summary, listing the most useful commands in the logical order of connection establishment.

`debug isdn q921`	Shows OSI layer 2 info, in particular whether the switch and router are communicating.
`debug isdn q931`	Shows the OSI layer 3 info, the signalling for the call, and whether or not the call goes through.
`debug ppp negotiation`	Shows PPP negotiations.
`debug ppp authentication`	Shows PPP CHAP or PAP authentication.
`debug dialer`	Shows what packets trigger dialing and why. Helps in a lab when you're trying to figure out what's going on!
`debug bri`	Is occasionally useful, but rather verbose. It does show OSI layer 1 info.
`show isdn status`	Shows what happened, useful as a summary if things are more or less working.
`debug isdn`	Might also be worth looking at.

If the router-switch connection seems to be fouled up, or if you want to bring down a connection in the lab, you can do:

clear interface bri 0/0

Trouble-Shooting Dial

I have a short list of techniques for debugging dial. I offer them here in the hope they are helpful to you. They are:

OSI layers
Template
Simplicity

OSI layers. Work your way through the OSI layers, and through the sequential steps that must occur for routers to connect via dial. The above table pretty much lists the debug commands you'd use with this approach.

Template. Work from the Command Guide example (or memory), and approach the problem from a point of view of "what command(s) am I missing?" This can help if you're new to dial, if it used to work and no longer does work, or if something somewhat odd is going on (like a call goes through but then hangs up immediately).

Simplicity. Strip out successive layers of complexity. This is particularly useful when you're learning dial or building a router config template in the lab, but can also be useful in tracking down elusive problems or IOS bugs. For example, if it isn't working and you're doing CHAP, try it without CHAP authentication. Keep making your scenario simpler until you get something that works. Then work back up to whatever level of complexity you need, one step at a time. Debug each step thoroughly before going to the next level.

One list of dial topics in order of increasing complexity: basic call establishment and data flow, then naming and avoiding two way flows. Then load threshold, MP behavior. Then authentication, usually CHAP. Finally, you've got dial backup via backup interface, dial on demand (DDR), either for connectivity or as a dial backup technique, and also refining the access list of interesting packets, to keep the line from coming up unnecessarily. Both dial backup and DDR also interact somewhat with routing, as you've got to work out a routing design that works well for what you're trying to do.

Dr. Peter J. Welcher (CCIE #1773, CCSI #94014) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has nine CCIE's, with expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/welcher . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to pjw@netcraftsmen.net .