I wouldn't be surprised if you told me you have fallen in love with SNMP. Because it is so universal in network administration. Because it is a powerful all-round talent that supplies you with nearly every kind of information you need about whatever network device. Surely you love SNMP, if you know how to set it up on your machine. And if you know what OIDs are and what you need the MIB (files) for. And if your setup is fine, SNMP works reliably (at least it should), and you can live happily ever after.
But have you ever wondered what makes SNMP so universal? Why you can use it in the most heterogenous networks comprising many different devices, different computer architectures, different operating systems, and different platforms and their compilers that all store, process, and present data in different ways?
For example, different computer architectures have different internal data formats. Some of them use big-endian order to represent let's say integers, which means that they treat an integer with the most significant byte first. Whereas others process integers the little-endian way with the least significant byte first.
How would a service that needs to read this integer, after receiving it, know how to read it, the least or the most significant byte first? Regarding SNMP, how does an SNMP agent know in which format it needs to send an answer containing an integer value to the managing entity - in big-endian or little-endian? Obviously, applying the native method on every system may be pragmatic, but it is not a solution because you could not compare the resulting values.
It's time to get some tough facts straight!
As you surely remember, the communication partners in an SNMP conversation are the managing entity and the managed devices. They send and receive messages containing management information through the network via SNMP, no matter what operating systems, programming languages, and compilers are involved.
Obviously, independence is what you need to achieve. To be independent from operating systems, programming languages, and other sorts of components that create difference. How does SNMP become free? The answer is: Structure! More precisely, a commonly understood and standardized structure, known as SMI (which stands for Structure of Management Information).
The evolution from the original SMI (defined in RFC 1155) to SNMPv2-SMI (defined in RFC 2578) brought important refinements, including better support for 64-bit counters and improved MODULE-IDENTITY constructs. These enhancements, standardized by the IETF (Internet Engineering Task Force), made SMI even more robust for modern high-speed networks while maintaining backward compatibility.
Firstly, this includes a type-structure for the data that you use when using SNMP, or, in other words, a definition for the description of integers, strings, OIDs, and so on. And secondly, you need a binary mapping structure to express what happens to these data types, i.e. you need rules for how to transmit these data types in networks. Thanks to these definitions, the format becomes clear and independent. And since the format is a known standard, any machine in your network can receive and "understand" a given piece of SNMP management information and then decide on how to store it in the format that corresponds to its architecture. Of course, these principles also apply to the sending part of the SNMP communication.
Remember, for the Structure of Management Information to create independency, we need definitions for
The definition of SMI data types is derived from ASN.1 (Abstract Syntax Notation One). As its name says, ASN.1 is quite abstract and maybe not the best example for intuitive data structure definitions. However, it is highly effective. Let's see why. (Little side note: We can only cover a very small and simple subset of ASN.1 here. If you want more, check out, for example, ASN.1 related ISO/OSI sources.)
The ASN.1/SMI data types can be broken down into two categories: simple and complex. The former are called basic data types, the latter are so-called higher-level constructs. Let's look at an example of both data types. (SMI pro tip: SMI contains more data types than just those stemming from ASN.1.)
There's one basic data type that you must have heard about when dealing with SNMP. It is the OBJECT IDENTIFIER, or OID. The most common notation is the sequence of digits, for example
1.3.6.1.2.1.2
This OID includes the names of the respective OID tree nodes if you note it as defined in ASN.1 (You can find out more about the actual definition of OBJECT IDENTIFIER in the table below):
{iso(1) identified-organization(3) dod(6) internet(1) mgmt(2) mib-2(1)}
In total, there are 11 basic data types for SMI MIB modules that have been defined in RFC-2578:
Here is an insight into some data type descriptions:
| Data Type | Description |
|---|---|
| INTEGER | 32-bit integer with a value between -2^31 and 2^31-1 inclusive, or a textually named number |
| OCTET STRING | 0 to 65,535 octets (bytes) |
| OBJECT IDENTIFIER | An administratively assigned name, represented as a sequence of non-negative integers |
| IpAddress | A 32-bit internet address represented as an OCTET STRING of length 4, in network byte-order |
| Counter32 | A non-negative integer that increases monotonically until it reaches a maximum value of 2^32-1, when it wraps around and starts increasing again from zero |
| Counter64 | Same as Counter32 but with a maximum value of 2^64-1 |
| Gauge32 | A non-negative integer that may increase or decrease, but shall never exceed a maximum value |
| TimeTicks | A non-negative integer that counts the time in hundredths of a second since some epoch |
However, these are not the only basic data types, there are many more data types out there in the internet.
When you're monitoring network devices like routers or Cisco switches, understanding the difference between these data types becomes crucial. Counter32 and Counter64 are monotonically increasing values—think of them as odometers that only count upward. They're perfect for tracking cumulative metrics like total bytes transmitted through an interface. When a Counter32 reaches its maximum value (2^32-1), it wraps back to zero, which is why Counter64 exists for high-speed interfaces where traffic volumes are massive.
Gauge32, on the other hand, measures values that can go up or down—like current CPU utilization, memory usage, or the number of active connections on a router. Unlike counters, gauges represent a snapshot at a specific moment in time. When an SNMP agent reports these values, it's using the exact data type definitions from SMI to ensure your monitoring system interprets them correctly, regardless of whether you're polling a Linux server or a Cisco device.
Let's move on to the higher-level constructs.
Remember the MIB-2, one of the most important standard MIB module for SNMP? It is defined using higher-level constructs. Let's have a look at the definition of the interfaces group within MIB-2:
interfaces OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of network interfaces (regardless of
their current state) present on this system."
::= { mib-2 2 }
This is the definition of a so-called managed object. It is called "interfaces", and it is of the basic data type INTEGER. The ACCESS clause says that this object can be read but not written to (read-only). The STATUS clause indicates that this object is mandatory for all implementations. And the DESCRIPTION clause provides human-readable text explaining what this object represents.
The last line shows the position of this object in the OID tree: it is a child of mib-2, which has the OID 1.3.6.1.2.1, so the full OID of interfaces is 1.3.6.1.2.1.2.
Another important higher-level construct is the SEQUENCE, which allows you to group related objects together. For example, the ifTable (interface table) uses a SEQUENCE to define the structure of each row in the table, containing information like interface index, description, type, speed, and various counters.
Beyond the basic constructs, SMI also defines textual conventions—essentially, refined data types that add semantic meaning to basic types. The most common example is DisplayString, which is technically an OCTET STRING but specifically intended for human-readable text (like device names or location descriptions).
Textual conventions don't change how data is encoded or transmitted; they simply provide additional context about how the data should be interpreted and displayed. This is particularly useful in MIB modules where you want to ensure that a string field is always treated as displayable ASCII text rather than arbitrary binary data. It's another layer of standardization that makes SNMP management more intuitive across different vendor implementations.
Now that we know how data types are defined, we need to understand how they're actually transmitted across the network. This is where BER (Basic Encoding Rules) comes in.
BER is a standard way of encoding ASN.1 data structures into a binary format for transmission. It uses a TLV (Type-Length-Value) encoding scheme:
For example, when an SNMP agent sends an INTEGER value of 42, BER encodes it as:
This encoding is completely independent of the underlying computer architecture. Whether the sending device uses big-endian or little-endian byte order internally doesn't matter—BER always uses the same encoding rules. The receiving device can then decode the BER-encoded data and convert it to whatever internal format it uses.
While SMI defines the structure and BER handles the encoding, the actual SNMP protocol messages travel across your network using the UDP (User Datagram Protocol) transport layer, typically on port 161 for requests and port 162 for traps. SNMP was designed with UDP in mind because it's lightweight and doesn't require the overhead of establishing connections—perfect for the request-response nature of network monitoring.
These SNMP messages, properly encoded using BER, travel over TCP/IP networks as simple datagrams. The beauty of this design is that whether you're polling a managed object on a local switch or a remote router across the internet, the SMI-defined structure ensures consistent interpretation of the data.
Understanding SMI is crucial for anyone working seriously with SNMP. It's the foundation that makes SNMP truly universal. Without SMI:
SMI provides the common language that allows a monitoring system running on Windows to understand data from a Linux server, a Cisco router, a NetApp storage array, and a printer—all in the same way.
So, the next time you're working with SNMP and wondering why it all just works despite the incredible diversity of network devices out there, remember SMI. It's the unsung hero that provides the structure, the data type definitions, and the encoding rules that make universal network management possible.
The Structure of Management Information might sound dry and technical, but it's actually one of the most elegant solutions in network management. It solves a genuinely hard problem - how to exchange management information between completely different systems - in a way that's both robust and extensible.
And now you know what SMI is, and why it matters!
Stay tuned on our SNMP blog series if at least one of the following questions has already crossed your mind: