Components and Architecture
Management Components
There are four basic components of SNMP:
- Managed nodes or network elements, each of which contains an agent
- At least one Network Management Station (NMS)
- Management information
- A network management protocol, which is used by the NMS and the agents to exchange management information
A managed node can be any system, including a software system, that has some kind of network connectivity. In fact, in the very early days of SNMP, in an attempt to demonstrate the versatility of SNMP, a company called Epilogue showed (at an Interop show in 1990) how SNMP could be used to manage any network connected device, such as a toaster. On this page, found using Google, John Romkey describes this event:
While I was at Epilogue, we created an Internet Toaster for Interop in 1990. I wanted to get people thinking of SNMP not just as getting variables, but for control applications, a wider vision. So we had an SNMP controlled toaster. If you put bread in the toaster, and set a variable in SNMP, the toaster would start toasting. There was a whole MIB written up for it, including how done you wanted the toast, and whether it was a bagel or Wonderbread. In order to figure out a matrix of how long to toast a bagel or Wonderbread to get it done to a specific doneness, I ended up with lots and lots of bread in my garage. ... The Internet Toaster got a lot of attention because of the novelty of it ... to have a Toaster connected to an Ethernet shows a lot about the state of the technology and where it can go.
If you didn't understand all of the terminology in that quotation - not to worry! Reread it after you complete this tutorial. Well, that might not help you know what Wonderbread is - that's a US-centric cultural thing (you didn't really click on that link, did you? Are you that bored? In the Arts&Crafts section they even have instructions on how to make clay out of Wonderbread and glue! Don't ask me. I was taught not to play with my food.). But after reading this tutorial you will know what a MIB is.
The agent contained in each managed node implements the SNMP protocol. The agent is capable of sending, receiving, and parsing SNMP messages. By interfacing with the device's functional (i.e., "useful") portion, the agent is capable of retrieving the necessary information from the device to answer queries from the NMS and to send trap messages (unsolicited notification messages). The agent is also capable of writing configuration changes to the device, according to requests sent from the NMS. Read and write privileges for one or more NMSs are defined to the agent with an access control configuration that is defined "out-of-band", i.e, by some method other than with SNMP, such as via a terminal, telnet or a Web ( HTTP) interface.
A Network Management Station (NMS) is a host that is capable of sending SNMP requests and receiving and parsing SNMP replies and trap messages to/from managed nodes. There are many commercial NMS software packages available, and typical features include the ability to "discover" manageable nodes using one of several methods - typically "brute force" approaches such as first "pinging" every address in a range and then sending a basic SNMP query to those IP addresses that respond to the ping. Such software packages will graphically display the managed nodes, using icons to indicate what type of device each node is (which can be learned, as you shall see, with SNMP queries). There might be display of status information, statistics, etc., in various graphic formats, thereby allowing network managers to manage hundreds or even thousands of nodes.
At the very other end of the spectrum, a network management station might be a simple host computer at which a network manager enters commands at an operating system prompt with a text-based interface. Clearly, if a manager has numerous devices to manage, this is not very convenient. For our learning purposes, we will use a public-domain software package that is at the quite low end of the spectrum as far as "fanciness" is concerned, but is more sophisticated than a command-driven system. The benefits of using such software (other than its attractive price) are that its graphical interface is sufficient to reduce the burden of remembering commands and it is capable of displaying the management information in a manner that will facilitate understanding the structure of this information. All NMSs must be capable of parsing and understanding the management information (the data that the NMS reads or writes to/from the managed device). To understand how SNMP works, it is vital to look at this structure, which we will do.
This brings us to the third component in the network management architecture: the management information. This, of course, is the information that is exchanged between managed nodes and NMSs. We will use the term managed object to mean a definition of a unit of management information. Do not get confused and think of a managed object as a managed device. It is not! A managed object is an abstract concept - it is the definition of some kind of information. For example, suppose we had a device whose color could be changed at will. We could define a managed object called "color" and the corresponding definition could be "the color of the device".
We call a a collection of related managed objects, which are defined in a document, a MIB (Management Information Base) Module. You'll see that there are some standard MIB modules - commonly just called MIBs - that all devices that meet the SNMP standard must support. There are other standard MIB modules that should be supported by devices for which the MIB is relevant. And there are vendor-specific private MIBs that contain definitions of managed objects specific to that vendor's products.
For example, all SNMP-managed devices must have certain information such as an IP address. This type of information would be defined in a standard MIB that all devices must support (to be considered SNMP-compliant). If the device has an Ethernet interface, there is some information that it should be able to provide, such as the number of collisions, and this information is defined in an Ethernet MIB, which all devices with an Ethernet interface should support. Lastly, suppose we are talking about an Ethernet switch, something quite ubiquitous. One particular vendor wants to offer a feature that will make its device more attractive to customers - the switch can change colors according to the decor of the wiring closet. Cool! So the vendor's private MIB would have a management object defined for that purpose.
So, MIBs contain the managed objects that represent the resources, configuration, status, etc. of a system. The managed objects have values assigned to them. The objects themselves are not values! Using our "color" example, if the object is called "color" and its definition is "the color of the device", the value assigned to it might be 0 for black, 1 for blush pink, 2 for steel gray, 3 for mold green, etc. In that case, the object is actually an integer, and the value of the integer will represent the color. It is the values of the management objects that may be monitored and modified by an NMS, perhaps to control the behavior of the system.
If I want to change the color of my switch to blush pink (the factory default color is black), I would want to set the object "color" to the value 1.
This brings us to the last component of the management architecture: the network management protocol. You might ask: "Isn't that what we call 'SNMP'? Isn't that the management protocol?" Well, SNMP is that and more. SNMP defines the MIBs, the architecture, and the protocol for the exchange of messages. It is this latter aspect - the protocol for the exchange of messages between managed nodes and NMSs, including the message types and formats - that we refer to as this last component.
We will see that there are several types of SNMP messages, and these permit the NMSs to read and/or write information, and the agents to send unsolicited "trap" messages, which are intended to be a kind of alarm or notification. The details of the MIBs and the messages will be discussed in later chapters.
Management Architecture
Like most of the applications that you are probably familiar with (e.g., DNS, FTP, etc.), SNMP employs a client-server architecture. As you probably know, in such an architecture, clients initiate communications by sending a request for a service, request for a connection, or a query. Servers passively await such requests. SNMP, being a member of the Internet suite of protocols (often called the TCP/IP suite of protocols, even if the transport layer is not TCP, but UDP, as in the case of SNMP), uses well-known port numbers on the server side to identify the application layer protocol.
Referring to Figure 3 below, since it is the NMS that initiates SNMP queries, while the agents in the various managed devices - printer, router, switch, toaster - passively await queries, we would say that the NMS is the client and the agents are servers. Port 161 is the well-known port number that is assigned to the SNMP application, so that agents listen to port 161 for queries.
Figure 3: Management Architecture
However, SNMP actually contains two client-server applications: the SNMP query/response protocol and the SNMP trap protocol. Traps, as I've mentioned, are unsolicited messages sent by the agents, intended to be used for alarms or as a notification of an unusual event. Since the agent is the initiator of a trap, we can't very well say that the agent is acting as a server when it sends a trap! Rather, the agent is then acting as a client, and the NMS, which is configured to receive traps from devices that it manages, acts as a server, listening on a different well-known port, port 162, for trap messages. On IANA's (IANA is the Internet Assigned Numbers Authority) list of well-known port numbers, you can see that port 161 is listed as the port for SNMP and 162 is listed as the port for SNMPTRAP. Thus, the NMS usually acts as a client, but sometimes acts as a server. And an agent usually acts as a server, but also can act as a client.
However, unlike the typical client application, when using the "trap application", the agent does not expect any kind of response! At least not a message response. There might be a human or other out-of-band response to a trap, but SNMP was designed to require a minimum of resources from agents (the devices are best off putting their energy into what their real task is, such as routing), and therefore, an agent is not expected to maintain a status or state machine regarding the traps that it sends. Further, traps might be sent as an alarm to signal some kind of serious failure - say, "my temperature has reached the danger point!". The agent might be in no physical state to receive an acknowledgment or message in response. It sends the trap with the hope that its manager(s) is listening! (We will see that a type of acknowledged trap called an InformRequest was also defined, as a later addition to SNMP.)
Protocol Architecture
I already mentioned that as a member of the TCP/IP suite, SNMP uses well-known port numbers for the server applications. I also mentioned in a parenthetical remark that SNMP uses UDP as its transport layer. We will see that there is a TCP option, not commonly used, and only reluctantly added to the protocol definition.
In principle, SNMP was defined to use UDP as its transport layer so as to minimize the resources needed by agents to implement the protocol. SNMP really is well-suited to be a UDP-based application. The responses to queries - and every query, whether a read operation or a write operation has a response - serve as acknowledgments to the queries. There is no need to send an ACK to a query if you are sending a response! The queries are relatively short messages, so that segmentation can be avoided. There is also no need for a retransmission mechanism. If an NMS does not get a response from an agent, it will simply send the query again, and if after trying two more times there is no response, the NMS better start worrying about the functioning of the agent (or its reachability).
And, an agent really doesn't care if the responses it sends were received. It doesn't want an ACK for those messages. If the NMS did not receive the sent response, the agent will hear from it again (unless there is a network problem, and it is up to the human who is responsible for the NMS to worry about that!). I already pointed out that an agent isn't interested in getting an ACK to traps that it sends.
This is expressed so succinctly in the inimitable style of one of the "fathers" of SNMP, Dr. Jeffrey Case, who used to have a column called Ask Dr. SNMP in a newsletter called The Simple Times. The Simple Times started publication in the exciting early days of SNMP, and lasted about 10 years. In answer to a concern about using UDP as the transport for traps, Dr. Case responded (Volume 1, Number 2):
... regarding the "design defect" of using the connectionless UDP, this is not a bug, it is a feature. Part of the success of the SNMP framework is as a result of the correct selection of a connectionless transport service.
So-called "reliable" transport protocols achieve reliability through retransmission. After sending a message, when an acknowledgement is not received in a timely fashion, the sender retransmits the message. That is, it repeats the message. That is, it repeats the message. Note that the protocol does not guarantee delivery, it only guarantees how long and how hard it will retry. If, for example, a backhoe cuts through a cable, the transport protocol will repeatedly attempt to deliver the message in the absence of receipt of an acknowledgement. So, is it possible to deliver these traps reliably when a backhoe cuts through a cable?
Back on the farm, we have a saying:
"Sure, almost anything is possible. You can even teach a goldfish to play the piano, if you use enough voltage."
Which is to say, when the cable is cut, it doesn't matter what your transport retransmission strategy is, because the signal won't get through until the cable is repaired. What you really need is more voltage, a lot more voltage.
Thus, the overhead required of a TCP implementation is overkill and would only bog down this protocol. A light protocol based on a light transport layer is more likely to be ubiquitous. It can be implemented in the simplest of devices, which was one of the important goals of the designers of the protocol.
