How SNMP Works

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

How SNMP Works

In this section

• SNMP Architecture

• SNMP Manager/Agent Communication

• SNMP Management Systems and Agents

• SNMP Messages

• SNMP Communities

• Related Information

Use Simple Network Management Protocol (SNMP) management software to monitor any network device configured with SNMP agent software. The SNMP agent, which is an optional component of Windows Server 2003, interacts with third-party SNMP management software to enable the flow of network status information between monitored devices and applications and the management systems that monitor them.

You can use SNMP in environments that include large networks with hundreds or thousands of nodes that would otherwise be difficult and costly to monitor. SNMP allows monitoring of network devices such as servers, workstations, printers, routers, bridges, and hubs, as well as services such as Dynamic Host Configuration Protocol (DHCP) or Windows Internet Name Service (WINS).

The following sections describe the architecture, components, and processes used by SNMP.

SNMP Architecture

To perform its monitoring services, SNMP uses a distributed architecture of management systems and agents and several related components. Windows Server 2003 provides an SNMP agent that is designed to be capable of interacting with any SNMP manager. The following components are the building blocks of SNMP and the Windows Server 2003 SNMP agent:

• SNMP management systems and agents

• Management Information Base (MIB)

• SNMP Messages

• SNMP Communities

• The communication process between SNMP managers and agents

The internal architecture of the Windows Server 2003 implementation of SNMP is divided into management and agent functions, which, in some cases, overlap. The following figure illustrates how the Windows Server 2003 SNMP structure fits into the layers of the underlying TCP/IP protocol architecture.

Windows Server 2003 SNMP Components at Each TCP/IP Layer

The following table lists the Windows Server 2003 SNMP internal components.

Windows Server 2003 SNMP Components

Component Name	Associated Programs	Component Type	Description
Microsoft SNMP Service (Also called master agent or extendible agent)	Snmp.exe	Agent	Receives SNMP requests and delivers them to the appropriate SNMP subagent DLL for processing. The service is also responsible for intercepting events (traps) from the SNMP subagents and forwarding trap messages to the appropriate management systems.
SNMP Subagents (Also called extension agents)	Inetmib1.dll, Hostmib.dll, Lmmib2.dll, and others	Agent	Provides a set of entry points. When an SNMP request is received, the SNMP service delivers it to the appropriate subagent by calling one of these entry points. After the subagent processes the message, it passes the information back to the SNMP service, which then forwards the message to the SNMP manager.
SNMP Utility API	Snmpapi.dll	Both Agent and Manager	Provides utilities that the SNMP service uses for memory management operations, address-decoding routines, object identifier handling routines, and so forth. Provides a set of routines that SNMP subagents use to handle and order SNMP objects. Although use of the Snmpapi.dll is not required, the framework defined by this tool greatly facilitates the development of new SNMP subagents.
WinSNMP API -and- Management API	Wsnmp32.dll -and- Mgmtapi.dll	Manager	Helps develop SNMP management software applications: The WinSNMP API provides a set of functions for encoding, decoding, sending, and receiving SNMP messages. The Management API is a simple API that resides on top of the WinSNMP and SNMP Utility APIs. It provides a limited set of functions that you can use to develop basic SNMP management applications quickly.
SNMP Trap Service	Snmptrap.exe	Manager	Uses the WinSNMP API to forward a trap message sent by an SNMP agent to the appropriate SNMP manager application.
SNMP Manager Application	Snmputil.exe	Manager	Provides a basic command-line utility with which to retrieve information from any SNMP agent in your network. This example of a management application was developed using the Management API.

SNMP Manager/Agent Communication

The following figure shows an example of the communication process between SNMP managers and agents.

Manager Requesting Number of Sessions from an SNMP Agent

The communication between the SNMP manager and SNMP agent in the example proceeds in the following fashion:

1. The SNMP manager, Host A, forms an SNMP message that contains an information request (Get) for the number of active sessions, the name of the community to which the SNMP manager belongs, and the destination of the message —the IP address (131.107.3.24) of the SNMP agent, Host B.

   The SNMP manager can use either the Microsoft SNMP Management API library (Mgmtapi.dll) or the Microsoft WinSNMP API library (Wsnmp32.dll) to perform this step.

2. The SNMP manager sends the information request to Host B by using the SNMP service libraries.

