MACAX-Snmp

SNMP and MIB Basics

Overview of

Network Management

& the role of SNMP

Purpose and Origin

In the early 1980s computer networks began to grow and be interconnected. As the size of these networks grew, they became harder to manage and maintain, thus the need for network management was realized. One of the oldest forms of network management is the use of the remote login to monitor or configure a network device; however, today more sophisticated network management tools are available. Network management is a requirement for anyone who wants to control and monitor their networks & its devices.

Functional Areas of Network Management

Network management is the ability to control and monitor a computer network from a central location. The International Organization for Standardization (ISO) defined a conceptual model for describing the key functional areas of network management which are described below.

Note: In general, network management systems available from vendors today do not support all the key functional areas, and in a supported functional area, the coverage may be incomplete even though support is claimed.

Fault Management: Provides facilities that allow network managers to discover faults in managed devices, the network, and network operation, to determine their cause and to take remedial action. To enable this, fault management provides mechanisms to:

Report the occurrence of faults

Log reports

Perform diagnostic tests

Correct faults (possibly automatically)

Configuration Management: Monitors network configuration information so that the effects of specific hardware and software can be managed and tracked. It may provide the ability to initialize, reconfigure, operate and shut down managed devices.

Accounting: Measures network utilization of individual users or groups to:

Provide billing information

Regulate users or groups

Help keep network performance at an acceptable level

Performance Management: Measures various aspects of network performance including the gathering and analysis of statistical data about the system so that it may be maintained at an acceptable level. Performance management provides the ability to:

Obtain the utilization and error rates of network devices

Provide a consistent level of performance by ensuring that devices have a sufficient capacity.

Security Management: Controls access to network resources so that information can not be obtained without authorization by:

Limiting access to network resources

Providing notification of security breaches and attempts

Network Management Architecture : In general, network management systems have the same basic architecture, as shown in the figure below.

Figure 1.1: Typical Network Management Architecture

The architecture consists of the following elements:

Network Management Station(s): The network management station runs the network management application that gathers information about managed devices from the management agent which resides within a managed device. The network management application typically must process large amounts of data, react to events, and prepare relevant information for display. It usually has a control console with a GUI interface which allows the operator to view a graphical representation of the network, control managed devices on the network and program the network management application. Some network management applications can be programmed to react to information collected from management agents and/or set thresholds with the following actions:

Perform tests and automatic corrective actions (reconfiguration, shutdown of a managed device)

Logging network events

Present status information and alerts to operator

Managed Devices: A managed device can be any type of node residing on a network, such as a computer, printer or router. Managed devices contain a management agent.

Management agents: Provides information about the managed device to the network management application(s) and may also accept control information.

Network management protocol: Protocol used by the network management application(s) and the management agent to exchange management information.

Management Information: The information that is exchanged between the network management application(s) and the management agents that allows the monitoring and control of a managed device.

Network management software (network management applications and agents) is usually based upon a particular network management protocol and the network management capabilities provided with the software are usually based upon the functionality supported by the network management protocol. Most systems use open protocols; however, some network management software is based upon vendor specific proprietary protocols. The selection of network management software is driven by the following factors:

Network environment (scope and nature of the network)

Network management requirements

Cost

Operating systems involved

The two most common network management protocols are the

Simple Network Management Protocol

Common Management Information Protocol

SNMP is by far the most widely used network management protocol and use is widespread in LAN environments. CMIP is used extensively in telecommunication environments, where networks tend to be large and complex. MACAX 1628 uses Simple Network Management Protocol for the management of network devices such as Uninterrupted Power Supplies. Following is a detailed description of SNMP.

SNMP : Introduction

Since it was developed in 1988, the Simple Network Management Protocol has become the de facto standard for internetwork management. A key reason for its widespread acceptance, besides being the chief Internet standard for network management, is its relative simplicity. Implementing SNMP management in a networked device is far more straightforward and better than most other standard or non-standard approaches to network management. Furthermore, SNMP is extensible, allowing vendors to easily add network management functions to their existing products. SNMP also separates the management architecture from the architecture of the hardware devices, which broadens the base of multivendor support. Perhaps most important, unlike other so-called standards, SNMP is not a mere paper specification, but an implementation that is widely available today.

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 the 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 internetworking industry.

