Is anyone successfully utilizing AAR (app aware routing) policies?

[pietro manicioto]

I have a TAC case opened with Cisco and they are stumped, which has me stumped and questioning life. I am at a point that I am questioning if Cisco has actually fully tested this, and/or if customers are actually using this tool?

So I implemented AAR policies in my overlay with some specific applications to prefer specific tloc colors and fail to the best available link based on SLA metrics I defined. 

I am finding that my spokes are following the policy as they should and processing over the best TLOC to the HUB and then the hub sends to the destination using the same TLOC color. However on the return route, the hub is using the routing table to determine its route back to the spoke vs preferring the original ingress TLOC. This is a problem because the routes are ECMP across all avail TLOC's in which the hubs sometimes will return the traffic back over the problematic link causing AAR to basically be moot and ignored. 

Cisco suggested adding my Hubs to an AAR policy as well, but my logic is that my Hubs will essentially never have a TLOC issue in my DC, so they will still ECMP regardless which again will put me back in the same boat, or not flip the traffic over at all. 

[MHM Cisco World]

Spoke send traffic to hub and hub redirect it to other spoke' i.e. there is no spoke to spoke?

MHM

[pietro manicioto]

I have a Hub and spoke topology, not a mesh. There is no spoke to spoke communications. 

[Kanan Huseynli · Accepted solution]

Hi,

I understood your concern. This is exactly how AAR works. AAR is unidirectional i.e if spoke send over TLOC1 it does not mean that return traffic will be via TLOC1. It totally depends on remote (i.e hub in your case) decision.

You need to implement AAR on hub as well, so it does not choose problematic tunnel. In reality, AAR does not check TLOCs, but checks TLOC-to-TLOC traffic which means ipsec tunnels between routers. And of course you need ECMP (routing table) in order AAR function (AAR considers only best paths).

AAR works based on best routes (remote TLOCs) and calculates application parameters (loss, jitter, delay) per tunnel (local to remote TLOC).

[pietro manicioto]

Thank you. I feel this was missing in the AAR documentation from Cisco and often return route traffic gets forgotten about. 

I had a meeting with Sales Architect's yesterday and confirmed the same thing. I was thinking the rules look at underlay metrics vs overlay/tunnel metrics and threw me for a loop. I am reviewing adding the hubs to the existing policies now