3. When Host B receives the message, it verifies that the community name (MonitorInfo) contained in the packet is on its list of acceptable community names, evaluates the request against the agent’s list of access permissions for that community, and verifies the source IP address.

   If the community name or access permission is incorrect, and the SNMP service has been configured to send an authentication trap, the agent sends an “authentication failure” trap to the specified trap destination, Host C. Hosts B and C belong to the TrapAlarm community.

4. The master agent component of the SNMP agent calls the appropriate extension agent to retrieve the requested session information from the MIB.

5. Using the session information that it retrieved from the extension agent, the SNMP service forms a return SNMP message that contains the number of active sessions and the destination — the IP address (131.107.7.29) of the SNMP manager, Host A.

6. Host B sends the response to Host A.

SNMP Management Systems and Agents

SNMP locates the network management component on one or more computers and locates the managed component on multiple managed devices:

• SNMP manager. An SNMP manager, also known as an SNMP management system or a management console, is any computer that sends queries for IP-related information to a managed computer, known as an SNMP agent. In some cases, the SNMP manager can send a request to an SNMP agent to change a configuration value.

• SNMP agent. An SNMP agent is any computer or other network device that monitors and responds to queries from SNMP managers. The agent can also send a trap message to the manager when specified events, such as a system reboot or illegal access, occur.

A computer on which you install SNMP management software is an SNMP manager, and a computer on which you install agent software, such as the Microsoft SNMP agent included with Windows Server 2003, is an SNMP agent. The SNMP manager displays the information it receives in a user-friendly graphical user interface. You configure SNMP options, including traps, on the SNMP agent, but the SNMP agent does not display the managed information that it sends to an SNMP manager. For more information about SNMP requests and trap messages, see “SNMP Messages” later in this section.

To enable SNMP communications between an SNMP manager and SNMP agents, you configure the SNMP manager and the SNMP agents that it manages as members of an SNMP community. The community name functions like a password to authenticate communications between the SNMP manager and agent. The SNMP community is an SNMP-defined group, not a group defined in the Active Directory directory service. For more information about SNMP communities, see “SNMP Communities” later in this section.

An SNMP manager can request the following types of information from the SNMP agents that it monitors:

• Network protocol identification and statistics

• Dynamic identification (discovery) of devices attached to the network

• Hardware and software configuration data

• Device performance and usage statistics

• Device error and event messages

• Program and application usage statistics

If you assign the SNMP manager write permission for the SNMP agent, the SNMP manager can also send a configuration request to the agent (using a Set message) to change a local parameter. However, Set requests are limited to a small set of client parameters that have read-write access defined. Most client parameters allow only read-only access.

Understanding the Management Information Base (MIB)

When an SNMP manager requests information from an SNMP agent, the SNMP agent retrieves the current value of the requested information from the Management Information Base (MIB). The MIB defines the managed objects that an SNMP manager monitors (or sometimes configures) on an SNMP agent.

Each system in a network (workstation, server, router, bridge, and so forth) maintains a MIB that reflects the status of the managed resources on that system, such as the version of the software running on the device, the IP address assigned to a port or interface, the amount of free hard drive space, or the number of open files. The MIB does not contain static data, but is instead an object-oriented, dynamic database that provides a logical collection of managed object definitions. The MIB defines the data type of each managed object and describes the object.

The MIB Tree

The SNMP-related branches of the MIB tree are located in the internet branch, which contains two main types of branches:

• Public branches (mgmt=2), which are defined by the Internet Engineering Task Force (IETF) RFCs, are the same for all SNMP-managed devices.

• Private branches (private=4), which are assigned by the Internet Assigned Numbers Authority (IANA), are defined by the companies and organizations to which these branches are assigned.

The following figure shows the structure of the SNMP MIB tree. There are no limits on the width and depth of the MIB tree.

The Structure of the SNMP MIB Tree

Immediately beneath the root of the MIB tree, International Organization for Standardization (iso), is the Organization (org) branch, followed by Department of Defense (dod), and then Internet (internet). Management (mgmt), the main public branch, defines network management parameters common to devices from all vendors. Underneath the Management branch is MIB-II (mib-2), and beneath this are branches for common management functions such as system management, printers, host resources, and interfaces.

The private branch of the MIB tree contains branches for large organizations, organized under the enterprises branch. Each organization has a root branch node under this object. Each organization creates its own subset of MIB branches and objects, which must comply with a common definition of SNMP information known as Structure of Management Information (SMI). SMI defines the allowed data types for MIB objects.

