SNMP Overview
The Simple Network Management Protocol (SNMP) is by far the dominant protocol in network management. This Protocol (SNMP) was designed to be an easily implementable, basic network management tool that could be used to meet network management needs.
It is named Simple Network Management Protocol as it is really easy to understand. A key reason for its widespread acceptance, besides being the chief Internet standard for network management, is its relative simplicity. There are different versions of SNMP, such as SNMP V1, SNMP V2c, and SNMP V3.
Implementing SNMP management in a networked device is far more straightforward than most other standard or non-standard approaches to network management. Despite that, SNMP application development has not been as simple as one would like it to be. It has required significant effort to develop management applications to manage a variety of networked devices to be managed. This situation is now changing for the better, as more SNMP tools become available. With improved tools, SNMP is poised to deliver end-to-end management for all areas of the growing inter-networking industry.
Thus SNMP has become the dominant standardized network management scheme in use today. The SNMP set of standards provides a framework for the definition of management information along with a protocol for the exchange of that information. The SNMP model assumes the existence of Managers and Agents.
Just think of insurance agents. They are the ones who help both the insurance companies and customers to get smooth access. Suppose we want to take an insurance policy, we do not have to spend anytime in taking that policy. The agent himself, will take care of it and just inform us the status.
In the same manner, Agent is a program which communicates with the Manager on one side and with Device or Application on the other side. It forms a part of the Device or Application so that it can know everything about the Device or Application regularly.
It is a software module in the device responsible for maintaining local management information and delivering that information to a manager via SNMP. A management information exchange can be initiated by the manager (via polling) or by the agent (via a trap). Agent functions as a device that gathers and sends data about the managed resource in response to a request from a manager. UDP ports, 161 and 162, are the default ports reserved for SNMP. The agent listens for requests and replies to them over port 161 and reports asynchronous traps on port 162, unless it is instructed to use different ports. SNMP accommodates resources that do not implement the SNMP software by means of proxies. A proxy is an SNMP agent that maintains information on behalf of one or more non-SNMP devices.
Just imagine a Manager, as an entity managing one or more agents from a remote place. For example, let's take an organization which has its office premises in 4 places with more than 200 PCs, 4 to 5 printers, and just 3 System Administrators. To manage all these machines and printers, the System Administrators have to keep moving around all offices. Instead, if they have the Managers installed in their machines and agents installed in all other machines then they can easily handle all machines from their place. They just have to query the agent from the manager to know the status of the machine. If the Agent automatically informs the Manager when a problem is likely to occur (say, the number of paper is becoming less than 100 or 50 in a printer ), then the System Administrator will do the necessary changes (insert papers in the printer) to prevent the problem from occurring. If we come to know that the printer is running out of paper after giving a print, we will definitely be upset with it. Instead, if the printer itself notifies (through the agent) the person concerned (System Administrator) about its paper level or ink level then it will be very useful for the Administrator.
Manager and Agent Relationship
SNMP facilitates communication between a managed device (a device with an SNMP agent, e.g., a router) and an SNMP Manager or management application (represents a user of network management). The SNMP agent on the managed device provides access to data (managed objects) stored on the managed device. The SNMP manager or management application uses this access to monitor and control the managed device.
Communication is via SNMP Protocol Data Units (PDUs) that are typically encapsulated in UDP packets, and five kinds of operations are permitted between managers and agents (managed device).
-
The manager can perform a get (or read) to obtain information from the agent about an attribute of a managed object.
-
The manager can perform a get-next to do the same for the next object in the tree of objects on the managed device.
-
The manager can perform a get-bulk to obtain information about a group of data from the agent. This is not possible in the case of SNMP V1.
-
The manager can perform a set (or write) to set the value of an attribute of a managed object.
-
The agent can send a trap, or asynchronous notification, to the manager telling it about some event on the managed device.
To specify to the SNMP agent which managed objects are of interest, the SNMP manager or management application, uses a well-defined naming syntax. Object names in this syntax are called object identifiers (object IDs, or OIDs), and are a series of numbers that uniquely identifies an object to an SNMP agent.
What Is a MIB (Management Information Base)?
MIB is a document about the device or the application. There are a lot of syntaxes defined for defining the MIB, but the purpose of the MIB is simple. For example, if a company wants to build an application and wants the application to be remotely managed, then while building the application itself, the architects of the application or the device will write a MIB which will have information, such as what are the variables that should be published outside (to the Manager), what is the use of each variable, what each value in the variable represents, and so on.
Each variable is assigned a unique identifier in SNMP that is called an object identifier (OID). Object identifier is a unique ID (like registration numbers), but the uniqueness is maintained all over the world. Let us see how this uniqueness is maintained. The format of OID is a sequence of numbers with dots in between. There are two roots for object identifiers, they are iso (which is .1) and ccit (which starts with .0). Most object identifiers start with .1.3.6.1 (where 1 = iso, 3 = org, 6 = dod, 1 = internet). From internet, there are two branches, mgmt and private.
All standard MIBs reside under mgmt (.1.3.6.1.2) in this diagram - for example, MIB II (.1.3.6.1.2.1). The distinction between the standard and private MIBs is that of control over the object definitions (that is, defining the variables ). Standard MIBs are those that have been approved by the Internet Activities Board (IAB). MIBs defined unilaterally by equipment and software vendors are initially defined as private MIBs under private.enterprises. A branch within the private.enterprises sub-tree is allocated to each vendor that registers for an enterprises object identifier. zoho has got the enterprise OID as 2162. So all the variables we define for our device or application should fall under .1.3.6.1.4.1.2162 (.iso.org.dod.internet.private.enterprise.zoho). Till the enterprise number (like 2162), the uniqueness is maintained by the committee, after this the uniqueness should be maintained by each enterprise.
For example, if we are going to manufacture a printer, then we can think of displaying the variables, such as noOfPapers, inkLevel etc., so that at anytime the system administrators will know how many papers are there in the printer without going to the printer. They will just install the Manager in these machines and will query the printer agent and get this information. There are standard MIBs available. For exaple, RFC1213-MIB is a standard MIB for managing the system that each operating system will implement. This MIB contains information about the system, number of interfaces, and so on. There is also a standard MIB for printer. SNMP agents for different types of devices provide access to objects that are specific to the type of device. In order to enable the SNMP manager or management application to operate intelligently on the data available on the device, the manager needs to know the names and types of objects on the managed device.
This is made possible by Management Information Base (MIB) modules, which are specified in MIB files usually provided with managed devices. For example, rfc1213-MIB(also known as MIB-II) is a MIB module which is typically supported by all SNMP agents on TCP/IP enabled devices or systems. This MIB file contains a description of the object hierarchy on the managed device, as well as the name (Object ID), syntax, and access privileges for each variable in the MIB. For example, when the MIB module is loaded in a MIB browser, the label of the variable, e.g., sysDescr, can be used to identify it, since the MIB browser can use the MIB module to translate this label to an Object ID.
One key aspect of MIBs is that only the types of objects on the managed device are specified by the MIB, and not the specific objects (or instances). For example, ifInOctets in rfc1213-MIB specifies a type of object for number of input octets on an interface, but the specific objects or instances of that type are specified as ifInOctets.1, ifInOctets.2, etc., depending on the number of interfaces. When specifying an object to the SNMP agent, a proper Object ID which includes the instance needs to be used by the manager. When not properly specified, the agent responds with a "No such variable" error.
A MIB group is a collection of managed objects, and is itself represented by the name or OID of a node in the OID tree. Groups may contain other groups. For example, bea is a MIB group that is a member of the private.enterprises MIB group. The nodes in the OID tree that are not groups - the base level of the OID tree - are the "leaves" of the OID tree. For example, in the following diagram:
-
MIB group x contains a group of objects, a, b, and c.
-
MIB group y contains a group of objects, d, e, and f.
Following are the MIB data types and constructs supported by Agent Toolkit.
SNMP V1 Data Types
| Data Type Name | Description |
|---|---|
| INTEGER | Used to specify a value whose range may include both positive and negative numbers. Range = -2e31 to 2e31 - 1 (SMIv1 doesn't specify minimum or maximum values for the range). Examples: INTEGER(0..127) -- corresponds to an unsigned 8-bit int INTEGER(0..40 | 50 | 65 | 90..100) INTEGER(-2147483648..2147483647) -- corresponds to a signed 32-bit int |
| INTEGER (enumerated integer) | Used to specify a list of labeled integer values. In SMIv1, the values should be greater than 0, whereas SMIv2 allows any values in the range (-2e31 to 2e31- 1). Example: INTEGER {true(1), false(2)} |
| Gauge | It represents a non-negative integer which may increase or decrease, but which holds at the maximum or minimum value specified in the range when the actual value goes over or below the range, respectively. |
| Counter | Used to specify a value which represents a count. The range is 0 to 4294967295. |
| TimeTicks | Used to specify the elapsed time between two events, in units of hundredth of a second. Range is 0 to 2e32 - 1. |
| OCTET STRING | Used to specify octets of binary or textual information. While SMIv1 doesn't limit the number of octets, SMIv2 specifies a limit of 65535 octets. A size may be specified which can be fixed, varying, or multiple ranges. Examples: OCTET STRING -- length can vary from 0 to 65535 bytes. |
| OBJECT IDENTIFIER | Used to identify a type that has an assigned object identifier value. |
| IpAddress | This type is used to specify an IPv4 address as a string of 4 octets. |
| NetworkAddress | This type was designed to allow a network address of any type to be specified. However, it is now obsolete. A value of this type is an IPv4 address. SMIv2 supports this type via the IpAddress type. |
| Opaque | Used to specify octets of binary information. SMIv2 specifies a limit of 65535 octets while there is no limit in SMIv1. A size may be specified which can be fixed, varying, or multiple ranges. A value of this type must be an encapsulation of ASN.1 BER encoded value. Examples: Opaque -- length can vary from 0 to 65535 bytes. Opaque (SIZE(0..255)) Opaque (SIZE(4)) -- fixed length of 4 bytes. Opaque (SIZE(0 | 4 | 6)) -- varying with 0, 4, or 6 bytes. |
SNMP V2 Data Types
| Data Type Name | Description |
|---|---|
| Integer32 | Used to specify a value whose range may include both positive and negative numbers. Range = -2e31 to 2e31 - 1 (SMIv1 doesn't specify minimum or maximum values for the range). Examples: Integer32(0..127) -- corresponds to an unsigned 8-bit int Integer32 -- same as -- Integer32(-2147483648..2147483647) Integer32(0..40 | 50 | 65 | 90..100) |
| INTEGER (enumerated integer) | Used to specify a list of labeled integer values. In SMIv1, the values should be greater than 0, whereas SMIv2 allows any values in the range (-2e31 to 2e31- 1). Examples: INTEGER { true(1), false(2) } |
| Unsigned32 | Used to specify a value whose range includes only non-negative integers (0 to 2e31 - 1). Examples: Unsigned32 -- same as Unsigned32(0..4294967295) Unsigned32(0..65535) -- corresponds to an unsigned 16 bit int Unsigned32(0..10 | 50 | 65 | 90..100) |
| Gauge32 | It represents a non-negative integer which may increase or decrease, but which holds at the maximum or minimum value specified in the range when the actual value goes over or below the range, respectively. |
| Counter32 | Used to specify a value which represents a count. The |
| Counter64 | Similar to Counter32, except the range is now (0 to 2e64 -1). This type may only be used when a 32-bit counter rollover could occur in less than an hour. Otherwise, the Counter32 type must be used. Since this type is not available in SNMPv1, it may only be used when backwards compatibility is not a requirement. |
| TimeTicks | Used to specify the elapsed time between two events, in units of hundredth of a second. Range is 0 to 2e32 - 1. |
| OCTET STRING | Used to specify octets of binary or textual information. |
| OBJECT | Used to identify a type that has an assigned object identifier value |
| IpAddress | This type is used to specify an IPv4 address as a string of 4 octets. |
| Opaque | Used to specify octets of binary information. SMIv2 specifies a limit of 65535 octets while there is no limit in SMIv1. A size may be specified which can be fixed, varying, or multiple ranges. A value of this type must be an encapsulation of ASN.1 BER encoded value. Examples: Opaque -- length can vary from 0 to 65535 bytes. |
| BITS | Used to specify a collection of labeled bits. It provides a way to label individual bits in an octet (an extension of OCTET STRING type). Examples: |
The following tables describe the constructs supported by Agent Toolkit and the mandatory elements that must be defined if the construct is created/edited.
| SNMPv1 Constructs | SMPv2 Constructs | Constructs Used Both in SNMPv1 and SNMPv2 |
|---|---|---|
| TRAP-TYPE | MODULE-IDENTITY | OBJECT-IDENTIFIER |
The Mandatory and the Optional fields for the various constructs :
| Construct Name | Mandatory Fields | Optional Fields |
|---|---|---|
| OBJECT-IDENTIFIER | -- | COMMAND-TYP |
| OBJECT-TYPE (SCALAR) | SYNTAX | DESCRIPTION REFERENCE DEFVAL |
| OBJECT-TYPE (TABLE) | SYNTAX SEQUENCE OF MAX-ACCESS STATUS | DESCRIPTION |
| MODULE-IDENTITY | LAST-UPDATED ORGANIZATION | REVISION REV-DESCRIPTION |
| TEXTUAL-CONVENTION (v2 Construct) | STATUS |
DISPLAY-HINT REFERENCE |
| OBJECT-IDENTITY | STATUS | REFERENCE |
| OBJECT-GROUP | OBJECTS | REFERENCE |
| NOTIFICATION-TYPE | STATUS | OBJECTS REFERENCE |
| NOTIFICATION-GROUP |
NOTIFICATIONS | REFERENCE |
| TRAP-TYPE | ENTERPRISE | VARIABLES DESCRIPTION REFERENCE |
The set of SNMPv2 Textual Conventions supported by the Agent Compiler and embedded agent are
-
DisplayString
-
PhyAddress
-
MacAddress
-
Truth Value
-
TestAndIncr.
-
Autonomous Type
-
Variable Pointer
-
Row Pointer
-
RowStatus
-
TimeStamp *
-
TimeInterval *
-
DateAndTime
-
Storage Type
-
TDomain
-
TAddress
|
| Note: The Agent Compiler supports these textual conventions but the relevant functionalities are not handled in the SNMP API. |
Following are the nodes present in SNMPv2-SMI mib:
-
org OBJECT IDENTIFIER ::= {iso 3}
-
dod OBJECT IDENTIFIER ::= {org 6}
-
internet OBJECT IDENTIFIER ::= {dod 1}
-
directory OBJECT IDENTIFIER ::= {internet 1}
-
mgmt OBJECT IDENTIFIER ::= {internet 2}
-
mib-2 OBJECT IDENTIFIER ::= {mgmt 1}
-
transmission OBJECT IDENTIFIER ::= {mib-2 10}
-
experimental OBJECT IDENTIFIER ::= {internet 3}
-
private OBJECT IDENTIFIER ::= {internet 4}
-
enterprises OBJECT IDENTIFIER ::= {private 1}
-
security OBJECT IDENTIFIER ::= {internet 5}
-
snmpV2 OBJECT IDENTIFIER ::= {internet 6}
-
snmpDomains OBJECT IDENTIFIER ::= {snmpV2 1}
-
snmpProxys OBJECT IDENTIFIER ::= {snmpV2 2}
-
snmpModules OBJECT IDENTIFIER ::= {snmpV2 3}
Relative and Absolute Object Identifiers
The examples on object identifiers discussed so far specifies the path to the variable always from the root of the OID tree. For example, the zoho object identifier .1.3.6.1.4.1.2162 specifies the path from the root of the tree. (The root does not have a name or a number, but the initial 1 in this OID is directly below root.) These are called absolute OIDs. However, a path to the variable may be specified relative to some node in the OID tree. For example, 2.1.1.7 specifies the sysContact object in the system group, relative to the internet (.1.3.6.1) node in the OID tree. This is called a relative OID.
Specifying Object Identifiers Symbolically
Until now, we have used only a series of integers separated by dots, called "dot-dot" notation, to describe OIDs. However, an OID can also be expressed symbolically, or by a combination of both integers and textual symbols. A symbolic OID uses mnemonic keywords to specify the managed object; for example:
mgmt.mib-2.system.sysDescr
The following numeric OID uses integers to specify the same managed object:
2.1.1.1
Note that this example is a relative OID. An OID may combine both symbolic and numeric representations of individual nodes of the OID tree; for example:
mgmt.mib-2.1.sysDescr
Absolute OID names always begin with a dot and must specify every node of the OID tree from the top-most node to the specific managed object:
.iso.org.dod.internet.mgmt.mib.system.sysDescr
.1.3.6.1.2.1.1.1
.iso.3.dod.1.mgmt.mib-2.1.sysDescr
Object Identifier with Instance Indexes
To obtain values of objects from the manager, it is necessary to specify the instance of the object. The instance of an object is specified by appending an instance index to the object identifier. For example, the last 0 in:
.iso.3.dod.1.mgmt.mib.1.sysUpTime.0
is the instance index. An instance index of "0" (zero) specifies the first instance, "1" specifies the second instance, and so on. Since sysUpTime is a scalar object, it has only one instance. Therefore, an instance index of zero is always specified when retrieving the value of a scalar object. An instance index higher than 0 can only be used in the case of columnar objects ( in table ), which can have multiple instances.
Suppose the employee table we saw above has the following data:
| empNumber (index column) | empName | empAge |
|---|---|---|
| 1 | xxx | 25 |
| 2 | yyy | 30 |
| 3 | zzz | 28 |
If a manager wants to do a snmpget and get the name of the 2nd employee then the manager will send a get request with the following OID:
.1.3.6.1.4.1.2162.1.1.2.2 (where 2 is the instance). So "yyy" will be returned from the agent as response to the manager.
A managed object has both a type (defined in ASN.1) and a value. For example, the SNMP system group variable sysLocation ( this variable is defined in RFC1213-MIB ) has the type, DisplayString and may have the value, "WebNMS Velachery". So in our case, we can define noOfPapers or inkLevel of the printer as a scalar object in the MIB.
Managed objects, in SNMP, are of two types : scalar objects and tabular objects.
A managed object that always has a single instance is called a scalar object. Tabular objects, on the other hand, have multiple instances, such as the rows of a table. For example, the MIB II system group has seven "leaf" variables under it, as illustrated in Figure below. Each of these objects is a scalar object. For example, the value of sysUpTime is the duration of time since re-initialization of a system's network management software (SNMP agent), measured in hundredths of a second.
Tables in SNMP are two-dimensional objects defined as an ASN.1 type called SEQUENCE OF, which allows 0 or more members. Each element of the sequence is an entry (row) in the table, which itself is a sequence of scalar-valued objects. SNMP does not allow tables to be nested within tables.
For example, the MIB II at group contains simply one tabular object, the atTable, which contains one row for each of a system's physical interfaces. Each row in the table is an instance of the object atEntry. Each row contains instances of the scalar-valued leaf objects atIfIndex, atPhysAddress, and atNetAddress. The leaf objects are called columnar objects since the instances of each such object constitute one column in the table. Although these objects have scalar-valued instances, they are not scalar objects because they can have multiple instances.
Another example for a table is, consider an organization. Each organization will have Employees. Suppose we want to define it in a MIB, we cannot go for scalar objects. We can define it in table format only.
An agent communicates with an SNMP manager, on the one hand, and the device or application ( so called Managed resource ) on the other hand, in the following way:
The SNMP manager sends an SNMP PDU ( Protocol Data Unit ) to the agent. This PDU contains an encoded request (such as a request to GET the value, or SET the value, of a specific managed object).
When the agent receives the request, it parses the SNMP PDU (ASN.1 decoding) to determine the type of request (i.e., GET or SET) and the MIB group, and invokes the appropriate access function corresponding to the object within the MIB group.
The access function does the actual work of retrieving the object's current value (for a GET request) or modifying the object's value (for a SET request). The method used to perform the GET or SET depends on where the managed object resides (i.e., UNIX kernel, shared memory, file, or in another process) and does not involve SNMP. If the object resides in another process, you can use shared memory or a proprietary protocol, such as Sun RPC/XDR or DCE RPC.
Depending on the value received from the access function, the agent hook layer returns one of the following responses to the agent core:
-
A value from a GET function
-
An OK from a SET function
-
An ERROR, if an error occurred
The agent core receives the response from the agent hook and builds the SNMP PDU (ASN.1 encoding). It then sends the response PDU to the SNMP manager.
In addition to retrieving data from the managed resource in response to requests from a management station, agents also send unsolicited messages to managers when they detect some significant event. An unsolicited message of this sort is called a trap notification. The fields that comprise the SNMP trap PDU occur in the order shown below:
| PDU type | enterprise | agent address | generic trap type | specific trap type | time stamp | variable bindings |
The fields have the following meaning:
-
PDU type identifies the packet as a trap notification.
-
enterprise is the vendor identification (OID) for the network management sub-system that generated the trap (.1.3.6.1.4.1.2162).
-
agent address is the IP address of the node where the trap was generated.
-
generic trap type is an integer in the range of 0 to 6. These values have the meanings indicated in Table 2-1.
-
specific trap type is a number that further specifies the nature of the event that generated the trap in the case of traps of generic type 6 (enterpriseSpecific). The interpretation of this code is vendor-specific.
-
timestamp is the duration between the last re-initialization of the agent that issued the trap and the time at which the trap was issued.
-
variable bindings provide additional information pertaining to the trap. This field consists of name/value pairs. The significance of this field is vendor-specific.
The interpretation of generic trap types is described below:
| Generic Trap Number | Name of Trap Type | Interpretation |
|---|---|---|
| 0 | coldStart | The agent that sends this trap re-initializes itself due to a reboot. |
| 1 | warmStart | The agent that sends this trap re-initializes itself due to a normal restart. |
| 2 | linkDown | One of the communication links on the agent node has failed. The first element in the variable bindings contains the name and value of the ifIndex instance for the downed interface. |
| 3 | linkUp | One of the communication links on the agent node has come up. The first element in the variable bindings is the name and value of the ifIndex instance for the affected interface. |
| 4 | authenticationFailure | The agent is reporting that it has received a request with an invalid community specification or a community with insufficient permissions to complete the request. |
| 5 | egpNeighborLoss: | The agent is reporting that the peer |
| 6 | enterpriseSpecific | The sending agent has detected an enterprise-specific event. The value of the specific trap type field indicates the nature of the event. |
The basic operations in SNMP are GET ( GET is an operation where the manager will request the agent for the value of a particular OID ). In our case, if the System Administrator likes to know the variable inkLevel of the printer, he will do a get with the OID of the variable inkLevel. The agent will send a response with the value.
Specifying SNMP Variables in Get Requests
To specify an object to an SNMP agent, both the Object Name or ID (which defines the type of object) and the instance (the specific object of the given type) need to be provided. From the MIB, you get the Object ID to which an instance needs to be added. For non-tabular (or scalar) objects, this is simply an instance of 0 (e.g., sysDescr.0). For tabular objects, the instance is defined by the MIB, and is a sequence of one or more variables (e.g., ifInOctets.2 or tcpConnState.179.74.15.126.1192.225.226.126.197.80).
In order to get and set SNMP variables, you will need to completely specify the Object ID plus instance. However, you can use getnext, specify just the Object ID from the MIB (e.g., sysDescr), and get the first instance of that type from the SNMP agent. This works for all types of objects.
When using WebNMS's MIB browser, select a MIB node of interest to you, and either select getnext, or add the instance you are interested in at the end of the OID and use get. You have to set up the WebNMS Extensible Agent to make available a custom SNMP agent, providing the SNMP data for a specific MIB that you choose or write. For this, you need to get a good understanding of your MIB and the instances of MIB objects to be made available from your agent.
SET (If you specify an OID and request the agent to set the value, the agent will process and set the value, otherwise throw an error). In our case, we should not allow the noOfPaper variable to be SET from the manager, since it is a variable maintained by the printer itself. So when a SET request is made for this OID, the agent will throw an "noAccessError". We will also define this variable as a read-only variable in the MIB.
GETNEXT (Suppose we are not aware of an OID of a variable, then we will traverse the agent by giving GETNEXT till we get the value of the variable we are interested in). Suppose we give a GETNEXT with .1.3.6, then the agent will respond with the next immediate OID it implements.
TRAP : All the above are requests sent from a manager to the agent. There is something called TRAP which the agent will send to the manager if it detects some errors. In our example, whenever the paper level, that is, the noOfPaper variable is less than 100, Agent sends a trap, so that the manager (System Administrator) will know it.
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