What is SNMP?

SNMP is a protocol used to communicate between the Manager and the Agent. Just think of it like a language which we speak. If two people are talking, they should have a common language, so that they understand each other. Similarly,SNMP serves as a common language for the Manager and the Agent to communicate. It is namedSimple Network Management Protocol as it is really easy to understand (One ofthe primary reasons for SNMP becoming popular). There are different versions of SNMP like SNMP V1, SNMP V2 and most recently, SNMP V3.

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 serves to provide 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.

Figure 1.2: An SNMP-Managed Network Consists of Managed Devices, Agents, and NMSs

Communication takes place via SNMP protocol data units (PDUs) that are typically encapsulated in UDP packets, and essentially four 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 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.

In order to specify to the SNMP agent which managed objects are of interest, the SNMP manager or management application, uses a well-defined naming syntax to specify the variables it is interested in. 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.

Overview of SNMP

The Simple Network Management Protocol (SNMP) was designed to be an easily implemented, basic network management tool that could be used to meet network management needs. SNMP has become the dominant standardized network management scheme in use today.

The SNMP set of standards provide 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. A manager is a software module responsible for managing part or the entire configuration on behalf of network management applications and users. An agent is a software module in a managed 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).

Figure 1.2: SNMP V2 Architecture

Agents function as collection devices that gather and send 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.

SNMP defines a client-server relationship. The network manager makes virtual connections to the SNMP agent which executes on a remote network device, and sends information to the manager regarding the device's status. In order for a manager to make requests of an agent and to interpret the responses and unsolicited traps that it receives, it uses a database which describes the information available from the agent. The database is referred to as the SNMP Management Information Base (MIB). There is a standard set of statistical and control values defined for hardware nodes on a network. These are described in a MIB which is part of the SNMP. SNMP also allows the extension of these standard values with values specific to a particular agent using private MIBs.

Directives issued to an SNMP agent consist of the identifiers of SNMP variables (referred to as MIB object identifiers or MIB variables) along with instructions either to get the value corresponding to the identifier, or set the identifier to a new value.

Through the use of private MIB variables, SNMP agents can be tailored for use in many devices. The definitions of MIB variables supported by a particular agent are incorporated in descriptor files, and made available to network management client programs so that they can become aware of MIB variables and their usage. These descriptor files are written using a subset of Abstract Syntax Notation (ASN.1) format as adopted by SNMP. When a new agent is added to extend the domain of a manager, the manager must be provided with a new MIB (ASN.1 file) that describes the features of the resources managed through that agent.

What is Agent?

Just think of insurance agents. They are the ones who help both the insurance companies and customers to get smooth access. Suppose I want to take an insurance policy, I do not need to spend anytime taking that policy. The agent will take care of it and just inform me the status. The same way Agent is a program which will communicate with the Manager on one side and with Device or Application on the other side. Agents will be part of the Device or Application so that it knows everything about the Device or Application.

A typical agent usually:

Implements full SNMP protocol.

Stores and retrieves management data as defined by the MIB.

Can asynchronously signal an event to the manager.

Can be a proxy for some non-SNMP manageable network node.

What is Manager?

Just think of it as an entity which will manage one or many agents from a remote place. For example take an office. We have offices in 4 places, 3 in one building and 1 in the other building. We have more than 20 UPS's for each building & just 3 System Administrators. To manage all the UPSs manually, the System Administrators have to roam around the office. But just imagine a situation where the System Administrators will sit before their machines with Managers installed in their machine and agents installed in all the machines in the office. They will just do queries from the Manager to Agent to know the status. Just think that the Agent will automatically inform the Manager if some problem is going to occur, then the System Administrator will do the to prevent the problem from occurring.

