Community in read only mode June 18 & 19
This community will be set in READ ONLY mode for a while on Tuesday June 18 into Wednesday June 19 while we import content and users from our Micro Focus Forums community site. MORE INFORMATION
David Campeau Absent Member.
Absent Member.
176 views

snmp error status TOO_BIG

There's an issue I'm seeing on some Cisco ASA's that are showing Malfunctioning Agent. AFter some research and opening a ticket, the issue is with the way NNM snmp polls.  The work around I was given deals with the following KM -

https://softwaresupport.hp.com/group/softwaresupport/search-result/-/facetsearch/document/KM1302980

 

The prolem with the KM is with 'zMaxOIDPerRequest' variable.  After some research zMaxOIDPerRequest deals with a competing monitoring software (zeonoss) where you can go in and change the zMaxOIDPerRequest in the gui (Not Cisco).

 

I've talked with the firewall engineers, and they don't seem to know the command or part of the config where they can tune the SNMP agent to allow the additional OID's to be polled in 1 snmpget.

 

Does anyone know where or how to tune the SNMP agent on a Cisco ASA?

 

Thanks,

 

 

David

0 Likes
14 Replies
Frequent Contributor.. Oleg Gawrilov Frequent Contributor..
Frequent Contributor..

Re: snmp error status TOO_BIG

If you disable bulkrequest in communication setting for that device NNM should not question multiple OIDs at once.

 

0 Likes
David Campeau Absent Member.
Absent Member.

Re: snmp error status TOO_BIG

Essentially this issue occours because NNM requests 6 or more OIDs at one time, and some devices refuse to repond to that many at once. HP has put the ball into the other court by saying Cisco needs to fix this issue, and recommends  the 'zMaxOIDPerRequest' parameter be changed on the Cisco device side. However, little does HP know that the 'zMaxOIDPerRequest' is of a competitors monitoring tool, that had the same problem, and that 'zMaxOIDPerRequest' is the object to change in the competitor software, so that it polls less OID's and fixes the issue.

 

 After talking to several firewall engineers, there's is no variable that can be adjusted to allow additional OID's to be polled at one time.  Essentially, the only hope of this being cleared up is by a Cisco code update that might happen sometime in the future, and that's still no guarantee to solve the problem.

 

Fortunately, the Firewalls can still be monitored normally, but unfortunately the agent is listed, in NNM, as "Malfunctioning" which appeals to my OCD, and is something I want to go in there a fix, but can't.

 

Best Regards,

 

David

0 Likes
Absent Member.. Walinton Absent Member..
Absent Member..

Re: snmp error status TOO_BIG

Hello David

Thank you for your feedback. Let me investigate this further and get back to you

Regards,

HP Support
If you find that this or any post resolves your issue, please be sure to mark it as an accepted solution.
0 Likes
Absent Member.. Walinton Absent Member..
Absent Member..

Re: snmp error status TOO_BIG

Hi David,

I continue to investigate this problem. Please expect an update from me this coming week

Thanks

HP Support
If you find that this or any post resolves your issue, please be sure to mark it as an accepted solution.
0 Likes
Absent Member.. Walinton Absent Member..
Absent Member..

Re: snmp error status TOO_BIG

Hello David

 

Thanks to your valuable feedback we have investigated this problem and have retired the knowledge document that was describing this problem.

 

I have submitted an Enhancement Request (ER) "A product-wide property to restrict the number of OIDs per request" for our RnD team to follow up on this issue.

 

I sincerely apologize for any confusion that this may have caused, and I thank you for bringing this up to our attention.

 

Within a week or so, the ER I submitted will have a public link, which I will share here for you to be able to follow up on this request.

 

 

Regards,

HP Support
If you find that this or any post resolves your issue, please be sure to mark it as an accepted solution.
0 Likes
David Campeau Absent Member.
Absent Member.

Re: snmp error status TOO_BIG

Thank you very much for following up with this issue and going above and beyond.

 

Best Regards,

 

David Campeau

0 Likes
Absent Member.. Walinton Absent Member..
Absent Member..

Re: snmp error status TOO_BIG

Hello David,

Thanks for your response.

 

There is actually more. As we continue to investigate this issue we have found out that NNMi does have code to handle this SNMP error code. Basically, NNMi will reduce the number of varbinds included in the request by 1/3 every time that we get this TOO_BIG error code, if using SNMP-get request (as opposed to GETBULK).

 

So, in your case, NNMi should have tried to get first 6 varbinds, it results in the TOO_BIG error code, then NNMi should have attempted 4 varbinds (6 - 6*/3), and so on until we get succesfull responses for all the needed varbinds.

 

