• Author / Uploaded
• OSCAR

Citation preview

ABC of Cisco SDWAN Viptela

Today’s WAN Challenges

The Viptela Solution

Step 1 • Separate transport from the service side of the network.

Step 2 • Centralize routing intelligence and enable segmentation.

Step 3 • Secure the network automatically.

The Viptela Solution

Step 4 • Managed via Central managed engine vManage.

Step 5 • Influence reachability through centralized policy.

Step 6 • Cloud readiness

Agenda Viptela Solution Overview Lab Setup Secure Control Plane Bring up Secure Data Plane Bring up Device Configuration Lab vManage Dashboard Tour Basic Feature Templates OMP TLOC Policy QoS Troubleshooting

2 Viptela Solution Overview

SD-WAN Transformation Architectural Principles

Solution Elements Secure Extensible Network •vManage Network Management System (NMS)—The vManage NMS is a centralized network management system that lets you configure and manage the entire overlay network from a simple graphical dashboard.

•vSmart Controller—The vSmart controller is the centralized brain of the Viptela solution, controlling the flow of data traffic throughout the network. The vSmart controller works with the vBond orchestrator to authenticate Viptela devices as they join the network and to orchestrate connectivity among the vEdge routers.

•vBond Orchestrator—The vBond orchestrator automatically orchestrates connectivity between vEdge routers and vSmart controllers. If any vEdge router or vSmart controller is behind a NAT, the vBond orchestrator also serves as an initial NAT-traversal orchestrator.

•vEdge Routers—The vEdge routers sit at the perimeter of a site (such as remote offices, branches, campuses, data centers) and provide connectivity among the sites. They are either hardware devices or software, called a vEdge Cloud router, that runs as a virtual machine. vEdge routers handle the transmission of data traffic.

vEdge-1000 Hardware

vEdge-2000 Hardware

vEdge 100 Hardware

vEdge 100m Hardware

Of these four components, the vEdge router can be a Viptela hardware device or software that runs as a virtual machine, and the remaining three are software-only components. The software vEdge router, vManage NMS, and vSmart controller software runs on servers, and the vBond orchestrator software runs as a process (daemon) on a vEdge router.

OUR LAB SETUP

Branch Side vEDGEs BR1-VEDGE1 0 ge0/1 ipv4 172.16.3.2/30 Up Up 0 ge0/2 ipv4 10.20.20.2/24 Up Up 0 ge0/3 ipv4 10.10.10.1/24 Up Up 0 system ipv4 10.3.0.1/32 Up Up 10 ge0/0 ipv4 10.3.0.2/24 Up Up 20 Loopb 0 ipv4 20.20.20.20/32 Up Up 30 Loopb 1 ipv4 30.30.30.30/32 Up Up 512 eth0 ipv4 198.18.134.104/18 Up Up BR1-VEDGE2 0 ge0/1 ipv4 100.64.3.2/30 Up Up 0 ge0/2 ipv4 10.20.20.1/24 Up Up 0 ge0/3 ipv4 10.10.10.2/24 Up Up 0 system ipv4 10.3.0.2/32 Up Up 10 ge0/0 ipv4 10.3.0.3/24 Up Up 512 eth0 ipv4 198.18.134.105/18 Up Up -

BR2-VEDGE1 0 ge0/0 ipv4 172.16.4.2/30 Up Up 0 ge0/1 ipv4 100.64.4.2/30 Up Up 0 system ipv4 10.4.0.1/32 Up Up 10 ge0/2 ipv4 10.4.254.10/24 Up Up 512 eth0 ipv4 198.18.134.106/18 Up Up -

3 Introduction to Hands-on Labs Bringup Sequence of Events

The entire system bringup process includes these steps: 1.Install hypervisor (KVM) on the server (preconfigured). 2.Spin-up virtual machines on the server (preconfigured). 3.Install images for vManage, vBond, vSmart and vEdges on the virtual machines (preconfigured). 4.Create a minimal configuration for vManage (Deploy vManage section). 5.Create a minimal configuration for vBond (Deploy vBond section). 6.Create a minimal configuration for vSmart (Deploy vSmart section). 7.Enable connectivity between Controllers (Enable Inter-Controller Connectivity section). 8.Generate CSRs for each Controller (Overlay Connections section). 9.Sign certificates to validate and authenticate the Controllers. (Certificate Signature section). 10.Create a minimal configuration for vEdges and establish IP connectivity into the WAN circuits (Deploy vEdge section). 11.Verify that vEdge routers are able to reach the Controllers (vEdge Connections section). 12.Authenticate each vEdge router (Certify vEdges section). 13.Register each vEdge router with vManage (Register vEdge section). 14.Verify that the vEdge are up in the vManage dashboard (Verify SD-WAN Connectivity section).

Virtual Fabric Bringup

Secure Control Channel: Control Elements

WorkFlow

After the Viptela devices boot and start running with their initial configurations, the second part of the bringup process begins automatically. This automatic process is led by the vBond orchestrator, as illustrated in the figure below. Under the leadership of the vBond software, the Viptela devices set up encrypted communication channels between themselves. Over these channels, the devices automatically validate and authenticate each other, a process that establishes an operational overlay network. Once the overlay network is running, the Viptela devices automatically receive and activate their full configurations from the vManage server.

Establish vEdge Router Identity

Secure Control Channel: vEdge Routers Connection to vBond Orchestrator

Secure Control Channel: vEdge Routers Connection to vSmart Controller and vManage vSmart-2# show certificate installed

vSmart-2# show control connections

Please show me these from vManage as well …

WoW Done with Control Plan , Let’s check Data Plan

Traffic Encryption Unbreakable Traffic Privacy  Each vEdge advertises its local IPsec encryption key  Symmetric encryption keys used asymmetrically

Optimal Network Utilization for Application Traffic Path MTU Discover  Automatic and proactive Network  Path MTU Discovery Support for Host Path MTU Discovery  TCP MSS adjustment

Path Liveliness and Quality Measurements Bidirectional Forwarding Detection  Detects loss, latency, jitter and max-MTU for the IPSec tunnels between all vEdge routers in a given virtual topology  Helps take forwarding decisions based on actual underlying transport performance  Bi-directionally echoes liveliness messages - No BFD neighbors - High solution scale

Data (IPSec) Connections

Let us check this Via vManage ….

Configuration Elements in a Device System Configuration • System ip address (Unique) • Site-id • System Organization name (This needs to be the same for all ) • vBond ip address • Host-name (Unique) Device Specific configuration (Interface level) • Tunnel-interface VPN 0 • Management Interface VPN 512 • Service Interface VPN 1 – 511

CLI Configuration Example for vSmart vSmart# Config t (Start the configuration mode) Entering the configuration mode terminal (System entering into configuration mode) vSmart(config)# (system ready to accept configuration commands) vSmart(config)# system (starting System Mode) vSmart(config-system)#system-ip 12.12.12.12 (Assign system-ip- it should be a unique value) vSmart(config-system )# site-id 10 (Site-id’s can be shared with other devices on site vSmart(config-system)# commit (write the configuration changes to device Memory) Commit complete (system wrote all changes to memory) Check this Via CLI …

vEdge Configuration Components

SYSTEM Configuration Parameters

Transport & Service VPN Parameters

Just For Fun … Can you go to any Vedge and change the GPS under system and view it over vManage 

Check the restriction as well if any ..

Lab Time , lets check our lab setup #trouble ticket 1

Device Configuration Lab Objectives Learning Objectives : Outcomes – Understand the basic device parameters by reconfiguring the vEdge device. • Current State – One vEdge is down Working : • Log into vManage using admin as the user name and password • Look at vManage dashboard to evaluate which devices are down. • Once the devices are identified, build a plan on how to bring the devices up. (Hint – look at other similar devices or modify the basic parameters) • SSH into the vEdge. Bring up the device so that it becomes available on vManage(Remember the 5 parameters) • Success: Devices should be up with both control and data connections.

vEdge Status .. Some linux Skills  Step 1: Please execute the following commands to see the interface and control connections status.

Show interface description Show control connections ‘Show control connection-history’ provides the time at which the control connections were established. Step 2- For in-depth troubleshooting, Debugs can be turned on to view packet exchanges, events etc. Access debugs under /var/log/vdebug and for system level /var/log/dsyslog Step 3: Turn on ’debug transport’ Clear control connections Go to /var/log/vdebug to check the debug information