SNMP Protocol Messages - Get, Set, and GetResponse

SNMP Protocol Messages - Introduction

Early on in this tutorial, when I discussed the components of SNMP, I explained that one of the components of SNMP is the protocol for the exchange of messages. To achieve its goal of being simple, SNMP has a limited set of managment commands and responses. The initial version of SNMP had only five operations. However, there is always some tension between simplicity and functionality, and in SNMPv2 a few more operations were added. With the original operations, the managment system could issue GetRequests (to retrieve or read the value of one or more object instances), GetNextRequests (whose purpose and function will be elaborated on in the next chapter), and SetRequests (to write or establish the value of one or more object instances). In response to any of these requests, a managed agent sends a Response message. A managed agent also sends an event notification, called a Trap to management systems predefined to it for this purpose, to identify the occurrence of exceptional situations.

SNMPv2 introduced two additional operations: GetBulk and Inform, each of which will be addressed in subsequent chapters - the GetBulk in the next chapter and the Inform will be discussed in the chapter on traps.

Protocol operations in SNMP encapsulated in what are called PDUs (Protocol Data Units), which are encapsulated in a message header. In this chapter, I will only discuss the PDU format for SNMPv2, as it replaces the SNMPv1 format (even though there are many SNMPv1 agents still out there). The additions made for security and other changes in SNMPv3 will be discussed in a later chapter. Figure 41 depicts the SNMPv2 general message format. The top message is the most general. I then focus on the PDU portion in the second frame, and in the bottom frame I zoom in on the Variable Bindings section.

Figure 41: SNMPv2 Message (all but GetBulk)

The header contains two fields: The Version is a 4-byte field, to maintain compatibility between versions. We can assume that there is old and new equipment, so the old versions won't just disappear from the scene. SNMPv1 has version 0 and SNMPv2 has version 1 (to be more specific, SNMPv2c - there were other versions of v2, but v2c is the one that was standardized by the IETF). The second field, the Community, is a poor excuse for a security model, which we will discuss in a later chapter.

In the PDU itself, the PDU type indicates what type of operation the message is performing, for example, 0 for GetRequest, 2 for Response, 7 for (SNMPv2) Trap. The Request ID is a number used to match requests with replies. It is generated by the device that sends a request and copied to this field in the Response-PDU by the responding agent. The Error Status and Error Index are set to zero (or are ignored) in GetRequest, GetNextRequest, and SetRequest messages. These fields are also set to zero in the Response, if there is no error to be indicated. However, if the agent had an error when processing the response, then the Error Status is set to a value, for example, 10 for wrongValue and 17 for notWritable, which would be sent if a manager tried to set a value that is read-only. In the case that the Error Status is non-zero, if the Error Index is also non-zero, then this index value refers to the variable binding (object instance+value) in the list that has a problem, and the other variable bindings are valid. If the Error Status is non-zero, but the Error Index is equal to zero, all the variable bindings are invalid - the error probably cannot be pinpointed to just one of the bindings. The use of these fields is a bit different in SNMPv1. One of the improvements in SNMPv2 over SNMPv1 is the error handling, including more detailed error codes. For example, in SNMPv1 an error code could indicate badValue, but in SNMPv2 the agent can be more specific and select from wrongValue, wrongEncoding, wrongLength, etc.

The variable bindings list is a list of pairs of object instance+value. If the message contains a GetRequest, the values are null, but in a SetRequest or a Response, the values are present, of course. Permitting multiple variable bindings in a PDU means that we don't need an SNMP request and response for each variable, which is a good thing! I can request the entire system group in one message, for example.

OK, I won't bore you with further details of error codes and the like - if you need to know that sort of excruciating detail, the best source is RFC 3416, and other relevant RFCs are listed in the References page. Instead, we'll try some hands-on activities, which are a lot more fun and illustrate the concepts.

Set Up Packet Capture Software for Hands-On Activity

In this hands-on activity, we will perform a get operation and a set operation and we will want to capture the packets so that you can see the message format, as described above. I'll show some packet capture results, but you'll get a lot more out of the activity if you try it yourself. If you have packet capture software installed on your computer, perhaps because you installed it for the RAD University DNS Tutorial, or if you have such software or a hardware device accessible in your network, you can skip to the next section. Otherwise, I strongly recommend that you go to the effort to install a packet capture program, such as Wireshark (which I highly recommend and which is freeware). You can install the software (as directed on the website). If you like computer networking and protocols, you'll find it helpful.

