Download
1 / 30
330 likes | 731 Vues
Simple Network Management Protocol (SNMP). Khalid ibrahim. Introduction to SNMP: History. 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.
E N D
Simple Network Management Protocol (SNMP) Khalid ibrahim
Introduction to SNMP: History • 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 • SNMP is based on the manager/agent model consisting of an SNMP manager, an SNMP agent, a database of management information, managed SNMP devices and the network protocol • The SNMP manager provides the interface between the human network manager and the management system • The SNMP agent provides the interface between the manager and the physical device(s) being managed. • The SNMP manager and agent use an SNMP Management Information Base (MIB) and a relatively small set of commands to exchange information. • The SNMP MIB is organized in a tree structure with individual variables, such as point status or description, being represented as leaves on the branches.
SNMP Messages • SNMP v1 uses the following five basic messages. • GET, • GET-NEXT, • GET-RESPONSE, • SET, and • TRAP to communicate between the SNMP manager and the SNMP agent. • The GET and GET-NEXT messages allow the manager to request information for a specific variable • SNMP v2 and v3 uses the additional four messages: • GET BULK • NOTIFICATION • INFORM • REPORT
SNMP Messages • The agent, upon receiving a GET or GET-NEXT message, will issue a GET-RESPONSE message to the SNMP manager with either the information requested or an error indication as to why the request cannot be processed • A SET message allows the SNMP manager to request a change be made to the value of a specific variable • The SNMP 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 SNMP TRAP message allows the agent to spontaneously inform the SNMP manager of an "important" event.
SNMP Messages • 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 SNMP agent, it is the message used by 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.
SNMP Messages • The small number of commands used is only one of the reasons SNMP is “Simple” • This simplicity has led directly to the widespread use of SNMP, specifically in the Internet Network Management Framework • Within this framework, it is considered "robust" because of the independence of the SNMP managers from the agents, e.g. if an SNMP agent fails, the SNMP manager will continue to function, or vice versa.
SNMP OID • SNMP OIDs Are the Leaves on the MIB Tree Structure • An SNMP OID (object identifier) is assigned to an individual object within a Management Information Base (MIB). • An MIB can be broken down into a tree structure. • Within this structure, individual OIDs are representative of the leaves on the tree. • More specifically, an OID is a string of numbers readable only to the MIB. • What does an SNMP OID look like? • Here's an example: 1.3.6.1.4.1.2681.1.2.102
Object Identifiers (OID) • OIDs are crucial in the assembly of SNMP messages. An SNMP OID functions as an address that identifies the location of a specific element within the entire SNMP network. • The translation of OIDs allows the SNMP manager to determine values for these objects. • The MIB assigns readable labels to each OID, which allows the manager to interpret and assemble SNMP messages. • Without the OID, the message cannot be translated into a form that is readable to humans. • When the SNMP manager requests the value of any object, it assembles a message with the OID, which is sent to the MIB for decoding. • If the OID is listed within the MIB at that particular management station, a message is sent back to the manager including the value requested for that particular OID
OID • Objects Not Listed in the MIB Cannot Be Monitored • If an object does not have an OID within a MIB, your SNMP manager cannot interpret it. • For example, if an SNMP RTU has a built-in component to monitor battery charge levels, but the battery charge sensor does not have an OID listed in the MIB file, the RTU will be unable to send and receive traps that contain battery-charge-level data. • While each SNMP OID is unique, the first several pieces of each OID are almost always the same. • These upper location levels are defined by a series of standard reference within the MIB. These series are called RFCs, or Requests for Comments. The RFCs that define SNMP OIDs are part of a larger group of RFC documents that define the Internet as a whole. Individual vendors create their own MIBs that only include the OIDs associated specifically with their device.
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 in the previous slides. • 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.
SNMP Operation • When an SNMP manager wants to know the value of an object, 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 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 included. • If the OID is not found, a special error response is sent that identifies the unmanaged object.
SNMP Data Packet Structure • Request Identifier: A number used to match requests with replies. It is generated by the device that sends a request and copied into this field in a GetResponse-PDU by the responding SNMP entity. • Error Index: When Error Status is non-zero, this field contains a pointer that specifies which object generated the error. Always zero in a request. • Variable Bindings: A set of name-value pairs identifying the MIB objects in the PDU, and in the case of a SetRequest-PDU or GetResponse-PDU, containing their values. • NOTE: Each variable binding contains an identifier, a type and a value (if a Set or GetResponse). • 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 Protocol Message Generation • Message generation in SNMP is a bit different than the typical TCP/IP client/server model used for most other protocols. • There aren't really any formal “clients” and “servers” in SNMP, since management information can be obtained from any device—it is distributed. • The network management station (NMS) usually acts as the client in these exchanges, sending a particular get or set request to an SNMP agent, which plays the role of server for the information it contains. • However, SNMP agents aren't usually considered “servers” in the conventional sense of the term.
SNMP Trap Message • SNMP traps deviate from the normal request/reply model of message generation entirely. • When a trap is triggered, an SNMP agent sends a trap message to a network management station on its own, not in reaction to receiving a request. • Since trap messages are unconfirmed there is no reply.
SNMP Operations • Our last article focused on the structure of SNMP messages, however an SNMP message is not sent by itself. • It is wrapped 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 • 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, co-axial or fiber).
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.
Traversing the Layers • 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.
Traversing the Layers • 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. • Network Interface layer • IP layer. • UDP layer; where the target port is checked for connected applications • Application Layer
Traversing the Layers • The message gets to 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.
