yvjanard

MAKING IN PROGRESS:

INTRODUCTION:

  Since its creation in 1988 as a short-term solution to manage  elements in the growing Internet and other attached networks,  SNMP has achieved widespread acceptance. SNMP was derived  from its predecessor SGMP (Simple Gateway Management  Protocol) and was intended to be replaced by a solution based on  the CMIS/CMIP (Common Management Information  Service/Protocol) architecture. This long-term solution, however,  never received the widespread acceptance of SNMP.

  SNMP is based on the manager/agent model consisting of a  manager, an agent, a database of management information,  managed objects and the network protocol. The manager provides  the interface between the human network manager and the  management system. The agent provides the interface between the

  manager and the physical device(s) being managed (see the  illustration above).

  The manager and agent use a  Management Information  Base (MIB) and a relatively  small set of commands to  exchange information. The  MIB is organized in a tree  structure with individual  variables, such as point status  or description, being  represented as leaves on the  branches. A long numeric tag  or object identifier (OID) is used to distinguish each variable  uniquely in the MIB and in SNMP messages.

  SNMP uses five basic messages (GET, GET-NEXT,  GET-RESPONSE, SET, and TRAP) to communicate between the  manager and the agent. The GET and GET-NEXT messages allow  the manager to request information for a specific variable. The  agent, upon receiving a GET or GET-NEXT message, will issue a  GET-RESPONSE message to the manager with either the  information requested or an error indication as to why the request  cannot be processed. A SET message allows the manager to request  a change be made to the value of a specific variable in the case of  an alarm remote that will operate a relay. The agent will then  respond with a GET-RESPONSE message indicating the change  has been made or an error indication as to why the change cannot  be made. The TRAP message allows the agent to spontaneously  inform the manager of an ?important? event.

  As you can see, most of the messages (GET, GET-NEXT, and  SET) are only issued by the SNMP manager. Because the TRAP  message is the only message capable of being initiated by an agent, it is the message used by DPS Remote Telemetry Units (RTUs) to  report alarms. This notifies the SNMP manager as soon as an  alarm condition occurs, instead of waiting for the SNMP manager  to ask.

  The small number of commands used is only one of the reasons  SNMP is "simple." The other simplifying factor is its reliance on an  unsupervised or connectionless communication link. This  simplicity has led directly to its widespread use, specifically in the  Internet Network Management Framework. Within this  framework, it is considered ?robust? because of the independence  of the managers from the agents, e.g. if an agent fails, the manager  will continue to function, or vice versa. The unsupervised  communication link does however create some interesting issues  for network alarm monitoring we will discuss more thoroughly in a  later issue of our tutorial.

  What Do You Want To Do With SNMP?

    1.Mediate SNMP and Other Protocols

    2.Display SNMP Alarm Data at Your NOC and in Your Web       Browser

    3.Monitor Discrete, Analog, and Ping Alarms via SNMP

    4.Automatically Dispatch Repair Personnel

    5.Control Remote Equipment via SNMP

    6.Use Dial-Up Connections to Link SNMP Remotes to LAN

    7.Find the SNMP Alarm Monitoring Capacity That's Right for       Your Size Site

  What Do You Want To Learn About SNMP?

  Each SNMP element manages specific objects with each object  having specific characteristics. Each object / characteristic has a  unique object identifier (OID) consisting of numbers separated by  decimal points (i.e., 1.3.6.1.4.1.2682.1). These object identifiers  naturally form a tree as shown below. The MIB associates each  OID with a readable label (i.e., dpsRTUAState) and various other  parameters related to the object. The MIB then serves as a data  dictionary or code book that is used to assemble and interpret SNMP messages.

  When an SNMP  manager wants  to know the  value of an  object /  characteristic,  such as the state  of an alarm  point, the system  name, or the  element uptime,  it will assemble a  GET packet that  includes the OID  for each object /  characteristic of  interest. The  element receives  the request and  looks up each OID in its code  book (MIB). If the OID is found (the object is managed by the  element), a response packet is assembled and sent with the current  value of the object / characteristic included. If the OID is not  found, a special error response is sent that identifies the  unmanaged object.

  When an element sends a TRAP packet, it can include OID and  value information (bindings) to clarify the event. DPS remote  units send a comprehensive set of bindings with each TRAP to  maintain traditional telemetry event visibility. Well-designed  SNMP managers can use the bindings to correlate and manage the events. SNMP managers will also generally display the readable  labels to facilitate user understanding and decision-making.

  This article in our series on the Simple Network Management Protocol  (SNMP) examines the communication between managers and agents.  Basic serial telemetry protocols, like TBOS, are byte oriented with a  single byte exchanged to communicate. Expanded serial telemetry  protocols, like TABS, are packet oriented with packets of bytes exchanged  to communicate. The packets contain header, data and checksum bytes.  SNMP is also packet oriented with the following SNMP v1 packets  (Protocol Data Units or PDUs) used to communicate:

    1.Get 

    2.GetNext 

    3.Set 

    4.Trap 

  The manager sends a Get or GetNext to read a variable or variables and  the agent's response contains the requested information if managed. The  manager sends a Set to change a variable or variables and the agent's

response confirms the change if allowed. The agent sends a Trap when a  specific event occurs.

  The image below shows the packet formats. Each variable binding  contains an identifier, a type and a value (if a Set or response). The agent  checks each identifier against its MIB to determine whether the object is

managed and changeable (if processing a Set). The manager uses its MIB  to display the readable name of the variable and sometimes interpret its  value.

   SNMP Packet Formats

   

  In this fourth article in our series, we continue to examine the  Simple Network Management Protocol (SNMP) focusing  specifically on the layered communication model used to exchange  information. Our last article focused on the structure of SNMP  messages, however an SNMP message is not sent by itself. It iswrapped in the User Datagram Protocol (UDP), which in turn is  wrapped in the Internet Protocol (IP). These are commonly  referred to as layers and are based on a four-layer model  developed by the Department of Defense (you may recall the DoD  origins of the Internet).

  SNMP resides in what is called the  Application layer, UDP resides in the  Transport layer and IP resides in the  Internet layer (somewhat obvious). The  fourth layer is the Network Interface  layer where the assembled packet is  actually interfaced to some kind of  transport media (i.e., twisted pair  copper, RG58 co-axial or fiber). While  this multi-layer model may seem a bit  confusing, it effectively isolates the tasks of communication and ultimately assists in designing and  implementing a network.

  Traversing the Layers

  To illustrate the function of this layered model, let's look at a single  SNMP GET request from the agent's perspective. The SNMP  manager wants to know what the Agent's System Name is and  prepares a GET message for the appropriate OID. It then passes  the message to the UDP layer. The UDP layer adds a data block  that identifies the manager port to which the response packet  should be sent and the port on which it expects the SNMP agent to  be listening for messages. The packet thus formed is then passed to  the IP layer. Here a data block containing the IP and Media Access  addresses of the manager and the agent is added before the entire  assembled packet gets passed to the Network Interface layer. The  Network Interface layer verifies media access and availability and  places the packet on the media for transport.

  After working its way across bridges and through routers (the  modern equivalent of over the rivers and through the woods) based  on the IP information, the packet finally arrives at the agent. Here  it passes through the same four layers in exactly the opposite order  as it did at the manager. First, it is pulled off the media by the  Network Interface layer. After confirming that the packet is intact  and valid, the Network Interface layer simply passes it to the IP  layer. The IP layer verifies the Media Access and IP address and passes it on to the UDP layer where the target port is checked for  connected applications. If an application is listening at the target  port, the packet is passed to the Application layer. If the listening  application is the SNMP agent, the GET request is processed as we  have discussed in previous articles. The agent response then follows  the identical path in reverse to reach the manager.

   An SNMP message passes through the protocol layers at both the   manager and the agent. Each layer addresses a specific   communication task. 

  An Aid for Troubleshooting

  Understanding this layered model makes it easier to troubleshoot  communication problems. When there is a problem, you can  simply trace it down, out one end, into, and up the other.  LAN/WAN link and activity status indicators provide some  visibility to the Network Interface layer. ICMP echo requests and  responses (Pings) provide some information regarding the proper  functioning of the IP layer. SNMP processing indicators can be  used to verify the passage of the packet through the UDP layer and  the functioning of the Application layer. Each step can be verified  independently until all steps are working correctly for end-to-end  communication.