Data Comm for Business, Inc.

Your Complete Data Communications Solution Provider

Network Management

By: Gene Kuhl, Data Comm for Business, Inc.

INTRODUCTION

Probably no two words used in the data communications industry can evoke as much commentary as the title of this paper. The genesis of network management is buried in the 1970's when networks were evolving from point-to-point circuits to multi-drop circuits. This simple change meant that there were now multiple opportunities to screw up the network and multiple choices on how to fix it. It was true then, and I suspect it is true today, that the ideal NMS would provide the following display:

THE LINK TO EAST EARLOBE IS DOWN
THE LINK HAS BEEN RESTORED USING DIAL BACKUP
MR. JONES FROM THE TELEPHONE COMPANY
IS HOLDING FOR YOU ON LINE 2

The primary goal was if it's broke, what broke, who is responsible for fixing it, and how can we operate until it is fixed? A secondary goal was if it's working , how well is it working?

During that period and for many years afterward an absolute plethora of "Network Management Systems" were introduced. There was only one problem - they did not manage the network. They were designed with the primary goal of being a vehicle to accelerate the sale of a particular vendor's products, and incidentally provide a diagnostic tool for that vendor's products. Since the vendor community could see no benefit to providing an open network management capability this goal could only be achieved by pressure from the user community. This is in fact what happened.

THE OPEN SYSTEM

The goal of the open system concept was very simple. The user wants to build a network using products from company A, B, and C, and he wants to manage this network from a single platform. Now a lot of heavy thinkers got into the act and the next thing we knew was that there was the wonderful seven layers of the OSI-based network management model, to which a lot of people said "HUH?" Also in that period came the concept of the Simple Network Management Protocol (SNMP) with a heavy emphasis on Simple. Conceptually a system was defined that was made up of managed network nodes and a network management station, where the managed nodes are minimally impacted by the management requirements. This minimal impact had to be both on the cost of providing the management capability in the node and the impact on the performance of the node. After all, the objective of the network node, and reason it was purchased, is to pass data, not implement a network management system. This then implies that the major computational requirements are placed on the management station. Very briefly, these were the objectives of the designers of the current generation of network management systems.

SNMP

This paper is not being written to provide an in-depth knowledge of SNMP and the functions that may be performed. Quite simply it is written with the hope that it may prove to be an elementary road guide for the uninitiated. One of the problems with any technology is that it quickly takes on a life of its own along with its own terminology, making it difficult to "get started." As the technology takes on its own life it also seems that a generation of devotees develops dedicated to the technology and not the problem the technology is designed to solve, further exacerbating the "getting started" problem. There is a "getting started" reference list at the end of this paper which the interested reader is encouraged to pursue for technical information.

This is simply written for the person who uttered those famous words:

"What the World is SNMP?"

One would think that the Simple Network Management Protocol would define a protocol. As it turns out the protocol is only one of three elements that make up SNMP. The elements of SNMP are the following:

SNMP relies on the concept of a central management station(s), the manager, communicating with a number of managed devices throughout the network, the agents. The communications used is UDP/IP again reflecting the simplicity required. The manager either requests information from the agent (GET), or directs the agent to change the value of a variable (SET). The result of the SET may result in an action within the node such as disconnecting a port. The basic concept is that SNMP deals with managed objects (variables) in the node which are mapped by the MIB. The MIB is a virtual database reflecting the resources of the agent, and the complete definition of each object. This definition includes the name, syntax, definition, description, and access privileges.

SNMP supports three basic operations on the MIB objects:

The SMI (Structure of Management Information) is a set of rules that defines the naming relationship of managed objects (variables). The SMI also defines generic data types such Integer, Counter, etc. The SMI organizes the managed objects into a hierarchy for identification purposes such that each managed object is absolutely identified.

For a variety of reasons, or non-reasons depending on the point of view taken, all of the elements of SNMP: the protocol, the SMI, and the MIB, are formally defined using a subset of the ISO defined language known as Abstract Syntax Notation One (ASN.1). While ASN.1 is not the simplest of concepts to deal with (a generous supply of Aspirin or Scotch will help) it does provide a tool to define data and data structures in a machine independent manner, and the Basic Encoding Rules (BER) define the transfer syntax. ASN.1 is used to define the format of the data being exchanged and to define the objects being managed. Prior to discussing the BER it is important to understand the basic encoding unit, the octet, is eight bits long. Since a byte is not necessarily a byte as data is moved from machine to machine (to say nothing of a word) it is necessary to have a formal definition of this unit. As data is passed to the network the most significant bit is bit 8 and the least significant is bit 1.

