Managing a small network isn’t all that difficult. When something doesn’t work, it’s usually obvious where the fault lies. But even for a small network, having some kind of management and monitoring in place is helpful. As your network grows, it becomes even more important to have some tireless automated watchdogs keeping an eye on things.
The computer world is cram-full of monitoring, alerting, and management tools of all kinds, from nice free Open Source applications like MRTG, Cacti, Nagios, OpenNMS, and Mon, to expensive commercial suites that do everything but cook breakfast like ZenWorks, HP OpenView, and Tivoli. These perform a range of different duties, such as network discovery and mapping, providing real-time status indicators, reporting outages, tracking processes, disk usage, restarting downed servers and shutting down devices in trouble.
The one thing these all have in common is they are SNMP-aware. SNMP (Simple Network Management Protocol) has been around since the ’80s. The idea was to create a standard protocol for managing IP (Internet Protocol) devices, rather than having a hodge-podge of different applications and suites that use differing, incompatible client agents.
When you start reading about SNMP, you’ll encounter all kinds of new terminology and abbreviations. There are three main pieces in an SNMP-managed network: network management systems (NMS), sometimes called managers, agents and your managed devices. Agents are software modules in managed devices; think of these as the go-betweens that handle communications between devices and managers. Because SNMP provides a common standard, theoretically all devices with SNMP agents can be managed by any SNMP-aware management applications. Messages originate from both ends: managers can query agents, and agents can volunteer information to managers.
Some devices have agents built-in, like managed switches, routers, printers, power supplies and network access points. You can also install SNMP agents on servers or workstations to monitor just about anything that is monitor-able: CPU temperature, services, database performance, disk space, network card performance — you name it.
There are three versions of SNMP: SNMPv1, SNMPv2, and (guess what!) SNMPv3. SNMPv1 is the most widespread, and probably will be for some time to come. The main objection to v1 is the lack of security; all messages are sent in cleartext. v2 was developed to add security, but it seems that development got a bit out of hand and we ended up with four versions:
- SNMPv2 “star”, or SNMPv2*
Only the first three are documented in RFCs, as a proper standard should be. Though in the case of SNMP, having RFCs may not be helpful because there are skillions of the darned things. Lot of luck sorting them out. v2 also added some new features and functionality, which added complexity, so it’s pretty much a mess.
SNMPv3 is supposed to restore order and sanity, and it is a nice implementation that is easier to use and has real security, so over time it should replace v1 and v2.
There is a common set of SNMP commands across all versions: read, write, and trap. You’ve probably heard of “SNMP traps”. Your manager uses the read and write commands: it polls for device information, which is stored by the agents as variables, and writes commands to devices, which means altering the variables. Managed devices emit traps asynchronously, which means when they have something urgent to say they don’t wait for the manager to ask them what’s up. For example, a router will report that it has lost Internet connectivity, or a server that it is overheating and melting down. Your manager will capture the trap and ideally do something sensible in response.
The ingenuity of SNMP is it doesn’t require the managed devices to do anything other than report state, which places a trivial burden on them, and uses the manager to do all the heavy lifting, like evaluating the information it collects and deciding what to do with it. The NMS doesn’t issue commands, but re-writes variables. This can be a bit weird to wrap your mind around, but the result is a very flexible, low-overhead system that is easy to implement across all kinds of devices by different vendors, and on different platforms.
SMI and MIB
No, not Stylish Mullets Irresistible and Men In Black, but Structure of Management Information and Management Information Base. This is fancy talk for all those device variables and how they are stored. Agents each keep a list of objects that they are tracking; then your manager collects and uses this information in hopefully useful ways. SMI is the syntax or framework used to define objects; MIB is the definitions for specific objects. Every object gets a unique Object Identifier (OID). These are managed in the same way as MAC addresses, with a central registry and unique allocations to hardware vendors.
All versions of SNMP use these five messages: GetRequest, GetNextRequest, SetRequest, GetResponse and Trap, which I believe explain themselves. SNMPv2 uses different message formats and protocol operations than v1, which pretty much renders it non-interoperable with v1. However, there workarounds. Some managers support both v1 and v2, or your v2 agents can act as v1 proxies. This means they translate messages between the manager and agent so that v1 devices can understand them.
RMON, or Remote Monitoring, is part of SNMP. It is an MIB module that defines a set of MIB objects for use by network monitoring probes. The SNMP framework is made up of dozens of MIB modules. Some are freely available, some are deep dark proprietary secrets, and of course you can always write your own. (See Resources for the online MIB validator, and to download MIBs.)
SNMP In Action
In future articles we’ll dig into how to use SNMP with Linux-based network management applications. Until then, you can play around with SNMP to see what it looks like. On Debian, install the snmp andsnmpd packages. On Fedora, net-snmp-utils and net-snmp. The installers should start up the snmp daemon automatically. Then run this command:
#snmpwalk -v 1 -c public localhost system
This should spit out a bunch of output that looks something like this:
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (32) 0:00:00.32 SNMPv2-MIB::sysORID.1 = OID: IF-MIB::ifMIB SNMPv2-MIB::sysORID.2 = OID: SNMPv2-MIB::snmpMIB SNMPv2-MIB::sysORID.3 = OID: TCP-MIB::tcpMIB
Of course the man pages will tell you how to do more fun things, and the excellent O’Reilly book “Essential SNMP, 2nd Edition” by Douglas Mauro and Kevin Schmidt is a great practical guide to understanding and using SNMP.
Want to read the SNMP RFCs? Really? Well, allrighty then. Start here at this handy partial table of the relevant RFCs: