Snmp

1 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP) An adage from the world of professional sports says that a baseball umpire is doing a good job when you forget that he is there. In many ways, the same could be said of a network administrator. The administrator is doing a good job when the network is running so smoothly and efficiently that users forget that the administrator exists. Because as the administrator knows all too well, the second there is a problem, the users will all remember that he or she is there very quickly. This means that a primary job of a network administrator is to keep tabs on the network and ensure that it is operating normally. Information about the hardware and software on the network is a key to performing this task properly. When networks were small, an administrator could stay informed about the status of hardware and software using simple means, such as physically walking over to a computer and using it, or using a low-level link layer management protocol. This is simply not possible with modern internetworks, which are large, geographically diverse, and often consist of many different lower-layer technologies. Usually, the only thing all the devices on the network have in common is an implementation of a particular internetworking protocol suite, such as TCP/IP. This makes the internetwork itself a logical way to facilitate the communication of network management information between devices and a network administrator. Early Development of SNMP Many people recognized during the early days of the Internet that some sort of network management technology would be needed for TCP/IP. Unfortunately, at first there was no single standard—in the 1980s, several different technologies were developed by different working groups. There were three main contestants: the High-level Entity Management System (HEMS) / High-level Entity Management Protocol (HEMP) as defined by RFCs 1021 through 1024; the Simple Gateway Monitoring Protocol (SGMP), defined by RFC 1028; and the Common Management Information Protocol (CMIP), which is actually part of the OSI protocol suite. The Internet Engineering Task Force (IETF) recognized the importance of having a unifying management standard for TCP/IP, and in 1988 published RFC 1052, IAB Recommendations for the Development of Internet Network Management Standards. This memo is not a standard, but more of a statement of intention and documentation of a meeting held on this subject. The conclusion of RFC 1052 was that SGMP be used as the basis of a new Internet standard to be called the Simple Network Management Protocol (SNMP). This development was to be carried out by the SNMP Working Group.

The Two Meanings of "SNMP"

2 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

The rationale of the middle two words in the name “Simple Network Management Protocol” is obvious, but the other two words are slightly more problematic. The word “Protocol” implies that SNMP is just a TCP/IP communication protocol, like other protocols such as DHCP or FTP. Unfortunately, this is both true and untrue: the term “SNMP” is ambiguous. At a lower level, SNMP does indeed refer specifically to the actual protocol that carries network management information between devices. This is in fact what most people think of when they talk about “SNMP”. However, as defined by the SNMP working group, the TCP/IP network management solution as a whole consists of a number of different elements arranged in an architecture. This architecture originally had no specific name, but is now called the Internet Standard Management Framework. Oddly, this higher-level framework is not abbreviated “ISMF” or anything like that; it is also called “SNMP”, which means that context is important in understanding that term. Note: To avoid confusion, I will often use the phrases “SNMP Framework” and “SNMP Protocol” to differentiate these two uses of the term “SNMP”. Design Goals of SNMP The word “Simple” in “Simple Network Management Protocol” is another sore spot for me; having researched and written about this technology, I now consider the presence of this term in the name “SNMP” to be almost a taunt. Let's put it this way: if a brain surgeon tells you that something is a “simple procedure”, you probably know to take that with a grain of salt—well, the same applies here. Even in its first iteration it was only somewhat simple; the most current version of SNMP is fairly complicated indeed, with many different standards defining the SNMP Framework, the SNMP Protocol itself, and a number of supporting elements. So why is it called “simple”? Well, as they say, everything's relative; SNMP is “simple” when compared to other protocols that are even more complex. Some of this can be seen by looking at the basic goals of the Internet Standard Management Framework and the SNMP protocol as a whole: o

SNMP defines a universal way that management information can be easily defined for any object and then exchanged between that object and a device designed to facilitate network management;

o

SNMP separates the functions of defining and communicating management information from the applications that are used for network management;

o

The actual SNMP protocol is fairly simple, consisting of only a few easy-tounderstand protocol operations;

o

The implementation of SNMP is relatively simple for the designers and manufacturers of products.

3 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

Since SNMP is a TCP/IP application layer protocol, it can theoretically run over a variety of transport mechanisms. It is most commonly implemented over IP, of course, but the most recent versions also define transport mappings that can allow SNMP information to be carried over other internetworking technologies. Again, my focus will continue to be almost exclusively on TCP/IP. Key Concept: The Simple Network Management Protocol (SNMP) defines a set of technologies that allows network administrators to remotely monitor and manage TCP/IP network devices. The term “SNMP” refers both to a specific communication protocol (sometimes called the SNMP Protocol) and an overall framework for Internet management (the SNMP Framework).

Further Development of SNMP and the Problem of SNMP Variations The description above provides the history of how the first version of SNMP was developed, leading to the publishing of the first Internet Standard Management Framework in 1988; this is now called SNMP version 1 (SNMPv1). This initial version of SNMP achieved widespread acceptance, and it is still probably the most common version of SNMP. Much of the history of SNMP since that time has been a rather confusing “standards nightmare”. SNMPv1 had a number of weaknesses, particularly in the area of security. For this reason, shortly after SNMPv1 was done, work began on a new version of SNMP. Unfortunately, this effort became a quagmire, with many competing variations of SNMPv2 being created. After many years of confusion, none of the SNMPv2 variants achieved significant success. Recently, a third version of the SNMP Framework and Protocol has been published, which adds new features and “reunites” SNMP back under a single universal protocol again. The topics on SNMP versions and SNMP standards later in this section further explore the history of SNMP since 1988; they can be considered a continuation of this topic, as they help clarify the very confusing story behind SNMP versions over the last decade and a half. This overview may have put more questions in your mind about the Internet Standard Management Framework and SNMP than it answered. This is part of why I said this stuff isn't really that simple. The next two topics in this section provide more information about the Framework and its components, and what those components do, so you can understand better what the Framework is all about.

4 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

SNMP Tutorial Part 1: An Introduction to SNMP Since its creation in 1988 as a short-term solution to manage elements in the growing Internet and other attached networks, SNMP has achieved widespread acceptance. SNMP was derived from its predecessor SGMP (Simple Gateway Management Protocol) and was intended to be replaced by a solution based on the CMIS/CMIP (Common Management Information Service/Protocol) architecture. This long-term solution, however, never received the widespread acceptance of SNMP. SNMP is based on the manager/agent model consisting of a manager, an agent, a database of management information, managed objects and the network protocol. The manager provides the interface between the human network manager and the management system. The agent provides the interface between the manager and the physical device(s) being managed (see the illustration above). The manager and agent use a Management Information Base (MIB) and a relatively small set of commands to exchange information. The MIB is organized in a tree structure with individual variables, SNMP is based on the manager/agent model of a network such as point status or description, being management architecture. represented as leaves on the branches. A long numeric tag or object identifier (OID) is used to distinguish each variable uniquely in the MIB and in SNMP messages. SNMP uses five basic messages (GET, GET-NEXT, GET-RESPONSE, SET, and TRAP) to communicate between the manager and the agent. The GET and GET-NEXT messages allow the manager to request information for a specific variable. The agent, upon receiving a GET or GET-NEXT message, will issue a GET-RESPONSE message to the manager with either the information requested or an error indication as to why the request cannot be processed. A SET message allows the manager to request a change be made to the value of a specific variable in the case of an alarm remote that will operate a relay. The agent will then respond with a GET-RESPONSE message indicating the change has been made or an error indication as to why the change cannot be made. The TRAP message allows the agent to spontaneously inform the manager of an �important� event. As you can see, most of the messages (GET, GET-NEXT, and SET) are only issued by the SNMP manager. Because the TRAP message is the only message capable of being initiated by an agent, it is the message used by DPS Remote Telemetry Units (RTUs) to report alarms. This notifies the SNMP manager as soon as an alarm condition occurs, instead of waiting for the SNMP manager to ask. The small number of commands used is only one of the reasons SNMP is "simple." The other simplifying factor is its reliance on an unsupervised or connectionless communication link. This simplicity has led directly to its widespread use, specifically in the Internet Network Management Framework. Within this framework, it is considered �robust� because of the independence of the managers from the agents, e.g. if an agent fails, the

5 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

