Defining Management Domains

You normally want to manage the network along management domains by dividing the network based on geography, business communities of interest, functionality, or network architecture. Geography is a common divider, and a map of the country (or continent or world) is often customized to reflect management domains. The pilot test provides a good proving ground for defining and implementing management domains.

There is a risk of missing pieces of the network within the intended management domain. This means portions of the network remain unmanaged. For single-station NNM implementations there is only one management domain, and the discovery process is manually directed into all corners of the network until no new subnets are discovered. For multistation NNM implementations, there is a risk that the domains may not fit snugly against each other, leaving gaps. For example, management domains A and B may discover a router and its subnets, leaving these subnets initially unmanaged. Which domain should set which subnet icons to the managed state? This illustrates why a considerable amount of bookkeeping is needed to ensure that the management domain pieces fit snugly into the overall network puzzle.

So is it better to allow gaps between the management domains or to allow overlaps? Most will agree that it’s far worse to leave a section of the network unmanaged than to have overlapping management domains. What are the consequences of having network devices managed by more than one NNM system? Managed devices will receive twice the number of SNMP queries and they will be pinged twice as often. When a device goes down, two groups will be working on the problem instead of one, unless, of course, network management is centralized. When a network device sends an SNMP trap, where is it sent? It’s sent to the NNM management stations(s) in the local SNMP agent software’s TrapForwarding list.

Network administrators may configure access control lists (ACLs) on their routers. These can limit access to specified services such as SNMP to specific devices or subnets. For example, to secure the SNMP service on a router, only the local NNM system is allowed access to it. This is a far more robust security mechanism than an unpublished SNMP community string. It has the side effect of limiting the opportunity for overlapping management domains to occur.

Given a strategy for determining the management domains, configuring the NNM system appropriately is more straightforward. By default, the initial management domain is the subnet the NNM system finds itself on. This can be expanded using the netmon daemon’s seedfile parameter. The seedfile is a list of devices in the management domain, typically routers, which have rich ARP caches and excellent network connectivity to help drive NNM’s autodiscovery. Manually directed autodiscovery is appropriate initially, whereby the map builder manually manages appropriate subnets as they are discovered until the desired section of the network is discovered.

Since defining the management domain is initially an iterative process, it’s nice to be able to repeat it. Manual methods are not easily repeated, so once everybody is satisfied that the management domain is correctly defined, a list of routers for the seedfile should be created and maintained. It is recommended that a master list of all seedfiles (for each collection and management station) be centrally maintained. If it is ever necessary to rebuild an NNM system from scratch, knowing the appropriate seedfile information is essential.