Theoretical Paper
- Computer Organization
- Data Structure
- Digital Electronics
- Object Oriented Programming
- Discrete Mathematics
- Graph Theory
- Operating Systems
- Software Engineering
- Computer Graphics
- Database Management System
- Operation Research
- Computer Networking
- Image Processing
- Internet Technologies
- Micro Processor
- E-Commerce & ERP
Practical Paper
Industrial Training
Simple Network Management Protocol
From Wikipedia, the free encyclopedia
Jump to: navigation, search
Layer | Protocols |
Application | DNS, TLS/SSL, TFTP, FTP, HTTP, IMAP, IRC, NNTP, POP3, SIP, SMTP, SNMP, SSH, TELNET, BitTorrent, RTP, rlogin, ENRP, … |
Transport | TCP, UDP, DCCP, SCTP, IL, RUDP, … |
Network | IP (IPv4, IPv6), ICMP, IGMP, ARP, RARP, … |
Link | Ethernet, Wi-Fi, Token ring, PPP, SLIP, FDDI, ATM, Frame Relay, SMDS, … |
The Simple Network Management Protocol (SNMP) forms part of the internet protocol suite as defined by the Internet Engineering Task Force. The protocol can support monitoring of network-attached devices for any conditions that warrant administrative attention.
MIBs
The SNMP protocol is extensible by design. This is achieved through the notion of a management information base or MIB, which specifies the management data of a specific subsystem of an SNMP-enabled device, 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
Architecturally, the SNMP framework has three fundamental components:
Master Agents
Subagents
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 specified (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
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 80's 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
snmpwalk
The output below exemplifies 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)