SD-WAN plus Equinix equals Global WAN

Peter Welcher
Architect, Operations Technical Advisor

How do you build a global SD-WAN leveraging Cisco Viptela routers and Equinix Performance Hubs?

This blog describes a generic approach, informed by some ongoing design work. My intent is to provide you with some of the details to consider in creating a global WAN design based on the above.

Let me hasten to add, the concepts in this blog also apply if you have wide-spread U.S. or other continental presences.

For “Viptela” you might substitute your preferred SD-WAN vendor, changing the appropriate details. I’m impressed with and most familiar with Cisco Viptela’s approach and equipment.

And yes, the same concepts apply (to a degree) to using other CoLo / circuit provider / Internet and Cloud Provider datacenters.

Key Design Drivers

Some of my prior blogs about Equinix (see References below) mentioned why one might center a WAN on Equinix.

Here’s the summary:

  • Provide regional private WAN egress to Internet and Cloud Service Providers (CSPs), e.g. Amazon AWS, Azure, Google, etc.
  • Locate security equipment (firewall plus whatever) at a few locations to hold costs down and simplify management
  • Leverage competition between carriers for cost-effective circuit pricing, and/or leverage Equinix ECX for agile connectivity

As far as why use SD-WAN, agility and cost-savings can come into play. You can balance quality of transport against speed of deployment and cost. Multiple transport links might provide redundancy / high availability, with app-specific failover if service on one link becomes low quality. Some choices for transport:

  • Classic WAN / MPLS / EPL / whatever WAN link(s)
  • Internet link(s)
  • Cellular

For example, if you have a new office, you can stand it up with an Internet-based tunnel. If it is big enough or the project will last long enough, you can later get a carrier circuit installed. Once it is installed, Viptela can prefer the link with better service, or load balance, assuming you keep the local Internet to back up the WAN circuit. Or you can just run off two Internet links if desired, one backing up the other. Of course, if both have lousy quality at the same time, Viptela can only do so much to improve things.

Circling the Globe (or U.S.)

Here’s a sample:

The general point here is to (a) have redundancy and (b) put your Performance Hubs where your business is / minimize latency. Some like to have four Performance Hubs in the U.S. (East pair and West pair), some like six (East, Middle and West pairs). Etc.

Each situation has its own specific requirements, so that’s about as much as I can say here. I did want to sneak in a cool “circling the globe” diagram — goal accomplished!

What Does the Performance Hub Look Like?

My prior blog “Is Equinix Performance Hub Part of Your Future WAN” contains a diagram.

An enhanced version follows to make sure all readers are equally confused.

The key point is that the Performance Hub contains one or more switches, routers and firewalls — your choice. Add servers and other equipment as needed.

To keep costs down, I’m partial to one Rack Unit (RU) L3 switches if you don’t need a full router, as you may have noticed. You can use VRFs to segment “inside” from “outside / untrusted” if your security team will let you.

In the above diagram:

  • The blue lines convey the Viptela “WAN transport” network, which likely connects in-region WAN sites, and includes the links to the rest of the Performance Hub-centric backbone.
  • Red lines represent untrusted Internet or CSP links.
  • Green is “Performance Hub LAN”, trusted. That might connect e.g. trusted servers within the Performance Hub.

Most of this can be done with VLANs or physical links, your choice. Similarly, you can do “Firewall-on-a-Stick” or use separate “inside” and “outside” ports. On the switch, VLANs and VRFs provide segmentation. Or use several switches.

What’s not really visible in the diagram is the SD-WAN VPN tunnels. The regional sites will have VPN tunnels terminating on the Viptela vEdge router in the Regional Performance Hub.

There might also be tunnels associated with the blue WAN transport network — that’s what the blue link to the Viptela is for.

There might be tunnels associated with Internet transport. They would come in through the firewall (or bypass it, as the Viptela only allows VPN traffic in by default). They would enter the Viptela on the red link.

The green link on the Viptela is its trusted LAN interface. I think of this as the connection to the rest of the “site”, whether the site is a Performance Hub or an office / branch / field site.

Yes, you could use vEdge Cloud virtual Viptela directly to the CSPs and put your security there. This approach puts your hybrid control point(s) at Equinix, rather than virtualized and distributed across CSPs. Each approach has its pros and cons. Latency, cost of CSP egress traffic.

How Do I Connect the SD-WAN Equipment?

Usually we connect a site to two Regional Hubs.

As far as a site’s SD-WAN, it’s pretty much the same as in the above diagram. Imagine a diagram with WAN and Internet links above a Viptela vEdge router, and green LAN link connecting to the site switches below it.

Redundant Viptela vEdge devices? VRRP.

Test Yourself

Exercise for the reader: How does office site web browsing traffic get to the Internet?

Answer: A site’s Internet-bound traffic comes in the LAN interface on the site Viptela. It is then VPN tunneled across one of the transport networks (WAN or Internet) and in the relevant interface on the Performance Hub Viptela. It in turn forwards the traffic out the green LAN port, to the firewall green interface, and thence out the red firewall interface to the Internet.

Note that the traffic might have crossed the Internet twice, once in VPN tunneled form, and once as normally routed traffic.

NetCraftsmen and SD-WAN

NetCraftsmen does this stuff: design and implementation of SD-WAN networks and Equinix Performance Hubs.

We also have carrier and management partners that can be leveraged to obtain circuits for a transport network, and to provide a full managed SD-WAN / WAN network solution.



Comments are welcome, both in agreement or constructive disagreement about the above. I enjoy hearing from readers and carrying on deeper discussion via comments. Thanks in advance!


Hashtags: #CiscoChampion #Equinix #Viptela #SD-WAN

Twitter: @pjwelcher

Disclosure Statement
Cisco Certified 20 Years

NetCraftsmen Services

Did you know that NetCraftsmen does network /datacenter / security / collaboration design / design review? Or that we have deep UC&C experts on staff, including @ucguerilla? For more information, contact us at

Leave a Reply


Nick Kelly

Cybersecurity Engineer, Cisco

Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.


Virgilio “BONG” dela Cruz Jr.

CCDP, CCNA V, CCNP, Cisco IPS Express Security for AM/EE
Field Solutions Architect, Tech Data

Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.


John Cavanaugh

CCIE #1066, CCDE #20070002, CCAr
Chief Technology Officer, Practice Lead Security Services, NetCraftsmen

John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services.  Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.

He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.