33 Replies Latest reply on Oct 28, 2016 5:50 AM by npereira1

    ping node from NPM


      Hi all,


      how can you make Solarwinds NPM ping a host device in steps of 30sec and ping 10 concecutive times?


      Im currently using SmokePing because I cannot seem to get Solarwinds to tell me when the device is not pingable when something happens to the link. I have the node status polling set to 10sec and callect statistics to 1minute and those are the lowest settings possible...


      Can't this be further customized for critical devices that are not SNMP based?


      I had 2 outages this morning, which Smokeping told me exactly what time and how many packets lost, yet solarwinds never alerted me, no logs, nothing. As if nothing ever happened...>?



          • Re: ping node from NPM
            I LIKE EGGS

            solarwinds uses a poll based method to gather deivces Status, responce and drops via ICMP


            It will poll data every couple of minutes or every minute like you mentioned you have got the lowest values.


            you can recive real time data with the use of syslogs and traps if your device can send these to solarwinds then you can infact Rrecive 500 traps a second and send emails instan or other actions when the trap syslog is recived


            also solarwinds uses a rapid ping if a node is deemed as down before it status is actually recorded as down so in your case this wont find an issue if you have flapping interface that flaps every hour say.


            Someone else Could have a different perspective but this my understanding

          • Re: ping node from NPM



            Check out ICMP Echo IP SLA operations.  Cisco routers can be configured for IP SLA from CLI, so lack of SNMP access is not a show-stopper for you.  VNQM can monitor IP SLA operations, whether it configured them or not.  Is there a Cisco device in your network that you can configure for this?  It could run the SLA job.  If it's your company's router, perhaps you could even SNMP monitor the IP SLA job from SolarWinds (presumably your company can SNMP monitor it's own assets(?)).  The product can do it, but the question is whether you can use a Cisco router in your network for IP SLA jobs.

            • Re: ping node from NPM
              Craig Norborg

              I believe you can do that if you get the Engineers toolset and install it as a web add-on to the Orion server.   I still use it as a separate tool and haven't integrated it into my Orion, but I think you should be able to use all tools from the web version.


              Network Engineer Tools - Engineer's Toolset | SolarWinds



              1 of 1 people found this helpful
                • Re: ping node from NPM

                  ok, i think we are getting off track here.


                  1) We dont want to implement a cisco router to monitor each sites MPLS router (the carriers device).

                  2) we need solarwinds to do this just like Smokeping is doing. ping the devices IP at each site and monitor it every 30 seconds, or shorter if possible.


                  I still dont have a clue if NPM can be programmed to ping this node on a 30sec interval for a specific number of pings. Is this possible or not? if it is, then how do we set this up?


                  If someone has any specific data or howto's on getting the IP SLA of someone elses cisco router to report to our Solarwinds, please let me know as this may be a solution, but I need to know how to set this up. I have read a bit on cisco's IP SLA, but have no idea on how to setup Solarwinds to monitor this SLA.

                    • Re: ping node from NPM

                      It wasn't my intention to take anything off-track - just correcting your assertion regarding the possibility of getting traps from a provider/carrier's device to NPM.



                      Best of luck to you.

                      1 of 1 people found this helpful
                      • Re: ping node from NPM

                        IF you have VNQM AND your provider has SLA jobs configured AND they provide SNMP credentials for you, you could do this:  Adding existing operations to VoIP and Network Quality Manager - SolarWinds Worldwide, LLC. Help and Support


                        Here is a description of NPM fast polling functionality.  Note that it is not customizable:  NPM poll down nodes - SolarWinds Worldwide, LLC. Help and Support


                        Rather than taking anything off track, rharland2012 and I have provided details on what can be done, since what you ask can not be done within NPM.

                        1 of 1 people found this helpful
                        • Re: ping node from NPM
                          Craig Norborg

                          Oh, guess I misunderstood.


                          You're not wanting an "on demand" thing like the toolkit offers, but a continuous monitoring like Orion does, but just ping and with an interval of every 30 seconds?   Is that correct?    I think I also gleaned that every 30 seconds you want it to do 10 pings instead of just one?


                          The only way I can think of even coming close to this would be to set up a node of type "Status Only" and to customize the "Node Status Polling" in the properties to be every 30 seconds.  No idea how to get the 10 pings every 30 seconds, unless you wanted to instead do the pings every 3 seconds (ie: 3 x 10 = 30seconds), but not even sure Orion >can< do every 3 seconds.   The only other thing I can thing of is to make the # of retries 30, but I think that affects every node and could have some adverse effects.

                            • Re: ping node from NPM

                              That is correct Craig,

                              I already have the node as a Status Only using ICMP. The issue is the pings. They are not consistante and not even close to 30sec...

                                • Re: ping node from NPM

                                  I just read the information supplied by D09H about the poll. Good info to know.


                                  My question now is as I packet sniff my network specifically for the icmp that Orion sends to one of the router, the pings are inconsistent. I have the node status polling set to 10 seconds and collect stats every 1 minute, and not seeing consistant pings being done.


                                  My question now is, is it the orion server that is too busy and can't do those pings in the time requested?

                                    • Re: ping node from NPM

                                      How many nodes are you monitoring currently? Status polling @ 10 sec will likely be problematic if you're polling large amounts of nodes - even if it is just ping.

                                      • Re: ping node from NPM

                                        Does your network have any QoS?  If any congestion, might be a casualty.  Can you packet capture off your SolarWinds server's NIC and at least confirm the expected quantity/ timing there?

                                        • Re: ping node from NPM
                                          Craig Norborg

                                          I'm guessing that might be partially the issue, but its probably also a bit of how Orion works.   And it should be noted that I'm making assumptions here from what I've seen both in the database and the settings, Orion may work drastically different.


                                          Orion servers are generally busy though.   They have a LOT going on.  Pinging devices every X seconds, polling devices every Y seconds for statistics, polling volumes, doing health checks, etc. etc..   How does it keep track of this? 


                                          Smokeping generally has one thing to do, ping a number of devices.   So when its done pinging them, it simply waits the required interval and starts over again, the same queue over and over.  Very predictable, very much on schedule or at least consistent.


                                          Solarwinds though has to somehow figure out when to do things, and there is no way it can keep all of its task lists in memory, and it definitely isn't doing the same thing in the same sequence over and over.    In the database there are fields for when the "NextPoll" and the "NextRediscovery" is.   Will Orion do it at the very second that is on each and every interface, node, volume, etc?    I doubt it, when it has free time it probably does an SQL query to see what needs to be polled based on their "NextPoll" field being either now or in the recent past, builds a list and then does that list sequentially, when its done, it starts all over again.   So the more items that its monitoring, the more things its monitoring on each item, the more "drift" there ends up being in these things.     Guessing the speed of your SQL server could sometimes influence this drift too.   If the drift gets to be greater than it should be, your polling intervals start increasing.   How big is this drift?  I'm guessing its in the seconds, sometimes it might be early on something, sometimes it might be late.   But in general when your polling intervals are a minute, or in the hundreds of a seconds, a few seconds drift on something probably isn't a bad thing.


                                          There is also the "Polling Settings" themselves.   I think by default Orion allows a ping to take 2500ms to come back, and it can miss a couple before it marks a node down.   SNMP has the same timeout and can do a couple retries.  That means if you're doing something with SNMP Orion could be trying to poll it for 7.5 seconds before it gives up and goes on to the next item.   Why is this important?   If you're ping is stuck behind an SNMP poll that fails often, it might get stuck waiting a bit for Orion to complete that.


                                          However, when you're trying to get super-consistent polling intervals for a very specific task at a very high rate?   I'm guessing it would try the best it can, but that it would have just the problems you're talking about.   How do you fix it?   Its possible that you could have a poller dedicated to these very specific and high speed pollers that you might get a bit better results.   Have it be uncluttered from the other stats.  But not only is that expensive in terms of licensing and hardware, I'm also guessing it won't handle a ton of these types of polls without drifting again.


                                          Maybe the other persons suggestions about IP SLA might help out?    Set up the IPSLA on the routers themselves and monitor them via a UnDP?


                                          But other than that, I would think you might need to go find an application more suited to your specific need, which it sounds like you might have already.   That is unless you can convince solarwinds there is enough of a market to maybe create a new polling engine type suited to this?

                                            • Re: ping node from NPM

                                              Thanks for your response Craig.


                                              Yes, I just pulled out an ASA5520 from it's box that we never deployed (as all our firewalls are Fortinet) but it doesnt seem to have the IP SLA commands. Possibly because it's not running the correct software version or software load, but trying to figure out if I could use this as a proof of concept for deploying small cisco routers at each site and run the IP SLA on them.



                                              Although this ASA5520 is a VPN appliance, it might not have the feature. I never really worked on ASA's so unsure...  Anyone can answer this?


                                              Here is a output of show ver:


                                              ciscoasa(config)# sh ver



                                              Cisco Adaptive Security Appliance Software Version 9.1(1)

                                              Device Manager Version 7.1(6)



                                              Compiled on Wed 28-Nov-12 10:38 by builders

                                              System image file is "disk0:/asa911-k8.bin"

                                              Config file at boot was "startup-config"



                                              ciscoasa up 9 mins 18 secs



                                              Hardware:   ASA5520, 2048 MB RAM, CPU Pentium 4 Celeron 2000 MHz,

                                              Internal ATA Compact Flash, 256MB

                                              BIOS Flash AT49LW080 @ 0xfff00000, 1024KB



                                              Encryption hardware device : Cisco ASA-55xx on-board accelerator (revision 0x0)

                                                                           Boot microcode        : CN1000-MC-BOOT-2.00

                                                                           SSL/IKE microcode     : CNLite-MC-SSLm-PLUS-2.03

                                                                           IPSec microcode       : CNlite-MC-IPSECm-MAIN-2.08

                                                                           Number of accelerators: 1



                                              0: Ext: GigabitEthernet0/0  : address is 0018.b964.726c, irq 9

                                              1: Ext: GigabitEthernet0/1  : address is 0018.b964.726d, irq 9

                                              2: Ext: GigabitEthernet0/2  : address is 0018.b964.726e, irq 9

                                              3: Ext: GigabitEthernet0/3  : address is 0018.b964.726f, irq 9

                                              4: Ext: Management0/0       : address is 0018.b964.726b, irq 11

                                              5: Int: Not used            : irq 11

                                              6: Int: Not used            : irq 5

                                              The Running Activation Key is not valid, using default settings:



                                              Licensed features for this platform:

                                              Maximum Physical Interfaces       : Unlimited      perpetual

                                              Maximum VLANs                     : 150            perpetual

                                              Inside Hosts                      : Unlimited      perpetual

                                              Failover                          : Active/Active  perpetual

                                              Encryption-DES                    : Enabled        perpetual

                                              Encryption-3DES-AES               : Disabled       perpetual

                                              Security Contexts                 : 2              perpetual

                                              GTP/GPRS                          : Disabled       perpetual

                                              AnyConnect Premium Peers          : 2              perpetual

                                              AnyConnect Essentials             : Disabled       perpetual

                                              Other VPN Peers                   : 750            perpetual

                                              Total VPN Peers                   : 750            perpetual

                                              Shared License                    : Disabled       perpetual

                                              AnyConnect for Mobile             : Disabled       perpetual

                                              AnyConnect for Cisco VPN Phone    : Disabled       perpetual

                                              Advanced Endpoint Assessment      : Disabled       perpetual

                                              UC Phone Proxy Sessions           : 2              perpetual

                                              Total UC Proxy Sessions           : 2              perpetual

                                              Botnet Traffic Filter             : Disabled       perpetual

                                              Intercompany Media Engine         : Disabled       perpetual

                                              Cluster                           : Disabled       perpetual



                                              This platform has an ASA 5520 VPN Plus license.



                                              Serial Number: JMX1102K0DY

                                              Running Permanent Activation Key: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000

                                              Configuration register is 0x1

                                              Configuration has not been modified since last system restart.


                                                • Re: ping node from NPM

                                                  Looks like a 10 second poll is possible...perhaps even less?


                                                  Configure the ASA for Redundant or Backup ISP Links - Cisco


                                                  This example is for ASA 5520.

                                                    • Re: ping node from NPM

                                                      link is invalid/

                                                        • Re: ping node from NPM

                                                          I just accessed via the link in the post...successfully.  Perhaps try a Google cache of the link?


                                                          These were the parts jumping out at me:

                                                          sla monitor 123

                                                          type echo protocol ipIcmpEcho interface outside

                                                          num-packets 3

                                                          frequency 10

                                                          !--- Configure a new monitoring process with the ID 123.  Specify the
                                                          !--- monitoring protocol and the target network object whose availability the tracking
                                                          !--- process monitors.  Specify the number of packets to be sent with each poll.
                                                          !--- Specify the rate at which the monitor process repeats (in seconds).


                                                          sla monitor schedule 123 life forever start-time now


                                                          !--- Schedule the monitoring process.  In this case the lifetime
                                                          !--- of the process is specified to be forever.  The process is scheduled to begin
                                                          !--- at the time this command is entered.  As configured, this command allows the
                                                          !--- monitoring configuration specified above to determine how often the testing
                                                          !--- occurs.  However, you can schedule this monitoring process to begin in the
                                                          !--- future and to only occur at specified times.


                                                          crypto ipsec security-association pmtu-aging infinite

                                                          crypto ca trustpool policy


                                                          track 1 rtr 123 reachability


                                                          !--- Associate a tracked static route with the SLA monitoring process.
                                                          !--- The track ID corresponds to the track ID given to the static route to monitor:
                                                          !--- route outside 1 track 1
                                                          !--- "rtr" = Response Time Reporter entry.  123 is the ID of the SLA process
                                                          !--- defined above.