10 Replies Latest reply on Dec 12, 2011 11:54 AM by cmellor

    Sonar Discovery


      I've setup a new scheduled discovery and have noticed that I must select a polling engine.  The problem I've come across is that my scanned subnet is split between two different pollers.  So I have devices split on different pollers.  When the scan finishes Orion thinks the device is new because it wasn't on the selected poller.  Is this the intended plan?

        • Re: Sonar Discovery

          Jeff fair question and the answer is yes 

          1. We have many customers who use polling engines to monitor duplicate IP space.  So we require a method to differentiate nodes and we do this by poller

          2. With 10.0 you can use the ignore feature to ignore those same nodes on discovery on one of the polling engines

            • Re: Sonar Discovery


              We're just beginning to experiment with Network Sonar Discovery in v10.  We have the same situation as Jeff.  We have 3 pollers.  For the sake of this discussion, we have a Class B network / 16 with all the nodes split across all 3 pollers (based on a custom property).  We would like to be able to set up a daily scheduled discovery to discover any new nodes.  Am I hearing right, we would need to create and schedule separate discoveries for each poller?  How would we use the ignore feature based on response #2 if the ignore list is global?  From what I can determine the ignore list is global and the nodes are not individually tied/paired to the specific discovery job. 

                • Re: Sonar Discovery


                  • Re: Sonar Discovery


                    Some quick answers.  Let me know if I can elaborate.

                    1. You don't need to schedule discoveries for each poller if you can ping the devices from a single poller.  However, if you will want to import any of the new nodes, then you will want them discovered on the corresponding poller.  It sounds like you might want to depending on how you've split up your nodes across your 3 pollers.

                    2. The ignore list is per engine ID (poller) not by discovery.  Hence, you can ignore different IP addresses, interfaces, and volumes for different pollers.


                      • Re: Sonar Discovery

                        Do you think it is practical for everyone with additional pollers to use scheduled discovery? The answer is simple. The discovery does not work its supposed to be! You should improve it.

                        You have that kind of bugs because you still did not implement  multiple IP support for single node which requested by a lot of customers for a long time.

                        Also I have the similar issue.

                          • Re: Sonar Discovery

                            Last week we added our additional poller. But, like others our discoveries are now useless to me. When it discovers everything twice it makes the list unmanageable. I don't feel that the proper solution is for me to have to ignore everything that has been discovered again simply because it is on the other poller.

                            Can someone fix the software to make a discovery option available so it can determine if the device is being monitored by any of the engines and if not being monitored then show it as a new device? I can see how some customers may like having each poller do its own discovery and show all new devices that each poller finds. That is easy to do if a poller is responsible for an entire subnet. But not all customers work that way.

                    • Re: Sonar Discovery

                      Is this still on-going or has SolarWinds fixed the issue?

                      Installed our new poller last Friday and setup a network sonar scan and its finding duplicates.

                      Also is there some type of automatic load balancing for Pollers?