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.
The Direct Cloud Access IWAN 2.3 feature enables users at branch sites to have best application experience to SaaS applications,
such as, Office 365, Google services, with reduced cost. This feature helps in constantly monitoring network and application
performance and select the optimized paths (usually local break out from branch to Cloud SaaS applications instead of back-haul
to the data center). Non-SaaS traffic still back-haul to data center for further inspection.
Feature Information for Configuring Direct Cloud Access
The following table provides release information about the feature or features described in this module. This table lists
only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise,
subsequent releases of that software release train also support that feature.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco
Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
Table 1. Feature Information for Direct Cloud Access IWAN 2.3
Direct Cloud Access IWAN 2.3
Cisco IOS XE Fuji 16.8.1
The Direct Cloud Access (DCA) feature allows traffic from trusted applications, part of well-trusted domains, to pass the
local Internet security check because traffic from these trusted applications have a lower security risk than untrusted Internet
The following commands were introduced or modified: domain path, path-preference, show domain dca-status, show domain default border, show domain default policy, show domain vrf border channels, show domain vrf master channels.
Prerequisites for Configuring Direct Cloud Access
To enable a host that typically operates in a private network directly communicate with a SaaS application in a public network,
use a NAT. Enable NAT on the same router that has DCA enabled or other devices in the path.
To improve security, you can enable a firewall, such as a zone-based firewall (ZBFW), in the path.
By default OpenDNS is used as DNS resolver for SaaS traffic, but you can choose to use other DNS resolver such as Google DNS
resolver 220.127.116.11. OpenDNS license/registration is not a must if you don't need OpenDNS security services.
Restrictions for Configuring Direct Cloud Access
IPv6 address is not supported.
DCA is not supported if the DNS traffic does not pass through the router which is enabled with DCA.
DCA does not work if SaaS applications use proxy. All traffic going to proxy server as DCA may not classify these applications
and cannot perform local breakout for traffic that is bound to proxy.
Applications that directly access the content and not through DNS resolution, NBAR may fail to classify as SaaS and cannot
provide local break-out.
DCA may not work on a device when NBAR classification results are not available on the device. You must customize NBAR to
classify the results to support DCA.
This feature depends on applications classification. SD-AVC helps in better classification with NBAR.
To access SaaS applications, a public IP address is required. NAT helps translate the user’s private IP address to a public
IP address. Configure NAT on the border router that has DCA enabled, or on other internet-facing devices.
Information About Configuring Direct Cloud Access
Direct Cloud Access Overview
The infrastructure of cloud-hosted services, such as Microsoft Office 365 and Google Apps, is in the cloud. Back-hauling traffic
from remote users and sites through the private WAN to the data center via Internet imposes additional bandwidth requirements
on the private WAN and may add latency to each connection. Moreover, private WAN connectivity is more expensive than direct
Internet connections, which could add a tremendous amount of cost to the equation.
The Direct Cloud Access IWAN 2.3 feature implements direct cloud access (DCA) on Cisco IWAN networks and allows trusted SaaS
traffic to be forwarded out over the optimized path (directly local break out) while other traffic still back-haul to headquarters
over VPN. DCA monitors the candidate path (DCA path, back-haul path to headquarter) performance and chooses the optimized
path in policy to get the best SaaS application performance. While adding direct Internet connectivity to the branch site
without back hauling to data center, IWAN DCA provides the security capability at branch site by enabling security features
like NAT and Firewall (Zone-based Firewall, Snort IPS, etc.) at branch sites.
DCA features include:
Automatic configuration of Cisco Umbrella Connector (supported from Cisco IOS XE Gibraltar 16.10.1)
Support for policy configured on a centralized hub, or per-site customized local policy
Customized local policy overrides global plicy.
If a hub connection goes down, local policy remains in effect.
Support for P2P interface, such as dialer interface, as DCA interface
Benefits of Direct Cloud Acces
Reduced operation cost as SaaS traffic no longer needs to go to headquarters which consume additional headquarter network
Business processes run faster through direct network access to the major cloud providers. A traffic classification mechanism
is required in order to achieve direct Internet access for selected cloud applications.
Direct Cloud Access Architecture
The overlay DMVPN WAN tunnels on a branch router are configured to dynamically learn the service provider they are connected
to. An underlay interface is identified as a direct access interface via configuration.
Packets from the LAN side on a branch site are sent over the overlay when packets do not match the criteria of the configured
application. When a flow matches the DCA criteria, the packets are directed to the DCA interface that is specified in the
path preference. DCA interfaces can be listed in the order of priority in the path preference configuration of the policy
for the application. The DCA interfaces are evaluated in the order of the configured path preference priority.
NBAR classification occurs at LAN ingress. NBAR provides the application ID, which is exported by the border router. If a
match occurs on the Master Controller for an application, the policy for the application is applied to the traffic class for
the specific flow.
The following figure explains the DCA functionality for Office365 application:
The following actions are performed to achieve DCA functionality:
Classify all the cloud applications based on the DNS.
Intercept DNS traffic and make decisions based on the classification.
If the traffic is from a trusted application, direct Internet access is provided. Ensure that security concerns are addressed
for the breakout traffic, which include, constant application monitoring, choosing network performance over candidate paths
(DCA path, back-haul path), selecting the optimized path according to policy (if DCA path is not good), back-hauling SaaS
traffic to data center and reverting back if DCA path recovered.
If the traffic is not from a trusted application, the traffic is passed it to the Headquarter for further security inspection
Route HTTP, HTTPS data traffic to Internet or Headquarter depending on the above decision.
Designate an Underlay Interface as Direct Access Interface
An interface of the border router must be designated as direct access interface. domain pathpath-namedirect-cloud-access command to specify the direct access interface. A service provider may have multiple links of direct access and each of the
direct access interface is measured independently.
When an interface is selected to be the direct access interface, all traffic to the whitelisted applications is directed through
the direct access interface. If there are multiple direct access interfaces, the traffic is directed on one direct access
interface depending on the performance metrics and policy.
Direct Cloud Access Components
Direct Cloud Access functionality has the following components:
Cisco Umbrella Connector
To achieve location proximity, the SaaS server must be closer to the branch router to achieve better application performance.
Generally, DNS requests for a SaaS application are destined to an enterprise DNS resolver. However, the DNS request must be
changed from enterprise DNS resolver to a public DNS resolver, such as, OpenDNS resolver or Google DNS resolver. The public
DNS resolver helps in placing the SaaS server closer to the branch router by using Cisco Umbrella connector. OpenDNS account
and registration is not mandatory.
DNS requests must be unencrypted traffic from the endpoint to the DNS server. Each direct access interface must be configured
with Open DNS.
Network Based Application Recognition (NBAR) is a classification engine that recognizes and classifies a wide variety of protocols
and applications. NBAR uses several classification information metadata such as application name, ID, traffic class, business
relevance, and so on.
For Direct Cloud Access functionality, once NBAR recognizes the DNS traffic as belonging to interesting cloud application,
it attaches this information to DNS packet in a way so that the umbrella connector feature can extract and use the information.
Cisco NBAR provides the first packet classification for some applications. Cisco NBAR uses DNS learning for application recognition
of user defined and predefined domains, Once the server is learned from the DNS response, traffic going to this server can
be classified as FIFO. SD-AVC also improves the first packet classification result.
Performance Routing Version 3
Performance Routing version 3 (PfRv3) delivers intelligent path control for application-aware routing across the WAN. Once
a DNS response is received, the data traffic (HTTP, HTTPS etc.) from cloud application is provided direct Internet access
(local break-out) or is sent to the headquarter for further security inspection.
IPSLA is enabled automatically by PfRv3 to probe each SaaS application over candidate paths by using IPSLA HTTP operation.
PfRv3 leverages the metrics reported by IPSLA to select the optimized path.
SaaS Reachability and Performance Management
Performance and reachability of each whitelisted application determines the path that an application takes. PfR measures the
reachability and performance of all VRFs and enables and shares one measurement across multiple VRFs.
One DSCP-agnostic channel is created as the next-hop for the direct access interface. The DSCP of DCA channel is configured
as FF. The routing protocol configured on the direct access interface determines the next hop for the channel.
After the channel next hop is up, the service is reached via next hop by using the following steps:
Application Domain Mapping
Application to domain URL and Differentiated Services Code Point (DSCP) mapping must be configured on the master controller
of each branch router so that IPSLA can measure the SaaS application using right domain and DSCP.
Reachability and Performance Probing
Measuring network characteristics is performed using IPSLA. IPSLA probes are not sent per VRF, instead, PFR creates a probing
layer for all the VRFs and path preferences in the VRFs in a domain. Reachability and performance can be verified per application
by using the show domain domain-nameborder dca command. This command provides information per application, per interface for a border router.
Traffic Steering and Flow Stickiness
When DCA is implemented on a network, traffic classes are automatically created for interested applications. The applications
configured in the policy includes path preferences, which corresponds to the respective DSCP configured per application.
When selecting a path, PfR assigns a path to a flow that is destined to a service, for example, Offic365. These flows might
traverse a NAT device or a firewall device that maintains the state for the flow sequence numbers. Changing the flow during
packet traversal may lead to flow reset. Therefore, when a path is selected, flows must align to that path only. If a path
is unreachable, the flow is reset by the client and retried. If the path experiences packet loss but still usable, new flows
are routed via alternate paths.
Local Policy Configuration
Direct Cloud Access (DCA) policy can be configured on a centralized hub, or it can be configured on any individual site as
a customized local policy. To configure local DCA policy, use the policy local type DCA command.
Customized local policy overrides global policy.
If a hub connection goes down, local policy remains in effect.
Example of Local Policy Configuration
policy local type DCA
class DCA sequence 4
match application ms-cloud-group saas-dca
path-preference DCA1 fallback DCA2
How to Configure Direct Cloud Access
Assign an Underlay Interface as Direct Access Interface
The following configuration snippet explains how to assign an Ethernet interface as direct access interface.
Define PfR Policy for SaaS Application on Hub Master Controller
The following configuration snippet explains how SaaS application policies are defined on hub master controller at a central
point and published to all branch sites. There is no need to define policies at each branch sites because branch sites still
have the capability to customize the interested SaaS.
Router(config)# domain iwan Router
Router(config-domain)# vrf green
Router(config-domain-vrf)# master hub
Router(config-domain-vrf-master)# class BUSINESS-CRITICAL sequence 10
Router(config-domain-vrf-master-class)# match app-group ms-cloud-group policy custom
Router(config-domain-vrf-master-class-match)# priority 1 delay 500 ms
Router(config-domain-vrf-master-class)# path-preference ATT-DCA fallback ATT next-fallback INET
Define SaaS Application Mapping on Branch Master Controller
To measure the SasS application’s reachability and performance, the domain URL and DSCP must be specified for IPSLA probing
for each SaaS application.
Use HTTP ping to probe a specific SaaS to determine reachability and performance. The system has built-in default URL domains
for popular SaaS applications. For a complete list, use show domain xxx master dca domain-map.
If there are multiple VRFs, IP SLA probing is performed for all domains defined for each VRF and the same IP SLA ID is used
for each domain group in the VRF.
If a desired SaaS is not included in the list, create a domain map for the service in PfRv3. For example, to add Servicenow:
By default, DNS requests for white-listed SaaS are intercepted by Umbrella, and the OpenDNS resolver is used to achieve location
Optionally, configure a specific DNS resolver, either on a hub master controller or on an specific branch master controller.
Configuring a DNS resolver on a specific branch overrides, for that branch, the DNS resolver configured on the hub.
Use the following on a hub master controller to configure a DNS resolver for all DCA branches.
The HTTP ping probe uses a default probe interval of 30 seconds.
Optionally, you can configure a specific interval on the hub master controller, which applies the change to all DCA branches,
or to a branch master controller, to change the interval for a specific branch.
Use the following on a hub master controller to configure the interval for all DCA branches.
Verify and Monitor Direct Cloud Access Configuration
Use the following commands to verify and monitor DCA configuration.
show domain iwan master traffic-classes summary
show domain iwan master traffic-classes detail
show domain iwan master traffic-classes dca detail
show domain iwan master traffic-classes dca application
show domaindomain-nameborder dca
Displays information about reachability and metrics collected for all paths towards a service. This command helps in understanding
the behavior of various paths for a service and how PFR is selecting the best paths depending on the metrics.
Displays the default policy on the master controller.
Device# show domain default master policy
No Policy publish pending
class SOCIAL-NETWORKING sequence 11
class type: Application Based
match application skype policy custom
priority 1 delay threshold 500 msec
To troubleshoot, use debug domain default master dca and debug domain default border dca commands.
Configuration Examples for Configuring Direct Cloud Access
Example: Configure DCA Link on a Single Branch Router
In this example, DCA is configured on Cisco IWAN network with a single branch router as shown in the following topology.
Beginning with Cisco IOS XE Gibraltar 16.10.1, the Umbrella service configuration is automatic.
DCA is configured on WAN underlay interface in order to distinguish tunnel WAN interface.
interface GigabitEthernet0/0/3 ! INET branch WAN DCA interface
domain iwan path DCA1 direct-cloud-access
Optionally, a second DCA can be created as WAN underlay interface.
The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use
these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products
and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.