F5 White PaperSNMP: SimplifiedThe Simple Network Management Protocol defines a methodfor managing devices that connect to IP networks. The“simple” in SNMP refers to the requirements for a manageddevice, not the protocol. This white paper defines the history,frequently used terms, and implementation of Peter Murray and Paul StalvigTechnical Marketing Managers

White PaperSNMP: 5Implementation8Perspective9Conclusion92

White PaperSNMP: SimplifiedIntroductionIt’s no secret that managing networks and applications are complex tasks. Multipletechnologies are in use today, often by the same organization. This article presentsan overview of one technology: the Simple Network Management Protocol (SNMP).SNMP offers a method to monitor and manage network devices and hosts. Thisdocument offers a simplified view of SNMP fundamentals and explains how thefundamental components work together. We’ll look at concepts including networkelements, the Network Management Station (NMS), SNMP and RMON probes, theManagement Information Base (MIB), Object Identifiers (OID), and more.Reading this can help you to achieve two objectives: 1) to better understandSNMP’s purpose and history, and 2) to help you better understand how itscomponents work together to deliver management information and controlnetwork devices.HistoryPrior to SNMP, most network devices were managed as individual elements byproprietary network management software. These software point productscould only manage a single vendor’s devices, and some were merely text-basedcommand-line utilities.The lack of functionality and interoperability resulted in overly complexmanagement implementations. Using a multitude of management systemsand network-related commands made troubleshooting network-related issuesextremely difficult, and prevented IT administrators from being able to see asingle, more complete view of the end-to-end network.Defined by the Internet Engineering Task Force (IETF) in the late ‘80s, SNMP wasdesigned to help monitor complex multi-vendor networks. Since then, two moreSNMP versions have been ratified by the Internet Engineering Task Force (IETF).SNMP v1 provided the basic structure and process required to define networkmanagement information, retrieve information from network devices, controldevices, and allow unsolicited messages—called Traps—to be sent to a NMS.The public, or generic, portion of the SNMP MIB defines generic deviceinformation, some limited performance information, and higher level performanceinformation. The public portion defines information that is primarily useful for3

White PaperSNMP: Simplifiedend stations. Device information and limited network information is available inthe public MIB.The lasting power of SNMP developed out of the capability for otherorganizations to extend the MIB. Most network equipment manufacturers haveadded private extensions to the SNMP MIB that define proprietary equipmentinformation. For example, an Ethernet switch manufacturer may offer a privateMIB extension that includes per-port traffic, user, and error information.SNMP VersionsSNMP v1 has been extended several times to incorporate new features,SNMP v2 added several features, including the capability to retrieve data inbulk rather than individually, and added the capability for the NMS toacknowledge a trap message. SNMP v3 added encryption both for thecommunity strings that are used to access to a network device and the SNMPdata transmitted between devices.SNMP Data CollectionSNMP was primarily used for device-based management, and was designed to beas non-invasive as possible. An important requirement for SNMP was to minimizemanaged-element processing overhead. SNMP was therefore designed to collectand report information, but not to provide sophisticated information processing.For example, an SNMP-managed node doesn’t report information such as linkthroughput; rather, SNMP defines the information to be collected and relies onthe NMS to retrieve and process the information to produce a derived value.In this example, determining link throughput requires an NMS to collect two itemsfrom a managed node—the packet count from a network interface, and systemtime. Collection must be performed twice. The NMS then calculates the numberof bits sent or received over the specified time period.RMON MIB ExtensionsThe Remote MONitoring (RMON) extensions to SNMP, including RMON 1 andRMON 2, were defined by the IETF to add “flow-based” monitoring, as opposedto “device-based” monitoring, which is what SNMP primarily delivers. The firstversion, RMON 1, defined ten management groups that focused on OSI Layer 1and Layer 2 information in Ethernet and Token Ring networks, which help tomonitor LANs. The second version, RMON 2, included ten more groups thatadded support for network protocol- and application-layer monitoring. Comparedto standard SNMP agents, agents that fully support RMON management requiremore processing capability. Because of this requirement, full RMON managementis typically carried out by one or more probes designed specifically for RMON.4

