New Nexus 9K Items
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:
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:
Random other facts:
Viptela has contributed a couple of key insights as well:
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:
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 188.8.131.52/16 for Internet, and 184.108.40.206/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 220.127.116.11 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 18.104.22.168/30 tunnel-interface encapsulation ipsec color gold allow-service all ! no shutdown ! interface ge0/2 ip address 22.214.171.124/24 tunnel-interface encapsulation ipsec color mpls allow-service all ! no shutdown ! ip route 0.0.0.0/0 126.96.36.199 ip route 0.0.0.0/0 188.8.131.52 ! 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):
The Viptela documentation. Pretty readable!
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
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 email@example.com.
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” 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.