The Simple Network Management Protocol is widely used for monitoring and configurations. In this video, you’ll learn about SNMP versions, SNMP traps, and the authentication process used by SNMP.
As a network administrator, you will install switches, routers, servers, firewalls and many other pieces of equipment into your infrastructure. Once you install that equipment, how do you ensure that it’s running optimally and that there are no errors or problems that you need to address? One of the ways to do that is by querying this device through a protocol known as SNMP. This is the simple network management protocol. And it is designed to provide a management interface to these devices over a standard set of protocols, regardless of who happens to manufacture that device.
Usually, the network team will have a central network management console. And that management console will query devices via SNMP and ask information that it would like to receive. For example, it would request from a switch how many bytes have gone into a particular interface. And that device will respond back with a particular value. And that information is stored in the management station.
The query that is being made to this device is querying a number of different parameters that are stored in what is known as a MIB. This is a management information base or a central database of data that is stored on that remote device. SNMP queries specific values in that database by referring to an object identifier, sometimes you’ll hear this referred to as an OID or an OID. All of this polling occurs over udp port 161 and allows us to access any of the devices on our network and gather information about how those devices are performing.
When configuring SNMP on your network management station, it may ask which version of SNMP that device is using. There are usually three different versions you can choose from. The first is the original version, or SNMP version 1. This provided a way to query those structured tables that are stored within the management information base on this device, but it sent all of that information across the network in the clear. There was no encryption associated with any of the transmission using SNMP version 1.
A newer version of SNMP was released that we named SNMP version 2, you’ll sometimes hear this referred to as SNMP version 2c. This is an improvement to SNMP version 1 because it’s able to query large chunks of data and have a more efficient communication to that device. But that entire communication remained non-encrypted or in the clear, so anybody tapping that connection would be able to see the entire communication.
The latest version of SNMP is SNMP version 3. This provides encryption and a number of different cryptographic capabilities such as message integrity and authentication. When we are performing a query to a device using SNMP, we need to refer to a specific variable that we would like to pull back to our management station. That individual variable is called an object identifier, or an OID. That object identifier is a series of numbers.
In fact, here is an ode. 1.3.6.1.2.1.11.28.0. Each one of those numbers is associated with a particular set of values. For example, the 1 is iso, 3 is org, 6 is dod, 1 is internet, 2 is management, and so on. And you can go all the way down this line until you can see that we’re looking for SNMP OutGetResponses, and that would be the number 28 at the end of that OID.
This is how we’re able to have hundreds or even thousands of different variables inside of that management information base. And we can query each of those variables individually by referring to their OID. Sometimes, these object identifiers are very standardized across devices. One of these standards is the MIB2 standard. It’s referred to here as the SNMPV2-MIB. That MIB2 standard is a set of OIDs that are identical across multiple devices.
But sometimes, a manufacturer has unique variables that are specific to that device. And in that case the manufacturer will create their own OID. And so you’ll need to refer back to the manufacturer’s documentation to determine what OIDs are associated with, what values within that MIB. Sometimes, the manufacturer will provide a file that documents the MIB, and you can add that file to your network management station. At that point, you can retrieve those OIDs from that device and know exactly what that OID is associated with.
One of the ways that you can query a device for SNMP information is to use a MIB logger. This is software that will cycle through every possible MIB value and pull down everything associated with the MIB inside of an individual device. This is a MIB logger on my Mac OS device called MIBBrowser. And you can see that I have it directed to a host at 10.1.10.64. It’s using port 161. And I’ve configured this MIB walker to use version 2c of SNMP.
The default community string on this device is public and my route OID is 1.3.6.1. And when I click the Fetch button, it begins gathering information about every possible MIB value that could be contained on that device. And when it finds a match, it adds it to the list. For example, it found a number of SNMP V2 MIB values. And you can see the list of those here. In fact, it even pulled back a system ID information, some contact information with my email. It even shows me the name of the system and how I can then correlate that back to a specific physical device.
If we scroll down a bit in this list, we can even find individual variables as part of this MIB and see the individual values associated with each one of those. For example, SNMP In Get Request has a total number of 4, and SNMP In Get Next has a value of 1,540. If you start collecting that information over time, you can begin to build out very large visualizations of how the network may be performing.
For example, this is a graph that has been created through a series of SNMP queries that take place on a standard basis. So you could see that going for an entire day, you can start to map out information such as response time values, any type of errors, or anything else that might be contained within that MIB.
This implementation of SNMP assumes that your network management station will be querying all of your SNMP enabled devices on your network at regular intervals. It would be common, for example, for a management station to query every device on the network every minute, every five minutes or whatever interval makes sense for your management station. But if there’s a problem on that device, you may not know the problem has occurred until the next time you perform that poll.
For that reason, you may want to configure a different feature of SNMP referred to as an SNMP trap. You can think of this as a proactive alarm that is sent from the device to the management station without the management station needing to poll that device first. These SNMP traps use a different port number. They use UDP 162.
For example, you could configure a switch or router to look for a certain number of CRC errors to occur. And if you get a large number of errors, for example, it increases by 5, that device will proactively send a trap message back to your network management station. As soon as that trap is received by the network management station, it can then alert other people on the network of the problem or start running scripts to help resolve whatever issue that might be.
In the MIB logger that we were using earlier, there was a value that we were adding to that MIB logger to be able to gain access to that system. That value is referred to as a community string. You can think of this as a simple password that allows you access to the SNMP data on that device. You can usually set up multiple community strings within a device. So it’s not unusual to have a read only string such as public.
There might be a read-write string such as private. And there might be a separate string that you would use for traps. These community strings are relatively simplistic and they’re only used for SNMP version 1 and SNMP version 2 or version 2c. There are other ways to authenticate using newer versions of SNMP.
And in SNMP version 3, we use a username and password that is sent across the network as a password hash. This is a much more secure way to authenticate. And if you’re running SNMP in your environment, it’s probably a good idea to use SNMP to have the most secure type of monitoring available.