| Simple Network Management Protocol |
Article Index for Simple |
Shopping Protocol |
Website Links For Simple |
Information AboutSimple Network Management Protocol |
| CATEGORIES ABOUT SIMPLE NETWORK MANAGEMENT PROTOCOL | |
| internet protocols | |
| internet standards | |
| network management | |
| system administration | |
| application layer protocols | |
| multi-agent systems | |
|
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 Identifier s, 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 Layer s of the OSI Reference Model , extending into Applications such as Database s, 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 Component s: # 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 Trap s 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 Unit s (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 RFC s for SNMP, now known as Simple Network Management Protocol version 1, appeared in 1988:
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.
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 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 MRTG and Cacti . 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. SEE ALSO EXTERNAL LINKS
|
|
|