109
Finally, at the high end are frameworks. Roughly, these are packages that can be easily extended. Since you can extend functionality by adding modules, frameworks are better suited for larger, diverse
networks. But be warned, dividing lines among these last categories are not finely drawn.
Unfortunately, at the time of this writing, there arent many freely available packages at these higher levels. The leading contenders are really works in progress. tkined is described in this chapter and the
next because it seemed, at the time this was written, to be further along and fairly stable. But there are at least two other projects making rapid progress in this area that are worth considering. The work of
Open Network Management Systems
http:www.opennms.org is truly outstanding and making
terrific progress. The other is the GxSNMP SNMP Manager http:www.gxsnmp.org
, a part of the GNOME project. Both are open source
http:opensource.org projects, and both appear to have a
committed base of supporters and are likely to be successful. At the time this was written, both had begun to release viable tools, particularly the Open Network Management Systems folks. Linux users
may want to also consider Cheops.
6.1.3 Selecting a Product
It may seem strange that a book devoted to noncommercial software would recommend buying software, but network management is one area in which you should at least consider the possibility.
Commercial products are not without problems, but noncommercial mapping and management tools are relatively scarce. Depending on the size of the network you are dealing with, you may have little
choice but to consider commercial products at this time.
The key factors are the size of your network, the size of your budget, and the cost of a nonfunctioning network. With point tools, you will be forced to put the pieces together. Certainly, this is something
you can do with a small network. If you are responsible for a single LAN or small number of LANs and if you can tolerate being down for a few hours at a time, then you can probably survive with the
noncommercial tools described here. But if you are responsible for a larger network or one that is rapidly changing, then you should consider commercial tools. While these may be quite expensive,
they may be essential for a large network. And if you are really dealing with a large number of machines, the cost per machine may not be that high.
Even if you feel compelled to buy commercial management software, you should read the rest of this chapter. Several of the point tools described here can be used in conjunction with commercial tools.
Some of these tools, because they are designed for a single function, will perform better than commercial tools that attempt to do everything. In a few instances, noncommercial tools address
issues not addressed by commercial tools.
6.2 Device Discovery
The first step in managing a network is discovering which devices are on the network. There are some fairly obvious reasons why this is important. You will need to track address usage to manage services
such as DNS. You may need this information to verify licensing information. From a security perspective, you will want to know if there are any devices on your network that shouldnt be there.
And one particularly compelling reason for a complete picture of your network is IP address management.
6.2.1 IP Address Management
110
Management of IP addresses is often cited as the most common problem faced in the management of an IP network. There are two goals in IP management—keeping track of the addresses in use so you
know what is available and keeping track of the devices associated with each assigned IP address.
Several developments over the last few years have helped to lessen the problems of IP management. First, DHCP servers, systems that automatically allocate and track IP addresses, help when dynamic
allocation is appropriate. But there are a number of reasons why a system may require a static IP address. Any resource or server—time server, name server, and so on—should be given a static
address. Network devices like switches and routers require static addresses. Some sites require reverse DNS lookup before allowing access. The easiest way to provide this is with a static IP address and
with an appropriate DNS entry.
[1]
Even when such issues dont apply, the cost and complexity of DHCP services may prevent their use. And even if you use DHCP, there is nothing to prevent a user
from incorrectly assigning a static IP address in the middle of the block of addresses you have reserved for DNS assignment.
[1]
Strictly speaking, static addresses are not mandatory in every case. Support for dynamic DNS, or DDNS, has been available for several years. With DDNS, DNS entries can be mapped to dynamically
assigned IP addresses. Unfortunately, many sites still do not use it.
Another development that has helped is automatic testing of newly assigned addresses. While earlier implementations of TCPIP stacks sometimes neglected to test whether an IP address was being used,
most systems, when booted, now first check to see if an IP address is in use before using it. The test, known as gratuitous ARP, sends out an ARP request for the IP address about to be used. If anyone
replies, the address must already be in use. Of course, this test works only when the other machine is turned on. You may set up a machine with everything appearing to work correctly, only to get a call
later in the day. Once such a problem has been detected, you will need to track it down.
While these and similar developments have gone a long way toward lessening the problems of IP management and duplicate IP addresses, IP management remains a headache on many networks.
Ideally, you will keep careful records as IP addresses are assigned, but mistakes are unavoidable. Thus, an automated approach is often desirable.
The simplest way to collect MACIP address pairs is to ping the address and then examine your ARP table. The ping is necessary since most ARP tables are flushed frequently. At one time, it was possible
to ping a broadcast address and get a number of replies at once. Most hosts are now configured to ignore ICMP requests sent to broadcast addresses. See the discussion of Smurf Attacks in
Chapter 3 .
You will need to repeat ping scans very frequently if you want to get a picture over time. It is a simple matter to create a script that automates the process of pinging a range of IP addresses, particularly if
you use a tool like fping. Youll need the output from the arp command if you want the MAC addresses. And you certainly will want to do some cleanup with sort or sed.
Fortunately, there is a class of tools that simplifies this process—IP scanner or ping scanner. These are usually very simple tools that send ICMP ECHO_REQUEST packets in a systematic manner to each
IP address in a range of IP addresses and then record any replies. These tools are not limited to using just ECHO_REQUEST packets.
6.2.2 nmap
