SNMP: The De Facto Network Management Standard

SNMP: The De Facto Network Management Standard

Two efforts were made in the 1980s to standardize the area of network management: OSI and SNMP. The intention was that the OSI approach would eventually replace SNMP, but this never happened . In the end, the OSI approach was found to be too complex for widespread adoption and was overtaken by its simpler counterpart . Some OSI inventions , such as ASN.1, did find their way into SNMP. SNMP is a much lighter variant that was globally adopted and has now become the de facto standard for network management. SNMP-based management system components are distributed throughout a network in the form of agents and managers. The appeal of the lightweight SNMP entities is that they consume minimal resources: This can be an aid to scalability (discussed in Chapter 3). The latter is an important management requirement even on modern networks with highly powerful hosts . The principal components of SNMP are:

• Agents

• Managers

• MIBs

• A communications protocol

The SNMPv3 standard replaces the terms agent and manager with entity . While entity is the correct term for SNMPv3, we need to distinguish between the manager (server) side and device (agent) side. So, for clarity, we will continue to use the terms agent and manager. Unless otherwise stated, these refer to SNMPv3 entities. Also, any reference to SNMP from here on should be interpreted as SNMPv3 unless otherwise stated. We now describe these principal components.

The SNMP Agent

SNMP agents are the entities that reside on managed devices. They listen on UDP port 161 for incoming SNMP messages; they use UDP port 162 for sending notification messages. Agents are the workhorses of management and provide the following functionality:

• Implementing and maintaining MIB objects

• Responding to management operations such as requests

• Generating notifications, both traps ( unacknowledged ) and informs ( acknowledged )

• Implementing security ”SNMPv1 and SNMPv2c support community-based security with clear-text passwords; stronger security (authentication and encryption) is available with SNMPv3

• Setting the access policy for external managers

SNMPv3 also provides an access control framework, which consists of:

• MIB view ”the set of managed objects in an agent MIB accessible to an SNMP manager. This is the manager's client view with respect to the agent.

• Access mode to managed objects ”either READ-ONLY or READ-WRITE. A READ-ONLY access mode means that no agent MIB objects can be written by a manager. MIB views are associated with specific access modes.

SNMP agents can be hosted on almost any computing device, including:

• Windows NT/2000 machines

• UNIX hosts

• Novell NetWare workstations and servers

• Many network devices, including hubs, routers, switches, terminal servers, PABXs, and so on

The agent listens on UDP port 161 for the following SNMP message types:

• Get requests the values of the specified object instances.

• Get- next requests the values of the lexical successors of the specified object instances.

• Get-bulk requests the values of portions of a table.

• Set modifies a specified set of object instance values.

The above messages either retrieve ( get ) or modify ( set ) NE data as defined in the MIB. The agent uses UDP port 162 for sending notification messages to a preconfigured IP address. Agents reside in the managed network and communicate with managers (described in the next section).

The SNMP Manager

SNMP managers are the entities that interact with agents. They provide the following functionality:

• Getting and setting the values of MIB object instances on agents

• Receiving notifications from agents

• Exchanging messages with other managers

It is unusual nowadays to have to write either SNMP agent or manager programs. Many system software vendors include them as standard software components. For example, all of the following products include an SNMP agent and manager:

• The pSOS [PSOS] real-time, embedded operating system

• The VxWorks [VXWORKS] real-time, embedded operating system

• The Java JDMK toolkit

In the cases of pSOS and VxWorks, the SNMP agent can be ported to an embedded system, such as a switch or router. This device then constitutes an NE and can be managed by an NMS. The SNMP agent on the NE can be considered part of another component called the EMS (which we met earlier). This is software dedicated to managing the NE. Various mechanisms for accessing the EMS are allowed, including:

• Serial

• Telnet

• SNMP

The NMS generally interacts with the EMS on its managed NEs using one of the above access methods . When an NE is first deployed in its factory-default state, it is often necessary to configure it via a serial interface. The other services and protocols available on the NE can then be enabled so that it can subsequently be accessed over a network. The major focus of this book is the NMS.

In Chapter 7, "Rudimentary NMS Software Components," we build basic Visual C++ and JDMK Java SNMP manager programs. Normally, an SNMP manager is a low-level software entity embedded in a larger body of software called the management application. The combination of the user , management application, SNMP manager, and multiple distributed SNMP agents constitutes the management system. Facilities offered by a management system are:

• FCAPS

• A centralized database

• Reporting

• Support for many simultaneous client users

• Topology discovery (not all NMS provide this)

• A full-featured , multilevel GUI representing the managed network

Both agents and managers support MIBs. Agents implement their MIB objects and (where appropriate) map them to real NE data. An example of such a mapping is between the ipInReceives object (from the IP MIB table) and the underlying NE IP protocol implementation. Strictly speaking, this mapping holds true for a host. For a router, the ipInReceives object is maintained by the interface statistics. However, in either case, the ipInReceives object maps to a piece of data maintained by a designated section of the NE.

The MIB

The importance of MIBs cannot be overstated. This is a recurring theme throughout this book. MIBs are a crucial component ”perhaps the crucial component ”of an NMS because they contain the data definitions for the managed objects. In Chapter 8 we use the MPLS MIBs to create LSPs. A MIB is simply a managed-object data description. The MIB defines the syntax (type and structure) and semantics of the managed objects. SNMP managers and agents exchange managed object instances using the SNMP protocol.

Managed objects may be defined using what are called textual conventions . These are essentially refinements of basic types (that are very loosely analogous to programming language data types or even Java/C++ classes), and some of those included in SMIv2 (Structure of Management Information) are:

• MacAddress is an IEEE 802 MAC address.

• TruthValue is a boolean value representing true (1) or false (2).

• TestAndIncr prevents two managers from simultaneously modifying the same object. Setting an object of type TestAndIncr to a value other than its current value fails. We will see a similar mechanism used in the MPLS tables.

• RowStatus is a standard way for adding and removing entries from a table (we will see this object used many times in the MPLS configuration examples).

• StorageType specifies how a row should be stored.

As discussed in the previous section, an example of a MIB object is the number of IP packets received by a host TCP/IP protocol stack from its interfaces. The MIB object called ipInReceives , in the IP group , fulfills this function (see Figure 1-8). Each IP packet received from a registered interface (including those received in error) results in the host agent incrementing the MIB object instance value for ipInReceives .

In addition to using textual conventions, MIB objects have additional attributes that are now described.

MIB Object Attributes

All SMIv2 MIB objects have a number of common attributes, including:

• SYNTAX : This is the object format ”for example, Unsigned32 (an integer), TruthValue (a Boolean true or false), and SEQUENCE (a container of other objects).

• MAX-ACCESS : This specifies the accessibility of the object ”for example, read-only means that the object can only be read (but not written) by managers.

• STATUS : This is the state of support for the object in the MIB ”for example, current means that the object is relevant and can or should be supported.

• DESCRIPTION : This is a text description of the object.

• DEFVAL : This is a default value that the agent can use when the object instance is first created.

• OBJECT IDENTIFIER : This is the unique name for a MIB object, described in the next section.

Managers use the object attributes in order to manipulate and understand MIB objects. Figure 1-7 illustrates an object called mplsFTNAddrType from the MPLS Forwarding Equivalency Class-To-Next Hop Label Forwarding Entry (FTN) MIB. This important MPLS MIB is described in more detail in Chapter 9, "Network Management Theory and Practice," to illustrate the way in which policy-based management is finding its way into the operation of MPLS NEs. For now, we examine the elements of a single object from this MIB in order to describe the above attributes.

