If I got a nickel for everytime I’ve seen the symptoms shown below…I could afford to be in the Bahamas right now. But instead, I get the joy of watching all the weather alerts for the state of Maine about the incoming Nor’ Easter. *sigh*
I’m sure many of you may recognize the behavior shown in the above screenshot. You have your devices discovered by Scrutinizer, but there’s no way to know what interface it’s trending because all you see are numbers. This blog may help you out with this issue.
When you discover a device, Scrutinizer attempts to do an SNMP GET to grab definitions for the following:
- Name of the device
- Descriptions of the interfaces
- Port speed associated with each interface.
If you didn’t create a credential in Scrutinizer for your personalized community string prior to the initial discovery, then Scrutinizer would have attempted the discovery using the PUBLIC community string, and you’d be seeing symptoms much like the screenshot shows. Just a bunch of numbers…no details.
If you are certain that you are using the correct community string and yet running an SNMP update still doesn’t work, I would suggest downloading a MIB Browser called GETIF.
GETIF is a really nice 3rd party tool that I use here in the office to diagnose problems such as this.
With GETIF; just provide the IP address of the device in question, the community string that the device should be using and it will test SNMP connectivity using a generic OID.
If GETIF is able to return a value for that OID, then we know the community string that you have defined is correct. Which would turn our focus to Scrutinizer and the credential you created.
If however, GETIF fails to return a value, then we know there’s an issue with the community string that you are using.
Tags: NetFlow, OID, SNMP