Polling
The network management system periodically queries the network device for information.
The advantage is the network management system is in control and knows the ‘big picture’.
The disadvantage is the amount of delay from when an event occurs to when it’s noticed.
If interval is too short, network bandwidth is wasted.
Oppositely long interval, response to events is too slow.
Walk
Reads a portion of the MIB tree from a device.It is completed by the operations get/getNext/getBulk
GetBulk
SNMPv2 defines the get-bulk operation, which allows a management application to retrieve a large section of a table at once. The standard get operation can attempt to retrieve more than one MIB object at once, but message sizes are limited by the agent's capabilities. If the agent can't return all the requested responses, it returns an error message with no data. The get-bulk operation, on the other hand, tells the agent to send as much of the response back as it can. This means that incomplete responses are possible. Two fields must be set when issuing a get-bulk command: nonrepeaters and max-repetitions. Nonrepeaters tells the get-bulk command that the first N objects can be retrieved with a simple get-next operation. Max-repetitions tells the get-bulk command to attempt up to Mget-next operations to retrieve the remaining objects.
Assume we're requesting three bindings: sysDescr, ifInOctets, and ifOutOctets. The total number of variable bindings that we've requested is given by the formula N + (M * R), where N is the number of nonrepeaters (i.e., scalar objects in the request -- in this case 1, because sysDescr is the only scalar object), M is max-repetitions (in this case, we've set it arbitrarily to 3), and R is the number of nonscalar objects in the request (in this case 2, because ifInOctets and ifOutOctets are both nonscalar). Plugging in the numbers from this example, we get 1 + (3 * 2) = 7, which is the total number of variable bindings that can be returned by this get-bulk request.
The Net-SNMP package comes with a command for issuing get-bulk queries. If we execute this command using all the parameters previously discussed, it will look like the following:
$ snmpbulkget -v2c -B 1 3 linux.ora.com public sysDescr ifInOctets ifOutOctets
system.sysDescr.0 = "Linux linux 2.2.5-15 #3 Thu May 27 19:33:18 EDT 1999 i686"
interfaces.ifTable.ifEntry.ifInOctets.1 = 70840
interfaces.ifTable.ifEntry.ifOutOctets.1 = 70840
interfaces.ifTable.ifEntry.ifInOctets.2 = 143548020
interfaces.ifTable.ifEntry.ifOutOctets.2 = 111725152
interfaces.ifTable.ifEntry.ifInOctets.3 = 0
interfaces.ifTable.ifEntry.ifOutOctets.3 = 0
Since get-bulk is an SNMPv2 command, you have to tell snmpgetbulk to use an SNMPv2 PDU with the -v2c option. The nonrepeaters and max-repetitions are set with the -B 1 3 option. This sets nonrepeaters to 1 and max-repetitions to 3. Notice that the command returned seven variable bindings: one for sysDescr and three each for ifInOctets and ifOutOctets.
Non-repeaters and maxRepetitions
They are used in getBulk.
Definition of Non-repeaters:- The Non-repeater specifies the number of variables in the variable-bindings list for which a single OID (lexicographic successor) is to be returned.
Definition of maxRepetitions :- The max-repetitions specifies the number of OIDs (lexicographic successor)to be returned for the remaining variables (total variables - nonrepeaters)in the variable bindings list.
For clearer understanding, Let us assume Nonrepeater=4, and Max-Repetitions=3;
If get values with OID lists which are .1.3.6.1.2.1.11.1.0, .1.3.6.1.2.1.11.2.0 , .1.3.6.1.2.1.11.3.0, .1.3.6.1.2.1.11.4.0, .1.3.6.1.2.1.11.5.0, .1.3.6.1.2.1.11.6.0 , and the method is getNext.
NonRepeater value is 4. So the first four variable returns a single lexicographic successor.
Request OIDs ----> Response
.1.3.6.1.2.1.11.1.0 ---> .1.3.6.1.2.1.11.2.0 and its value
.1.3.6.1.2.1.11.2.0 ---> .1.3.6.1.2.1.11.3.0 and its value
1.3.6.1.2.1.11.3.0 ---> .1.3.6.1.2.1.11.4.0 and its value
.1.3.6.1.2.1.11.4.0 ---> .1.3.6.1.2.1.11.5.0 and its value
The subsequent OIDs in the OIDs list to be returned the number of max-repetitions lexicographic successor.
Request ---> Response
.1.3.6.1.2.1.11.5.0 --> .1.3.6.1.2.1.11.6.0, .1.3.6.1.2.1.11.7.0, .1.3.6.1.2.1.11.8.0 and its value.
Request ---> Response
.1.3.6.1.2.1.11.6.0 --> .1.3.6.1.2.1.11.7.0, .1.3.6.1.2.1.11.8.0 , .1.3.6.1.2.1.11.9.0 and its value.
So the response will be,
.1.3.6.1.2.1.11.2.0 and its value
.1.3.6.1.2.1.11.3.0 and its value
.1.3.6.1.2.1.11.4.0 and its value
.1.3.6.1.2.1.11.5.0 and its value
.1.3.6.1.2.1.11.6.0 and its value
.1.3.6.1.2.1.11.7.0 and its value
.1.3.6.1.2.1.11.7.0 and its value
.1.3.6.1.2.1.11.8.0 and its value
.1.3.6.1.2.1.11.8.0 and its value
.1.3.6.1.2.1.11.9.0 and its value
EngineID in V3
USM用snmpEngineID标识SNMPv3实体，SNMPv3实体可以是一个运行在被管设备上的管理代理，也可以是一个管理进程。为了防范报文重放、延迟和重定向，SNMPv3定义了权威SNMP引擎，由参与通信的sNMP引擎中的一个充当权威引擎。当SNMP操作(如Get，GetNeXt，GetBulk，Set或Inform)需要响应报文时，则接收报文并产生响应的SNMP引擎是权威引擎。当SbMP操作不需要响应报文(如SNMPv2-Trap，Response或Report)时，则发送报文的SNMP引擎是权威引擎。
非权威引擎与权威引擎互相通信必须共亨用户的鉴别密钥和加密密钥。为了安全，USM中非权威引擎不保存密钥，只在权威引擎中预存密钥。非权威引擎上的密钥在需要时由操作用户输入口令临时生成，权威引擎中则要预先根据用户口令生成并保行密钥，整个网络上只此一份。权威引挚上的这个密钥称为本地化密切。用户保存的只是口令，权威引擎保存的是用户的本地化密钥。在权威引擎上的密钥还有一个本地化过程。
在与另一个SNMP引擎通信之前必须先获得对方的引擎标识snmpEngineID。首先非权威引擎向权威引擎发送一个请求报文，权威引擎收到该请求后在响应报文ReportPDU中填写本地的snmpEngineID。
若需要建立可信的通信，则非权威引擎还要与权威引擎建立时间同步。这是通过向权威引擎发送鉴别请求报文实现的；权威引擎在响应报文中填写本地引擎的最新snmpEngineBoots和snmpEngineTime变量值。