Click here to request your free 14-day trial of Cisco Umbrella through NetCraftsmen today!

9/20
2018
Peter Welcher

Viptela Your WAN

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

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 info@netcraftsmen.com.

Peter Welcher

Peter Welcher

Architect, Operations Technical Advisor

A principal consultant with broad knowledge and experience in high-end routing and network design, as well as data centers, Pete has provided design advice and done assessments of a wide variety of networks. CCIE #1773, CCDP, CCSI (#94014)

View more Posts

 

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.