SNMP - The Good, the Bad, and the Ugly

As today's networks get larger and more complex, the requirement to collect large amounts
of statistical data on the health of the network is becoming increasingly important in order
to deliver basic network management functions.
Simple Network Management Protocol (SNMP) is one of the more widely utilised
technologies in network management solutions. In practice, SNMP is not as "simple" to
implement as one would expect!
This article explores some of the SNMP shortcomings that Statscout has identified while
developing and deploying our network monitoring products into large network infrastructures.
Simple Network Management Protocol
· The major problem with SNMP is that it was not designed to retrieve large amounts
of data efficiently and therefore requires a significant amount of network bandwidth.
Stories about 30% of network bandwidth being chewed up by SNMP based network
management systems are all too common.
· The encoding method used in SNMP often puts a considerable load on the CPU
and memory of switch/router cards, and if not implemented correctly, often results
in the device crashing when sent large or corrupt requests. Every now and then,
CERT alerts tend to kick vendors into action to produce fixes, but the same problems
tend to creep back in when new equipment is produced.
· Most of today’'D5s network equipment is manufactured under tight budgetary
controls, resulting in their management cards being light on resources. Because
of this, many network device vendors tend to allocate the lowest CPU priority to
SNMP. Developers of network management applications must be extremely careful
not to overrun the available network bandwidth and at the same time be sure not
to overrun the network device itself. A management application can only “'D2reliably”'D3
send a single request before waiting for a response. Sending multiple requests in
parallel risks overrunning the device.
· SNMP is sensitive to network delay. For example, a large network delay will
significantly slow an SNMP walk of large tables (eg. routing/interface tables).
· SNMP has not evolved much since its initial creation. SNMPv1 still remains the
current de facto standard due to the amount of real world deployed equipment.
SNMPv2c’'D5s usefulness hinges on network device’'D5s 64 bit counters actually
working, while SNMPv3 is still yet to achieve a real world deployment level that
would consider it as a "standard protocol". Even in its latest form, SNMPv3 is still
plagued with inefficiencies.
· SNMP is still a crude, insecure and inefficient protocol. Why hasn't SNMP been
designed to operate over a compressed TCP stream? Why hasn't the encoding
method been replaced with something more efficient?
MIBs
· Mere mortals find MIB syntax extremely difficult to follow. Vendors seem to invent
their own long and cryptic object names, probably to stop name space clashes.
They are also inconsistent with their indenting levels within the file itself, to the
extent that it appears that

Statscout – Blanket Network Monitoring SNMP: the good, the bad and the ugly – June 2004
 different developers have edited the same MIB using a variety of text editors. Some
text editors use tabs and others spaces. Depending on the tabstop setting of the
editor, the MIB text will display randomly, making it difficult to follow. DOS/Windows
editors will end lines in a carriage return/new line while UNIX editors simply use a
new line. A bit of consistency here would help everyone.
· Developers of the standard RFC MIBs lacked the foresight to include some very
basic counters. For example, in the ifTable of MIB-2 (rfc1213), why did they bother
defining ifInDiscards (number of discarded packets) and not count the number of
bytes which were discarded? Counting the number of packets is of little practical
use as the sizes of the packets vary depending on the MTU. Network Managers
want to know the volume of data that was discarded during congestion periods so
they can determine how under provisioned their links are. They are unable to
determine this from a packet count.
· Many counter sizes were originally defined too small for today's networks (eg. 32
instead of 64 bit). One could forgive the original designers for that one, but in cases
like RFC1573, where ifXTable was created to increase the size of counters, why
were a number of the object types left at 32 bits? For example, the definition for
“ifHighSpeed” is:
"An estimate of the interface's current bandwidth in units of 1,000,000 bits
per second. If this object reports a value of `n' then the speed of the
interface is somewhere in the range of `n-500,000' to `n+499,999'. For
interfaces which do not vary in bandwidth or for those where no accurate
estimation can be made, this object should contain the nominal bandwidth.
For a sub-layer which has no concept of bandwidth, this object should be
zero."
This is OK if we assume that all link speeds are multiples of one megabit. Simply
making this a 64 bit counter would have provided more precise numbers instead
of “an estatimate”.
· Why are there so many ways to say "receive bytes"? A quick search through the
standard RFC MIBs shows the definitions ifInOctets, frCircuitReceivedOctets,
x25CircuitInOctets, rptrMonitorPortReadableOctets, etc. They are all basically the
same thing. MIBs should have been designed in a way so that the standard definitions
could be expanded, not completely duplicated into vendor specific MIBs.
For example, a frame relay PVC does not fit the standard ifTable of MIB-2 because
it requires additional counter types (eg. FECN/BECN). Instead of creating a new
MIB, new object types could have been dynamically added onto the ifTable resulting
in a single definitive object for determining byte counts through an interface,
irrespective of its physical or virtual type.
Furthermore, many vendors replicate objects in ifTable and invent variables such
as fooBarSyncStatsReceiveOctets.
· Counters for bytes at various points of the packet path would also be useful. For
example, counters should be implemented on both sides of the compression in
WAN interfaces. This would allow for the monitoring of link compression levels.

