When describing any framework for network management, certain questions must inevitably be addressed:
The Internet Network Management Framework exactly addresses the the questions posed above. The framework consists of four parts:
In the following four sections, we cover the four major components of
the Internet network management framework in more detail.
SMI Base Data Types
RFC 2578 [RFC 2578] specifies the basic data
types in the SMI MIB module-definition language. Although the
SMI is based on the ASN.1 (Abstract Syntax Notation One) [ISO
1987, ISO X.680] object definition language
(see section 8.4) developed by the ISO in the 1980, enough SMI-specific
data types have been added that SMI should be considered a data definition
language in its own right. The eleven basic data types defined in RFC 2578
are shown in Table 8.3-1. In addition to these scalar objects, it
is also possible to impose a tabular structure on an ordered collection
of MIB objects using the SEQUENCE OF construct; see [RFC
2578] for details. Most of the data types in Table 8.3-1 will
be familiar (or self-explanatory) to most readers. The one data type
we will discuss in more detail shortly is the OBJECT IDENTIFIER data type,
which is used to name an object.
Data type | Description |
INTEGER | 32 bit integer, as defined in ASN.1, with a value between -2^31 and 2^31-1 inclusive, or a value from a list of possible named constant values |
Integer32 | 32 bit integer with a value between -2^31 and 2^31-1 inclusive |
Unsigned32 | Unsigned 32 bit integer in the range 0 to 2^23-1 inclusive |
OCTET STRING | ASN.1-format byte string representing arbitrary binary or textual data, up to 65535 bytes long |
OBJECT IDENTIFIER | ASN.1-format administratively assigned (structured name); see section 8.3 |
IPaddress | 32-bit Internet address, in network byte order |
Counter32 | 32-bit counter that increases from 0 to 2^32-1 and then wraps around to 0. |
Counter64 | 64-bit counter |
Gauge32 | 32-bit integer that will not count above 2^31-2 nor decrease beyond 0 when increased or decreased |
TimeTicks | time, measured in 1/100ths of seconds since some event |
Opaque | uninterpreted ASN.1 string, needed for backward compatibility |
SMI Higher Level Constructs
In addition to the basic data types, the SMI data definition language also provides higher level language constructs:
ipInDelivers OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of input datagrams successfully delivered
to IP user-protocols (including ICMP)."
::= { ip 9 }
Postal: Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
US
Phone: +1 408 526 5260
Email: kzm@cisco.com"
DESCRIPTION
"The MIB module for managing IP and ICMP implementations,
but excluding their management of IP routes."
REVISION "9103310000Z"
DESCRIPTION
"The initial revision of this MIB module was part of MIB-
II."
::= { mib-2 48}
As noted above, the Management Information Base, MIB, can be thought of as a virtual information store, holding managed objects whose values collectively reflect the current "state" of the network. These values may be queried and/or set by a managing entity by sending SNMP messages to the agent that is executing in a managed node on behalf of the managing entity. Managed objects are specified using the OBJECT-TYPE SMI construct discussed above and gathered into MIB modules using the MODULE-IDENTITY construct.
The IETF has been busy standardizing the MIB modules (i.e., the management information) associated with routers, hosts and other network equipment. This includes basic identification data about a particular piece of hardware, and management information about the device's network interfaces and protocols. As of the release of SNMPv3 (mid-1999), there were nearly 100 standards-based MIB modules and an even larger number of vendor-specific (private) MIB modules. With all of these standards, the IETF needed a way to identify and name the standardized modules, as well as the specific managed objects within a module. Rather than start from scratch, the IETF adopted a standardized object identification (naming) framework that had already been put in place by the International Organization for Standardization (ISO). As is the case with many standards bodies, the ISO had "grand plans" for their standardized object identification framework - to identify every possible standardized object (e.g., data format, protocol, or piece of information) in any network, regardless of the network standards organization (e.g., Interne IETFt, ISO, IEEE, or ANSI), equipment manufacturer, or network owner. A lofty goal indeed! The object identification framework adopted by ISO is part of the ASN.1 (Abstract Syntax Notation One) [ISO 1987, ISO X.680] object definition language (see section 8.4). Standardized MIB modules have their own cozy corner in the all encompassing naming framework, as discussed below.
As shown in Figure 8.3-1, objects are identified in the ISO naming framework in a hierarchical manner. Note that each branch point in the tree has both a name and a number (shown in parenthesis); any point in the tree is thus identifiable by the sequence of names or numbers that specify the path from the root to that point in the identifier tree. A fun, but incomplete and unofficial, WWW-based utility for traversing part of the object identifier tree (using branch information contributed by volunteers) is http://www.alvestrand.no/harald/objectid/top.html.
At the top of the hierarchy are the International Organization for Standardization (ISO) and the Telecommunication Standardization Sector of the International Telecommunication Union (ITU-T), the two main standards organizations dealing with ASN.1, as well as a brach for joint efforts by these two organizations. Under the ISO branch of the tree, we find entries for all ISO standards (1.0) and for standards issued by standards bodies of various ISO-member countries (1.2). Although not shown in Figure 8.3-1, under (ISO ISO-Member-Body, a.k.a. 1.2) we would find USA (1.2.840), under which we would find a number of IEEE, ANSI, and company-specific standards. These include RSA (1.2.840.11359) and Microsoft (1.2.840.113556), under which we find the Microsoft File Formats (1.2.840.112556.4) for various Microsoft products, such as Word (1.2.840.11356.4.2). But we are interested here in networking (not Microsoft Word files), so let us turn our attention to the branch labeled 1.3 - the standards issued by bodies recognized by the ISO. These include the US Department of Defense (6) (under which we will find the Internet standards), the Open Software Foundation (22), the airline association SITA (69) and NATO-identified bodies (57), as well as many other organizations.
Under the Internet branch of the tree (1.3.6.1), there are seven categories. Under the private (1.3.6.1.4) branch, we will find a list [IANA 1999b] of the names and private enterprise codes of more than 4000 private companies that have registered with the Internet Assigned Numbers Authority (IANA) [IANA 99]. Under the management (1.3.6.1.2) and MIB-2 branch (1.3.6.1.2.1) of the object identifier tree, we find the definitions of the standardized MIB modules.
Standardized MIB modules
The lowest level of the tree in Figure 8.3-1 shows some of the important hardware-oriented MIB modules (system and interface) as well as modules associated with some of the most important Internet protocols. [RFC 2400] lists all of the standardized MIB modules. While MIB-related RFC's make for rather tedious and dry reading, it is instructive (i.e., line eating vegetables, it is "good for you") to consider a few MIB module definitions to get a flavor for the type of information in a module.
The managed objects falling under system contain general information
about the device being managed; all managed devices must support the system
MIB objects. Table 8.3-2 defines the objects in the system group, as defined
in [RFC 1213].
Object Identifier | Name | Type | Description (from RFC 1213) |
1.3.6.1.2.1.1.1 | sysDescr | OCTET STRING | "full name and version identification of the system's hardware type, software operating-system, and networking software" |
1.3.6.1.2.1.1.2 | sysObjectID | OBJECT IDENTIFIER | Vendor assigned object ID that "provides an easy and unambiguous means for determining `what kind of box' is being managed." |
1.3.6.1.2.1.1.3 | sysUpTime | TimeTicks | "The time (in hundredths of a second) since the network management portion of the system was last re-initialized." |
1.3.6.1.2.1.1.4 | sysContact | OCTET STRING | "The contact person for this managed node, together with information on how to contact this person." |
1.3.6.1.2.1.1.5 | sysName | OCTET STRING | "An administratively-assigned name for this managed node. By convention, this is the node's fully-qualified domain name" |
1.3.6.1.2.1.1.6 | sysLocation | OCTET STRING | "The physical location of this node." |
1.3.6.1.2.1.1.7 | sysServices | Integer32 | A coded value that indicates the set of services available at this node: physical (e.g., a repeater), datalinkl/subnet (e.g., bridge), internet (e.g., IP gateway), end-end (e.g., host), applications. |
Table 8.3-3 defines the managed objects in the MIB module for
the UDP protocol at a managed entity.
Object Identifier | Name | Type | Description (from RFC 2013) |
1.3.6.1.2.1.7.1 | udpInDatagrams | Counter32 | "total number of UDP datagrams delivered to UDP users" |
1.3.6.1.2.1.7.2 | udpNoPorts | Counter32 | "total number of received UDP datagrams for which there was no application at the destination port" |
1.3.6.1.2.1.7.3 | udpInErrors | Counter32 | "number of received UDP datagrams that could not be delivered for reasons other than the lack of an application at the destination port" |
1.3.6.1.2.1.7.4 | udpOutDatagrams | Counter32 | "total number of UDP datagrams sent from this entity" |
1.3.6.1.2.1.7.5 | udpTable | SEQUENCE of UdpEntry | a sequence of UdpEntry objects, one for each port that is currently open by an application, giving the IP address and the port number used by application |
SNMPv2 PDU Type | sender-reciever | Description |
GetRequest | manager-to-agent | get value of one or more MIB object instances |
GetNextRequest | manager-to-agent | get value of next MIB object instance in list or table |
GetBulkRequest | manager-to-agent | get values in large block of data, e.g. values in a large table |
InformRequest | manager-to-manager | inform remote managing entity of MIB values remote to its access |
SetRequest | manager-to-agent | set value of one or more MIB object instances |
Response | agent-to-manager
or manager-to-manager |
generated in response to GetRequest, GetNextRequest, GetBulkRequest, SetRequestPDU, or InformRequest, |
SNMPv2-Trap | agent-to-manager | inform manager of an exceptional event |
SNMPv2 defines seven types of messages, known generically as Protocol Data Units - PDUs, as shown in Table 8.3-4. The format of the PDU is shown in Figure 8.3-2. The GetRequest, GetNextRequest, and GetBulkRequest PDUs are all sent from a managing entity to an agent to request the value of one or more MIB objects at the agent's managed device. The object identifiers of the MIB objects whose values are being requested are specified in the variable binding portion of the PDU. GetRequest, GetNextRequest, and GetBulkRequest differ in the granularity of their data requests. GetRequest can request an arbitrary set of MIB values; multiple GetNextRequests can be used to sequence through a list or table of MIB objects; GetBulkRequest allows a large block of data to be returned, avoiding the overhead incurred if multiple GetRequest or GetNextRequest messages were to be sent. In all three cases, the agent responds with a Response PDU containing the object identifiers and their associated values.
The SetRequest PDU is used by a managing entity to set the
value of one or more MIB objects in a managed device. An agent replies
with a Response PDU with the 'noError' Error Status to confirm
that the value has indeed been set.
The InformRequest PDU is used by a managing entity to notify
another managing entity of MIB information that is remote to
the receiving entity. The receiving entity replies with a Response
PDU with the 'noError' Error Status to acknowledge receipt of the InformRequest
PDU.
Given the request-response nature of SNMPv2, it is worth noting here that although SNMP PDU's can be carried via many different transport protocols, the SNMP PDU is typically carried in the payload of a UDP datagram. Indeed, [RFC 1906] states that UDP is "the preferred transport mapping." Since UDP is an unreliable transport protocol, there is no guarantee that a request, or its response will be received at the intended destination. The Request ID field of the PDU is used by the managing entity to number its requests to an agent; an agent's response takes its Request ID from that of the received request. Thus, the Request ID field can be used by the managing entity to detect lost requests or replies. It is up to the managing entity to decide whether to retransmit a request if no corresponding response is received after a given amount of time. In particular, the SNMP standard does not mandate any particular procedure for retransmission, or even if retransmission is to be done in the first place. It only requires that the managing entity "needs to act responsibly in respect to the frequency and duration of re-transmissions." Which, of course, leads one to wonder how a "responsible" protocol should behave!
The final type of SNMPv2 PDU is the trap message. Trap message
are generated asynchronously, i.e., not in response to a received
request but rather in response to an event for which the managing entity
requires notification. [RFC 1907] defines
well-known trap types that include a cold or warm start by a device, a
link going up or down, the loss of a neighbor, or an authentication failure
event. A received trap request has no required response from a managing
entity.
As SNMP has matured through three versions, its functionality has grown but so too, alas, has the number of SNMP-related standards documents. This is evidenced by the fact that there is even now an RFC [RFC 2571] that " describes an architecture for describing SNMP Management Frameworks"! While the notion of an "architecture" for "describing a framework" might be a bit much to wrap one's mind around, the goal of RFC 2571 is an admirable one - to introduce a common language for describing the functionality and actions taken by an SNMPv3 agent or managing entity. The architecture of an SNMPv3 entity is straightforward, and tour through the architecture will serve to solidify our understanding of SNMP.
The so-called SNMP applications consist of a command generator, notification receiver and proxy forwarder (all of which are typically found in a managing entity); a command responder and notification originator (both of which are typically found in an agent); and the possibility of other applications. The command generator generates the GetRequest, GetNextRequest, GetBulkRequest and SetRequest PDUs that we examined above in section 8.3.3 and handles the received responses to these PDUs. The command responder executes in an agent and receives, processes and replies (using the Response message) to received GetRequest, GetNextRequest, GetBulkRequest and SetRequest PDUs. The notification originator application in an agent generates Trap PDUs; these PDUs are eventually received an processed in a notification receiver application at a managing entity. The proxy forwarder application forwards request, notification, and response PDUs.
A PDU sent by an SNMP application next passes through the SNMP "engine" before it is sent via the appropriate transport protocol. Figure 8.3-3 shows how a PDU generated by the command generator application first enters the dispatch module, where the SNMP version is determined. The PDU is then processed in the message processing system, where the PDU is wrapped in a message header containing the SNMP version number, a message ID and message size information. If encryption or authentication is needed then the appropriate header fields for this information is included as well; see [RFC 2571] for details. Finally, the SNMP message (the application-generated PDU plus the message header information) is passed to the appropriate transport protocol. The preferred transport protocol for carrying SNMP messages is UDP (i.e., SNMP messages are carried as the payload in a UDP datagram), and the preferred port number for the SNMP is port 161.
We have seen above that SNMP messages are used to not just monitor, but also to control (e.g., through the SetRequest command) network elements. Clearly, an intruder that could intercept SNMP messages and/or generate its own SNMP packets into the management infrastructure could wreak havoc in the network. Thus, it is crucial that SNMP messages be transmitted securely. Surprisingly, it is only in the most recent version of SNMP that security has received the attention that it deserves. SNMPv3 provides for encryption, authentication, protection against playback attacks (see sections 7.2 and 7.3), and access control. SNMPv3 security is known as user-based security [RFC 2574] in that there is the traditional concept of a user, identified by a user name, with which security information such as a password, key value, or access privileges are associated.
Copyright Keith W. Ross and Jim Kurose 1996-1999