Unsolved
This post is more than 5 years old
13 Posts
0
2586
August 14th, 2012 12:00
Discovery errors: Agent loops in response to GET_NEXT
We are having a discovery problem with Brocade/Foundry switches. On certain model switches, we get a discovery error of “SWFE-E-ELOOP-Agent loops in response to GET_NEXT: Agent: 10.2.6.10, First OID: .1.3.6.1.2.1.17.4.3.1.2.188.48.91.195.241.165“, with a different OID every time.
An snmpwalk of the switch fails with the following, also with different OIDs:
Error: OID not increasing:
>>>>>> SNMPv2-SMI::mib-2.17.4.3.1.1.212.190.217.159.4.181
>>>>>>> = SNMPv2-SMI::mib-2.17.4.3.1.1.0.24.139.90.156.245
The vendor is recommending that we use the “-Cc” flag. They reference the man page for snmpwalk:
“Some agents (LaserJets are an example) return OIDs out of order, but
can complete the walk anyway. Other agents return OIDs that are out of
order and can cause snmpwalk to loop indefinitely. By default, snmpwalk
tries to detect this behavior and warns you when it hits an agent
acting illegally. Use -Cc to turn off this behavior as -Cc Do not check
whether the returned OIDs are increasing.”
Is there a way to do this in ItOps IP 8.1.2?
Btw, I have tried SNMP v1 and v2c. Both have the same results.
Thanks.
Steve
SteveLee2
13 Posts
0
August 22nd, 2012 07:00
The question really pertains to discoveries in Smarts. Is there a way to do this in discovery.conf or with sm_tpmgr?
bkuhhirte
52 Posts
0
August 29th, 2012 18:00
The short answer is no. For the sm_snmpwalk utility there is some logic to try and skip ahead to the next branch of the SNMP MIB, but during discovery, we are attempting to probe specific leaf entries - not just get the full tree.
I would suggest that your course of action here is to talk to support to change the certification for the device which will avoid the problematic spots in the MIB.