Network management and monitoring
In the late 1970's, computer networks had grown from a simple layout of small, separate networks that were not interconnected to larger networks that were interconnected. These larger networks were called internets and their size grew at an exponential rate. Larger the networks became the more difficult it became to manage (monitor and maintain), and it soon became evident that network management was required.
Network Management issues
The International Organization for Standards has defined five key areas of network management. These are
1.
fault management
2.
configuration management
3.
security management
4.
performance management
5.
accounting management.
Performance Management
The goal of performance management is to measure and make available various aspects of network performance so that internetwork performance can be maintained at an acceptable level. Examples of performance variables that might be provided include network throughput, user response times, and line utilization.
Management entities continually monitor performance variables. When a performance threshold is exceeded, an alert is generated and sent to the network management system. This is a reactive system. When performance becomes unacceptable by virtue of an exceeded user-defined threshold, the system reacts by sending a message. Performance management also permits proactive methods. For example, network simulation can be used to project how network growth will affect performance metrics. Such simulation can effectively alert administrators to impending problems, so that counteractive measures can be taken.
Configuration Management
The goal of configuration management is to monitor network and system configuration information so that the effects on network operation of various versions of hardware and software elements can be tracked and managed. Because all hardware and software elements have operational quirks, flaws, or both that might affect network operation, such information is important to maintaining a smooth-running network.
Accounting Management
The goal of accounting management is to measure network utilization parameters so that individual or group uses of the network can be regulated appropriately. Such regulation minimizes network problems (because network resources can be apportioned out based on resource capacities) and maximizes the fairness of network access across all users.
As with performance management, the first step toward appropriate accounting management is to measure utilization of all important network resources. Analysis of the results provides insight into current usage patterns. Usage quotas can be set at this point. Some correction will be required to reach optimal access practices. From that point on, ongoing measurement of resource use can yield billing information as well as information used to assess continued fair and optimal resource utilization.
Fault Management
The goal of fault management is to detect, log, notify users of, and (to the extent possible) automatically fix network problems in order to keep the network running effectively. Because faults can cause down time or unacceptable network degradation, fault management is perhaps the most widely implemented of the ISO network management elements.
Security Management
The goal of security management is to control access to network resources according to local guidelines so that the network cannot be sabotaged (intentionally or unintentionally) and sensitive information cannot be accessed by those without appropriate authorization. For example, a security management subsystem can monitor users logging on to a network resource, refusing access to those who enter inappropriate access codes.
Security management subsystems work by partitioning network resources into authorized and unauthorized areas. For some users, access to any network resources is inappropriate. Such users are usually company outsiders. For other (internal) network users, access to information originating from a particular department is inappropriate. For example, access to human resource files is inappropriate for most users outside the human resource department.
Implementing Network Management
Network management may be defined as "the process of controlling a complex data network so as to maximize its efficiency and productivity".
The best way in which a network can be managed is to attain each of the five above areas of network management the most efficiently. To aid in this task, network management protocols are used so that the process of network management is automated (run by computers) as much as possible. Network management is used for functions such as to
monitor printer queues
set up addresses for devices
assign priorities for communication
install software on the network
manage databases
manage power on the network
There are many network management protocols available. The two mainstream protocols however are
SNMP ( Simple Network Management Protocol )
CMIP ( Common Management Information Protocol).
SNMPv1 was the first protocol used. SNMPv2 was designed in 1980's and incorporated many of the features of the original SNMP (which is still in wide use today) as well as a few added features that addressed the original protocol's shortcomings. CMIP also designed in 1980's is better organized and contains many more features than either SNMP v1 or v2. CMIP works under the OSI (Open Systems Interconnection) communication stack. Both protocols have some advantages and disadvantages.
The information the SNMP and CMIP can attain from a network is defined as a MIB (Management Information Base). The MIB is structured like a tree. At the top of the tree is the most general information available about a network. Each branch of the tree then gets more detailed into a specific network area, with the leaves of the tree as specific as the MIB can get. For instance, devices may be a parent in the tree, its children being serial devices and parallel devices. The value of these may be 6 , 2, 4 accordingly; with the numbers corresponding to the number of devices attached ( 2 serial + 4 parallel = 6 total devices). Each node in the MIB tree is referred to as a variable (hence in the above example, devices, serial devices, and parallel devices are all variables, their values being 6, 2, 4 accordingly). The top of a LAN MIB tree is usually referred to as "internet". There is only one MIB tree defined by ISO. However, part of this tree has sections for vendor-specific extensions. Usually each vendor-specific network has its own MIB that contains its own variable names (for instance, IBM has its own MIB, as does Sun, HP, etc..). Although the variable names may be different, the information contained in each vendor-specific MIB tree is generally the same.
SNMP - Simple Network Management Protocol
Introduction
Since it was developed in 1988, the Simple Network Management Protocol has become the de facto standard for internetwork management. Because it is a simple solution, requiring little code to implement, vendors can easily build SNMP agents to their products. 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 multi-vendor support. Perhaps most important, unlike other so-called standards, SNMP is not a mere paper specification, but an implementation that is widely available today.
Network Management Architectures
Network management system contains two primary elements: a manager and agents. The Manager is the console through which the network administrator performs network management functions. Agents are the entities that interface to the actual device being managed. Bridges, Hubs, Routers or network servers are examples of managed devices that contain managed objects. These managed objects might be hardware, configuration parameters, performance statistics, and so on, that directly relate to the current operation of the device in question. These objects are arranged in what is known as a virtual information database ,called a management information base, also called MIB. SNMP allows managers and agents to communicate for the purpose of accessing these objects.
Structure of Management Information
In the Manager/Agent paradigm for network management, managed network objects must be logically accessible. Logical accessibility means that management information must be stored somewhere, and therefore, that the information must be retrievable and modifiable. SNMP actually performs the retrieval and modification. The Structure of Management Information (SMI) which is given in RFC 1155, is based on the OSI SMI given in Draft proposal 2684.
The SMI organizes, names, and describes information so that logical access can occur. The SMI states that each managed object must have a name, a syntax and an encoding. The name, an object identifier(OID), uniquely identifies the object. The syntax defines the data type,such as an integer or a string of octets. The encoding describes how the information associated with the managed objects is serialized for transmission between machines.
Each managed object is given a globally unique name called an object identifier (OID). The object identifier is part of a hierarchical name space that is managed by the ISO. The hierarchical structure is used to guarantee that each name is globally unique. In an object identifier, each level of the hierarchy is identified by a number. All SNMP managed objects start with the number 1.3.6.1.
The syntax used for SNMP is the Abstract Syntax Notation One, ASN.1. The encoding used for SNMP is the Basic Encoding Rules, BER. The names used are object identifiers.
SNMP Protocol
SNMP is based on the manager/agent model. SNMP is referred to as "simple" because the agent requires minimal software. Most of the processing power and the data storage resides on the management system, while a complementary subset of those functions resides in the managed system.
To achieve its goal of being simple, SNMP includes a limited set of management commands and responses. The management system issues Get, GetNext and Set messages to retrieve single or multiple object variables or to establish the value of a single variable. The managed agent sends a Response message to complete the Get, GetNext or Set. The managed agent sends an event notification, called a trap to the management system to identify the occurrence of conditions such as threshold that exceeds a predetermined value. In short there are only five primitive operations:
get (retrieve operation)
get next (traversal operation)
get response (indicative operation)
set (alter operation)
trap (asynchronous trap operation)
The NMS periodically requests the status of each device (GetRequest) and each agent responds with the status of its device (GetResponse). Making periodic requests is called polling. Polling reduces the burden on the agent because the NMS decides when polls are needed, and the agent simply responds. Polling also reduces the burden on the network because the polls originate from a single system are at a predictable rate. The shortcoming of polling is that it does not allow for real-time updates. If a problem occurs on a managed device, the manager does not find out until the agent polled. To handle this, SNMP uses a modified polling system called trap-directed polling.
A trap is an interrupt signalled by a predefined event. When a trap event occurs, the SNMP agent does not wait for the manager to poll, instead it immediately sends information to the manager. Traps allow the agent to inform the manager of unusual events while allowing the manager to maintain control of polling. SNMP traps are sent on UDP port 162. The manager sends polls on port 161 and listens for traps on port 162.
Outline of the SNMP protocol
Each SNMP managed object belongs to a community. A community is defined by a community name which is an OctetString with 0 to 255 octets in length. Each SNMP message consists of three components
version number
community name
data - a sequence of PDUs associated with the request
Security levels with basic SNMP
Authentication:
trivial authentication based on plain text community name exchanged in SNMP messages authentication is based on the assumption that the message is not tampered with or interrogated
Authorization:
Once community name is validated then agent or manager checks to see if sending address is permitted or has the rights for the requested operation "View" or "Cut" of the objects together with permitted access rights is then derived for that pair (community name, sending address)
What does SNMP access
SNMP access particular instances of an object. All instances of an object in the MIB reside at the leaf nodes of the MIB tree. SNMP Protocol accesses objects by forming an Object identifier of form x.y where x is the "true" OID for the object in the MIB, and y is a suffix specified by the protocol that uniquely identifies a particular instance (e.g.. when accessing a table). For primitive single instance leaf objects use y=0 for example: sysDescr (OID: 1.3.6.1.2.1.1.1) would be referenced in the SNMP protocol by 1.3.6.1.2.1.1.1.0 (i.e sysDescr.0). For single instance of columnar leaf objects (i.e one instance from a table type of object) use y=I1.I2.I3.... (Ii are table indexes) for example.
Table 8.1: A portion of the MIB tree
Value
iso
1
org
3
dod
6
internet
1
directory
1
mgmt
2
mib-II
1
system
1
sysDescr
1
sysUpTime
3
interfaces
2
ifTable
2
ifEntry
1
ifInOctets
10
ip
4
An example of some of the nodes in the MIB tree is shown in Table 8.1. The abstract syntax notation, ASN.1 is illustrated below:
ObjectDescriptor OBJECT-TYPE
SYNTAX ObjectSyntax
ACCESS AccessMode
STATUS StatusType
DESCRIPTION Description ::= {ObjectGroup Entry}
The following definitions describe the pieces of the macro:
ObjectDescriptor: Indicates the textual name assigned to the MIB variable being defined.
ObjectSyntax: Indicates the abstract syntax for the object type. It must be one of:
INTEGER
OCTET
STRING or DisplayString
OBJECT IDENTIFIER
NULL
Network Address
Counter
Gauge
Time Ticks
Opaque
See RFC 1155 for definitions of each ObjectSyntax variable.
AccessMode: Specifies the permissions of the object, which can be either:
read-only
read-write
write-only
not-accessible
StatusType: Specifies the status of the object, which can be either:
mandatory
optional
deprecated
obsolete
Description: Specifies a textual description of the purpose of the MIB variable being defined.
ObjectGroup: Defines the object group for this MIB variable. The ObjectGroup variable identifies the subtree for the MIB variable.
Entry: Defines the unique location of the MIB variable in the ObjectGroup variable.
An example of the ASN.1 for the MIB entry for sysDescr is shown below:
sysDescr OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-only
STATUS mandatory
DESCRIPTION A textual description of the entity.
This value should include the full name and
version identification of system's hardware
type,software operating-system, and networking
software. It is mandatory that this only contain
printable ASCII characters.
::= { system 1 }
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 management 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 Management 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.
The details of the SNMP protocol
This description of SNMP is from Request for Comments: 1157: A Simple Network Management Protocol (SNMP). It defines a simple protocol by which management information for a network element may be inspected or altered by logically remote users.
The Internet Activities Board recommends that all IP and TCP implementations be network manageable. This implies implementation of the Internet MIB (RFC-1156) and at least one of the two recommended management protocols SNMP (RFC-1157) or CMOT (RFC-1095).
The SNMP Architecture
Implicit in the SNMP architectural model is a collection of network management stations and network elements. Network management stations execute management applications which monitor and control network elements. Network elements are devices such as hosts, gateways, terminal servers, and the like, which have management agents responsible for performing the network management functions requested by the network management stations. The Simple Network Management Protocol (SNMP) is used to communicate management information between the network management stations and the agents in the network elements.
Goals of the Architecture
The SNMP explicitly minimizes the number and complexity of management functions realized by the management agent itself. This goal is attractive in at least four respects:
1.
The development cost for management agent software necessary to support the protocol is accordingly reduced.
2.
The degree of management function that is remotely supported is accordingly increased, thereby admitting fullest use of internet resources in the management task.
3.
The degree of management function that is remotely supported is accordingly increased, thereby imposing the fewest possible restrictions on the form and sophistication of management tools.
4.
Simplified sets of management functions are easily understood and used by developers of network management tools.
A second goal of the protocol is that the functional paradigm for monitoring and control be sufficiently extensible to accommodate additional, possibly unanticipated aspects of network operation and management. A third goal is that the architecture be, as much as possible, independent of the architecture and mechanisms of particular hosts or particular gateways.
Representation
Management information communicated by operation of the SNMP is represented according to the subset of the ASN.1 language that is specified for the definition of non-aggregate types. The SNMP continues and extends this tradition by utilizing a moderately more complex subset of ASN.1 for describing managed objects and for describing the protocol data units used for managing those objects. In addition, the desire to ease eventual transition to OSI-based network management protocols led to the definition in the ASN.1 language of an Internet-standard Structure of Management Information (SMI) and Management Information Base (MIB). The use of the ASN.1 language, was, in part, encouraged by the successful use of ASN.1 in earlier efforts, in particular, the SGMP.
Also for the sake of simplicity, the SNMP uses only a subset of the basic encoding rules of ASN.1. Namely, all encodings use the definite-length form. Further, whenever permissible, non-constructor encodings are used rather than constructor encodings. This restriction applies to all aspects of ASN.1 encoding, both for the top-level protocol data units and the data objects they contain.
Operations
The SNMP models all management agent functions as alterations or inspections of variables. Thus, a protocol entity on a logically remote host (possibly the network element itself) interacts with the management agent resident on the network element in order to retrieve (get) or alter (set) variables. This strategy has at least two positive consequences:
1.
It has the effect of limiting the number of essential management functions realized by the management agent to two: one operation to assign a value to a specified configuration or other parameter and another to retrieve such a value.
2.
A second effect of this decision is to avoid introducing into the protocol definition support for imperative management commands: the number of such commands is in practice ever-increasing, and the semantics of such commands are in general arbitrarily complex.
The strategy implicit in the SNMP is that the monitoring of network state at any significant level of detail is accomplished primarily by polling for appropriate information on the part of the monitoring center(s). A limited number of unsolicited messages (traps) guide the timing and focus of the polling. Limiting the number of unsolicited messages is consistent with the goal of simplicity and minimizing the amount of traffic generated by the network management function. The exclusion of imperative commands from the set of explicitly supported management functions is unlikely to preclude any desirable management agent operation.
Currently, most commands are requests either to set the value of some parameter or to retrieve such a value, and the function of the few imperative commands currently supported is easily accommodated in an asynchronous mode by this management model. In this scheme, an imperative command might be realized as the setting of a parameter value that subsequently triggers the desired action. For example, rather than implementing a "reboot command," this action might be invoked by simply setting a parameter indicating the number of seconds until system reboot.
Transport
The communication of management information among management entities is realized in the SNMP through the exchange of protocol messages. Consistent with the goal of minimizing complexity of the management agent, the exchange of SNMP messages requires only an unreliable datagram service, and every message is entirely and independently represented by a single transport datagram. While this document specifies the exchange of messages via the UDP protocol, the mechanisms of the SNMP are generally suitable for use with a wide variety of transport services.
Administrative Relationships
The SNMP architecture admits a variety of administrative relationships among entities that participate in the protocol. The entities residing at management stations and network elements which communicate with one another using the SNMP are termed SNMP application entities. The peer processes which implement the SNMP, and thus support the SNMP application entities, are termed protocol entities.
A pairing of an SNMP agent with some arbitrary set of SNMP application entities is called an SNMP community. Each SNMP community is named by a string of octets, that is called the community name for said community.
An SNMP message originated by an SNMP application entity that in fact belongs to the SNMP community named by the community component of said message is called an authentic SNMP message. The set of rules by which an SNMP message is identified as an authentic SNMP message for a particular SNMP community is called an authentication scheme. An implementation of a function that identifies authentic SNMP messages according to one or more authentication schemes is called an authentication service.
Clearly, effective management of administrative relationships among SNMP application entities requires authentication services that (by the use of encryption or other techniques) are able to identify authentic SNMP messages with a high degree of certainty. Some SNMP implementations may wish to support only a trivial authentication service that identifies all SNMP messages as authentic SNMP messages. For any network element, a subset of objects in the MIB that pertain to that element is called a SNMP MIB view.
An element of the set { READ-ONLY, READ-WRITE } is called an SNMP access mode. A pairing of a SNMP access mode with a SNMP MIB view is called an SNMP community profile. A SNMP community profile represents specified access privileges to variables in a specified MIB view. For every variable in the MIB view in a given SNMP community profile, access to that variable is represented by the profile according to the following conventions:
1.
if said variable is defined in the MIB with "Access:" of "none," it is unavailable as an operand for any operator;
2.
if said variable is defined in the MIB with "Access:" of "read-write" or "write-only" and the access mode of the given profile is READ-WRITE, that variable is available as an operand for the get, set, and trap operations;
3.
otherwise, the variable is available as an operand for the get and trap operations.
4.
In those cases where a "write-only" variable is an operand used for the get or trap operations, the value given for the variable is implementation-specific.
A pairing of a SNMP community with a SNMP community profile is called a SNMP access policy. An access policy represents a specified community profile afforded by the SNMP agent of a specified SNMP community to other members of that community. All administrative relationships among SNMP application entities are architecturally defined in terms of SNMP access policies. For every SNMP access policy, if the network element on which the SNMP agent for the specified SNMP community resides is not that to which the MIB view for the specified profile pertains, then that policy is called a SNMP proxy access policy. The SNMP agent associated with a proxy access policy is called a SNMP proxy agent.
While careless definition of proxy access policies can result in management loops, prudent definition of proxy policies is useful in at least two ways:
1.
It permits the monitoring and control of network elements which are otherwise not addressable using the management protocol and the transport protocol. That is, a proxy agent may provide a protocol conversion function allowing a management station to apply a consistent management framework to all network elements, including devices such as modems, multiplexors, and other devices which support different management frameworks.
2.
It potentially shields network elements from elaborate access control policies. For example, a proxy agent may implement sophisticated access control whereby diverse subsets of variables within the MIB are made accessible to different management stations without increasing the complexity of the network element.
Naming
The names for all object types in the MIB are defined explicitly in the Internet-standard MIB or in other documents. Each instance of any object type defined in the MIB is identified in SNMP operations by a unique name called its "variable name." In general, the name of an SNMP variable is an OBJECT IDENTIFIER of the form x.y, where x is the name of a non-aggregate object type defined in the MIB and y is an OBJECT IDENTIFIER fragment that identifies the desired instance.
This naming strategy admits the fullest exploitation of the semantics of the GetNextRequest-PDU because it assigns names for related variables so as to be contiguous in the lexicographical ordering of all variable names known in the MIB.
The type-specific naming of object instances is defined below for a number of classes of object types. Instances of an object type to which none of the following naming conventions are applicable are named by OBJECT IDENTIFIERs of the form x.0, where x is the name of said object type in the MIB definition.
For example, suppose one wanted to identify an instance of the variable sysDescr. The object class for sysDescr is:
iso org dod internet mgmt mib system sysDescr 1 3 6 1 2 1 1 1
Hence, the object type, x, would be 1.3.6.1.2.1.1.1 to which is appended an instance sub-identifier of 0. That is, 1.3.6.1.2.1.1.1.0 identifies the one and only instance of sysDescr.
Protocol Specification
The network management protocol is an application protocol by which the variables of an agent's MIB may be inspected or altered. Communication among protocol entities is accomplished by the exchange of messages, each of which is entirely and independently represented within a single UDP datagram using the basic encoding rules of ASN.1.
A message consists of a version identifier, an SNMP community name, and a protocol data unit (PDU). A protocol entity receives messages at UDP port 161 on the host with which it is associated for all messages except for those which report traps (i.e., all messages except those which contain the Trap-PDU). Messages which report traps should be received on UDP port 162 for further processing.
An implementation of this protocol need not accept messages whose length exceeds 484 octets. However, it is recommended that implementations support larger datagrams whenever feasible.
It is mandatory that all implementations of the SNMP support the five PDUs:
GetRequest-PDU,
GetNextRequest-PDU,
GetResponse-PDU,
SetRequest-PDU,
Trap-PDU.
In the case of the UDP, a transport address consists of an IP address along with a UDP port. Other transport services may be used to support the SNMP. In these cases, the definition of a transport address should be made accordingly.
The top-level actions of a protocol entity which generates a message are as follows:
1.
It first constructs the appropriate PDU, e.g., the GetRequest-PDU, as an ASN.1 object.
2.
It then passes this ASN.1 object along with a community name its source transport address and the destination transport address, to the service which implements the desired authentication scheme. This authentication service returns another ASN.1 object.
3.
The protocol entity then constructs an ASN.1 Message object, using the community name and the resulting ASN.1 object.
4.
This new ASN.1 object is then serialized, using the basic encoding rules of ASN.1, and then sent using a transport service to the peer protocol entity.
Similarly, the top-level actions of a protocol entity which receives a message are as follows:
1.
It performs a rudimentary parse of the incoming datagram to build an ASN.1 object corresponding to an ASN.1 Message object. If the parse fails, it discards the datagram and performs no further actions.
2.
It then verifies the version number of the SNMP message. If there is a mismatch, it discards the datagram and performs no further actions.
3.
The protocol entity then passes the community name and user data found in the ASN.1 Message object, along with the datagram's source and destination transport addresses to the service which implements the desired authentication scheme. This entity returns another ASN.1 object, or signals an authentication failure. In the latter case, the protocol entity notes this failure, (possibly) generates a trap, and discards the datagram and performs no further actions.
4.
The protocol entity then performs a rudimentary parse on the ASN.1 object returned from the authentication service to build an ASN.1 object corresponding to an ASN.1 PDUs object. If the parse fails, it discards the datagram and performs no further actions. Otherwise, using the named SNMP community, the appropriate profile is selected, and the PDU is processed accordingly. If, as a result of this processing, a message is returned then the source transport address that the response message is sent from shall be identical to the destination transport address that the original request message was sent to.
The GetRequest-PDU
Upon receipt of the GetRequest-PDU, the receiving protocol entity responds according to any applicable rule in the list below:
1.
If the object's name does not exactly match the name of some object available or the object is an aggregate type, then error noSuchName is returned.
2.
If the size of the GetResponse-PDU generated would exceed a local limitation, then error tooBig is returned.
3.
If the value of the object cannot be retrieved, then error genErr is returned.
4.
If none of the foregoing rules apply, then the receiving protocol entity sends to the originator of the received message the GetResponse-PDU such that, for each object named in the variable-bindings field of the received message, the corresponding component of the GetResponse-PDU represents the name and value of that variable.
The GetNextRequest-PDU
The receiving protocol entity sends to the originator of the received message the GetResponse-PDU such that, for each name in the variable-bindings field of the received message, the corresponding component of the GetResponse-PDU represents the name and value of that object whose name is, in the lexicographical ordering of the names of all objects available for get operations in the relevant MIB view, together with the value of the name field of the given component, the immediate successor to that value.
Suppose that a routing table has three entries:
Destination NextHop Metric 10.0.0.99 89.1.1.42 5 9.1.2.3 99.0.0.3 3 10.0.0.51 89.1.1.42 5
The management station sends to the SNMP agent a GetNextRequest-PDU containing the indicated OBJECT IDENTIFIER values as the requested variable names:
GetNextRequest ( ipRouteDest,
ipRouteNextHop,
ipRouteMetric1 )
The SNMP agent responds with a GetResponse-PDU:
GetResponse (( ipRouteDest.9.1.2.3 = "9.1.2.3" ),
( ipRouteNextHop.9.1.2.3 = "99.0.0.3" ),
( ipRouteMetric1.9.1.2.3 = 3 ))
The management station continues with:
GetNextRequest ( ipRouteDest.9.1.2.3,
ipRouteNextHop.9.1.2.3,
ipRouteMetric1.9.1.2.3 )
The SNMP agent responds:
GetResponse (( ipRouteDest.10.0.0.51 = "10.0.0.51" ),
( ipRouteNextHop.10.0.0.51 = "89.1.1.42" ),
( ipRouteMetric1.10.0.0.51 = 5 ))
The management station continues with:
GetNextRequest ( ipRouteDest.10.0.0.51,
ipRouteNextHop.10.0.0.51,
ipRouteMetric1.10.0.0.51 )
The SNMP agent responds:
GetResponse (( ipRouteDest.10.0.0.99 = "10.0.0.99" ),
( ipRouteNextHop.10.0.0.99 = "89.1.1.42" ),
( ipRouteMetric1.10.0.0.99 = 5 ))
The management station continues with:
GetNextRequest ( ipRouteDest.10.0.0.99,
ipRouteNextHop.10.0.0.99,
ipRouteMetric1.10.0.0.99 )
As there are no further entries in the table, the SNMP agent returns those objects that are next in the lexicographical ordering of the known object names. This response signals the end of the routing table to the management station. 4.1.4.
The GetResponse-PDU
The form of the GetResponse-PDU is identical to that of the GetRequest-PDU except for the indication of the PDU type. The GetResponse-PDU is generated by a protocol entity only upon receipt of the GetRequest-PDU, GetNextRequest-PDU, or SetRequest-PDU.
The SetRequest-PDU
The form of the SetRequest-PDU is identical to that of the GetRequest-PDU except for the indication of the PDU type. For each object named in the variable-bindings field of the received message, the corresponding value is assigned to the variable. Each variable assignment specified by the SetRequest-PDU should be effected as if simultaneously set with respect to all other assignments specified in the same message. The receiving entity then sends to the originator of the received message the GetResponse-PDU of identical form except that the value of the error-status field of the generated message is noError and the value of the error-index field is zero.
The Trap-PDU
The Trap-PDU is generated by a protocol entity only at the request of the SNMP application entity. The means by which an SNMP application entity selects the destination addresses of the SNMP application entities is implementation-specific. Upon receipt of the Trap-PDU, the receiving protocol entity presents its contents to its SNMP application entity.
The significance of the variable-bindings component of the Trap-PDU is implementation-specific. Interpretations of the value of the generic-trap field are:
The coldStart Trap signifies that the sending protocol entity is reinitializing itself such that the agent's configuration or the protocol entity implementation may be altered.
The warmStart Trap signifies that the sending protocol entity is reinitializing itself such that neither the agent configuration nor the protocol entity implementation is altered.
The linkDown Trap signifies that the sending protocol entity recognizes a failure in one of the communication links represented in the agent's configuration. The Trap-PDU of type linkDown contains as the first element of its variable-bindings, the name and value of the ifIndex instance for the affected interface.
The linkUp Trap signifies that the sending protocol entity recognizes that one of the communication links represented in the agent's configuration has come up.
The authenticationFailure Trap signifies that the sending protocol entity is the addressee of a protocol message that is not properly authenticated.
The Advantages of SNMP
The largest advantage to using SNMP is that its design is simple, hence it is easy to implement on a large network, for it neither takes a long time to set up nor poses a lot of stress on the network. Also, its simple design makes it easy for a user to program variables they would like to have monitored, for in a more low-level perspective each variable consists of the following information:
the variable title
the data type of the variable (integer, string)
whether the variable is read-only or read-write
the value of the variable
The net result of this simplicity is a network manager that is easy to implement and not too stressful on an existing network.
Another advantage of SNMP is that it is in very wide use today. This popularity came about when no other network managers appeared to replace the "band-aid" implementation of SNMP. The result of this is that almost all major vendors of internetwork hardware, such as bridges and routers, design their products to support SNMP, making it very easy to implement.
Expandability is another benefit of SNMP. Because of its simple design, it is easy for the protocol to be updated so that it can expand to the needs of users in the future.
The Disadvantages to SNMP and how they can be Overcome
SNMP is by no means a perfect network manager. It has its faults, yet because of its clever design most of these faults have workarounds.
The first deficiency with SNMP is that it has some large security gaps that can give network intruders access to the information carried along the network. Intruders could also potentially shut down some terminals.
The solution to this problem is simple. Because of the expandability of SNMP, the latest version of SNMP, called SNMPv2, has added some security mechanisms that help combat the largest security problems:
privacy of data (to prevent intruders from gaining access to information carried along the network),
authentication (to prevent intruders from sending false data across the network),
access control (which restricts access of particular variables to certain users, thus removing the possibility of a user accidentally crashing the network).
The biggest problem with SNMP though is that it is generally considered to be so simple that the information it deals with is neither detailed nor well-organized enough to deal with the expanding networks of the 1990's. This is mainly due to the quick creation of SNMP, for it was never intended to lead network management into the 1990's.
This large problem has been fixed in a newer release of SNMP, SNMPv2. This new version allows for more in-detail specification of variables, including the use of the table data structure for easier data retrieval. Also included are two new PDU's that are used to manipulate the tabled objects. In fact, so many new features have been added that the formal specifications for SNMP have expanded from 36 pages (with v1) to 416 pages with SNMPv2. Some may argue that with SNMPv2 the protocol lost its simplicity, but the fact is that changes to SNMP were necessary. It was an old system that just could not handle the network-intensive world of the 1990's. SNMPv2 incorporates a Remote Monitoring MIB (RMON), and enhanced security procedures.
RMON
The RMON specification defines standard network monitoring functions and interfaces for communicating between SNMP-based devices. RMON gives networks the capability to provide an effective and efficient way to monitor subnetwork-wide behavior while reducing the burden both on other agents and management stations.
The RMON MIB uses an agent device connected to a broadcast network for collecting network traffic statistics. The RMON MIB also performs calculations directly at the agent and does not rely on the manager for all of its functions. Typically, an agent is only responsible for management information that relates to its own device. Without a remote monitoring function, it is difficult, if not impossible, for a manager to construct a profile of any activity on an individual subnetwork.
The RMON MIB can be implemented directly into today's management applications and does not require the entire SNMPv2 to be used. To be effective, a dedicated management station with RMON management and agent capability is attached to the central LAN. The RMON agents are resident on devices that monitor each subnetwork to which they are attached, thereby giving the manager network layer monitoring. This monitoring includes off-line operation, problem detection and reporting, value-added data and multiple-manager support.
Common Management Information Protocol (CMIP)
The CMIP protocol was supposed to be the protocol that replaced SNMP in the late 1980's. Funded by governments and large corporations, many thought that it would become a reality because of its almost unlimited development budget. Unfortunately, problems with its implementation have delayed its widespread availability and it is now only available in limited form from its developers themselves.
CMIP was designed to build on SNMP by making up for SNMP's shortcomings and becoming a bigger, more detailed network manager. Its basic design is similar to SNMP, whereby PDU's are employed as variables to monitor a network. CMIP however contains 11 types of PDU's (compared to SNMP's five).
In CMIP, the variables are seen as very complex and sophisticated data structures, with many attributes. These include :
1.
variable attributes: which represent the variables characteristics (its data type, whether it is writable).
2.
variable behaviors: what actions of that variable can be triggered.
3.
Notifications: the variable generates an event report whenever a specified event occurs (such as a terminal shutdown would cause a variable notification event.
As a comparison, SNMP only employs variable properties one and three from above.
The Advantages to the CMIP Approach
The biggest feature of the CMIP protocol is that its variables not only relay information to and from the terminal (as in SNMP), but they can also be used to perform tasks that would be impossible under SNMP. For instance, if a terminal on a network cannot reach its file server a pre-determined amount of times, then CMIP can notify the appropriate personnel of the event. With SNMP however a user would have to explicitly keep track of how many unsuccessful attempts to reach a file server that a terminal has incurred. CMIP thus results in a more efficient network management system, as less work is required by a user to keep updated on the status of their network.
Another advantage to the CMIP approach is that it addresses many of the shortcomings of SNMP. For instance, it has built in security management devices that support authorization, access control, and security logs. The result of this is a safer system from the installation of CMIP; no security upgrades are necessary (like SNMP).
The last advantage is that CMIP was funded by not only governments, but also large corporations. One can induce that CMIP not only has a very large development budget, but also that when it becomes a widely available protocol it will have numerous immediate users, namely the governments and corporations that funded it.
The Disadvantages of CMIP and potential solutions to these problems
From the above, one might wonder that if CMIP is so wonderful, why hasn't it been implemented already (for after all, it has been in development for about ten years). The answer to this is CMIP's only significant disadvantage: the CMIP protocol takes more system resources than SNMP by a factor of ten. In other words, very few systems on this planet would by able to handle a full implementation of CMIP without massive network modifications (such as the installation of thousands of dollars of memory and the purchase of new protocol agents). This major disadvantage has no inexpensive workaround, and for this reason many people believe that the CMIP protocol is doomed to fail. The only possible workaround is to decrease the size of the protocol by changing its specifications. Several protocols have been developed to run "on top" of CMIP and thus use less resources but none of these has gathered enough momentum to challenge SNMP.
Another problem with CMIP is that it is very difficult to program; for the variables require so many different variables that only a few skilled programmers would be able to use the variables to their full potential.