Print Friendly
Comments

Monitoring an SNMP-Enabled Router - Part 2

Using the Check a Network Response task it's possible to poll an SNMP enabled device. Part 2 of this guide describes bandwidth monitoring on devices supporting Management Information Base for Network Management of TCP/IP-based Internets: MIB-II (IETF RFC 1213). See also Part 1.

DISCLAIMER: The information provided herein is intended as an example only. No representation is made as to its accuracy, completeness or suitability for a particular purpose or platform (see also the Winserver Wingman EULA). Please test your own implementation thoroughly in the specific environment within which it need function and ensure that it operates as required.

Tested On: [1] Linksys WRT54G running DD-WRT v24-SP2 [2] Linksys LRT214 (Stock)

Bandwidth Usage

The RFC defines multiple tables with rows corresponding to each of the network interfaces on the device (both virtual and physical). While the internal interface names may not prove especially useful in terms of identifying the desired physical port it's the logical place to start. Using the SNMP Query utility (in Options > General) enumerate the interface name table. Given a router at 192.168.1.1, query;

snmp://public@192.168.1.1/1.3.6.1.2.1.2.2.1.2/

[1.3.6.1.2.1.2.2.1.2.1:OctetString] lo
[1.3.6.1.2.1.2.2.1.2.2:OctetString] ifb0
[1.3.6.1.2.1.2.2.1.2.3:OctetString] ifb1
[1.3.6.1.2.1.2.2.1.2.4:OctetString] teql0
[1.3.6.1.2.1.2.2.1.2.5:OctetString] sit0
[1.3.6.1.2.1.2.2.1.2.6:OctetString] ip6tnl0
[1.3.6.1.2.1.2.2.1.2.7:OctetString] eth0
[1.3.6.1.2.1.2.2.1.2.8:OctetString] eth1
[1.3.6.1.2.1.2.2.1.2.9:OctetString] eth2
					

Each interface's media connection speed (i.e. 100Mbps, 1Gbps);

snmp://public@192.168.1.1/1.3.6.1.2.1.2.2.1.5/

[1.3.6.1.2.1.2.2.1.5.1:Gauge] 10000000
[1.3.6.1.2.1.2.2.1.5.2:Gauge] 10000000
[1.3.6.1.2.1.2.2.1.5.3:Gauge] 10000000
[1.3.6.1.2.1.2.2.1.5.4:Gauge] 0
[1.3.6.1.2.1.2.2.1.5.5:Gauge] 0
[1.3.6.1.2.1.2.2.1.5.6:Gauge] 0
[1.3.6.1.2.1.2.2.1.5.7:Gauge] 1000000000
[1.3.6.1.2.1.2.2.1.5.8:Gauge] 1000000000
[1.3.6.1.2.1.2.2.1.5.9:Gauge] 10000000
					

Each interface's traffic received counter (in octets);

snmp://public@192.168.1.1/1.3.6.1.2.1.2.2.1.10/

[1.3.6.1.2.1.2.2.1.10.1:Counter32] 11584
[1.3.6.1.2.1.2.2.1.10.2:Counter32] 0
[1.3.6.1.2.1.2.2.1.10.3:Counter32] 0
[1.3.6.1.2.1.2.2.1.10.4:Counter32] 0
[1.3.6.1.2.1.2.2.1.10.5:Counter32] 0
[1.3.6.1.2.1.2.2.1.10.6:Counter32] 0
[1.3.6.1.2.1.2.2.1.10.7:Counter32] 3927023970
[1.3.6.1.2.1.2.2.1.10.8:Counter32] 378696914
[1.3.6.1.2.1.2.2.1.10.9:Counter32] 0
					

And finally the traffic transmit counters (in octets);

snmp://public@192.168.1.1/1.3.6.1.2.1.2.2.1.16/

[1.3.6.1.2.1.2.2.1.16.1:Counter32] 11584
[1.3.6.1.2.1.2.2.1.16.2:Counter32] 0
[1.3.6.1.2.1.2.2.1.16.3:Counter32] 0
[1.3.6.1.2.1.2.2.1.16.4:Counter32] 0
[1.3.6.1.2.1.2.2.1.16.5:Counter32] 0
[1.3.6.1.2.1.2.2.1.16.6:Counter32] 0
[1.3.6.1.2.1.2.2.1.16.7:Counter32] 401327587
[1.3.6.1.2.1.2.2.1.16.8:Counter32] 1837510170
[1.3.6.1.2.1.2.2.1.16.9:Counter32] 438
					

Based on the above queries we've identified our WAN connection as on interface eth1 (Row 8). If it's not immediately clear try comparing the counters before and after completing a large download.

If we decide that sustained traffic greater than 25Mbps in-bound, or 5Mbps out-bound, are notifiable events for our 30-Down/6-Up VDSL connection we're ready to calculate our octet thresholds. Given a 5 minute test frequency;

25Mbps = 25000000 (bits-per-second) / 8 (bits-per-octet) * 300 (seconds) = 937500000
 5Mbps =  5000000 (bits-per-second) / 8 (bits-per-octet) * 300 (seconds) = 187500000

We can now configure a task to monitor in-bound usage;

Check WAN inbound traffic (is not more than 25Mbps) every 5 minutes.

Task Parameters

Task Type: Check a Network Response

Frequency: 5 Minutes

Address: snmp://public@192.168.1.1/1.3.6.1.2.1.2.2.1.10.8 (Receive Counters, Row 8)

Port: 161

CAUTION On: (response) ...is not returned or; is numerically more than; [Delta]937500000; 2 times.


And also a task to monitor out-bound use;

Check WAN outbound traffic (is not more than 5Mbps) every 5 minutes.

Task Parameters

Task Type: Check a Network Response

Frequency: 5 Minutes

Address: snmp://public@192.168.1.1/1.3.6.1.2.1.2.2.1.16.8 (Transmit Counters, Row 8)

Port: 161

CAUTION On: (response) ...is not returned or; is numerically more than; [Delta]187500000; 2 times.


Counter Limitations

The SNMPv1 counters defined by RFC 1213 are unsigned 32-bit values which wrap when they overflow. If the in-bound connection described above ran constantly at 25Mbps such a counter would wrap approximately every 23 minutes causing the alert condition to clear before being set again on a subsequent evaluation (assuming the same usage continues). The illustrated task would remain fit for the intended purpose of notifying unusual usage but once thresholds begin to approach 100Mbps (where the counter will wrap every 5.7 minutes) an alternative configuration should be considered;

1. Remove the requirement that the alert condition be met on 2 consecutive checks minimizing any delay in re-setting the alert state after a counter wrap.

2. Decrease the test frequency to 1-minute and adjust thresholds accordingly. The counter will still wrap and clear the alert but for no longer than 1 minute in 5. Further where online reporting is concerned, escalating alert-levels are always reported immediately but de-escalations are withheld until at least 5 minutes after the previous notification so brief vacillations of this type are unlikely to be notified at all.

3. Procure a device that maintains 64-bit counters as defined by RFC 2233 (SMIv2) and use the snmpv2:// protocol prefix when querying these.

It's likely that a future version of this software will include specific provision for counters that wrap and maintain 64-bit totals internally.

12 August 2016