It's very important to be able to read MIBs, so we briefly describe the object in Figure 1-7. The first line is added for information only. It describes the columns in the figure. In the left-hand column is the line number, and the right-hand column shows the attributes (or characteristics) of the object. Real MIBs do not contain line numbers or headings like this. So, the real version of this MIB (in an agent or NMS) would not contain either the top line or the line numbers in the left-hand column.

On line 1, we see a MIB object called mplsFTNAddrType . This identifies the MIB object with a symbolic name. An NMS (or MIB browser) can do get s and set s using this name. We know this is a MIB object because of the keyword OBJECT-TYPE .

Line 2 indicates the syntax of the object ( mplsFTNAddrType ). It shares the syntax of another object called InetAddressType (defined in a MIB called INET-ADDRESS-MIB ). This illustrates the way SNMP reuses legacy components to build new ones. The SYNTAX InetAddressType is imported from the latter MIB and represents an IP address string.

Line 3 indicates that the MAX-ACCESS (or operational permissions) allowed on object instances of type mplsFTNAddrType is read-create. This means that a manager can either read an existing object instance or create a new one.

Line 4 indicates that the STATUS of mplsFTNAddrType is current, meaning that this object should be supported.

Line 5 gives a DESCRIPTION of mplsFTNAddrType and provides a useful textual reason for the use of this object.

Line 6 provides an acceptable default value for instances of mplsFTNAddrType . This is indicated by the DEFVAL clause and in this case has the symbol value ipv4 (this has the value ipV4 , or 1 , as seen in the DESCRIPTION ). Later we will see the importance of default values in the NMS.

Line 7 indicates the name used to access this object via SNMP ”in this case it is column number 6 in the table row called mplsFTNEntry (defined earlier in this MIB).

Understanding the contents of Figure 1-7 takes us a long way on the road to understanding MIB objects. We now delve a little more deeply into the overall structure of MIBs.

OIDs and Lexicographic Ordering

All MIB objects have unique names called object identifiers (OIDs). An OID is a sequence of 32-bit unsigned integers that represents a node within a tree-based structure (with a single root). Only an instance of a MIB object can be retrieved from an agent. An instance of a MIB object is identified by an OID concatenated with the instance value. The instance value is a sequence of one or more 32-bit unsigned integers.

The order of the OIDs is an important aspect of SNMP. All objects can be traced from the root in a process called walking the MIB . During a walk, each branch of the MIB tree is traversed from left to right starting at the root. For example, the standard IP group or table has the OID 1.3.6.1.2.1.4, as illustrated in Figure 1-8. The IP group and some of its constituent objects are shown in this diagram.

MIBs are plain-text files. They are compiled into the agent source code and become part of the executable file. If a manager wants to access some agent MIB objects, then either the associated MIB module file is needed or a MIB walk can be attempted.

All MIB objects follow the model depicted in Figure 1-8. The IP object is a table that contains scalar (single-value) objects. It is also possible to have non-tabular scalar objects in the MIB, as we'll see in Chapter 2, Figure 2-5. Appendix C contains a list for part of the IP table retrieved from a real device.

Another important aspect of lexicographic ordering is that a manager can use it to "discover" an agent MIB. This is for that case in which the manager does not have a copy of the agent MIB and needs to determine what objects the agent supports. The discovery process consists of walking the MIB. It should be noted that this is not a very good way of retrieving agent data. It is far better to have the MIB details at the manager side because the structure and meaning of the NE data will then be apparent.

SNMP Protocol Data Units (PDU)

SNMP managers and agents communicate using a very simple messaging protocol. This is a straightforward fetch ( get ), store ( set ), and notification model [ComerStevens]. Managers retrieve agent data using get operations, and they modify agent data using set operations. When agents want to communicate some important event, they do so by sending a notification message to a preconfigured IP address. If the agent wants to receive an acknowledgment from the manager, then it sends an inform message.

Table 1-2 illustrates the protocol messages provided by the different versions of SNMP.

Table 1-2. Protocol Data Units in the Different Versions of SNMP