A typical manager usually:

Is implemented as a Network Management Station (the NMS).

Implements full SNMP Protocol.

Is able to

Query agents,

Get responses from agents,

Set variables in agents,

Acknowledge asynchronous events from agents.

The following diagram provides an overview of the Manager - Agent relationship.

How the Agent Works

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:

1. 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).

2. 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.

3. 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

4. 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.

SNMP Primitive Operations

The basic operations in SNMP are :

GET (retrieve operation)

SET (alter operation)

GETNEXT (traversal operation)

TRAP (asynchronous trap operation)

In the following pages, we will discuss the above operations in detail.

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 inputVoltage of the UPS, he will do a get with the OID of the variable inputVoltage. The agent will send a response with the value.

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 batteryCharge variable to be SET from the manager, since it is a variable maintained by the UPS 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 variablewe are interested in. Suppose if we give a GETNEXT with .1.3.6, then the agent will respond with the next immediate OID it implements.

TRAP

In addition to retrieving data from the managed resource in response to requests from a management station, agents typically also have the ability to send unsolicited messages to managers when they detect some significant event. An unsolicited message of this sort is called a trap notification.

All the above are requests sent from a manager to the agent. There is TRAP which the agent will send to the manager if it detects some errors. In our example whenever the charge of battery i.e. the batteryCharge variable is less than 100, we will send a trap, so that the manager ( System Administrator ) will know it.

The fields that comprise the SNMP trap PDU occur in the order are shown below.

PDU typeenterpriseagent addressgeneric trap typespecific trap typetime stampvariable bindingsThe fields have the following meaning:

PDU type identifies the packet as a trap notification.

enterprise is the vendor identification (OID) for the network management subsystem 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 length of time 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

SNMPv2 also defines two new protocol operations: GetBulk and Inform. The GetBulk operation is used by the NMS to efficiently retrieve large blocks of data, such as multiple rows in a table. GetBulk fills a response message with as much of the requested data as will fit. The Inform operation allows one NMS to send trap information to another NMS and to then receive a response. In SNMPv2, if the agent responding to GetBulk operations cannot provide values for all the variables in a list, it provides partial results.

What is MIB ?

MIB stands for "Management Information Base". It is nothing but 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 it 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 like what are all the variables that should be published outside ( to the Manager ) and what is the use of each variable and what each value in the variable represents and other information.

Each variable is assigned a unique identifier in SNMP that is called an object identifier (OID). Object identifier is nothing but 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 dotsin between. There are two roots for object identifiers, they are ( iso - which is .1 ) and ccit ( which starts with .0) Most object identifier starts 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 ( i.e 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 subtree is allocated to each vendor that registers for an enterprises object identifier. AdventNet 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.adventnet ). Till the enterprise number ( like 2162 ) the uniqueness is maintained by the committee, after this the uniqueness should be maintained by each enterprise.

For e.g. if we are going to manufacture a UPS, then we can think of variables like batteryCharge, inputFrequency etc. should be published, 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 example RFC1628-MIB is a standard MIB for UPSs which each operating system will implement. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing uninterruptible power supply (UPS) systems.

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 MIB's 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.

MIB Groups

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 .

SNMPV1 Data Types

Data Type NameDescriptionINTEGERUsed 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 intINTEGER (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) } GaugeIt 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. CounterUsed to specify a value which represents a count. The range is 0 to 4294967295. TimeTicksused to specify the elapsed time between two events, in units of hundredth of a second. Range is 0 to 2e32 - 1. OCTET STRINGUsed 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.

OCTET STRING (SIZE(0..255))

OCTET STRING (SIZE(4)) -- fixed length of 4 bytes.

OCTET STRING (SIZE(0 | 4 | 6)) -- varying with 0, 4, or 6 bytes OBJECT IDENTIFIERUsed to identify a type that has an assigned object identifier value IpAddressThis type is used to specify an IPv4 address as a string of 4 octets. NetworkAddressThis 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. OpaqueUsed 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