manager will continue to function, or vice versa. The unsupervised communication link does however create some interesting issues for network alarm monitoring we will discuss more thoroughly in a later issue of our tutorial. SNMP Tutorial Part 2: The Management Information Base (MIB) top Each SNMP element manages specific objects with each object having specific characteristics. Each object / characteristic has a unique object identifier (OID) consisting of numbers separated by decimal points (i.e., 1.3.6.1.4.1.2682.1). These object identifiers naturally form a tree as shown below. The MIB associates each OID with a readable label (i.e., dpsRTUAState) and various other parameters related to the object. The MIB then serves as a data dictionary or code book that is used to assemble and interpret SNMP messages. When an SNMP manager wants to know the value of an object / characteristic, such as the state of an alarm point, the system name, or the element uptime, it will assemble a GET packet that includes the OID for each object / characteristic of interest. The The branch of the MIB object identifier tree. element receives the request and looks up each OID in its code book (MIB). If the OID is found (the object is managed by the element), a response packet is assembled and sent with the current value of the object / characteristic included. If the OID is not found, a special error response is sent that identifies the unmanaged object. When an element sends a TRAP packet, it can include OID and value information (bindings) to clarify the event. DPS remote units send a comprehensive set of bindings with each TRAP to maintain traditional telemetry event visibility. Well-designed SNMP managers can use the bindings to correlate and manage the events. SNMP managers will also generally display the readable labels to facilitate user understanding and decision-making. SNMP Tutorial Part 3: Understanding Packet Types and Structure top This part of our tutorial on the Simple Network Management Protocol (SNMP) examines the communication between managers and agents. Basic serial telemetry protocols, like TBOS, are byte oriented with a single byte exchanged to communicate. Expanded serial telemetry protocols, like TABS, are packet oriented with packets of bytes exchanged to communicate.

6 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

The packets contain header, data and checksum bytes. SNMP is also packet oriented with the following SNMP v1 packets (Protocol Data Units or PDUs) used to communicate: 1. 2. 3. 4.

Get GetNext Set Trap

The manager sends a Get or GetNext to read a variable or variables and the agent's response contains the requested information if managed. The manager sends a Set to change a variable or variables and the agent's response confirms the change if allowed. The agent sends a Trap when a specific event occurs. The image below shows the packet formats. Each variable binding contains an identifier, a type and a value (if a Set or response). The agent checks each identifier against its MIB to determine whether the object is managed and changeable (if processing a Set). The manager uses its MIB to display the readable name of the variable and sometimes interpret its value.

SNMP Packet Formats SNMP Tutorial Part 4: Layered Communication top In this fourth article in our series, we continue to examine the Simple Network Management Protocol (SNMP) focusing specifically on the layered communication model used to exchange information. Our last article focused on the structure of SNMP messages, however an SNMP message is not sent by itself. It is wrapped in the User Datagram Protocol (UDP), which in turn is wrapped in the Internet Protocol (IP). These are commonly referred to as layers and are based on a four-layer model developed by the Department of Defense (you may recall the DoD origins of the Internet). Understanding this layered model makes it easier to SNMP resides in what is called the Application layer, troubleshoot communication UDP resides in the Transport layer and IP resides in problems. When there is a the Internet layer (somewhat obvious). The fourth problem, you can simply trace it down...

7 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

layer is the Network Interface layer where the assembled packet is actually interfaced to some kind of transport media (i.e., twisted pair copper, RG58 co-axial or fiber). While this multi-layer model may seem a bit confusing, it effectively isolates the tasks of communication and ultimately assists in designing and implementing a network. Traversing the Layers To illustrate the function of this layered model, let's look at a single SNMP GET request from the agent's perspective. The SNMP manager wants to know what the Agent's System Name is and prepares a GET message for the appropriate OID. It then passes the message to the UDP layer. The UDP layer adds a data block that identifies the manager port to which the response packet should be sent and the port on which it expects the SNMP agent to be listening for messages. The packet thus formed is then passed to the IP layer. Here a data block containing the IP and Media Access addresses of the manager and the agent is added before the entire assembled packet gets passed to the Network Interface layer. The Network Interface layer verifies media access and availability and places the packet on the media for transport. After working its way across bridges and through routers (the modern equivalent of over the rivers and through the woods) based on the IP information, the packet finally arrives at the agent. Here it passes through the same four layers in exactly the opposite order as it did at the manager. First, it is pulled off the media by the Network Interface layer. After confirming that the packet is intact and valid, the Network Interface layer simply passes it to the IP layer. The IP layer verifies the Media Access and IP address and passes it on to the UDP layer where the target port is checked for connected applications. If an application is listening at the target port, the packet is passed to the Application layer. If the listening application is the SNMP agent, the GET request is processed as we have discussed in previous articles. The agent response then follows the identical path in reverse to reach the manager.

An SNMP message passes through the protocol layers at both the manager and the agent. Each layer addresses a specific communication task. An Aid for Troubleshooting

8 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

Understanding this layered model makes it easier to troubleshoot communication problems. When there is a problem, you can simply trace it down, out one end, into, and up the other. LAN/WAN link and activity status indicators provide some visibility to the Network Interface layer. ICMP echo requests and responses (Pings) provide some information regarding the proper functioning of the IP layer. SNMP processing indicators can be used to verify the passage of the packet through the UDP layer and the functioning of the Application layer. Each step can be verified independently until all steps are working correctly for end-to-end communication. SNMP Tutorial Part 5: Common Mistakes Made When Integrating SNMP and NonSNMP Systems ... and How You Can Avoid Them top SNMP is a standard protocol that has wide acceptance in the industry and is flexible enough to describe almost anything. Because of these advantages, many network managers have come to believe that SNMP should be used for all network monitoring applications. SNMP certainly has its place in an effective telecom network management solution, but this doesn't mean that any off-the-shelf SNMP manager can provide adequate visibility and control of your network. The typical off-the-shelf SNMP manager is not designed for displaying and processing telemetry data for effective network monitoring, especially for the kind of real-world monitoring tasks network managers most need performed. These capabilities can be added to an SNMP manager, but it usually requires substantial custom software development. Before you buy … make sure you avoid these 7 common mistakes Relying on off-the-shelf SNMP systems for mission-critical telemetry is a major mistake. If you’re switching from traditional telemetry or integrating non-SNMP monitoring with an SNMP-based system, an off-the-shelf SNMP manager will not provide the detailed alarm data you expect. Before you commit to an SNMP monitoring solution, you need to make sure it supports essential network alarm monitoring functions. There are seven common mistakes network managers typically make when integrating SNMP and non-SNMP monitoring. Your SNMP implementation will be successfully only if you can avoid them. 1. Selecting a system that doesn’t provide complete, precise alarm descriptions A basic SNMP manager doesn't record the location, time, severity, or a precise description of alarm events. To adapt an off-the-shelf SNMP manager to monitor these factors, you must create and maintain a master alarm list representing all the monitored points in your network — and then also create and maintain a database associating all the traps that may be sent to the SNMP manager with the alarms on that list.

9 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

2. Settling for a system that can’t identify cleared alarms Even more database work is required to identify whether a trap corresponds to an alarm condition or a clear condition. Creating this addition to the trap association database often requires analyzing multiple variable bindings within the trap packet. 3. Not maintaining a history of standing alarms Relying solely on a basic SNMP manager for network alarm monitoring can potentially result in completely losing visibility of threats to your network. A basic SNMP manager doesn't maintain a list of standing alarms. Instead, the typical SNMP manager maintains an event log of newly reported traps and a history log of acknowledged traps. As soon as a trap is acknowledged, it is considered cleared. Imagine what might happen to your network if a system operator acknowledges an alarm, and then, for whatever reason, fails to correct the alarm condition. Who would know the alarm is still standing? 4. Not identifying system operators Basic SNMP managers do not record the identity of the system operator who acknowledges an alarm. In the example of the negligent system operator, it would be impossible to determine who had made the mistake or to assign responsibility for the resulting problems. 5. Trusting a system that’s insecure for multiple users Out of the box, the typical SNMP manager is not designed for multi-user security. All traps are posted to one alarm list; all users may view all alarms, and all users may acknowledge all alarms. 6. Broadcasting all alarms to all system users Basic SNMP managers have no built-in functions for organizing alarms by logical category, posting the same alarm to multiple logical categories, or sorting which alarms the user wants to see. If Jones is in charge of all equipment for the Western region, and Smith is in charge of power plants, both need to know about a generator failure in Tucson, but neither one needs to know about all the alarms in the network. And if one manager corrects the alarm condition and acknowledges the alarm, the other manager needs to know it was acknowledged and by whom. Unfortunately, standard SNMP managers will not support these functions. 7. Allowing yourself to be bombarded by nuisance alarms No SNMP manager supports the advanced features necessary for best quality telemetry monitoring, such as notifications escalation, legacy protocol mediation, nuisance alarm silencing, automatic control relay operation, and automatic notifications by pager and e-mail. Requirements for Extensive Customization Reduce the Advantages of an Open Standard It is true that many, but not all, of these functions can be added to standard SNMP managers, but implementing network alarm monitoring in a basic SNMP manager usually involves a substantial amount of custom software module development. Even when prebuilt software modules are available, they usually require custom tweaking to perform exactly as you want them to.

