Skip to main content

SNMPv1/v2/v3 Message/PDU Format


SNMPv1 Message Formats

SNMPv1 messages contain two parts: a message header and a protocol data unit (PDU).
Figure: An SNVPv1 Message Consists of a Header and a PDU illustrates the basic format of an SNMPv1 message.
Figure: 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 number - Specifies the version of SNMP used.
§  Community name - Defines 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: SNMPv1 Get, GetNext, Response, and Set PDUs Contain the Same Fields illustrates the fields of the SNMPv1 Get, GetNext, Response, and Set PDUs transactions.
Figure: SNMPv1 Get, GetNext, Response, and Set PDUs Contain the Same Fields

The following descriptions summarize the fields illustrated in Figure: SNMPv1 Get, GetNext, Response, and Set PDUs Contain the Same Fields:
§  PDU type - Specifies the type of PDU transmitted.
§  Request ID - Associates SNMP requests with responses.
§  Error status - Indicates one of a number of errors and error types. Only the response operation sets this field. Other operations set this field to zero.
§  Error index - Associates an error with a particular object instance. Only the response operation sets this field. Other operations set this field to zero.
§  Variable bindings - Serves 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: The SNMPv1 Trap PDU Consists of Eight Fields illustrates the fields of the SNMPv1 Trap PDU.
Figure: The SNMPv1 Trap PDU Consists of Eight Fields

The following descriptions summarize the fields illustrated in Figure: The SNMPv1 Trap PDU Consists of Eight Fields:
§  Enterprise - Identifies the type of managed object generating the trap.
§  Agent address - Provides the address of the managed object generating the trap.
§  Generic trap type - Indicates one of a number of generic trap types.
§  Specific trap code - Indicates one of a number of specific trap codes.
§  Time stamp - Provides the amount of time that has elapsed between the last network reinitialization and generation of the trap.
§  Variable bindings - The data field of the SNMPv1 Trap PDU. Each variable binding associates a particular object instance with its current value.

SNMPv2 Message Format

SNMPv2 messages consist of a header and a PDU.
Figure: SNMPv2 Messages Also Consist of a Header and a PDU illustrates the basic format of an SNMPv2 message.
Figure: 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 number - Specifies the version of SNMP that is being used.
§  Community name - Defines 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).
The following descriptions summarize the fields illustrated in Figure: SNMPv2 Get, GetNext, Inform, Response, Set, and Trap PDUs Contain the Same Fields:
§  PDU type - Identifies the type of PDU transmitted (Get, GetNext, Inform, Response, Set, or Trap).
§  Request ID - Associates SNMP requests with responses.
§  Error status - Indicates one of a number of errors and error types. Only the response operation sets this field. Other operations set this field to zero.
§  Error index - Associates an error with a particular object instance. Only the response operation sets this field. Other operations set this field to zero.
§  Variable bindings - Serves as the data field of the SNMPv2 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).
Figure: SNMPv2 Get, GetNext, Inform, Response, Set, and Trap PDUs Contain the Same Fields illustrates the fields of the SNMPv2 Get, GetNext, Inform, Response, Set, and Trap PDUs.
Figure: SNMPv2 Get, GetNext, Inform, Response, Set, and Trap PDUs Contain the Same Fields

GetBulk PDU Format

Figure: The SNMPv2 GetBulk PDU Consists of Seven Fields illustrates the fields of the SNMPv2 GetBulk PDU.
Figure: The SNMPv2 GetBulk PDU Consists of Seven Fields

The following descriptions summarize the fields illustrated in Figure: The SNMPv2 GetBulk PDU Consists of Seven Fields:
§  PDU type - Identifies the PDU as a GetBulk operation.
§  Request ID - Associates SNMP requests with responses.
§  Non repeaters - the number of objects that are only expected to return a single GETNEXT instance, not multiple instances. Managers frequently request the value of sysUpTime and only want that instance plus a list of other objects.
§  Max repetitions - the number of objects that should be returned for all the repeating OIDs. Agent's must truncate the list to something shorter if it won't fit within the max-message size supported by the command generator or the agent.
§  Variable bindings - Serves as the data field of the SNMPv2 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).

SNMP V3 Message Format:
• The SNMPv3 message format is shown in Figure

