cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
653
Views
0
Helpful
3
Replies
Amir.csco
Beginner

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

Hi,

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

thanks,

 

3 REPLIES 3
William Benson
Beginner

Are you performing an ipIcmpEcho for your SLA monitor?

you could do something like

ip sla monitor 10

type echo protocol ipIcmpEcho 10.10.10.10

frequency 5

timeout 500

 

That would tell the monitor to ping 10.10.10.10 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 10.10.10.10

over preferred route:

traceroute 10.10.10.10

reply from 10.1.1.1

reply from 10.1.2.1

reply from 10.1.3.1

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

So we'll create that static route

ip route 10.1.3.1 255.255.255.255 10.1.1.1

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

ip sla monitor 10

type echo protocol ipicmpecho 10.1.3.1

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 10.10.10.10 is 10.1.1.1 so we'll add a tracked route for that using the SLA monitor and track above

ip route 10.10.10.10 255.255.255.255 10.1.1.1 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 10.10.10.10 is through 10.1.1.2 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.10.10.10 255.255.255.255 10.1.1.2 10

So as long as latency to 10.1.3.1 which is the last hop we can ping before the 10.10.10.10 host is less than 500ms track 10 will be up and 10.1.1.1 will be the gateway we use to get to that ip.  If latency to 10.1.3.1 goes above 500ms it will fail to 10.1.1.2.  As soon as latency to 10.1.3.1 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 10.10.10.10 through the preferred gateway.

Joseph W. Doherty
Hall of Fame Expert

Disclaimer

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.

Posting

I would recommend the PfR solution.