The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
BFD (Bidirectional Forwarding Detection) detects link failure conditions and gathers performance routing data (PfR), including
loss, latency, and jitter information of Cisco Catalyst SD-WAN tunnels (both IPsec and GRE).
Each BFD hello packet collects the following information:
Latency: RTT (Round trip time) between BFD echo request and reply.
Jitter: The variation in the delay of packet arrival times in a network. It is a measure of the irregularity in the timing
of data packets as they are transmitted and received.
Loss: Number of echo requests that fail to receive a reply.
By default, with a BFD hello timer of 1 second, one sample of PfR data is collected every second. This PfR data is collected
over the duration of the poll interval (default 10 minutes). During the poll interval, the average of each statistic is computed.
To determine dynamic path decisions based on the thresholds specified in application-aware routing SLAs, a default multiplier
of 6 is employed to review multiple averages of the poll-interval. A poll interval average refers to the average time duration
between consecutive polling or measurement events in a network monitoring or performance measurement system. The poll interval
average provides an indication of how frequently the system collects data or samples network metrics over a specific time-period.
Convergence time refers to the amount of time it takes for the network to recover and resume normal operations after a failure
or disruption. However, the default convergence time for detection of slowly degrading WAN circuits is between 10 minutes
and 1 hour. Even with the lowest recommended poll-interval of 2 minutes and 6 intervals, the convergence time is between 2
minutes and 12 minutes. Setting a very low poll interval can result in false positives of PfR and traffic instability due
to insufficient sample data for loss, latency, and jitter measurements.
Without enhanced application-aware routing enabled, Cisco IOS XE Catalyst SD-WAN devices require several minutes to switch traffic from one network path to another to meet SLA requirements when the loss, latency,
and jitter exceed specific threshold values. Enabling enhanced application-aware routing speeds the detection of tunnel performance
issues. This enables Cisco IOS XE Catalyst SD-WAN device to redirect traffic away from tunnels that do not meet SLA requirements.
PfR measurements
Table 1. PfR measurements
Metric
Source
Description
Loss
BFD
Measured as loss of BFD packet at 1pps or one packet in n_app_probe_class (n-apc) sec
If the application probe class (APC) configuration is not set, the loss of BFD packets occurs at a rate of 1 packet per second
(1pps). With the APC configuration, the loss is reduced to 1 packet in N seconds.
RTT measurements 1 pps or one packet in n-apc sec
Without the application probe class (APC) configuration, the loss of RTT packets occurs at a rate of 1 packet per second
(1pps). With the APC configuration, the loss is reduced to 1 packet in N seconds.
Jitter
BFD
Variation in RTT
Application-aware routing design and measurements
The default BFD hello-interval is 1 sec, and the app-route/SLA poll-interval is 10 mins:
The BFD hello-interval refers to the frequency at which BFD (Bidirectional Forwarding Detection) protocol sends hello packets
to detect the liveliness of a network path. By default, the hello-interval is set to 1 second. On the other hand, the app-route/SLA
poll-interval determines how frequently the network monitoring system collects data or measures network metrics related to
application routes or Service Level Agreements (SLAs). The default poll-interval for app-route/SLA is set to 10 minutes.
By default, the system calculates to 60 minutes using 1 pps x 600 sec x 6 buckets:
Refers to the calculation of a default value for the poll-interval in minutes. It calculates the interval by multiplying 1
packet per second (pps) by 600 seconds (10 minutes) and then multiplying the result by 6 buckets. The resulting value is 60
minutes, which is the default poll-interval.
Experts suggest using a poll-interval of 120 seconds (2 minutes) and a multiplier of 5, which results in a 10-minute interval.
This recommendation is often followed to achieve a specific monitoring frequency.
Reducing the poll-interval/multiplier helps improve detection time but may lead to false positives with a small number of
samples for PfR metrics:
Decreasing the poll-interval and/or the multiplier can enhance the speed at which network performance issues are detected.
However, reducing these values may also increase the likelihood of false positives, which is that the system may incorrectly
identify issues due to a small number of data samples. The detection time and the accuracy of PfR (Performance Routing) metrics
must be balanced.
The only option is to improve the measurement accuracy at a faster rate by reducing the BFD Hello interval:
To achieve a faster and more accurate measurement of network performance, the recommended approach is to decrease the BFD
hello-interval. Network path liveliness refers to the condition of the connectivity and availability of network paths. By
reducing the interval at which hello packets are exchanged, the liveliness of network paths can be detected more frequently,
leading to improved measurement accuracy.
Benefits of enhanced application-aware routing
Improved the PfR metrics (loss/latency/jitter) measurements by introducing inline data that allows for more accurate and detailed
measurements of these metrics. Inline data refers to the traffic that is processed and inspected directly at the edge of the
network, within the Cisco IOS XE Catalyst SD-WAN devices. Instead of routing all the traffic to a central location for analysis and security checks, inline data allows for real-time
inspection and decision-making at the network edge.
Quick Enhanced-App-Route Detection and SLA Enforcement, which involves reducing the PfR poll-interval to a very low value
(minimum of 10 seconds). This allows the Cisco IOS XE Catalyst SD-WAN devices to quickly detect any slow degradation of circuits. If a circuit fails to meet the SLA threshold, the tunnels are swiftly
switched out from SLA forwarding to ensure efficient and reliable network performance. SLA (Service Level Agreement) forwarding
refers to the capability of the Cisco Catalyst SD-WAN solution to dynamically route network traffic based on predefined performance criteria or SLAs.
The speed of SLA switch-over is improved.
SLA Dampening is introduced for a smoother transition to SLA forwarding. Before implementing SLA forwarding again, the tunnel
goes through a process called dampening, which helps prevent disruptions and instabilities. This ensures a smooth transition
back to SLA, minimizing any negative effects on network performance.
Enhancements are made to measure loss, latency, and jitter.
Guidelines of enhanced application-aware routing
Both GRE and IPSEC tunnels are supported.
All existing TLOCs and WAN interface types, including physical, sub interface, loopback bind, dialer, and LTE interfaces,
are supported.
TLOC Extension tunnels are supported.
Both IPv4 and IPv6 underlay tunnels are supported.
SLA update and switchover occur at a minimum interval of 10 seconds.
Tunnel scale is not impacted, with minimal impact on memory and performance.
Support is provided with and without app-probe class configuration in SLA classes. For more information on app-probe class,
see Application Probe Class.
SLA dampening is supported.
Compatibility with Cisco IOS XE Catalyst SD-WAN devices not running enhanced application-aware routing
In the following scenario:
On the local side: The Cisco IOS XE Catalyst SD-WAN device is upgraded to Cisco IOS XE Catalyst SD-WAN Release 17.12.1a and later and has EAAR (Enhanced Application-Aware Routing) enabled.
On the remote side: The Cisco IOS XE Catalyst SD-WAN device is not upgraded to Cisco IOS XE Catalyst SD-WAN Release 17.12.1a and the EAAR is not enabled.
Then the system will fall back to using BFD based measurements where support compatibility with older releases and disabled
features are present.
If both the local and remote sides are using Cisco IOS XE Catalyst SD-WAN Release 17.12.1a but the EAAR feature is not enabled, the system will revert to using BFD based measurements.
Note
The EAAR feature is disabled by default to support existing deployments.
Supported devices for enhanced application-aware routing
Cisco IOS XE Catalyst SD-WAN devices
Restrictions for enhanced application-aware routing
The branch device on which you enable this feature does not support loopback unbind mode. The loopback unbind mode refers
to a network interface configuration in which the loopback device is disconnected from the network stack.
There is no per-queue measurement for GRE tunnels. Per queue measurement is used to monitor and analyze network traffic on
a per-queue basis. It involves measuring and collecting various metrics and statistics for each individual queue in a network
device or system. A queue is a buffer where packets are stored before they are transmitted or processed.
Prerequisites for enhanced application-aware routing
To enable application-aware routing on a Cisco IOS XE Catalyst SD-WAN device, enable enhanced application-aware routing on both the Cisco IOS XE Catalyst SD-WAN devices.
Configure enhanced application-aware routing
The procedures in this section describe how to deploy the enhanced app-aware routing configurations from Cisco Catalyst SD-WAN Manager to Cisco IOS XE Catalyst SD-WAN devices.
Use one of these methods to configure enhanced application-aware routing:
Configure enhanced application-aware routing using configuration groups
From the Cisco SD-WAN Manager menu, choose Configuration > Configuration Groups.
Choose a configuration group. Under Actions click Edit.
Under Feature Profiles click System Profile.
Choose basic and under Actions click Edit Feature.
In the Edit Basic Feature page, use the Enhanced App-Route field and choose one of the modes as follows:
Mode
EAAR poll interval
EAAR poll multiplier
EAAR poll window
SLA dampening multiplier
SLA dampening window
Aggressive
10s
6
10s - 60s
120
20 mins
Moderate
60s
5
60s - 300s
40
40 mins
Conservative
300s
6
300s - 1800s
12
60 mins
Click Save.
Configure enhanced application-aware routing using CLI commands
For more information about using CLI templates, see CLI Add-On Feature Templates and CLI Templates. By default, CLI templates execute commands in global configuration mode.
Enable enhanced PfR measurements for SLA enforcement.
bfd enhanced-app-route enable
Enabling the application-aware routing feature on a Cisco IOS XE Catalyst SD-WAN device requires you to enable the PfR CLI on both the remote Cisco IOS XE Catalyst SD-WAN device and the local Cisco IOS XE Catalyst SD-WAN device.
This feature involves two steps:
The remote Cisco IOS XE Catalyst SD-WAN device must provide loss statistics to the local Cisco IOS XE Catalyst SD-WAN device.
The local Cisco IOS XE Catalyst SD-WAN device then utilizes these metrics to enforce Service Level Agreements (SLAs).
When the enhanced application aware PfR is enabled, the default poll-interval of 10 seconds and multiplier of 6 is used for
SLA enforcement and switchover. To modify these settings, use the following configuration options:
bfd enhanced-app-route pfr-poll-interval
bfd enhanced-app-route pfr-multiplier <number>
The aggressive mode setting for app route pfr multiplier is 6 by default. It is 5 for the moderate mode.
Note
Use the bfd enhanced-app-route ignore-local-loss to ignore local loss on the router which is caused by QOS queues.
By default, loss includes both local and WAN loss.
Configure the SLA dampening time. This is the waiting time before returning the tunnel to SLA buckets after meeting the SLA.
The default time is 120 seconds. Enable the SLA dampening when the enhanced PfR is enabled.
bfd sla-dampening enable
bfd sla-dampening multiplier <number>
The aggressive mode setting for dampening multiplier is 120 by default.
Configure enhanced application-aware routing using templates
From the Cisco SD-WAN Manager menu, choose Configuration > Templates.
Click Feature Templates.
Click Add Template.
Choose a device and click the Cisco System template under Basic Information.
In the Enhanced App-Aware Routing field, click Global from the drop-down list and choose one of the following modes:
Mode
EAAR poll interval
EAAR poll multiplier
EAAR poll window
SLA dampening multiplier
SLA dampening window
Aggressive
10s
6
10s - 60s
120
20 mins
Moderate
60s
5
60s - 300s
40
40 mins
Conservative
300s
6
300s - 1800s
12
60 mins
Note
You can configure the enhanced application aware routing (EAAR) poll interval, poll multiplier, and SLA dampening multiplier
only through CLI template.
Click Save.
Verify the enhanced application-aware routing configuration
To verify the enhanced application-routing configuration and display the configured params for EAAR use the show sdwan app-route params command.
You can use the show sdwan bfd sessions alt command to highlight the flags for EAAR.
Device# show sdwan bfd sessions alt
*Sus = Suspend
*GREinUDP = GREinUDP encap
*EAAR = Enhanced Application-Aware Routing
*NA = Flag Not Set
SOURCE TLOC REMOTE TLOC DST PUBLIC DST PUBLIC
SYSTEM IP SITE ID STATE COLOR COLOR SOURCE IP IP PORT ENCAP BFD-LD FLAGS UPTIME
-------------------------------------------------------------------------------------------------------------------------------------------------------------
172.16.0.0 100 up lte lte 10.0.0.0 10.0.0.1 12367 ipsec 20013 NA 0:07:48:38
172.16.0.1 100 up lte lte 10.0.0.0 10.0.0.1 12377 ipsec 20014 NA 0:07:48:39
172.16.0.0 400 up lte lte 10.0.0.0 10.0.0.1 12366 ipsec 20015 NA 0:07:48:39
172.16.0.1 500 up lte lte 10.0.0.0 10.0.0.1 12366 ipsec 20016 EAAR 0:07:48:39
You can use show sdwan app-route stats summary command to display the app-route (PfR) stats details for each tunnel, across different intervals of measurements, for every
configured APC.
Device# show platform hardware qfp active feature sdwan datapath pathmon summary
Src IP Dst IP Src Port Dst Port Encap Uidb Bfd Discrim PathMon
------ ------ -------- ------- ------ ------- ----------- ------
10.0.0.0 10.0.0.1 12346 12366 IPSEC 65527 20003 in/out
Device# show sdwan bfd sessions alt
*Sus = Suspend
*GREinUDP = GREinUDP encap
*EAAR = Enhanced Application-Aware Routing
*NA = Flag Not Set
SOURCE TLOC REMOTE TLOC DST PUBLIC DST PUBLIC
SYSTEM IP SITE ID STATE COLOR COLOR SOURCE IP IP PORT ENCAP BFD-LD FLAGS UPTIME
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
172.16.0.0 100 down private1 lte 10.0.0.0 10.0.0.1 12367 ipsec 20011 EAAR NA
172.16.0.1 500 down private1 3g 10.0.0.0 10.0.0.1 12366 ipsec 20013 EAAR NA
172.16.0.0 600 down private1 3g 10.0.0.0 10.0.0.1 12366 ipsec 20007 EAAR NA
Feedback