10 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

The need for extensive customization eliminates the advantage of using a simple open standard, and it is difficult to justify significant development costs after purchasing an already expensive SNMP manager. Why take the time, trouble, and expense to recreate capabilities that are already present in a high-quality, SNMP-capable network alarm management system? The Right Role for Your SNMP manager Relying on an SNMP manager for critical network monitoring just doesn't take into account the tons of legacy and non-SNMP equipment that is functioning perfectly fine out in networks all over the world. The role of an SNMP manager is best used for inventorying network devices and drilling down into equipment details after your network monitoring system notifies you of a problem. SNMP can be an effective tool, but it's only one item in your network alarm monitoring toolkit, and it can be used more effectively when it is part of a total network monitoring solution. The T/Mon Network Alarm Monitoring Solution If you are looking to avoid these 7 mistakes, then the T/Mon network alarm monitoring system is for you. It is specifically designed to avoid them. Network managers who rely on T/Mon for their network alarm monitoring, notification, and control comment, “Looking at one map and knowing it represents every piece of equipment you’re monitoring in the field… that’s pretty good peace of mind."

SNMP - Simple Network Managment Protocol Introduction Since it was developed in 1988, the Simple Network Managment Protocol has become the de facto standard for internetwork managment. Because it is a simple solution, requiring little code to implement, vendors can easily build SNMP agents to their products. SNMP is extensible, allowing vendors to easily add network managment functions to their existing products. SNMP also separates the managment architecture from the architecture of the hardware devices, which broadens the base of multivendor support. Perhaps most important, unlike other so-called standards,SNMP is not a mere paper specification, but an implementation that is widely available today. This article will discuss the following issues: Network Managment Architectures

11 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

Structure of Managment Information Managment Information Base SNMP Protocol Underlying communications protocols Click here for list of WWW pages related to SNMP

Network Managment Architectures Network managment system contains two primary elements: a manager and agents. The Manager is the console through which the network administrator performs network managment functions. Agents are the entities that interface to the actual device being managed. Bridges, Hubs, Routers or network servers are examples of managed devices that contain managed objects. These managed objects might be hardware, configuration parameters, performance statistics, and so on, that directly relate to the current operation of the device in question. These objects are arranged in what is known as a virtual information database ,called a managment information base, also called MIB. SNMP allows managers and agents to communicate for the purpose of accessing these objects. The model of network managment architecture looks like this:

A typical agent usually:

12 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

• • • •

Implements full SNMP protocol. Stores and retrieves managment data as defined by the Managment Information Base Can asynchronously signal an event to the manager Can be a proxy for some non-SNMP manageable network node. Click here to see a typical proxy architecture.

A typical manager usually: • • •

Implemented as a Network Managment Station (the NMS) Implements full SNMP Protocol Able to o Query agents o Get responses from agents o Set variables in agents o Acknowledge asynchronous events from agents

Some prominent vendors offer network managment platforms which implement the role of the manager (listed in alphabetic order) : • • • •

Dec PolyCenter Network Manager Hewlett-Packard OpenView IBM AIX NetView/6000 SunConnect SunNet Manager

Structure of Managment Information In the Manager/Agent paradigm for network managment, managed network objects must be logically accessible. Logical accessibility means that managment information must be stored somewhere, and therefore, that the information must be retrievable and modifiable. SNMP actually performs the retrieval and modification. The Structure of Managment Information (SMI) which is given in RFC 1155, is based on the OSI SMI given in Draft proposal 2684. The SMI organizes, names, and describes information so that logical access can occur. The SMI states that each managed object must have a name, a syntax and an encoding. The name, an object identifier(OID), uniquely identifies the object. The syntax defines the data type,such as an integer or a string of octets. The encoding describes how the information associated with the managed objects is serialized for transmission between machines. The syntax used for SNMP is the Abstract Syntax Notation One, ASN.1. The encoding used for SNMP is the Basic Encoding Rules, BER. The names used are object identifiers. later we will see how the MIB uses these names. ASN.1 is used to specify many RFCs (and not just the SMI), for example the Internet standard MIB and SNMP. ASN.1 is used widely in OSI for specification purposes. ASN.1 used for defining SMI and MIBs is a subset of the ASN language given by OSI. ASN.1 does specify in itself Object instances (protocol specific) message transmission format (BER)

13 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

Click here to see more information on ASN.1 . Each object whether it's a device or a characteristics of a device, must have a name by which it can be uniquely identified. That name is the object identifier. It is written as a sequence of integers, separated by periods. For example, the sequence 1.3.6.1.2.1.1.1.0 specifies the system description within the system group, of the mgmt subtree.

Managment Information Base Managment information bases (MIBs) are a collection of definitions, which define the properties of the managed object within the device to be managed. Every managed device keeps a database of values for each of the definitions written in the MIB. It is not the actual database itself - it is implementation dependant. Definition of the MIB conforms to the SMI given in RFC 1155. Latest Internet MIB is given in RFC 1213 sometimes called the MIB-II. Click here to see MIB architecture. You can think of a MIB as an information warehouse Criteria and Philosophy for standardized MIB • • • • • • • •

Objects have to be uniquely named Objects have to be essential Abstract structure of the MIB needed to be universal For the standard MIB maintain only a small number of objects Allow for private extensions Object must be general and not too device dependant Objects can not be easily derivable from their objects If agent is to be SNMP manageable then it is mandatory to implement the Internet MIB (currently given as MIB-II in RFC 1157)

Naming an Object • • •

Universal unambiguous identification of arbitrary objects Can be achieved by using an hierarchical tree Based on the Object Identification Scheme defined by OSI

14 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

Object identifiers • • • • • • • •

Object name is given by its name in the tree All child nodes are given unique integer values within that new sub-tree Children can be parents of further child sub-tree(i.e they have subordinates) where the numbering scheme is recursively applied The Object Identifier (or name) of an object is the sequence of non-negative Integer values traversing the tree to the node required. Allocation of an integer value for a node in the tree is an act of registration by whoever has delegated authority for that sub tree This process can go to an arbitrary depth If a node has children then it is an aggregate node Children of the same parent cannot have the same integer value

Object and Object identifiers

15 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

• • • •

Object is named or identified by the sequence of integers in traversing the tree to the object type required This does notidentify an instance of the object The Object Identifier (OID) is shown in a few ways with a.b.c.d.e being the preferred OIDs can name many types of objects: Standard documents (e.g.: FTAM) people (e.g.: Tax file numbers in Sweden are OIDs) Organizations (e.g.: RAD or LANNET) Computing network nodes (e.g.: workstations) Dumb devices (e.g.: toasters) ... in fact anything at all ...

•

For SNMP it is the Internet sub-tree for constructing OIDs for SNMP manageable agents

The Internet Sub-tree • • • •

•

Directory sub-tree if for future directory services Experimental sub-tree is for experimental MIB work - still has to be registered with the authority (IESG) Mib sub-tree is the actual mandatory Internet MIB for all agents to implement (currently MIB-II RFC 1156 - this is the only sub tree of mgmt) Enterprise sub-tree (of private) are MIBs of proprietary objects and are of course not mandatory (sub-tree registered with Internet Assigned Numbers Authority) for example: Cisco router OID: 1.3.6.1.4.1.9.1.1 SNMP managment nearly always interest in MIB and specific enterprises MIBs

MIB-II Standard Internet MIB • • •

• • •

Definition follows structure given in SMI MIB-II (RFC 1213) is current standard definition of the virtual file store for SNMP manageable objects Has 10 basic groups o system o interfaces o at o ip o icmp o tcp o udp o egp o transmission o snmp If agent implements any group then is has to implement all of the managed objects within that group An agent does not have to implement all groups Note: MIB-i and MIB-II have same OID (position in the internet sub-tree)

16 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

