Determining the Communities of Interest in a Network

A community of interest may be defined by the end-to-end systems used by a given business unit. For example, site network managers are interested in their community of hubs, bridges, switches, brouters, and routers. A WAN manager in a given country is interested in the community of domestic carriers, service providers, and the effected distribution routers. Web site managers are interested in their community of servers, storage attached network (SAN) disk drives, and printers. e-mail administrators live in their community of e-mail and gateway servers, and keep an eye on DNS because it serves up Mail Exchange (MX) records. Managers of file and print servers work within their community of interest. An engineering group’s community of interest is their workstations, servers, and network printers.

Some business units may be geographically dispersed. They have a presence at multiple sites within a corporation. For example, multiple research labs are a community of interest, as are marketing groups and consulting groups.

Some organizations that use the corporate network don’t want their equipment to be managed. This may stem from distrust, concern over configuration control and stability of the equipment, or security issues. There may be “unauthorized” or “nonstandard” equipment in use on the network and they don’t want it discovered. After all, when it’s easier to apologize than to ask for permission, it’s prudent to avoid disclosure as well. Simple paranoia may be at work.

For example, as a routine part of configuration management, NNM attempts to download the default page of a web server. The web server logs each page access, which can fill the log file on small local servers in a few weeks. The server administrator does not want NNM to manage their web service, just their equipment.

For another example, consider the network staff that manages the Internet access routers. They monitor the CPU utilization for these routers, which may have huge routing tables. Each SNMP request for a routing table entry is CPU intense. Needless NNM queries of the routing table (a standard aspect of autodiscovery) can raise a router CPU to nearly 100% utilization. It can be difficult to downplay this by noting that the SNMP process in a router has low priority. Short bursts of high CPU utilization due to SNMP operations are acceptable, but continuously high utilization is a bad thing because it can mask real high-CPU problems such as those caused by route flapping.

The IT group providing the NNM tool to the user community must consider the community of interest and use it to help define the NNM management domain.

Discovering communities of interest may be labor-intensive. You need to talk to a lot of people in a lot of departments to understand the organizational network needs. Factoring in the periodic organizational changes and the addition of new network services, it could become a full-time task merely to keep the community of interest profile updated. Centralized versus distributed support structures can have a big impact on the community of interest.

Enter Remote Monitoring (RMON2) technology. Network devices with embedded RMON2 SNMP agents are capable of sampling network packets and identifying the application (via the TCP or UDP port number). External probes can be installed when there aren’t any embedded agents available. Tools such as Agilent/HP NetMetrix are able to consolidate the output from many RMON2 probes and display a diagram depicting the network source-destination traffic pairs by application type. This makes identifying communities of interest an automated affair and avoids the pitfall of collecting inaccurate data from interviews.