Difference between revisions of "GETNEXT"
Line 1: | Line 1: | ||
− | {{protocol|GETNEXT|utility=snmpgetnext|ref=3416}} | + | {{protocol|GETNEXT|utility=snmpgetnext|ref=3416|snmp=1-3}} |
The '''GETNEXT''' command (GetnextRequest) requests a list of instances from a remote entity, but expects the '''next''' variable in the tree back. If a '''GETNEXT''' is issued on an object that does not exist, the agent MUST return the next instance in the [[MIB]] tree that does exist. If a '''GETNEXT''' is issued for an object that does exist, the agent must skip this entry and find the next instance in the MIB tree to return. If no more MIB objects exist in the MIB tree then an ''End of MIB'' exception is returned. | The '''GETNEXT''' command (GetnextRequest) requests a list of instances from a remote entity, but expects the '''next''' variable in the tree back. If a '''GETNEXT''' is issued on an object that does not exist, the agent MUST return the next instance in the [[MIB]] tree that does exist. If a '''GETNEXT''' is issued for an object that does exist, the agent must skip this entry and find the next instance in the MIB tree to return. If no more MIB objects exist in the MIB tree then an ''End of MIB'' exception is returned. |
Latest revision as of 05:12, 19 July 2011
SNMP Protocol Operation | |
GETNEXT | |
SNMP Versions: | SNMPv1-3 |
---|---|
CLI Utility: | snmpgetnext |
Protocol List: |
The GETNEXT command (GetnextRequest) requests a list of instances from a remote entity, but expects the next variable in the tree back. If a GETNEXT is issued on an object that does not exist, the agent MUST return the next instance in the MIB tree that does exist. If a GETNEXT is issued for an object that does exist, the agent must skip this entry and find the next instance in the MIB tree to return. If no more MIB objects exist in the MIB tree then an End of MIB exception is returned.
The expected returned PDU will be a RESPONSE, although a REPORT may be issued as well in certain SNMPv3 circumstances.
snmpwalk uses GETNEXTs!
The snmpwalk application actually uses GETNEXT operations and continually asks for the next variable after the last one until it meets an end condition, which is either because it reached the end of the MIB tree or because the next OID returned was after the requested OID to be walked.