Can CFLOW and Syslog traffic from CEDGE be pinned to a specific TLOC ?

[csco10260962]

Can CFLOW and Syslog traffic from CEDGE be pinned to a specific TLOC ?

We have AAR in place with traffic being pinned to tloc private 1 (fiber ipvpn in our case) and as fallback private2 is up (LTE connection)

For all traffic from service side vpn's is correctly pinned to privae1 tloc. Only traffic as syslog and cflow from the cedge itself using a service side vpn interface as source is using both tlocs (In the case of some cedges this couses al lot of data usasge on the private2 lte tloc)

[csco10260962]

By pinned is mean all traffic using private1 as preferred tloc and private2 as backup path with its own sla.

some traffice is using private1 tloc with strict. And i would like to pinn syslog and cflow to private1 also with strict. At he moment it looks like traffic generated from the cedge itself (selfzone) does not use AAR policy.

[Kanan Huseynli]

Hi,

Self-generated packet (which is sourced in VPN) indeed pass both AAR and DataPolicy.

Could you share your configured? Did you configure AAR on both direction? Because, when you configure remote sites for AAR, return traffic can still come via "bad" channels.

[csco10260962]

I mirrored forward path and return path in match statements in different sequence rules and this is applied to datacenter cedges as the decentralized cedges. I think a data policy also won't do the trick as this also only covers traversing traffic. Maybe clia add on template with ip local-policy might work but will have to test if that is still supported in sdwan mode and with an action set local-tloc. As there is no feature template that supports this as of now i think.

[Kanan Huseynli]

I don't know your setup, but in my lab I have two color between site A and site B.I've configured AAR both for site A and site B with prefered color public-internet. I've generated router-self traffic from site B and transit traffic from site B core switch. When everything is OK, traffic go through public-internet. Then I simulated WAN failure by adding loss for public-internet TLOC transport, traffic both for self generated packets and transit packets got dropped partially (based on loss %) till routers switch to another path due to AAR. After switching to the second interface (biz-internet), both traffic have begun to work without loss.

Thus, AAR works for self-generated packets. Datapolicy also works (you may do by just adding simple drop rule - traffic will begin to be dropped due to datapolicy).

[Kanan Huseynli]

Also, there are certain cases rules in AAR are skipped due to data policy actions.

In general, below is he document for AAR with restrictions/ caveats. However, if you can share configuration details, it would be better. In general, as I mentioned self router generated (sourced from service VPN) indeed pass both AAR and DataPolicy rules.

https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/policies/ios-xe-17/policies-book-xe/application-aware-routing.html

[csco10260962]

