0
5.2kviews
List and explain SNMPv2 command.
1 Answer
1
78views

SNMPv2 Protocol Operations:

i. There are seven protocol operations in SNMPv2. The messages, get-request, get-next-request, set-request, and get-response, are in both SNMP1 and SNMPv2 versions and operate in a similar fashion.

ii. The two additional messages that are in SNMPv2, which are not in version 1, are the GetBulkRequest and InformRequest.

iii. The command, get-bulk-request, is an enhancement of get-next request and retrieves data in bulk efficiently.

GetBulkRequest PDU Operation:

i. The get-bulk-request operation is added in SNMPv2 to retrieve bulk data from a remote entity. Its greatest benefit is in retrieving multiple rows of data from a table.

ii. The basic operation of get-bulk-request is the same as get-next-request.

iii. The data structure of the response for the get-bulk-request operation differs from other get and set operations.

iv. Successful processing of the get-bulk-request produces variable bindings (larger array of Var-BindList) in the response PDU, which is larger than that contained in the corresponding request.

v. Thus, there is no one-to-one relationship between the VarBindList of the request and response messages. Figure 14 shows a conceptual MIB to illustrate the operation of get-next-request and get-bulk-request.

MIB for Operation Sequences

MIB for Operation Sequences

vi. The sequence starts with a get-request message from the manager process with a VarBindList array of two scalar variables A and B. It is subsequently followed by the get-next-request message with three columnar OBJECT IDENTIFIERS T.E.1, T.E.2, and T.E.3.

vii. The get-response returns the first instance values T.E.1.1, T.E.2.1, and T.E.3.1. The sequence of operation continues until fourth instance is retrieved. The last get-next-request message with the OBJECT IDENTIFIERS T.E.1.4, T.E.2.4, and T.E.3.4 generates the values T.E.2.1, T.E.3.1, and Z.

viii. This is because there are no more instances of the table.

ix. It retrieves the three objects, which are logically the next lexicographically higher objects—namely T.E.2.1 (next to T.E.1.4), T.E.3.1 (next to T.E.2.4), and Z (next to T.E.3.4).

x. The manager would stop the sequence at this message. However, if it continues the operation, it would receive a noSuchName error message.

GetBulkRequest Command:

i. One of the major enhancements SNMPv2 provides is the GetBulkRequest PDU. Its purpose is to minimize the number of protocol exchanges required to retrieve a large amount of management information.

ii. The GetBulkRequest PDU allows SNMPv2 manager to request that the response be as large as possible given the constraints on message size.

iii. The GetBulkRequest operation uses the same selection principle as the GetNext-Request operation; that is, selection is always of the next object instance in lexicographic order.

iv. The difference is that, with GetBulkRequest, it is possible to specify that multiple lexicographic successors be selected.

v. In essence, the GetBulkRequest operation works in the following way.

vi. The GetBulkRequest includes a list of (N + R) variable names in the variable-bindings list. For each of the first N names, retrieval takes place as for GetNextRequest.

vii. That is, for each variable in the list, the next variable in lexicographic order plus its value are returned; if there is no lexicographic successor, and then the named variable and a value of endOfMibView are returned.

viii. For each of the last R names, multiple lexicographic successors are returned.

ix. The GetBulkRequest PDU has two fields not found in the other PDUs: non-repeaters and max- repetitions. The non- repeaters field specifies the number of variables in the variable-bindings list for which a single lexicographic successor is to be returned.

GetBulkRequest Command

GetBulkRequest Command

x. The max-repetitions field specifies the number of lexicographic successors to be returned for the remaining variables in the variable-bindings list. To explain the algorithm, let us define the following:

L = number of variable names in the variable-bindings field of the GetBulk-Request PDU

N = the number of variables, starting with the first variable in the variable-bindings field, for which a single lexicographic successor is requested

R = the number of variables, following the first N variables, for which multiple lexicographic successors are requested

M = the number of lexicographic successors requested for each of the last R variables

The following relationships hold:

$N = MAX [MIN (non- repeaters, L). 0)$

$M = MAX (max-repetitions, 0)$

$R = L — N$

The effect of the MAX operator is that if the value of either non-repeaters or max-repetitions is less than zero, a value of 0 is substituted.

SNMPv2 -Trap and InformRequest PDU Operations:

i. The SNMPv2-Trap PDU performs the same function as in version1. A Trap is defined by using a NOTIFICATION-TYPE macro.

ii. If the macro contains an OBJECTS clause, then the objects defined by the clause are in the variable bindings in the order defined in the clauses.

iii. An InformRequest PDU is generated by a manager (in contrast to trap generated by an agent) to inform another manager of information in its MIB view.

iv. While a trap is received passively by a manager, an InformRequest generates a response in the receiving manager to send to the sending manager.

Please log in to add an answer.