39 Replies Latest reply on Oct 30, 2012 4:50 AM by michal.hrncirik

    What we are working on for NPM


      As always, since NPM 10.3 has been released recently we are already working on the next release of NPM. Here is a preview:


      1. Better support for international customers.
      2. Support for better charts
      3. HW Health Monitoring for major market vendors
      4. Out of the box support for BigIP F5 devices and HP MSM760 and MSM765 wireless devices
      5. Custom Property Enhancements
      6. General web performance improvements for larger customers
      7. Multiple UnDPs in a single chart
      8. Support for audit trail
      9. Better handling of duplicate nodes - same devices with multiple IPs
      10. Supportability enhancements and fixes
      11. Ability to set polling intervals based on the specific UnDP
      12. Better support for nodes with multiple IP Addresses
      13. Native support for Hyper-V
      14. Adding support for Windows Server 2012 as a supported OS platform




      PLEASE NOTE:  We are working on these items based on this priority order, but this is NOT a commitment that all of these enhancements will make the next release.  We are working on a number of other smaller features in parallel.   If you have comments or questions on any of these items (e.g. how would it work?) or would like to be included in a preview demo, please let us know!

        • Re: What we are working on for NPM

          What is supportability enhancements?

          • Re: What we are working on for NPM



            You mentioned in #49243 "UX Reviews and Beta tests" to sign up for, but you didn't mention where we would sign up for said things. Were you just referring to the normal RC releases, or actual beta testing? We would REALLY love to have the Multiple UnDP Graphs sooner than later. :-)




              • Re: What we are working on for NPM

                Hi lan,


                I'm glad you are asking. We typically announce the Beta availability here on Thwack so you can just respond on that thread and I'll contact you directly. We also send emails to our customers so they may participate very easily. Regarding the Multiple UnDP graps, this is something we would like to validate with our users so if you don't mind I'd like to have a short session with you and we may discuss what our designers have already prepared.




                • Re: What we are working on for NPM
                  Kellie Mecham

                  Hi Wifig0d,


                  I just asked to friend you on thwack.  For any user feedback sessions on these features, please feel free to email me directly at kellie.mecham@solarwinds.com.  We're getting ready to run some next week (week of August 20) on out of the box support for BigIP F5 devices and showing multiple UnDPs in a chart (plus maybe more).  For anyone who has 60 minutes to give us any day next week between  7:30 am to 11am Central time, we'd sure love your feedback!  Email me and I can schedule you or give you more information.


                • Re: What we are working on for NPM

                  I'm glad to hear that out of the box hw monitoring is coming. It's been a challenge sometimes to do that, we do it with a combination of syslog and UnDP tables and alarms.


                  I'd like to ask for an enhancement to the "tabular view" for UnDP as well. Specifically, I'd like to be able to put in a column filter.

                  Example: We'd like to monitor our cisco switches' fiber optic tranceiver rx and tx levels. We can get that info by joining the ENTITY-MIB::entPhysicalName mib (sensor names) table with the CISCO-ENTITY-SENSOR-MIB::entSensorValue. Put that in a tabular UnDP view and you're seeing all the values.... for everything.


                  You can edit the tabular view to only display specific indexes, but here's the thing: a) that table is a member of every node's page and b) the indexes are different on chassis to chassis! So i can only manally manage one table per view, and configure it to only display the right info for one system


                  So much easier if for a specific table view if we could set in an snmp regex or sql expression to limit the display for a particular table to All matching indexes that match entPhysicalName like '%Transmit Power%' or even better, where entSensorValue is returning a value of type dbm.


                  Thx much for considering it.

                  • Re: What we are working on for NPM



                    I just want to give the Dev Team props for the "new" interface charts...it is a feature that adds a huge level of class and flexibility to the product overall. This may have been answered previously, but what is the timetable for adding a min/max/avg BPS chart in the new format? We use those for the majority of our custom interface views and that would be a HUGE addition for us. Also, the ability to use new charts for UnDP poller charts would be great as well.


                    To add to spruance's request above...I'd love to be able to join a UnDP table of values with another table of descriptors for drawing the graphs. An example would be the following:


                    On a Nexus 7K, I have a UnDP poller to pull the "cbQosCMPrePolicyBitRate" table and graph the traffic against each of our class-maps prior to QoS policing. The issue with the MIB structure is that each of the table entries is assigned an integerial (?) Index value, but I would want my graph to show the traffic values, AND have each line correleated to the human readable class-map name rather than the random integer indexID which is pulled from another table.


                    I hope this makes sense...I've re-written it twice now



                    • Re: What we are working on for NPM


                      What in :

                      6.General web performance improvements for larger customers?
                      But any how its look good...

                      • Re: What we are working on for NPM


                        Can you give me more information on Solarwinds Alert Manager (win32 app) on the use of script and receiving sms message by phone thank you


                        • Re: What we are working on for NPM

                          I hope "HW Health Monitoring for major market vendors" isn't limited to Cisco but includes Juniper as well.

                            • Re: What we are working on for NPM



                              I think its about server hardware  vendors like HP or IBM and not network vendors.



                                • Re: What we are working on for NPM

                                  Ahh, gotcha.  I thought that all moved to SAM.  Kind of confusing in my book.  Server HW health monitoring should be in one place IMO.

                                    • Re: What we are working on for NPM

                                      I have both NPM and SAM - and there is always confusion here on who monitors what. I basically told my crew this:


                                      NPM Monitors hardware - pings, snmp traffic, netflow.   (INFRASTRUCTURE)


                                      SAM monitors Services, Applications and Disk Space - including CPU and Memory utilization.  (SERVERS)

                                      • Re: What we are working on for NPM

                                        From previous discussions with SW sales and support:


                                        - SAM is really going to be the basic server tool (i say basic because VMware stuff is really best in the VMM tool)

                                        - NPM is heading more towards its original intentions of a network tool


                                        What this means is, all of us on NPM, where we had servers, network, etc.. are going to want to look at SAM since it's a much better SERVER tool (even though it was branded as an application tool before).  We made this critical error a few years ago when we decided not to renew APM (pre-SAM) and now that they've added hardware back into it, it's caused us some grief as we realize we should have been on APM/SAM all along (but APM didn't do hardware).


                                        So, in my opinion, what SW has done is create confusion for customers.  I'll be honest, it's caused us to look at other tools. There are still strange gaps in SW software where you end up needing 3 tools that may/do not share databases so you have multiple environments polling the same things for different reasons.  Yes, I know this is the case with other vendors, but at least the core DB/infrastructure is shared, so if you DO go with the same products from the same vendor, they all talk to each other.


                                        Just my thoughts - i love SW software in general, but the recent rebranding of SAM/APM has caused us some heartburn.

                                      • Re: What we are working on for NPM



                                        no it won't be limited to Cisco. We are working on support for Dell, HP, F5 and Juniper networking hardware devices.

                                        It is already included in our Beta 2 release and would be great if you can test it and let us know for what devices it has worked or not.




                                    • Re: What we are working on for NPM

                                      #8 Support for audit trail.

                                      I am hoping that this is relevant to a ticket that I submitted: Case # 355722 - Feature Request - Events do not show what user made changes in Orion.


                                      I have noticed that under Alerts, Orion does correctly log what username (and to my surprise was granular enough to determine within a Windows Domain) has acknowledged an Alert.  My request regarding this ticket was to add support of this type of logging to the Event Log page as to determine what user has made a change in Orion. (add/remove node/interface, change status etc).  This would add accountability to individuals who have access to make changes in Orion and are not documenting information correctly/completely.


                                      We have Orion NPM SLX with 3 additional pollers and approximately 20,000 nodes on our network.  We have about 25 individuals with access to modify data in Orion and it is incredibly frustrating to track down who is consistently mucking up our database when there is no record of who made what changes.



                                      • Re: What we are working on for NPM



                                        Could you comment on the status of:

                                        9. Better handling of duplicate nodes - same devices with multiple IPs

                                        I have been looking forward to this feature for many releases.

                                        Best regards,

                                        Henrik Noerr

                                        • Re: What we are working on for NPM

                                          I would think the #1 priority would be increasing the SLX unlimited to truely unlimited, as in more than 12,000 Elements.

                                          We have Juniper MX960 sw/routers with 4,000 interfaces, 22 CPUs and 14 vendor MIBS. there are 2 in each site node we activate.


                                          Guess how many I can fit on a single SLX license?



                                          This has made our system of 12 NPM polling engines completely unscalable.

                                          Everytime I add a node, I have to delete 6,000 interfaces manually or log into the Database and running a SQL to find all the MX960 intefaces, delete any that are listed as secondary.

                                          struggling to make more than 4 fit on one server.


                                          Our network has over 1,000 devices to be monitored, With 6 more nodes with 2 MX960s in them before the end of the year. bringing the total to 1,160 devices.


                                          I heard there were vast increases i the 10.4 release... The tern used was Super Poller - True or untrue?


                                          Example of my server counts for just interface elements, this is after I went through all of them and deleted any interfaces that I could.

                                          Unfortunately, I can't add all 12 IPs to each device ACLs so the # 4 servers are the router/switch servers the MX has to go on and #5 is a backup, If it ends in V the poller is on a virtual server.if not it's a standale.



                                          Verizon VoIP and CSS7

                                            • Re: What we are working on for NPM



                                              How many Elements total ???

                                              I hate to say that again Solarwinds need "engineering guide" that will have best practice and max.

                                              Solarwinds couldn't  have the scalability of HP openview or other "big shop" software that can run 25,000 elements and 1,000,000 interface per server.

                                              I'm happy that I don't have 20,000+ node in my network and keep I NPM.



                                                • Re: What we are working on for NPM

                                                  12 Servers X 12,000 elements = 144,000

                                                  Currently, we have 35,487 elements on the entire system, 2 servers are at zero and just installed and not in any ACLs or the IDN firewalls.

                                                  Currently Total Server Utilization would be 25% Elements (one is a hot standby, one is for another organization and thier Cisco 3020 switches)


                                                  So the total number of servers dedicated to VoIP networks is 10.


                                                  10 X 12,000 = 120,000

                                                  35,487 total elements currently w/additional 18,000 by year end for 2012 total of 53,487 (give or take a few)

                                                  Of the 18,000 elements approx 12,000 of which will be the new MX960s.

                                                  So by Year End my total server utilization will be 45%



                                                  Servers of necessity had to have only 3 server IPs per device type (1 of which is the hot standby) due to the limits of some device ACLs. So essentially, we have 2 servers for firewalls, 2 for Routers, 2 for Switches, 2 for Border Controllers or 24,000 elements per device type.and the hot standby.


                                                  Some servers can contain many more devices, than others.due to the number of interfaces on those devices, Universal MIBS (i.e., Vendor MIBs) account for very few of the total elements monitored.

                                                  The new Juniper MX960 switch/router upon discovery has 4,000 interfaces of which roughly only 960 or so are useful physical interfaces, the remainder are signaling and media VLANS assigned to customers. This forces me to go into the interfaces and delete the specific (3,000 or so) one's not needed so that I can recover element space on the server I add the device to.


                                                  So essentially most of my servers are being used at <20% I have 3 that are above 75% and if I had to stick with the 3 IPs for the new MX960 switch/routers I'd be screwed.


                                                  I've managed to talk both engineering and operations into adding 2 more server IPs for these new devices giving me 4 pollers and 1 standby server dedicated to just 1 device type of 6. This is not Solarwinds fault. But, I'm extremely hopeful that the new release will greatly increase the element count on my SLX (unlimited) licenses. If not, some form of IP load balancing device will have to be placed between Solarwinds servers and the networks.


                                                  This is my tale of woe.

                                                  Thanks for listening





                                                    • Re: What we are working on for NPM

                                                      Hi Radioman


                                                      That sound bad.....

                                                      We have more den 10 MX960 but they don't have so many subinterface.

                                                      What is running in does subinterfaces that is so importent ?

                                                      When we had some Juniper E router that is a BRAS that has alot of pppoe custemeres we had problem to discover the physic GE/XE/AE  because there where so many pppoe subinterface.

                                                      By the way how your SQL cope with 33K ?

                                                        • Re: What we are working on for NPM

                                                          I have 30 MXs now with another 6 before the end of the year.

                                                          GE/FE/XE/AE/LC/IP/and a few more..


                                                          On my hottest server I have a mix of Juniper M10i and MX960s. Total Element count right now is 8,146 after deleting out unnecessary interfaces.

                                                          Viewed via the Node Manager thats 33 pages of 250 interfaces on one server.


                                                          Based on that this server can add 2 more, maybe 4 MX960s, add 1 Delete interfaces, add the second delete the interfaces to keep it below 12,000 elements.

                                                          But the last one will discover 4000 and push the elements to 14-15K before I delete the unneeded interfaces. Just for my own morbid curiosity, after List Resources ran, I manually deleted 3,200 interfaces, takes about and 30 mins and would give me Carpal Tunnel pretty quick.



                                                  • Re: What we are working on for NPM

                                                    I wouldn't mind if the HW Health Monitoring also included Avaya network equipment.  We are a big Nortel/Avaya network shop.

                                                    • Re: What we are working on for NPM

                                                      I'm glad to hear about the better F5 support. Particularly helpful would be the ability for NCM to login to the LTM, save the config to a .ucs file and then back up the .ucs file. Since the .ucs file has all the elements required for a successful restore, that would be nice.

                                                      • Re: What we are working on for NPM

                                                        Another thing that would really be nice to have would be a switch port mapper integrated into Orion. Any plans for something like that?



                                                        • Re: What we are working on for NPM

                                                          I would personally like to see better native support for PTP wireless radios.

                                                          • Re: What we are working on for NPM

                                                            Are there any plans to improve visibility of Lightweight AP's? It would be nice to have similar features like the Autonomous AP.