MIB Objects

At the programmatic level, the definition of each MIB object that an SNMP agent manages includes the following elements:

• The object name and object identifier (also known as an OID).

• A text description of the object.

• The object’s data-type definition (such as counter, string, gauge, or address).

• The index for objects that are assigned complex data types. The index specifies the key field for the table — that is, the field that can be used to identify a row.

  The only complex SNMP data type that is allowed is a table, and tables cannot be nested. Examples include the list of a system’s network interfaces, a routing table, or the Address Resolution Protocol (ARP) table.

• The level of access to the object (such as read or read/write) that is allowed.

• Size restrictions.

• Range information.

SNMP references each MIB variable by using its unique object identifier, which identifies the location of a given managed object within the MIB namespace. The object identifier reflects the object’s position within the hierarchy of the MIB tree, containing a sequence of subidentifiers that begin at the root of the MIB tree and end at the object (leaf node). Subidentifiers are separated with a period.

To reference a MIB object, you can use either numeric or text subidentifiers. For example, the following text-based object identifier is interchangeable with its numeric counterpart, shown beneath it. The value of this object identifier, in either format, identifies the current operational state of a network adapter.

.iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifOperStatus

.1.3.6.1.2.1.2.2.1.8

Corresponding to each object identifier is a value that represents the current state of the object. SNMP, which accesses only the leaf nodes in the MIB tree, references a MIB variable by the dotted numeric string that represents its object identifier in order to retrieve the current value of the variable.

Microsoft has the authority to assign names to objects within the 311 (microsoft) namespaces. For example, Microsoft (itself represented in MIB notation as .1.3.6.1.4.1.311) defines various MIB branches under its root node, such as:

.1.3.6.1.4.1.311.1.3 — Dynamic Host Configuration Protocol (DHCP)

.1.3.6.1.4.1.311.1.2 — Windows Internet Name Service (WINS)

.1.3.6.1.4.1.311.1.7.2 — File Transfer Protocol (FTP)

.1.3.5.1.4.1.311.1.7.3 — Hypertext Transfer Protocol (HTTP)

Interacting with MIB Objects

To understand how SNMP interacts with MIB objects, you must first understand that the SNMP agent consists of a master agent and one or more subagents, also known as extension agents, which are the dynamic link libraries (DLLs) that SNMP uses to process a request received from an SNMP manager.

When the SNMP service starts, it loads each SNMP extension agent that is listed in the registry. When the master agent receives a request from the SNMP manager, it passes the request to an extension agent, which accesses the appropriate MIB and returns the current value of the relevant MIB object to the SNMP master agent. The SNMP agent then returns the information to the SNMP manager. An SNMP agent can also send unsolicited MIB information to the SNMP manager in response to an event that has been defined as an SNMP trap (unexpected event). In some cases, the SNMP agent changes (or sets) the value of the MIB object.

For example, in order to assess the network load at a particular point in your network, you can use SNMP to retrieve the value of a counter that tracks the number of packets sent over a link to the SNMP agent. Or you might use SNMP to retrieve the value that represents the amount of disk space available for storage. Although SNMP is used less commonly to set the value of a MIB object, to ensure that a link is not used, you might use SNMP to set the link state value of a MIB object to a disabled state.

Compiling a New or Updated MIB File by Using Mibcc.exe

As explained earlier, the SNMP-related branches of the MIB tree are located in the internet branch of the tree. The internet branch contains public branches that are defined by the IETF and private branches that are defined by large organizations. When an organization creates its own subset of MIB branches and objects, or updates an existing MIB file, the new or updated MIB file must be created in compliance with SMI-prescribed data types.

If your organization adds or updates a new MIB file, use the Mibcc.exe tool to compile the MIB file so that the SNMP Management API (Mgmtapi.dll) can use the MIB objects in the new or updated MIB file. After you compile the MIB file, you can reference objects by their text object identifiers instead of their numeric object identifiers. The ASN.1 language is used to define the formats of the protocol data units (PDUs) that are exchanged by SNMP entities and to define the objects that are managed through SNMP. Mibcc.exe converts the ASN.1 MIB description into the binary Mib.bin file, which the Management API then uses to map text-based object names to numeric object identifiers.

