Anticipating Network Field Day 19
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.
Some of my prior blogs about Equinix (see References below) mentioned why one might center a WAN on Equinix.
Here’s the summary:
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:
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.
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!
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:
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.
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.
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 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
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 firstname.lastname@example.org.
Anticipating Network Field Day 19
Meraki SD-WAN and Insight
Viptela Your WAN
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 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.