GETBULK - Revision history

Wes at 05:11, 19 July 2011

2011-07-19T05:11:29Z

Wes at 05:11, 19 July 2011

2011-07-19T05:11:17Z

Wes: Created page with "{{protocol|GETBULK|utility=snmpgetbulk|ref=3416}} The '''GETBULK''' operation merely requests a number of GETNEXT responses to be returned in a single packet rather than hav..."

2011-07-19T05:06:00Z

Created page with "{{protocol|GETBULK|utility=snmpgetbulk|ref=3416}} The '''GETBULK''' operation merely requests a number of GETNEXT responses to be returned in a single packet rather than hav..."

New page

{{protocol|GETBULK|utility=snmpgetbulk|ref=3416}}

The '''GETBULK''' operation merely requests a number of [[GETNEXT]] responses to be returned in a single packet rather than having to issue multiple [[GETNEXT]]s to retrieve all the data that is needed. This is generally more efficient with network bandwidth and also allows an agent to optimize how it retrieves the data from the [[MIB]] instrumentation. However, there is also the possibility of an ''overrun'', which means to get back more data than was needed because parts of the MIB tree that wasn't required were returned as well.

The expected returned [[PDU]] will be a [[RESPONSE]], although a [[REPORT]] may be issued as well in certain [[SNMPv3]] circumstances.

== Parameters ==

The '''GETBULK''' operation takes two parameters:

;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.

← Older revision		Revision as of 05:11, 19 July 2011
Line 1:		Line 1:
−	{{protocol\|GETBULK\|utility=snmpgetbulk\|ref=3416\|snmp=~~v2c~~-3}}	+	{{protocol\|GETBULK\|utility=snmpgetbulk\|ref=3416\|snmp=2c-3}}

	The '''GETBULK''' operation merely requests a number of [[GETNEXT]] responses to be returned in a single packet rather than having to issue multiple [[GETNEXT]]s to retrieve all the data that is needed. This is generally more efficient with network bandwidth and also allows an agent to optimize how it retrieves the data from the [[MIB]] instrumentation. However, there is also the possibility of an ''overrun'', which means to get back more data than was needed because parts of the MIB tree that wasn't required were returned as well.		The '''GETBULK''' operation merely requests a number of [[GETNEXT]] responses to be returned in a single packet rather than having to issue multiple [[GETNEXT]]s to retrieve all the data that is needed. This is generally more efficient with network bandwidth and also allows an agent to optimize how it retrieves the data from the [[MIB]] instrumentation. However, there is also the possibility of an ''overrun'', which means to get back more data than was needed because parts of the MIB tree that wasn't required were returned as well.

← Older revision		Revision as of 05:11, 19 July 2011
Line 1:		Line 1:
−	{{protocol\|GETBULK\|utility=snmpgetbulk\|ref=3416}}	+	{{protocol\|GETBULK\|utility=snmpgetbulk\|ref=3416\|snmp=v2c-3}}

	The '''GETBULK''' operation merely requests a number of [[GETNEXT]] responses to be returned in a single packet rather than having to issue multiple [[GETNEXT]]s to retrieve all the data that is needed. This is generally more efficient with network bandwidth and also allows an agent to optimize how it retrieves the data from the [[MIB]] instrumentation. However, there is also the possibility of an ''overrun'', which means to get back more data than was needed because parts of the MIB tree that wasn't required were returned as well.		The '''GETBULK''' operation merely requests a number of [[GETNEXT]] responses to be returned in a single packet rather than having to issue multiple [[GETNEXT]]s to retrieve all the data that is needed. This is generally more efficient with network bandwidth and also allows an agent to optimize how it retrieves the data from the [[MIB]] instrumentation. However, there is also the possibility of an ''overrun'', which means to get back more data than was needed because parts of the MIB tree that wasn't required were returned as well.