Hands on Get, Set, and Response

We will use BlackOwl as our management software, so now to set up an agent! The ideal situation would be if you have access to a device with an SNMP agent. You might actually have such a device at hand - many of the home routers are SNMP-compliant (though mine isn't). If you do, the documentation should have information about this agent. To manage it with SNMP, you need to know its IP address (presumably that is the address defined in your computer as your default gateway). You also need to know the community string for read operations and the community string for write operations. A community string is roughly similar to a plain-text password (and therefore not secure at all), and I will discuss it in the chapter on security and SNMPv3. In the meantime, treat it like a password - typically, the default community string for read operations is "public" and for write operations "private", but the documentation for your device should have this information.

If you don't have an SNMP-compliant device handy, don't despair - there are two other options for you to work with in this hands-on activity. The next option is to turn on the SNMP agent in your Windows computer (assuming you are using Windows, which has quite a high likelihood). If you are using Linux, for example, you also could activate an SNMP agent, but I will not explain how to do that here. To activate you SNMP agent in Windows, right-click on the My Computer icon and then select Manage from the little pop-up menu. You'll get a Computer Management window. In the left-hand menu, expand on the Services and Applications item and select Services. In the right-hand list that appears, scroll down until you see the SNMP Service, as seen in Figure 42.

Figure 42: Managing the SNMP Service in Windows

If the service is not running, you can start the service by clicking - see where it is circled in red in Figure 42. Or, you can right click on the selected service and start it from the little pop-up menu. If you right click on the service, the little pop-up menu also has an option for Properties. Select that and you get a window that allows you to define some of the agent's properties. If you are doing this, go ahead and define the agent details. The contact name will be the information contained in the value of the object sysContact and the location will be the value of sysLoc from the System group. The services (I selected those that were not yet checked) will be reflected in the sysServices object value, as seen in Figure 43.

Figure 43: Configuring the Windows SNMP Agent

If you click the Security tab, you will see that the default READ ONLY community string is already defined to "public". You can add another community string for READ WRITE, as I did in Figure 44. We won't do anything fancier than that (CREATE is to add a row to a table - you need a fancier management system than BlackOwl for that).

Figure 44: Configuring the Windows SNMP Agent Community Strings

After you configure your agent, restart the service (same way you started the service) for the information to take effect.

As a fallback position, if you don't have access to an SNMP agent on your network, I will provide a packet capture file that you can open with Wireshark. If you use the Windows computer that you are working on as your SNMP agent, you will be able to perform operations and see the output in BlackOwl, but you will not be able to capture any packets for those operations, because the messages do not leave your computer (even if you address it by its IP address), so you can use the file I provide.

As a fall-furthest-back position, if you don't even set up the SNMP agent on your computer or install packet capture software, you can follow along by looking at the images that I display. But I do hope you'll do this together with me!

Before we proceed to the activity, I will say a few words about Basic Encoding Rules (BER). When discussing MIBs, I explained that the Structure of Management Information uses a formal notation language called ASN.1. The SMI also specifies that the messages be encoded for transmission using encoding called BER. BER is a set of rules defined to translate ASN.1 into a stream of octets to be transmitted across a network. However, when we capture packets, the packet capture software is able to decode the messages. I have decided that I will not discuss BER in this tutorial, as the only people that really need to understand it are those who implement that portion of an application that must do the encoding. People who use SNMP, who write MIBs, who integrate off-the-shelf SNMP agents, etc. do not need to implement BER. Those who do will be turning to documentation more technically detailed (and boring) than this tutorial. A brief explanation of BER is included in the SNMP Tutorial from the Poznan University of Technology (Poland), but if you get sidetracked with that tutorial, don't forget to come back!

OK, is your agent up? Open BlackOwl and switch to the Tree view. Expand your tree so that you see the System group's objects. Notice that in the top right frame the Host named (by default) is "localhost". So, if you query "localhost" you will get information for your computer (assuming you turned on the agent). We can choose the object whose value we wish to get and use the "get" button. (The community string for READ is set, by default, to "public", so we don't need to configure that.) When you click on the "get" button" you'll get a small window that gives details of the command you want to send. You can click "OK". I'll do that for several objects, and the results appear in Figure 45.

