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變量值。