FEATURE REQUEST - SNMP Timeout to higher than 10 seconds

Hello,

We have Cisco Nexus equipement and we had a lot of snmp timeout. After working with Cisco for several days, the conclusion is that Nexus equipement can take up to 20 seconds to response to SNMP request and *this is normal behavior for Nexus*.

The problem is, in NPM, the maximum value is 10 seconds (10 000 millisecond).

In UDT, the maximum timeout is 30 seconds. It would be nice if all solarwinds products had the same maximum snmp timeout.

This timeout should be higher than 10 seconds like 30 or 60 seconds.

This is very important for monitoring Nexus equipment.

thank you

Find more posts tagged with

prodfr

Status: None

Comments

rschroeder

That's a surprise, and a disappointment in Cisco. For as powerful as Cisco claims they are, and for being data center solutions, I expect them to respond in just a few milliseconds from any of my sites.

The latency between my most distant site and my Nexus gear is 11 ms round trip. I want Nexus to respond to snmp queries equally fast.

therealdax

Just had SolarWinds close a case for a customer with this exact issue.

Unfortunately the case was closed with no resolution as the timeout is on Cisco's side even though the SolarWinds server is plugged directly into the Nexus.

rschroeder

If your shop is big enough, use Solarwinds NAM, you can have up to 25 pollers. then locate them strategically so snmp won't time out.

deverts

All,

I realize this is an OLD (4.5 years) post that seems to have been revisited, but I felt it necessary to "add my 2 cents." It has been my experience that this is not a Nexus issue, the Nexus is doing it's job protecting itself (at least in newer code). The CoPP (Control Plane Policer) is protecting itself from excessive Management traffic (SNMP, ICMP, SSH, etc.). By default Nexus comes with a strict CoPP applied (copp profile strict), this blocks all types of management traffic when it sees excessive amounts of it. I've seen this happen multiple times for the same reason: Monitoring software configured to scan all the RFC1918 scopes, instead of only those networks you actually have configured. In a smaller network, it's not bad...but I've seen printer management software set up by vendors cause all manner of issues in a moderately sized environment. With NTA installed and the Nexus configured, you don't need the following but:

The fix has always been, login to the Nexus when it's occurring and run:

ethanalyzer local interface inband limit-captured-frames 50000

There are other options, but this will immediately display the packets and you can sift through the output for the root cause.

rschroeder

I'm fighting that last issue today as a recently-deployed printer management/discovery tool turns several thousand printers into DDOS tools for scanning subnets via snmp.

Ugh! I sympathize with the printer group for wanting to have a simple and complete network-based management tool. But misconfiguring it to hit not only all RFC 1918 addresses, but ALL IPv4 addresses is a big mistake.