Cisco IT is preparing our global WAN for employees’ growing use of third-party cloud services. Already we use more than 400 cloud services. The most popular are Cisco WebEx, Salesforce, SAP, and Office365.

One of our goals for changing the WAN is to minimize costs. The other is to make sure that the experience of using cloud services is as good as the experience of using CITEIS, our private cloud. CITEIS stands for Cisco IT Elastic Infrastructure Services.

Here are five ways we’re preparing our global WAN for growing use of cloud services.

1 – Split Tunneling
When we first started using third-party cloud services, all application traffic traveled to a Cisco data center before going out to the service provider. But that approach doesn’t make sense if you’re connecting to a cloud application, like WebEx. If I’m connecting to a U.S. cloud provider from a Cisco office in Milan, why should the request be routed first through the data center in London? That approach increases latency, which makes for a poor user experience.

So we’re starting to provide two WAN links for Cisco offices, starting in Europe. One link carries traffic for applications hosted in our private cloud, like email and Oracle customer-care applications. But web traffic, including third-party cloud services, goes out over a Layer 2 MPLS link. This WAN design is called split tunneling. It significantly offloads the global WAN. For example, approximately 15-25 percent of network traffic for the 25,000 employees who work from home at least one day a week now goes out over an Internet link.

Already, about 25 percent our remote offices have a direct Internet connection, and we’re quickly adding other offices. Adding a direct Internet connection to remote offices has the potential to lower our WAN circuit costs by 10 to 20 percent.

To protect end devices connected to commercial Internet services, we use Cisco Cloud Web Security. It blocks threats based on signatures and the website’s “reputation,” which is based on dozens of variables. Examples include the hosting country and how long the domain has been registered.

2 – Internet Handoff, to Adjust Bandwidth As Needed
Split tunneling allows us to use a smaller primary circuit for Cisco offices, because Internet traffic travels over the secondary circuit. But if the secondary circuit goes down, we need to temporarily add capacity to the primary circuit so that application performance ddoesn’tslow.

Internet handoff solves that challenge. It gives us the flexibility to add or subtract bandwidth based on need. For example, we can temporarily add 10 Mbps during a two-hour companywide video broadcast, or if the secondary circuit fails. Adding bandwidth is a logical change, not a physical change, so our service providers generally need only 48 hours’ notice.

3 – Carrier-Neutral Facilities
We’ve begun connecting larger Cisco offices to carrier-neutral facilities (see figure). These sites are shared by multiple ISPs and carriers—and recently, by more and more cloud service providers. Connecting directly into the buildings where cloud servers are located improves the user experience. Carrier-neutral facilities also give us a larger choice of ISPs, another way to control the user experience. We’re expecting the move to carrier-neutral facilities to lower WAN circuit costs because it’s easier to switch to a different ISP or carrier with a better price. All it takes to switch is a new cross-connect, not a whole new access circuit.


4 – WAN Optimization and Application Acceleration
Another way we’re making room for more cloud traffic is by making better use of our existing WAN bandwidth. Web traffic from Cisco offices to cloud service providers needs only about half the bandwidth it would otherwise because we use Cisco Wide-Area Application Services (WAAS). File transfer traffic uses 82 percent less space. As a result, 2 terabytes of transfers in April 2014 used only 351 GB. Another way that WAAS improves the user experience for software-as-a-service (SaaS) is by locally caching the websites.

5 – Software-Defined Networking and Performance Routing (PfR)
Our next project to adapt the WAN for more cloud services is to start using the secondary WAN link to Cisco offices. The secondary link generally has only 25 percent of the bandwidth capacity of the primary link. Until now, we only used the secondary link if the primary link went down. When we start using both links, the branch router will select the best path for each application by using Performance Routing (PfR), which is part of the Cisco IOS Software. PfR selects the best link based on reachability, delay, loss, jitter, opinion score (MOS), and link use or circuit pricing.

We expect cloud use to keep growing. As it does, the techniques I’ve described will help us control costs and the user experience.

For More Information