How Much Traffic Does NNM Create?

A network management system will generate many different kinds of traffic in various amounts. A reasonably complete list of traffic types follows:

• DNS forward and reverse lookups plus zone transfers

• status polling (ICMP echo request and reply)

• SNMP configuration polling by netmon

• collection station to management station traffic

• SNMP traps received from the network

• HTTP and Java traffic to remote browser users

• X-Window traffic from remote ovw users

• performance data collection by snmpCollect

• RMON SNMP traffic collected by NetMetrix

• ITO agent traffic to the ITO manager

• MeasureWare statistic to PerfView

Given the bursty nature of this traffic, a dedicated 100BASE-T full duplex switch port should be used to connect the NMS system to the network. The full duplex feature eliminates the possibility of collisions and the 100-megabit/second line speed ensures high throughput and reduces LAN latency to a minimum. It also allows the remote disk backup process to complete in a timely manner.

Despite the conservative musing above, it’s the author’s experience that a standard Ethernet connection is generally sufficient. Still, it’s preferable to know how much traffic the NNM system is generating. This can be done using one of these methods:

• let the NNM system poll its own LAN interface

• let the NNM system poll the switch port it’s connected to

• use the NNM system’s MeasureWare agent and PerfView

• use NetMetrix and an RMON probe to monitor NNM traffic

• attach a LAN analyzer to the NNM system Ethernet port

The NNM system is supposed to be situated in the heart of its management domain to minimize the impact of network management traffic by diversifying it. All traffic in and out of the NNM system does not impact just one WAN circuit. Yet if a large number of managed devices and subnets exist at the far end of a relatively slow serial line, you should estimate the impact of NNM traffic to avoid breaking our 10% rule. RMON2 probes with HP NetMetrix can accurately measure the traffic.

Note that the network management staff and the NNM administrators need to work together. It’s already problematic that router SNMP agents are assigned the lowest task priorities in Cisco routers. It’s less helpful if SNMP traffic is also assigned to a low priority queue by a router’s manager, or if the NNM system’s IP address is excluded from the router’s access control list (ACL). Such antics are symptomatic of dysfunctional teams.

Prior to deploying NNM, the question of NNM’s traffic impact can’t be answered by measurement, so you need to attempt a quick analysis. Assume that your management domain looks like Figure 9-6. Given the bandwidth of the WAN links and the number of managed devices in each campus area, can you calculate the SNMP traffic impact due to performance polling? (You don’t have RMON2 probes or NetMetrix in this discussion). Assume that traffic between sites A and D passes through sites B and C. There is no NNM traffic on the line between sites F and C since both have a direct line to site D. A simple spreadsheet is used to tabulate the data and calculate the results. You can assume five-minute polling and 200-byte packets. Each device polled is assumed to have one interface in the sample arithmetic. You should adjust the arithmetic to reflect your device average interface count. You calculate that the line between sites E and D suffers a mere 2.1% utilization, the worst of all the lines you calculated. This is well below your 10% maximum rule of thumb. Table 9-1 organizes the arithmetic. Polling traffic in bytes-per-second is calculated by multiplying the packet size in bytes by eight times the number of nodes and dividing by the polling interval of five minutes times 60 seconds per minute:

(packet_size_in_bytes × 8 × Number_of_nodes)/(300 seconds)

Now calculate the percent line utilization by dividing the polling traffic in bits-per-second by the line speed in bits-per-second and multiplying by 100:

(polling_traffic/line_speed)×100