Pruebas y análisis de resultados

As we installed the dependencies and compiled Zabbix server with SNMP support, all that's left to do is setting up SNMP monitoring configuration. Before we do that, we'll need some device that has an SNMP agent installed. This is where you can choose between various options—you can use any networked device that you have access to, like manageable switch, network printer, UPS with SNMP interface, and so on. As SNMP agents usually listen on port 161, you will need the ability to connect to such a device on this port over UDP. Although TCP is also supported, UDP is much more widely used.

If you don't have access to such a device, you can also start up an SNMP daemon on a computer. For example, you could easily use "Another Host" as a testbed for SNMP querying. Many distributions ship with the SNMP daemon from the Net-SNMP package, and often it is enough to simply start snmpd service. If that's not the case for your chosen distribution, you'll either have to find one of those networked devices with an SNMP agent already available, or configure snmpd manually.

Whichever way you choose, you will have to find out what data the device actually provides and how to get it. This is where Net-SNMP comes in, providing many useful tools to work with SNMP-enabled devices. We will use several of these tools to discover information that is needed to configure SNMP items in Zabbix. Let's start by verifying whether our SNMP device is reachable and whether it responds to our queries.

While SNMPv3 is the current version of SNMP since 2004, it is still not as widespread as versions 1 and 2. There's a whole lot of old devices in use that only support older protocol versions, and many vendors do not hurry with SNMPv3 implementations.

To complicate things further, SNMPv2 also isn't widely used. Instead, a variation of it, the community-based SNMPv2 or SNMPv2c, is used. While devices can support both v1 and v2c, some only support one of these. Both use so called "community" authentication, though user authentication is performed based on single community string. Therefore, to query a device you would have to know which protocol version it supports, and the community string to use. Though it's not as hard as it sounds; most devices use common string for access—"public", as does Net-SNMP daemon. Unless you explicitly change this string, you can just assume that's what is needed to query any host.

If you have installed and started Net-SNMP daemon on "Another Host", you can do a simple query to verify SNMP connectivity:

$ snmpstatus -v 2c -c public <IP address>

If the daemon is started correctly and network connectivity is fine, you should get some output, depending on what system you have:

