Name Service

Many network management packages attempt to use name service to resolve the IP addresses of network devices from their names and vice versa. If you choose to define your network devices to name service, the way you set up name service can influence how well your network management software works. Conversely, the way your NMS uses name resolution can be more or less robust.

It really doesn't matter what form of name service you use, as all of them work and our recommendations apply to all of them. The three methods of providing name service in common usage today are the following:

• A hosts file: on UNIX, commonly known as /etc/hosts; and on Windows NT, /WINNT/system32/drivers/etc/lmhosts.sam file

• The Domain Name Service (DNS) protocol

• Sun's Network Information Service Plus (NIS+) protocol

Keep this in mind if you want your NMS to continue to work during network outages. If you have implemented name service so that name resolutions don't happen in a timely fashion during outages, you may find that your NMS is not able to report on the outages while it's waiting for responses to name-resolution queries. Therefore, you should be sure to have a means to access the information locally if you choose to use name resolution.

For DNS, this means that the NMS should be a secondary DNS server with a full copy of the DNS tables not a caching server. It should not be used to provide DNS services to other hosts because the real-time needs of DNS clients may conflict with the processing needs of your NMS.

The same should be done for NIS+ or other name services.

A common problem that network management systems have that can involve name service is not recognizing that a particular IP address belongs to a particular device. Consider a router that has many interfaces, each with a unique IP address. Cisco routers normally will label a packet with the source IP address of the interface the packet is going out. If the router is sending your management system syslog messages, the source IP address is the only thing that identifies the device the messages came from. So, if this router sends a syslog message to the management station through the interface Ethernet 0, the packet will have a source address of the IP address of Ethernet 0 by default. But suppose there is redundancy in the network and Ethernet 1 appears to be the same cost as Ethernet 0 to get to the management station. The router may choose to send a second syslog message via Ethernet 1, with Ethernet 1's source IP address. Two different IP addresses, but the same device. Your NMS needs to recognize this and attribute both messages to the same device.

We recommend that you ensure that all network devices have a designated address for management purposes, such as a loopback address, and that the address be used in all packets sourced by that device. See the section called "Setting Up a Loopback Interface" in Chapter 18 for more details on how to implement this.

You can also assist your NMS in determining the source device by defining all addresses on each network device and ensuring that reverse lookups (looking up a name from an address) for all addresses for each device resolve to the same name.

Another problem that an NMS that implements polling, either for availability or performance, must solve is determining what tag (name or IP address) to use to communicate with the device. You, as the network administrator, also will want to communicate with your network devices by using a tag that works as reliably as possible. If name service resolves the name of the device to a loopback or other high-availability address on the device, both your NMS and you can use the name of the device reliably.

Otherwise, both your NMS and you will need to keep a list of the possible addresses on the device and try all of them until one works (hopefully). Let your dynamic routing protocols do the work for you by defining loopback addresses on your devices, and by using these addresses as the only address or the first address returned by name service.

The way you set up name service also can help when troubleshooting your network. Say you want to ping the IP address on a particular interface on a device to determine whether you have connectivity to that interface. You can either remember all your device's IP addresses and what interfaces they are on or you can have name service remember this for you. Say you have a device called router1. You could set up name service so that for each interface on router1 with an IP address, there is a corresponding alias in name service pointing to that IP address. For example, if this router has an Ethernet 0 interface, you could use the alias router1-eth0.