5
provide a way for administrators to learn more about their networks. For example, protocol analyzers like ethereal provide an excellent way to learn the inner workings of a protocol like TCPIP. 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 systems.
1.3 Troubleshooting and Management
Troubleshooting does not exist in isolation from network management. How you manage your network will determine in large part how you deal with problems. A proactive approach to
management can greatly simplify problem resolution. The remainder of this chapter describes several important management issues. Coming to terms with these issues should, in the long run, make your
life easier.
1.3.1 Documentation
As a new administrator, your first step is to assess your existing resources and begin creating new resources. Software sources, including the tools discussed in this book, are described and listed in
Appendix A . Other sources of information are described in
Appendix B .
The most important source of information is the local documentation created by you or your predecessor. In a properly maintained network, there should be some kind of log about the network,
preferably with sections for each device. In many networks, this will be in an abysmal state. Almost no one likes documenting or thinks he has the time required to do it. It will be full of errors, out of
date, and incomplete. Local documentation should always be read with a healthy degree of skepticism. But even incomplete, erroneous documentation, if treated as such, may be of value. There are
probably no intentional errors, just careless mistakes and errors of omission. Even flawed documentation can give you some sense of the history of the system. Problems frequently occur due to
multiple conflicting changes to a system. Software that may have been only partially removed can have lingering effects. Homegrown documentation may be the quickest way to discover what may
have been on the system.
While the creation and maintenance of documentation may once have been someone elses responsibility, it is now your responsibility. If you are not happy with the current state of your
documentation, it is up to you to update it and adopt policies so the next administrator will not be muttering about you the way you are muttering about your predecessors.
There are a couple of sets of standard documentation that, at a minimum, you will always want to keep. One is purchase information, the other a change log. Purchase information includes sales
information, licenses, warranties, service contracts, and related information such as serial numbers. An inventory of equipment, software, and documentation can be very helpful. When you unpack a system,
you might keep a list of everything you receive and date all documentation and software. A changeable rubber date stamp and ink pad can help with this last task. Manufacturers can do a poor
job of distinguishing one version of software and its documentation from the next. Dates can be helpful in deciding which version of the documentation applies when you have multiple systems or
upgrades. Documentation has a way of ending up in someones personal library, never to be seen again, so a list of what you should have can be very helpful at times.
Keep in mind, there are a number of ways software can enter your system other than through purchase orders. Some software comes through CD-ROM subscription services, some comes in over the
6
Internet, some is bundled with the operating system, some comes in on a CD-ROM in the back of a book, some is brought from home, and so forth. Ideally, you should have some mechanism to track
software. For example, for downloads from the Internet, be sure to keep a log including a list identifying filenames, dates, and sources.
You should also keep a change log for each major system. Record every significant change or problem you have with the system. Each entry should be dated. Even if some entries no longer seem relevant,
you should keep them in your log. For instance, if you have installed and later removed a piece of software on a server, there may be lingering configuration changes that you are not aware of that may
come to haunt you years later. This is particularly true if you try to reinstall the program but could even be true for a new program as well.
Beyond these two basic sets of documentation, you can divide the documentation you need to keep into two general categories—configuration documentation and process documentation. Configuration
documentation statically describes a system. It assumes that the steps involved in setting up the system are well understood and need no further comments, i.e., that configuration information is sufficient to
reconfigure or reconstruct the system. This kind of information can usually be collected at any time. Ironically, for that reason, it can become so easy to put off that it is never done.
Process documentation describes the steps involved in setting up a device, installing software, or resolving a problem. As such, it is best written while you are doing the task. This creates a different
set of collection problems. Here the stress from the task at hand often prevents you from documenting the process.
The first question you must ask is what you want to keep. This may depend on the circumstances and which tools you are using. Static configuration information might include lists of IP addresses and
Ethernet addresses, network maps, copies of server configuration files, switch configuration settings such as VLAN partitioning by ports, and so on.
When dealing with a single device, the best approach is probably just a simple copy of the configuration. This can be either printed or saved as a disk file. This will be a personal choice based
on which you think is easiest to manage. You dont need to waste time prettying this up, but be sure you label and date it.
When the information spans multiple systems, such as a list of IP addresses, management of the data becomes more difficult. Fortunately, much of this information can be collected automatically. Several
tools that ease the process are described in subsequent chapters, particularly in Chapter 6
. For process documentation, the best approach is to log and annotate the changes as you make them
and then reconstruct the process at a later time. Chapter 11
describes some of the common Unix utilities you can use to automate documentation. You might refer to this chapter if you arent familiar
with utilities like tee, script, and xwd.
[2] [2]
Admittedly these guidelines are ideals. Does anyone actually do all of this documenting? Yes, while most administrators probably dont, some do. But just because many administrators dont succeed in
meeting the ideal doesnt diminish the importance of trying.
1.3.2 Management Practices
