SNMP on Linux for the Newbie
Printer friendly: http://www2.maxsworld.org/howtos/snmp.html
This how-to is geared toward the newbies of SNMP on Linux hosts. If you have little to no experience dealing with the SNMP protocols, then it should prove useful to get you off and running.
System:
CentOS 4.3 (Will work on any RHEL/Fedora flavors)
References:
Net-SNMP: http://net-snmp.sourceforge.net/
SNMPLink.org: http://www.snmplink.org/
Need more? Just Google for “SNMP” and you’ll get about 30 million hits, I think there’s a little information out there. 
Packages/Dependencies:
RPM Packages: net-snmp net-snmp-libs net-snmp-utils
SNMP is run as the service snmpd, which is provided by the above packages.
What’s this SNMP stuff?
In case you don’t know, Simple Network Management Protocol. Now, what the heck is that? SNMP is an industry standard when it comes to hardware. It’s used to monitor and manage virtually any device on a network that has an IP address. Basically, it’s a software layer used to talk to the hardware of a device. There’s tons of information available on this subject, so Google away. This is just a quick guide to installing the SNMP service on a Linux host, and then use the tools provided to see what you can poll and put to use. SNMP’s information is gathered with the help of MIB’s (Management Information Blocks). For the majority of what you are are going to poll, the MIB’s will already be present, but if not, oodles of MIB’s are available for downloads. If you want to get really good at SNMP, I suggest purchasing a book such as Essential SNMP published by O’Reilly. You can do some very cool stuff with this service. If you plan on running Nagios or MRTG, then you need to learn SNMP.
How does it work? This is more complicated to explain, so again if you really want to learn SNMP, buy a book and read. The short version is this: SNMP passes over the UDP traffic protocol. Most of you are probably used to hearing TCP, but UDP is used for the transport medium. So, an SNMP request is made on a host to a remote host. The traffic passed is UDP traffic to the remote host. When the request hits the remote host, it passes over the application layer to poll the hardware of which you are requesting. A response is then sent back to the host from where the request came. SNMP keeps track of what it’s going to talk to by a naming scheme (OID - Object ID). In short, it’s a roadmap for the underlying hardware, and can be seen as a set of numbers such as .1.3.6.2.1.1. This is the common “system” OID, where you can find things like system names, contact information, and uptime information. I’m picking on the system OID, because it’s common and simple. Now, there’s a big long list of the major top level OID’s. These serve as the standards for the industry. From here, hardware vendors write their SNMP specs in the form of MIB’s, which at some point, will talk to the top level OID’s. Again, I am simplifying this in crayon, so get yourself a book if you want details.
Another aspect of SNMP is traps. Traps can be fun, because this is where you can control your devices through a network management server (NMS). For instance, you can set up a host to send a trap to a machine if certan events are triggered, or not triggered. I’ll use a simple temperature monitor as an example. If a temperature goes above a certain point, a trap can be sent to the NMS which in return, can shut down equipment or notify you about what is happening. You can see already where this can come in handy! I’m not going into a lot of detail about traps. I don’t use them very often, because I mainly use SNMP for polling requests and receiving results to simply monitor hosts and graph statistics.
There are three versions of SNMP used. SNMPv1, SNMPv2c, and SNMPv3. V1 and v2c can be grouped together because they use the “communities” for polling read-only, read-write, and traps. These versions lack in security, but if you use it the way I do, that is, read-only through an intranet, then you shouldn’t have any problems. I’ll be using v2c as my demo. V1 and v2c pass a text only phrase, thus the security concerns. SNMPv3 addresses this security concern with encryption. If you desire strong security, then I suggest using this version. An example of this would be if you have to pass traffic outside your network on the web, then back into a location. Again, I don’t have a need for this, but you might.
1) Installation:
A simple rpm -q net-snmp net-snmp-libs net-snmp-utils will determine if you have the packages installed or not. If not, simply install them from yum.
[me@mymachine ~] yum install net-snmp net-snmp-libs net-snmp-utils
Just to note, there are two other packages that you might be interested in down the road. For now they aren’t needed, but they are net-snmp-perl and net-snmp-devel. The Perl package contains the necessary files so that you can use SNMP from within Perl. Obviously, the development package is self-explanatory.
2) Configuration:
The main configuration file of interest to you after installation is located at /etc/snmp/snmpd.conf. Go ahead and open up this file and see what it’s in it.
[me@mymachine ~] vim /etc/snmp/snmpd.conf
This is the basic example file, but it’s very well documented and should help assist you in figuring out what parameters are. At first glance, you might get scared. You really only need a few configurations entered to start polling, so let’s start with that. First, let’s take the default file and tuck it away somewhere safe so you can refer to it later, before you start hacking away at the main file. From here there are two ways to configure the file…a) manually, the fastest, and b) using the snmpconf utility. I’ll show you manually, later you can play with the snmpconf utility. It provides a lot of help along the way, and explains a lot of items as well. Just remember to save your current file in case you wipe it out with the snmpconf utility later.
[me@mymachine ~] cd /etc/snmp
[me@mymachine ~] mv snmpd.conf snmpd.conf.org
[me@mymachine ~] touch snmpd.conf
[me@mymachine ~] vim snmpd.conf
Technically, you need only enter one simple line to enable read-only of all information the host can possibly dish out via SNMP. You can use any community string value you would like, if you don’t want to use the standard. To get started, enter the following lines. Save and exit the file.
rocommunity public
syslocation “Wherever your machines sits”
syscontact someone@youremail.com
Congrats, you’re now ready to fire the agent up:
[me@mymachine ~] chkconfig snmpd on
[me@mymachine ~] service snmpd start
For now let’s leave the configuration file alone and move along to more exciting things, like actually polling the machine you just set up. You can come back to configure more detailed configurations later, or you can resort to the snmpconf utility to explore and learn on your own.
Note: I’ve only shown you how to get SNMP up and running quickly with read-only poll access from anywhere on your network. You can do many useful things, such as locking it down to a different community string, or only specific users. Also, you can secure it to only allow polls from a different community string, but only from a certain IP address. An example of this would be:
rocommunity whateverstringyouwant 192.168.0.7
This example would allow only the IP of 192.168.0.7, when passed with the appropriate community string, to read-only SNMP information. This is a simple way of secluding it from the rest of your network and only allowing it to be polled from a certain host…an NMS for example.
Tools of SNMP:
Many folks use fancy polling tools through GUI’s, and they are useful at first for learning, but you truly only need two of tools SNMP provides…snmpwalk and snmpget. They will become your exploration partners in your quest to seek SNMP enlightenment. Let’s see what each one does.
The first, snmpwalk, does exactly what it sounds like. Given the correct arguments, snmpwalk will poll the remote host for every possible piece of information that it can find. To see the manual:
[me@mymachine ~] man snmpwalk
It’s very simple to use, so let’s get to polling. Either from the machine you just set up SNMP on, or better, from a remote machine with SNMP installed, poll the machine you just set up.
[me@mymachine ~] snmpwalk -v2c -c public localhost | less
SNMPv2-MIB::sysDescr.0 = STRING: Linux hostname.net 2.6.9-34.EL #1 Wed Mar 8 00:07:35 CST 2006 i686
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
SNMPv2-MIB::sysUpTime.0 = Timeticks: (47525) 0:07:55.25
SNMPv2-MIB::sysContact.0 = STRING: someone@youremail.com
SNMPv2-MIB::sysName.0 = STRING: yoursystemname
SNMPv2-MIB::sysLocation.0 = STRING: “Your Location”
…..and so on. You’ll get a ton or results being passed back.
Snmpget functions basically the same way snmpwalk does, except it retrieves specific information. This means if you already have or know the OID you want to poll, you can simply retrieve that bit of information. Check the manual for it the same way you did for snmpwalk.
MIBs:
What the hell?…You’re probably thinking right. Ok, well, you can start to see the MIB information I was talking about earlier. Let me explain a bit further about MIB’s and OID’s.
Take the SNMPv2-MIB::sysLocation.0 = STRING: “Your Location” result it passed back. Remember earlier I mentioned a set of numbers equaled basically a roadmap. syslocation.0 actually equals .1.3.6.1.2.1.1.6.0 with it broke down in integer form. Let’s break out snmpget now so you can see.
[me@mymachine ~] snmpget -v2c -c public localhost .1.3.6.1.2.1.1.6.0 is the same as:
[me@mymachine ~] snmpget -v2c -c public localhost sysLocation.0
Starting to make sense now? The MIB’s point to the specific OID information mainly for sanity’s sake. If you had to remember the numbers all the time, it would all blend together. Let’s check out the actual MIB file.
[me@mymachine ~] cd /usr/share/snmp/mibs <--Here is where all the MIB's are stored.
[me@mymachine ~] vim SNMPv2-MIB.txt
This file holds all the information available for this particular MIB and all the contact information of who maintains it. This file also directly tells SNMP where it relates in the chain of the OID. Scroll down through the file until you locate the sysLocation specifications. It’ll look similar to this:
sysLocation OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
“The physical location of this node (e.g., ‘telephone
closet, 3rd floor’). If the location is unknown, the
value is the zero-length string.”
::= { system 6 }<--Ah, ha! Notice it's pointing to the main system OID referred to earlier.
What this tells you is: 1) it returns a string result, 2) the maximum access level is read-write, 3) just your basic description, and 4) the path to which the answer lies. It's pointing to the system 6 OID...just a path so it knows where to go, in other words .1.3.6.1.2.1.1.6.0.
Get to walking…
There is so much information that can be retrieved via SNMP, that it’s almost ridiculous. You can virtually find anything you want on a remote system information wise. Browse through all the MIB’s and you will start to see the abyss of information it can provide. Of particular interest are the following:
IF-MIB: Interface information
TCP-MIB: TCP related information
UDP-MIB: UDP related information
HOST-RESOURCES-MIB: The biggest MIB of them all. Anything from partitions to every RPM installed on the system
IPV6-MIB: IP version 6 information
Start to troll around in the MIB files and use snmpwalk/snmpget and you will soon get the hang of how to use these tools for reporting purposes. It takes a long time to get good at using these tools, at least it did with myself, but once you use them on a regular basis, you’ll wonder how you got along on your network without them. Once you get the hang of things, you can directly use the tools for monitoring applications such as Nagios. Using Nagios and SNMP together, your system won’t be able to burp without you knowing, if you so desire. For instance, I use Nagios directly with SNMP to monitor temperature probes, disk usage on hosts, services that are running, and certain processes that must be maintained. Now you can read my MRTG how-to after setting up SNMP on all your hosts, and you can start to generate graphs for things such as TCP traffic in and out of hosts. This proves useful down the road for pattern recognition and troubleshooting on your network. Just play around and you’ll get the hang of it…the command line is your friend.
Third party MIBs:
More than likely you are going to have hardware somewhere along the lines that isn’t directly related to Linux. My example of this would be a UPS system. Let’s use an enterprise level UPS such as BestPower as the example. Guess what? If you’re running a BestPower UPS device, you can grab the MIB file off the manufacturer and start to track anything from voltages and current, to load averages on your system.
SNMP is an industry standard. If it’s hardware related, more times than not, the manufacturer has written MIB specifications for it. If you’re unsure, contact the manufacturer or check around online. There are plenty of free MIB sites up and running that provide these files for no charge.
Patience:
Be patient. It takes a lot of playing before things start to click. Get yourself a book and ask questions if need be, after you’ve searched for the answers yourself. As long as you make things read-only, you can’t really harm anything on your network. The time and effort put in learning SNMP pays for itself down the road. Being able to track information proves useful many times, and knowing about problems ahead of time prevents downtime. If you’re learning this on your own, then put it to good use at your place of employment and impress your employers with being able to stay on top of your network. Most of all, have fun!