You can find Mibcc.exe in the C:\Program Files\Resource Kit folder when you install the Windows Server 2003 Resource Kit companion CD. The Mib.bin file is located in systemroot on Windows Server 2003.

SNMP Messages

SNMP sends operation requests and responses as SNMP messages. An SNMP message consists of an SNMP protocol data unit (PDU) plus additional message header elements defined by the relevant RFC. An SNMP agent sends information in two situations:

• When it responds to a request from an SNMP manager

• When a trap event occurs

SNMP Message Types

The following table describes each type of message that the SNMP manager and agent programs use to communicate with each other.

SNMP Message Types

SNMP Message	From / To	Message Description
Get	Manager / agent	Accesses and retrieves the current value of one or more MIB objects on an SNMP agent .
GetResponse	Agent / manager	Replies to a Get, GetNext, or Set operation.
GetNext	Manager / agent	Browses the entire tree of MIB objects, reading the values of variables in the MIB sequentially. Typically, you use GetNext to obtain information from selected columns from one or more rows of a table. GetNext is especially useful for browsing dynamic tables, such as an internal IP route table or an ARP table, reading through the table one row at a time.
GetBulk (SNMPv2c only)	Manager / agent	Retrieves data in units as large as possible within the given constraints on the message size. GetBulk, which accesses multiple values at one time without using a GetNext message, minimizes the number of protocol exchanges required to retrieve a large amount of information. To avoid fragmentation, restrict the maximum message size to a size smaller than the path maximum transmission unit (MTU), the largest frame size allowed for a single frame on your network. Typically, when it is not known how many rows are in a table, GetBulk is used (rather than GetNext) to browse all rows in the table.
Set	Manager / agent	Changes the current value of a MIB object. In order to update a MIB value on the SNMP agent, the SNMP manager must have write access to the object. Set is used infrequently, because most MIB objects are read-only by default, so that unauthorized changes cannot be made.
Trap	Agent / manager	Notifies the specified SNMP manager (the trap destination) when an unexpected event occurs locally on the managed host. You can use traps for limited security checking (such as notifying the trap destination if the agent receives an information request from an SNMP manager that it does not recognize) or for troubleshooting (such as notifying the trap destination if the WINS service fails).

SNMP uses the connectionless User Datagram Protocol (UDP) service to transmit SNMP messages. SNMP uses the simple UDP transport service, which guarantees neither delivery nor correct sequencing of delivered packets, so that SNMP can continue functioning after many other network services have failed. By default, UDP port 161 is used to listen for SNMP messages and port 162 is used to listen for SNMP traps. If necessary — for example, because your organization already uses ports 161 and 162 for some other protocol or service — you can change these port settings by configuring the local Services file (this Services file is different from the Windows Services snap-in). The following figure shows messages moving between an SNMP manager and several SNMP agents.

Messages Sent Between an SNMP Manager and its Managed Devices

Get Message Requires Instance Identifier

When typing an SNMP command (such as Snmputil.exe), you can specify a MIB object by using either numeric or text subidentifiers. For example, as explained earlier, both of the following notations refer to the object identifier whose value is the current operational status of an interface:

.iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifOperStatus

.1.3.6.1.2.1.2.2.1.8

The object identifier of a MIB object identifies the type of object. The instance identifier of a MIB object, used only in SNMP Get operations, indicates which value to retrieve. That is, a Get operation must specify ObjectIdentifier.SpecificValueToRetrieve. Two types of instance identifiers exist:

• Object is not in a table. If an object can return only one value (such as the description of a system), you append the suffix .0 to the end of the object identifier.

• Object is in a table. If an object can return different values (such as a router that has more than one interface), you append an index at the end of the object identifier to indicate which instance to return. For example, if a router has four interfaces and you want to use a Get command with Snmputil.exe to return the current status of an interface that has an interface index (ifIndex) of 3, you type .3 at the end of the object identifier.

SNMP Trap Types

The SNMP standard defines six types of traps and provides a seventh trap type that an organization can use to implement enterprise-specific traps. The following table lists the seven trap types.

SNMP Trap Types

Trap Type	Trap Name	Description
0	ColdStart	The SNMP agent initialized its configuration tables.
1	WarmStart	The SNMP agent re-initialized its configuration tables.
2	LinkDown	The state of a network adapter on the SNMP agent changed from up to down.
3	Linkup	The state of a network adapter on the SNMP agent changed from down to up.
4	authenticationFailure	The SNMP agent received a message from an SNMP manager, but the message contained an invalid community name.
5	egpNeighborLoss	The SNMP agent could not communicate with its Exterior Gateway Protocol (EGP) peer.
6	enterpriseSpecific	Reserved for vendor-defined error conditions and error codes.