• Version – It is an Integer that identifies the version of SNMP. For SNMPv3, it is 3.
• Msg ID – A number used to identify an SNMPv3 message and to match response messages to request messages. The use of this field is similar to that of the Request ID field in the PDU format, but they are not identical. This field was created to allow matching at the message processing level regardless of the contents of the PDU, to protect against certain security attacks. Thus, Msg ID and Request ID are used independently.• Max Size – This field represents the maximum size of message which the requesting SNMP entity can accept.
• MaxSize - The maximum size of message that the sender of this message can receive. Minimum value of this field is 484.
• Flags – This field contains the message security level. 0 – message is authenticated, 1 – message uses privacy, 2 – a report PDU is expected for the message
• Security Model – This field indicates the security model used to generate the message. When USM is used, it has a value of 3
• Engine ID – This field has the SNMPEngineID of the authoritative SNMP entity involved in the transaction. When a request PDU is generated from an SNMP engine, the remote peer (agent for Get request and manager for Trap request) is the authoritative SNMP entity.
• Engine Boots – This field has the snmpEngineBoots value of the authoritative SNMP entity involved in the transaction
• Engine Time – This field has the snmpEngineTime value of the authoritative SNMP entity involved in the transaction
• User Name – This field contains the principal who originated the request.
• Security Parameters – This field contains the security parameters that are security model dependent. It contains the authentication parameters and the privacy parameters for USM.
• Context Engine ID – Within an administrative domain, the contextEngineID uniquely identifies an SNMP entity that may realize an instance of a context with a particular contextName.
• Context Name – A contextName is used to name a context. Each contextName must be unique within an SNMP entity.
• PDU – The SNMP PDU (Protocol Data Unit) is used for communication between the SNMP entities


Comments

Popular posts from this blog

What is QinQ(IEEE 802.1ad)

What is QinQ In this section, we will see about Switching concept QinQ. In service provider networks, This is very important. Service provider use this Switching function to pass customer data from one end to other end with two vlan id’s in own switching network.  Explanation: The QinQ technology is called VLAN dot1q tunnel, 802.1Q tunnel, VLAN Stacking technology. The standard comes from IEEE 802.1ad and it is the expansion of the 802.1Q protocol. QinQ adds one layer of 802.1Q tag (VLAN tag) based on the original 802.1Q packet head. With the double layers of tags, the VLAN quantity is increased to 802.1Q. QinQ encapsulates the private network VLAN tag of the user in the public(service provider) network VLAN Tag to make the packet with double layers of VLAN Tags cross the backbone network (public network) of the operator. In the public network, the packet is passed according to the out layer of VLAN tag (that is the public network VLAN Tag) and the private network

Beacon Frames, Probe request and response

Beacon frame  is one of the management frames in  IEEE 802.11  based WLANs. It contains all the information about the network. Beacon frames are transmitted periodically, they serve to announce the presence of a wireless LAN and to synchronise the members of the service set. Beacon frames are transmitted by the  access point  (AP) in an infrastructure  basic service set  (BSS). In IBSS network beacon generation is distributed among the stations. Beacons are sent periodically at a time called Target Beacon Transmission Time(TBTT) 1 TU = 1024 microseconds Beacon interval =100 TU (100x 1024 microseconds or 102.4 milliseconds) 1. Timestamp (8 byte) 2. Beacon Interval (2 byte) 3. Capability info (2 byte) 4. SSID (variable size) 5. Supported Rates (variable size) Probe Request:  A station or client becomes active or on a PC when the wlan card it enabled it becomes active sends a probe request frame when it needs to obtain information from another station or access point.

Difference between Polling and Trap in Network Management – Which one is better?

A Network Manager’s job is to get data from Network Elements and present it to the administrators or operators. There are two ways of doing this activity:  1) Polling and 2) Trap . Here is a quick difference between the two: Polling  : A traditional way of providing operators with the network elements information. It’s characteristics are as follows: ·        Pull Mechanism – Requests and get information from network elements at periodic intervals. The periodic interval is most often configurable. ·        Provides non-real time information. It may happen that some changes happen in network element but polling happens an hour after that. Thus, operator gets to know about the changes after an hour. ·        Higher bandwidth needed. Traps  : When an alarm situation exists a trap can be generated, or if some changes happen at network element, an attribute value change event can be generated by the agent. It’s characteristic are as follows: ·        Push Mechanism – E