Simple Network Management Protocol: Difference between revisions

Content deleted Content added

Inline

Revision as of 09:25, 7 August 2006

The simple network management protocol (SNMP) forms part of the internet protocol suite as defined by the Internet Engineering Task Force. The protocol is used by network management systems for monitoring network-attached devices for conditions that warrant administrative attention.

Management Information Base (MIBs)

The SNMP's extensible design is achieved with management information bases (MIBs), which specify the management data of a device subsystem, using a hierarchical namespace containing object identifiers, implemented via ASN.1. The MIB hierarchy can be depicted as a tree with a nameless root, the levels of which are assigned by different organizations. This model permits management across all layers of the OSI reference model, extending into applications such as databases, email, and the Java EE reference model, as MIBs can be defined for all such area-specific information and operations.

Architecture

SNMP framework consists of master agents, subagents and management stations.

A master agent is a piece of software running on an SNMP-capable network component (say, a router) that responds to SNMP requests made by a management station. Thus it acts as a server in client-server architecture terminology or as a daemon in operating system terminology. A master agent relies on subagents to provide information about the management of specific functionality. Master agents can also be referred to as Managed objects.

A subagent is a piece of software running on an SNMP-capable network component that implements the information and management functionality defined by a specific MIB of a specific subsystem (e.g., the ethernet link layer). Some capabilities of the subagent are gathering information from managed objects, configuring parameters of the managed objects, responding to managers' requests, and generating alarms (or traps).

The manager or management station is the final component in the SNMP architecture. It functions as the equivalent of a client in the client-server architecture. It issues requests for management operations on behalf of an administrator or application, and receives traps from agents as well.

The SNMP protocol

The SNMP protocol operates at the application layer (layer 7) of the OSI model. It specifies (in version 1) five core protocol data units (PDUs):

GET REQUEST, used to retrieve a piece of management information.
GETNEXT REQUEST, used iteratively to retrieve sequences of management information.
GET RESPONSE
SET, used to make a change to a managed subsystem.
TRAP, used to report an alert or other asynchronous event about a managed subsystem. In SNMPv1, asynchronous event reports are called traps while they are called notifications in later versions of SNMP. In SMIv1 MIB modules, traps are defined using the TRAP-TYPE macro; in SMIv2 MIB modules, traps are defined using the NOTIFICATION-TYPE macro.

Other PDUs were added in later versions, including:

GETBULK REQUEST, a faster iterator used to retrieve sequences of management information.
INFORM, an acknowledged trap.

Typically, SNMP uses UDP ports 161 for the agent and 162 for the manager. The Manager may send Requests from any available port (source port) to port 161 in the agent (destination port). The agent response will be given back to the source port. And the Manager will receive traps on port 162. The agent may generate trap from any available port.

Development and Usage

Version 1

The first RFCs for SNMP, now known as Simple Network Management Protocol version 1, appeared in 1988:

RFC 1065 — Structure and identification of management information for TCP/IP-based internets
RFC 1066 — Management information base for network management of TCP/IP-based internets
RFC 1067 — A simple network management protocol

These protocols were obsoleted by:

RFC 1155 — Structure and identification of management information for TCP/IP-based internets
RFC 1156 — Management information base for network management of TCP/IP-based internets
RFC 1157 — A simple network management protocol

Version 1 has been criticized for its poor security. Authentication of clients is performed only by a "community string", in effect a type of password, which is transmitted in cleartext. The '80s design of SNMP V1 was done by a group of collaborators who viewed the officially sponsored OSI/IETF/NSF (National Science Foundation) effort (HEMS/CMIS/CMIP) as both unimplementable in the computing platforms of the time as well as potentially unworkable. SNMP was approved based on a belief that it was an interim protocol needed for taking steps towards large scale deployment of the Internet and its commercialization. In that time period Internet standard authentication/security was both a dream and discouraged by focused protocol design groups.

Version 2

Version 2 was not widely adopted due to serious disagreements over the security framework in the standard.

Simple Network Management Protocol version 2 (RFC 1441–RFC 1452), also known as SNMP v2 or SNMP v2p, revises version 1 and includes improvements in the areas of performance, security, confidentiality, and manager-to-manager communications. It introduced GETBULK, an alternative to iterative GETNEXTs for retrieving large amounts of management data in a single request. However, the new party-based security system in SNMP v2, viewed by many as overly complex, was not widely accepted. Community-Based Simple Network Management Protocol version 2, or SNMP v2c, is defined in RFC 1901–RFC 1908. In its initial stages, this was also informally known as SNMP v1.5. SNMP v2c comprises SNMP v2 without the controversial new SNMP v2 security model, using instead the simple community-based security scheme of SNMP v1. While officially only a "Draft Standard", this is widely considered the de facto SNMP v2 standard.

User-Based Simple Network Management Protocol version 2, or SNMP v2u, is defined in RFC 1909–RFC 1910. This is a compromise that attempts to offer greater security than SNMP v1, but without incurring the high complexity of SNMP v2. A variant of this was commercialized as SNMP v2*, and the mechanism was eventually adopted as one of two security frameworks in SNMP v3.

Version 3