app-route-policy _PA_AAR-Prodlocaties-Steunpunten-Datacenter-V1_KA_AAR-Prodlocaties-Steunpunten-Datacenter-V1
vpn-list KA
sequence 1
match
source-data-prefix-list PA-Decentraal
destination-ip 0.0.0.0/0
!
action
backup-sla-preferred-color private1
sla-class Default preferred-color private1
!
!
sequence 11
match
source-ip 0.0.0.0/0
destination-data-prefix-list PA-Decentraal
!
action
backup-sla-preferred-color private1
sla-class Default preferred-color private1
!
!
sequence 21
match
source-ip 10.159.0.0/16
destination-ip 0.0.0.0/0
!
action
backup-sla-preferred-color private1
sla-class Default preferred-color private1
!
!
sequence 31
match
source-ip 0.0.0.0/0
destination-ip 10.159.0.0/16
!
action
backup-sla-preferred-color private1
sla-class Default preferred-color private1
!
!
sequence 41
match
source-data-prefix-list KA-Steunpunten
destination-ip 0.0.0.0/0
!
action
sla-class Default preferred-color private1 fallback-to-best-path
!
!
sequence 51
match
source-ip 0.0.0.0/0
destination-data-prefix-list KA-Steunpunten
!
action
sla-class Default preferred-color private1
!
!
sequence 61
match
source-data-prefix-list KA-Decentraal
destination-ip 0.0.0.0/0
!
action
sla-class Best-Effort strict preferred-color private1
!
!
sequence 71
match
source-ip 0.0.0.0/0
destination-data-prefix-list KA-Decentraal
!
action
sla-class Best-Effort strict preferred-color private1
!
!
!
vpn-list PA
sequence 1
match
source-data-prefix-list PA-Decentraal
destination-ip 0.0.0.0/0
!
action
backup-sla-preferred-color private1
sla-class Default preferred-color private1
!
!
sequence 11
match
source-ip 0.0.0.0/0
destination-data-prefix-list PA-Decentraal
!
action
backup-sla-preferred-color private1
sla-class Default preferred-color private1
!
!
sequence 21
match
source-ip 10.159.0.0/16
destination-ip 0.0.0.0/0
!
action
backup-sla-preferred-color private1
sla-class Default preferred-color private1
!
!
sequence 31
match
source-ip 0.0.0.0/0
destination-ip 10.159.0.0/16
!
action
backup-sla-preferred-color private1
sla-class Default preferred-color private1
!
!
sequence 41
match
source-data-prefix-list KA-Steunpunten
destination-ip 0.0.0.0/0
!
action
sla-class Default preferred-color private1 fallback-to-best-path
!
!
sequence 51
match
source-ip 0.0.0.0/0
destination-data-prefix-list KA-Steunpunten
!
action
sla-class Default preferred-color private1
!
!
sequence 61
match
source-data-prefix-list KA-Decentraal
destination-ip 0.0.0.0/0
!
action
sla-class Best-Effort strict preferred-color private1
!
!
sequence 71
match
source-ip 0.0.0.0/0
destination-data-prefix-list KA-Decentraal
!
action
sla-class Best-Effort strict preferred-color private1
!
!
!
!

[Kanan Huseynli]

It is hard to understand something from just AAR config.

Share problematic segment (subnet) with list and its data / AAR policy in both direction with description.

[csco10260962]

vpn-list PA = service vpn 10

source-data-prefix-list PA-Decentraal = supernet routes for 10.160.0.0/13,10.176.0.0/12,10.192.0.0/16,10.191.0.0/16

problem traffic is from source data-prefix-list to host 10.9.2.50 udp/2055 in the datacenter

[csco10260962]

Cflow is using vpn 10 as source and as source interface a subint that is in service vpn 10. I added a more spefic entry to AAR policy at the first sequence rule destination prefix 10.9.26.82/32 protocol 17 port 2055. sla class default preffered color private1 strict. But this has no effect. Looks like AAR does not look at local generated traffic.

[Kanan Huseynli]

Do you have data policy that overlaps for the same traffic? Also, mention which version of controllers/ routers do you use?

[csco10260962]

No we have no data policy in place on the interfaces save QOS and access policy to the router itself voor SSH and snmp.

20.7.2 are software versions and 17.7.1a on cedge side

[Kanan Huseynli]

Okay, so no data policy.

Did you configure AAR or datapolicy for reverse direction (from DC -where 10.9.26.82/32 placed to PA-decentral as I understand)? Also, how to do check that AAR does not work for local traffic? (In my lab for 20.11/17.11 it works, most probably you have incorrect or incomplete configuration). If you see bandwidth usage on LTE, check for both incoming and outbound traffic utilization. You most probably have incoming traffic from DC.

[csco10260962]

DC has the same AAR policy. There is no traffic from DC for this as it's udp traffic cflow and syslog.

I check this with live production traffic and EPC on the cedge itself on the tunnel interface as a filter for vpn 10. LTE interface is tunnel 10. Testing SDWAN policy from router with simulate flows doesn't allways give correct results i noticed, especially when you have a doata policy in place. Pressing simulate flows can give different results depending on how often you press the test button. Only real live data gives the correct results. 

[Kanan Huseynli]

Can you confirm that SLA meet the sla-class?

From one of the remote router share:

sh sdwan app-route sla-class

sh sdwan app-route stats | include remote-system-ip|local-color|remote-color|sla-class-index