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.
About SD-WAN
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:
Mandatory:
- 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
Desirable:
- Support for multi-tenancy on management platform (managed services provider support)
Possible Plusses:
- 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.
Insights
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!
Sample Configuration
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 1.1.0.0/16 for Internet, and 12.1.0.0/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 1.1.1.10
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 1.1.1.17/30
tunnel-interface
encapsulation ipsec
color gold
allow-service all
!
no shutdown
!
interface ge0/2
ip address 12.1.1.1/24
tunnel-interface
encapsulation ipsec
color mpls
allow-service all
!
no shutdown
!
ip route 0.0.0.0/0 1.1.1.18
ip route 0.0.0.0/0 12.1.1.2
!
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
The Viptela documentation. Pretty readable!
Comments
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 #Viptela #SDWAN
Twitter: @pjwelcher
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 info@ncm2020.ainsleystaging.com.