Troubleshooting guide

2-8
Cisco Broadband Local Integrated Services Solution Troubleshooting Guide
OL-5169-01
Chapter 2 Troubleshooting Overview
Troubleshooting Strategy
Preparing Yourself to Troubleshoot
Troubleshooting complex networks, like those implemented in the Cisco BLISS for Cable solution, is
somewhat different than troubleshooting other networks. The best way to approach any troubleshooting
problem is to isolate the cause, not the symptom. Of course, the only clues you have are the syptoms, but
you must use them to synthesize a possible (maybe even probable) cause. You can solve any reproducible
problem in any system for which you have the requisite knowledge, training, and experience.
It is always easier to recover from network problems if you are prepared ahead of time. Possibly the most
important requirement in any network environment is to accurately document all current information
about the network and make it available to support personnel. Having complete network information is
critical to making effective network changes, as well as troubleshooting quickly and easily. During the
process of troubleshooting the network, it is very important to ensure that this documentation is kept
up-to-date.
As you troubleshoot, isolate problem causes, and restore your network to its normal functioning, you
apply your expertise about your own network. In order to troubleshoot effectively, you should know your
network well and be able to communicate efficiently and effectively with all key people involved in
network administration and those people affected by the problem.
Consider the solution architecture shown in Figure 1-1 and ask yourself the following questions to
determine whether you are prepared to deal with network problems:
• Do you have accurate physical, functional, and logical maps of your network?
Does your organization have an up-to-date network map that outlines the physical location of all the
devices on the network and how they are connected, as well as a logical map of network addresses,
network numbers, subnetworks, and so on?
• Do you have a list of all network protocols implemented in your network?
For each of the protocols implemented, do you have a list of the network numbers, subnetworks,
zones, areas, and so on that are associated with them?
For each of these protocols do you have a correct, up-to-date set of configuration parameters?
• Do you know all the points of contact to external networks, including any connections to the HFC
network, the PSTN, the SS7 network, and the Internet?
For each external network connection, do you know which signaling/routing protocols are used?
• Do you have an established baseline for all elements of your network?
Has your organization documented normal network behavior and performance at different times of
the day so that you can compare the current problem with a baseline? What constitutes the normal
baseline functioning that you expect when your network is running well? What events, new
equipment, software, or reconfigurations have been added since the last baseline?
• What specific application characteristics and traffic demands are involved (and which are not
involved) in the problem? What past troubleshooting cases (if any) might apply to or assist with the
current situation?
A systematic troubleshooting method helps overcome the time that is often wasted trying to work
through the maze of complex, interrelated network details. Because networks are strategic tools in your
organization, it is a practical reality to look for shortcuts. These shortcuts usually come from prior
expertise, which, in turn, probably resulted from systematic troubleshooting.
To communicate what is learned during network problem solving, use a process for documenting your
troubleshooting details. Both now and in the future, this documentation step can help you, help others in
your team, and help the engineers in Cisco’s Technical Assistance Center (TAC).