Hi @seanrb2020,
Apologies for responding late! I'm hoping that I'm right in assuming by DIA you mean Direct Internet Access!
Just to clarify, there are two main methods of implementing Direct Internet Access. DIA is sometimes also referred to as "split tunnelling" or "local breakout". The two methods of implementing it being:
- Using a Centralised Data Policy (specifically, the Traffic Data Policy) with a rule sequence that specifies an action of 'NAT VPN'. This essentially makes it a 'DIA rule'. This type of configuration is akin (but more powerful) to Policy(-Based) Routing
- The other option is using a NAT DIA route via the Configuration Groups that were first introduced in 20.8.1, or the legacy/classic method, which is still commonly used, called 'Templates', or Device/Feature Templates. The NAT DIA route is configured within the Service VPN Feature Profile (Configuration Groups) or Service VPN Feature Template (Templates)
To directly address your question: No, the AAR Policy will not work with any method of Direct Internet Access. There is nothing that stops AAR and DIA configuration from being applied at the same time, but if a packet matches a NAT DIA route or Centralised Data Policy DIA rule and matches an AAR policy, DIA will take full precedence. This is my experience from multiple SD-WAN controller and WAN Edge versions and is described briefly in SD-WAN Configuration Guides
To demonstrate this, consider this topology with the conditions outlined, as an example:
- Site 1 with two NAT-enabled TLOCs (WAN Transports): biz-internet, mpls
- An AAR Policy with a match statement for the SLA Class that defines 5% maximum packet loss tolerance
- A Centralised Traffic Data Policy with a DIA rule that NATs all traffic destined towards 1.1.1.1/32 to VPN0, applied to site 1 in VPN 2001 from-service.
- biz-internet has 10% packet loss
- mpls has 2% packet loss
To summarise, biz-internet is out of compliance with the AAR policy because its packet loss is above 5%. MPLS is in compliance as its packet loss is less than 5%. Since the DIA rule does not specify any specific TLOCs with the Local TLOC action, all NAT-enabled TLOCs are candidate to be used for DIA. If a packet enters the service-side VPN 2001 LAN interface destined to 1.1.1.1, and if AAR and DIA worked in tandem, you would expect that only mpls will be chosen for DIA. That is not correct. Both biz-internet or mpls may be used for DIA, as the DIA rule overrides the AAR policy.
Consider the same topology but with the following conditions (changes marked in bold):
- Site 1 with two NAT-enabled TLOCs (WAN Transports): biz-internet, mpls
- An AAR Policy with a match statement for the SLA Class that defines 5% maximum packet loss tolerance, and a preferred color of biz-internet as the action
- A Traffic Policy with a DIA rule that NATs all traffic destined towards 1.1.1.1/32 to VPN0 (NAT route leak), applied to site 1 in vpn 2001
- biz-internet has 2% packet loss
- mpls has 2% packet loss
To summarise, both TLOCs are in compliance. Since the DIA rule does not specify any specific TLOCs, all NAT-enabled TLOCs are candidate to be used for DIA. If a packet enters the service-side VPN 2001 LAN interface destined to 1.1.1.1, and if AAR and DIA worked in tandem, you would expect that only biz-internet will be chosen for DIA since it is the preferred color that is defined in the AAR Policy. That is not correct. Both biz-internet and mpls may be used for DIA, as the DIA rule overrides the AAR policy.
The NAT DIA route using Configuration Groups or Templates work the same. Say for example you had 3 TLOCs: biz-internet, mpls, LTE. Consider if a packet enters a LAN interface configured in Service VPN 2001. Even if VPN 2001 is configured with a NAT DIA route with an AAR Policy that defines a specific TLOC, it is not used. Traffic is load balanced across all 3 TLOCs regardless of their compliance.
To clarify, AAR can be used with a Data Policy, and they can work in collaboratively in tandem. It used to be that the Data Policy would always override AAR, but that change came with SD-WAN release 20.6.1/17.6.1. However, AAR can not be used in tandem with certain (actually, still many as of writing) rules/features within the Data Policy. As confusing as it sounds, the AAR policy is evaluated before the Data Policy, but in many cases may still be overridden by the Data Policy. For example, even with taking NAT out of the policy, a preferred color of biz-internet may be set in AAR. Even if biz-internet is in compliance, a Data Policy configured only with an action that sets a Local TLOC of only mpls will mean that MPLS is used.
An example where they work together is if the Data Policy sets a Local TLOC action of both biz-internet and mpls. Since the AAR Policy prefers biz-internet, which is in common with one of the TLOCs specified in the Data Policy rule, only biz-internet will be used.
See the following excerpts from the SD-WAN Configuration Guide:
Note
When both application-aware routing and data policies are configured, if the data policy rules that contain actions such as redirect DNS, NextHop, secure internet gateway, NAT VPN, or service, the traffic which matches those rules will skip AAR policy even though the traffic also matches rules defined in the AAR policy. Data policy actions override AAR rules.
If you are able to setup a testing environment (lab) you can configure your policies and use FIA (Feature Invocation Array) to get a full output of the decision making process of packet forwarding. As the name suggests, it displays the features that have been invoked, their outcome, and the impact on the forwarding path. It is similar to the packet-tracer tool on ASAs and the Cisco Secure Firewall's LINA engine. I would not recommend relying on the 'Simulate Flows' feature of the GUI (or show sdwan policy service-path for the CLI) for these scenarios. Complex traffic engineering that is described here has a potential for bugs and I've seen mismatches with the simulation (regardless of if all-paths is specified) and the true behaviour.
Since AAR cannot be used, the NAT DIA Tracker can be used to track reachability of a TLOC and failover to another NAT-enabled TLOC. The threshold value within the tracker can be used as a form of measurement of the delay/latency.
Hope that helps, let me know if anything is confusing
