Saturday, February 22, 2020

Introduction to SNMP

Imagine you have a large network that has many switches and routers, a dozen servers and hundreds of workstations…wouldn’t it be great if you could monitor all those devices somehow? Using a NMS (Network Management System) it’s possible to monitor all devices in your network. Whenever something bad happens (like an interface that goes down) you will receive an e-mail or text message on your phone so you can respond to it immediately.
Sounds good?
Back in the 80s, some smart folks figured out that we should have something to monitor all IP based network devices. The idea was that most devices like computers, printers, and routers share some characteristics. They all have an interface, an IP address, a hostname, buffers and so on.
They created a database with variables that could be used to monitor different items of network devices and this resulted in SNMP (Simple Network Management Protocol).
SNMP runs on the application layer and consists of a SNMP manager and a SNMP agent. The SNMP manager is the software that is running on a pc or server that will monitor the network devices, the SNMP agent runs on the network device.
SNMP Manager Agent
The database that I just described is called the MIB (Management Information Base) and an object could be the interface status on the router (up or down) or perhaps the CPU load at a certain moment. An object in the MIB is called an OID (Object Identifier).
The SNMP manager will be able to send periodic polls to the router and it will use store this information. This way it’s possible to create graphs to show you the CPU load or interface load from the last 24 hours, week, month or whatever you like.
It’s also possible to configure your network devices through SNMP. This might be useful to configure a large number of switches or routers from your network management system so you don’t have to telnet/ssh into each device separately to make changes.
The packet that we use to poll information is called a SNMP GET message and the packet that is used to write a configuration is a SNMP SET message.

Network Management System

To give you an example of what a NMS looks like, I’ll show you some screenshots of Observium.
Observium is a free SNMP based network monitoring platform which can monitor Cisco, Linux, Windows and some other devices. It’s easy to install so if you never worked with SNMP or monitoring network devices before I can highly recommend giving it a try. You can download it at http://www.observium.org.
Here’s what it looks like:
observium dashboard overview
Above you see an overview of all the devices that our NMS manages. There are two linux devices, two Cisco devices and there’s a VMWare ESXi server. You can see the uptime of all devices.
Let’s take a closer look at one of the Cisco devices:
Observium Cisco Switch
This switch is called “mmcoreswitch01” and it’s a Cisco Catalyst 3560E. It gives us a nice overview of the CPU load, the temperature and the interfaces that are up or down.
Let’s take a closer look at the temperature of this switch:
Observium Cisco Switch Temperature
Here’s the temperature of this switch from the last month. When the temperature exceeds a certain value (let’s say 50 degrees Celcius) then we can tell our NMS to send us an e-mail.
Let’s take a look at an interface of this switch:
Observium cisco switch interface
Here’s an overview of the VLAN 10 interface. You can see how much traffic is sent and received on this interface. We can zoom in one one the graphs if we want:
observium cisco switch interface graph
This gives a nice overview of how much traffic was sent in the last 24 hours of this particular interface.
I hope this gives you an idea of what a NMS looks like and why this might be useful. If you want to take a look at Observium yourself you can use the live demo on their website:

SNMP Messages

All the information that Observium shows us is retrieved by using SNMP GET messages:
SNMP Get Message
The NMS will send SNMP GET messages to request the current state of certain OIDs every few minutes or so. This is great for monitoring the temperature or traffic statistics but the downside of using these SNMP GET messages is that it might take a few minutes for the NMS to discover that an interface is down.
Besides using SNMP GET messages, a SNMP agent can also send SNMP traps. A trap is a notification that it sent immediately as soon as something occurs, for example, an interface that goes down:
SNMP Trap message
As soon as something bad happens (like the interface that goes down) the SNMP agent will send a SNMP trap immediately to the NMS. The NMS will respond by sending you an e-mail, text message or a notification on the screen.
These SNMP trap messages sound like a good idea but there’s one problem with them…there is no acknowledgment for the SNMP trap, so you never know if the trap made it to the NMS or not. SNMP version 3 deals with this problem with an alternative message which uses an acknowledgment called the inform message.

OID (Object Identifier)

We can use a NMS to monitor one of our network devices but how do we exactly know what to monitor? There are so many things we could check for…a single interface on a router has over 20 things we could check: input/output errors, sent/received packets, interface status, and so on. Each of these things to check has a different OID (Object Identifier).
Since there are so many OIDs, the MIB is organized into a hierarchy that looks like a tree. In this tree, you will find a number of branches with OIDs that are based on RFC standards but you will also find some vendor specific variables. Cisco, for example, has variables to monitor EIGRP and other Cisco protocols.
Let me give you an example of this tree by showing where the ‘hostname’ and ‘domainname’ objects are located. These objects can be used to discover the hostname and domainname of the router.
SNMP MIB OID Tree
The tree starts with the “iso” branch and then we drill our way down to org, dod, internet, private, enterprises, cisco, local, lcpu and there we find the hostname and domainname objects. Note that the branches have numbers…instead of typing out the names I can just use the numbers.
1.3.6.1.4.1.9.2.1.3 will be used to get information about the hostname and 1.3.6.1.4.1.9.2.1.4 for the domainname.
The MIB is huge and knowing where to find the right objects can be troublesome, that’s why most NMSes have a nice GUI that lets you select the things you want to monitor without having to worry about the object numbers.
If you want to test SNMP you don’t have to install a NMS, you can use SNMPGET which is a free tool that you can download here:
Here’s an example of SNMPGET where I use a linux host to query a router that has been configured for SNMP:
# snmpget -v2c -c MYSTRING 192.168.1.1 1.3.6.1.4.1.9.2.1.3.0
iso.3.6.1.4.1.9.2.1.3.0 = STRING: "Router"
The community string that I used is MYSTRING, the IP address of the router is 192.168.1.1 and the object I’m interested in is 1.3.6.1.4.1.9.2.1.3. As a result, the router reports its hostname. Here’s another example for the domainname:
# snmpget -v2c -c MYSTRING 192.168.1.1 1.3.6.1.4.1.9.2.1.4.0 
iso.3.6.1.4.1.9.2.1.4.0 = STRING: "localdomain"
I didn’t configure any domainname on this router so the result is “localdomain”.

SNMP Versions

SNMP has three versions:
  • Version 1
  • Version 2c
  • Version 3
Version 1 is so old that it’s very unlikely that you will encounter it on a production network. Version 1 and 2 both use community-strings as a password to authenticate access to the SNMP agent. These community-strings are sent in clear-text which makes SNMP version 1 and 2 very insecure.
SNMP version 3 is a better choice nowadays because it supports username-based authentication instead of a community-string and also supports encryption. There are 3 different security modes:
  • noAuthNoPriv: username authentication but no encryption.
  • authNoPriv: MD5 or SHA authentication but no encryption.
  • authPriv: MD5 or SHA authentication and encryption.
Even if you decide to use SNMP version 3 without authentication or encryption, you can still track activity down to a username.

Conclusion

In this lesson, you have learned how SNMP allows us to monitor our network devices. The only thing left is to configure this on your network devices which I have covered in other lessons:
I hope you enjoyed this lesson. If you have any questions feel free to leave a comment.

No comments:

Post a Comment