Viptela Your WAN
Infrastructure By Louis Spencer JR | September 24, 2018
NetCraftsmen has seen a big uptick in interest in Viptela SD-WAN lately. So, I thought a blog going over some Viptela basics might be of interest. I’m going to try to keep this simple and brief. Well, brief for one of my writing efforts.
Let’s start with, “what is SD-WAN?” The hype has gotten more than a little out of hand. There is something like 40+ vendors claiming to do SD-WAN.
To me, there are several key aspects that define SD-WAN:
WAN solutions supporting dual+ transport-based tunnels (usually MPLS + Internet or single / dual Internet, possibly with cellular backup) GUI-based automation of WAN / VPN tunnels between sites Dynamic routing and LAN-side routing interoperability, e.g. to steer traffic through the SD-WAN tunnels WAN tunnel condition awareness and app steering (packet loss, latency, jitter) Ease of use Support for multi-VRF segmentation
Support for multi-tenancy on management platform (managed services provider support)
WAN compression and acceleration (but is this declining in importance, in part as speeds go up and circuit prices fall?) Per-app metrics (monitor actual app experience rather than just link-based statistics — is this useful or just more complexity and performance drain?) Per-app quality enhancement (Forward Error Correction, send traffic along both paths, etc. — useful?) Branch security and DNS whitelist / routing options (quality of the firewall and application gateway code?)
Cisco Viptela meets the Mandatory and Desirable items above and is a solid example of SD-WAN.
Cisco Meraki is an automated firewall and VPN solution. Because it does not do dynamic path selection, nor app awareness and app path redirection, I do not consider it to be SD-WAN. It is SD-Firewall or maybe SD-VPN or SD-Branch.
Other vendors’ products may tout some of the items under “plusses” above.
After watching people struggle with MPLS VPN + IPsec VPN over the last decade plus, I’ll credit Cisco IWAN (and likely others) with a key insight:
If you tunnel all your WAN traffic, then you don’t end up with BGP + IGP redistribution ugliness — it’s all IGP routing!
Random other facts:
The Cisco EIGRP OTP solution (sort of route reflector for EIGRP with dynamic LISP tunneling of traffic) is another clever way of accomplishing the same end result. The EIGRP site-summary feature also helps with this — simpler redistribution filtering and EIGRP site stubbiness for IWAN.
Viptela has contributed a couple of key insights as well:
If you might be standing up your network of SD-WAN devices on the Internet, you need good security. With MPLS, there is control over who might be trying to connect to your VPN. With Internet, you need to protect against rogue SD-WAN devices. You don’t want someone with the virtual appliance code or a real appliance joining your tunnels — strong security controls are needed. What Is Viptela Networking Like?
There’s a bit to go into. Let’s save details for later blogs in order to focus on the overall feel of building a Viptela network. There are four basic phases:
Plan and order the physical or virtual appliances, circuits, etc. Bring up the basic control network Add / configure devices Add features Operate it
For the first of these, Plan and Order, that’s where a good consulting firm comes in. There’s one I can recommend…
For Bring Up, that’s a matter of getting the PKI infrastructure in place. Viptela has it pretty well-documented. The key is to bring up the three control components; vManage, vBond, and vSmart, and get them happily talking to each other. We’ll reserve more details for later — or see this document. See also the Viptela Bringup documentation, but don’t get scared off by it, the process is fairly straight-forward. I’ll add the word “certificates” here, but not pursue it further (TMI for this blog).
You can then Configure Devices, either via CLI or (better!) via templates. Templates can be built for specific generic configuration nuggets. Not surprisingly, these are called Feature Templates. You can then combine them with device-specific information in… wait for it… Device Templates.
You can build templates via the GUI, or via the CLI (with variable place-holders).
It took me maybe 10-15 minutes the first time through the template GUI, to get used to the template GUI. Powerful, so catching on to the way options are handled took a little time.
When you’re working with Device-Specific templates, you can “attach” it to one or more devices. You can then click and download a CSV, or view and edit the equivalent table in your web browser. The CSV has one column for each device-specific value the template needs. If you open the CSV in Excel, you can use that to enter the data, for one or multiple devices. Then re-upload. And then the system will configure the device(s) appropriately. Automation!
The neat thing here is that if you edit the template, you’ll get prompted to push the revised configuration out. That’s a lot of power, so use it responsibly!
Being a Cisco veteran, I like my config files. If for nothing else, a ZIP backup set of configs on my laptop, and for diff comparisons. How does one do a diff with a GUI-only product when trying to find out if anything changed just before the latest outage?
Viptela devices have config files. You can do one per device, but then you’re missing out on the power of automation. Templates!
Having said that, Viptela configurations are fairly readable.
Here’s an edited Viptela configuration for your reading pleasure (using 184.108.40.206/16 for Internet, and 220.127.116.11/16 for WAN):
system host-name vedge1 system-ip 172.16.0.11 site-id 10 no route-consistency-check organization-name “Corp-1234” vbond 18.104.22.168 aaa auth-order local radius tacacs usergroup basic task system read write task interface read write ! usergroup netadmin ! ! omp no shutdown graceful-restart advertise connected advertise static ! security ipsec authentication-type ah-sha1-hmac sha1-hmac ! ! vpn 0 interface ge0/1 ip address 22.214.171.124/30 tunnel-interface encapsulation ipsec color gold allow-service all ! no shutdown ! interface ge0/2 ip address 126.96.36.199/24 tunnel-interface encapsulation ipsec color mpls allow-service all ! no shutdown ! ip route 0.0.0.0/0 188.8.131.52 ip route 0.0.0.0/0 184.108.40.206 ! vpn 1 interface ge0/0 ip address 10.1.1.2/24 no shutdown ! ip route 0.0.0.0/0 10.1.1.1 ! vpn 512 interface eth0 ip dhcp-client no shutdown ! !
Note the brevity compared to, say, a Cisco router DMVPN configuration. Comparison of application SLA specifications and paths can end up similarly terse.
Explanation (of above Viptela configuration):
A VPN is similar to a VRF: an interface or sub-interface can belong to only one. The tunnel-interface line causes a GRE or IPsec tunnel to be used. Color is a name for a WAN transport, so “gold” might be one ISP (or several), and “mpls” might be your MPLS provider. So, VPN 0 sets up tunnels over each transport (to hub or other sites — details omitted for now). VPN 512 is a management VRF with a management interface in it. VPN 1 (and 2, etc.) are the various security segments, the service LAN interfaces. These are in effect the VRF’s LAN interfaces that get tunneled to the VPNs of the same number at the other sites. You’re probably wondering, “how does it know what to tunnel to?”. For instance, in DMVPN you have to identify the hub site. Well, that’s the job of the vSmart controller(s) — getting the sites talking to each other. References