Showing results for 
Search instead for 
Did you mean: 

Rerouting traffic to an alternative path when RTT/Latency of the main path goes above the certain threshold


My goal is to cause a traffic route changes to secondary path when RTT/Latency threshold violation occurs in the primary path via EEM or PBR. I found that router is able to analyze RTT on the primary path via IP SLA ( ip sla reaction-configuration ) so when RTT drops blow or goes above of the defined threshold then SNMP trap will generate or another IP SLA ( ip sla reaction-trigger ) will activate. I am unclear how to use this SLA result for changing traffic route, I can do a reaction-configuration to catch the RTT violation but how do I trigger the route change to the second path? how can i use this SLA in EEM or PBR?

or maybe i should leave this solution and use PfR to address my needs



William Benson

Are you performing an ipIcmpEcho for your SLA monitor?

you could do something like

ip sla monitor 10

type echo protocol ipIcmpEcho

frequency 5

timeout 500


That would tell the monitor to ping every 5 secs and if the latency is higher than 500ms it would time out and the track would fail and then inject the next highest metric route into the table.

Just to expand on my post above:

To make this work you won't really be able to trace to the final host, cause once the track fails and the new route is injected, if over the new route latency is below 500ms the track would show as good to final host and original route would be injected back into the routing table again, and you can see this would just start causing the track to fail up and down like a yo-yo.


What you could do is hard route either the first or last hop along the path of one route, and the first or last hop along the other route before the final host and check for latency right before it gets to the final destination and monitor that SLA and fail.

For example:

Final host is

over preferred route:


reply from

reply from

reply from

We're going to say that was the final hop before it reached host over your preferred link

So we'll create that static route

ip route

Now that we know will only route out the preferred gateway we can create the monitor

ip sla monitor 10

type echo protocol ipicmpecho

frequency 5

timeout 500

ip sla monitor schedule 10 life forever start-time now


now the monitoring has begun..but we need to setup a track for that sla

so we'll create track 10 to track sla monitor 10:

track 10 rtr 10 reachability


That track will test sla monitor 10 and if it fails, we'll use it to change the routing table.

So our preferred route to is so we'll add a tracked route for that using the SLA monitor and track above

ip route 1 track 10

Metric for this route is 1 and as long as track 10 is up it will be injected.

Our secondary route to is through we'll just add a higher metric route for this path that will only be used if track 10 fails and the above route is removed from the table:

ip route 10

So as long as latency to which is the last hop we can ping before the host is less than 500ms track 10 will be up and will be the gateway we use to get to that ip.  If latency to goes above 500ms it will fail to  As soon as latency to falls below 500ms and the track shows as up again, the lower metric route will be injected back into the table and the router will start sending traffic to through the preferred gateway.

Joseph W. Doherty
Hall of Fame Expert


The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.


I would recommend the PfR solution.