We're now wondering, why wasn't this the case, or was it and there is something else that we do not know about?

 

The ER will stand, as I am requesting for a property to control manually the amount of varbinds to be used, but we'd like to investigate this problem further to see why isn't this working as coded.

 

Would you be willing to work with us to get this sorted out?

 

We will need NNMi tracing and packet captures.

 

Thanks much,

Walinton

 

HP Support
If you find that this or any post resolves your issue, please be sure to mark it as an accepted solution.
0 Likes
Absent Member.. Walinton Absent Member..
Absent Member..

Re: snmp error status TOO_BIG

Hello David

 

Here the link to the ER https://softwaresupport.hp.com/group/softwaresupport/search-result/-/facetsearch/document/LID/QCCR1B134985

The link should be accesible within a week or so.

 

I am still interested in following up with the issue, so please let us know if you can work with us to sort this out

 

Thanks much

HP Support
If you find that this or any post resolves your issue, please be sure to mark it as an accepted solution.
0 Likes
David Campeau Absent Member.
Absent Member.

Re: snmp error status TOO_BIG

Yes, I'll be available when the time comes.

 

Please contact me when ready.

 

Best Regards.

 

David

0 Likes
Absent Member.. Walinton Absent Member..
Absent Member..

Re: snmp error status TOO_BIG

David,

We're ready when you are.

If you worked on this issue in the past, can you share the case number? I will use the info in the case to get in touch with you privately

Thanks much,

HP Support
If you find that this or any post resolves your issue, please be sure to mark it as an accepted solution.
0 Likes
Micro Focus Expert
Micro Focus Expert

Re: snmp error status TOO_BIG

Hello David,

 

I agree with you. The doument looks to me misleading. By default NNMi uses SNMP Bulk requests during discovery. Some devices may not properly support Bulk requests. In such case you could configure a special monitoring for this device instructing NNMi to not use Bulk. Sometimes a device may porperly reply with SNMP v1 but not SNMP v2. All depends how device behaves.  Which of the commands below actually work ?

 

nnmsnmpget.ovpl -v 1 <hostname> sysObjectID.0 sysUpTime.0 sysContact.0 sysName.0 sysLocation.0

 

nnmsnmpget.ovpl -v 2c <hostname> sysObjectID.0 sysUpTime.0 sysContact.0 sysName.0 sysLocation.0

 

If the first one works but not the second one you can try SNMPv1. If the second one also works try to disable Bulk requests to see if it helps. If none of the above commands work then I am afraid you would need to consult the vendor for a solution. Perhapse the device needs a firware update.

 

Best regards,

Sergey Pankratov
NNMi Support

The views expressed in my contributions are my own and do not necessarily reflect the views and strategy of HPE
If you find this or any post resolves your issue, please be sure to mark it as an accepted solution.
If you are satisfied with anyone’s response please remember
to give them a KUDOS and show your appreciation
0 Likes
Absent Member.. Walinton Absent Member..
Absent Member..

Re: snmp error status TOO_BIG

Hello Sergey


Thanks for your response.

 

This is a problem that does not seem to be related to the SNMP version and/or the SNMP get method (bulk vs not bulk). Basically, NNMi has code to handle the SNMP_TOO_BIG error code and on this case, it seems that it did not handle it properly.

 

This only happens to SNMP-get requests (as the TOO_BIG error is defined for this method) and while we did not try the version, it could probably be the same. I agree with you that a solution from the Vendor can be an option and that was initially suggested, but then after investigating with the Lab, we found out that we should be able to handle the TOO_BIG error code. 

 

The idea of working with David is to be able to troubleshoot this problem and hopefully determine if NNMi was properly handling the error code and something else happened, or if we have room for improvement here.


Thanks a lot!

HP Support
If you find that this or any post resolves your issue, please be sure to mark it as an accepted solution.
0 Likes
David Campeau Absent Member.
Absent Member.

Re: snmp error status TOO_BIG

This is something I'm willing to work on.. Sorry, I haven't subscribed to this thread, so some time has gone by before I checked back.

 

What can I do to help?

 

Thanks,

 

David

0 Likes
Highlighted
Absent Member.. Walinton Absent Member..
Absent Member..

Re: snmp error status TOO_BIG

David,

 

We will need to enable tracing and collect some data, let me send you a private message so that we collect the information and once we have some results we can post over here

 

Thanks,

Walinton

HP Support
If you find that this or any post resolves your issue, please be sure to mark it as an accepted solution.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.