Statscout – Blanket Network Monitoring SNMP: the good, the bad and the ugly – June 2004
 · A large network delay will have a significant impact on how fast SNMP operates.
Many of today’'D5s devices will only “'D2reliably”'D3 send a single request before
waiting for a response. This is why for example an SNMP walk takes forever to
retrieve large tables. Sending multiple requests in parallel risks overrunning and
crashing the device. Each MIB object defines an implementation status, which in
many cases is "mandatory". This means if a device implements the MIB-2 ifTable,
every object of the ifTable should be implemented for every index. Unfortunately,
a number of vendors choose not to implement every object type in tables, which
effectively leaves "holes" in the tables. This causes grief to application developers
as it is very difficult to reliably perform efficient and fast walking of MIB tables.
· Vendors MIB load order and dependencies can be difficult to determine resulting
in the obligatory trial and error routine.
Issues We Have Encountered
· Counters increment incorrectly (eg. by impossible amounts, go backwards, stop
at maximum values, or don't increment at all)
· Counters are incremented on the wrong side of compression software, giving false
link byte counts.
· Interface index numbers change when a device is rebooted and configuration
changes have occurred since the last reboot.
· There are holes in tables because "mandatory" parts of MIBs have not been
implemented for all interfaces.
· Some devices get “'D2confused”'D3 and continually loop on an SNMP walk.
· Various devices crash/reboot when sent large request packets.
In My Opinion
Getting SNMP to scale in a large environment is difficult due to its bandwidth requirements,
network delay sensitivity and device implementation issues.
Today’'D5s network manager or engineer should be able to proactively monitor their entire
network in real-time, without worrying about the underlying inefficiencies of SNMP.
Technologies like RMON were doomed to failure from the start due to the designer's
insistence on running with the SNMP/MIB architecture. RMON could have been successful
if it used a much more efficient transport mechanism. Our experience indicates that it is
difficult to find a site that actually uses RMON probes as an “'D2effective”'D3 monitoring
tool. It is obvious to see why Netflow/sflow didn't bother with SNMP.
Community Name Addressing is a hack to get around a fundamental design flaw in the
MIB for interfaces indexes.
Auto discovery has proven to be ineffective. Most of our 320 customers have tried it,
experienced network crashes and have vowed never to try it again. Technical Analysts
say auto discovery is a must, while end users say “'D2not on my network thanks”'D3.
The good is, at least the majority of vendors implement SNMP in some shape or form.

Statscout – Blanket Network Monitoring SNMP: the good, the bad and the ugly – June 2004
The "Simple" should be taken out of Simple Network Management Protocol, as it is
anything but that.
What can we do about it? A few mediaeval public whippings wouldn't hurt!
Paul Koch
Chief Technology Officer, Statscout
About Statscout
Statscout is the leading provider of Network Performance Monitoring software to
organizations seeking ease of use, scalability, low cost of ownership, low impact to network
infrastructure and ease of deployment.
Statscout is the first network performance monitoring tool purpose built to deliver Blanket
Network Monitoring - “The monitoring of every interface, on every network device, every
60 seconds with minimal impact on the network. “
Statscout achieves Blanket Network Monitoring without affecting the network by collecting
a small, specific set of SNMP OIDs and delivering effective real-time and historical reports
on the collected data.
Statscout generally appeals to government departments, corporate enterprises and
educational facilities with 1000 to 200,000 network interfaces seeking a high return on
investment from a network monitoring solution.
Request a free trial of Statscout by completing the contact form on www.triplecomm.co.uk

Statscout – Blanket Network Monitoring SNMP: the good, the bad and the ugly – June 2004