SNMP Protocol SNMP is based on the manager/agent model.SNMP is referred to as "simple" because the agent requires minimal software.Most of the processing power and the data storage resides on the managment system, while a complementary subset of those functions resides in the managed system. To achieve its goal of being simple,SNMP includes a limited set of managment commands and responses. The managment system issues Get, GetNext and Set messages to retrieve single or multiple object variables or to establish the value of a single variable. The managed agent sends a Response message to complete the Get, GetNext or Set. The managed agent sends an event notification, called a trap to the managment system to identify the occurrence of conditions such as threshold that exceeds a predetermined value. In short there are only five primitive operations: get (retrieve operation) get next (traversal operation) get response (indicative operation) set (alter operation) trap (asynchronous trap operation) SNMP Message Construct Each SNMP message has the format: • • •

Version Number Community Name - kind of a password One or more SNMP PDUs - assuming trivial authentication

17 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

Each SNMP PDU except trap has the following format: • • • •

request id - request sequence number error status - zero if no error otherwise one of a small set error index - if non zero indicates which of the OIDs in the PDU caused the error2 list of OIDs and values - values are null for get and get next

Trap PDUs have the following format: • • • • • •

enterprise - identifies the type of object causing the trap agent address - IP address of agent which sent the trap generic trap id - the common standard traps specific trap id - proprietary or enterprise trap time stamp - when trap occurred in time ticks list of OIDs and values - OIDs that may be relevant to send to the NMS

Outline of the SNMP protocol • • • •

Each SNMP managed object belongs to a community NMS station may belong to multiple communities A community is defined by a community name which is an OctetString with 0 to 255 octets in length. Each SNMP message consists of three components o version number o community name o data - a sequence of PDUs associated with the request

Security levels with basic SNMP

Authentication o o

trivial authentication based on plain text community name exchanged in SNMP messages authentication is based on the assumption that the message is not tampered with or interrogated

Authorisation o o

Once community name is validated then agent or manager checks to see if sending address is permitted or has the rights for the requested operation "View" or "Cut" of the objects together with permitted access rights is then derived for that pair (community name, sending address)

Summary o o o

Not very secure SNMP version 2 is addressing this Extended security is possible with current protocol (example: DES and MD5)

18 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

o

Does not reduce its power for monitoring

What does SNMP access • • •

•

•

SNMP access particular instances of an object All instances of an object in the MIB reside at the leaf nodes of the MIB tree SNMP Protocol access objects by forming an Object identifier of form x.y where x is the "true" OID for the object in the MIB, and y is a suffix specified by the protocol that uniquely identifies a particular instance (e.g.. when accessing a table) For primitive single instance leaf objects use y=0 for example: sysDescr (OID: 1.3.6.1.2.1.1.1) would be referenced in the SNMP protocol by 1.3.6.1.2.1.1.1.0 (i.e sysDescr.0) For single instance of columnar leaf objects (i.e one instance from a table type of object) use y=I1.I2.I3.... (Ii are table indexes) for example: Click here to see access to the interfaces table

MIB traversal using GetNext operation

Underlying communication protocols SNMP assumes that the communication path is a connectionless communication subnetwork.In other words, no prearranged communication path is established prior to the transmission of data.As a result , SNMP makes no guarantees about the reliable delivery of the data.although in practice most messages get through , and those that don't can be retransmitted. The primary protocols that SNMP implements are the User Datagram Protocol (UDP) and the Internet Protocol (IP).SNMP also requires Data Link Layer protocols such as Ethernet or TokenRing to implement the communication channel from the managment to the managed agent. SNMP's simplicity and connectionless communication also produce a degree of robustness. Neither the manager nor the agent relies on the other for its operation.Thus, a manager may continue to function even if a remote agent fails. When the agent resumes functioning , it can send a trap to the manager, notifying it of its change in operational status. The connectionless nature of SNMP leaves the recovery and error detection up to the NMS(Network Managment Station) and even up to the agent. However keep in mind that SNMP is actually transport independent (although original design was connectionless transport function, which corresponds to the UDP protocol) and can be implemented on other transports as well: • • • • •

TCP (Connected approach) Direct mapping onto Ethernet MAC level Encapsulation onto X25 protocol Encapsulation onto ATM Cell and so on.....

19 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

The following figure describes the Transport Mechanism used in SNMP over UDP:

UDP Transport • • • • • • • • •

Agent listen on UDP port 161 Responses are sent back to the originating NMS port from a dynamic port , although many agents use port 161 also for this target. Maximum SNMP message size is limited by maximum UDP message size (i.e 65507 octets) All SNMP implementations have to> receive packets at least 484 octets in length Some SNMP implementation will incorrectly or not handle packets exceeding 484 octets Asynchronous Traps are received on port 162 of the NMS UDP more suitable than TCP when dynamic route changes occur often (e.g. when there are problems in the network) UDP packets minimize the demands placed on the network(no resource tied up as with connection mode) Agent and NMS are responsible for determining error recovery

20 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

The following diagrams shows the architecture of UDP transport.

21 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

22 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

1. What is SNMP? 2. How is SNMP vulnerable? 3. Is our network or system in danger of attack? 4. What can happen if we are attacked? 5. How can we protect our network or system? 6. Are there any alternatives to using SNMP? 7. Do these vulnerabilities affect home users? 8. What are managers and agents? 9. What is a community string and how is it used? 10. What protocols/ports does SNMP use? 11. Where can I find the specifications for SNMP? 12. Where can I find additional information about SNMP? 13. Has the CERT/CC received any reports of SNMP scanning? 14. I have detected scanning of my network or systems for SNMP. Should I report that to the CERT/CC?

15. Has the CERT/CC received any reports of exploitation of these vulnerabilities? 16. An intruder has exploited these SNMP vulnerabilities on my system. What should I do? 17. I am not a vendor, but I use or otherwise have first-hand knowledge of an SNMP product 18. 19. 20.

21.

that is vulnerable, but it is not on the CERT/CC's list. Should I report that to the CERT/CC? Our company manufactures a product that uses SNMP, and we think it might be vulnerable, but we are not sure. How can we get more information on these vulnerabilities? Our company manufactures a product that uses SNMP, and we know it to be affected by these vulnerabilities, but we are not listed in any of your vendor statements. How can we get added to your list of vendors? Our company manufactures a product that uses SNMP, but we know it is not affected by these vulnerabilities. Nonetheless, we are being swamped with calls to our help desk about this issue. We are not currently listed in any of your vendor statements, but we'd like to be. How can we get added to your list of vendors? Who is OUSPG?

1. What is SNMP? The Simple Network Management Protocol (SNMP) is the most popular protocol in use to manage networked devices. SNMP was designed in the late 80's to facilitate the exchange of management information between networked devices, operating at the application layer of the ISO/OSI model. The SNMP protocol enables network and system administrators to remotely monitor and configure devices on the network (devices such as switches and routers). Software and firmware products designed for networks often make use of the SNMP protocol. Support for SNMP is available on a multitude of systems, including, but not limited to, • • • • •

Core Network Devices (Routers, Switches, Hubs, Bridges, and Wireless Network Access Points) Operating systems (on nearly all architectures) Consumer Broadband Network Devices (Cable Modems and DSL Modems) Consumer Electronic Devices (Cameras and Image Scanners) Networked Office Equipment (Printers, Copiers, and FAX Machines)

23 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

•

2.

• • • How

Network and Systems Management/Diagnostic Frameworks (Network Sniffers and Network Analyzers) Uninterruptible Power Supplies (UPS) Networked Medical Equipment (Imaging Units and Oscilloscopes) Manufacturing and Processing Equipment is SNMP vulnerable?

