1.2. Need for Troubleshooting Tools
The best time to prepare for problems
is before you have them. It may sound trite, but if you don't
understand the normal behavior of your network, you will not be able
to identify anomalous behavior. For the proper management of your
system, you must have a clear understanding of the current behavior
and performance of your system. If you don't know the kinds of
traffic, the bottlenecks, or the growth patterns for your network,
then you will not be able to develop sensible plans. If you
don't know the normal behavior, you will not be able to
recognize a problem's symptoms when you see them. Unless you
have made a conscious, aggressive effort to understand your system,
you probably don't understand it. All networks contain
surprises, even for the experienced administrator. You only have to
look a little harder.
It might seem strange to some that a network administrator would need
some of the tools described in this book, and that he wouldn't
already know the details that some of these tools provide. But there
are a number of reasons why an administrator may be quite ignorant of
the rapid growth of the Internet, turnkey systems seem to have grown
in popularity. A fundamental assumption of these systems is that they
are managed by an inexperienced administrator or an administrator who
doesn't want to be bothered by the details of the system.
Documentation is almost always minimal. For example, early versions
of Sun Microsystems' Netra Internet servers, by default, did
not install the Unix manpages and came with only a few small manuals.
Print services were disabled by default.
This is not a condemnation of turnkey systems. They can be a real
blessing to someone who needs to go online quickly, someone who never
wants to be bothered by such details, or someone who can outsource
the management of her system. But if at some later time she wants to
know what her turnkey system is doing, it may be up to her to
discover that for herself. This is particularly likely if she ever
wants to go beyond the basic services provided by the system or if
she starts having problems.
Other nonturnkey systems may be
customized, often heavily. Of course, all these changes should be
carefully documented. However, an administrator may inherit a poorly
documented system. (And, of course, sometimes we do this to
ourselves.) If you find yourself in this situation, you will need to
discover (or rediscover) your system for yourself.
In many organizations,
responsibilities may be highly partitioned. One group may be
responsible for infrastructure such as wiring, another for network
hardware, and yet another for software. In some environments,
particularly universities, networks may be a distributed
responsibility. You may have very little control, if any, over what
is connected to the network. This isn't necessarily
bad -- it's the way universities work. But rogue systems on
your network can have annoying consequences. In this situation,
probably the best approach is to talk to the system administrator or
user responsible for the system. Often he will be only too happy to
discuss his configuration. The implications of what he is doing may
have completely escaped him. Developing a good relationship with
power users may give you an extra set of eyes on your network. And,
it is easier to rely on the system administrator to tell you what he
is doing than to repeatedly probe the network to discover changes.
But if this fails, as it sometimes does, you may have to resort to
collecting the data yourself.
Sometimes there may be some
unexpected, unauthorized, or even covert changes to your network.
Well-meaning individuals can create problems when they try to help
you out by installing equipment themselves. For example, someone
might try installing a new computer on the network by copying the
network configuration from another machine, including its IP address.
At other times, some "volunteer administrator" simply has
her own plans for your network.
Finally, almost to a person, network administrators must teach
themselves as they go. Consequently, for most administrators, these
tools have an educational value as well as an administrative value.
They provide a way for administrators to learn more about their
networks. For example, protocol analyzers like
provide an excellent way to learn the
inner workings of a protocol like TCP/IP. Often, more than one of
these reasons may apply. Whatever the reason, it is not unusual to
find yourself reading your configuration files and probing your
|1. Network Management and Troubleshooting||1.3. Troubleshooting and Management|