The SNMP show
|
|
|||
|
|
Welcome back to the SNMP show! Yes, we're your host, Gearhead, and we'd like to start off this week with (roll on the drums please, maestro) SNMP message structure! Take it awaaaayyyy . . .
Thank you us, thank you very much. We'd like to begin with what SNMP messages look like. Messages in SNMP Versions 1 and 2 consist of data wrapped in a User Datagram Protocol (UDP) message. This data consists of a header and a Protocol Data Unit (PDU), aka "payload." The header consists of two fields: Version Number and Community Name.
Advertisement: |
Version Number is 1 or 2, depending on the version of SNMP being used, and Community Name is an identifying string that names the group of managers for which the message is intended.
The PDUs of all types of messages except traps under Version 1 (Get, GetNext, Response and Set) contain the same fields:
Request ID - a value that associates requests with responses.
Error status - only used by a response to indicate an error (otherwise it is set to zero).
Error index - only used by a response to associate an error with a particular object instance (an object being a managed entity under SNMP).
Variable bindings - These are the data fields of the PDU. Each variable binding associates a particular object instance (a managed item) with its current value (this doesn't apply to Get and GetNext requests).
SNMP Version 1 traps are structured a bit differently and also use eight PDU fields:
Enterprise - identifies the type of managed object generating the trap.
Agent address - the address of the managed object generating the trap.
Generic trap type - indicates a generic trap type.
Specific trap code - indicates specific trap codes.
Time stamp - Provides the amount of time that has elapsed between the trap being generated and the last network reinitialization.
Variable bindings - As in the above PDU types.
Version 2 tidied this up somewhat by using one format for all existing message types. With the addition of one new field - PDU Type (for example, Get, GetNext, Inform, Response, Set or Trap) - the PDU looks the same as the format of Version 1 Get, GetNext, Response and Set PDUs.
But Version 2 also introduced a new request: GetBulk. The GetBulk operation was added to make it easier to access large amounts of related information without initiating repeated GetNext operations. GetBulk was designed to virtually eliminate the need for GetNext operations.
The PDU for GetBulk consists of seven fields that start with PDU type and Request ID and then gets exotic:
Nonrepeaters - used when there are scalar objects with only one variable and specifies the number of object instances that should be retrieved no more than once from the beginning of the request. In other words, it assures nonduplicated data.
Max repetitions - the maximum number of times that other variables beyond those specified by the nonrepeaters field should be retrieved.
And our old friend, variable bindings.
What is really different in Version 2 is security. The header in Version 2 messages is often called a wrapper. This wrapper includes authentication and privacy information in the form of destination and source "parties."
A party is an SNMP Version 2 entity that can initiate or receive Version 2 communication, and each party consists of a single, unique party identity, a logical network location, one authentication protocol and one privacy protocol. In addition to destination and source parties, the wrapper specifies a context - the managed objects visible to an operation.
SNMP Version 1 specified that the protocol operates over UDP and IP. The Version 2 specification is far more complex: The transport mapping document (RFC 1449) defines SNMP over other transport protocols, including OSI Connectionless Network Service (CLNS), AppleTalk's Datagram Delivery Protocol and Novell's Internet Packet Exchange, and includes instructions on how to provide an SNMP Version 1 proxy.
Well folks, that's all we have time for! On our show next week we'll feature the Management Information Base, the data structure to which SNMP requests relate. So tune in next week, same journal, same column. Until then, this is Gearhead saying goodbye.
Show your lineup to gearhead@gibbs.com.
RELATED LINKS
Comments and suggestions to gh@gibbs.com.
Gibbs Forum
The place to discuss Gibbs's columns.
Check out this week's edition of
Backspin for more musings from Gibbs.
Logging messages with SNMP
Part 1 of the series. Network World, 07/01/02.
|
|
|
|||||