The vulnerabilities affect both manager and agent software (see "What are managers and agents?" for an explanation of these terms). Vulnerabilities in both managers and agents include denial-of-service conditions, format string vulnerabilities, and buffer overflows. Some of the vulnerabilities do not require the malicious packet to use the proper community string (see "What is a community string and how is it used?"). Several of the more serious vulnerabilities allow the execution of arbitrary code by a remote unauthenticated attacker. Refer to CERT advisory CA-2002-03 (http://www.cert.org/advisories/CA-2002-03.html) for a detailed description of the vulnerabilities.

3. Is our network or system in danger of attack? Because of the relatively large number of products that support SNMP, it is unlikely that our list of affected products is comprehensive. Therefore, if you use products that support SNMP, we encourage you to first refer to CERT advisory CA-2002-03 (http://www.cert.org/advisories/CA-2002-03.html) for a partial list of affected vendors and products. If your vendor(s) are not listed you should contact them directly for more information to ensure your system is protected.

4. What can happen if we are attacked? Exploitation of these vulnerabilities can cause denial-of-service conditions, service interruptions, and in some cases will allow an attacker to gain unauthorized, privileged access to the affected device. Effects for some specific products can be found in CERT advisory CA-2002-03 (http://www.cert.org/advisories/CA-2002-03.html). Contact your vendor(s) for additional information on other products.

5. How can we protect our network or system? A number of steps can be taken to improve the security of systems relying on SNMP: • • • • • •

Apply a patch from your vendor. Disable all nonessential SNMP software. Filter SNMP access to managed devices to ensure the traffic originates from known management systems. Filter SNMP services at your network perimeter (ingress/egress filtering). Change SNMP community strings from their defaults. Segregate network management traffic onto a separate network.

Refer to CERT advisory CA-2002-03 (http://www.cert.org/advisories/CA-2002-03.html) for more details and the most recent information regarding recommended solutions.

6. Are there any alternatives to using SNMP?

24 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

Although there aren't many practical alternatives to SNMP, there are steps that administrators can take to better secure their systems that use SNMP. See the "How can we protect our network or system?" section above or refer to CERT Advisory CA-2002-03 (http://www.cert.org/advisories/CA-2002-03.html) for more information.

7. Do these vulnerabilities affect home users? Most home users are not directly affected by these vulnerabilities. However, home users with more advanced configurations may be at risk. If you use one or more of the following in your home system or network, additional steps might be necessary to ensure protection: • • • • •

Microsoft Windows operating systems with SNMP services enabled advanced operating systems (e.g., Linux or other Unix operating systems) network-based router appliances network-based firewall appliances wireless Ethernet (802.11a/b) access points

Note that in many cases SNMP services are not enabled by default, so merely using one or more of the products above does not mean that you are definitely vulnerable. Home users with one or more of the above technologies in use on their home networks are encouraged to refer to CERT advisory CA-2002-03 (http://www.cert.org/advisories/CA2002-03.html) for a partial list of affected vendors and products. If your vendors are not listed you should contact them directly for more information to ensure your system is protected.

8. What are managers and agents? SNMP is built around the concept of "managers" and "agents." Manager software (commonly installed on a network management system) makes requests to agent software running on a host or device to gather data on the operational status, configuration, or performance statistics of that system (polling). Some agents allow configuration parameters to be changed by managers, while others provide read-only statistics and configuration information. Additionally, agents can generate ad hoc messages to manager systems to inform them of unusual events (traps).

9. What is a community string and how is it used? The community string (a.k.a. community name) provides a weak authentication mechanism to the SNMP protocol. Agents can be configured to allow read-only, readwrite, or no access to their parameters based on the community string in a request. Community strings are passed in clear text in SNMP messages, so they can be easily sniffed and are therefore insufficient for authenticating legitimate manager requests. Note that many of the vulnerabilities described in CERT advisory CA-2002-03 (http://www.cert.org/advisories/CA-2002-03.html) do not require an attacker to know the configured community strings in order to exploit the vulnerability.

10. What protocols/ports does SNMP use? SNMP uses 161/udp for general purpose (request/response) communications, and 162/udp for traps. Additionally, the SNMP multiplexing protocol (smux, defined in

25 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

RFC1227 http://www.ietf.org/rfc/rfc1227.txt) uses 199/tcp. Another SNMP extension, the AgentX protocol (RFC2741, http://www.ietf.org/rfc/rfc2741.txt) uses 705/tcp.

11. Where can I find the specifications for SNMP? The current SNMPv1 standard is defined in the Internet Engineering Task Force (IETF) STD0015 / RFC1157 (http://www.ietf.org/rfc/rfc1157.txt). There are also a number of draft and proposed standards for SNMPv2 and SNMPv3. Refer to IETF STD0001 / RFC3000 (http://www.ietf.org/rfc/rfc3000.txt) for the current status of the various SNMP-related RFCs.

12. Where can I find additional information about SNMP? The comp.protocols.snmp FAQ may be found at http://www.faqs.org/faqs/snmp-faq/part1/ and http://www.faqs.org/faqs/snmp-faq/part2/ There are a number of SNMP-related Working Groups in the "Operations and Management" area of the IETF (http://www.ietf.org/).

13. Has the CERT/CC received any reports of SNMP scanning? As of 9:25 EST (UTC-0500) February 12, 2002, we have received reports of scanning for SNMP services related to these vulnerabilities and are working to verify. New incident reports are being sent to the CERT/CC all the time, though, so you are encouraged to refer to our Current Activity page (http://www.cert.org/current/current_activity.html) for the latest information on incident trends.

14. I have detected scanning of my network or systems for SNMP. Should I report that to the CERT/CC? If you have detected scanning for SNMP services on your network, you should first determine whether this scanning has led to a compromise or not. You may wish to refer to our Intruder Detection Checklist (http://www.cert.org/tech_tips/intruder_detection_checklist.html) for additional tips on determining whether a compromise has occurred. Once you are certain that no compromise has occurred and the impact was limited to scanning only, you are encouraged to report this activity to the CERT/CC using our Incident Reporting Form, available at http://www.cert.org/reporting/incident_form.txt. Reporting scanning activity to the CERT/CC will help us better assist you, and allow us to relate ongoing intruder activities. This also provides us a better overview of trends in attack profiles and provides input for other CERT documents such as advisories and summaries. We prefer that Incident Reporting Forms be sent to us via email to [email protected]. 15.Has the CERT/CC received any reports of exploitation of these vulnerabilities? As of 9:25 EST (UTC-0500) February 12, 2002, we have received reports of exploitation of SNMP services related to these vulnerabilities and are working to verify them. New incident reports are being sent to the CERT/CC all the time, though, so you are

26 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

encouraged to refer to our Current Activity page (http://www.cert.org/current/current_activity.html) for the latest information on incident trends.

16. An intruder has exploited these SNMP vulnerabilities on my system. What should I do? As described in CERT advisory CA-2002-03 (http://www.cert.org/advisories/CA-200203.html), exploitation of these SNMP vulnerabilities can cause denial-of-service conditions, service interruptions, and in some cases will allow an attacker to gain unauthorized, privileged access to the affected device(s). If you suspect that your system may have been compromised, you may wish to refer to our Intruder Detection Checklist (http://www.cert.org/tech_tips/intruder_detection_checklist.html). Once you have confirmed that a compromise has occurred, please refer to our Steps for Recovering from a UNIX or NT System Compromise (http://www.cert.org/tech_tips/root_compromise.html) Regardless of whether the exploitation resulted in system compromise or denial-ofservice, we would appreciate it if you would complete and return an Incident Reporting Form as this will help us better assist you, and allow us to relate ongoing intruder activities. This also provides us a better overview of trends in attack profiles and provides input for other CERT documents such as advisories and summaries. We prefer that Incident Reporting Forms be sent to us via email to [email protected]. The Incident Reporting Form is available from http://www.cert.org/reporting/incident_form.txt.

17. I am not a vendor, but I use or otherwise have first-hand knowledge of an SNMP product that is vulnerable, but it is not on the CERT/CC's list. Should I report that to the CERT/CC? If you have first-hand knowledge of an SNMP product that is vulnerable to either of these vulnerabilities, and that product or vendor is not listed in CERT advisory CA-200203 (http://www.cert.org/advisories/CA-2002-03.html), you are encouraged to contact us using our Product Vulnerability Reporting Form. This form can be found at http://www.cert.org/reporting/vulnerability_form.txt. Please send the completed form to [email protected] with VU#617947 in the subject line.

18. Our company manufactures a product that uses SNMP, and we think it might be vulnerable, but we are not sure. How can we get more information on these vulnerabilities?

The CERT/CC encourages any vendors whose products are affected (whether vulnerable or not) by these or any other security vulnerabilities to contact us so that we can establish a working relationship on this and any future issues that may arise. If you are authorized to represent your organization on this issue, please contact the CERT/CC via our hotline at +1 412-268-7090. CERT/CC personnel answer 8:00 a.m.- 5:00 p.m. EST(GMT-5) / EDT(GMT-4) on working days; they are on call for emergencies during other hours and on weekends and holidays.

19. Our company manufactures a product that uses SNMP, and we know it to be affected by these vulnerabilities, but we are not listed in any of your vendor statements. How can we get added to your list of vendors?

27 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

The CERT/CC encourages any vendors whose products are affected (whether vulnerable or not) by these or any other security vulnerabilities to contact us so that we can establish a working relationship on this and any future issues that may arise. If you are authorized to represent your organization on this issue, please contact the CERT/CC via our hotline at +1 412-268-7090. CERT/CC personnel answer 8:00 a.m.- 5:00 p.m. EST(GMT-5) / EDT(GMT-4) on working days; they are on call for emergencies during other hours and on weekends and holidays.

20. Our company manufactures a product that uses SNMP, but we know it is not affected by these vulnerabilities. Nonetheless, we are being swamped with calls to our help desk about this issue. We are not currently listed in any of your vendor statements, but we'd like to be. How can we get added to your list of vendors? The CERT/CC encourages any vendors whose products are affected (whether vulnerable or not) by these or any other security vulnerabilities to contact us so that we can establish a working relationship on this and any future issues that may arise. If you are authorized to represent your organization on this issue, please contact the CERT/CC via our hotline at +1 412-268-7090. CERT/CC personnel answer 8:00 a.m.- 5:00 p.m. EST(GMT-5) / EDT(GMT-4) on working days; they are on call for emergencies during other hours and on weekends and holidays.

21. Who is OUSPG? The Oulu University Secure Programming Group (OUSPG) is an academic research group located at Oulu University in Finland. The purpose of this research group is to test software for vulnerabilities. History has shown that the techniques used by the OUSPG have discovered a large number of previously undetected problems in the products and protocols they have tested. Earlier this year, the OUSPG produced a comprehensive test suite for evaluating implementations of the Lightweight Directory Access Protocol (LDAP). This test suite was developed with the strategy of abusing the protocol in unsupported and unexpected ways, and it was very effective in uncovering a wide variety of vulnerabilities across several products. This approach can reveal vulnerabilities that would not manifest themselves under normal conditions.

What's the difference between SNMPv1, SNMPv2 and SNMPv3? ------------------------------------------------------What's the difference between SNMPv2 and SNMPv2c? -----------------------------------------------A full description is probably beyond the scope of this FAQ. Very briefly, the original protocol and admin framework was described in RFCs 1155-1157, and is now known as SNMPv1. Practical experience showed up various problems and deficiencies with this, and a number of revised frameworks were developed to try and address these problems. Unfortunately, it proved difficult to achieve any sort of agreement - particularly over the details of

28 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

the administrative framework to use. There was less disagreement over the proposed changes to the protocol operations. These included: * increasing the range of errors that could be reported * introducing "exception values" (so a single missing value didn't affect the other varbinds in the same request) * a new GETBULK operation (a supercharged GETNEXT) * new notification PDUs (closer in structure to the other request PDUs) Strictly speaking, it's this revised protocol (originally defined in RFC 1905, and most recently in RFC 3416) that is "SNMPv2". The only framework based on this protocol that saw a significant level of use was "Community-based SNMPv2" or "SNMPv2c" (defined in RFCs 1901-1908). This retained the same administrative framework as SNMPv1 (with all of the accompanying limitations), but using the new protocol operations. More recently, a new administrative framework has been developed, building on the various competing SNMPv2 proposals, and using the same SNMPv2 protocol operations. This is SNMPv3, which is defined in RFCs 3411-3418. It addresses some of the deficiencies of the community-based versions, including significant improvements to the security of SNMP requests (like it finally has some!). SNMPv3 is now a full IETF standard protocol. Strictly speaking, SNMPv3 just defines a fairly abstract framework, based around the idea of "Security Models" and "Access Control Models". It's this combination of SNMPv3 plus accompanying models that actually provides a working SNMP system. However, the only models in common use are the "User-based Security Model" (RFC 3414) and the "View-based Access Control Model" (RFC 3415). So "SNMPv3" is frequently used to mean the combination of the basic SNMPv3 framework with these two particular models. This is also sometimes described as "SNMPv3/USM". So in brief: - SNMPv2c updated the protocol operations but left the administrative framework unchanged. - SNMPv3 updated the administrative framework but left the protocol operations unchanged. Can I use SNMPv1 requests with an SNMPv2 MIB (or vice versa)?

29 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

-----------------------------------------------------------Yes. The syntax used to specify a MIB file (better referred to as SMIv1 or SMIv2) is purely concerned with how to define the characteristics of various management objects. This is (almost) completely unrelated to the versions of the protocol used to operate on these values. So it is quite reasonable to use SNMPv1 requests on objects defined using SMIv2, or SNMPv2 (or SNMPv3) requests on objects defined using SMIv1. The one exception is objects of syntax Counter64, which are only accessible using SNMPv2 or higher. SNMPv1 requests will either treat such objects as an error, or skip them completely.

Where can I find more information about network management? ---------------------------------------------------------There are a number of sites with network management information on the World Wide Web. A couple of the most useful are http://www.simpleweb.org/ http://www.snmplink.org/ http://www.mibdepot.com/ There are two Usenet newsgroups which are relevant. 'comp.dcom.net-management' which discusses general issues relating to network management 'comp.protocols.snmp' which is specifically concerned with use of SNMP in particular (though there is a large overlap between these two groups). The SNMP group also has an FAQ (split into two parts) which discusses more general issues related to SNMP, including books, software, other sites, how to get an enterprise number, etc, etc. This is available from ftp://rtfm.mit.edu/pub/usenet/comp.protocols.snmp/ or via any of the Web sites above.

30 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

How do I add a MIB? -----------------This is actually two separate questions, depending on whether you are referring to the tools, or the agent (or both). See the next question or the next section respectively.

How do I add a MIB to the tools? ------------------------------Adding a MIB to the client-side tools has two main effects: - it allows you to refer to MIB objects by name (rather than having to use the numeric OIDs) - it allows the results to be displayed in a more immediately meaningful fashion. Not just giving the object names, but also showing named enumeration values, and interpreting table indexes properly (particularly for string and OID index values). Most of the tools (apart from 'snmptable') will work quite happily without any MIB files at all - although the results won't be displayed in quite the same way. The same holds true for the agent - see the AGENT section for details. There are two steps required to add a new MIB file to the tools. Firstly, copy the MIB file into the appropiate location: cp MY-MIB.txt /usr/local/share/snmp/mibs (which makes it available to everyone on the system) or mkdir $HOME/.snmp mkdir $HOME/.snmp/mibs cp MY-MIB.txt $HOME/.snmp/mibs (which makes it available to you only) Note that the location of the shared MIB directory may be different from that given here - particularly if you're working with a vendor supplied distribution. See where the MIBs are currently installed, and copy the new MIB to the same place. Secondly, tell the tools to load this MIB:

31 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

export MIBS=+MY-MIB (load it for this session only) or echo "mibs +MY-MIB" >> $HOME/.snmp/snmp.conf (load it every time) This will add the new MIB to the list of MIBs loaded by default. Omitting the '+' will *replace* the list of MIBs to be loaded by the specified (colon-separated) list - together with any MIBs that they explicitly rely on. Note that the value for this variable is the name of the MIB module, *not* the name of the MIB file. These are typically the same (apart from the .txt suffix), but if in doubt, check the contents of the file. The value to use is the token immediately before the word DEFINITIONS at the start of the file. If you prefer to have the tools load all available MIBs (which may slow them down), then set the MIBS environmental variable (or the snmp.conf token "mibs") to the special value "ALL". Note that you need *both* steps.

Why can't I see anything from the agent? --------------------------------------There are two main general causes of problems retrieving information from the agent. Either the client tool may not like the request (and refuse to send it at all), or the agent may not respond with anything useful. The simplest way to distinguish between the two is to run the command with the command-line option '-d'. If this doesn't display a hex dump of the raw outgoing packet, then it's the client side which is dropping the request. Hopefully you should see some form of error message, to help identify what's wrong. If this displays one or more outgoing dumps (but nothing coming back), then the request is failing at the agent end. See the next entry for more details. If you see dumps of both the outgoing request, and a response, but no results are displayed, then either there may be a problem with decoding the response (in which case you should see an error message), or the agent may simply not support the requested information (and the

32 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

response is being discarded as irrelevant).

Why doesn't the agent respond? ----------------------------Assuming that the agent is actually sending the request (see the previous entry), there are two main likely causes for the agent not to respond. Either it doesn't receive the request (e.g. it's being blocked by a firewall or packet filtering), or it receives it, but is unwilling (or unable) to process it. If the remote system is running the Net-SNMP agent, then the easiest way to check what's going wrong is to shut down the agent, and re-start it using the options: -f -Le -d This will display raw dumps of packets seen (or sent) by the agent, just as the '-d' flag did for the client side in the previous entry. Restart the agent with these flags, and send the same query as before. If the agent doesn't display anything in response to this request, then it's probably some form of firewall settings, which are preventing the agent from ever seeing the request. If the agent displays a dump of the incoming request, but nothing going out, then the most likely cause is access control settings. See the relevant entries in the AGENT section for details. A third possibility is that the agent *is* responding to the request, but only after a long delay. This would be indicated by a series of incoming packet dumps (showing various retries from the client side), followed by several outgoing dumps - possibly long after the client tool has given up in disgust. See the entry The agent worked for a while, then stopped responding. Why? later in this section. The same basic causes could also affect other vendors' SNMP agents. Please consult the relevant documentation for how to investigate and address such problems.

I can see the system group, but nothing else. Why? --------------------------------------------------

33 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

This is almost definitely due to the access configuration of the agent. Many pre-configured systems (such as most Linux distributions) will only allow access to the system group by default, and need to be configured to enable more general access. The easiest way to test this is to try a GETNEXT request that ought to return the entry of interest. e.g. snmpgetnext -v1 -c public localhost UCD-SNMP-MIB::versionTag instead of snmpget -v1 -c public localhost UCD-SNMP-MIB::versionTag.0 If the agent responds with "end of MIB" or a different object, then either the agent doesn't implement that particular object at all, or the access control won't allow you access to it. See the entries on access control in the AGENT section for how to configure the Net-SNMP agent, or consult the agent's own documentation.

Why can't I see values in the tree? ----------------------------------------------------------If you're walking a specific tree, but failing to see anything in it, then the most likely cause is that the agent simply does not implement those particular MIB objects. Or if it does, that the access control or other configuration settings mean that there's nothing for you to see there. However, if you're trying a basic "snmpwalk" with no explicit OID specified, then this would also explain why you're not seeing any enterprise-specific results. By default, unless given an explicit starting OID, then the 'snmpwalk' command will display the contents of the 'mib-2' tree, containing most of the IETF-standard management information supported by the agent. When the agent reaches the end of this tree, it will return the first enterprise-specific value, and 'snmpwalk' will recognise that this marks the end of the (implicitly) request tree, and stop. No enterprise-specific information will be displayed. To walk the whole tree, and see *all* the information that the agent supports, specify a starting point of '.iso' or '.1'. To walk a specific enterprise subtree, specify the root of this tree as the starting point - e.g: snmpwalk -v1 -c public localhost UCD-SNMP-MIB::ucdavis

34 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

There is more information about particular UCD-specific subtrees in the AGENT section.

The agent worked for a while, then stopped responding. Why? ----------------------------------------------------------There are three basic possibilities: - the agent has crashed - it is hanging - it is temporarily overloaded Detecting whether the agent has crashed should be fairly straighforward. If you can reliably reproduce this crash (e.g. by sending a particular SNMP request), then contact the coders list for advice. It's the other two cases that are probably more significant. To tell the difference between these two, try leaving the agent undisturbed for a while, and then probe it using a single 'snmpget' request, specifying a longer timeout (e.g. '-t 120'). If it now responds, then something was probably sending requests (including duplicate retries) faster than the agent could process them, and it was building up a backlog. Try adjusting the timeout period and retry frequency of these client requests, or look at improving the efficiency of the implementation of the relevant MIB objects. If the agent remains unresponsive (particularly if the load on the system is steadily climbing), then it's probably hanging, and all you can really do is restart the agent. If you can identify what causes this to happen, then contact the coders list for advice.

Requesting an object fails with "Unknown Object Identifier" Why? ---------------------------------------------------------------If a general snmpwalk shows a particular entry, but asking for it more specifically gives a "sub-identifier not found:" or "Unknown Object Identifier" error, then that's a problem with the tool, rather than the agent. Firstly, make sure that you're asking for the object by the right name. Object descriptors are case-sensitive, so asking for 'sysuptime' will not be recognised, but 'sysUpTime' will.

35 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

Alternatively, the object may be defined in a MIB that hasn't been loaded. Try loading in all the MIB files: snmpget -m ALL -v1 -c public localhost sysUpTime.0 or specify the name of the appropriate MIB explicitly: snmpget -v1 -c public myhost SNMPv2-MIB::sysUpTime.0 Note that this uses the name of the *module*, not the name of the file. See the second entry in this section for the distinction. However, if 'snmpwalk' displays the object by name, this is unlikely to be the cause, and you should look closely at the exact object name you are using.

Why do I get "noSuchName" when asking for "sysUpTime" (or similar)? -----------------------------------------------------------------Assuming that you do have access to this object, the most likely cause is forgetting the "instance subidentifier". If you try walking the 'system' group, you should notice that all of the results have a number after the MIB object name. This is the "instance subidentifier" of that particular MIB instance. For values from the sysORTable, this basically provides an index into the table, and should be very familiar. But the other values in the system group also have an instance number displayed. For non-table objects ("scalars"), this instance subidentifier will always be '0', and it *must* be included when making a GET request. Compare the following: $ snmpget -v1 -c public localhost sysUpTime Error in packet Reason: (noSuchName) There is no such variable name in this MIB. This name doesn't exist: system.sysUpTime $ snmpget -v1 -c public localhost sysUpTime.0 system.sysUpTime.0 = Timeticks: (69189271) 8 days, 0:11:32.71 This is a little less obscure when using SNMPv2c or v3 requests: $ snmpget -v 2c -c public localhost sysUpTime system.sysUpTime = No Such Instance currently exists

36 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

Why do I sometimes get "End of MIB" when walking a tree, and sometimes not? -------------------------------------------------------------------------This depends on which MIB modules are supported by the agent you are querying and exactly what you're asking for. Note that a tree is walked by repeatedly asking for "the next entry" until all the values under that tree have been retrieved. However, the agent has no idea that this is what's happening - all it sees is a request for "the next entry after X". If the object X happens to be the last entry in a sub-tree, the agent will provide the next object supported (as requested) even though this will be in a different subtree. It's up to the querying tool to recognise that this last result lies outside the area of interest, and simply discard it. If the object X happens to be the last entry supported by the agent, it doesn't have another object to provide, so returns an "end of MIB" indication. The Net-SNMP tools report this with the message above. But in either case, the actual information provided will be the same.

How do I use SNMPv3? ------------------The simplest form of SNMPv3 request (unauthenticated, unencrypted) would be something like: snmpget -v 3 -l noAuthNoPriv localhost sysUpTime.0 An authenticated request would specify a username and pass phrase: snmpget -v 3 -l authNoPriv -u dave -A "Open the Door" localhost sysUpTime.0 A fully secure request would also specify the privacy pass phrase: snmpget -v 3 -l authPriv -u dave -A "Open the Door" -X "Bet you can't see me" localhost sysUpTime.0 In practise, most of these would probably be set via configuration directives in a personal $HOME/.snmp/snmp.conf file (note, *not* the agent's snmpd.conf file). The equivalent settings for the third example would be:

37 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

defSecurityName dave defSecurityLevel authPriv defAuthPassphrase "Open the Door" defPrivPassphrase "Bet you can't see me" If the AuthPassphrase and the PrivPassphrase are the same, then you can use the single setting defPassphrase "Open the Door and see me" instead. See the AGENT section for how to configure the agent for SNMPv3 access.

I cannot set any variables in the MIB. ------------------------------------There are three possible reasons for this: Many MIB objects are defined as "read-only" and inherently cannot be changed via SET requests. Attempts to do so will typically be dropped by the 'snmpset' command without ever being sent to the agent. Of those objects that can in principle be changed, the agent may not include the code necessary to support SET requests. (GET and GETNEXT are much easier to handle - particularly for objects relating to the internals of the underlying operating system). Even if SET support has been implemented, the agent may not be configured to allow write access to this object. Ready-installed distributions (such as those shipped with Linux) tend to be configured with read-only access to part of the mib tree (typically just the system group) and no write access at all. To change this, you will need to set up the agent's access control configuration. See the AGENT section for more details. Note that neither the community string "public" nor "private" can be used to set variables in a typical default configuration.

Variables seem to disappear when I try to set them. Why? -------------------------------------------------------This is actually the same as the previous question - it just isn't

38 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

particularly obvious, particularly when using SNMPv1. A typical example of this effect would be $ snmpget -v1 -c public localhost system.sysLocation.0 system.sysLocation.0 = somewhere nearby $ snmpset -v1 -c public localhost system.sysLocation.0 s "right here" Error in packet. Reason: (noSuchName) There is no such variable name in this MIB. This name doesn't exist: system.sysLocation.0 Trying the same request using SNMPv2 or above is somewhat more informative: $ snmpset -v 2c -c public localhost system.sysLocation.0 s "right here" Error in packet. Reason: notWritable The SNMPv1 error 'noSuchName' actually means: "You can't do that to this variable" rather than "this variable doesn't exist". It may be the case that it doesn't exist at all. It may exist but you don't have access to it (although someone else with different administrative credentials might do). Or it may exist, but you simply can't perform that particular operation (e.g. changing it). Similarly, the SNMPv2 error 'notWritable' means "not writable in this particular case" rather than "not writable under any circumstances". If you are sure that the object is writable (and has been implemented as such), then you probably need to look at the agent access control. See the AGENT section for more details.

Why can't I change sysLocation (or sysContact)? ---------------------------------------------Assuming that the access control settings should allow this, another possibility for the 'sysLocation' and 'sysContact' objects is that you've got a configuration option in the 'snmpd.conf' file which already sets the corresponding value there. Earlier versions of the Net-SNMP agent would allow you to write to these objects, but the new value would be forgotten the next time the agent was re-started. More recent versions of the agent reject such write requests if there's a value configured via the 'snmpd.conf' file. If there isn't such a config setting, then the write request will succeed

39 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

(assuming suitable access control settings), and the new value will be retained the next time the agent restarts.

I get an error when trying to set a negative value - why? -------------------------------------------------------This is a different problem. What's happening here is that the routine that parses the arguments to the 'snmpset' command is seeing the '-' of the new value, and treating it as a command-line option. This normally generates an error (since digits typically aren't valid command line options). The easiest way to solve this is include the "end-of-option" indicator '--' in the command line, somewhere before the new value (but after all of the options, obviously). For example: snmpset -v 2c -c public localhost -- versionRestartAgent.0 i -1 (This will also fail, since -1 isn't an acceptable value for this particular object, but that's not the point here!)

I get an error when trying to get a string-indexed table value - why? -------------------------------------------------------------------This is probably due to the shell swallowing the quotes, before they ever get to the SNMP command's OID parser. Try escaping them: or

snmpget ..... vacmGroupName.3.\"wes\" snmpget ..... 'vacmGroupName.3."wes"'

How do I send traps and notifications? --------------------------------------Traps and notifications can be sent using the command 'snmptrap'. The following examples generate the generic trap 'coldStart' and a (dummy) enterprise specific trap '99' respectively: snmptrap -v 1 -c public localhost "" "" 0 0 "" snmptrap -v 1 -c public localhost "" "" 6 99 ""

40 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

The empty parameters "" will use suitable defaults for the relevant values (enterprise OID, address of sender and current sysUptime). An SNMPv2 or SNMPv3 notification (either trap or inform) takes the OID of the trap to send: snmptrap -v 2c -c public localhost "" UCD-SNMP-MIB::ucdStart snmptrap -v 2c -c public localhost "" .1.3.6.1.4.1.2021.251.1 (These two are equivalent ways of specifying the same trap). Any of these commands can be followed by one or more varbinds, using the same (OID/type/value) syntax as for 'snmpset': snmptrap -v 2c -c public localhost "" ucdStart sysContact.0 s "Dave" Generating traps from within the agent is covered in the AGENT and CODING sections. You should also read the snmptrap tutorial at http://www.net-snmp.org/tutorial-5/commands/snmptrap.html which will help you understand everything you need to know about traps.

How do I handle traps and notifications? --------------------------------------Handling received traps is done using the tool 'snmptrapd'. This can log these traps via the syslog mechanism: snmptrapd -Ls 7

(log to 'LOCAL7')

printed to standard output snmptrapd -f -Lo or pass them to an external command. This last approach uses a 'traphandle' directive in the configuration file 'snmptrapd.conf'. A typical file might look something like: traphandle .1.3.6.1.6.3.1.5.1 page_me up traphandle .1.3.6.1.4.1.2021.251.1 page_me up traphandle .1.3.6.1.4.1.2021.251.2 page_me down traphandle default log_it where 'page_me' and 'log_it' are the command to be run. (You probably need to specify full pathnames, to ensure that the commands will be

41 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

found. They're just short here for readability). Note that the first entry uses the OID corresponding to the SNMPv1 'coldStart' trap. See the co-existence RFC (RFC 2576) for details of mapping SNMPv1 traps to SNMPv2 OIDs. Starting with net-snmp 5.3, snmptrapd will no longer automatically accept all incoming traps. It must be configured with authorized SNMPv1/v2c community strings and/or SNMPv3 users. Non-authorized traps/informs will be dropped. Please refer to the snmptrapd.conf(5) manual page for details. There's a tutorial with more details on the web site at http://www.net-snmp.org/tutorial-5/commands/snmptrap.html

My traphandler script doesn't work when run like this - why not? --------------------------------------------------------------If a traphandler script works fine when run manually from the command line, but fails or generates an error when triggered by an incoming notification, then there are two likely causes. Firstly, the interactive shell environment may not be precisely the same as that for programs executed by the snmptrapd daemon. In particular, it's quite possible that the PATH environmental variable may not include all the additional directories that are commonly set up for a personal login configuration. To avoid this problem (particularly for traphandler shell scripts), it's worth giving the full path to all programs used within the script. Secondly, the snmptrapd daemon may not always recognise the appropriate interpreter to use for a particular trap handler. If this is the case, then you can specify this interpreter explicitly as part of the trap handle directive: traphandle default /usr/bin/perl /usr/local/bin/log_it In this case, it's almost certain that you'll also need to give the full path to the traphandle script (as shown)

How big can an SNMP request (or reply) be? -----------------------------------------

42 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

The protocol definition specifies a "minimum maximum" packet size (484 bytes for UDP), which all systems must support, but does not attempt to define an upper bound for this maximum size. This is left to each individual implementation. The UCD software used a fixed size buffer of 1472 bytes to hold the encoded packet, so all requests and responses had to fit within this. The Net-SNMP releases handle packet buffers rather differently, and are not subject to the same fixed restrictions.

How can I monitor my systems (disk, memory, etc)? -----------------------------------------------In general, the Net-SNMP suite consists of relatively low-level tools, and there is nothing included that is designed for high-level, long-term monitoring of trends in network traffic, disk or memory usage, etc. There are a number of packages available that are designed for this purpose. Two of the most widely used are MRTG (http://www.mrtg.org/) and RRDtool (http://oss.oetiker.ch/rrdtool/). There are also several frontends built on top of RRDtool, including Cacti (http://www.cacti.net/) and Cricket (http://cricket.sourceforge.net/). There are details of how to set up Cricket to monitor some of the UCD extensions at http://www.afn.org/~jam/software/cricket/ We have also set up a page that describes in detail how MRTG can be set up to monitor disk, memory and cpu activity at http://www.net-snmp.org/tutorial-5/mrtg/index.html There is also a web-based network configuration system "Net-Policy", based upon SNMP. This is not strictly connected to the Net-SNMP project, but a number of the core developers are also involved with that system. See http://net-policy.sourceforge.net for more details.

Applications complain about entries in your example 'snmp.conf' file. Why? -------------------------------------------------------------------------There *is* no example 'snmp.conf' shipped with the standard distribution. The configuration file 'EXAMPLE.conf' is designed as a config for the agent, and should be installed as 'snmpd.conf' (note the 'd'). The file 'snmp.conf' is intended for general configuration options,

43 Overview and History of the TCP/IP Internet Standard Management Framework and Simple Network Management Protocol (SNMP)

applicable to all applications (via the SNMP library). Rename (or merge) the 'snmp.conf' file to 'snmpd.conf', and this should fix the problem.

OK, what should I put in snmp.conf? ---------------------------------This is used to set common configuration values for most of the applications, to avoid having to specify them every time. Examples are the SNMPv3 settings mentioned above, defaults for which MIBs to load and where from (see the second entry in the APPLICATIONS section), and the default SNMP version, port and (if appropriate) community string to use. Some of these (such as the MIB file location), might be best put in a shared snmp.conf file (typically /usr/local/share/snmp/snmp.conf or /etc/snmp/snmp.conf) to apply to all users of the system. Others (particularly the SNMPv3 security settings), are more likely to refer to a particular user, and should go in a personal snmp.conf file (typically $HOME/.snmp/snmp.conf). See 'snmpget -H' and/or the snmp.conf(5) man page for more details. You can also use the "snmpconf" command to help you generate your snmp.conf configuration file (just run it and answer its questions).