Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
Troubleshooting occurs not only in response to a problem report, but as part of routine
network maintenance. Similarly, ongoing network maintenance processes (for example,
updating network documentation) often help troubleshoot future problems. This section
addresses the mutually beneficial relationship between troubleshooting and maintenance.
The Relationship Between Maintenance and Troubleshooting Tasks
Chapter 1, “Introduction to Network Maintenance,” pointed out that network maintenance
is composed of multiple processes and tasks. Interestingly, network maintenance
tasks often include troubleshooting tasks, and vice versa. For example, when installing a
new network component as part of ongoing network maintenance, an installer is often required
to troubleshoot the installation until the new network component is functioning
www.CareerCert.info
www.CareerCert.info
www - CareerCert - info
44 CCNP TSHOOT 642-832 Official Certification Guide
properly. Also, when troubleshooting a network issue, the troubleshooter might use network
documentation (for example, a physical topology diagram created as part of a network
maintenance task) to help isolate a problem.
This interrelationship between maintenance and troubleshooting suggests that the effectiveness
of your troubleshooting efforts is influenced by the effectiveness of your routine
network management tasks. Because these tasks are so interrelated, you might want to
take proactive measures to ensure your structured maintenance and troubleshooting
processes complement one another. For example, both network troubleshooting and
maintenance include a documentation component. Therefore, the value of a centralized
repository of documentation increases as a result of its use for both maintenance and
troubleshooting efforts.
Maintaining Current Network Documentation
A set of current network documentation can dramatically improve the efficiency of troubleshooting
efforts. For example, if a troubleshooter is following the path that specific
traffic takes through a network, a physical network topology diagram could help in
quickly determining the next network component to check.
A danger with relying on documentation, however, is that if the documentation is dated,
the troubleshooter could be led down an incorrect path because of her reliance on that
documentation. Such a scenario is often worse than not having documentation at all, because
in the absence of documentation, a troubleshooter is not aware of the need to collect
updated and appropriate data.
Although few argue with the criticality of maintaining current documentation, in practice,
documenting troubleshooting efforts often falls by the wayside. The lack of followthrough
when it comes to documenting what happened during a troubleshooting scenario
is understandable. The troubleshooter’s focus is on resolving a reported issue in a timely
manner (that is, an urgent task) rather than documenting what they are doing at the time
(that is, an important task). Following are a few suggestions to help troubleshooters keep
in mind the need to document their steps:
■ Require documentation: By making documentation a component in the troubleshooting
flow, troubleshooters know that before a problem report or a trouble
ticket can be closed out, they must generate appropriate documentation. This knowledge
often motivates troubleshooters to perform some level of documentation (for
example, scribbling notes on the back of a piece of paper) as they are performing
their tasks as opposed to later trying to recall what they did from memory, thus increasing
the accuracy of the documentation.
■ Schedule documentation checks: A structured maintenance plan could include a
component that routinely requires verification of network documentation.
■ Automate documentation: Because manual checks of documentation might not be
feasible in larger environments, automated processes could be used to, for example,
compare current and backup copies of device configurations. Any difference in the
configurations indicates that someone failed to update the backup configuration of a
device after making a configuration change to that device. To assist with the automation
www.CareerCert.info
www.CareerCert.info
www - CareerCert - info
Chapter 2: Introduction to Troubleshooting Processes 45
Key
Topic
Table 2-3 Importance of Clear Communication During Troubleshooting
Troubleshooting Phase The Role of Communication
Problem report When a user reports a problem, clear communication with
that user helps define the problem. For example, the user can
be asked exactly what is not working correctly, if she made
any recent changes, or when the problem started.
of backups, Cisco IOS offers the Configuration Archive and Rollback feature and the
Embedded Event Manager.
Establishing a Baseline
As previously mentioned, troubleshooting involves knowing what should be happening on
the network, observing what is currently happening on the network, and determining the
difference between the two. To determine what should be happening on the network, a
baseline of network performance should be measured as part of a routine maintenance
procedure.
For example, a routine network maintenance procedure might require that a show
processes cpu command be periodically issued on all routers in a network, with the output
logged and archived. As shown in Example 2-1, the show processes cpu command
demonstrates the 5-second, 1-minute, and 5-minute CPU utilization averages. When troubleshooting
a performance problem on a router, you could issue this command to determine
how a router is currently operating. However, without a baseline as a reference
before troubleshooting, you might not be able to draw a meaningful conclusion based on
the command output.
Example 2-1 Monitoring Router CPU Utilization
R1# show processes cpu
CPU utilization for five seconds: 18%/18%; one minute: 22%; five minutes: 22%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
1 0 1 0 0.00% 0.00% 0.00% 0 Chunk Manager
2 4 167 23 0.00% 0.00% 0.00% 0 Load Meter
3 821 188 4367 0.00% 0.13% 0.14% 0 Exec
4 4 1 4000 0.00% 0.00% 0.00% 0 EDDRI_MAIN
5 43026 2180 19736 0.00% 4.09% 4.03% 0 Check heaps
...OUTPUT OMITTED...
Communicating Throughout the Troubleshooting Process
Each of the troubleshooting phases described in the previous section, “Using Troubleshooting
Procedures,” requires clear communication. Table 2-3 describes how communication
plays a role in each troubleshooting phase.
Table 2-3 Importance of Clear Communication During Troubleshooting
Troubleshooting Phase The Role of Communication
Collect information Some information collected might come from other parties
(for example, a service provider). Clearly communicating
with those other parties helps ensure collection of the
proper data.
Examine collected information Because a troubleshooter is often not fully aware of all aspects
of a network, collaboration with other IT personnel is
often necessary.
Eliminate potential causes The elimination of potential causes might involve consultation
with others. This consultation could provide insight
leading to the elimination of a potential cause.
Hypothesize underlying cause The consultation a troubleshooter conducts with other IT
personnel when eliminating potential causes might also help
the troubleshooter more accurately hypothesize a problem’s
underlying cause.
Verify hypothesis Temporary network interruptions often occur when verifying
a hypothesis; therefore, the nature and reason for an interruption
should be communicated to the users impacted.
Problem resolution After a problem is resolved, the user originally reporting the
problem should be informed, and the user should confirm
that the problem has truly been resolved.
Also, depending on the severity of an issue, multiple network administrators could be involved
in troubleshooting a problem. Because these troubleshooters might be focused on
different tasks at different times, it is possible that no single administrator can report on
the overall status of the problem. Therefore, when managing a major outage, those involved
in troubleshooting the outage should divert user inquiries to a manager who is in
frequent contact with the troubleshooting personnel. As a side benefit, being able to
quickly divert user requests for status reports to a manager helps minimize interruptions
from users.
Change Management
Managing when changes can be made and by whose authority helps minimize network
downtime. In fact, these two factors (that is, when a change is allowed and who can authorize
it) are the distinguishing factors between making a change as part of a routine
maintenance plan and making a change as part of a troubleshooting process.
The process of change management includes using policies that dictate rules regarding
how and when a change can be made and how that change is documented. Consider the
(Continued)
www.CareerCert.info
www.CareerCert.info
www - CareerCert - info
Chapter 2: Introduction to Troubleshooting Processes 47
following scenario, which illustrates how a maintenance change could be a clue while troubleshooting
a problem report:
Last week, a network administrator attempted to better secure a Cisco Catalyst
switch by administratively shutting down any ports that were in the down/down state
(that is, no physical layer connectivity to a device). This morning a user reported that
her PC could not access network resources. After clearly defining the problem, the
troubleshooter asked if anything had changed, as part of the collect information troubleshooting
phase. Even though the user was unaware of any changes, she mentioned
that she had just returned from vacation, thus leading the troubleshooter to wonder if
any network changes had occurred while the user was on vacation. Thanks to the network’s
change management system, the troubleshooter was able to find in the documentation
that last week an administrator had administratively shut down this user’s
switch port.
The previous illustration points out the need for a troubleshooter to ask the question
“Has anything changed?” By integrating a documentation requirement in a change management
policy, someone troubleshooting a problem can leverage that documented
change information.
No comments:
Post a Comment