02-23-2021 07:41 AM
Hi, I have an issue on a 1900 router that on occasion the icmp SLA probe stops working even though I can reach the destination via ping. I notice that the WAN was losing packets an the SLA will see this correctly, however I had two instances that the SLA when into timeout and it never recovered even though from the CLI I could ping the destination IP using the same source ip as the probe. Does anyone know why this would happen, below you can see the IOS version I uses, which BTW I used on other router's with no problems. Does the SLA have something built in if it sees too many timeout/ok status? Or is this a bug with the IOS. BTW I adjust the SLA parameters below so its not so tight however I never had an issue before using the same parameters, I'm at a loss as to what would cause an SLA to stop reporting correctly.
TIA, Paul
C1900 Software (C1900-UNIVERSALK9-M), Version 15.7(3)M3, RELEASE SOFTWARE (fc2)
ip sla 555
icmp-echo 50.xx.xx.xx source-ip 216.xx.xx.xx
threshold 30
timeout 30
frequency 30
track 555 ip sla 555 reachability
delay down 60
Solved! Go to Solution.
02-23-2021 09:54 AM
Hello,
the timeout and threshold values in your IP SLA seem low. Keep in mind that these are milliseconds. Try and change the values to:
ip sla 555
icmp-echo 50.xx.xx.xx source-ip 216.xx.xx.xx
threshold 1000
timeout 1000
frequency 30
08-25-2021 08:46 AM
Changing the timers to the suggested values has been to fix the issue. they were probably too low.
02-23-2021 08:34 AM
Do you have any QoS configured
is the router connected to WAN ?
may be worth put another monitoring towards that IP to compare the results.
02-23-2021 09:09 AM
Yes I have QOS for VOIP only, its connected to the WAN, that icmp probe is towards the WAN. The WAN link was bouncing when the probe suddenly was stuck on timeout, however from the command line I could ping the other side of the WAN link no problems. This has happened to me a few times on this router and I can't figure out why, restarting the SLA didnt work, I had to remove it and then re-add it.
The problem is when the SLA probe is stuck with a timeout it affects the ip track which is linked to certain static routes.
Paul
02-23-2021 09:26 AM
For some reason lets think we consider IP SLA stuck to investigate that, do we have any other NMS which can prove same time no ping loss ?
what is the CPU Load at the time,
Other suggestion May be this could be a bug also, if possible upgrade and test
02-23-2021 09:44 AM
While the SLA times out I'm able to ping successfully on the CLI, doing the same operation the SLA is doing. CPU is normal. Maybe a bug like you are suggesting.
Paul
02-23-2021 09:24 AM
Would it be possible to post your topology and router configuration (replace usernames & passwords with ***)
02-23-2021 09:42 AM
It's a straight forward config with IP SLA and track configured to change the some routes in case the SLA timeouts. Again while the SLA times out I'm able to ping successfully on the CLI, doing the same operation the SLA is doing. I wonder if this might be a bug on that IOS. I was trying to figure out if someone else had this issue at some point.
02-23-2021 09:54 AM
Hello,
the timeout and threshold values in your IP SLA seem low. Keep in mind that these are milliseconds. Try and change the values to:
ip sla 555
icmp-echo 50.xx.xx.xx source-ip 216.xx.xx.xx
threshold 1000
timeout 1000
frequency 30
02-23-2021 09:59 AM
Yes, I agree I have already changed those to exactly what you suggested. I search for bugs related to the SLA issue I have and couldn't find any as well. So hopefully that the SLA is not as frequent It might solve my issue.
Thanks, Paul
02-23-2021 01:27 PM
Hello,
--> icmp-echo 50.xx.xx.xx source-ip 216.xx.xx.xx
Which address are you actually pinging, that is, how many hops away is that ? What if you change it to:
icmp-echo 8.8.8.8 source-ip 216.xx.xx.xx
?
02-23-2021 01:35 PM
pinging 216.xx address which is the next hop on the WAN side via interface Gig0/0. The biggest issue i have is that the SLA just stood in timeout status but using the same source and destination ip in CLI it worked. I actually had to remove the SLA config and redo it. Even SLA restart didnt solve the problem. Its a weird issue and from what i can tell its not an IOS bug.
02-23-2021 01:58 PM
Hello,
odd indeed.
If possible, try the config below, and check if that makes a difference.
track 555 ip sla 555 reachability
delay down 10 up 10
!
ip sla 555
icmp-echo 50.xx.xx.xx source-ip 216.xx.xx.xx
threshold 1000
timeout 3000
frequency 3
!
ip sla schedule 555 life forever start-time now
02-23-2021 03:08 PM
I have a similar config as yours now. I will monitor it, just wanted to post in case anyone had a similar issue. I thought it could be a bug related to that IOS version but when I checked I saw nothing.
Thanks for your response.
Paul
08-25-2021 08:46 AM
Changing the timers to the suggested values has been to fix the issue. they were probably too low.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: