Viptela SDWAN

You might also like

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 68

Cisco SDWAN

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
Why SDWAN ??
WAN Challenges
Market Player :
SDN & CISCO SDWAN
What is SDN?

In the SDN architecture, the control and data planes are


decoupled, network intelligence and state are logically
centralized, and the underlying network infrastructure is
abstracted from the applications…”
Where Cisco Stands in SDN Solution!!
Cisco Fabric Architectures
Cisco SDWAN : Top View
Cisco SD-WAN Solution Overview
Today’s WAN
Challenges
Viptela Solution Overview
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
SD-WAN Transformation
Architectural Principles
Solution Elements Secure Extensible Network
•vManage Network Management System (NMS)
•vSmart Controller
•vBond Orchestrator
•vEdge Routers
vEdge-1000 Hardware
vEdge-2000 Hardware
vEdge 100 Hardware
vEdge 100m Hardware
Viptela/ Partner Cloud
OUR LAB
SETUP
3 Introduction to Hands-on Labs
Bringup Sequence of Events
Day 02
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 ).
5.Create a minimal configuration for vBond (Deploy vBond ).
6.Create a minimal configuration for vSmart (Deploy vSmart ).
7.Enable connectivity between Controllers (Enable Inter-Controller Connectivity ).
8.Generate CSRs for each Controller (Overlay Connections ).
9.Sign certificates to validate and authenticate the Controllers. (Certificate Signature ).

  vEDGE Bringup

1.Create a minimal configuration for vEdges and establish IP connectivity into the WAN circuits (Deploy vEdge ).
2.Verify that vEdge routers are able to reach the Controllers (vEdge Connections ).
3.Authenticate each vEdge router (Certify vEdges ).
4.Register each vEdge router with vManage (Register vEdge ).
5.Verify that the vEdge are up in the vManage dashboard (Verify SD-WAN Connectivity).
Virtual Fabric Bringup
Secure Control Channel: Control Elements
Establish vEdge Router Identity
Secure Control Channel: vEdge Routers Connection to
vBond Orchestrator
Secure Control Channel: vEdge Routers Connection to
vSmart Controller and vManage
Verification
Verification
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
Recommendation
vManage Recommendation
A Viptela overlay network can be managed by one vManage NMS, or it can managed by a cluster,
which consists of a minimum of three vManage NMSs. It is recommended that you build a network,
especially a larger network, with a vManage cluster.

vBond Recommendation
It must have a public IP address so that all Viptela devices in the network can connect to it
(it is the only Viptela device that must have a public address). While the vBond orchestrator
can be located anywhere in the network, it is strongly recommended that you place it in a DMZ.

vSmart Recommendation
It is recommended that an overlay network have at least two vSmart controllers to provide redundancy.
A single vSmart controller can support up to 2,000 control sessions (that is, up to 2,000 TLOCs).
A vManage NMS or vManage cluster can support up to 20 vSmart controllers in the overlay.

vEdge Recommendation
An overlay network can consist of a few or a large number of vEdge routers.
A single vManage NMS, which provides management and configuration services to the vEdge
routers, can support up to about 2,000 routers, and a vManage cluster can support up to about 6K Routers
Data (IPSec) Connections

Let us check this Via vManage ….


Check bfd sessions, ip route etc ..
vManage Dashboard
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)
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)
vEdge Configuration Components
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
Task 1# Find you lab setup
Task 2 # From vManage login to all vEdges use both
Dashboard and CLI
Task 3 # troubleshooting, Bringup the vEdge
Refer lab setup details ::
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
Can you show me more of linux skills

http://linux-ip.net/html/tools-ip-route.html
Lab objective :
Please configure DC1 vEdge 1 with CLI
Templates
Use the Templates screen to configure all Viptela devices in the overlay network that are managed by the
vManage NMS. To do so:
1.Create a device template.
2.Attach Viptela devices to the device template.
Create a Device Template
Device templates define a device's complete operational configuration. A device template consists of a number of
feature templates. Each feature template defines the configuration for a particular Viptela software feature. Some
feature templates are mandatory, indicated with an asterisk (*), and some are optional. Each mandatory feature
template, and some of the optional ones too, have a factory-default template. For software features that have a
factory-default template, you can use either the factory-default template (named Factory_Default_feature-
name_Template) or you can create a custom feature template.
Create a Device Template from Feature Templates
Steps:
Create a Device Template from Feature Templates
Create a Device Template from the CLI
Edit a Template
View a Template
Delete a Template
View Device Templates Attached to a Feature Template
View Devices Attached to a Device Template
Perform Parallel Template Operations
On Viptela devices in the overlay network, you can perform the same operations, in parallel, from one or more
vManage servers.
Attach Devices to a Device Template
Copy a Template
Edit a CLI Device Template
Export a Variables Spreadsheet in CSV Format for a Template
Change the Device Rollback Time and View Configuration Differences
Available Feature Templates
AAA Multicast VPN Interface Cellular
Archive NTP VPN Interface Ethernet
Banner OMP VPN Interface GRE
BFD OSPF VPN Interface IPsec
BGP PIM VPN Interface NAT Pool
Bridge Security VPN Interface PPP
Cellular Profile SNMP VPN Interface PPP Ethernet
DHCP Server System WiFi Radio
IGMP VPN WiFi SSID
Logging VPN Interface Bridge

You might also like