15.2 Juniper Networks Troubleshooting Model

Juniper Networks prescribes a particular troubleshooting model, shown in Figure 15-1, for network and router troubleshooting. This simple method adapts well to any given network situation. The following sections take it step-by-step.

Figure 15-1. Juniper Networks Troubleshooting Model

15.2.1 Identify the Symptoms

What exactly is leading you to believe there is a network or router problem? Are there alarms or LEDs illuminated on the router? Do you see information on the craft interface that indicates a problem? We will cover both of these types of indicators in this section. Perhaps it is a network outage that first alerts you to a problem. It could be a kind of catastrophic event that does not allow for normal trouble indicators to let you know that a situation is beginning to occur. It is vital that you begin to act as soon as the symptom of a problem is noted.

15.2.2 Isolate Possible Causes

Now that you have identified some of the symptoms that you are seeing, you need to evaluate the possible causes. The faster you find the cause of the problem, the faster the network will be running smoothly again.

In Figure 15-2, New York's connection to router 2 via serial 1/0 has gone down. New York sends an SNMP trap to the network management station (NMS), indicating an interface-down condition (the symptom). This symptom then gives a network manager or engineer cause to believe that the problem is isolated between New York and router 2 on the serial line. This is where troubleshooting should begin. From experience, you may know that the problem may be beyond that single connection, but unless there are other indications of a larger problem, you should start with serial 1/0.

Figure 15-2. Isolating the Cause of a Problem

The following are good ways to isolate possible causes:

• Taking note of any known activity, such as maintenance, that may be happening in the network

• Noting any other information, such as SNMP traps that have been received

• Working on the problem in parts; in other words, dividing all the possible symptoms into manageable parts

If more than one symptom exists, find the common ground and start working there. If router 2 in Figure 15-2 connects all users from New York's Ethernet LAN to the Internet, users on the New York Ethernet LAN will, of course, be unable to reach the Internet. However, if users on the router 2 side also complain that they cannot reach the Internet, suddenly the possible causes have changed. Work in the area of the common ground (router 2) to locate the problem. If problems being experienced by users on the router 2 LAN are unrelated (printer problems, for example), work each problem separately and according to its priority (e.g., total network outages before user problems). Draw on your own experience or the experience of the staff to brainstorm quickly. Ask questions: Have you seen this happen before? If so, under what conditions? No one can be aware of every occurrence in a large network. It is helpful to leverage everyone's knowledge.

15.2.3 Take Action to Diagnose the Problem Correctly

A good network troubleshooter is very much like a medical doctor in the emergency room of a hospital. You assess the symptoms, and based on the information you have, you try to come up with the possible causes of the symptoms. Once you have possible causes, you run tests or otherwise evaluate your possible diagnoses. For example, if you thought that a possible cause of the network outage in Figure 15-2 is a loose cable, you would take action by going to New York to evaluate the condition of the cable and the connection. This is a very simple example, but it gives you an idea of one possibility and one way to troubleshoot it.

It is vital that you log each step or action taken to try to resolve the problem. The worst thing to do is to keep trying different actions, only to end up causing more problems. If you don't have an accurate log of what you have changed, you will find that it is nearly impossible to retrace your steps, should you need to do so.

Often an inexperienced network troubleshooter cannot tell you how the problem was ultimately resolved, only that something finally worked. The same can be said, however, of experienced troubleshooters . Often it is hard to pinpoint the exact cause of a problem, but part of good troubleshooting is getting into the habit of documenting all of the steps, so that you can try to discover the root cause of the original problem. This also allows you to backtrack, if necessary.

TIP

Use the logging feature on your terminal session to capture every keystroke.

15.2.4 Evaluate the Solution

One way to evaluate this particular solution is to see if the interface returns to an up state on the NMS. Another way is to perform a show interfaces command on the console for New York to determine the up or down status of the interface. This is the moment of truth, when you determine whether or not the problem is completely resolved. If it is not, you must return to an appropriate step in the process.

For instance, if this problem has been resolved, only to be replaced by a new problem, you must return to step one. If this problem has not been resolved, you may go back to step three and try a new course of action against another possible cause of the symptoms. Troubleshooting will not be complete until the symptoms have all been resolved and the network is once again stable.

This method of troubleshooting works well for most network situations. In the remainder of this chapter, we will discuss how to recognize and use various problem indicators that will help you in your daily network troubleshooting.