Centralized Control Policy Architecture
In the Cisco Catalyst SD-WAN network architecture, centralized control policy is handled by the Cisco SD-WAN Controller, which effectively is the routing engine of the network. The Cisco SD-WAN Controller is the centralized manager of network-wide routes, maintaining a primary route table for these routes. The Cisco SD-WAN Controller builds its route table based on the route information advertised by the Cisco vEdge devices in its domain, using these routes to discover the network topology and to determine the best paths to network destinations. The Cisco SD-WAN Controller distributes route information from its route table to the devices in its domain which in turn use these routes to forward data traffic through the network. The result of this architecture is that networking-wide routing decisions and routing policy are orchestrated by a central authority instead of being implemented hop by hop, by the devices in the network.
Centralized control policy allows you to influence the network routes advertised by the Cisco SD-WAN Controllers. This type of policy, which is provisioned centrally on the Cisco SD-WAN Controller, affects both the route information that the Cisco SD-WAN Controller stores in its primary route table and the route information that it distributes to the devices.
Centralized control policy is provisioned and applied only on the Cisco SD-WAN Controller. The control policy configuration itself is never pushed to devices in the overlay network. What is pushed to the devices, using the Overlay Management Protocol (OMP), are the results of the control policy, which the devices then install in their local route tables and use for forwarding data traffic. This design means that the distribution of network-wide routes is always administered centrally, using policies designed by network administrators. These policies are always implemented by centralized Cisco SD-WAN Controllers, which are responsible for orchestrating the routing decisions in the Cisco Catalyst SD-WAN overlay network.
All centralized control plane traffic, including route information, is carried by OMP peering sessions that run within the secure, permanent DTLS connections between devices and the Cisco SD-WAN Controllers in their domain. The end points of an OMP peering session are identified by the system IDs of the devices, and the peering sessions carry the site ID, which identifies the site in which the device is located. A DTLS connection and the OMP session running over it remain active as long as the two peers are operational.
Control policy can be applied both inbound, to the route advertisements that the Cisco SD-WAN Controller receives from the devices, and outbound, to advertisements that it sends to them. Inbound policy controls which routes and route information are installed in the local routing database on the Cisco SD-WAN Controller, and whether this information is installed as-is or is modified. Outbound control policy is applied after a route is retrieved from the routing database, but before a Cisco SD-WAN Controller advertises it, and affects whether the route information is advertised as-is or is modified.
Route Types
The Cisco SD-WAN Controller learns the network topology from OMP routes, which are Cisco Catalyst SD-WAN-specific routes carried by OMP. There are three types of OMP routes:
-
Cisco Catalyst SD-WAN OMP routes—These routes carry prefix information that the devices learn from the routing protocols running on its local network, including routes learned from BGP and OSPF, as well as direct, connected, and static routes. OMP advertises OMP routes to the Cisco SD-WAN Controller by means of an OMP route SAFI (Subsequent Address Family Identifier). These routes are commonly simply called OMP routes.
-
TLOC routes—These routes carry properties associated with transport locations, which are the physical points at which the devices connect to the WAN or the transport network. Properties that identify a TLOC include the IP address of the WAN interface and a color that identifies a particular traffic flow. OMP advertises TLOC routes using a TLOC SAFI.
-
Service routes—These routes identify network services, such as firewalls and IDPs, that are available on the local-site network to which the devices are connected. OMP advertises these routes using a service SAFI.
Default Behavior Without Centralized Control Policy
By default, no centralized control policy is provisioned on the Cisco SD-WAN Controller. This results in the following route advertisement and redistribution behavior within a domain:
-
All Cisco vEdge devices redistribute all the route-related prefixes that they learn from their site-local network to the Cisco SD-WAN Controller. This route information is carried by OMP route advertisements that are sent over the DTLS connection between the devices and the Cisco SD-WAN Controller. If a domain contains multiple Cisco SD-WAN Controllers, the devices send all OMP route advertisements to all the controllers.
-
All the devices send all TLOC routes to the Cisco SD-WAN Controller or controllers in their domain, using OMP.
-
All the devices send all service routes to advertise any network services, such as firewalls and IDPs, that are available at the local site where the device is located. Again, these are carried by OMP.
-
The Cisco SD-WAN Controller accepts all the OMP, TLOC, and service routes that it receives from all the devices in its domain, storing the information in its route table. The Cisco SD-WAN Controller tracks which OMP routes, TLOCs, and services belong to which VPNs. The Cisco SD-WAN Controller uses all the routes to develop a topology map of the network and to determine routing paths for data traffic through the overlay network.
-
The Cisco SD-WAN Controller redistributes all information learned from the OMP, TLOC, and service routes in a particular VPN to all the devices in the same VPN.
-
The devices regularly send route updates to the Cisco SD-WAN Controller.
-
The Cisco SD-WAN Controller recalculates routing paths, updates its route table, and advertises new and changed routing information to all the devices.
Behavior Changes with Centralized Control Policy
When you do not want to redistribute all route information to all Cisco vEdge devices in a domain, or when you want to modify the route information that is stored in the Cisco Catalyst SD-WAN Controller's route table or that is advertised by the Cisco Catalyst SD-WAN Controller, you design and provision a centralized control policy. To activate the control policy, you apply it to specific sites in the overlay network in either the inbound or the outbound direction. The direction is with respect to the Cisco Catalyst SD-WAN Controller. All provisioning of centralized control policy is done on the Cisco Catalyst SD-WAN Controller.
Applying a centralized control policy in the inbound direction filters or modifies the routes being advertised by the Cisco vEdge device before they are placed in the route table on the Cisco Catalyst SD-WAN Controller. As the first step in the process, routes are either accepted or rejected. Accepted routes are installed in the route table on the Cisco Catalyst SD-WAN Controller either as received or as modified by the control policy. Routes that are rejected by a control policy are silently discarded.
Applying a control policy in outbound direction filters or modifies the routes that the Cisco Catalyst SD-WAN Controller redistributes to the Cisco vEdge devices. As the first step of an outbound policy, routes are either accepted or rejected. For accepted routes, centralized control policy can modify the routes before they are distributed by the Cisco Catalyst SD-WAN Controller. Routes that are rejected by an outbound policy are not advertised.
VPN Membership Policy
A second type of centralized data policy is VPN membership policy. It controls whether a Cisco vEdge device can participate in a particular VPN. VPN membership policy defines which VPNs of a device is allowed and which is not allowed to receive routes from.
VPN membership policy can be centralized, because it affects only the packet headers and has no impact on the choice of interface that a Cisco vEdge device uses to transmit traffic. What happens instead is that if, because of a VPN membership policy, a device is not allowed to receive routes for a particular VPN, the Cisco Catalyst SD-WAN Controller never forwards those routes to that driver.
Examples of Modifying Traffic Flow with Centralized Control Policy
This section provides some basic examples of how you can use centralized control policies to modify the flow of data traffic through the overlay network.
Create an Arbitrary Topology
One way to minimize this overhead is to create a hub-and-spoke type of topology in which one of the devices acts as a hub site that receives the data traffic from all the spoke, or branch, devices and then redirects the traffic to the proper destination. This example shows one of the ways to create such a hub-and-spoke topology, which is to create a control policy that changes the address of the TLOC associated with the destination.
The figure illustrates how such a policy might work. The topology has two branch locations, West and East. When no control policy is provisioned, these two devices exchange data traffic with each other directly by creating an IPsec tunnel between them (shown by the red line). Here, the route table on the Device West contains a route to Device East with a destination TLOC of 203.0.113.1, color gold (which we write as the tuple {192.0.2.1, gold}), and Device East route table has a route to the West branch with a destination TLOC of {203.0.113.1, gold}.
To set up a hub-and-spoke–type topology here, we provision a control policy that causes the West and East devices to send all data packets destined for the other device to the hub device. (Remember that because control policy is always centralized, you provision it on the Cisco Catalyst SD-WAN Controller.) On the Device West, the policy simply changes the destination TLOC from {203.0.113.1, gold} to {209.165.200.225, gold}, which is the TLOC of the hub device, and on the Device East, the policy changes the destination TLOC from {192.0.2.1, gold} to the hub's TLOC, {209.165.200.225, gold}. If there were other branch sites on the west and east sides of the network that exchange data traffic, you could apply these same two control policies to have them redirect all their data traffic through the hub.
Set Up Traffic Engineering
The figure shows that Site ID 100 has two hub devices, one that serves the West side of the network and a second that serves the East side. Data traffic from the Device West must be handled by the Device West hub, and similarly, data traffic from the Device East branch must go through the Device East hub.
To engineer this traffic flow, you provision two control policies, one for Site ID 1, where the Device West device is located, and a second one for Site ID 2. The control policy for Site ID 1 changes the TLOC for traffic destined to the Device East to {209.165.200.225, gold}, and the control policy for Site ID 2 changes the TLOC for traffic destined for Site ID 1 to {198.51.100.1, gold}. One additional effect of this traffic engineering policy is that it load-balances the traffic traveling through the two hub devices.
With such a traffic engineering policy, a route from the source device to the destination device is installed in the local route table, and traffic is sent to the destination regardless of whether the path between the source and destination devices is available. Enabling end-to-end tracking of the path to the ultimate destination allows the Cisco Catalyst SD-WAN Controller to monitor the path from the source to the destination, and to inform the source device when that path is not available. The source device can then modify or remove the path from its route table.
As part of end-to-end path tracking, you can specify how to forwarded traffic from the source to the ultimate destination using an intermediate device. The default method is strict forwarding, where traffic is always sent from Device-A to Device-B, regardless of whether Device-B has a direct path to Device-D or whether the tunnel between Device-B and Device-D is up. More flexible methods forward some or all traffic directly from Device-A to Device-D. You can also set up a second intermediate device to provide a redundant path with the first intermediate device is unreachable and use an ECMP method to forward traffic between the two. The figure Traffic Engineering3 adds Device-C as a redundant intermediate device.
Centralized control policy, which you configure on Cisco Catalyst SD-WAN Controllers, affects routing policy based on information in OMP routes and OMP TLOCs.
This type of policy allows you to set actions for matching routes and TLOCs, including redirecting packets through network services, such as firewalls, a feature that is called service chaining.
In domains with multiple Cisco Catalyst SD-WAN Controllers, all the controllers must have the same centralized control policy configuration to ensure that routing within the overlay network remains stable and predictable.
Configure the Network Topology
When you first open the Configure Topology and VPN Membership screen, the Topology tab is selected by default.
To configure the network topology and VPN membership, see the following sections.
Configuration Components
A centralized control policy consists of a series of numbered (ordered) sequences of match-action pairs that are evaluated in order, from lowest sequence number to highest sequence number. When a route or TLOC matches the match conditions, the associated action or actions are taken and policy evaluation on that packets stops. Keep this process in mind as you design your policies to ensure that the desired actions are taken on the items subject to policy.
If a route or TLOC matches no parameters in any of the sequences in the policy configure, it is, by default, rejected and discarded.
The figure illustrates the configuration components for a centralized control policy.
Create a Hub and Spoke Policy
Procedure
Step 1 |
In the Add Topology drop-down, select Hub and Spoke. |
Step 2 |
Enter a name for the hub-and-spoke policy. |
Step 3 |
Enter a description for the policy. |
Step 4 |
In the VPN List field, select the VPN list for the policy. |
Step 5 |
In the left pane, click Add Hub and Spoke. A hub-and-spoke policy component containing the text string My Hub-and-Spoke is added in the left pane. |
Step 6 |
Double-click the My Hub-and-Spoke text string, and enter a name for the policy component. |
Step 7 |
In the right pane, add hub sites to the network topology:
|
Step 8 |
In the right pane, add spoke sites to the network topology:
|
Step 9 |
Repeat steps as needed to add more components to the hub-and-spoke policy. |
Step 10 |
Click Save Hub and Spoke Policy. |
Create a Policy for Mesh
Procedure
Step 1 |
In the Add Topology drop-down, select Mesh. |
Step 2 |
Enter a name for the mesh region policy component. |
Step 3 |
Enter a description for the mesh region policy component. |
Step 4 |
In the VPN List field, select the VPN list for the policy. |
Step 5 |
Click New Mesh Region. |
Step 6 |
In the Mesh Region Name field, enter a name for the individual mesh region. |
Step 7 |
In the Site List field, select one or more sites to include in the mesh region. |
Step 8 |
Repeat these steps to add more mesh regions to the policy. |
Step 9 |
Click Save Mesh Region. |
Custom Control (Route and TLOC)
Policy for a topology with a custom route and TLOC configuration.
Procedure
Step 1 |
In the Add Topology drop-down, select Custom Control (Route & TLOC). |
Step 2 |
Enter a name for the custom control policy component. |
Step 3 |
Enter a description of the custom control policy component. |
Step 4 |
Click Sequence Type. The Add Control Policy popup displays. |
Step 5 |
Click Route or TLOC to create a policy of that type. |
Step 6 |
Click Sequence Rule. |
Custom Control (Route)
Create a policy to apply on an OMP route. By default, the Match tab is selected, displaying match condition options.
Procedure
Step 1 |
From the Add Custom Control Policy screen, click Route. |
|||||||||||||||||||||||||||||||||
Step 2 |
Click Sequence Rule. Match and Actions options display. |
|||||||||||||||||||||||||||||||||
Step 3 |
From the Match tab, select and configure match conditions for your route.
|
|||||||||||||||||||||||||||||||||
Step 4 |
From the Actions tab, select IPv4, IPv6, or Both, to designate which protocol the actions should apply to. Not all of the following options are available for all protocols. |
|||||||||||||||||||||||||||||||||
Step 5 |
Click Accept or Reject for the IP traffic meeting the match conditions.
|
|||||||||||||||||||||||||||||||||
Step 6 |
Click Save Match and Actions. |
Create a Custom Control (TLOC)
Create a policy to apply to a TLOC. By default, the Match tab is selected, displaying match condition options.
Procedure
Step 1 |
From the Add Custom Control Policy screen, click TLOC. |
||||||||||||||||||||
Step 2 |
Click Sequence Rule. Match and Actions options display. |
||||||||||||||||||||
Step 3 |
From the Match tab, select and configure match conditions for your route.
|
||||||||||||||||||||
Step 4 |
Click Accept or Reject to apply the following match conditions to an action.
|
Import Existing Topology
Procedure
Step 1 |
In the Add Topology drop-down, select Import Existing Topology to open the matching popup |
Step 2 |
Under Policy Type, click the topology type you want to import:
|
Step 3 |
Select a policy from the field list. Cisco SD-WAN Manager populates this field from the available topologies for the type you select. |
Step 4 |
Click Import. |
Step 5 |
Click Save Control Policy to save the Route policy. |
Create a VPN Membership Policy
Procedure
Step 1 |
In the Topology bar, click VPN Membership. |
Step 2 |
Click Add VPN Membership Policy. The Update VPN Membership Policy popup displays. |
Step 3 |
Enter a name and description for the VPN membership policy. |
Step 4 |
In the Site List field, select the site list. |
Step 5 |
In the VPN Lists field, select the VPN list. |
Step 6 |
Click Add List to add another VPN to the VPN membership. |
Step 7 |
Click Save. |
Step 8 |
Click Next to move to Configure Traffic Rules in the wizard. |
Configure Centralized Policies Using Cisco SD-WAN Manager
To configure a centralized policy, use the Cisco SD-WAN Manager policy configuration wizard. The wizard consists of the following operations that guide you through the process of creating and editing policy components:
-
Create Groups of Interest: Create lists that group together related items and that you call in the match or action components of a policy.
-
Configure Topology and VPN Membership: Create the network structure to which the policy applies.
-
Configure Traffic Rules: Create the match and action conditions of a policy.
-
Apply Policies to Sites and VPNs: Associate the policy with sites and VPNs in the overlay network.
-
Activate the centralized policy.
For a centralized policy to take effect, you must activate the policy.
To configure centralized policies using Cisco SD-WAN Manager, use the steps identified in the procedures that follow this section.
Components of Centralized Policies
The following are the components required to configure a centralized policy. Each one is explained in more detail in the sections below.
policy lists color-list list-name color color prefix-list list-name ip-prefix prefix
site-list list-name site-id site-id tloc-list list-name tloc address color color
encap encapsulation [preference value] vpn-list list-name vpn vpn-id
control-policy policy-name
sequence number
match match-parameters
action reject accept export-to vpn accept set parameter
default-action (accept | reject) apply-policy site-list list-name control-policy policy-name (in | out)
Components for VPN Membership
The following are the components required to configure a VPN membership policy. Each one is explained in more detail in the sections that follow.
policy
lists
app-list list-name
(app applications | app-family application-families)
data-prefix-list list-name
ip-prefix prefix
site-list list-name
site-id site-id
tloc-list list-name
tloc ip-address color color encap encapsulation [preference value]
vpn-list list-name
vpn vpn-id
policer policer-name
burst bytes
exceed action
rate bandwidth
data-policy policy-name
vpn-list list-name
sequence number
match
app-list list-name
destination-data-prefix-list list-name
destination-ip prefix/length
destination-port port-numbers
dscp number
dns-app-list list-name
dns (request | response)
packet-length number
protocol number
icmp-msg
icmp6-msg
source-data-prefix-list list-name
source-ip prefix/length
source-port port-numbers
tcp flag
action
cflowd (not available for deep packet inspection)
count counter-name
drop
log
redirect-dns (dns-ip-address | host)
tcp-optimization
accept
nat [pool number] [use-vpn 0]
set
dscp number
forwarding-class class
local-tloc color color [encap encapsulation] [restrict]
next-hop ip-address
policer policer-name
service service-name local [restrict] [vpn vpn-id]
service service-name [tloc ip-address | tloc-list list-name] [vpn vpn-id]
tloc ip-address color color [encap encapsulation]
tloc-list list-name
vpn vpn-id
default-action
(accept | drop)
apply-policy site-list list-name
data-policy policy-name (all | from-service | from-tunnel)
Apply Centralized Control Policy in the CLI
You apply centralized control policy directionally:
-
Inbound direction (in )—The policy analyzes routes and TLOCs being received from the sites in the site list before placing the routes and TLOCs into the route table on the Cisco Catalyst SD-WAN Controller, so the specified policy actions affect the OMP routes stored in the route table.
-
Outbound direction (out )—The policy analyzes routes and TLOCs in the Cisco Catalyst SD-WAN Controller's route table after they are exported from the route table.
For all control-policy policies that you apply with apply-policy commands, the site IDs across all the site lists must be unique. That is, the site lists must not contain overlapping site IDs. An example of overlapping site IDs are those in the two site lists site-list 1 site-id 1-100 and site-list 2 site-id 70-130 . Here, sites 70 through 100 are in both lists. If you were to apply these two site lists to two different control-policy policies, the attempt to commit the configuration on the Cisco Catalyst SD-WAN Controller would fail.
The same type of restriction also applies to the following types of policies:
-
Application-aware routing policy (app-route-policy )
-
Centralized data policy (data-policy )
-
Centralized data policy used for cflowd flow monitoring (data-policy that includes a cflowd action and apply-policy that includes a cflowd-template command)
You can, however, have overlapping site IDs for site lists that you apply for different types of policy. For example, the sites lists for control-policy and data-policy policies can have overlapping site IDs. So for the two example site lists above, site-list 1 , site-id 1-100 , and site-list 2 site-id 70-130 , you could apply one to a control policy and the other to a data policy.
Configure Centralized Policies Using the CLI
To configure a centralized control policy using the CLI:
-
Create a list of overlay network sites to which the centralized control policy is to be applied (in the apply-policy command):
The list can contain as many site IDs as necessary. Include one site-id command for each site ID. For contiguous site IDs, you can specify a range of numbers separated with a dash (–). Create additional site lists, as needed.vSmart(config)# policy vSmart(config-policy)# lists site-list list-name vSmart(config-lists-list-name)# site-id site-id
-
Create lists of IP prefixes, TLOCs, and VPNs as needed: vSmart(config)# policy lists vSmart(config-lists)# prefix-list list-name vSmart(config-lists-list-name)# ip-prefix prefix/length vSmart(config)# policy lists vSmart(config-lists)# tloc-list list-name vSmart(config-lists-list-name)# tloc address color color encap encapsulation [preference value] vSmart(config)# policy lists vSmart(config-lists)# vpn-list list-name vSmart(config-lists-list-name)# vpn vpn-id
-
Create a control policy instance: vSmart(config)# policy control-policy policy-name vSmart(config-control-policy-policy-name)#
-
Create a series of match–action pair sequences:
The match–action pairs are evaluated in order, by sequence number, starting with the lowest numbered pair and ending when the route matches the conditions in one of the pairs. Or if no match occurs, the default action is taken (either rejecting the route or accepting it as is).vSmart(config-control-policy-policy-name)# sequence number vSmart(config-sequence-number)#
-
Define match parameters for routes and for TLOCs: vSmart(config-sequence-number)# match route route-parameter vSmart(config-sequence-number)# match tloc tloc-parameter
-
Define actions to take when a match occurs: vSmart(config-sequence-number)# action reject vSmart(config-sequence-number)# action accept export-to (vpn vpn-id | vpn-list list-name) vSmart(config-sequence-number)# action accept set omp-tag number
vSmart(config-sequence-number)# action accept set preference value
vSmart(config-sequence-number)# action accept set service service-name (tloc ip-address | tloc-list list-name) [vpn vpn-id]
vSmart(config-sequence-number)# action accept set tloc ip-address color color [encap encapsulation] vSmart(config-sequence-number)# action accept set tloc-action action
vSmart(config-sequence-number)# action accept set tloc-list list-name
-
Create additional numbered sequences of match–action pairs within the control policy, as needed.
-
If a route does not match any of the conditions in one of the sequences, it is rejected by default. If you want nonmatching routes to be accepted, configure the default action for the policy: vSmart(config-policy-name)# default-action accept
-
Apply the policy to one or more sites in the Cisco Catalyst SD-WAN overlay network: vSmart(config)# apply-policy site-list list-name control-policy policy-name (in | out)
-
If the action you are configuring is a service, configure the required services on the Cisco SD-WAN devices so that the Cisco Catalyst SD-WAN Controller knows how to reach the services:
Specify the VPN is which the service is located and one to four IP addresses to reach the service device or devices. If multiple devices provide the same service, the device load-balances the traffic among them. Note that the Cisco SD-WAN device keeps track of the services, advertising them to the Cisco Catalyst SD-WAN Controller only if the address (or one of the addresses) can be resolved locally, that is, at the device's local site, and not learned through OMP. If a previously advertised service becomes unavailable, the Cisco SD-WAN device withdraws the service advertisement.Device(config)# vpn vpn-id service service-name address ip-address
Following are the high-level steps for configuring a VPN membership data policy:
-
Create a list of overlay network sites to which the VPN membership policy is to be applied (in the apply-policy command):
vSmart(config)# policy vSmart (config-policy)# lists site-list list-name vSmart(config-lists-list-name)# site-id site-id
The list can contain as many site IDs as necessary. Include one site-id command for each site ID. For contiguous site IDs, you can specify a range of numbers separated with a dash (–). Create additional site lists, as needed.
-
Create lists of IP prefixes and VPNs, as needed:
vSmart(config)# policy lists vSmart(config-lists)# data-prefix-list list-name vSmart(config-lists-list-name)# ip-prefix prefix/length
vSmart(config)# policy lists vSmart(config-lists)# vpn-list list-name vSmart(config-lists-list-name)# vpn vpn-id
-
Create lists of TLOCs, as needed. vSmart(config)# policy vSmart(config-policy)# lists tloc-list list-name vSmart(config-lists-list-name)# tloc ip-address color color encap encapsulation [preference number}
-
Define policing parameters, as needed:
vSmart(config-policy)# policer policer-name vSmart(config-policer)# rate bandwidth vSmart(config-policer)# burst bytes vSmart(config-policer)# exceed action
-
Create a data policy instance and associate it with a list of VPNs:
vSmart(config)# policy data-policy policy-name vSmart(config-data-policy-policy-name)# vpn-list list-name
-
Create a series of match–pair sequences:
vSmart(config-vpn-list)# sequence number vSmart(config-sequence-number)#
The match–action pairs are evaluated in order, by sequence number, starting with the lowest numbered pair and ending when the route matches the conditions in one of the pairs. Or if no match occurs, the default action is taken (either rejecting the route or accepting it as is).
-
Define match parameters for packets:
vSmart(config-sequence-number)# match parameters
-
Define actions to take when a match occurs:
vSmart(config-sequence-number)# action (accept | drop) [count counter-name] [log] [tcp-optimization] vSmart(config-sequence-number)# action acccept nat [pool number] [use-vpn 0] vSmart(config-sequence-number)# action accept redirect-dns (host | ip-address) vSmart(config-sequence-number)# action accept set parameters
-
Create additional numbered sequences of match–action pairs within the data policy, as needed.
-
If a route does not match any of the conditions in one of the sequences, it is rejected by default. To accept nonmatching prefixed, configure the default action for the policy:
vSmart(config-policy-name)# default-action accept
-
Apply the policy to one or more sites in the overlay network:
vSmart(config)# apply-policy site-list list-name data-policy policy-name (all |from-service | from-tunnel)
Centralized Control Policy Configuration Examples
This topic provides some straightforward examples of configuring centralized control policy to help you understand the configuration procedure and get an idea of how to use policy to influence traffic flow across the Cisco SD-WAN overlay network domain.
Traffic Engineering
This example of traffic engineering forces all traffic to come to a Cisco SD-WAN device using a device hub instead of directly.
One common way to design a domain in a Cisco SD-WAN overlay network is to route all traffic destined for branches through a hub router, which is typically located in a data center, rather than sending the traffic directly from one Cisco SD-WAN device to another. You can think of this as a hub-and-spoke design, where one device is acting as a hub and the devices are the spokes. With such a design, traffic between local branches travels over the IPsec connections that are established between the spoke routers and the hub routers when the devices are booted up. Using established connections means that the devices do not need to expend time and CPU cycles to establish IPsec connections with each other. If you were to imagine that this were a large network with many devices, having a full mesh of connections between each pair of routers would require a large amount of CPU from the routers. Another attribute of this design is that, from an administrative point of view, it can be simpler to institute coordinated traffic flow policies on the hub routers, both because there are fewer of them in the overlay network and because they are located in a centralized data center.
This topology has two devices in different branches:
-
The Device West in site ID 1. The TLOC for this device is defined by its IP address (192.0.2.1), a color (gold), and an encapsulation (here, IPsec). We write the full TLOC address as {192.0.2.1, gold, ipsec}. The color is simply a way to identify a flow of traffic and to separate it from other flows.
-
The Device East in site ID 2 has a TLOC address of {203.0.113.1, gold, ipsec}.
The devices West and East learn each other’s TLOC addresses from the OMP routes distributed to them by the Cisco Catalyst SD-WAN Controller. In this example, the Device East advertises the prefix 209.165.201.0/27 as being reachable at TLOC {203.0.113.1, gold, }. In the absence of any policy, the Device West could route traffic destined for 209.165.201.0/27 to TLOC {203.0.113.1, gold, ipsec}, which means that the Device West would be sending traffic directly to the Device East.
However, our design requires that all traffic from West to East be routed through the hub router, whose TLOC address is {209.165.200.225, gold, ipsec}, before going to the Device East. To effect this traffic flow, you define a policy that changes the route's TLOC. So, for the prefix 1209.165.201.0/27, you create a policy that changes the TLOC associated with the prefix 209.165.201.0/27 from {203.0.113.1, gold, ipsec}, which is the TLOC address of the Device East, to {209.165.200.225, gold, ipsec}, which is the TLOC address of the hub router. The result is that the OMP route for the prefix 209.165.201.0/27 that the Cisco Catalyst SD-WAN Controller advertises to the Device West that contains the TLOC address of the hub router instead of the TLOC address of the Device East. From a traffic flow point of view, the Device West then sends all traffic destined for 209.165.201.0/27 to the hub router.
The device also learns the TLOC addresses of the West and East devices from the OMP routes advertised by the Cisco Catalyst SD-WAN Controller. Because, devices must use these two TLOC addresses, no policy is required to control how the hub directs traffic to the devices.
Here is a policy configuration on the Cisco Catalyst SD-WAN Controller that directs the Device West (and any other devices in the network domain) to send traffic destined to prefix 209.165.201.0/27 to TLOC 209.165.200.225, gold, which is the device:
policy
lists
prefix-list east-prefixes
ip-prefix 209.165.201.0/27
site-list west-sites
site-id 1
control-policy change-tloc
sequence 10
match route
prefix-list east-prefixes
site-id 2
action accept
set tloc 209.165.200.225 color gold encap ipsec
apply-policy
site west-sites control-policy change-tloc out
A rough English translation of this policy is:
Create a list named “east-prefixes” that contains the IP prefix “209.165.201.0/27”
Create a list named “west-sites” that contains the site-id “1”
Define a control policy named “change-tloc”
Create a policy sequence element that:
Matches a prefix from list “east-prefixes”, that is, matches “209.165.201.0/27”
AND matches a route from site-id “2”
If a match occurs:
Accept the route
AND change the route’s TLOC to “209.165.200.225” with a color of "gold" and an encapsulation of "ipsec"
Apply the control policy “change-tloc” to OMP routes sent by the vSmart
controller to “west-sites”, that is, to site ID 1
This control policy is configured on the Cisco Catalyst SD-WAN Controller as an outbound policy, as indicated by the out option in the apply-policy site command. This option means the Cisco Catalyst SD-WAN Controller applies the TLOC change to the OMP route after it distributes the route from its route table. The OMP route for prefix 209.165.201.0/27 that the Cisco Catalyst SD-WAN Controller distributes to the Device West associates 209.165.201.0/27 with TLOC 209.165.200.225, gold. This is the OMP route that the Device West installs it in its route table. The end results are that when the Device West sends traffic to 209.165.201.0/27, the traffic is directed to the hub; and the Device West does not establish a DTLS tunnel directly with the Device East.
If the West side of the network had many sites instead of just one and each site had its own device, it would be straightforward to apply this same policy to all the sites. To do this, you simply add the site IDs of all the sites in the site-list west-sites list. This is the only change you need to make in the policy to have all the West-side sites send traffic bound for the prefix 209.165.201.0/27 through the device. For example:
policy
lists
prefix-list east-prefixes
ip-prefix 209.165.201.0/27
site-list west-sites
site-id 1
site-id 11
site-id 12
site-id 13
control-policy change-tloc
sequence 10
match route
prefix-list east-prefixes
site-id 2
action accept
set tloc 209.165.200.225 color gold encap ipsec
apply-policy
site west-sites control-policy change-tloc out
Creating Arbitrary Topologies
To provide redundancy in the hub-and-spoke-style topology discussed in the previous example, you can add a second Cisco hub to create a dual-homed hub site. The following figure shows that site ID 10 now has two Device hubs. We still want all inter-branch traffic to be routed through a device hub. However, because we now have dual-homed hubs, we want to share the data traffic between the two hub routers.
-
Device Hub West, with TLOC 209.165.200.225, gold. We want all data traffic from branches on the West side of the overlay network to pass through and be processed by this device.
-
Device Hub East, with TLOC 198.51.100.1, gold. Similarly, we all East-side data traffic to pass through the Device Hub East.
Here is a policy configuration on the Cisco Catalyst SD-WAN Controller that would send West-side data traffic through the Cisco hub, and West and East-side traffic through the Device Hub East:
policy
lists
site-list west-sites
site-id 1
site-list east-sites
site-id 2
tloc-list west-hub-tlocs
tloc-id 209.165.200.225 gold
tloc-list east-hub-tlocs
tloc-id 198.51.100.1 gold
control-policy prefer-west-hub
sequence 10
match tloc
tloc-list west-hub-tlocs
action accept
set preference 50
control-policy prefer-east-hub
sequence 10
match tloc
tloc-list east-hub-tlocs
action accept
set preference 50
apply-policy
site west-sites control-policy prefer-west-hub out
site east-sites control-policy prefer-east-hub out
Here is an explanation of this policy configuration:
Create the site lists that are required for the apply-policy configuration command:
-
site-list west-sites lists all the site IDs for all the devices in the West portion of the overlay network.
-
site-list east-sites lists the site IDs for the devices in the East portion of the network.
Create the TLOC lists that are required for the match condition in the control policy:
-
west-hub-tlocs lists the TLOC for the Device West Hub, which we want to service traffic from the West-side device.
-
east-hub-tlocs lists the TLOC for the Device East Hub, to service traffic from the East devices.
Define two control policies:
-
prefer-west-hub affects OMP routes destined to TLOC 209.165.200.225, gold, which is the TLOC address of the Device West hub router. This policy modifies the preference value in the OMP route to a value of 50, which is large enough that it is likely that no other OMP routes will have a larger preference. So setting a high preference value directs traffic destined for site 100 to the Device West hub router.
-
Similarly, prefer-east-hub sets the preference to 50 for OMP routes destined TLOC 198.51.100.1, gold, which is the TLOC address of the Device East hub router, thus directing traffic destined for site 100 site to the Device East hub 198.51.100.1 router.
Apply the control policies:
-
The first line in the apply-policy configuration has the Cisco Catalyst SD-WAN Controller apply the prefer-west-hub control policy to the sites listed in the west-sites list, which here is only site ID 1, so that the preference in their OMP routes destined to TLOC 209.165.200.225 is changed to 50 and traffic sent from the Device West to the hub site goes through the Device West hub router.
-
The Cisco Catalyst SD-WAN Controller applies the prefer-east-hub control policy to the OMP routes that it advertises to the devices in the east-sites list, which changes the preference to 50 for OMP routes destined to TLOC 198.51.100.1, so that traffic from the Device East goes to the Device East hub router.