The Simple Network Management Protocol (SNMP) made simple.
All administrator and engineers should have a basic understanding of SNMP. Not knowing what SNMP can do for you is like not understanding the fuel gage on your car. I’m driving and my car seems to be running fine. Why am I stopping? My car is not moving. What does that E on that funny gage mean?
First, let’s talk about this handy little protocol. SNMP (Simple Network Management Protocol) allows systems management tools to collect information from network devices, servers, printers and other devices on an IP network. It is the most widely used management protocol in use today. Most all System management software use SNMP to allow administrators to remotely monitor the performance of their network devices. For the purpose of this article, routers, switches, servers, power distribution units (PDU- fancy word for a power strip), KVM’s and any other device that is SNMP capable will be referenced as a network device. SNMP was developed in 1988 and the RFC was published in 1990. SNMP functions at the Application Layer (Layer 7) of the OSI model. This is the same layer where some other popular protocols function such as SMTP, FTP, Telnet, SSH, IMAP and POP. I find that some Network Admins and Engineers are surprised by this fact. The communication method is port to port. SNMP listens on port 161. Port 162 is used for the TRAP service.
The SNMP communications process consists of a Manager and an Agent. The Manager is an application running on a PC, Server or appliance that initiates the SNMP request to the managed network device. One of the most popular and exceptional Managers is SolarWinds Network Performance Monitor (NPM). There are many others.
The Agent receives the request from the Manager and responds back to the port from which the Manager initiated the request. Pretty simple.
Below is a WireShark packet capture of the SNMP traffic between the Manager and the managed network device. As you can see, the request was initiated from port 62288 on the Manager to port 161 on the managed network device. I’ve found that a good number of administrators and engineers think that SNMP traffic originates on port 161 of the Manager. This is incorrect. The Manager sends the GET request from a random high port to port 161 on the managed network device.
- Traffic from the Manager to the network device.
- The response from the managed network device to the Manager.
There are only three actions that SNMP employs. Five if you want to include the two additional versions of GET.
GET – This request is the most common action. The Manger asks the target device for information.
- GetNext – This action is used with SNMP-Walk type programs. It just gets the next variable.
- GetBulk – This action returns information using multiple GetNext requests.
SET – I don’t want to get ahead of myself but I must state the dangers of using SET. Don’t use this action for SNMP version 1 or 2. These versions are not secure. The community string is sent in clear text and can be easily intercepted using a protocol sniffer. See the WireShark traffic above. I have the community string blacked out in the capture. SET will change network device configurations. For this action to work the SNMP Agent running on the device will need a Read/Write (RW) community string. Again, do not set a R/W community string on any device using SNMP v1 or v2. It can be used with SNMP v3 but I would still recommend against using it at all. Use SSH or some other secure method to make changes to you network devices. And it goes without saying; do not allow SNMP access through a Public (Internet) facing interface.
Trap – This is an action performed by SNMP on the device. The Manager listens on port 162 for traps.
Now lets talk about SNMP versions. SNMP version 1 and 2 are nearly the same. There were improvements from 1 to 2 and small changes to version 2c. Many network devices use version 2c. I do not want to get too far in the weeds. If you want the details of each version upgrade, review the RFC’s. Version 1 and 2 are the easiest to configure. There is nothing wrong with using version 2 if that is the only version your device supports. Version 3 is recommended if your network device supports this version. At first you may think version 3 is too complicated to configure but it becomes easier once you have done it a couple of times on different devices. The security features provided by SNMP v3 are as follows:
- Message integrity – Ensuring that a packet has not been tampered with in transit.
- Authentication – Determining that the message is from a valid source.
- Encryption – Scrambling the contents of a packet.
To simplify SNMP v3 remember these steps. I purposely left out the version 3 configuration commands. You need to research the commands needed to configure your particular network device. Be sure and get some type of SNMP troubleshooting tool with detailed diagnostics capability to check SNMP connectivity to the managed network device. You can make changes with the CLI or modify snmp.conf files till the cows come home but if the SNMP service is not available to the Manager, then the cows will never come home.
- Create an access list to limit SNMP requests from authorized Management Servers.
- Set the location and point of contact information.
- Create a ”View”. This command determines what variables the SNMP Manager can query. Do not restrict access to the MIB tree. I’ve found that this level of restriction is hardly ever justified. Include from MIB tree ISO down.
- Create a Group that is authorized to use this view.
- Create a user and add to this group.
Windows has not caught up with other network device manufacturers. Microsoft does not support SNMP version 3. More than likely, this is due to Microsoft wanting you to use its WMI protocol. I’ll address WMI in another article.
You have probably heard the term MIB or OID tossed around when engineers are discussing SNMP.
MIB stands for Management Information Base and is a collection of information organized hierarchically. You can compare a MIB to a DNS server.
OIDs or Object Identifiers uniquely identify managed objects in a MIB hierarchy. This is depicted as a tree. The levels in the tree are assigned by different organizations. Top-level MIB OIDs belong to different standard organizations. Vendors define private branches. This is where they set their own unique objects for their products however they do use the top level OID’s when possible. Why recreate a CPU performance variable OID when one already exists at the top level. But a printer manufacture may want an OID variable to indicate ink levels in a color printer for their own management software. This variable OID is published by the printer manufacture and you can use it to build custom SNMP graphs or alerts. Just remember this….a Management device looks up the OID in the MIB and uses the OID to query the target device for a variable. It’s that simple.
SolarWinds publishes updates to their MIB monthly. The most critical part of any Manager is the number of standard and proprietary MIBs it supports. Without the correct MIBs, the data collected from a remote device is difficult to interpret and use. SolarWinds MIB Browser is shipped with over 250,000 precompiled unique OIDs from hundreds of standard and vendor MIBs – the largest collection in the industry. SolarWinds engineers continually update the MIB database with the latest MIBs.
This is a screenshot of the MIB tree using SolarWinds MIB Browser. I simply pointed it at a Cisco device and the tool connected with the Read Only (RO) community string. Now all I need to do is expand the tree down to the branch that interests me. Issue a GET command and the device returns the variable I requested. In this case I issued a few GETNext commands. Following the tree in the left pane we see that Cisco is using the standard OID for the six variables in the right pane. The lower left pane displays information about the OID. The OID for System Up Time is 126.96.36.199.188.8.131.52.
As I mentioned before, vendors create and publish their own MIB’s. The SolarWinds MIB has incorporated more than a 1000 Cisco specific MIBs.
This concludes our computer-side chat about SNMP. SNMP can help you manage your network no matter how big or small. Remember these points.
- Use SNMP version 3 whenever possible.
- The Manager does not initiate the SNMP request from port 161.
- An MIB is a database used to manage network devices. It contains OIDs.
- Check for additional vendor MIBs.
- Stay away from network management tools that use the SET command but do not support SNMP version 3.
Cisco MIB/OID on-line application.
SolarWinds MIB Browser tool
SNMP RFC 1157