Each ASN.1 type is encoded as three fields, tag, length, and value. The simple type of tags are Integer, Octet String, and Object Identifier. Constructor types are Sequence and Sequence Of. A Sequence may be thought of as a data structure or an array of mixed type of variables, while a Sequence Of is an array of homogenous variables. The Object Identifier uniquely identifies a named object (variable, managed object). This is done by transversing the MIB starting at the most basic element until the object in question is reached. For example the PC that is a part of the PA2000 would be identified as 1.3.6.1.4.1.233.32.2 where:

Do not confuse the Object Identifier with the notation used for IP addresses, as they have nothing in common other than using a "dot" notation.

The SNMP operations are packaged in protocol data units (PDU) that contain the operation (GET, SET, etc.) along with some information and authentication items. The SNMP packet is represented as a Sequence of the following items.

Version Currently zero
Community Name Octet String
PDU A Sequence of the following
Tag Defines PDU as GET, SET, etc.
Length
Length of the PDU
Request ID Used for correlation between agent and manager
Error Status Non-zero represents type of error
Error Index Indicates which Varbind caused the error

Sequence of Varbinds

A Varbind is a Sequence of Object ID's and values. If the PDU Tag is a SET then the value will be the new value for the managed object under control of the agent. If the Tag were for a GET operation the value would indicate the current value of the managed object. For example, if PDU Tag indicated a SET operation and the Object Identifier were 1.3.6.1.4.1.233.32.3.1.1.9.1 this might identify the Mux Reset flag for the first instance of an SPL Mux, which would then be followed by 02 ( the flag for an integer), 01 (the length of the encoded octet containing the new value), 02 (the value for Reset, 01 being the normal value). The PDU may contain multiple SET or GET operations in one packet but all operations must be successful or the entire operation is rejected and no values are changed and/or reported.

TRAPS

The subject of Traps can, and has filled volumes on the subject of when to generate traps, if at all. If the traps are generated asynchronously upon detection of some pre-defined anomaly in the managed device, then does one not run the risk of clogging the network with trap information? There is also a valid question based on whether a trap represents information or only after trap data is correlated with other data does it become information. All of this is interesting but beyond the scope of this paper, but the reader should be aware that traps and their use is not a well defined subject..

Basically there are seven generic trap definitions as follows:


  1. Cold Start Trap
  2. Warm Start Trap
  3. Link Down Trap
  4. Link Up Trap
  5. Authentication Failure
  6. Egp Neighbor Loss
  7. Enterprise Specific
The Trap PDU is slightly different than the other PDU's previously discussed.

Tag 04
Length Length of the PDU
Object Identifier This is the sysObjectID which identifies the type agent
Network Address The IP address of the agent sending the trap
Generic Trap Type Defined above
Specific Type of Trap This will be zero unless the Generic Trap is Enterprise Specific then it will be enterprise defined.
TimeTicks Time in tens of milliseconds since the agent was last initialized - probably of great value.

**** If the Generic trap type is not Enterprise Specific the PDU ends here***

Sequence of Varbinds termed "interesting information" and will be unique to the node with as many variables as the writer of the agent deems necessary to convey his message.

REFERENCES

Marshall T. Rose, The Simple Book - Second Edition, Prentice Hall

ISBN 0-13-177254-6

Douglas Steedman, Abstract Syntax Notation One (ASN.1): the Tutorial and Reference
Technology Apprasials Ltd., 1990 ISBN 1-871802-06-7
RFC 1155 Structure of Management Information
RFC 1157 Simple Network Managment Protocol
RFC 1212 Concise MIB Definitions
RFC 1213 Management Information Base II


Gene Kuhl writes firmware at Data Comm for Business, Inc. His Email address is Gkuhl@dcbnet.com



Data Comm for Business, Inc. is a manufacturer and distributor of a diverse line of data communications and networking products. Their experts can help you connect remote sites with phone (1-800-4-dcbnet), email (info@dcbnet.com), or personal (807 Pioneer, Champaign, Il. 61820) assistance. Check out their Web page at http://www.dcbnet.com .