The Windows Server 2003 SNMP service can send enterprise-specific traps on behalf of the Event To Trap Translator.

SNMP Communities

SNMP version 2c introduced the use of shared community names for authentication of SNMP traffic. By default, in Windows Server 2003, no community names are configured and the SNMP service accepts SNMP requests only from the host name, localhost. To enable successful communication between an SNMP agent and an SNMP manager, you must configure at least one community name in SNMP. SNMP community names are case-sensitive.

A community name acts as a password that is shared, typically, by multiple SNMP agents and one or more SNMP managers. You configure the SNMP manager and the computers or devices that it manages as members of a single SNMP community. An SNMP agent only accepts requests from SNMP managers that are on the agent’s list of acceptable community names.

When an SNMP manager sends a query or set request to the SNMP agent, the SNMP service compares the community name of the requestor with the community name of the agent and its access permissions. If the names match, the SNMP manager is successfully authenticated, and the agent replies to the query or performs the set request. If the community names do not match, the SNMP agent considers the request a failed access attempt and — if configured to do so — can send an SNMP trap message notifying the trap destination that an improper access has been attempted.

One computer or device can belong to several communities. SNMP community names are specific to SNMP and are not related to Active Directory or Workgroup names. In the past, the SNMP default community name, Public, was used widely for read-only access and the name, Private, was used for read-write access. To increase security, specify a unique community name and change it frequently, as you would a password.

By defining an SNMP community, you can group computers together for administrative convenience and provide limited security by restricting communication to only those computers that are members of the community. Two common bases for grouping computers into an SNMP community are by physical proximity or by function. The recommended practice is to create SNMP communities based on function rather than location.

In addition to specifying that the SNMP agent can communicate only with a specified set of SNMP managers, you can specify the access permission (such as Read Only or Read Write) for each community and specify that a trap be sent, alerting a trap destination to the authentication failure if either the community name or access permission is incorrect. For the community name, specify the most restrictive permission possible. For example, do not choose the Read Write permission if the Read Only permission is sufficient. Also check the permission level of the MIB access variable. It interacts with the community security level. For example, if your community access level is set to Read Only and the MIB access variable is set to Read Write, the following operations are valid: Get, GetNext, GetResponse, and Trap. However, the Set request is blocked by the more restrictive community access level.

You might want to specify one community name for the SNMP agent and its trap destination and another community name for the SNMP agent and any SNMP manager that sends the agent query and set requests. Using separate community names for requests and traps ensures that the agent has an available destination to which it can send an alert if an unauthorized SNMP manager tries to request information.

The security that the SNMP service provides through the use of community names used in conjunction with access permissions and authentication traps is rudimentary. Because community names are sent across the network as clear text (which is unencrypted), even secret and frequently changed community names with restricted permissions represent a potential security risk. Clear text messages are easily intercepted and decoded by network analyzers such as Microsoft Network Monitor. Community names sent in clear text can be captured and used by unauthorized personnel to access valuable information about network resources.

To help prevent the interception of SNMP messages, configure Internet Protocol Security (IPSec) policies on all SNMP managers and SNMP agents.

Related Information

• For more information about SNMP, see the following RFCs in the IETF RFC Database.

The following RFCs relate to SNMP version 1:

• RFC 1157, “Simple Network Management Protocol (SNMP).”

• RFC 1155, “Structure and Identification of Management Information for TCP/IP-based Internets.”

• RFC 1213, “Management Information Base for Network Management of TCP/IP-based Internets: MIB-II.”

• RFC 1573, “Evolution of the Interfaces Group of MIB-II.”

The following RFCs relate to SNMP version 2:

• RFC 1901, “Introduction to Community–Based SNMPv2.”

• RFC 1902, “Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2).”

• RFC 1903, “Textual Conventions for SNMPv2.”

• RFC 1904, “Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2).”

• RFC 1905, “Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2).”

• RFC 1906, “Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2).”

• RFC 1907, “Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2).”

• RFC 1908, “Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework.”

• RFC 2089, “V2ToV1 Mapping SNMPv2 onto SNMPv1 Within a Bi-Lingual SNMP Agent.”