Chapter12.ISDN BRI Troubleshooting


Chapter 12. ISDN BRI Troubleshooting

From a technology prospective, most of the ISDN fundamentals are covered in the previous chapters of this part. This chapter provides you with a systematic approach to ISDN troubleshooting and demonstrates the suggested layer-by-layer approach to ISDN problems. The approach requires you to start from the physical layer and go up, layer by layer and protocol by protocol, to identify potential issues. This chapter covers the following common issues:

  • Troubleshooting the physical layer

  • Troubleshooting the data link layer

  • Troubleshooting the network layer

  • Troubleshooting the Point-to-Point Protocol (PPP), including link control protocol (LCP), authentication, Network Control Protocol (NCP), and the termination of connections

  • Troubleshooting MLP, PPP, callback, and MMP

  • Troubleshooting telephone interfaces

The layer-by-layer approach in Integrated Services Digital Network (ISDN) troubleshooting requires that you start at the physical layer. In the enterprise environment, it's best to troubleshoot both ends of the connectionthe remote user side and the core side. Before starting the process, however, you need to ensure that you have basic connectivity to the router. See Chapter 4, "Troubleshooting Approaches, Models, and Tools," for tools such as ping and trace. Telnet and SSH are another set of utilities to access the router and some Microsoft Windows-based tools and applications, such as WINIPCFG, IPCONFIG, and HyperTerm.exe can be used also. Most people prefer the console connection. When this is not possbile, just keep in mind that the IOS-based ISDN routers usually are configured for five simultaneous Telnet sessions, whereas 77x routers allow only one by default.

During the troubleshooting process, you might see a significant amount of activity on the screen. This chapter focuses on showing you how to analyze that output.

It is always good to know the exact or relative time of the events. This allows you to recreate the process and understand the chain of events, even if you need to manually set up the clock. One command to remember is service timestamps, which applies a timestamp to your log or debug information. It also provides information about when debug events occurred, and it indicates the specific time and duration of an event. The service timestamps command has two options: the debug uptime and log datetime msec. The log datetime msec option is the more common of the two options because it logs the date and time in msecs. The following shows the timeservice command options:

 804-isdn# configure terminal 804-isdn(config)#service timestamps debug uptime 804-isdn(config)#service timestamps log datetime msec 

Another good practice is to turn on and off the following command when you are connected over a Telnet session to the router:

 804-isdn#terminal monitor 804-isdn#teminal no monitor 

This command enables you to see or not see the debug output on your screen when you have a Telnet session established with the remote router.

If you are connected through the console port, use the options of the command 804-isdn(config)#logging console (described in Chapter 4).

Another useful command, especially when you are monitoring certain events is logging buffered number debugging. To explain the reason, look to a typical case. The user's router intermittently can make calls out in the late evening. Because it is not always possible to monitor the events in the middle of the night, especially when they are intermittent, one good approach is to configure the router with this command and add some issue-related debug commands. In this case, debug dialer is the first one to consider. Then, the next morning, even if the end user is not available, you can review the events from the previous night with the show logging command.

Before entering the layer-by-layer methodology, keep your main objectives in mind. Two things are important to keep in mind during the troubleshooting process of ISDN:

  • If the router can make outgoing calls

  • If the router can pass data

Start with the first feature. If the router can make or accept calls, it's an indication that the router is functioning properly. Also, this indicates that the D channel is functional between the customer premises equipment (CPE) and the ISDN switch, and Layers 1, 2, and 3 of the D channel are set up correctly.

If the router cannot pass data, this mainly concerns encapsulating protocols, such as PPP.




Troubleshooting Remote Access Networks CCIE Professional Development
Troubleshooting Remote Access Networks (CCIE Professional Development)
ISBN: 1587050765
EAN: 2147483647
Year: 2002
Pages: 235

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net