When networking was in its infancy, as with many new technologies, there were many competing approaches to handling the infrastructure that made the physical connections as well as the protocols that ran on those physical connections. Novell and Microsoft, for example, were big proponents of their own protocols. But in the end, the common Internet Protocol, or IP standard, won out. With that came a big boom in the networking industry.
Once there was a connectivity standard, the need for a complementary standard for monitoring the data and programs moving over networks became clear. A group of network engineers created a task force to develop, publish, and ratify the standard that became SNMP or “Simple Network Management Protocol.” By 1990, the Internet Architecture Board (IAB) approved SNMP v1 as the Internet standard for network management but continued to optimize the standard through more iterations:
SNMPv1 worked just fine in a time when networks were still very, very private, and security wasn't a significant concern.
SNMPv2 was introduced when the Internet came around, and networks started becoming interconnected. People could communicate to outside networks from computers within their own private networks, exposing their systems and data with SNMP. Security became a concern, so v2 included an authentication component that, unfortunately, became too complex to manage efficiently.
SNMPv2c reverted to a previous version of SNMP used by communities with the community name as the authenticator. This has become the standard version of SNMPv2.
SNMPv3 includes features to beef up security even further: encryption and authentication of the source. The information inside the envelope is encrypted, and you have the key to decrypt it on the acceptance side. Both SNMPv2c and SNMPv3 are relatively common with v3 being the standard that more security-focused companies are adopting.
A Simple Protocol for Limited Bandwidth
Some of us already know that the "S" stands for "simple," but why was simple a critical component? When SNMP was designed 40 years ago, bandwidth was at a premium. In 1984, total global Internet traffic was 15 Gigabytes per month. Monitoring network traffic could be a little like quantum mechanics: because monitoring tools were so heavy, you couldn’t observe the traffic without affecting the results.
Back in the late 90s, monitoring could make up 20% of network traffic. That’s why the protocol had to be so lightweight: you couldn’t get people to use the protocol or even monitor the network if monitoring took up too much bandwidth.
Today, SNMP traffic doesn't even appear in monitoring reports because the footprint is so small compared to the available bandwidth and network usage. That’s the advantage of utilizing a protocol designed when bandwidth was a premium in a time when bandwidth is a commodity.
However, “simple” means it is lightweight in terms of bandwidth, but it turns out the protocol was really only considered simple by network engineers. Monitoring is a complex subject, and no matter how you approach the task, that complexity has to go somewhere. If you simplify the network communications, the complexity gets pushed out to the applications doing the monitoring.
“Monitoring is a complex subject, and no matter how you approach the task, that complexity has to go somewhere.”
Standard Data Structure Delivers Predictability
SNMP’s standard specifies five core protocol data units (PDUs) that make data easier to parse on the receiver or application side. Network engineers know every field of that packet and expect it to be structured in a specific way: if there's a certain byte here and another byte there, they know exactly what each byte means, and can decode it on the receiving end. It requires that users be able to understand how to structure and code the request, encrypt the request, get it into that packet, send it over, and then, on the receiving side, do the same thing. Setting up this structured packet requires some complex work.
One approach to avoiding this complexity is to use an unstructured or non-standard protocol. The problem is that this just pushes complexity to the edges. The application or user needs to take all the non-standard data and parse it into a structure that means something. It gets stored in an unstructured data store and then multi-indexed by that technology so that users can actually find and use it. And since it's not a recognized standard, someone could decide to change the data format on a whim, putting you back at square one.
Nobody took the time to abstract SNMP’s operational complexity away because it's a complicated application to write. That was one of the reasons other protocols found a foothold; some people thought, “I don't want to keep training on this SNMP thing – it's too hard.”
However, SNMP is a very simple, lightweight message that can supply huge impacts. With this format, just a few bytes on the network can deliver a surprising amount of data.
As you can see, there’s more to this “simple” protocol than meets the eye. It delivers a light load on bandwidth in a structured, predictable format – with benefits you can only get from a recognized industry standard. Part 2 will dig into how SNMP’s stable standard, connectionless approach, and encryption capabilities deliver security with scalability.