Troubleshoot ISDN problems on your Cisco router

Choosing ISDN for your company's backup dialing needs can be a reliable approach. But like any technology, ISDN isn't bulletproof, and it can still go down. David Davis walks you through the process of troubleshooting ISDN on your Cisco router and shares some troubleshooting commands that can come in handy.

Over the past few years, the price of high-speed Internet connectivity has dropped lower and lower. This decrease has encouraged businesses to move to VPN-based networks, and many use these networks for their primary connectivity.

However, if your organization is running critical real-time data over a WAN, a VPN network probably isn't the best choice for your company. Instead, because of unpredictable factors of Internet connectivity such as delay and reliability, you've likely established a dedicated connection such as frame relay, MPLS, or point-to-point circuits.

In addition, any organization that relies on business-critical, real-time networks usually requires a backup circuit. Some companies choose dedicated circuits from alternate carriers; others opt for the Internet VPN approach. You can use the Internet VPN approach on whichever Internet circuit is available—wireless, DSL, cable, and so on.

But this option, while high in speed and low in cost, can be troublesome to maintain. These less-expensive circuits usually come with poor service-level agreements (SLAs) and flimsy tech support. (A standard answer to your outage problem would likely be "reboot the router.")

ISDN: One company's alternative

I work for a mid-to-large retail company that has 70 locations. In our case, we don't require additional bandwidth on our backup network, nor do we need the additional headache that DSL circuits would bring. And we're not about to invest in a fully redundant T1 network for backup purposes only.

So, my organization has chosen to stay with ISDN and bond basic rate interface (BRI) B-channels together to get 128-Kbps backup circuits when needed. The network has about 60 ISDN dial-backup lines.

Over the years, ISDN has proven very reliable for my company. It provides quick connection, and it isn't complex to troubleshoot. Nor does it ride the Internet where security is a concern. While ISDN isn't the best choice for high-speed Internet access, it has its niche uses and works great for them.

But ISDN isn't bulletproof, and it can still go down. In my experience, the most common problem with an ISDN circuit occurs when Layer 1 (i.e., the physical layer) goes down. Let's look at how to begin troubleshooting such a problem. (Of course, we'll assume that you had a fully functioning ISDN circuit before the problem occurred and that you made no changes to cause it to go down.)

Determining the problem

While the reason for this could be as simple as an unplugged cable, the culprit is usually that the ISDN interface in the router has lost connectivity to the carrier's ISDN switch. To determine whether this is actually the case, first check your ISDN status by using the show isdn status command (simple, right?). Here's an example of this command's output:

ISDN BRI3/0 interface
        dsl 16, interface ISDN Switchtype = basic-ni
    Layer 1 Status:
    Layer 2 Status:
        TEI = 64, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
        TEI = 73, Ces = 2, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
        TEI 64, ces = 1, state = 5(init)
            spid1 configured, spid1 sent, spid1 valid
            Endpoint ID Info: epsf = 0, usid = 0, tid = 1
        TEI 73, ces = 2, state = 5(init)
            spid2 configured, spid2 sent, spid2 valid
            Endpoint ID Info: epsf = 0, usid = 1, tid = 1
    Layer 3 Status:
        0 Active Layer 3 Call(s)
    Active dsl 16 CCBs = 0
    The Free Channel Mask:  0x80000003
    Total Allocated ISDN CCBs = 0

To determine whether everything is copacetic, you should look for three main things in this output:

  • Layer 1 Status should say Active.
  • Layer 2 Status should say MULTIPLE_FRAME_ESTABLISHED.
  • Under Layer 2, spid1 and spid2 should both say configured and valid.

In the sample output, this was all true. Of course, if this is all true, you don't have a problem. So, let's look at some more sample output to see an example of a problematic configuration.

Global ISDN Switchtype = basic-ni
ISDN BRI3/0 interface
          dsl 24, interface ISDN Switchtype = basic-ni     Layer 1 Status:
          DEACTIVATED     Layer 2 Status:
          Layer 2 NOT Activated
          TEI Not Assigned, ces = 1, state = 3(await establishment)
              spid1 configured, spid1 NOT sent, spid1 NOT valid
          TEI Not Assigned, ces = 2, state = 3(await establishment)
              spid2 configured, spid2 NOT sent, spid2 NOT valid
    Layer 3 Status:
          0 Active Layer 3 Call(s)
    Active dsl 24 CCBs = 0
    The Free Channel Mask:  0x80000003
    Total Allocated ISDN CCBs = 0

In this output, the first thing you should notice is that Layer 1 says DEACTIVATED. In this case, the ISDN cable remains connected, but the ISDN switch isn't on, or there has been some loss of communication between the ISDN switch and the ISDN interface on the router.

Troubleshooting the issue

Before calling the carrier and opening a ticket for a Layer 1 Down status, let's keep investigating. On the interface, try using the clear isdn interface bri0/0 command and the no shutdown command.

If this doesn't bring the circuit back up, try rebooting the router. (This is typically an activity you should schedule after hours using the reload at X command.) After the reboot has occurred, check the status of Layer 1. If it's still down, it's time to open a ticket with the carrier.

Of course, the trick with backup lines is determining when a Layer 1 is down—something that's preferable to know before you actually need that backup line. For this purpose, a UNIX administrator at our company wrote a handy script that runs daily, which runs a rsh $host show isdn stat command in a loop for every router we have.

The script looks for any ISDN interface where Layer 1 is not active, and it sends an e-mail alert about any such routers. This way, we know if a circuit is having trouble at the physical layer, and we can begin troubleshooting the matter in a proactive fashion, using the steps I've outlined in this article.

More resources

Here are some more commands that can come in handy when you're troubleshooting ISDN problems:

  • show isdn: This command displays information about memory, Layer 2 and Layer 3 timers, and the status of PRI channels. Parameters include active, history, memory, service, status, and timers.
  • show dialer: This command displays general diagnostic information for interfaces configured for dial-on-demand routing (DDR). Parameters include interface, type, and number.
  • isdn test call interface: You can use this command to test your DDR configuration. In addition, you can use this command to verify the dialing string and speed without knowing the IP address of the remote router.
  • isdn test disconnect interface: This command disconnects an ISDN data call without bringing down the interface.
  • show logging: As the name implies, this command shows the contents of logging buffers.
  • show running-config interface bri0/0: This command shows the router's configuration for a specific interface (in this case, the BRI0/0 interface). Using show running-config without specifying an interface shows the router's entire configuration file.
  • debug dialer: This command displays DDR debugging information about the packets received on a dialer interface. Parameters include events and packets.
  • debug isdn: This command displays information about ISDN interfaces, including current or historical ISDN calls. Parameters include active, history, memory, service, status, and timers.

Miss a column?

Check out the Cisco Routers and Switches Archive, and catch up on David Davis' most recent columns.

Want to learn more about router and switch management? Automatically sign up for our free Cisco Routers and Switches newsletter, delivered each Friday!

David Davis has worked in the IT industry for 12 years and holds several certifications, including CCIE, MCSE+I, CISSP, CCNA, CCDA, and CCNP. He currently manages a group of systems/network administrators for a privately owned retail company and performs networking/systems consulting on a part-time basis.

Editor's Picks

Free Newsletters, In your Inbox