SD-WAN Overview: Software Defined Wide Area Network
It simplifies the WAN by using centralized control function to secure and intelligently direct traffic across network
It uses software to control the connectivity, management and services between branch routers or cloud instances
It decouples the control plane from forwarding plane of WAN routers
It simplifies the way big companies connect new links to branch routers, manage the way those links are utilized for Voice, Data and video traffic
SD-WAN supports multiple connection types – MPLS, Internet, LTE etc.
SD-WAN allows load sharing across multiple physical links of any sort to carry traffic without much engineering
It provides WAN simplification, lower costs, Bandwidth efficiency and seamless on-ramp to the cloud with significant application performance without sacrificing security and data privacy
It delivers optimal application performance under any network condition or congestion
It continuously adapts to changes in the network that could impact App performance including congestion, slowness & outages without manual intervention
SD-WAN provides ZTP i.e. zero touch provisioning
It follows whitelisting model i.e. every device should be authenticated and authorized using certificate or any other method
SDN: Software Defined Network
SDA: Software Defined Access – To manage Layer 2 devices from a server called DNAC
ACI: Application Center Infrastructure – To support nexus 9K devices in ACI mode – configuration and management will happen from APIC (Application Policy Infrastructure Controller)
SD-WAN – To manage WAN from a single place
vManage is for SD-WAN, APIC is for ACI and DNAC is for SDA
SD-WAN Solution and Architecture:
SD-WAN (Software-Defined Wide Area Networking) is a popular technology solution that simplifies the management and operation of a wide area network (WAN) by separating the network’s control and data planes
It is a software-based approach to wide area network (WAN) connectivity that enables enterprises to connect their branch offices, data centers, and cloud resources securely and reliably
It uses software-defined networking (SDN) concepts to manage and optimize WAN traffic
It abstracts the network’s underlying infrastructure and separates the control and data planes
SD-WAN offers centralized management and visibility, automation, and intelligent traffic routing, enabling enterprises to deploy, manage, and secure WAN connections easily
SD-WAN architecture utilizes a centralized controller that manages the network traffic, routing policies, security policies, and WAN links
AAR (Application Aware Routing)
To define the network characteristics requirements for an application & leveraging the calculated path liveness & quality measurement to influence the traffic path dynamically, providing the best experience for the applications at all times
For example, we can define AAR to choose MPLS circuit if the latency is >=100ms, loss is >=2% and jitter is >=50ms on Internet circuit, otherwise it will continue to use best route i.e. Internet.
Application performance can be increased without the need for WAN upgrades
How does SD-WAN work:
SD-WAN works by deploying a virtual overlay network on top of the existing physical network infrastructure
The overlay network abstracts the underlying transport network and creates a logical network that provides a secure, resilient, and high-performance connection between the enterprise sites
SD-WAN uses multiple network links, such as broadband, MPLS, LTE, and satellite, and intelligently routes traffic based on application policies and network conditions
SD-WAN works by utilizing software-defined networking (SDN) to optimize the traffic routing and management of WAN connections
SD-WAN uses a centralized controller to manage the network traffic, routing policies, security policies, and WAN links
The controller communicates with edge devices, such as vEdges and cEdges, to control the flow of data across the WAN
SD-WAN allows enterprises to utilize multiple network links, such as broadband and LTE, to improve network performance and reduce costs
The SD-WAN solution monitors the network conditions and application policies to optimize the traffic routing across the available network links
This enables enterprises to prioritize critical applications, such as voice and video, over non-critical applications, such as email and file transfers
Overall, SD-WAN provides a more agile, flexible, and cost-effective approach to WAN connectivity, enabling enterprises to improve network performance and reduce WAN costs while ensuring security and reliability
Benefits of Cisco SD-WAN Viptela:
Improved application performance
Enhanced security
Simplified operations
Reduced WAN costs
Increased business agility
How Cisco SD-WAN Viptela works:
Cisco SD-WAN Viptela uses a centralized policy-based management approach to configure and monitor network devices
It uses an overlay network architecture that abstracts the physical network infrastructure and provides secure, optimized, and application-aware connectivity
Cisco SD-WAN Viptela security:
Cisco SD-WAN Viptela provides security through various features such as end-to-end encryption, segmentation, application-aware security policies, and cloud-based security services
It also integrates with third-party security solutions such as firewalls, IPS/IDS, and malware protection
Cisco SD-WAN Viptela deployment options:
Cisco SD-WAN Viptela can be deployed on-premises, in the cloud, or as a hybrid solution.
It can run on physical or virtualized infrastructure and supports multiple hypervisors
Cisco SD-WAN Viptela licensing:
Cisco SD-WAN Viptela is licensed based on the number of vEdge & cEdge routers and the features required
The licenses can be perpetual or subscription-based
Cisco SD-WAN Viptela difference with traditional WAN technologies:
Cisco SD-WAN Viptela is different from traditional WAN technologies such as MPLS and VPNs as it provides secure, optimized, and application-aware connectivity over any transport medium
It simplifies operations, enhances performance, and reduces costs compared to traditional WAN technologies
There are three controllers used for network orchestration and management
vBond Orchestrator: responsible for authenticating and authorizing devices to join the network
vSmart Controller: responsible for managing and enforcing network policies and providing centralized control for routing decisions
vManage: responsible for providing a single pane of glass management for the entire network, including configuration, monitoring, and troubleshooting
Together, these controllers provide a comprehensive solution for managing and optimizing the network performance of Cisco SD-WAN deployment
The SD-WAN Viptela controllers do not sit in the Data Plane.
In the Cisco SD-WAN Viptela solution, the controllers (vBond, vSmart, and vManage) are part of the Management Plane, which is separate from the Data Plane
The Management Plane is responsible for managing and orchestrating the overlay network, while the Data Plane is responsible for forwarding packets between vEdg
v – Viptela
vManage – Management Plane – VM
vBond – Orchestration plane – VM
vSmart – Control Plane – VM
vEdge – WAN Edge Device – VM or Physical devices
vManage NMS (Network Management System) provides centralized management and monitoring of the network
vBond orchestrator is responsible for authenticating and authorizing the vEdge routers
vSmart controllers are responsible for policy and routing decisions.
vEdge routers are the edge devices that provide connectivity to branch offices, data centers, and cloud environments.
-
Right order to configure components is vManage –> vBond –> vSmart
-
VMs can be installed on-prem or cloud (cisco cloud also available)
-
All 3 controllers (vManage, vBond, vSmart) should be known to each other (authenticate and authorize themselves) before we configure managed devices
-
IP reachability should be there between 3 controllers
-
Login to vManage and add vBond IP address to issue the certificate to vBond for mutual authentication to happen
-
Login to vManage and add vSmart IP address to issue the certificate to vSmart for mutual authentication to happen
-
VManage will supply information of vBond to vSmart and information of vSmart to vBond
-
-
vEdge (WAN Edge device) is configured with IP address of vBond for communication to happen between vEdge and vBond and authentication will happen using certificate. Once Authenticated, vBond will provide the information of vManage and vSmart to WAN Edge device and vice-versa
OR
-
We can use PnP portal (Plug and Play) called as ZTP (Zero Touch Provisioning). We can define a URL into WAN Edge (vEdge), then WAN Edge will reach out to that URL and URL will provide information of vBond to WAN Edge and authentication will start, then WAN Edge will come to know about vManage and vSmart
-
Between every WAN edge device, there is an IPSec tunnel (can be disabled), one tunnel per transport (per circuit between Edges)
-
If there are multiple circuits (For Ex, Lease line, Broadband, MPLS ) between two WAN Edge devices, then there will be 3 IPSec tunnels
-
vSmart will help in formation of IPSec tunnel
-
WAN Edge software upgrades or configuration is downloaded from vManage
-
It is always suggested to have clusters setup for controllers to build redundancy to avoid single point of failure type of situations
Management plane (vManage): The vManage network management system provides a centralized dashboard for administrators to manage and monitor the SD-WAN Viptela solution. It allows administrators to configure policies, view network performance metrics, and quickly troubleshoot any issues
It does certificate management
Device registration – register WAN Edges, vBond, vSmart
It is responsible for central configuration management & system monitoring (full statistics)
The vManage is a fully manageable centralized portal to run and operate software defined network (SD-WAN)
The vManage controller that provides a single pane of glass GUI interface to easily deploy, configure, monitor and troubleshoot all Cisco SD-WAN components in the network
The vManage ensures that the vBond Orchestrator, vSmart Controllers, and WAN Edge routers are complying the rules and participating in the trust relationship by keeping track of the devices, certificates, and their trust levels
Centralized control plane policies configured through vManage are distributed to vSmart using NETCONF protocol and from vSMART, these policies are distributed to vEdges using OMP(Overlay Management Protocols) updates
EIGRP is not supported from vManage for vEdge devices, OSPF and BGP are supported
EIGRP is supported for cEdge devices
So key features include:
Network orchestration
Configuration management
Real-time monitoring
Analytics
Reporting
It also provides automation capabilities for provisioning and configuration changes
Cisco vManage deployment options:
Cisco vManage can be deployed as a virtual machine (VM) on-premises or in the cloud
It can run on VMware, KVM, or AWS platforms
Cisco vManage security:
Cisco vManage provides security through various features such as role-based access control (RBAC), Secure Sockets Layer (SSL) encryption, and two-factor authentication
It also integrates with third-party security solutions such as firewalls and malware protection
Cisco vManage Benefits: Some benefits are
Network management
Enhanced network visibility
Improved network performance
Reduced operational costs
Increased business agility
Orchestration Plane (vBond): vBond plays a critical role in Cisco SD-WAN architecture as an orchestrator of the overlay network. Its primary role is to authenticate and authorize the edge routers (vEdge routers) that join the overlay network
It onboards the devices
It will authenticate and inform WAN Edge about IP address of vSmart and vManage and vice-versa
It is used for initiating bring up process and securely onboarding the SD-WAN vEdge routers into the SD-WAN overlay
The vBond controller authenticates and authorizes the SD-WAN components onto the network
In the first step, it creates secure tunnel with vEdge and informs vSmart and vManage about its parameters like for instance IP address
The vBond orchestrator distributes the list of vSmart and vManage controller information to the vEdge (WAN Edge) routers
The vBond has to be fully connected with every device
Cisco vBond key features:
Device authentication and authorization
zero-touch provisioning
Secure communication
It also provides real-time visibility and analytics for the network
Cisco vBond device management:
Cisco vBond can manage a variety of Cisco devices including vEdge/cEdge routers that are part of a Cisco SD-WAN deployment
Cisco vBond security:
Cisco vBond provides security through various features such as certificate-based authentication, Secure Sockets Layer (SSL) encryption, and secure communication protocols
It also integrates with third-party security solutions such as firewalls and intrusion detection and prevention systems (IDPS)
Cisco vBond benefits: Some benefits are
Simplified network management
Enhanced network security
Improved network performance
Reduced operational costs
Increased business agility
Cisco vBond integration with other Cisco network management tools:
Cisco vBond integrates with other Cisco network management tools such as Cisco vManage and Cisco Identity Services Engine (ISE) to provide end-to-end network management and automation
Overlay Management Protocol (OMP):
OMP is used to distribute routing information across the SD-WAN overlay network, enabling each vEdge router to build a complete view of the network topology and make intelligent routing decisions based on business and application policies
OMP is designed to be lightweight and efficient, and it provides features such as encryption and authentication to ensure secure communication between the controllers and the routers
Control Plane (vSMART): The vSmart controller is the brain of the SD-WAN Viptela solution, responsible for the centralized management and control of the network. It provides real-time analytics and visibility into the network, allowing administrators to make informed decisions and quickly troubleshoot any issues
It is the brain of the SD-WAN overlay
Handles routing part
It establishes control connections with WAN Edges
vSmart controller uses a proprietary routing protocol called the Overlay Management Protocol (OMP) for overlay routing
All the route policies, route filtering, route manipulation will be done by vSmart
If vSmart is hosted in cloud, it forms DTLS tunnel with all of the WAN Edge devices
OMP Protocol works inside DTLS which will help in advertising the overlay prefixes (internal networks) to vSmart
vSmart will process the information and advertise the prefix information to other WAN Edge devices
vSmart will help in forming IPSec tunnel between 2 WAN Edge devices, vSmart will distribute the pre-shared keys
The vSmart builds and maintains the network topology and make decisions on the traffic flows
All the control plane policies, centralized data policies, and VPN topology policies are configured on vSmart by vManager
The vSmart controller disseminates control plane information between WAN Edge devices, implements control plane policies and distributes data plane policies to network devices for enforcement
It does all the complex work of path calculation, route advertisement etc. there by offloading the Data Plane to do only packet forwarding
It gets the subnet information from each edge routers and performs the path-calculations on the received information
It works as a BGP route-reflector because it shares the received routing information with other vEdge routers
Each edge router forms a routing neighborship to vSmart controller only
OMP (Overlay Management Protocol) in Cisco SD-WAN is used by vSmart to perform the routing functions
Centralised control plane policies configured through vManage are distributed to vSmart using NETCONF and from vSmart, these policies are distributed to vEdges using OMP updates
If vSmart is down:
WAN Edge routers will work with last known configuration received from vSmart
WAN Edge will be running for 43200 seconds (12 hours) and it will flush the information after that – timer can be set individually on all routers and vSmart
If WAN Edge router is down or reboots within those 12 hours, once it restores, it will flush the information
vSmart sends
- OMP routes
- TLOC routes (Transport Locator)
- Service routes (internal prefixes and networks of WAN Edge sites)
- IPSec SA parameters
- Centralized Routing (Global) Policies
So we need to have multiple vSmart’s (multiple OMP neighborship between WAN Edge routers and vSmart’s) for redundancy
OMP neighborship will be broken if there is no response, Hold down timer is 60 seconds (OMP Hold Time), 3 keep alive messages will be sent in those 60 seconds
Cisco vSmart key features:
Policy-based routing, centralized management, security, and automation
It also provides real-time visibility and analytics for the network
Cisco vSmart device management:
Cisco vSmart can manage a variety of Cisco devices including vEdge routers that are part of a Cisco SD-WAN deployment
Cisco vSmart security:
Cisco vSmart provides security through various features such as Secure Sockets Layer (SSL) encryption, certificate-based authentication, and secure communication protocols
It also integrates with third-party security solutions such as firewalls and intrusion detection and prevention systems (IDPS)
Cisco vSmart Benefits: Some benefits are
Simplified network management
Enhanced network security
Improved network performance
Reduced operational costs
Increased business agility
Data plane (vEdge): The vEdge routers are the physical devices that connect the network endpoints to the SD-WAN Viptela solution. They provide secure connectivity and routing between the branches, data centers, and cloud environments
It is data plane component
Routes data traffic
It has underlay and overlay routes
It will establish management connection with vManage (Management Plane) and control connection (OMP connection) with vSmart
It is responsible for forwarding packets based on decisions from the control plane (vSMART)
vEdge physical/virtual devices provide secure data-plane connectivity between the sites in the same SD-WAN overlay network
Once vBond onboards the vEdge device in the Cisco SD-WAN overlay network, then vEdge device establishes secure control connections with all the controllers (vBond, vManage, vSmart) where it receives configuration, policies and routing information
vEdge devices are responsible for establishing secure connections for traffic forwarding, security, encryption, Quality of Service (QoS) enforcement and more
The vEdge device establishes secure IPsec tunnels with other vEdges, which is part of the same SD-WAN overlay network, to forward data-traffic
There is a BFD Tunnel (Bidirectional Forward Detection) tunnel created between all WAN Edge routers for liveliness of WAN edge routers
Cisco WAN Edge devices:
Cisco offers a range of WAN Edge devices including
vEdge routers
ISR routers
ASR routers
Each device is designed for different use cases and deployment scenarios
Cisco WAN Edge devices network performance:
Cisco WAN Edge devices improve network performance through various features such as intelligent path selection, Quality of Service (QoS), and application optimization
They also support various transport types including MPLS, broadband, and cellular
WAN Edge devices Security:
Cisco ensures security in WAN Edge devices through various features such as certificate-based authentication, encryption, and secure communication protocols
They also integrate with third-party security solutions such as firewalls and intrusion detection and prevention systems (IDPS)
It is similar to VRF (Virtual Routing Forwarder)
There are three types of traffic in any infrastructure:
Underlay – connectivity with the ISPs, running routing protocols and establishing the connectivity with other devices
Overlay – tunnels created and traffic passing through those tunnels – Data plane traffic
OOB – Out Of Band management (helps when underlay goes down)
VPN ID 0 is used in SD-WAN Underlay (VPN Zero – Transport VPN)
The interfaces which are being used in Underlay network, which are used for establishing the connectivity or enabling the reachability with controllers and WAN Edge routers, these interfaces will part of VPN 0
VPN ID 512 is used for OOB (can be management network)
eth0 on vBond and vEdge is reserved for VPN 512
The interfaces which are receiving the actual data plane traffic will be part of Overlay
VPN ID 1 – 511 & 513 – 65535 is used in Overlay (Service VPN)
Any one available VPN ID will be used
Default username and password is admin/admin
Select the storage device as vdb, It will take some time to format the storage device
vmanage#show run
#conf t
#system
#host-name vManage-test
#system-ip 100.100.100.1 This is just an identification, not routable
#organization-name nwsknowledgebase.com
#site-id 1
#vbond 90.1.1.3 90.1.1.3 is vBond IP
#clock timezone <click tab to see the options>
#commit Commit is important to save the config
#end
vManage-test#show run system To see the system configuration
vManage-test#show run vpn 512 To see the OOB interface config
vManage-test#show int vpn 512 To see the interface details and status
#conf t
#vpn 512
#interface eth1
#ip address 192.168.100.2/24
#no shut
#exit
#exit
#commit
#exit
#ping 192.168.100.1 vpn 512 Default route takes vpn 0
vManage-test#show run vpn 0 To see the underlay interface config and tunnel interface (overlay) and what services are allowed and not allowed
vManage-test#show int vpn 0 To see the interface details and status
#conf t
#vpn 0
#interface eth0
#ip address 90.1.1.2/24
#no shut
#no ipv6 dhcp-client if IPv6 dhcp is enabled
#tunnel-interface Controllers will establish overlay tunnels with the all WAN edges, so need to make this as tunnel interface
#allow-service netconf Netconf is a service which is used for pushing the configuration to the devices
#allow-service ssh
#exit
#exit
#exit
#commit
#exit
Below services with allow/no allow comes by default for VPN 0, we can allow or remove manually
#allow-service icmp to #no allow-service icmp If we want to disable icmp for VPN 0
#allow-service dns
#allow-service dns
#allow-service https
#no allow-service ntp
#no allow-service stun
#ping 192.168.100.1 vpn 0 Default route takes vpn 0
#ping vpn 0 source eth1 8.8.8.8 To initiate ping on the transport VPN 0 from source interface eth1 to google dns
vManage-test#show ip route
#conf t
#vpn 0
#ip route 0.0.0.0/0 90.1.1.1 default static route
#commit
#end
Access https://192.168.100.2 (management IP) from browser
Login with admin/admin
We can see Dashboard, Monitor, Configuration, Tools, Maintenance, Administration, vAnalytics in the left pane
Click Settings under Administration to edit and setup
Organization name
vBond IP address
Controller Certificate Authorization:
Enterprise Root Certificate: To select Root CA Certificate
This certificate is called Root certificate
Copy the contents of Root Cert (certificate in Base64 encoding)
Paste the contents
Enable “Set CSR Properties” – if we have multiple vManage servers, the current vManage will act as Root CA server
Domain name: nwsknowledgebase.com
Give all the details as required
Click Import & Save
Now we upload Root CA to vManage, so vManage knows about Root CA
Manual: if we are going manual, then we can generate CSR directly
Now vManage should make a certificate request to Root CA with its private and primary key
Click Certificates under Configuration and click Controllers
Controller Type as vManage and hostname as vManage-test with system IP 100.100.100.1 etc.
Click … (3 dots, in the end) and click “Generate CSR” to copy the certificate contents
Share this CSR (Certificate Service Request) with certificate admin team to issue the certificate
Once certificate (base64 encoded) is received from the team which is called vManage certificate
Click “Install Certificate” to select the file OR paste the contents of certificate and click Install
Now vManage will be authorized
Note: Installing certificate will take around 1 minute. Control plane connections may flap but data plane traffic will not be impacted by this procedure
Basically the steps are
Add Device
Generate CSR
Upload Certificate
Update vBond
Click Devices under Configuration and click Controllers to see the Controller Types with Hostname, System IP, Site ID, Device status, Certificate status
Default username and password is admin/admin
Change the password of admin, otherwise we cannot add vBond to vManage with default creds
vbond#show run
#conf t
#system
#host-name vBond-test
#system-ip 100.100.100.2 This is just an identification, not routable
#organization-name nwsknowledgebase.com
#site-id 1
#vbond 90.1.1.3 local Its own IP address, 90.1.1.3 is vBond IP
#clock timezone <click tab to see the options>
#commit Commit is important to save the config
#end
vBond-test#show run system To see the system configuration
vBond-test#show run vpn 512 To see the OOB interface config
vBond-test#show int vpn 512 To see the interface details and status
#conf t
#vpn 512
#interface eth0 eth0 on vBond and vEdge is reserved for VPN 512
#ip address 192.168.100.3/24
#no shut
#exit
#exit
#commit
#exit
#ping 192.168.100.1 vpn 512 Default route takes vpn 0
vBond-test#show run vpn 0 To see the underlay interface config and tunnel interface (overlay) and what services are allowed and not allowed
vBond-test#show int vpn 0 To see the interface details and status
#conf t
#vpn 0
#interface ge0/0
#ip address 90.1.1.3/24
#no shutdown
#no ipv6 dhcp-client if IPv6 dhcp is enabled
#tunnel-interface Controllers will establish overlay tunnels with the all WAN edges, so need to make this as tunnel interface
#encapsulation ipsec
#allow-service netconf Netconf is a service which is used for pushing the configuration to the devices
#allow-service ssh
#exit
#exit
#exit
#commit
#exit
Below services with allow/no allow comes by default for VPN 0, we can allow or remove manually
#allow-service icmp to #no allow-service icmp If we want to disable icmp for VPN 0
#allow-service dns
#allow-service dns
#allow-service https
#no allow-service ntp
#no allow-service stun
#ping 192.168.100.1 vpn 0 Default route takes vpn 0
#ping vpn 0 source eth1 8.8.8.8 To initiate ping on the transport VPN 0 from source interface eth1 to google dns
vBond-test#show ip route
#conf t
#vpn 0
#ip route 0.0.0.0/0 90.1.1.1 default static route
#commit
#end
Access https://192.168.100.2 (vManage management IP) from browser and Login
We can see Dashboard, Monitor, Configuration, Tools, Maintenance, Administration, vAnalytics in the left pane
Click Devices under Configuration and click Controllers
Click Add Controller and select vBond
vBond Management IP address: 90.1.1.3
Username as admin and password which was setup in CLI
Generate CSR: uncheck to do it manually
Click Add
Note: To delete the vBond device, Click … (3 dots, in the end) and click Invalidate to remove the device
Here Root certificate will be pushed by vManage to vBond
Click Certificates under Configuration and click Controllers
Controller Type: vBond
Click … (3 dots, in the end) and click “Generate CSR” to copy the certificate contents
Share this CSR (Certificate Service Request) with certificate admin team to issue the certificate
Once certificate (base64 encoded) is received from the team which is called vBond certificate
Click “Install Certificate” to select the file OR paste the contents of certificate and click Install
Now vBond will be authorized and will show hostname, system IP etc.
Basically the steps are
Add Device
Generate CSR
Upload Certificate
Click Devices under Configuration and click Controllers to see the Controller Types with Hostname, System IP, Site ID, Device status, Certificate status
Default username and password is admin/admin
Change the password of admin, otherwise we cannot add vBond to vManage with default creds
vsmart#show run
#conf t
#system
#host-name vSmart-test
#system-ip 100.100.100.3 This is just an identification, not routable
#organization-name nwsknowledgebase.com
#site-id 1
#vbond 90.1.1.3 90.1.1.3 is vBond IP
#clock timezone <click tab to see the options>
#commit Commit is important to save the config
#end
vSmart-test#show run system To see the system configuration
vSmart-test#show run vpn 512 To see the OOB interface config
vSmart-test#show int vpn 512 To see the interface details and status
#conf t
#vpn 512
#interface eth1
#ip address 192.168.100.4/24
#no shut
#exit
#exit
#commit
#exit
#ping 192.168.100.1 vpn 512 Default route takes vpn 0
vSmart-test#show run vpn 0 To see the underlay interface config and tunnel interface (overlay) and what services are allowed and not allowed
vSmart-test#show int vpn 0 To see the interface details and status
#conf t
#vpn 0
#interface eth0
#ip address 90.1.1.4/24
#no shutdown
#no ipv6 dhcp-client if IPv6 dhcp is enabled
#tunnel-interface Controllers will establish overlay tunnels with the all WAN edges, so need to make this as tunnel interface
#allow-service netconf Netconf is a service which is used for pushing the configuration to the devices
#allow-service ssh
#exit
#exit
#exit
#commit
#exit
Below services with allow/no allow comes by default for VPN 0, we can allow or remove manually
#allow-service icmp to #no allow-service icmp If we want to disable icmp for VPN 0
#allow-service dns
#allow-service dns
#allow-service https
#no allow-service ntp
#no allow-service stun
#ping 192.168.100.1 vpn 0 Default route takes vpn 0
#ping vpn 0 source eth1 8.8.8.8 To initiate ping on the transport VPN 0 from source interface eth1 to google dns
vSmart-test#show ip route
#conf t
#vpn 0
#ip route 0.0.0.0/0 90.1.1.1 default static route
#commit
#end
Access https://192.168.100.2 (vManage management IP) from browser and Login
We can see Dashboard, Monitor, Configuration, Tools, Maintenance, Administration, vAnalytics in the left pane
Make sure vBond is already added and configured and functional in vManage
Click Devices under Configuration and click Controllers
Click Add Controller and select vSmart
vSmart Management IP address: 90.1.1.4
Username as admin and password which was setup in CLI
Protocol: DTLS
Generate CSR: uncheck to do it manually
Click Add
Note: To delete the vSmart device, Click … (3 dots, in the end) and click Invalidate to remove the device
Here Root certificate will be pushed by vManage to vSmart
Click Certificates under Configuration and click Controllers
Controller Type: vSmart
Click … (3 dots, in the end) and click “Generate CSR” to copy the certificate contents
Share this CSR (Certificate Service Request) with certificate admin team to issue the certificate
Once certificate (base64 encoded) is received from the team which is called vSmart certificate
Click “Install Certificate” to select the file OR paste the contents of certificate and click Install
Now vSmart will be authorized and will show hostname, system IP etc.
Basically the steps are
Add Device
Generate CSR
Upload Certificate
Update vBond
Click Devices under Configuration and click Controllers to see the Controller Types with Hostname, System IP, Site ID, Device status, Certificate status
We should get a license from Cisco to add WAN Edges
We need to have chassis and serial number details to add the device
VMs does not have chassis and serial no details, so Cisco gives vChassis number with virtual serial number known as Token (can be used only once)
To see the list of Device Models with Chassis number and Token details as per the license
Configuration –> Devices –> WAN Edge List
Physical devices can be vEdge, ISR Routers, ASR Routers (cEdge)
Virtual devices can be vEdge, Cloud Service Router with capability of SDWAN
Device Models are vEdge Cloud, CSR1000v etc.
Here we use vEdge Cloud Chassis number and Token for vEdge configuration
To find the physical device chassis and serial
#show certificate serial Physical device comes with certificate installed
vEdge will make request (vChassis + Token) to vBond to add in SD-WAN Environment
vBond will receive the request and mutual authentication should happen to make sure vEdge is the right (not malicious) one
So, we have the root certificate already installed in all the controllers. We can download and upload to vEdge Folder /home/admin and install the root certificate via CLI
When vBond responds after checking vChassis number and Token, vEdge will match the root certificate of the vBond with its own root certificate, if it matches, then both devices vEdge and vBond will communicate each other (mutual authentication)
vBond-test#show orchestrator valid-vedges Shows Valid Edges
Once vBond has approved any vEdge, that information will be sent to vManage and vSmart
Now vManage will issue the identity to vEdge (automatically generates CSR and certificate)
Administration –> Settings
WAN Edge Cloud Certificate Authorization: Automated OR Manual
Manual: we need to generate CSR and follow manual process (same as controllers)
vedge#show run
#conf t
#system
#host-name vEdge-test
#system-ip 100.100.100.11 This is just an identification, not routable
#organization-name nwsknowledgebase.com
#site-id 1
#vbond 90.1.1.3 90.1.1.3 is vBond IP
#clock timezone <click tab to see the options>
#commit Commit is important to save the config
#end
#conf t
#vpn 0
#interface eth0
#ip address 90.1.1.5/24
#no shutdown
#no ipv6 dhcp-client if IPv6 dhcp is enabled
#tunnel-interface Controllers will establish overlay tunnels with the all WAN edges, so need to make this as tunnel interface
#encapsulation ipsec
#allow-service netconf Netconf is a service which is used for pushing the configuration to the devices
#allow-service ssh
#exit
#exit
#exit
#commit
#exit
vEdge-test#show ip route
#conf t
#vpn 0
#ip route 0.0.0.0/0 90.1.1.1 default static route
#commit
#end
Root certificate to vEdge
Administration –> settings
Controller Certificate Authorization: Click Edit
Copy the Enterprise Root Certificate contents
Paste and make the file extension as .cer (rootcert.cer)
Transfer the .cer file to vEdge via winscp in Folder /home/admin
#show certificate install To see certificate is installed or not
#request root-cert-chain install /home/admin/rootcert.cer To install the certificate
This is to ensure that it understands and authorizes vBond
To see the list of Device Models with Chassis number and Token details as per the license
Configuration –> Devices –> WAN Edge List
Pick one related to vEdge device model and copy Chassis and Token
#request vedge-cloud activate chassis-number <chassis> token <token>
#show certificate serial To see device chassis number and serial number
vEdge details will appear in sometime related to chassis-number we selected
Configuration –> Devices –> WAN Edge List
We can see license is utilized and token replaced with serial number, Hostname (vEdge-test), System-IP will be shown for that license
Which means vEdge-test successfully added
Cloud Service Router with capability of SD-WAN
It is cisco based
We should get a license from Cisco to add WAN Edges
We need to have chassis and serial number details to add the device
VMs does not have chassis and serial no details, so Cisco gives vChassis number with virtual serial number known as Token (can be used only once)
To see the list of Device Models with Chassis number and Token details as per the license
Configuration –> Devices –> WAN Edge List
Physical devices can be vEdge, ISR Routers, ASR Routers (cEdge)
Virtual devices can be vEdge, Cloud Service Router with capability of SDWAN
Device Models are vEdge Cloud, CSR1000v etc.
Here we use CSR1000v Chassis number and Token for cEdge configuration
To find the physical device chassis and serial
#show certificate serial Physical device comes with certificate installed
cEdge will make request (Chassis + Token) to vBond to add in SD-WAN Environment
#request platform software sdwan vedge-cloud activate chassis-number <chassis> token <token>
vBond will receive the request and mutual authentication should happen to make sure cEdge is the right (not malicious) one
cEdge already has the root certificate which we installed already
When vBond responds after checking vChassis number and Token, cEdge will match the root certificate of the vBond with its own root certificate, if it matches, then both devices cEdge and vBond will communicate each other (mutual authentication)
vBond-test#show orchestrator valid-vedges Shows Valid Edges
Once vBond has approved any cEdge, that information will be sent to vManage and vSmart
Now vManage will issue the identity to cEdge (automatically generates CSR and certificate)
Administration –> Settings
WAN Edge Cloud Certificate Authorization: Automated OR Manual
Manual: we need to generate CSR and follow manual process (same as controllers)
#config-transaction
#hostname cEdge-test
#system
#system-ip 100.100.100.55
#site-id 5
#vbond 90.1.1.3
#organization-name nwsknowledgebase.com
#clock timezone GMT –5 30
#commit
#end
#config-tran
#interface GigabitEthernet1
#no shut
#ip add 1.1.1.3 255.255.255.252
#ip route 0.0.0.0 0.0.0.0 1.1.1.1
#exit
#interface Tunnel1
#no shut
#ip unnumbered GigabitEthernet1
#tunnel source GigabitEthernet1
#tunnel mode sdwan
#exit
#sdwan
#interface GigabitEthernet1
#tunnel-interface
#encapsulation ipsec
#allow-service sshd
#allow-service netconf
#allow-service all This may be required for tftp certificate transfer
#commit
#show sdwan running-config To see the SDWAN config
#copy tftp://2.2.2.2/rootcert.cer bootflash:rootcert.cer To copy cert file from tftp server
#dir bootflash: | i rootcert To see the file
#request platform software sdwan root-cert-chain install bootflash:rootcert.cer To install the certificate
#show sdwan certificate root-ca-cert
Feature Template: It is used to configure specific features or functions on a device, such as VPN, OSPF, or QoS. Feature templates can be applied to multiple devices to ensure consistent configuration
Some template types are below. Each type of template will be different for different models
System
VPN 0
VPN 512
Interface configuration (VPN Interface Ethernet)
OSPF
Banner
NTP
AAA
Each template will have pre-populated fields with below options (all or some or anyone)
Global
Device Specific – if any field is selected with this option, we cannot set the value, then it has to be edited when device template is pushed to the device as per its device configuration
Default
Configuration –> Templates –> Feature
Click Add Template
Select Device type/model in left pane to see the available template types
Select any template to see the fields
Device Template: To define the overall configuration of a device, including the hostname, IP address, and other basic settings
Device templates can be used to configure new devices quickly and easily, and they can be customized for specific device types or locations
All or some feature templates will be linked to Device template and attach the device template to devices wherever we want to push the configuration
Configuration –> Templates –> Device
Click Create Template –> Select “From Feature Template”
Select Device Model
Give all the details as required and select feature templates as required in all the sections
There will be additional templates in right pane on every section, click + to add template type
Once Device templates are created, we can see the list
Click … (3 dots, in the end) on any device template name and select Attach Devices
Select the devices in Available section and move them to Selected devices and click Attach
Once attached, we can see the devices with Hostname, System IP and some fields will be empty because we selected Device Specific for few fields (unique fields) in feature template
Click … (3 dots, in the end) on each device and click Edit Device Template
Fill the fields as required for each device and click Update
As the configuration is update, now we need to push the device template configuration to device
Click Next
To see the Config Preview for each device. Select any Device in the left pane to see the device template configuration
To see the Config Difference between Local configuration vs New configuration. Select any Device in the left pane to see the device template configuration
Click Configure Devices if we are good with the new configuration
Enable Confirm configuration changes on devices and click OK
CLI templates: CLI templates are used to configure devices using CLI commands rather than the vManage GUI
CLI templates can be useful for advanced users who prefer to work with command-line interfaces, and they can be used to configure complex features or functions that are not available in the GUI
VPN ID 1 – 511 & 513 – 65535 is used in Overlay (Service VPN)
Any one available VPN ID will be used
vSmart forms DTLS tunnel with all of the WAN Edge devices
OMP Protocol (Overlay Management Protocol) works inside DTLS which will help in advertising the overlay prefixes (internal networks) to vSmart
vSmart will process the information and advertise the prefix information to other WAN Edge devices
vSmart will help in forming IPSec tunnel between 2 WAN Edge devices, so traffic between 2 vEdges will be encrypted and go through IPSec tunnel
OMP learns prefixes (internal networks behind site routers) automatically
So no redistribution is needed when the prefixes are being learned by OMP
But whatever subnets are in OMP has to redistributed towards OSPF
OMP (OMP neighborship) is used between WAN Edge routers and vSmart
OSPF or BGP –> OMP (automatic)
OMP –> OSPF (Manual)
When we use OSPF between site router and vEdge
And when advertise the subnets the Interface address/loopback address (subnets) via OSPF in Site Router
Note: State has to be POINT_TO_POINT (P2P) for the interfaces which has loopback addresses for OSPF to learn exact subnet mask, otherwise it will consider as host (/32)
#int lo0 OR int range lo0-2
#ip ospf network point-to-point
#end
The subnets will be automatically redistributed to OMP provided we have service VPN setup
#conf t
#vpn 100 service VPN ID is 100
#router
#ospf
#redistribute omp OMP is being redistributed into OSPF
#area 0
#interface ge0/1 vEdge interface connected to site router
#exit
#exit
#commit
#end
For Ex, vEdge-test1 is connected to site 1 router and advertised all the subnets
vEdge-test2#show ip routes
All the subnets which are behind site 1 router will show up here with VPN 100, ipsec (between WAN Edges), advertised by OMP
The subnets which are behind site 2 router (connected to this vEdge-test2) will show up here with VPN 100, no ipsec (as this is between site router and vEdge), advertised by OSPF IA (Inter Area)
It is used when we are dealing with OMP
OMP (Overlay Management Protocol) in Cisco SD-WAN is used by vSmart to perform the routing functions
Generally, when we check the route for any destination, we see next-hop address
In case of OMP, we see TLOC which tells through which transport a prefix has been advertised
Redistribution happens automatically from OSPF to the OMP
TLOC is a combination of three things:
System IP – non routable address, identifies that particular prefix has been advertised through which transport
Color – MPLS, Biz-internet etc.
IPSec or GRE (encryption that we are using to protect our data plane traffic), must be same on both the ends
vEdge-test#show ip route We can see all prefixes with protocols ospf, connected, omp
OMP will not have nexthop address and will have TLOC IP (system IP), color, ENCAP
#show ip route 2.1.1.1/24 To see the route for one prefix
#show ip route 2.1.1.1/24 detail To see the route for one prefix in detail
#show ip route omp We can see all omp routes
If another vEdge is advertising the prefix via mpls and bizinternet, then we see two entries for that prefix with different color but same TLOC IP
#show omp tlocs To see the detail of every TLOC entry
#show interface descripton
#show bgp summary
#show app cflowd flows | tab
#show app cflowd flows | i <ip>
#show app cflowd flows | i ge0/0
#show policy
#show control connections
#show system status
#show bfd sessions