White PaperSNMP: SimplifiedWhen implemented fully, RMON can provide many of the features andfunctionality offered by network analyzers. The disadvantage to RMON is thatRMON agents shoulder a greater management burden because they must collectinformation from managed elements and process that information to providehigher-level data.Many network devices lack the processing horsepower required for extensiveprocessing and instead implement only a small subset of the RMON groups. Infact, a device must only support statistics, history, alarms and events, the first fourRMON 1 groups, to be labeled as RMON-compliant.SMON MIB ExtensionsThe Switch MONitoring (SMON) definition further extended RMON to includedetailed (typically Ethernet-based) LAN switch information. SMON enableddevice-wide reporting and control for the one or more virtual LANs (VLANs)defined on the switch.DefinitionsOften technologies like SNMP change over time due to proprietary vendorextensions and implementations, requiring users to learn numerous new terms.Oddly, SNMP terms have remained true to the initial terminology. While thismay seem irrelevant, it actually shows the full commitment and support vendorshave made to SNMP. Below are the necessary definitions for understandinghow SNMP works.Network Element(s): “Network elements are devices such as hosts, gateways,terminal servers, and the like, which have management agents responsible forperforming the network management functions requested by the networkmanagement stations” (J. Case, 1990). Quite simply, a network element is amonitored device. An element is often referred to as a node or a managednode. The (managed) node construct allows SNMP administrators to referencenetwork elements without the complexity normally associated with other systemadministrators. SNMP administrators may use agent to refer to the softwarerunning on a given network element.Network Management Station (NMS): A server that runs the networkmanagement application. It is the primary recipient that network elementscommunicate with to relay the management and control information; it alsoprovides the methods and means to analyze and report significant information.5

White PaperSNMP: SimplifiedSNMP Relay Device (also known as SNMP Probe, SNMP Collection Point,SNMP Proxy Agent): A node that polls Network Elements to collect informationas a proxy for one or more NMSs. The collecting device may itself be an NMS, forexample, residing in a regional data center. An SNMP Relay Device helps localizeSNMP polling and trap reception, thereby reducing SNMP traffic across enterprisebackbones and WAN links. An SNMP Relay Device may do local processing tosummarize data that can then be sent in bulk to the NMS.RMON Probe: An RMON probe, which resides on a specific LAN, collectsinformation for that LAN, performs more sophisticated processing than anSNMP agent, and reports more complex information such as link and individualLayer 2 throughput.Stand-alone RMON probe appliances are another solution that often deliversmore complete RMON feature support than that found in most networkequipment. RMON and SMON enabled administrators to place probes in thenetwork to perform remote polling, logging, and trap forwarding functions.Probes typically have the extra processing power to analyze and distill informationbefore it is transferred to an NMS.Management Information Base (MIB): The MIB is a database containingObject Identifier (OID) information. The MIB can be depicted as a hierarchicaltree-based structure where the MIB is the “tree” and each individual object isa “leaf.” Each individual object is identified by an OID. Levels within the MIBare assigned by different organizations. The top-level MIB OIDs belong tovarious standards organizations, while lower-level OIDs belong to associatedorganizations such as Network Equipment Manufacturers, who assign OIDs thatextend the MIB with proprietary values.Object Identifier (OID): Object Identifiers identify individual entries, or objects,within the MIB. OIDs are specified using an “x,y” naming convention, definedby Abstract Syntax Notation One (ASN.1). In this naming convention, “x” is anumeric value identifying an OID’s position within the MIB tree and “y” is ahuman-readable OID name, also called a variable name. The numerical OIDsmake searching through the MIB and reporting “human readable information”an easier process. Figure 1 represents the F5 OID hierarchy, which defines all OIDsthat reside below the string beginning with

White PaperSNMP: 2Management1MIB-23Experiment4Private5Security6SNMP (v2)1Enterprise3375F51. 1: F5 OID hierarchyProtocol Data Unit (PDU): A PDU tells the NMS and/or the agent what SNMPaction to take. SNMP version 1 contained the five following PDUs: GetRequest,GetNextRequest, SetRequest, GetResponse, and Trap. SNMP version 2 addedGetBulk Request and Inform (which acknowledges a Trap). GetResponse isthe only PDU used to respond to GetRequest, GetNextRequest, GetBulk, andSetRequest PDUs. All PDUs except Trap are sent via User Datagram Protocol (UDP)on Port 161. Traps are sent on UDP Port 162.Traps or Alerts: Traps or alerts are the method by which important, unsolicitedinformation is reported to an NMS by a network element to an NMS or probe. Notrap response is defined in SNMP v1, and each managed element must have oneor more Trap receivers defined for the Trap to be effective.In SNMP version 2 and higher, the concept of a Trap was extended using anotherSNMP message called Inform. Like a Trap, an Inform message is unsolicited.However, Inform enables an NMS running SNMPv2 (or higher) to send a Trap toanother NMS, and can also be used by a SNMP v2 (or higher) managed node tosend an SNMP v2 Trap. The receiving node sends a response telling the sendingNMS that the receiving NMS received the Inform message. Both messages aresent on UDP Port 161.7

