Simple Network Management Protocol
Overview and basic concepts
In typical SNMP uses, one or more administrative computers, called
managers, have the task of monitoring or managing a group of hosts or devices
on a computer network. Each managed system executes, at all times, a software
component called an agent which reports information via SNMP to the manager.
Essentially, SNMP agents expose management data on the
managed systems as variables. The protocol also permits active management tasks,
such as modifying and applying a new configuration through remote modification
of these variables. The variables accessible via SNMP are organized in
hierarchies. These hierarchies, and other metadata (such as type and
description of the variable), are described by Management Information Bases (MIBs).
An SNMP-managed network consists of three key components:
Managed device
Agent — software which runs on managed devices
Network management system (NMS) — software which runs on the
manager
A managed device is a network node that implements an SNMP
interface that allows unidirectional (read-only) or bidirectional access to
node-specific information. Managed devices exchange node-specific information
with the NMSs. Sometimes called network elements, the managed devices can be
any type of device, including, but not limited to, routers, access servers, switches,
bridges, hubs, IP telephones, IP video cameras, computer hosts, and printers.
An agent is a network-management software module that resides
on a managed device. An agent has local knowledge of management information and
translates that information to or from an SNMP specific form.
A network management system (NMS) executes applications that
monitor and control managed devices. NMSs provide the bulk of the processing
and memory resources required for network management. One or more NMSs may
exist on any managed network.
Management information base (MIB)
Main article: Management information base
SNMP itself does not define which information (which
variables) a managed system should offer. Rather, SNMP uses an extensible
design, where the available information is defined by management information
bases (MIBs). MIBs describe the structure of the management data of a device
subsystem; they use a hierarchical namespace containing object identifiers (OID).
Each OID identifies a variable that can be read or set via SNMP. MIBs use the
notation defined by ASN.1.
Protocol details
SNMP operates in the Application Layer of the Internet
Protocol Suite (Layer 7 of the OSI model). The SNMP agent receives requests on
UDP port 161. The manager may send requests from any available source port to
port 161 in the agent. The agent response will be sent back to the source port
on the manager. The manager receives notifications (Traps and InformRequests) on
port 162. The agent may generate notifications from any available port. When
used with Transport Layer Security or Datagram Transport Layer Security
requests are received on port 10161 and traps are sent to port 10162.
SNMPv1 specifies five core protocol data units (PDUs). Two
other PDUs, GetBulkRequest and InformRequest were added in SNMPv2 and carried
over to SNMPv3.
All SNMP PDUs are constructed as follows:
IP header UDP
header version community PDU-type request-id error-status error-index variable bindings
The seven SNMP protocol data units (PDUs) are as follows:
GetRequest
A manager-to-agent request to retrieve the value of a
variable or list of variables. Desired variables are specified in variable
bindings (values are not used). Retrieval of the specified variable values is
to be done as an atomic operation by the agent. A Response with current values
is returned.
SetRequest
A manager-to-agent request to change the value of a variable
or list of variables. Variable bindings are specified in the body of the
request. Changes to all specified variables are to be made as an atomic
operation by the agent. A Response with (current) new values for the variables
is returned.
GetNextRequest
A manager-to-agent request to discover available variables
and their values. Returns a Response with variable binding for the
lexicographically next variable in the MIB. The entire MIB of an agent can be
walked by iterative application of GetNextRequest starting at OID 0. Rows of a
table can be read by specifying column OIDs in the variable bindings of the
request.
GetBulkRequest
Optimized version of GetNextRequest. A manager-to-agent
request for multiple iterations of GetNextRequest. Returns a Response with
multiple variable bindings walked from the variable binding or bindings in the
request. PDU specific non-repeaters and max-repetitions fields are used to
control response behavior. GetBulkRequest was introduced in SNMPv2.
Response
Returns variable bindings and acknowledgement from agent to
manager for GetRequest, SetRequest, GetNextRequest, GetBulkRequest and
InformRequest. Error reporting is provided by error-status and error-index
fields. Although it was used as a response to both gets and sets, this PDU was
called GetResponse in SNMPv1.
Trap
Asynchronous notification from agent to manager. Includes
current sysUpTime value, an OID identifying the type of trap and optional
variable bindings. Destination addressing for traps is determined in an
application-specific manner typically through trap configuration variables in
the MIB. The format of the trap message was changed in SNMPv2 and the PDU was
renamed SNMPv2-Trap.
InformRequest
Acknowledged asynchronous notification manager to manager or
agent to manager. Manager-to-manager notifications were already possible in
SNMPv1 (using a Trap), but as SNMP commonly runs over UDP where delivery is not
assured and dropped packets are not reported, delivery of a Trap was not
guaranteed. InformRequest fixes this by sending back an acknowledgement on
receipt. Receiver replies with Response parroting all information in the
InformRequest. This PDU was introduced in SNMPv2.
Version 1
SNMP version 1 (SNMPv1) is the initial implementation of the
SNMP protocol. SNMPv1 operates over protocols such as User Datagram Protocol (UDP),
Internet Protocol (IP), OSI Connectionless Network Service (CLNS), AppleTalk
Datagram-Delivery Protocol (DDP), and Novell Internet Packet Exchange (IPX). SNMPv1
is widely used and is the de facto network-management protocol in the Internet
community.
The first RFCs for SNMP, now known as SNMPv1, 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
After a short time, RFC 1156 (MIB-1) was replaced by more
often used:
RFC 1213 — Version 2 of management information base (MIB-2) for
network management of TCP/IP-based internets
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
SNMPv2 (RFC 1441–RFC 1452), revises version 1 and includes
improvements in the areas of performance, security, confidentiality, and
manager-to-manager communications. It introduced GetBulkRequest, an alternative
to iterative GetNextRequests for retrieving large amounts of management data in
a single request. However, the new party-based security system in SNMPv2, viewed
by many as overly complex, was not widely accepted.
Community-Based Simple Network Management Protocol version 2,
or SNMPv2c, is defined in RFC 1901–RFC 1908. In its initial stages, this was
also informally known as SNMPv1.5. SNMPv2c comprises SNMPv2 without the controversial
new SNMP v2 security model, using instead the simple community-based security
scheme of SNMPv1. While officially only a "Draft Standard", this is
widely considered the de facto SNMPv2 standard.
User-Based Simple Network Management Protocol version 2, or
SNMPv2u, is defined in RFC 1909–RFC 1910. This is a compromise that attempts to
offer greater security than SNMPv1, but without incurring the high complexity
of SNMPv2. A variant of this was commercialized as SNMP v2*, and the mechanism
was eventually adopted as one of two security frameworks in SNMP v3.
SNMPv1 & SNMPv2c interoperability
As presently specified, SNMPv2 is incompatible with SNMPv1
in two key areas: message formats and protocol operations. SNMPv2c messages use
different header and protocol data unit (PDU) formats from SNMPv1 messages. SNMPv2c
also uses two protocol operations that are not specified in SNMPv1. Furthermore,
RFC 2576 defines two possible SNMPv1/v2c coexistence strategies: proxy agents
and bilingual network-management systems.
Proxy agents
A SNMPv2 agent can act as a proxy agent on behalf of SNMPv1
managed devices, as follows:
A SNMPv2 NMS issues a command intended for a SNMPv1 agent.
The NMS sends the SNMP message to the SNMPv2 proxy agent.
The proxy agent forwards Get, GetNext, and Set messages to
the SNMPv1 agent unchanged.
GetBulk messages are converted by the proxy agent to GetNext
messages and then are forwarded to the SNMPv1 agent.
The proxy agent maps SNMPv1 trap messages to SNMPv2 trap
messages and then forwards them to the NMS.
Bilingual network-management system
Bilingual SNMPv2 network-management systems support both
SNMPv1 and SNMPv2. To support this dual-management environment, a management
application in the bilingual NMS must contact an agent. The NMS then examines
information stored in a local database to determine whether the agent supports
SNMPv1 or SNMPv2. Based on the information in the database, the NMS
communicates with the agent using the appropriate version of SNMP.
Version 3
Although SNMPv3 makes no changes to the protocol aside from
the addition of cryptographic security, its developers have managed to make
things look much different by introducing new textual conventions, concepts, and
terminology.
SNMPv3 primarily added security and remote configuration
enhancements to SNMP.
Security has been the biggest weakness of SNMP since the
beginning. Authentication in SNMP Versions 1 and 2 amounts to nothing more than
a password (community string) sent in clear text between a manager and agent. Each
SNMPv3 message contains security parameters which are encoded as an octet
string. The meaning of these security parameters depends on the security model
being used.
SNMPv3 provides important security features:
Confidentiality - Encryption of packets to prevent snooping
by an unauthorized source.
Integrity - Message integrity to ensure that a packet has
not been tampered with in transit including an optional packet replay
protection mechanism.
Authentication - to verify that the message is from a valid
source.
As of 2004 the 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. The IETF has designated SNMPv3 a full
Internet standard, the highest maturity level for an RFC. It considers earlier
versions to be obsolete (designating them "Historic").
In practice, SNMP implementations often support multiple
versions: typically SNMPv1, SNMPv2c, and SNMPv3.
RMON
An RMON implementation typically operates in a client/server
model. Monitoring devices (commonly called "probes" in this context) contain
RMON software agents that collect information and analyze packets. These probes
act as servers and the Network Management applications that communicate with
them act as clients. While both agent configuration and data collection use
SNMP, RMON is designed to operate differently than other SNMP-based systems:
Probes have more responsibility for data collection and
processing, which reduces SNMP traffic and the processing load of the clients.
Information is only transmitted to the management
application when required, instead of continuous polling.
In short, RMON is designed for "flow-based" monitoring,
while SNMP is often used for "device-based" management. RMON is
similar to other flow-based monitoring technologies such as NetFlow and SFlow
because the data collected deals mainly with traffic patterns rather than the
status of individual devices. One disadvantage of this system is that remote
devices shoulder more of the management burden, and require more resources to
do so. Some devices balance this trade-off by implementing only a subset of the
RMON MIB groups (see below). A minimal RMON agent implementation could support
only statistics, history, alarm, and event.
The RMON1 MIB consists of ten groups:
- Statistics:
real-time LAN statistics e.g. utilization, collisions, CRC errors
- History:
history of selected statistics
- Alarm:
definitions for RMON SNMP traps to be sent when statistics exceed defined
thresholds
- Hosts:
host specific LAN statistics e.g. bytes sent/received, frames sent/received
- Hosts
top N: record of N most active connections over a given time period
- Matrix:
the sent-received traffic matrix between systems
- Filter:
defines packet data patterns of interest e.g. MAC address or TCP port
- Capture:
collect and forward packets matching the Filter
- Event:
send alerts (SNMP traps) for the Alarm group
The RMON2 MIB adds ten more groups:
- Protocol
Directory: list of protocols the probe can monitor
- Protocol
Distribution: traffic statistics for each protocol
- Address
Map: maps network-layer (IP) to MAC-layer addresses
- Network-Layer
Host: layer 3 traffic statistics, per each host
- Network-Layer
Matrix: layer 3 traffic statistics, per source/destination pairs of hosts
- Application-Layer
Host: traffic statistics by application protocol, per host
- Application-Layer
Matrix: traffic statistics by application protocol, per source/destination
pairs of hosts
- User
History: periodic samples of user-specified variables
- Probe
Configuration: remote configure of probes
- RMON Conformance: requirements for RMON2 MIB conformance
NetFlow
NetFlow is a network protocol developed by Cisco Systems for
collecting IP traffic information. NetFlow has become an industry standard for
traffic monitoring and is supported by platforms other than Cisco IOS and NXOS
such as Juniper routers, Enterasys Switches, vNetworking in version 5 of
vSphere, Linux, FreeBSD, NetBSD and OpenBSD.
Network Flows
Main article: Packet flow
A network flow has been defined in many ways. The
traditional Cisco definition is to use a 7-tuple key, where a flow is defined
as a unidirectional sequence of packets all sharing all of the following 7
values:
- Source
IP address
- Destination
IP address
- Source
port for UDP or TCP, 0 for other protocols
- Destination
port for UDP or TCP, type and code for ICMP, or 0 for other protocols
- IP
protocol
- Ingress
interface (SNMP ifIndex)
- IP
Type of Service
CDP
The Cisco Discovery Protocol (CDP) is a proprietary Data
Link Layer network protocol developed by Cisco Systems. It is used to share
information about other directly connected Cisco equipment, such as the
operating system version and IP address. CDP can also be used for On-Demand
Routing, which is a method of including routing information in CDP
announcements so that dynamic routing protocols do not need to be used in
simple network.
Syslog
Syslog is a standard for computer data logging. It allows
separation of the software that generates messages from the system that stores
them and the software that reports and analyzes them.
Syslog can be used for computer system management and
security auditing as well as generalized informational, analysis, and debugging
messages. It is supported by a wide variety of devices (like printers and
routers) and receivers across multiple platforms. Because of this, syslog can
be used to integrate log data from many different types of systems into a
central repository.
Messages refer to a facility (auth, authpriv, daemon, cron, ftp,
lpr, kern, mail, news, syslog, user, uucp, local0, ... , local7 ) and are
assigned a severity (Emergency, Alert, Critical, Error, Warning, Notice, Info
or Debug) by the sender of the message.
Configuration allows directing messages to various local
devices (console), files (/var/log/) or remote syslog daemons. Care must be
taken when updating the configuration as omitting or misdirecting message
facilities or severities can cause important messages to be ignored by syslog
or overlooked by the administrator.
logger is a command line utility that can send messages to
the syslog.
Some implementations permit the filtering and display of syslog
messages.
Syslog is now standardized within the Syslog working group
of the IETF.
