19 Replies Latest reply on Oct 31, 2011 2:33 PM by mavturner

    Network Discovery improvements

    rgward

      1. Be able to "discover by" Machine Type and Vendor/Manufacturer only. We are a large DOT network with 9 Class B networks. When doing discoveries we have a huge number of nodes discovered as "Unknown" (workstations, etc.). It would be huge improvement to be able to exclude/ignore "unknown" devices as well as known vendor devices such cameras, DVRs, encoders/decoders, etc. when running a discovery. Many of these type devices are supported by 3rd-party contractors in our environment and not the responsibility of our NOC. Unknowns are added clutter to wade through Scheduled Discovery Results.  For example, we would like to be able to discover Cisco devices in one discovery, wireless devices in another, servers in another, UCS in another (saw this suggested in another thread) with all other devices to be ignored and not show on the device discovery results. This could be included in the discovery wizard after specifying the networks.


      2. Also, would like to see on the Import Interfaces page the Machine Type/Vendor the interface is associated with also listed along side each Interface. Presently, when there are multiple Vendor devices discovered, the list of Interfaces to Import shows, for example, multiple Ethernet groups and makes it hard to determine which Ethernet group to import.


      3.  Preserve added SNMP credentials rather than having to start from scratch with Public and Private credentials.  Would prefer to start with no credentials and choose from a drop-down picklist.  Today we have to delete Public and Private with every new discovery job created..


      4. Be able to delete a subnet or seed router from the list when editing a discovery job.


      5. Be able to set discovery frequency to start Once and Custom discoveries to begin at a set time in the future. Only option for Once is "Yes, run this discovery now".


      6.  Be able to Save a Custom or Daily job without having to Schedule. 


      7. When editing a discovery job, be able to advance directly to appropriate step that needs to be edited (ESX, Network, Discovery Setting, Discovery Scheduling). Currently in v10.1, you have to click-thru the entire wizard, for example, to change Network Settings, Discovery Settings or Discovery Scheduling runtime.


      8. Identify poller assigned in Network Sonar Discovery job list and also on each node listed in Scheduled Discovery Results. When running mulitple pollers and discovery jobs for each poller, there is no way to tell which poller disovered a node.


      9. Would like to see discovery job results show count for each discovered Status. For example, Found (22), Changed (13), Found and Changed (35), etc.


      10. Would like to see discovery job perform check against NPM database and identify if node already exists in NPM.


      11.  Revamp the entire Discovery Wizard.  Too many clicks and refreshes to configure or make a simple changes as noted in #6 #7(edited; 1/29/2011).  All the discovery job settings can easily be specified in a single view.


      12. Support for multiple concurrent discoveries per polling engine.  Present design falls short for large networks.


      13. Continuous active discovery with ability to select networks using IP ranges, supernets/subnets, or networks using a seed router, and by discovery criteria noted in #1).


       

        • Re: Network Discovery improvements

          Rgward--

          Thanks for the detail of your feedback. I'll mark for the PM to review.

          M

            • Re: Network Discovery improvements
              rgward

              Sure would like to hear back from the PM on these features.

              • Re: Network Discovery improvements
                extrands

                When can we expect to see some resolutions to these?  Since the scheduled discovery "feature" was added, there have been nummerous threads regarding its functionality (or lack therof), but I have not seen any changes whatsoever make their way into the updates. I would love to have the countless hours I have wasted "ignoring" interfaces returned to me.  Try, just once, discovering a VOIP gateway with 2000+ interfaces.  Then try to ignore all but the 10 or so interfaces you really care about, and you may begin to see why this is an issue that needs attention.  Repeat this process on 20 or so gateways.  You may be looking for different software all together.  A simple "check all" would be a help, then I could at least de-select the 10 I want without having to click on 1990 others, and I cannot imagine that your product developers are so busy they could not incorporate that in the past year and a half. As it is, using discovery has become such a chore that I rarely, if ever use it.  When I do, I regret it.

                A network monitoring system is supposed to simplify monitoring the network.  Orion does that- mostly.  The areas where it fails though are extremely frustrating, as is the process we have to go through to get you to fix those mistakes.  I've seen far too many "I'll mark for the PM to review" and darn few of them seem to result in a timely fix. The more difficult it is to add devices to a system, the less likely it will be used. 

                 

                Steve Extrand

                Sr Network Analyst

                (1) Orion v10 SLX polling engine & Additional Web Server 35500 elements

                (3) Orion v10 SLX polling engine

                (3) NTA v3.7 775 interfaces

                (3) IPSLA SLAX

                  • Re: Network Discovery improvements
                    bshopp

                    This is absolutely on our list of things we want to enhance.  Just a matter of time and priority.  Based on feedback from ya'll, internal stuff etc. we have a large list and we are chugging through it as quickly as we realistically can.

                    In the meantime people have created extension to do some specific use cases, like Interface Discovery by Description or Identify Uplinks

                      • Re: Network Discovery improvements
                        extrands

                        I don't think that an issue that has been around as long as this one has could realistically be called a priority.  If one of your developers has had this on his to-do list since it first came out, you need a new developer, because the job isn't getting done. 

                        I have complained in the past over the rush to add new features over functionality of existing ones.  This too continues to be one of SolarWinds weak points.  The network discovery piece shouldn't have passed beta in its current form. It is functionally impossible to efficiently use in an enterprise.  I'm somewhat appalled that my network management software vendor would point me to a link for downloading a script written by another user, with the "This script is not supported by SolarWinds" warning plastered on it as a potential solution to a design flaw.

                        Don't get my wrong- I love Orion, best platform I've used. I just want to see you stop with the 80/20 development and release fully functional tested features rather than something that promises what we are looking for, then fails once in the real world.  I want the features we purchase to work, and when they don't I expect they, and not additional features, will be the true priority. 

                         

                        Steve Extrand

                        Sr Network Analyst

                        (1) Orion v10 SLX polling engine & Additional Web Server 35500 elements

                        (4) Orion v10 SLX polling engine

                        (3) NTA v3.7 775 interfaces

                        (3) IPSLA SLAX

                        • Re: Network Discovery improvements
                          smartd

                          What I've asked for several times is a requested feature list on your thwack site, and the ability of users to vote on these items.  That lets us see if our issues are popular or unpopular with the community and to know they are on your list.

                          An example i've given before is here: http://yammer.uservoice.com/forums/22714-general-feedback

                        • Re: Network Discovery improvements
                          lhorstma


                          I would love to have the countless hours I have wasted "ignoring" interfaces returned to me.  Try, just once, discovering a VOIP gateway with 2000+ interfaces.  Then try to ignore all but the 10 or so interfaces you really care about, and you may begin to see why this is an issue that needs attention.  Repeat this process on 20 or so gateways. 

                           



                          I have nightmares about VOIP gateways. I'm going to send my therapy bills straight to Brandon... But yeah, what Steve describes is essentially why I would like to have to option to automatically filter out interfaces by name with some wildcards, so all those VOIP interfaces never even pop up on my discovery results. It would make like much easier.

                            • Re: Network Discovery improvements
                              ctopaloglu

                              You expressed my feelings Steve! Congratulations!

                                • Re: Network Discovery improvements
                                  extrands

                                  Unfortunately, the latest RC release (10.2 RC3) of NPM still doesn't include a way to deal with this.  I'm sure that it is "on the developers list", though.  Seems like an exercise in futility.  I know that every feature request cannot be honored, but this one seems so simple, the coding so minor, you would think...

                                   

                                  Steve Extrand

                                  Sr Network Analyst

                                  (1) Orion v10 SLX polling engine & Additional Web Server 35500 elements

                                  (4) Orion v10 SLX polling engine

                                  (3) NTA v3.7 1400 interfaces

                                  (3) IPSLA SLAX

                                    • Re: Network Discovery improvements
                                      ctopaloglu

                                      By the way, Let us don't forget the highly requested multiple IP support for the single node feature. 6 years and counting...

                                        • Re: Network Discovery improvements
                                          Questionario

                                          yea, multiple IPs for a single node is something we are missing as well!

                                          also hope that network discovery has been fixed in 10.2 but I will see.. :P

                                            • Re: Network Discovery improvements
                                              extrands

                                              Well, thus far I don't see it fixed in 10.2 RC3.  Perhaps we can shame SolarWinds into including it before they package the final release of 10.2, but somehow I doubt it. 

                                              Steve Extrand

                                              Sr Network Analyst

                                              (1) Orion v10 SLX polling engine & Additional Web Server 35500 elements

                                              (4) Orion v10 SLX polling engine

                                              (3) NTA v3.8 1400 interfaces

                                              (3) IPSLA SLAX

                                                • Re: Network Discovery improvements
                                                  smartd

                                                  I doubt it too.  Again, filters reduces the number of polled nodes and interfaces.  It doesn't increase the number, so thus is a low priority to Solarwinds.  Same deal with the mulitple IP addresses.

                                                    • Re: Network Discovery improvements
                                                      ctopaloglu


                                                      I doubt it too.  Again, filtersreduces the number of polled nodes and interfaces.  It doesn't increase the number, so thus is a low priority to Solarwinds.  Same deal with the mulitple IP addresses.

                                                       



                                                      Good point!

                                                      • Re: Network Discovery improvements
                                                        extrands

                                                        Of course.  Even keeping good customers like ourselves satisfied has to take a back seat to increasing revenue.

                                                        Steve Extrand

                                                        Sr Network Analyst

                                                        (1) Orion v10 SLX polling engine & Additional Web Server 35500 elements

                                                        (4) Orion v10 SLX polling engine

                                                        (3) NTA v3.8 1400 interfaces

                                                        (3) IPSLA SLAX

                                                          • Re: Network Discovery improvements
                                                            mavturner

                                                            The frustration with long standing requests is certainly warranted. I can also guarantee that these types of threads are highly visibile within the company at all levels. Steve, your concern about new features before fully maturing existing ones is something that is definitely becoming more apparently recently.

                                                            We are a business and sometimes customers get frustrated with our decisions. However, there is no conspiracy to prioritize or delay features like this based on trying to artificially increase your license count. I can honestly say I've never been involved in a meeting where we de-prioritized a feature based on concern that it would then be to easy to only manage what they are actually using.

                                                            We introduced some minor improvements on the back end in 10.2 to better help customers de-dupe their nodes when running discovery. We certainly have a lot more work to do (better enumeration of all IPs and a resource to show the list of IPs in use by the node).

                                                            Regarding filtering of interfaces, nodes, and volumes; when we introduced UDT we made sure to offer several options to quickly filter which ports were being monitored. This was done based on experience with customer frustration for NPM discovery. We would like to get similar functionality ported to NPM, we just haven't gotten there yet.

                                                            I'm happy to talk with you guys (or anyone else) offline in more detail about your top feature requests and what is causing the most frustration. Just send me a private message or ask here and I'll reach out to you.

                                                            In 10.2 we focused on performance as that has been brought up by a lot of customers. Chris wrote a blog post about the number ofOrion NPM 10.1…you asked, we listened! included in the last release of NPM. Of course we still have a lot to do, but I would like to think there are solid examples of how we have acted based directly off of your requests in the past and plan to act in the future.

                                                            Thanks and keep the great feedback coming!

                                                            Mav

                                        • Re: Network Discovery improvements
                                          lhorstma

                                          To add to these suggestions I would like to see some additional filtering tools added to the discoveries.

                                          One would be adding interface types to the ignore list, so instead of adding each individual VOIP interface to the ignore list for every router I could add a single entry to automatically ignore all interfaces named "Voice Encapsulation*" and another one for "EFXS*", preferably with a text box with wildcards enabled rather than displaying a list of choices with checkboxes.

                                          I would like to be able to filter by things like interface description, again with a text box with wildcards, so I could do something like "Interface Description = "Sprint T1*"" or something like "Interface Description != Null".

                                          I would also like to filter by node name, so I could make a filter to ignore "NodeName = "???NS*", and thus filter out specific devices based on my naming scheme.

                                          I would like to do much of this filtering in the discovery set up, so once discovery is completed those things are already filtered out for me, and I get a message that says something meaningful and actionable like "1 new node found, 3 nodes changed"http://orion.network.ibechtel.com/Orion/Discovery/Results/ScheduledDiscoveryResults.aspx?Status=58 instead of something meaningless like "12 new nodes found, 216 nodes changed" (which will only be meaningful after I've put in countless hours of manually ignoring nodes and interfaces).

                                          • Re: Network Discovery improvements
                                            smartd

                                            I absolutely agree with item #1.  We need this in a big way.  I'd love to run scans for my Juniper, HP, and Cisco device types much more often.

                                            I'd also like to be able to populate custom fields with default data on import.