In the Cisco SD-WAN overlay network, VRFs divide the network into different segments.

Cisco SD-WAN employs the more prevalent and scalable model of creating segments. Essentially, segmentation is done at the edges of a router, and the segmentation information is carried in the packets in the form of an identifier.

The figure shows the propagation of routing information inside a VRF.

In this figure:

• Router-1 subscribes to two VRFs, red and blue.

  • The red VRF caters to the prefix 10.1.1.0/24 (either directly through a connected interface or learned using the IGP or BGP).

  • The blue VRF caters to the prefix 10.2.2.0/24 (either directly through a connected interface or learned using the IGP or BGP).

• Router-2 subscribes to the red VRF.

  • This VRF caters to the prefix 192.168.1.0/24 (either directly through a connected interface or learned using the IGP or BGP).

• Router-3 subscribes to the blue VRF.

  • This VRF caters to the prefix 192.168.2.0/24 (either directly through a connected interface or learned using the IGP or BGP).

Because each router has an OMP connection over a TLS tunnel to a vSmart controller, it propagates its routing information to the vSmart controller. On the vSmart controller, the network administrator can enforce policies to drop routes, to change TLOCs (which are overlay next hops) for traffic engineering or service chaining). The network administrator can apply these policies as inbound and outbound policies on the vSmart controller.

All prefixes belonging to a single VRF are kept in a separate route table. This provides the Layer 3 isolation required for the various segments in the network. So, Router-1 has two VRF route tables, and Router-2 and Router-3 each have one route table. In addition, the vSmart controller maintains the VRF context of each prefix.

Separate route tables provide isolation on a single node. So now the question is how to propagate the routing information across the network.

In the Cisco SD-WAN solution, this is done using VRF identifiers, as shown in the figure below. A VRF ID carried in the packet identifies each VRF on a link. When you configure a VRF on a Router, the VRF has a label associated with it. The Router sends the label, along with the VRF ID, to the vSmart controller. The vSmart controller propagates this Router-to- VRF-ID mapping information to the other Routers in the domain. The remote Routers then use this label to send traffic to the appropriate VRF. The local Routers, on receiving the data with the VRF ID label, use the label to demultiplex the data traffic. This is similar to how MPLS labels are used. This design is based on standard RFCs and is compliant with regulatory procedures (such as PCI and HIPAA).

It is important to point out that the transport network that connects the routers is completely unaware of the VRFs. Only the routers know about VRFs; the rest of the network follows standard IP routing.

The Cisco SD-WAN solution involves the use of VRFs to separate traffic.

Global VRF

The global VRF is used for transport. To enforce the inherent separation between services (such as prefixes that belong to the enterprise) and transport (the network that connects the routers), all the transport interfaces (that is, all the TLOCs) are kept in the global VRF. This ensures that the transport network cannot reach the service network by default. Multiple transport interfaces can belong to the same VRF, and packets can be forwarded to and from transport interfaces.

A global VRF contains all interfaces for a device except for the management interface, and all the interfaces are disabled. For the control plane to establish itself so that the overlay network can function, you must configure tunnel interfaces in a global VRF.For each interface in a global VRF, you must set an IP address, and you create a tunnel connection that sets the color and encapsulation for the WAN transport connection. (The encapsulation is used for the transmission of data traffic.) These three parameters—IP address, color, and encapsulation—define a TLOC (transport location) on the router. The OMP session running on each tunnel sends the TLOC to the vSmart controllers so that they can learn the overlay network topology.

Dual Stack Support on Transport VPNs

In the global VRF, Cisco IOS XE SD-WAN devices and vSmart controllers support dual stack. To enable dual stack, configure an IPv4 address and an IPv6 address on the tunnel interface. The router learns from the vSmart controller whether a destination supports IPv4 or IPv6 addresses. When forwarding traffic, the router chooses either the IPv4 or the IPv6 TLOC based on the destination address. But IPv4 is always preferred when configured.

Management VRF

Mgmt-Intf is the management VRF on Cisco IOS XE SD-WAN devices. It is configured and enabled by feault. It carries out-of-band network management traffic among the devices in the overlay network. You can modify this configuration if desired.

Mapping Host Names to IP Addresses

! IP DNS-based host name-to-address translation is enabled
  ip domain lookup
! Specifies hosts 192.168.1.111 and 192.168.1.2 as name servers
  ip name-server 192.168.1.111 192.168.1.2
! Defines cisco.com as the default domain name the device uses to complete
! Set the name for unqualified host names  
  ip domain name cisco.com

Verify Configuration

Run the show ip vrf brief command to view information about the VRF interface.

Device# sh ip vrf brief
  Name                             Default RD            Interfaces
  10                               1:10                  Gi4
  11                               1:11                  Gi3
  30                               1:30
  65528                            <not set>             Lo65528

Some straightforward examples of creating and configuring VRFs to help you understand the configuration procedure for segmenting networks.

Configuration on the vSmart Controller

On the vSmart controller, you configure general system parameters and the two VPNs—​VPN 0 for WAN transport and VPN 512 for network management—​as you did for the Cisco IOS XE SD-WAN device. Also, you generally create a centralized control policy that controls how the VPN traffic is propagated through the rest of the network. In this particular example, we create a central policy, shown below, to drop unwanted prefixes from propagating through the rest of the network. You can use a single vSmart policy to enforce policies throughout the network.

Here are the steps for creating the control policy on the vSmart controller:

1. Create a list of sites IDs for the sites where you want to drop unwanted prefixes:

   vSmart(config)# policy lists site-list 20-30 site-id 20
   vSmart(config-site-list-20-30)# site-id 30
   

2. Create a prefix list for the prefixes that you do not want to propagate:

   vSmart(config)# policy lists prefix-list drop-list ip-prefix 10.200.1.0/24
   

3. Create the control policy:

   vSmart(config)# policy control-policy drop-unwanted-routes sequence 10 match route prefix-list drop-list
   vSmart(config-match)# top
   vSmart(config)# policy control-policy drop-unwanted-routes sequence 10 action reject
   vSmart(config-action)# top
   vSmart(config)# policy control-policy drop-unwanted-routes sequence 10 default-action accept
   vSmart(config-default-action)# top
   

4. Apply the policy to prefixes inbound to the vSmart controller:

   vSmart(config)# apply-policy site-list 20-30 control-policy drop-unwanted-routes in
   

Here is the full policy configuration on the vSmart controller:

apply-policy
 site-list 20-30
  control-policy drop-unwanted-routes in
 !
!
policy
 lists
  site-list 20-30
   site-id 20
   site-id 30
  !
  prefix-list drop-list
   ip-prefix 10.200.1.0/24
  !
 !
 control-policy drop-unwanted-routes
  sequence 10
   match route
    prefix-list drop-list
   !
   action reject
   !
  !
  default-action accept
 !
!

CLI commands for monitoring segmentation (VRFs).

• show dhcp

• show ipv6 dhcp

• show ip vrf brief

• show igmp commands

• show ip igmp groups

• show pim commands