Introduction

In the context of SD-WAN, virtual private networks (VPNs) play a crucial role in segmenting the network, similar to Virtual Routing and Forwarding instances (VRFs) that are commonly used. Essentially, VPNs create isolated environments where each network operates independently with its own dedicated forwarding table. When configuring an interface or subinterface, it is associated with a specific VPN and cannot be part of multiple VPNs simultaneously.

To ensure proper routing and identification, labels are employed within the OMP route attributes and packet encapsulation. These labels serve as markers that indicate which VPN a packet belongs to.

By using labels, the SD-WAN solution can accurately route traffic within the overlay network and maintain the isolation between different VPNs.

This segmentation enhances security, performance, and control within the SD-WAN architecture, allowing for efficient management of network resources and ensuring that data flows securely and accurately between VPNs.

In the SD-WAN architecture, VPNs are identified by a four-byte integer ranging from 0 to 65535.

By default, WAN Edge devices and controllers come with two primary VPNs: VPN 0 and VPN 512.

Note that vManage and vSmart controllers only allow configuration for VPNs 0 and 512, while the vBond orchestrator supports additional VPN configurations. However, for optimal functionality and adherence to best practices, it is recommended to utilize only VPN 0 and 512.

Cisco SDWAN default VPNs

• VPN 0: This VPN is known as the transport VPN, dedicated to the interfaces responsible for connecting to the WAN transports. It serves as the initiation point for establishing secure DTLS/TLS connections to the controllers. To ensure proper communication and reachability, it is essential to configure static or default routes, or even a dynamic routing protocol within this VPN. This allows the control plane to establish and facilitates the routing of IPsec tunnel traffic to remote sites.

• VPN 512: Designated as the management VPN, this VPN handles out-of-band management traffic to and from Cisco SD-WAN devices. OMP (Overlay Management Protocol) ignores this VPN, meaning it is not carried across the overlay network. VPN 512 is specifically designed to facilitate management-related operations, such as device monitoring, configuration, and troubleshooting. It ensures that management traffic remains separate from other data traffic flowing through the overlay network, enhancing security and control.

To illustrate this concept, consider the following figure depicting VPNs on a WAN Edge router:

In the above diagram, the WAN Edge router consists of some VPNs. The interfaces IF1 and IF2 are part of the transport VPN (VPN 0), responsible for connecting to WAN transports.

• IF3 is associated with the service VPN (VPN 10), which is connected to the local network at the site and carries user data traffic.

• IF4 and IF5 are associated with the service VPN (VPN-n), which is connected to the local network at the site and carries user data traffic.

• Lastly, the IF0 port is assigned to VPN 512, which is the management VPN responsible for handling out-of-band management traffic for Cisco SD-WAN devices.

Apart from the default VPNs, it is necessary to create one or more service-side VPNs that encompass interfaces connecting to the local-site network and carrying user data traffic. It is advisable to choose service VPN numbers within the range of 1-511, ensuring they do not overlap with default and reserved VPNs (0,512).

These service VPNs can be configured with various features such as OSPF or BGP routing protocols, Virtual Router Redundancy Protocol (VRRP) for high availability, quality of service (QoS) policies, traffic shaping, and policing.

It is worth noting that the depiction above showcases the representation of VPNs both on the vEdge router itself and within the vManage configuration interface.

However, when the configurations are deployed from vManage to the IOS XE SD-WAN routers, they undergo an automatic conversion process to conform to the format supported by the IOS XE SD-WAN software parser.

Here are some of the differences to take into account:

• VRF terminology is used instead of the VPN keyword

• The global table is used to represent VPN 0

• VRF Mgmt-intf is enabled by default on the management interface and is used to represent VPN 512

While IOS XE routers accept names for VRF definitions, with IOS XE SD-WAN code, VRF definitions must be numbers only.

Example 1: VPN configuration on Viptela OS (Controllers or vEdge)

vpn 0
 interface ge0/1
   ip address 192.168.1.10/24
   tunnel-interface
     encapsulation gre
     color blue
     allow-service dhcp
     allow-service dns
     allow-service icmp
     no allow-service sshd
     no allow-service ntp
     no allow-service stun
     !
   no shutdown
   !
 ip route 0.0.0.0/0 192.168.1.254
!
vpn 512
 interface eth0
  ip dhcp-client
  no shutdown
 !
!

Validation command-lines:

vEdge# show ip route vpn <VPN-ID>

vEdge# show run | section vpn

Example 2: VPN configuration on Cisco IOS-XE (cEdges)

!
 vrf definition 10
  rd 1:10
  address-family ipv4
   exit-address-family
!
interface Tunnel 10
  no shutdown
  ip unnumbered GigabitEthernet1
  tunnel source GigabitEthernet1
  tunnel mode sdwan
!
interface GigabitEthernet 1
 no shutdown 
 ip address 192.168.1.10 255.255.255.0
!
sdwan
  interface GigabitEthernet 1
   tunnel-interface
    encapsulation ipsec
    color lte
   !
 !
!
ip route 0.0.0.0 0.0.0.0 192.0.2.25
!

Validation command-lines:

cEdge# show ip route vrf <VPN-ID>

cEdge# show ip vrf brief

Get the Cisco SD-WAN Zero-to-One ebook