SNMPV2 Data Types

Data Type NameDescriptionInteger32Used 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) }

INTEGER { lessThan(-1), equal(0), greaterThan(1) } Unsigned 32Used 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) Gauge32It 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.Counter32Used to specify a value which represents a count. The range is 0 to 4294967295. Counter 64Similar 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 SNMPv1 it may only be used when backwards compatibility is not a requirement. TimeTicksused to specify the elapsed time between two events, in units of hundredth of a second. Range is 0 to 2e32 - 1. OCTET STRINGUsed 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.

OCTET STRING (SIZE(0..255))

OCTET STRING (SIZE(4)) -- fixed length of 4 bytes.

OCTET STRING (SIZE(0 | 4 | 6)) -- varying with 0, 4, or 6 bytes OBJECT IDENTIFIERUsed to identify a type that has an assigned object identifier value IpAddressThis type is used to specify an IPv4 address as a string of 4 octets. OpaqueUsed 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 BITSUsed to specify a collection of labelled bits. It provides a way to label individual bits in an octet (an extension of OCTET STRING type).

Examples:

BITS { 1 (TCP), 2(Netware), 3(NetBIOS)

MIB Constructs

The following tables describe the constructs supported by AgentToolkit and the mandatory elements which must be defined if the construct is created/edited.

Constructs Supported by AgentToolkit

SNMPv1 ConstructsSNMPv2 ConstructsConstructs used both in SNMPv1 and SNMPv2TRAP-TYPEMODULE-IDENTITY TEXTUAL CONVENTION OBJECT-IDENTITY OBJECT-GROUP NOTIFICATION-TYPE NOTIFICATION-GROUPOBJECT-IDENTIFIER OBJECT-TYPE (SCALAR) OBJECT-TYPE (TABLE)

Mandatory and the Optional fields for the various constructs

Construct NameMandatory FieldsOptional FieldsOBJECT-IDENTIFIER (v1 & v2 Construct)---COMMAND-TYPEOBJECT-TYPE (SCALAR) (v1 & v2 Construct)SYNTAX MAX-ACCESS STATUSDESCRIPTION REFERENCE DEFVAL COMMAND TYPEOBJECT-TYPE (TABLE) (v1 & v2 Construct)SYNTAX SEQUENCE OF MAX-ACCESS STATUSDESCRIPTION REFERENCE COMMAND TYPEMODULE-IDENTITY (v2 Construct)LAST-UPDATED ORGANIZATION CONTACT-INFO DESCRIPTIONREVISION REV-DESCRIPTIONTEXTUAL-CONVENTION (v2 Construct)STATUS DESCRIPTION SYNTAX DISPLAY-HINT REFERENCE OBJECT-IDENTITY (v2 Construct)STATUS DESCRIPTION REFERENCE OBJECT-GROUP (v2 Construct)OBJECTS STATUS DESCRIPTIONREFERENCENOTIFICATION-TYPE (v2 Construct)STATUS DESCRIPTIONOBJECTS REFERENCENOTIFICATION-GROUP (v2 Construct)NOTIFICATIONS STATUS DESCRIPTIONREFERENCETRAP-TYPE (v1 Construct)ENTERPRISEVARIABLES DESCRIPTION REFERENCE

Scalar Objects and Tabular Objects

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, "AdventNet Velechery". So in our case we can define batteryCharge or inputFrequency of the UPS 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 is itself 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 our 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. The below figure shows the table.

In this empNumber will be defined as the index column, so that it can identify the employee.

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 AdventNet 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 Indices

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 consider the employee table we saw above have the following data

empNumber ( index column )empNameempAge 1xxx252yyy303zzz28If a manager wants to do a snmpget and get the name of the 2nd employee then he 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.

Underlying communication protocols

SNMP assumes that the communication path is a connectionless communication subnetwork.In other words, no prearranged communication path is established prior to the transmission of data.As a result , SNMP makes no guarantees about the reliable delivery of the data.although in practice most messages get through , and those that don't can be retransmitted. The primary protocols that SNMP implements are the User Datagram Protocol (UDP) and the Internet Protocol (IP).SNMP also requires Data Link Layer protocols such as Ethernet or TokenRing to implement the communication channel from the managment to the managed agent.

SNMP's simplicity and connectionless communication also produce a degree of robustness. Neither the manager nor the agent relies on the other for its operation.Thus, a manager may continue to function even if a remote agent fails. When the agent resumes functioning , it can send a trap to the manager, notifying it of its change in operational status. The connectionless nature of SNMP leaves the recovery and error detection up to the NMS(Network Managment Station) and even up to the agent. However keep in mind that SNMP is actually transport independent (although original design was connectionless transport function, which corresponds to the UDP protocol) and can be implemented on other transports as well:

TCP (Connected approach)

Direct mapping onto Ethernet MAC level

Encapsulation onto X25 protocol

Encapsulation onto ATM Cell

and so on.....

The following figure describes the Transport Mechanism used in SNMP over UDP:

UDP Transport

Agent listen on UDP port 161

Responses are sent back to the originating NMS port from a dynamic port , although many agents use port 161 also for this target.

Maximum SNMP message size is limited by maximum UDP message size (i.e 65507 octets)

All SNMP implementations have to> receive packets at least 484 octets in length

Some SNMP implementation will incorrectly or not handle packets exceeding 484 octets

Asynchronous Traps are received on port 162 of the NMS

UDP more suitable than TCP when dynamic route changes occur often (e.g. when there are problems in the network)

UDP packets minimize the demands placed on the network(no resource tied up as with connection mode)

Agent and NMS are responsible for determining error recovery

The following diagrams shows the architecture of UDP transport.

SNMP Management

SNMP is a distributed-management protocol. A system can operate exclusively as either an NMS or an agent, or it can perform the functions of both. When a system operates as both an NMS and an agent, another NMS might require that the system query manage devices and provide a summary of the information learned, or that it report locally stored management information.

SNMP Security

SNMP lacks any authentication capabilities, which results in vulnerability to a variety of security threats. These include masquerading occurrences, modification of information, message sequence and timing modifications, and disclosure. Masquerading consists of an unauthorized entity attempting to perform management operations by assuming the identity of an authorized management entity. Modification of information involves an unauthorized entity attempting to alter a message generated by an authorized entity so that the message results in unauthorized accounting management or configuration management operations. Message sequence and timing modifications occur when an unauthorized entity reorders, delays, or copies and later replays a message generated by an authorized entity. Disclosure results when an unauthorized entity extracts values stored in managed objects, or learns of notifiable events by monitoring exchanges between managers and agents. Because SNMP does not implement authentication, many vendors do not implement Set operations, thereby reducing SNMP to a monitoring facility.

SNMP Interoperability

As presently specified, SNMPv2 is incompatible with SNMPv1 in two key areas: message formats and protocol operations. SNMPv2 messages use different header and protocol data unit (PDU) formats than SNMPv1 messages. SNMPv2 also uses two protocol operations that are not specified in SNMPv1. Furthermore, RFC 1908 defines two possible SNMPv1/v2 coexistence strategies: proxy agents and bilingual network-management systems.

Proxy Agents

An SNMPv2 agent can act as a proxy agent on behalf of SNMPv1 managed devices, as follows:

An SNMPv2 NMS issues a command intended for an 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.

SNMP Reference: SNMPv1 Message Formats

SNMPv1 messages contain two parts: a message header and a protocol data unit (PDU). Figure 56-4 illustrates the basic format of an SNMPv1 message.

Figure56-4: An SNVPv1 Message Consists of a Header and a PDU

SNMPv1 Message Header

SNMPv1 message headers contain two fields: Version Number and Community Name. The following descriptions summarize these fields:

Version numberSpecifies the version of SNMP used.

Community nameDefines an access environment for a group of NMSs. NMSs within the community are said to exist within the same administrative domain. Community names serve as a weak form of authentication because devices that do not know the proper community name are precluded from SNMP operations.

SNMPv1 Protocol Data Unit

SNMPv1 PDUs contain a specific command (Get, Set, and so on) and operands that indicate the object instances involved in the transaction. SNMPv1 PDU fields are variable in length, as prescribed by ASN.1. Figure 56-5 illustrates the fields of the SNMPv1 Get, GetNext, Response, and Set PDUs transactions.

Figure56-5: SNMPv1 Get, GetNext, Response, and Set PDUs Contain the Same Fields

The following descriptions summarize the fields illustrated in Figure 56-5:

PDU typeSpecifies the type of PDU transmitted.

Request IDAssociates SNMP requests with responses.

Error statusIndicates one of a number of errors and error types. Only the response operation sets this field. Other operations set this field to zero.

Error indexAssociates an error with a particular object instance. Only the response operation sets this field. Other operations set this field to zero.

Variable bindingsServes as the data field of the SNMPv1 PDU. Each variable binding associates a particular object instance with its current value (with the exception of Get and GetNext requests, for which the value is ignored).

Trap PDU Format

Figure 56-6 illustrates the fields of the SNMPv1 Trap PDU.

Figure56-6: The SNMPv1 Trap PDU Consists of Eight Fields


EnterpriseIdentifies the type of managed object generating the trap.

Agent addressProvides the address of the managed object generating the trap.

Generic trap typeIndicates one of a number of generic trap types.

Specific trap codeIndicates one of a number of specific trap codes.

Time stampProvides the amount of time that has elapsed between the last network reinitialization and generation of the trap.

Variable bindingsThe data field of the SNMPv1 Trap PDU. Each variable binding associates a particular object instance with its current value.

SNMP Reference: SNMPv2 Message Format

SNMPv2 messages consist of a header and a PDU. Figure 56-7 illustrates the basic format of an SNMPv2 message.

Figure56-7: SNMPv2 Messages Also Consist of a Header and a PDU

SNMPv2 Message Header

SNMPv2 message headers contain two fields: Version Number and Community Name. The following descriptions summarize these fields:

Version numberSpecifies the version of SNMP that is being used.

Community nameDefines an access environment for a group of NMSs. NMSs within the community are said to exist within the same administrative domain. Community names serve as a weak form of authentication because devices that do not know the proper community name are precluded from SNMP operations.

SNMPv2 Protocol Data Unit

SNMPv2 specifies two PDU formats, depending on the SNMP protocol operation. SNMPv2 PDU fields are variable in length, as prescribed by Abstract Syntax Notation One (ASN.1).

Figure 56-8 illustrates the fields of the SNMPv2 Get, GetNext, Inform, Response, Set, and Trap PDUs.


PDU typeIdentifies the type of PDU transmitted (Get, GetNext, Inform, Response, Set, or Trap).


Error statusIndicates one of a number of errors and error types. Only the response operation sets this field. Other operations set this field to zero.

Error indexAssociates an error with a particular object instance. Only the response operation sets this field. Other operations set this field to zero.


Figure56-8: SNMPv2 Get, GetNext, Inform, Response, Set, and Trap PDUs Contain the Same Fields

GetBulk PDU Format

Figure 56-9 illustrates the fields of the SNMPv2 GetBulk PDU.

Figure56-9: The SNMPv2 GetBulk PDU Consists of Seven Fields


PDU typeIdentifies the PDU as a GetBulk operation.


Non repeatersSpecifies the number of object instances in the variable bindings field that should be retrieved no more than once from the beginning of the request. This field is used when some of the instances are scalar objects with only one variable.

Max repetitionsDefines the maximum number of times that other variables beyond those specified by the Non repeaters field should be retrieved.


EMBED Microsoft Visio Drawing

- PAGE 38 -

MACAX-Snmp

Documents

Transcript of MACAX-Snmp