Network Sonar to Detect which poller can monitor

Currently, when we use the network sonar feature, we need to tell SolarWinds which poller to use. While this is good, sometimes this can be a bit cumbersome -- especially if we are dealing with multiple SolarWinds pollers. After all, perhaps some of the devices are set to allow snmp scanning from one poller but not the other. Thus, we may end up having to do a bit of trial and error until we find which devices respond to which SolarWinds pollers. Do you see where I am going with this?

I propose for a checkbox that will tell SolarWinds to try all pollers on the device and to chose the first one that responds via SNMP. That would allow us to have tens or even hundreds of devices discovered and added via a single job. Nice, huh? And, of course, we can always re-assign a device to another poller, if we want to balance the load on our SolarWinds servers.

If you like this idea, I'd very much appreciate your support for this. Have a great day, everyone!!!

Find more posts tagged with

monitoring_nodes

npm monitoring

network sonar discovery

add_nodes

Status: None

Comments

HerrDoktor

"After all, perhaps some of the devices are set to allow snmp scanning from one poller but not the other." - I do see that your feature-requst really helps with this, but this is symptom treating, not root-cause treating.

I tend to be yery radical with device owners/responsible teams. Configure your devices and I can monitor them. Don't configure them and live with the consequences. I write "work instructions" for the monitoring systems with my clients to distribute to the device-owners and we are done. Internal audits always has been on our side when there were devices that haven't been monitored and caued issues.

When you are in a larger organization and you want to "save everyone" by bending your product that it fits everyone you will most likely go crazy.

mr.e

You make a very good point, HerrDoktor. Maybe I am partly enabling lazy behaviour for our IT folks. Indeed I wish that all my users took ownership and did their part Still, on the other side, I am thinking a bit about ourselves (SolarWinds admins too).

rschroeder

I like part of this idea, and I'd modify it such that SW would automatically choose the APE based on some criteria with the discovered client. I break my network equipment down by region and site-name; it would be nice if I had a way to tell NPM that new nodes with specific characters in their names must be managed by a specific poller.

yaquaholic

If this were also a poller test function, testing each node, from each poller and reporting back those that fail any communication.

Effectively something like a port scanner run on each poller, that can extract a list of nodes from the Orion database and populate back a table of its findings.

From this we could then see where the network security/configuration is stopping things from working.

This should be part of the node adding process, so that Orion checks that the newly added node can be polled from primary/secondary (under HA) and from each APE.

To have this as retrospective tool (to review those already added to the DB), would also be very handy.

We operate one Orion platform for over 40 customers, so reviewing the ACLs is not a task the network guys undertake without good reason and we frequently are unaware that ACLs are not correctly in place, until something goes wrong and we start shifting the polling load around.

mr.e

yaquaholic, I must say I like your idea a lot. I think it is better than what I proposed. I can already picture running a test from all our six APE's simultaneously and let SolarWinds tell us which devices respond to each APE. Also, this test should be smart enough to tell us which polling methods are accepted for each node (i.e. SNMPv1, SNMPv2, SNMPv3, WMI, agent, etc.). Finally,this should produce a report that we can then share w/our users. With the report, we can tell our users which devices need configuration in order to allow polling from all our APE's. No more guessing nor running discoveries for each of our six APE's. Nice!!!

Also, your idea would help us stop enabling the few lazy ones who do not bother to configure their devices properly. In other words, we would no longer be enablers which is one of the points that HerrDoktor was trying to make -- and he is right.

So, yaquaholic, this is your idea. So, I don't want to "steal your thunder" here. Bottom line, if you submit a feature request on it, you'll have my vote.

rschroeder

My environment has grown from three polling engines to seven in the last ten months, and when we added UDT I had to stop using snmp-v3 to poll/monitor switches and move back to unsecure snmp-v2c to get the benefits from UDT.

My solution, which you might consider adopting, was to simply build an ACL that only allows my switches to respond to a specific snmp-v2c string if it comes from defined sources like APE's. All other snmp must be v3. And the sources for that traffic are also restricted.

With this kind of ACL in place it no longer matters (from your switches' point of view) which poller is trying to talk to a given switch, which sounds like a convenient improvement to your environment that addresses your challenges.

This also makes it MUCH easier to move elements/switches/routers between APE's to better balance the load on each APE.

I wrote the ACL, tested it on a number of switches, pushed it out using NCM, and then began polling 800+ switches with snmp-v2c. The result was perfect, plus I started getting all the UDT information we need for our CMDB.

On Cisco switches, the ACL looks like this

access-list xx permit host x.x.x.x

(duplicate the above line as many times as needed to list all the ip addresses of hosts that must be allowed to use snmp-v2c and a specific string)

access-list xx deny any (this needs to be the last line in the ACL)

Then the ACL needs to be applied to the community string:

snmp-server community abcde ro xx (where "xx" is the number of the access list, and "abcde" is the snmp-v2 community string)

Notice that the community string is "ro" or "read-only". You have the option to make it read-write, but I don't recommend it since it can be problematic to track down who made changes via an snmp tool when they can use snmp read-write privileges.

You can include as many host IP addresses in the ACL as you wish--all of your APE's, maybe your team's workstations (they need to be using fixed or reserved IP addresses so they don't change).

Swift packets!

Rick Schroeder

Quick Links

All Categories
Recent Posts
Activity
Unanswered
Groups
Help
Best Of