[UDP: <IP address>:161]=>[Linux zab 2.6.16.60-0.21-default #1 Tue May 6 12:41:02 UTC 2008 i686] Up: 20:17:40.28

Interfaces: 3, Recv/Trans packets: 108105509/35678987 | IP: 48381196/35649135

1 interface is down!

We can see here that it worked, and by default a connection was made over UDP to port 161. We can see the target system's operating system, hostname, kernel version, when was it compiled and what hardware architecture it was compiled for, as the well as current uptime. There's also some network statistics information tucked on. If you are trying to query a network device, it might have restrictions on who is allowed to use SNMP agent. Some devices allow free access to SNMP data, some restrict it by default and every connecting host has to be allowed explicitly. If a device does not respond, check it's configuration—you might have to add IP address of the querying machine to the SNMP permission list.

Looking at the snmpstatus command itself, we passed two parameters to it—SNMP version (2c in this case) and community (which is as discussed before, "public"). If you have other SNMP-enabled hosts, you can try the same command on them. Let's look at some different devices:

$ snmpstatus -v 2c -c public <IP address>

[UDP: [<IP address>]:161]=>[IBM Infoprint 1532 version NS.NP.N118 kernel 2.6.6 All-N-1] Up: 5 days, 0:29:53.22

Interfaces: 0, Recv/Trans packets: 63/63 | IP: 1080193/103316 As we can see, this has to be an IBM printer. And hey, it seems to be using a

[ 110 ]

While many systems will respond to version 2c queries, sometimes you might see the following:

$ snmpstatus -v 2c -c public <IP address> Timeout: No Response from <IP address>

This could of course mean network problems, but sometimes SNMP agents ignore requests coming in with protocol version they do not support or an incorrect community string. If the community string is incorrect, you would have to find out what it has been set to; this is usually easily available in the device or SNMP daemon configuration (for example, Net-SNMP usually has it set in the configuration

file /etc/snmp/snmp.conf). If you believe a device might not support a particular protocol version, you can try another command:

$ snmpstatus -v 1 -c public <IP address>

[UDP: [<IP address>]:161]=>[HP ETHERNET MULTI-ENVIRONMENT,SN:

CNBW71B06G,FN:JK227AB,SVCID:00000,PID:HP LaserJet P2015 Series] Up: 3:33:44.22

Interfaces: 2, Recv/Trans packets: 135108/70066 | IP: 78239/70054 So this HP LaserJet printer did not support SNMPv2c, only v1. Still, when queried using SNMPv1, it divulged information like the serial number and series name. Let's look at another SNMPv1 only device:

$ snmpstatus -v 1 -c public <IP address>

[UDP: [<IP address>]:161]=>[APC Web/SNMP Management Card (MB:v3.6.8 PF:v2.6.4 PN:apc_hw02_aos_264.bin AF1:v2.6.1 AN1:apc_hw02_sumx_261.bin MN:AP9617 HR:A10 SN: ZA0542025896 MD:10/17/2005) (Embedded PowerNet SNMP Agent SW v2.2 compatible)] Up: 157 days, 20:42:55.19

Interfaces: 1, Recv/Trans packets: 2770626/2972781 | IP: 2300062/2388450

This seems to be an APC UPS, and it's providing a lot of information stuffed in this output, including serial number and even firmware versions. It also has considerably longer uptime than the previous systems—157 days.

But surely there must be more information obtainable through SNMP and also this looks a bit messy. Let's try another command from Net-SNMP arsenal, snmpwalk. This command tries to return all the values that are available from a particular SNMP agent, so the output could be very large—we'd better restrict it to few lines at first. $ snmpwalk -v 2c -c public 10.1.1.100 | head -n 6

SNMPv2-MIB::sysDescr.0 = STRING: Linux zab 2.6.16.60-0.21-default #1 Tue May 6 12:41:02 UTC 2008 i686

SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10

DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (8411956) 23:21:59.56 SNMPv2-MIB::sysContact.0 = STRING: Sysadmin (root@localhost)

SNMPv2-MIB::sysName.0 = STRING: zab

SNMPv2-MIB::sysLocation.0 = STRING: Server Room

As we can see, this command outputs various values; with a name or identifier displayed on the left, and value itself on the right. Indeed, the identifier is called

object identifier or OID, and it is a unique string, identifying single value. Looking at the output, we can also identify some of the data we saw in the output of snmpstatus—SNMPv2-MIB::sysDescr.0 and DISMAN-EVENT-MIB:: sysUpTimeInstance. Two other values, SNMPv2-MIB::sysContact.0 and SNMPv2-MIB::sysLocation.0 haven't been changed from the defaults, and thus aren't too useful right now. While we are at it, let's compare this output to the one from APC UPS:

$ snmpwalk -v 1 -c <IP address> | head -n 6

SNMPv2-MIB::sysDescr.0 = STRING: APC Web/SNMP Management Card (MB: v3.6.8 PF:v2.6.4 PN:apc_hw02_aos_264.bin AF1:v2.6.1 AN1:apc_hw02_sumx_ 261.bin MN:AP9617 HR:A10 SN: ZA0542025896 MD:10/17/2005) (Embedded PowerNet SNMP Agent SW v2.2 compatible)

SNMPv2-MIB::sysObjectID.0 = OID: PowerNet-MIB::smartUPS450

DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (1364829916) 157 days, 23:11:39.16

SNMPv2-MIB::sysContact.0 = STRING: Unknown SNMPv2-MIB::sysName.0 = STRING: Unknown SNMPv2-MIB::sysLocation.0 = STRING: Unknown

The output is quite similar, containing the same OIDs, and the system contact and location values aren't set as well. But to monitor some things, we have to retrieve single value per item and we can verify that it works with another command, snmpget. $ snmpget -v 2c -c public 10.1.1.100 DISMAN-EVENT-MIB::sysUpTimeInstance

DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (8913849) 1 day, 0:45:38.49

We can add any valid OID, like DISMAN-EVENT-MIB::sysUpTimeInstance in the above example, after the host to get whatever value it holds. Let's look closer at the OID itself. In its current form, it consists of two parts, separated by two colons. The first part is the name of management information base or MIB. MIBs are collections of item descriptions, mapping numeric OIDs to textual ones. The second part is uniquely identifiable descriptor from this MIB, so such a pair can be used to refer to single, specific value. We can see full OID by adding a the flag -Of to modify the output: $ snmpget -v 2c -c public -Of 10.1.1.100 DISMAN-EVENT-MIB::

[ 112 ]

That's a considerably long name, showing the tree-like structure. It starts with a no-name root object, and goes further with all the values attached at some location to this tree. Well, we mentioned numeric form, and we can make snmpget output numeric names as well with the flag -On:

$ snmpget -v 2c -c public -On 10.1.1.100 DISMAN-EVENT-MIB:: sysUpTimeInstance

.1.3.6.1.2.1.1.3.0 = Timeticks: (9048942) 1 day, 1:08:09.42

So each OID can be referred to in one of three notations—short, long, or numeric. In this case, DISMAN-EVENT-MIB::sysUpTimeInstance, .iso.org.dod.internet. mgmt.mib-2.system.sysUpTime.sysUpTimeInstance, and .1.3.6.1.2.1.1.3.0 all refer to the same value.

You can look at mansnmpcmd for other supported output

formatting options.

But how does this fit into Zabbix SNMP items? Well, to create an SNMP item in Zabbix, you have to enter an OID. How do you know what OID to use? Often you might have the following choices:

Just know it Ask somebody Find it out yourself

More often than not first two options don't work, so finding it out yourself will be the only way. As we have learned, Net-SNMP tools are fairly good at supporting such a discovery process.