DHCP Reassigns an IP address

Suppose you remove an Ethernet switch from service and return its IP address manually to the DHCP lease pool. As NNM performs a status poll every five minutes, this switch will appear to go down. Meanwhile, you install a replacement switch with a different legitimate IP address. You manually ping it and NNM discovers it, adds it to the map, and shows the new network connections. Suddenly, a non-SNMP capable device comes online, issues a DHCP request, and receives the recycled switch’s IP address. NNM’s next five minute status poll succeeds and the old switch (seemingly) goes back up! But NNM is no longer able to communicate with the old switch SNMP agent, and leaves the switch icon and its connection on the map, even while the new switch is also shown with very similar connections. Given NNM’s tendency to trust old data, the old switch will not be removed from the database. The only solution is to manually delete the old switch from the map. Of course, one might argue that network equipment IP addressees should always be leased permanently, but the problems do not stop there.

A variation of this problem is that the new switch is given the same IP address as the old one. On the next configuration check, new interfaces appear and NNM discovers them, but the old interfaces are not deleted and simply go down. Again, the fix is to delete the switch and rediscover it. Now you can’t blame it on DHCP.

Let’s suppose that you have an existing workstation that is in the NNM database but doesn’t support SNMP. The workstation gets its IP address from DHCP and the lease is for five days. Now the workstation is shut down and moved to a new subnet, where it is promptly is assigned a new IP address and again is discovered by NNM. Now NNM considers it to have two interfaces, one up and one down. Since it has no SNMP agent, NNM cannot determine if the workstation is truly a router or not, but since there are two interfaces, NNM promotes it to the Internet submap, just like it would a router.

While NNM will delete a node that is down for seven days by default, it will not remove an interface that is down for seven days. Again, the fix is to delete the workstation and allow it to be rediscovered.

At this point it is clear that the NNM 6.1 DHCP-supported features can be brought to bear on such problems. First, in the $OV_CONF/C/ filters file, define a filter that matches the range of IP addresses subject to DHCP assignment. Visit the Options:Network Polling Configuration menu and enable this DHCP filter. The DHCP server must be configured to transmit the SNMP traps OV_DHCP_Alloc and OV_DHCP_Release to the NNM system, where netmon will receive them. The result is a reduction in configuration alarms regarding DHCP devices. NNM will delete the IP addresses for devices with IP addresses that match the DHCP filter after they have stayed down for a specified time. This time interval can be controlled by typing:

					xnmpolling -delDhcpAddrTime interval-spec
				

and it is enabled by typing:

					xnmpolling -delDhcpAddrsOn
				

This is subject to the option -dhcpFiltName filter-name. All these features can be enabled or disabled using the command:

					xnmpolling -dhcpHandlingOn
				

The xnmpolling GUI saves its configuration data in the $OV_CONF/ polling file. See Figure 13-2 for a sample screenshot of a DHCP configuration with the xnmpolling command.