Category: SNMP

The configuration of SNMP on Cisco devices is fairly straightforward, and is handled from global configuration mode. For the purpose of this illustration, I’m going to assume that we’re using a Cisco 2500 router.

The command to enable SNMP on the router is snmp community, followed by the community name. This command also allows you to configure the SNMP agent as read only or for both read and write access. If not specified, the agent will be configured as read only by default. In this case, we’ll set the community name to public, allowing both read and write access. This will allow an NMS to both configure and gather information from our managed device. SNMP settings are configured from global configuration mode.

Router#config t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#snmp ?
chassis-id String to uniquely identify this chassis
community Enable SNMP; set community string and access privs
contact Text for mib object sysContact
enable Enable SNMP Traps or Informs
host Specify hosts to receive SNMP notificationbs
location Text for mib object sysLocation
packetsize Largest SNMP packet size
queue-length Message queue length for each TRAP host
system-shutdown Enable use of the SNMP reload command
tftp-server-list Limit TFTP servers used via SNMP
trap-source Assign an interface for the source address of all traps
trap-timeout Set timeout for TRAP message retransmissions
view Define an SNMPv2 MIB view

Router(config)#snmp community public ?
<1-99> Std IP accesslist allowing access with this community string
<1300-1999> Expanded IP accesslist allowing access with this community
string
ro Read-only access with this community string
rw Read-write access with this community string
view Restrict this community to a named MIB view
<cr>

Router(config)#snmp community public rw

Now that the router has been configured with a community name, SNMP is enabled. An NMS could now gather information from this managed device with Get commands.

Our next step is configuring our agent with the address of an NMS, such that it knows where to forward trap messages when errors occur, or once defined thresholds are exceeded. The first step involves enabling the agent to send traps using the snmp-server enable traps command. The next step is supplying the address of the NMS that will receive these traps, using the smnp-server host command.

Router(config)#snmp-server enable traps
Router(config)#snmp-server host 192.168.1.21 ?
WORD SNMP community string
informs Send Inform messages to this host
traps Send Trap messages to this host
version SNMP version to use for notification messages

Router(config)#snmp-server host 192.168.1.21 public
For the purpose of equipment identification, it is always a good idea to also configure SNMP agents with contact and location information, as shown below.
Router(config)#snmp contact Dan
Router(config)#snmp location Toronto Location A, Main Server Room

To view SNMP statistics for a given system, use the show snmp command.

Router#show snmp
Chassis: 02265778
0 SNMP packets input
0 Bad SNMP version errors
0 Unknown community name
0 Illegal operation for community name supplied
0 Encoding errors
0 Number of requested variables
0 Number of altered variables
0 Get-request PDUs
0 Get-next PDUs
0 Set-request PDUs
2 SNMP packets output
0 Too big errors (Maximum packet size 1500)
0 No such name errors
0 Bad values errors
0 General errors
0 Response PDUs
2 Trap PDUs

SNMP logging: enabled
Logging to 192.168.1.21.162, 0/10, 2 sent, 0 dropped.

Notice that the logging option at the end of the show snmp command output shows what appears to be an invalid IP address. In this case, the trailing “162” represents the UDP port number to which trap messages will be sent on the NMS. Like all configuration information, the SNMP settings on a router can be viewed using the show run command. A truncated version of the output is displayed below.

Router#show run
Building configuration...

Current configuration:
!
snmp-server community public RW
snmp-server location Toronto Location A, Main Server Room
snmp-server contact Dan DiNicolo
snmp-server enable traps
snmp-server host 192.168.1.21 traps public
!
line con 0
transport input none
line aux 0

If there’s one area that’s certain to get people confused when it comes to SNMP, it would have to be the understanding the purpose of a Management Information Base (MIB). The concept isn’t so difficult if you tear away most of the techno-jargon. Every SNMP managed device includes an MIB. Think of an MIB as a database that stores management information about a device. This database is made up of different manageable objects that have properties. For example, one standard MIB object is known as “sysName”. This object can hold a value – the name of the managed device. If an NMS were to query the device for its “sysName”, the value stored in that MIB object would be returned. Similarly, another standard MIB object called “sysUpTime” stores a value that outlines how long a device has been running since its last boot. The MIB stored within a managed device controls how it can be managed via SNMP.

