The Business Need

Before we begin, let's first define what is a Software-as-a-Service (SaaS) application from a network perspective? Well, a SaaS application is just an enterprise-grade business application that is typically used over the Internet. The most popular SaaS applications at the moment are Microsoft Office 365, Google Workplace, and Salesforce. From a network standpoint, there is not much difference between a SaaS application and a regular Internet website. However, there is a huge difference from a business perspective! That is why SaaS applications are special and need to be treated differently because the business relies on these software-as-a-service apps, and when they are not working, the business is impacted.

So the business needs to make sure that these SaaS applications are available 24/7. But how do we achieve that with the traditional WAN approach of backhauling traffic over private WAN circuits to the data center via a hub-and-spoke architecture? This model is expensive, introduces unnecessary latency, creates a bandwidth bottleneck at the datacenter WAN links, and a performance bottleneck at the centralized security stack. This imposes major problems related to single-point-of-failures (the data center, the security stack), complexity, and user experience. The visibility into the application performance characteristics between the end-user and the Internet is also very limited.

Another aspect of the problem is the traditional network protocol stack. Even if we allow direct Internet access at branches, there is a very limited set of traditional protocols that can track the performance of a service on the Internet and route around a failure or performance degradation. But at the same time, Internet links do not have guaranteed quality, they can degrade at any given moment. Also, Internet Service providers (ISP) can suffer from outages, congestions, ongoing DDoS attacks, prefix black holes, and other conditions that can affect the reachability of Internet services. Security is another major factor that makes the tasks even harder. Opening the branches directly to Internet can expose them to cybersecurity vulnerabilities, would allow users to access unauthorized storage locations on the Internet, and would expose the company to sensitive data infiltration.

What is Cloud onRamp for SaaS?

Cloud onRamp for SaaS (formerly known as CloudExpress) is a set of Cisco SD-WAN capabilities designed to address the challenges that Software-as-a-Service applications impose on the wide-area network. In a nutshell, Cloud onRamp for SaaS lets us specify SaaS applications and DIA(Direct Internet access) interfaces and then allows only these pre-defined apps to break out to the Internet through the specified local DIA circuits while at the same time determines the best performing path for each SaaS app. Additionally, the solution continuously monitors each available path for each SaaS application, and in case of a problem with one path, it dynamically moves the SaaS traffic to an alternative one.

There are a few common architectures that we are going to go through in this lesson using the topology shown in figure 2:

• Scenario 1: Accessing SaaS applications through DIA Links at branches

• Scenario 2: Using the DIA link of a Gateway Site for redundancy

• Scenario 3: Direct Internet Access through Colos or CNFs

• Scenario 4: Direct Internet Access through Secure Web Gateways (SWGs)

Scenario 1: Accessing SaaS applications through DIA Links at branches

Organizations that use multiple inexpensive Internet links at remote branches can enable Cloud onRamp on the WAN edge router to permit traffic from selected SaaS applications to break out directly to the Internet. It is important to note that, only traffic from these SaaS applications will be allowed to use the local Intertnet links, while all other user flows will follow the regular overlay routing paths. 

When we specify a Software-as-a-Service App for Branch-1, the vEdge on-site performs the following steps visualized in figure 3:

1. The WAN edge router at Branch-1 performs DNS resolution for the configured SaaS applications separately over each ISP circuit. This implies that there must be a DNS server address in VPN 0 for each different Internet Service Provider. Note that most popular SaaS apps have their own worldwide networks and will resolve with different IP addresses in different regions/sub-regions of the world.
2. The WAN edge router at Branch-1 initiates periodic HTTPs pings to each configured Software-as-a-Service app. A Quality of Experience score (1-10) is then calculated based on packet loss and latency values reported by the HTTPs pings. This is done separately over each ISP circuit. The vEdge router then selects the path with the highest score as the best-performing path.

When a user onsite connects for the first time to one of the Software-as-a-Service apps, the user's device initiates a DNS query for the apps' URL, and the following chain of events visualized in figure 4 happen:

3. The WAN edge router's DPI engine intercepts the user's DNS query. If the host DNS query is for the Cloud onRamp SaaS application, the vEdge router forwards it over the best performing circuit to the DNS server that is defined for this ISP.
4. DNS queries for non-Cloud onRamp applications are forwarded according to the routing table towards the SD-WAN overlay fabric

5. When a user initiates a connection to the app, the WAN edge's DPI engine identifies that this flow is part of a Cloud onRamp for SaaS application and overrides the routing decision for it. The flow is rerouted through the best-performing Internet circuit that is configured for this Software-as-a-Service service. 

It is very important to note that all other users' flows that are not part of the Cloud onRamp will be routed using the traditional Cisco SD-WAN routing over the overlay fabric.

Scenario 2: Using the DIA link of a Gateway Site

In many production deployments, remote sites only have one Internet link which can be used for Direct Internet Access (DIA). In this scenario, the branch site can use a gateway site that has DIA links to the Internet for redundancy in case of its own Internet link degrades.

The Cisco SD-WAN can select the best connection for each application through the gateway site. If the remote site connects use more than one gateway site, SD-WAN ensures that SaaS traffic uses the optimal path for each app, even through different gateway sites.

The process is similar to the previous scenario with the only difference being the way the QoE score of the path via the gateway site is calculated.

1. The WAN edge router at Branch-1 and at the gateway site (the Regional Hub) perform DNS resolution for the configured SaaS application as is visualized in figure 6.

2. Both vEdge routers then initiate periodic HTTP probes toward the configured app.
3. The vEdge router at Branch-1 determines the best performing path toward the SaaS application based on the QoE score. 
   • Compares between the local Internet link's QoE score vs the composite metric of HTTP pings from the gateway vEdge (advertised via OMP, the blue line) + overlay tunnel health to gateway vEdge (the green dashed line)
   • The overlay tunnel health is determined using BFD

4. When a user onsite connects for the first time to one of the Software-as-a-Service apps, the user's device initiates a DNS query for the apps' URL, and the following chain of events happen:
5. The WAN edge router's DPI engine intercepts the DNS query
   • If the local DIA link is the best path, the router forwards the DNS query over the local Internet link
   • If the Gateway vEdge router (at the Regional Hub) is the best path, Branch-1's vEdge router forwards DNS query to the gateway vEdge router, which in turn forwards it to the DNS server defined locally over its local DIA circuit.
6. When a user initiates a connection to the app, the WAN edge's DPI engine identifies that this flow is part of a Cloud onRamp for SaaS application and overrides the routing decision for it. The flow is rerouted through the best-performing path.

Scenario 3: Direct Internet Access through Colos or CNFs

Some organizations do not want to allow direct Internet access at each and every remote branch and instead opt to use regional hubs to serve Internet traffic. These regional hubs can be hosted in 3rd party colocation facilities (Colos) or Carrier-Neutral Facilities (CNFs), and they can provide security capabilities with Next-Generation Firewall (NGFW) or Unified Threat Management (UTM).