Avatar

If you haven’t seen my colleague Ben Irving’s Network of the Future blog, I recommend you check it out. In this blog I’ll share what we’ve accomplished so far in terms of the new WAN architecture Ben describes here.

Why increase WAN capacity?

Two reasons. First, we need more capacity to keep delivering a great application experience from our private cloud. Employees in our 450 branch offices use the WAN to access applications for engineering, finance, marketing, HR, etc.

Second, we’re becoming a true multi-cloud company. We use almost 1000 cloud services, including Cisco Webex, Salesforce, Office365, and Box. Currently, more than 25% of traffic from our campuses and branch offices heads to public clouds. We expect that percentage to keep growing, so we need WAN capacity to carry that traffic reliably and securely.

Historically, when we needed more capacity we paid the service provider to bump up the guaranteed bandwidth (committed information rate) on our existing circuits. That’s quite costly in some regions, like the Middle East. Scaling WAN bandwidth also takes a lot of time and coordination because our various service providers and carriers use different systems and backend devices.

Now we’re switching gears by optimizing the capacity we already have, using SD-WAN technology. The bonus is that the same SD-WAN solutions also lower our operational costs in ways I’ll cover at the end of this blog.

Offloading traffic to the Internet

Today, Cisco sites receive one of several WAN services, depending on their size and availability requirements. Large offices and TAC sites get two MPLS circuits—one primary and one for backup. Midsize offices get one MPLS circuit and a VPN-over-Internet connection for backup. Smaller offices typically just have the VPN-over-Internet connection.

MPLS circuits are well worth the cost for our critical traffic because they’re fast and secure. But it’s harder to justify MPLS for backup circuits because they’re hardly ever used. So now we’re experimenting with giving large offices one MPLS and one Internet link. We use the Internet link not only for backup but also for less-critical traffic. Shifting less-critical traffic to the Internet frees up more capacity for critical traffic on the MPLS link—and also saves money.

Making this work requires two kinds of SD-WAN intelligence:

  • Recognizing the type of traffic currently flowing across the network. Does it have security or performance requirements that require it to go over MPLS?
  • Routing the traffic to the right link: critical traffic to MPLS, less-critical traffic to the Internet.

Viptela, our SD-WAN solution, does both. Part of Cisco IT’s mission is to be Cisco’s first customer—“customer zero”—for new products, like Viptela. Putting Cisco products to work to solve our own business needs gives us the chance to validate deployment guidelines, evaluate use cases, and recommend operational best practices for our customers. We’re currently conducting a pilot in nine midsize offices—three in Europe (Scotland, Manchester, and Prague) and six in the Americas (Glendale, Rancho Cordova, Pleasanton, Franklin, Richmond, and Irvine). We’re using Viptela to set policies for which application traffic travels over the primary (MPLS) and secondary (Internet) circuits. For example, video and engineering traffic always travel over MPLS because of their performance and security requirements, while email and web searches can go over the Internet. Based on initial testing, we expect to reduce overall load on the primary circuit at each local office by approximately 25%. You can read about the deployment details in this brief.

Saving money at the same time

In addition to freeing up WAN capacity, SD-WAN technology is also lowering operational costs, by:

  • Putting the idle secondary WAN link to work so that we don’t have to pay for more bandwidth.
  • Providing direct Internet access.
  • Enabling us to manage routing policy centrally from the Viptela cloud. This comes up when we need to apply a security patch, troubleshoot performance issues, or change a WAN security policy. Before, an engineer made the change device by device. With an SD-WAN controller, the engineer can define policy centrally and then push it out to all SD-WAN routers with a click. We expect automation to lower WAN operational costs by 30%.

Next steps

We’ll soon extend Viptela to a total of 25 sites—4 more in August and and the rest in the fall of 2018. In addition to offloading email and web searches to the Internet, we’ll also offload traffic from several business applications, including Webex, Box, iCloud, and Office365. We’ll load-balance this traffic across both circuits.

What are your hopes and plans for SD-WAN? Share them in the comment box.

Spanish version