I have recently installed the latest version of IP SLA Manager. For some reason, all latency values above 100 ms displays with red numbers. Since we have a very distributed network, our normal latency values ranges from 5 ms to above 700 ms, so 100 ms is not a critical value for me. Is there any way to adjust this threshold individually for each node?
I have tried different values within the Edit Operation properties, but the latency value is still red even when within my threshold value.
Sorry for the delay in responding; we were trying to reproduce your issue, and were unsuccessful in doing so. I'm assuming you're referring to the gauge values, which you should be able to edit the thresholds accordingly. I just tried it and it worked for me.
At this point I would recommend opening a support ticket and reference this thwack post.
Hi, and thanks for your replies.
Operation Status says "Warning". Status Message is "Warning threshold level reached for: Round Trip Time".
The actual latency for this path displays in IP SLA as 700 ms, and the latency threshold value I have defined in "Edit Operation" is more than the double; 1700 ms.
I suspect that IP SLA references to a global value in NPM Settings; "Response time" Warning level. But even when setting this value to 1700 ms it is not reflected in IP SLA. The warning is still active, and the latency value displays as red for some reason.
I might do as suggested and open a ticket on this case.
Was there a solution to this problem? I'm getting the same thing. ie. IP SLA HTTP operation continually 'warning' even though thresholds are set way above actual results.
I now have a resolution to this issue after raising a ticket. It was basically due to a mis-understanding on my part. I was thinking that the threshold value in NPM was controlling the warning state when in fact it is the threshold value configured on the Cisco switch. Here is the explanation from Solarwinds support:
The thresholds in IPSLA can be set to allow more or less time for the information to be received back from the device. This way if you have an operation you know should be responding quickly, then it would have a lower threshold so you know when the operation is either not being run, or completed in the amount of time you set for IPSLA to expect to receive the information back from the completed operation. The device timeout tells the device that the operation it's running should take less than the timeout value setup on the device to complete.
Thanks for your comments Garrie. Could you please post the config that you made for the ip sla operation work without warning? We are having the same problem.
Also i would like to know if you can explain"...The thresholds in IPSLA can be set to allow more or less time for the information to be received back from the device..." Are you using SNMP traps in the operation?? Because as far as i know, the device with the ip sla operration does not send info to the NMS like netflow, it's only collect statistics locally and you can get those statistics with SNMP. Is that right? So, if you set thresholds in the operation, this will only work if you set snmp traps.
Please feel free to correct this or share your comments. Thanks a lot again!
The IP SLA stats are collected and stored by the device performing the IP Operation at a rate designated by the frequency line in the device config.
'NPM IP SLA' then retrieves these from the device via SNMP at a rate designated by the frequency setting in NPM.
Here is an example of one of my IP SLA Operation configs:
ip sla monitor 102100
type jitter dest-ipaddr x.x.x.x dest-port 50098 source-ipaddr x.x.x.x codec g729a codec-numpackets 100 codec-size 100
ip sla monitor schedule 102100 life forever start-time now ageout 3600
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process. Learn more today by joining now.