Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials

SNMPv3 and Foundry

Anyone else here use SNMPv3 on Foundry devices? We have to restart the NPM service daily as we are losing graphing of the interfaces and the CPU utilization.

Running the same SNMP query from the command prompt shows that the boxes are all still responding to snmp requests.

Monitoring with SNMPv2c during the same interval does not fail.

DES and AES encryption both eventually result in no information being graphed. Solarwinds support has not come up with any theories on why this might be happening. Has anyone else seen this or know of a potential workaround?

Find more posts tagged with

Accepted answers

All comments

bshopp

Are you using SNMPv3 to monitor any other devices/vendors or just Foundry?

bwiechman

Just Foundry. The majority of our devices do not support v3.

edupont

I just ran into this problem myself. What I found was that Foundry has apparently implemented the v3 stack with an error in how they deal with the snmpEngineTime. The v3 spec says that it is maintained in seconds but the Foundry switches maintain it in tenths of seconds. This causes a "not in time window" error because the authoritative server (the switch) gets out of sync with the non-authoritative server (our app). The reason it always works from the command prompt is that the response is almost instantaneous and the non-authoritative server (the snmp tool) initializes the value each time the command is issued. I haven't discovered a workaround yet other than initializing the application each time I issue a get or set, but that is not really a workable solution for us.

bwiechman

That might explain it. What I saw was that the Foundry switches would typically work for some period of time, but then eventually fail. Typically this occurred sometime within a 4-12 hour span. Most of the devices would simply fail to graph properly in the NPM at that time, while others would be graphed intermittently.

Not sure if that entirely fits the explanation you describe.

After some pain I do have a working patch for NPM that appears to resolve this issue. If you reference case #107672 they might be able to push that build to you as well.