A centralized control policy is a policy that manipulates the route and tloc information that is exchanged between the vSmart controllers and the vEdge devices in the Cisco SD-WAN overlay fabric. It can influence the overlay topology of IPsec tunnels and the routing paths through the fabric. 

Types of Centralized Policies

Figure 1. Types of Centralized Policies

In Cisco SD-WAN, there are two types of Centralized Control Policies that fulfill different objectives:

  • Topology - Topology policies control the route information such as omp, tloc, and service routes that are being redistributed to a list of sites. As the name implies, they are typically used for limiting the number of overlay tunnels between sites and controlling the overlay topology.
  • VPN Membership - VPN Membership policies are used to control the distribution of routing information for specific VPNs to a list of sites. A typical use-case is for creating guest networks that have Internet access but site-to-site communication is restricted.

To fully understand why do we use centralized control policies, you need to have a good understanding of the control plane in the Cisco SD-WAN solution. Let's recall how it works.

Control Plane Overview

The Cisco SD-WAN Viptela solution is a Wide Area Network (WAN) overlay architecture that applies the principles of Software-Defined Networking (SDN) where the control plane of the network is completely separated and isolated from the data plane. In the Cisco SD-WAN, the vSmart controller represents the control plane of the overlay fabric and is effectively the centralized route engine that manages a network-wide routing table. It receives three types of route information from all WAN edge routers and builds a centralized route table. Then it redistributes this route information towards all vEdge devices.

IMPORTANT  It is very important to understand that WAN edge devices do not exchange any kind of control plane information, such as routes and tlocs, to one another.  

Figure 1 visualizes this concept. If vEdge-1 sends an OMP Update to the controllers, vSmart processes this message and if needed sends out an update to all other WAN edge devices. However, vEdge-1 would never send an OMP update directly to another vEdge router directly. 

Cisco SD-WAN Exchange of Control Plane information
Figure 2. Cisco SD-WAN Exchange of Control Plane information

Route Types

There are three types of OMP routes that the vSmart controllers learn from the WAN edge devices:

  • OMP routes - These routes represent prefix information that WAN edge devices learn from their local network. For example, these could be connected networks, static routes, or OSPF process running onsite redistributed into OMP.  The OMP routes could be displayed using the show omp command.
  • TLOC routes - These routes simply carry TLOC information from vEdges to the vSmart controllers. They could be displayed using the show omp tlocs command.
  • Service routes - These routes represent network services, such as firewalls and IPS, that are running on the local-site network to which
    the vEdge router is connected. They could be displayed using the show omp services command.

Centralized Control Policy

Network engineers that do not have any prior experience with SD-WAN solutions at first struggle to realize where the centralized policy is applied. That is why we tried to visualize where exactly the "magic happens". If you look at the diagram shown in figure 3, the red arrows represent a policy applied in the direction of the arrow. You can clearly see that an inbound control policy affects the OMP route information coming from vEdge routers before it is stored in the vSmart controllers' database. And an outbound one affects the OMP route advertisements from the controllers toward the WAN edge devices.

Cisco SD-WAN Centralized Control Policy Directions
Figure 3. Cisco SD-WAN Centralized Control Policy Directions

Default vSmart Behavior

As we have already learned, there is no centralized control policy configured on the vSmart controller by default. Therefore, by default, the controller acts in the following way:

  • Each vEdge device sends all site-local prefixes, tlocs, and service routes toward the controller using all established  DTLS control connections.  
  • The vSmart controller accepts all incoming OMP routes (omp, tloc, or service) and stores them in the respective route tables per VPN. 
  • The vSmart then redistributes all learned routes to all WAN edge devices. This results in a full-mesh overlay fabric and full IP reachability between all nodes.
  • Each vEdge device continually sends route updates.
  • The vSmart updates its routing table based on each update and advertises any routing changes to all edge devices.

Cisco SD-WAN Overlay behavior without Centralized Policy
Figure 3. Cisco SD-WAN Overlay behavior without Centralized Policy

vSmart Behaviour with Centralized Policy

As we said, the default behavior of the controller is to advertise all routes (omp, tloc, and service) which results in a full mesh overlay fabric and any-to-any IP reachability. However, in most cases, this is not the desired network outcome that companies require. Therefore, in most scenarios, the network topology should be customized and the IP reachability must follow the company's policy. 

When we want to control the route information that is stored in the controllers' route tables or the route information that is advertised to vEdges, we provision a Centralized Control Policy. When such a policy is applied, the behavior of the controllers change as follow:

  • When a Centralized Control Policy is applied in an inbound direction, it filters or modifies the route information that is coming from vEdges before it is placed in the controller's routing table. 
  • When a Centralized Control Policy is applied in an outbound direction, it filters or modifies the route information that is advertised to vEdges.  

Cisco SD-WAN Overlay behavior with Centralized Policy
Figure 4. Cisco SD-WAN Overlay behavior with Centralized Policy

Policy Components

Defining a new policy through the vManage Policy Wizard is a three steps process:

  • Step 1 - Create Groups of Interest. In Cisco IOS, there are a few types of lists that can identify specific groups of interest. Network engineers are pretty familiar with access-lists, prefix-lists, as-path lists, and so on. In Cisco SD-WAN there are even more and different types of lists such as site-lists, VPN lists, TLOC lists, and so on. However, the idea is pretty much the same, you just identify specific values of interest.
  • Step 2 - Configure Topology and VPN Membership. At this step, we define our Control and VPN membership policies that are used to manipulate the propagation of routing information in the control plane such as OMP and Transport Locator (TLOC) routes. A control policy is defined as a sequence of match-action statements. Typically a list created at step 1 is matched and then a specific set of actions is taken upon it. 
  • Step 3 - Apply Policies to Sites and VPNs. Cisco SD-WAN centralized policies are always applied to a site-list that identifies one or more site-ids. If the policy is applied in the inbound direction, it affects the route updates coming from the vEdge routers that have these site-ids. If the policy is applied in the outbound direction, the policy affects the OMP route advertisements from the vSmart controller to the vEdge devices with the specified site-ids.

Cisco SD-WAN Centralized Policy Components
Figure 5. Cisco SD-WAN Centralized Policy Components

Activating a Centralized Control Policy

In Cisco SD-WAN, vManage is the single pane of glass for administration and operation of the overlay fabric. This is the centralized tool where all configuration, management, and troubleshooting takes place. Of course, this includes the configuration of Centralized policies. 

When a Centralized Policy is defined and activated in vManage, vManage pushes that policy as a NETCONF transaction to the vSmart controllers. The policy itself is never pushed to the WAN edge devices, only the results of the policy are advertised by the vSmart controllers via OMP to the overlay. It is also important to mention that the vSmart controller only keeps the last configured policy in its configuration database. 

Ways to configure a Centralized Policy
Figure 6. Ways to configure a Centralized Policy

In a typical production deployment, there are at least two or three vSmart controllers that provide a control plane redundancy. In this scenario, it is the responsibility of vManage to ensure that the centralized policy configuration is synchronized across all controllers.  When a new policy is being applied, if for whatever reason it cannot be pushed successfully to one of the controllers, vManage automatically rolls back to all changes to the last synchronized configuration.