Figure 45: Get Operation on Localhost

Notice that the sysContact and sysLocation are the values that I defined when I configured my agent (in Figure 43). The sysLocation is writeable (look at the MIB definition to see that the MAX-ACCESS is read-write; and you can also see it in the MIB view in your MIB browswer). So let's change the value of sysLocation. To do that, we must first define the community string for READ WRITE access. Click on the "Properties" button in the top right frame in BlackOwl and define the community string as you defined it for your agent, as shown in Figure 46, and be sure to select SNMPv2c, the version that we are using (we haven't yet discussed secure SNMPv3, and the Windows agent doesn't support that, anyway, nor do the agents I will access in my network).

Figure 46: Defining the Community String to be Used by BlackOwl

Now select the object sysLocation and click on the "set" button. You can enter the value that you want for the sysLocation, as I did in Figure 47.

Figure 47: Entering the Value for sysLocation

You can see the result of the set operation - my system location changed - in Figure 48.

Figure 48: Changed Value for sysLocation

If you have access to an SNMP agent on the network, you can start your packet capture program and then repeat this activity after entering the IP address of the device (remember to define the community string for READ WRITE). Stop your packet capture to examine the results. I will display a "get" message, its "response" message, a "set" message, and its "response" message in Figures 49-52, and if you are unable to capture your own packets, you can dowload my capture file and open it with Wireshark. Even if you do not capture your own packets, I encourage you to take the time to examine my capture file yourself. Pay attention to the fact that the community string (public for the "get" and "private" for the "set") appears in plain text - you can look at the hexadecimal display and its interpretation in the bottom frame. We'll address that issue in the chapter on security and SNMPv3. Notice that the object is named by the OID, with a zero at the end because these objects are scalars. Compare the captured information to the message format that I described above. In short, examining a packet capture gives you the opportunity to be sure that you understand the total picture, including the protocol layers, the request-response nature of the protocol (compare the values of the request ID), etc.

Figure 49: getRequest sysContact

For those of you who are not familiar with the Wireshark display, you can see that there are three information "panes": (from top to bottom) a packet summary, a packet detail, and the hexadecimal dump with ASCII text translation. The packet in the upper pane highlighted in royal blue is the packet detailed in the middle pane and is displayed in the hex dump. Selecting a field to be highlighted in the middle pane will highlight the corresponding portion in the hex dump.

Figure 50: getResponse sysContact

Figure 51: setRequest sysLocation

Figure 52: getResponse sysLocation

As you can see, there is no difference between a response to a getRequest and a response to a setRequest. The getResponse message serves as an acknowledgment in the latter case. The management system recognizes this by virtue of the request ID - it matches the request ID of the setRequest that was sent. Since SNMP runs over UDP, there is no other acknowledgment of a request sent, so if a setRequest were sent and acted upon properly, without a getResponse message, the only way that a management system would have to verify that its request was carried out would be by sending a getRequest. It's clearly more efficient for the agent to send a getResponse, which serves as an acknowledgment at the application level.

We'll look at examples of actions on non-scalar objects in the next chapter. But before that, there are two more activities that you might enjoy, below.

Interactive Applet

This interactive Java Applet demonstrates the message exchange in SNMP and the logical structure of management information. The messages you can construct include types we have not yet looked at, but you can certainly review what you've learned so far by trying the Applet with the "get" and "set" operations! The options permit you to change the transport layer to TCP, something that was included as an option in SNMPv2, but is not likely to be found implemented.

The Simpleweb Interactive Tutorial

The Simpleweb has a terrific tutorial with a demo MIB, with which you can try out your knowledge of SNMP. You have to enter the OID on which you want to operate, which means it tests your understanding of the OID and the management information tree. I suggest that you also purposely put in OIDs that are erroneous, to see the errors that are returned; try setting an object that is read-only (the only one that can be set is "name"); try choosing the wrong type when performing a "set" - and take a look at the errors that you've generated. Again, in the meantime, just try out "get" and "set". Notice on the left-hand menu, if you want to compare to SNMPv1 (in particular the error handling), you can do that. Have fun! It's a nice demo! And when you are ready, go on to find out about getNext and getBulk.

Previous Next

www.rad.com