The Internet Engineering Task Force (IETF) recognizes Simple Network Management Protocol version 3 as defined by RFC 3411–RFC 3418 (also known as STD0062) as the current standard version of SNMP as of 2004. The IETF considers earlier versions as "Obsolete" or "Historical".

In practice, SNMP implementations often support multiple versions: typically SNMPv1, SNMPv2c, and SNMPv3. See RFC 3584 "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework".

Usage Examples

Monitoring device uptimes (sysUpTimeInstance)
Inventory of OS versions (sysDescr)
Collect interface information (ifName, ifDescr, ifSpeed, ifType, ifPhysAddr)
Measuring network interface throughput (ifInOctets, ifOutOctets)
Querying a remote ARP cache (ipNetToMedia)

Applying SNMP

snmpwalk

The output below show an example of an snmpwalk (snmpwalk is a Net-SNMP application) performed on a router, and shows general information about the device.

snmpwalk -c public punch system
SNMPv2-MIB::sysDescr.0 = STRING: Cisco Internetwork Operating System Software
IOS (tm) C2600 Software (C2600-IO3-M), Version 12.2(15)T5,  RELEASE SOFTWARE (fc1)
TAC Support: http://www.cisco.com/tac
Copyright (c) 1986-2003 by cisco Systems, Inc.
Compiled Thu 12-Jun-03 15:49 by eaarm
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.9.1.187
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (835747999) 96 days, 17:31:19.99
SNMPv2-MIB::sysContact.0 = STRING: wikiuser
SNMPv2-MIB::sysName.0 = STRING: punch
SNMPv2-MIB::sysLocation.0 = STRING: test
SNMPv2-MIB::sysServices.0 = INTEGER: 78
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (0) 0:00:00.00

Router graphing software

A lot of data about the performance, load and error rates of network elements like routers and switches can be gathered through SNMP. There are a number of tools which gather this data on a regular basis and which can produce various kinds of graphs from it. Such graphs can be interpreted by network adminstrators to evaluate a network's performance, identify (potential) bottlenecks and help in (re)designing a network.

Example tools of this type are Multi Router Traffic Grapher and Cacti.

Caveats of SNMP

Autodiscovery

SNMP by itself is simply a protocol for collecting and organizing information. Most toolsets implementing SNMP offer some form of discovery mechanism, a standardized collection of data common to most platforms and devices, to get a new user or implementor started. One of these features is often a form of automatic discovery, where new devices discovered in the network are polled automatically. For SNMPv1 and SNMPv2c, this presents a security risk, in that your SNMP read communities will be broadcast in cleartext to the target device. While security requirements and risk profiles vary from organization to organization, care should be taken when using a feature like this, with special regard to common environments such as mixed tenant datacenters, server hosting and colocation facilities, and similar environments.

Negative Impact

SNMP implementations vary across platform vendors. In some cases, SNMP is often a feature add, and not an element of the core design. SNMP's tree structure and linear indexing may not always mate well with the internal data structures that are elements of a platform's basic design. Using SNMP to query certain data sets may result in high CPU utilization that has negative effects on operation. One example of this would be large routing tables, such as BGP or IGP.

Index Shifting

Modular devices may renumber their indexes whenever slotted hardware is added or removed. Index values are typically assigned at boot time and remain fixed until the next reboot. Hardware added while the device is 'live' may have their indexes assigned at the end of the existing range, only to be reassigned at the next reboot, causing a massive shift for all hardware objects that are polled *after* the new addition. Network inventory and monitoring tools may then experience corruption and mismatch polled data, if unable to account for this behaviour.

Proxy Agent

Normally, a network management system is able to manage device with SNMP agent installed. However in the absence of the SNMP agent, it can be managed with the help of a proxy agent.

The SNMP agent associated with the proxy policy is called a proxy agent, or commercially a proxy server. The proxy agent monitor non-SNMP Community with non-SNMP agents and then converts the objects and data to SNMP compatible objects and data to be fed to an SNMP manager.

External links

Implementations

Cisco

RFCs

RFC 1155 — Structure and Identification of Management Information for TCP/IP-based Internets
RFC 1156 — Management Information Base for Network Management of TCP/IP-based internets
RFC 1157 — A Simple Network Management Protocol (SNMP)
RFC 1441 — Introduction to version 2 of the Internet-standard Network Management Framework
RFC 1213 — Management Information Base for Network Management of TCP/IP-based internets: MIB-II
RFC 3410 (Informational) — Introduction and Applicability Statements for Internet Standard Management Framework
RFC 3411 (Standard 62) — An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks
RFC 3412 (Standard 62) — Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
RFC 3413 (Standard 62) — Simple Network Management Protocol (SNMP) Application
RFC 3414 (Standard 62) — User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
RFC 3415 (Standard 62) — View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)
RFC 3416 (Standard 62) — Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)
RFC 3417 (Standard 62) — Transport Mappings for the Simple Network Management Protocol (SNMP)
- RFC 3418 (Standard 62) — Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)
RFC 3512 (Informational) — Configuring Networks and Devices with Simple Network Management Protocol (SNMP)
RFC 3584 (Best Current Practice) — Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework

@@ Line 116: / Line 116: @@
 * [[AgentX]]
 * [[SMUX]]
+* [[Net-SNMP]] formally UCD-SNMP
 ==External links==