White PaperSNMP: SimplifiedNetwork Management SystemManaged Network ElementUDP Port 161SNMP v1: GetRequest,GetNextRequest, SetRequestSNMP v2: GetBulkMIBOIDOIDOIDUDP Port 161SNMP v1: GetResponseUDP Port 162SNMP v1: TrapSNMP v2: InformMIBOIDOIDOIDFigure 2: SNMP CommunicationCommunity: SNMP specifies two groups, called communities, to enable accessto the OIDs on a managed element. SNMP community strings function aspasswords to secure access to an element’s OIDs. The read-community string,named public by default, allows read-only access, while the write-communitystring, named private by default, allows write access. Both community stringsmust be defined for full management access to an element, and commoncommunity strings must be defined on all elements, probes, and NMSs for fullmanagement in an SNMP domain. Note that until SNMP v3, community stringswere sent in clear text, reducing SNMP security. Version 3 specified encryptedcommunity strings and PDUs.ImplementationNow that we’ve looked at definitions, it’s easier to see how SNMP operates ina network. In its simplest form, an SNMP agent is loaded on a host with theappropriate MIB components. MIB components include the SNMP MIB, and mayinclude RMON extensions, SMON extensions, private MIB extensions, ora combination.The agent is configured to communicate with one or more NMSs using specificSNMP community strings. The NMS IP address is also configured to enable theagent to send Traps or Notifications. The agent contains the SNMP MIB andtypically, the manufacturer’s private MIB extensions. The agent may also containRMON or SMON extensions.The NMS is configured with the same community strings as the elements itmanages. The NMS is also configured with the appropriate combination of theSNMP MIB, RMON extensions, SMON extensions, and private MIB extensionsrequired to manage the agents for which it is responsible. The NMS is alsoconfigured, either manually or through automatic discovery, with the IP addressesof the agents it is to manage. Note that SNMP communication requires networkdevices to open UDP Ports 161 and 162 for polling and Traps/Notifications.8

White PaperSNMP: SimplifiedAfter initial configuration is complete, the agent collects information. The NMSperiodically polls the agent. When appropriate, the agent sends Traps to the NMS.The NMS can also be used to modify agent configuration as appropriate.In a more complicated network, probes or multiple NMSs may be used inremote sites to limit WAN-based SNMP communication. Probes typically collectSNMP, RMON, or SMON MIB and process the data as appropriate (RMONand SMON only). Remote NMSs may also relay information to one or morecentralized NMSs.The central NMS polls probes and remote NMSs for agent data, enabling localadministration (where appropriate), centralized administration for a completenetwork overview, and summarized (bulk) data transfer from remote sites toreduce WAN utilization.PerspectiveCompared to previous monitoring and management methods, SNMP reducesthe amount of overhead on the network element. Reduced processing overheadand a common platform enables growth and platform independence. Thisallows SNMP to be used on almost every IP network, often using a single,centralized NMS. While larger IP networks may require SNMP proxies tominimize WAN-based SNMP traffic, the reduction in the number of NMSscompared to previous methods enabled IT to focus on the other issues and tosimplify the management network.ConclusionThrough the use of SNMP agents, probes, and NMSs, information technologysystems-monitoring has grown dramatically and has drastically reducedthe requirement for administrators to manually monitor individual networkcomponents. The ability to have systems inform an NMS, and ultimately humans,of error conditions has led to increased uptime and availability. While not perfect,SNMP provides many of the tools necessary to collect and analyze data to enablesystem tuning for optimum performance and to identify when and where futuregrowth in the network is required.9

White PaperSNMP: SimplifiedF5 Networks, Inc.Corporate HeadquartersF5 NetworksAsia-PacificF5 Networks Ltd.Europe/Middle-East/AfricaF5 NetworksJapan K.K.401 Elliott Avenue WestSeattle, WA 98119 1-206-272-5555 Voice(888) 88BIGIP Toll-free 1-206-272-5556 [email protected] 65-6533-6103 Voice 65-6533-6106 [email protected] 44 (0) 1932 582 000 Voice 44 (0) 1932 582 001 [email protected] 81-3-5114-3200 Voice 81-3-5114-3201 [email protected] Simplified 03/08 2008 F5 Networks, Inc. All rights reserved. F5, F5 Networks, the F5 logo, BIG-IP, VIPRION, FirePass, and iControl are trademarks or registered trademarks of F5 Networks, Inc. in the U.S.and in certain other countries.10

appropriate MIB components. MIB components include the SNMP MIB, and may include RMON extensions, SMON extensions, private MIB extensions, or a combination. The agent is configured to communicate with one or more NMSs using specific SNMP community strings. The NMS IP address is also configured to enable the agent to send Traps or Notifications.