RFC 1213 defines what is known as the standard MIB, which contains 171 manageable objects. All SNMP-manageable devices implement this MIB, which includes various objects capable of measuring and monitoring protocol activity, providing name and description information, and so forth. Furthermore, registered organizations like Cisco can also define their own private MIB extensions that provide additional management capabilities for their particular equipment. Cisco has defined hundreds of manageable objects within their private MIB.

MIBs are defined as part of a tree-like structure. Every MIB object is defined according to a name and associated object identifier (OID) number. The standard SNMP MIB, known as MIB-II, is identified by the OID 1.3.6.1.2.1. It can also be identified by its name – iso.org.dod.internet.mgmt.mib-2. Private organizations (like Cisco) are allocated a branch in the “private” portion of the tree. In particular, Cisco’s OID branch begins at 1.3.6.2.4.1.9. Beneath this portion of the MIB tree, Cisco can define its own private MIB objects, having said that, all objects privately defined by Cisco will start with the OID 1.3.6.2.4.1.9. Similarly, those defined by Microsoft will start with 1.3.6.2.4.1.311.

As mentioned earlier, an MIB is stored within a managed device. While this makes the device capable of being managed by SNMP, an NMS still needs to be configured to know about the particular MIB used by a device, since it probably includes private extensions. Think of it this way. Since vendors can create their own MIB extensions specific to their devices, there are literally thousands of possible MIB objects defined for different products, by different vendors. For an NMS to know about them all would first and foremost be almost impossible, and secondly, a huge waste of resources. To account for this, most NMS products support only the standard SNMP MIB by default. However, vendors usually supply MIB files with their products, and make then available by download from their websites. These MIB files can subsequently be compiled into an NMS, thus making it capable of managing the custom MIB settings of a particular device.

SNMP is a protocol dedicated to gathering network information with as little overhead as possible; SNMP was never designed with security in mind. For example, in SNMPv1 and SNMPv2, the only true security element was the community string. In effect, if a device was enabled for SNMP write access and someone knew the community string, they could make configuration changes to the equipment. In many cases, guessing the community string wasn’t very hard, since many companies never took the time to change it from its default value – public. Obviously this presents a huge security risk, which in turn has led many companies to restrict SNMP access to read only, and in many cases, not enable it at all.

To overcome these limitations, SNMPv3 implements a true security model that provides for message integrity, authentication, and encryption. Each of these concepts is considered below:

• Message integrity. Used to ensure that an SNMP message has not been tampered with in transit by a third party.

• Authentication. Used to ensure that the source of the SNMP message is from a valid source. SNMPv3 is capable of using a common username, as well as MD5 or SHA algorithms to provide secure authentication between SNMPv3 devices.

• Encryption. Used to securely scramble the contents of SNMP messages to ensure secure transmission between an NMS and a managed device. SNMPv3 is capable of using 56-bit DES encryption for transmitted packets.

Ultimately, SNMPv3 represents a significantly improvement over previous versions from a security standpoint. However, it’s still important to remember that in order to use SNMPv3, you will require both an NMS and managed devices that support it. Depending upon the IOS version installed on your router, you may or may not be capable of supporting it at the current time. Cisco has supported SNMPv3 in their routers since IOS version 12.0.3T.

As part of the configuration of a managed device, you can also identify whether it should be configured for read access, write access, or both. If configured for read access, an NMS like HP OpenView can gather information about the device. If configured for write access, an NMS can also configure the device using SNMP commands. The choice will depend upon whether you want to use the NMS strictly for gathering information or for configuration purposes also.

The “simple” part in the Simple Network Management Protocol relates to the fact that the interactions between managed devices and an NMS aren’t terribly complex. In the original version of SNMP (SNMPv1), only four operations are possible between an NMS and a managed device. There are outlined below:

• Get. The Get operation is used by an NMS to obtain a single piece of information from a managed device. For example, the NMS may be requesting the device’s configured name. “Get” is a read operation.

• GetNext. The GetNext operation is issued by an NMS in order to obtain more than one piece of information from a managed device. For example, the NMS may wish to obtain both the name and system uptime of a particular device. In SNMPv1, when an NMS wants to obtain multiple pieces of information from a managed device, its only option is to issue Get and GetNext commands. “GetNext” is also a read operation.

• Set. The Set command is used by an NMS to configure a managed device with a particular value. For example, maybe the NMS wants to configure or “set” a threshold on a managed device that tells it to alert the NMS if its CPU utilization hits 70% for a defined period of time. “Set” is a write operation.

• Trap. A Trap operation is different that those described above, because it is initiated from a managed device. A trap message is used to alert an NMS to the fact that a threshold defined by the NMS (with the set command) has been reached, or that an error/event of some type has occurred. For example, a router may have been configured to set a trap message to an NMS when its average CPU utilization is over 70% for a period of one minute. Trap messages are said to be asynchronous, in that a managed device sends them without a request from an NMS.

SNMPv2 introduced two additional SNMP commands:

• GetBulk. The GetBulk operation was implemented to allow NMSs to obtain multiple pieces of information from a managed device in a single request. It’s important to note that this command is not supported on devices using SNMPv1. “GetBulk” is a read command.

• Inform. The Inform operation allows an NMS to forward trap information to other NMSs.

As mentioned earlier, SNMP was designed to use UDP as its transport protocol. This is part of what helps make SNMP “lightweight”, since the session establishment overhead associated with TCP is avoided. When an NMS wants to configure a managed device or gather information from it, it will make a request to that device, destined for UDP port 161. As with most exchanges in the world of TCP/IP, the source port will usually be chosen dynamically.

Perhaps the most important feature of SNMP from a monitoring perspective is the ability of a managed device to send trap messages to an NMS asynchronously. In other words, when an error occurs on a device, or when one of the thresholds previously “set” by the NMS is reached, the managed device will automatically send a trap message to its configured NMS. Trap messages from a managed device are sent to UDP port 162 on the NMS.

Three versions of SNMP have been standardized – SNMPv1, SNMPv2, and SNMPv3. While the versions all work in a similar manner, they are not directly compatible. Some of the differences between the versions include:

• SNMPv2 and SNMPv3 include additional commands not available in SNMPv1.
• In SNMPv1 and SNMPv2, security is based on a very simple administrative grouping known as a community. SNMPv3 is the most secure of the versions, including features that provide message integrity, authentication, and encryption.

Having said that, many vendors (including Cisco) have made their devices “multilingual”, meaning that they are capable of using SNMPv1, SNMPv2, SNMPv3, or even different versions concurrently. Along the same lines, most SNMP NMSs are also “multilingual”.

The Simple Network Management Protocol (SNMP) is an application-layer communication protocol that provides a standardized method for managing network devices. The protocol is part of the TCP/IP protocol suite and uses UDP as its transport protocol.
In order to better appreciate how SNMP works, let’s begin by taking a look at the different components of an SNMP-based system – managed devices, agents, and network management systems.

• Managed Devices. A managed device is any piece of equipment that includes the ability to be managed via the SNMP protocol. Common examples include hubs, switches, routers, printers, and servers.
• Agents. A managed device includes a software module known as an agent. An agent implements the SNMP protocol on a device, allowing information about the device to be stored and retrieved. The terms “agent” and “managed device” are often used interchangeably when discussing SNMP.
• Network Management System. An SNMP Network Management System (NMS) is an application capable of monitoring and configuring SNMP managed devices. Examples of common NMSs include HP OpenView, SunNet Manager, and TNG Unicenter. These applications act as the focal point on an SNMP-managed network, where data is collected and configuration is carried out. In order to use SNMP to manage a network, at least one NMS must be present. NMSs are also sometimes referred to as consoles.