Purpose of Cisco SD-WAN Policies

The ongoing transformation to digital business means that organizations are relying on their IT infrastructure more than ever before. There is more data flowing across the network, and that data is increasingly critical to ongoing business operations. Cisco SD-WAN policies are the mechanism through which administrators can encode their intent into the network fabric and organizations can start to realize new kinds of value. IT administrators today are being tasked to meet new demands from business leaders that have direct implications on the structure and operation of the network. One such objective is to reduce the costs of the WAN transport infrastructure. Realizing this objective often involves moving from an Active/Standby design to a forwarding architecture where all links can be used in parallel. Additionally, administrators are moving away from expensive, leased-line transports and relying more and more on commodity Internet circuits to meet their transport needs. At the same time, business stakeholders require the same application experience that they have traditionally had with MPLS transports. Policies are the way that network administrators configure the Cisco SD-WAN fabric in order to meet their business intentions. Through the next several chapters we will discuss different types of policies and how they can be used with different use cases to solve business problems.

Types of Cisco SD-WAN Policies

Network administrators use several different types of policies in order to meet their business objectives. Policies can be classified as either centralized policies or localized policies.

Broadly speaking, centralized policies control routing information and data that is forwarded across the Cisco SD-WAN fabric. Localized policies control routing and traffic forwarding at the perimeter of the Cisco SD-WAN fabric where WAN Edge routers interface with traditional routers. Figure 5-1 illustrates the relationships between these types of policies.

Centralized Policy

Figure 5-2 shows that centralized policies can be further classified as either control policies (called topology policies in the vManage GUI) or data policies (called traffic policies in the vManage GUI). Control policies are used to manipulate the structure of the Cisco SD-WAN fabric by altering the control plane information exchanged by the Overlay Management Protocol (OMP). Data policies are used to manipulate the data plane directly by altering the forwarding of traffic through the Cisco SD-WAN fabric.

Localized Policy

Similar to centralized policies, localized policies can be used to manipulate both the control plane and the data plane. Figure 5-3 illustrates the two main types of localized policy: traditional localized policy and security policy. Traditional localized policies include route policy, quality of service, and access control lists (ACLs). The security policy feature set supports use cases such as compliance, guest access, Direct Cloud Access (DCA), and Direct Internet Access (DIA).

Localized policies that affect the control plane, called route policies, can be used to filter or manipulate routes exchanged or learned outside of the SD-WAN fabric via protocols such as BGP, OSPF, and EIGRP. Route policies can also be used to filter routes as they are redistributed from one protocol to another—including into and out of OMP. Route policies are the only way to impact the control plane with localized policy.

Localized policies that affect the data plane include the following:

• Quality of Service: Quality of Service (QoS) can be configured on the WAN Edge routers to perform queueing, shaping, policing, congestion avoidance, and congestion management.

• Access Control Lists: Access control lists (ACLs) can be created with the localized policy to filter traffic at the interface level. ACLs can also be used to mark or remark traffic for QoS purposes.

• Security Policy: Security policies were first introduced in version 18.2 with the Zone-Based Firewall (ZBFW) feature set and have continued to expand in functionality in subsequent releases. As of version 19.2, the Security Policy feature set currently supports Application-Aware ZBFW, Intrusion Prevention, URL Filtering, Advanced Malware Protection (AMP), and DNS Security. These features are used to affect traffic in the data plane.

Policy Domains

Figures 5-2 and 5-3 illustrate that both the control plane and the data plane can be manipulated with both centralized policies and localized policies. By comparison, Figure 5-4 illustrates the relationship between centralized control policies and localized control policies. Centralized policies are activated on the vSmart controllers and affect the control plane of the Cisco SD-WAN fabric. Localized route policies are applied to the individual WAN Edge routers and affect the routing domain in the local site that is attached to the Cisco SD-WAN fabric.

A similar distinction can be made about centralized data policies and localized data policies. Centralized data policies can affect the forwarding of data across the entire Cisco SD-WAN fabric, whereas localized data policies can be applied as narrowly as a single interface on a single router. Figure 5-5 illustrates these relationships.

The remaining discussion in this chapter focuses primarily on centralized policies. While most of the concepts are applicable to both centralized and localized policies, there are some key differences in the way that localized policies are constructed and applied. These differences will be discussed in further detail in Chapter 9, “Localized Policies,” and Chapter 10, “Cisco SD-WAN Security.”

Cisco SD-WAN Policy Construction

Cisco SD-WAN policies may be intimidating or confusing at first look, but they are remarkably similar in construction and operation to routing policies created on traditional IOS routers. Creating a routing policy on a traditional IOS router is a three-step process:

Step 1. Define lists to identify the groups of interest. Lists such as an access control list, an IP prefix list, and an Autonomous System (AS) path list are commonly used for this purpose.

Step 2. Define a route map. A route map is a structured sequence of match and set statements, where traffic of interest from the list defined in the first step is matched and then the specific set of actions to be taken is listed.

Step 3. Apply the route map. In order for the policy to have any effect at all, the route map must be applied. A single route map can be applied in a number of different ways, such as on an interface to configure policy routing in the data plane, or on a routing neighbor to manipulate routing updates in the control plane. Configuring the list and route maps without applying them has no effect on the control plane or data plane of an IOS router.

Example 5-1 illustrates this process by showing a router at a remote site that has a BGP peering with a data center router (BGP neighbor 192.168.1.100). The network administrator creates and applies the following policy in classic Cisco IOS syntax to only accept the default route advertisement from the data center router and to set a specific MED value to that default route.

Example 5-1 Configuring a Routing Policy in Traditional Cisco IOS with a BGP Route Map

Click here to view code image

REMOTE_R1#
REMOTE_R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
! Step 1:  Define the list to identify the traffic of interest
! In this example, an ip prefix-list is defined to match only a default route
REMOTE_R1(config)#ip prefix-list DEFAULT_ONLY permit 0.0.0.0/0
REMOTE_R1(config)#
! Step 2:  Define a route-map to execute the necessary policy actions
! In this example, sequence 10 permits the routes from our prefix-list,
! and sets the MED value to 1000; sequence 20 denies all other routes.
REMOTE_R1(config)#route-map PERMIT_ONLY_DEFAULT permit 10
REMOTE_R1(config-route-map)#match ip address prefix-list DEFAULT_ONLY
REMOTE_R1(config-route-map)#set metric 1000
REMOTE_R1(config-route-map)#route-map PERMIT_ONLY_DEFAULT deny 20
REMOTE_R1(config-route-map)#exit
REMOTE_R1(config)#
! Step 3:  Apply the Route-Map
! In this example, the route-map is applied to one of the configured BGP neighbors
REMOTE_R1(config)#router bgp 100
REMOTE_R1(config-router)#neighbor 192.168.1.100 remote-as 20
REMOTE_R1(config-router)#neighbor 192.168.1.100 route-map PERMIT_ONLY_DEFAULT in
REMOTE_R1(config-router)#end
REMOTE_R1#

While Cisco SD-WAN policies can appear intimidating to new engineers because they are much more flexible than traditional IOS-based policies, the same three-step process is used for configuring policies with Cisco SD-WAN:

Step 1. Define lists to identify the groups of interest. There are many more and different types of lists that can be used with Cisco SD-WAN than with traditional IOS. This, in part, accounts for the greater flexibility with Cisco SD-WAN than with traditional routing policy. In addition to using lists to identify traffic of interest, certain lists can also be used when defining actions and when applying policies. Lists will be discussed in greater detail in the next section.

Step 2. Define a policy. Cisco SD-WAN policies are defined in a structured sequence of match and action statements, where traffic of interest from the list defined in the first step is matched and then the specific set of actions to be taken is listed. There are many different types of policies that can be used with Cisco SD-WAN to accomplish different objectives, but the structure of those policies is similar. The specific criteria that can be matched on and the different actions that can be taken differ between the types of policies.

Step 3. Apply the policy. As with traditional Cisco IOS route maps, in order for the Cisco SD-WAN policy to have any effect at all, the policy must be applied; a route map that has been configured but not applied does not affect the operation of the router. With Cisco SD-WAN, centralized policies are always applied to a site list that matches one or more site IDs. If there are multiple WAN Edge routers at a single site, each of the routers configured with the same site ID will be subjected to the same centralized policy. Depending on the type of policy, the policy can also be applied to a specific VPN and to a specific direction of traffic flow.

Figure 5-6 illustrates this three-step process.

In Example 5-2, the three-step process for creating SD-WAN policies is implemented to create a similar routing policy as shown in Example 5-1.

Example 5-2 Configuring a Centralized Policy with Cisco SD-WAN

Click here to view code image

! Step 2:  Define a control-policy to execute the necessary policy actions
! In this example, sequence 1 permits the routes from our prefix-list,
! and sequence 11 permits the TLOC Routes.
! The default action denies all other routes and TLOCs.
policy
 control-policy PERMIT_ONLY_DEFAULT
    sequence 1
    match route
     prefix-list DEFAULT_ONLY
     site-list DC_1
    !
    action accept
    !
   !
   sequence 11
    match tloc
     site-list DC_1
    !
    action accept
    !
   !
  default-action reject
 !
! Step 1:  Define the list to identify the groups of interest
! In this example, a similar prefix-list is defined to match only a default
! route, as was done in Example 5-1.
lists
 prefix-list DEFAULT_ONLY
  ip-prefix 0.0.0.0/0
 !
! Step 1 (continued): Two site-lists were defined to specify where
! the route is sourced from, and where the policy is applied.
 site-list REMOTE_1
  site-id 300
 !
 site-list DC_1
   site-id 100
  !
 !
!
! Step 3:  Apply the Policy
! In this example, the policy is applied to the remote site specified in the
 site-list REMOTE_1.
apply-policy
 site-list REMOTE_1
  control-policy PERMIT_ONLY_DEFAULT out
 !
!

Later chapters of this book will review the construction of policies in much greater detail; do not be concerned if the meaning of specific commands is not yet clear. The purpose of Examples 5-1 and 5-2 is to review the commonality of the structure of Cisco SD-WAN policies with traditional control and data plane policies in Cisco IOS.

Types of Lists

Lists are the foundational building block of Cisco SD-WAN policies. Lists allow for flexibility and extendibility in both how items are matched and how actions are taken in a Cisco SD-WAN policy. Cisco SD-WAN has many different types of lists that can be used to match different groups of interest in the control plane and the data plane. With centralized policies, the following types of lists can be used:

• Application List: An application list can match on a specific application or an application family. These lists are used to assist administrators in creating business-relevant rules using Layer 7 application definitions rather than needing to specify Layers 3 and 4 (IP address and port) values. Common examples would include a “VOICE_AND_VIDEO” application list that would match applications such as RTP (VoIP), WebEx, and TelePresence and a “SCAVENGER” application list that matches non-business-critical applications such as YouTube, Facebook, and Netflix. Application lists are only used as matching criteria.

• Color List: As discussed in Chapter 3, “Control Plane and Data Plane Operations,” a “color” is an attribute of a TLOC. Color lists can specify a single color or a group of colors. These lists can be used in both control plane and data plane policies and can be used as matching criteria as well as when specifying an action.

• Prefix List: A prefix list is used to specify a range of routes in Classless Inter-Domain Routing (CIDR) notation. This list is used for matching routing information in the control plane exclusively and can only be used in control policies. Unlike in traditional IOS, where a single access list or prefix list can be used to match either control plane routes or data plane traffic (depending on how it is used in the policy), Cisco SD-WAN defines two separate lists for these functions: a prefix list and a data prefix list.

• Data Prefix List: A data prefix list is very similar to a prefix list; however, a data prefix list in Cisco SD-WAN can only be used to match traffic in the data plane and is only used in data policies.

• Site List: Every site in the Cisco SD-WAN fabric is assigned a site identifier called a Site-ID. A site list can be a single, multiple, or range of site IDs. Site lists are often used as matching criteria in policy statements and to specify which site or sites a particular policy gets applied to. This is discussed further in the following section.

• Policers: Similar to traditional Cisco IOS, a policer is used for limiting the rate of traffic that ingresses or egresses. A policer list can only be used as part of an action statement in a policy and not part of a match statement.

• SLA (Service Level Agreement) Class List: An SLA class list is used with an Application-Aware Routing policy to define an SLA in terms of the maximum loss, latency, jitter, or a combination of the three, that a particular class of traffic should experience.

• TLOC Lists: As discussed in Chapter 3, a TLOC is a Transport Locator and serves as the next-hop address in routing lookups that happen across the SD-WAN fabric. A TLOC list is a set of next-hop addresses and can be used with both control and data policies to manipulate the next-hop address of traffic that is forwarded over the SD-WAN fabric.

• VPN List: A VPN list is a list of service-side VPNs (or VRFs) and is used to specify matching criteria in a control policy for which VPN segment a particular data policy should be applied to.

Policy Definition

While there are many different types of Cisco SD-WAN policies, all of the policies are defined with a similar structure. Each policy is a numbered sequence of match and action clauses that are evaluated ordinally. Inside of a particular sequence number, you may configure multiple matching conditions and multiple actions. If multiple conditions are specified, then a logical AND between the conditions is evaluated, and all of the criteria must be met in order to be matched by that sequence. This case can be seen in Example 5-3, where the matching criteria of sequence 1 specifies that routes must match both (logical AND) the prefix list DEFAULT_ONLY and the site list DC_1_OR_2. Any default routes that are not from either Site 100 or Site 200 would not satisfy both of the criteria and therefore would not be matched by sequence 1 and would continue to be evaluated by additional sequences in the policy. Likewise, any routes from Site 100 or Site 200 that are not default routes would also not satisfy both of the criteria and would not be matched by sequence 1.

Example 5-3 Centralized Policy with Multiple Matching Criteria

Click here to view code image

 control-policy PERMIT_ONLY_DEFAULT
! Sequence 1 accepts routes that are matched by the prefix list DEFAULT_ONLY
! and the Site list DC_1_OR_2.
    sequence 1
     match route
      prefix-list DEFAULT_ONLY
      site-list DC_1_OR_2
     !
     action accept
     !
    !
    sequence 11
     match tloc
      site-list DC_1_OR_2
    !
    action accept
    !
   !
  default-action reject
 !
!

Sequence 1 in Example 5-3 shows that multiple lists can be specified as the matching criteria for a single sequence, and in that case, all of the matching criteria (both the prefix list and the site list in this example) must be met in order matched by sequence 1. At the same time, each of those lists can contain one or more values, as illustrated by the site list DC_1_OR_2 in Example 5-4.

Example 5-4 Lists That Match Multiple Values

Click here to view code image

 lists
  prefix-list DEFAULT_ONLY
   ip-prefix 0.0.0.0/0
  !
  site-list REMOTE_1
   site-id 300
  !
  ! This list, when used as matching criteria, will match multiple values.  Site 100
 OR Site 200
  ! will be matched by this list.
  site-list DC_1_OR_2
   site-id 100,200
  !
 !
!

In the event that the list being used as matching criteria contains multiple values, matching any one value will be sufficient for that criterion: in Example 5-3, sequence 1 will match routes sourced from the Site-ID list DC_1_OR_2, which is defined in Example 5-4 to be either site-id 100 or site-id 200. In this way, you can see that the multiple values within a single list, when used as a match condition, are treated as a logical OR. As each router is configured with a single site-id, there is no way that a single route could fulfill the matching criteria to be from site-id 100 AND site-id 200 at the same time.

Similar to traditional Cisco route maps and ACLs, the matching logic applied in Cisco SD-WAN policies is on a first-match basis. As soon as any given sequence in the policy is matched, those specific actions are taken and no further match statements are evaluated. As such, it is a common practice to put the most specific matching criteria at the beginning of the policy and the broader, more general matches at the end of the policy.

Once a particular sequence number is matched, the first action that an administrator configures is to either “Accept or Reject” in a centralized control policy or “Accept or Deny” in a centralized data policy. Additional, optional actions can be configured in addition to accepting or denying/rejecting the entry, but this choice is mandatory. If the entry in a control policy is rejected, no further actions can be taken. In data policies, if the traffic is rejected, then you have the option to log or count the traffic. If the matching entry is accepted, there are many more possible options that can be taken in both cases. Additional examples of this will be covered in much greater detail in subsequent chapters. Example 5-5 highlights an example of these action statements.

Example 5-5 Policy Actions and Default Action

Click here to view code image

 control-policy PERMIT_ONLY_DEFAULT
    sequence 1
     match route
      prefix-list DEFAULT_ONLY
      site-list DC_1_OR_2
     !
 ! Every policy sequence either accepts or denies 122(for control policies) /
 ! rejects (for data policies) entries
     action accept
     !
    !
    sequence 11
     match tloc
      site-list DC_1_OR_2
    !
    action accept
   !
  !
 ! Every policy has a default action that applies when no other sequences
 ! have been matched
  default-action reject
 !
!

Each policy also has a default action as the very last sequence. This default action is similar to the implicit denial that is found in traditional Cisco ACLs and route maps, but unlike traditional Cisco route maps, the default action is always configured explicitly. When configuring centralized policies, it is important to keep in mind that the default action exists and is set to Reject or Deny for control and data policies accordingly. Example 5-5 highlights the default action configuration.

Cisco SD-WAN Policy Administration, Activation, and Enforcement

Each of the several different kinds of centralized policies, including control, VPN membership, centralized data, and Application-Aware Routing, is configured as an individual component policy. This process was described in “Step 2: Define the Policy” in the previous section. Each of these component policies has its own specific sequence of match and action statements and is processed completely independently from the others. These individual policies are then combined into a single centralized policy.

Building a Centralized Policy

Example 5-6 demonstrates the process of combining multiple component policies together. This example continues to build on the policy that was created in Examples 5-4 and 5-5 and adds a centralized data policy to filter the traffic from a specific application on the network. This centralized data policy has a single sequence, sequence 1, that matches on an application list called BLOCKED_APPS. In addition to the new centralized data policy, Example 5-6 also includes several new lists, including the application-list BLOCKED_APPS, as well as the VPN list CORP_VPN and the site list ALL_BRANCHES.

Lastly, the apply-policy stanza at the end of the policy has been updated. This stanza now indicates that the new data policy has been applied to the sites indicated by the ALL_BRANCHES site list.

Example 5-6 Centralized Policy with Multiple Component Sub-Policies

Click here to view code image

policy
 control-policy PERMIT_ONLY_DEFAULT
    sequence 1
     match route
      prefix-list DEFAULT_ONLY
      site-list DC_1_OR_2
     !
     action accept
     !
    !
    sequence 11
     match tloc
      site-list DC_1_OR_2
     !
     action accept
     !
    !
  default-action reject
 !
! The new data policy "_CORP_VPN_BLOCK_BAD_APPS" has been added
 data-policy _CORP_VPN_BLOCK_BAD_APPS
! This policy only applies to traffic in the specified VPN list
  vpn-list CORP_VPN
    sequence 1
    match
     app-list BLOCKED_APPS
    !
    action drop
    !
   !
  default-action accept

 lists
  app-list BLOCKED_APPS
   app youtube
  !
  prefix-list DEFAULT_ONLY
   ip-prefix 0.0.0.0/0
  !
  site-list ALL_BRANCHES
   site-id 300-599
 !
   site-list REMOTE_1
   site-id 300
  !
  site-list DC_1_OR_2
   site-id 100,200
  !
  vpn-list CORP_VPN
   vpn 10
 !
!
! The new data policy has been applied to all of the sites referenced
! by the site-list “ALL_BRANCHES”.
!
apply-policy
 site-list ALL_BRANCHES
  data-policy _CORP_VPN_BLOCK_BAD_APPS all
 !
 site-list REMOTE_1
  control-policy PERMIT_ONLY_DEFAULT out
 !
!

As Example 5-6 shows, a single centralized policy can consist of many different component policies that can be applied to different subsets of sites in the apply-policy stanza to implement the intent of the administrator. The control policy PERMIT_ONLY_DEFAULT is only applied to site-id 300, and at the same time, the data policy _CORP_VPN_BLOCK_BAD_APPS is applied to site-ids 300–599. In this way, a single site with the site-id 300 would have both the control and data policy applied, while at the same time sites with site-ids 301–599 would only have the data policy applied.

Centralized data policies will always be applied with a site list, a VPN list, and a direction. The direction is either configured as from-tunnel, from-service, or all (from-tunnel means WAN to LAN, and from-service means LAN to WAN). These policies can manipulate traffic that is both being received from the fabric and transmitted across the fabric. In Example 5-6, the data policy is configured with the all option, indicating that this policy is applied to traffic flowing in both directions. Chapter 7 discusses these options in further detail.

Application-Aware Routing policies will always be configured with a VPN list and a site list, but not with an explicitly configured directionality. As the purpose of an Application-Aware Routing policy is to select the specific tunnel in which the SD-WAN traffic should be forwarded (based on the real-time performance of the site-to-site tunnels), Application-Aware Routing policies can only be used when the traffic is destined across the fabric. The directionality of this policy is always fixed; it is not logical to configure an Application-Aware Routing policy for traffic that is already received across the Cisco SD-WAN fabric and being forwarded out to a local service-side VPN interface. Chapter 8 discusses this in further detail.

Each Cisco SD-WAN fabric can have only a single centralized policy that is active at any point in time. That single policy can have as many different component policies as necessary, and those component policies can apply to different sets of sites or VPNs in order to accomplish the desired business outcomes. In the case of Example 5-6, this complete centralized policy is the combined entirety of the named control and data policies, the lists that are referenced in those policies and the apply-policy stanza that specifies where the policies will be enforced. All of these elements together make up a single centralized policy and are indented under the “policy” statement in the very first line.

Activating a Centralized Policy

vManage is the single point of administration for the entire Cisco SD-WAN fabric. This is the place where all management, monitoring, configuration, and troubleshooting is done for the entirety of the solution. This includes the configuration of all policies. While this chapter has primarily dealt with the building blocks of policies with the CLI as an introduction, the following chapters will walk through many different examples of policy configuration and activation using the vManage NMS, which is how most enterprises choose to manage their environments.

Once a centralized policy is built in vManage, it is then activated. When a centralized policy is activated on vManage, vManage writes that policy in its entirety into the configuration of the vSmart controller. This configuration transaction is accomplished through NETCONF—the same mechanism that is used to configure the WAN Edge router configurations from vManage. As NETCONF is being used to modify the configuration of the vSmart controllers, it is typical for the application process to take several seconds. As this process modifies the configuration of the vSmarts, this also means that the policy changes are persistent. Should a vSmart controller reboot for any reason, when it re-initializes, it will have a copy of the last policy that was configured from vManage.

Typical production deployments will have two or more vSmarts, depending on redundancy and scale needs, and it is the responsibility of vManage to ensure that the policy configuration on all of the vSmart controllers remains synchronized. If, for whatever reason, the policy change is not applied successfully to all of the vSmart controllers, vManage will automatically roll back the policy change from all vSmart controllers.

While all of the policies in the Cisco SD-WAN fabric are administered on vManage, different types of policies are enforced at different locations in the network. As Application-Aware Routing policies and data policies are manipulating the forwarding of traffic in the data plane (and these policies are enforced on the WAN Edge routers themselves), these policies need to be propagated all the way to the WAN Edge routers. In the Cisco SD-WAN solution, this is accomplished by configuring the policies on the vManage and activating the policies to the vSmart controllers. The vSmart controller then encodes the necessary parts of the policies into an OMP update and advertises these policies to the WAN Edge routers. The left column in Figure 5-7 illustrates this process.

The architectural decision to encode centralized data policy updates in OMP, rather than to encode them into the configuration of the WAN Edge with NETCONF, has several important implications. Transmitting the centralized data policy as an OMP routing update allows for large-scale changes to be rolled out to the entire SD-WAN fabric very quickly rather than needing to make individual NETCONF configuration transactions on potentially hundreds or thousands of devices (which could take on the order of minutes to tens of minutes). Centralized data policy changes can be rolled out to the entirety of the fabric as quickly as any other routing update can be propagated and processed—typically, in a matter of seconds after the configuration is applied to the vSmarts. Additionally, as the policies are not stored in the configuration of the router, should the router reload for any reason, the policy configuration will be lost and upon re-initialization the router will have no effective policy. This is not considered a problem, as the WAN Edge router will need to establish control connections with the vSmart controllers in order to build fabric tunnels and forward traffic, and therefore will relearn the necessary policy information through OMP updates at that time.

As centralized control policies and VPN membership policies manipulate control plane updates, these policies are enforced on the vSmarts themselves. Fundamentally, these control policies are manipulating or restricting the advertisement of control plane information. As all control plane information flows through the vSmart controllers, enforcing control policies on the vSmart provides an elegant, simple, and scalable solution. There is no need for these policies to be advertised to the individual WAN Edge routers. Instead, the effects of these policies are seen in the routing updates that are propagated from the vSmarts to the WAN Edge routers. The center column of Figure 5-7 shows this relationship.

All localized policies, including traditional localized policies and security policies, are administered on the vManage and configured directly to the WAN Edge routers via device template configuration. In this way, localized policies have much more in common with feature templates than centralized policies. Localized policies and security policies do not directly interact with the vSmart controllers. The rightmost column of Figure 5-7 illustrates this relationship.

Packet Forwarding Order of Operations

As multiple types of policies can be applied to a given site and affect the forwarding of a single flow, it is important to understand the order in which these policies are applied and evaluated, and how they work together. First, as control policies do not directly affect the data plane, they are processed independently of data plane policies. Control policies instead impact the routing information that the data plane is built upon and, in this manner, they are able to impact the forwarding of traffic. As control policies filter, manipulate, summarize, or restrict the advertisement of a specific routing prefix or TLOC, a WAN Edge will have altered control plane information and will build its forwarding plane from this altered control plane information. Figure 5-8 shows the packet forwarding order of operations.

The following steps are evaluated sequentially when forwarding a packet through a WAN Edge router:

1. IP Destination Lookup: The first step in the packet-forwarding process is to perform a routing lookup on the destination IP of the packet in the routing table. This information is then used to inform the rest of the forwarding decisions that are made as the packet is processed through the WAN Edge router.

2. Ingress Interface ACL: Localized policy can be used to create ACLs and tie them to interface templates. Interface ACLs can be used for packet filtering, policing, and QoS marking or remarking. If a packet is denied by the ingress ACL, it is dropped at this point and is not processed any further.

3. Application-Aware Routing: The Application-Aware Routing policy is evaluated after the forwarding decision has been made based on the routing table. It is important to note that an Application-Aware Routing policy can only make distinctions between equal paths in the routing table. If the routes for a destination’s multiple next-hop addresses are not equal-cost paths in the routing table, then the Application-Aware Routing policy will have no effect, and the flow will follow the most preferred path based on the routing table. This will be explored further in Chapter 8.

4. Centralized Data Policy: The centralized data policy is evaluated after the Application-Aware Routing policy and is able to override the Application-Aware Routing forwarding decision.

5. Routing and Forwarding: Routing lookups are now performed to determine the correct output interfaces so that processing can be continued there.

6. Security Policy: If security policies are configured, they are processed in the following order: Firewall, Intrusion Prevention, URL-Filtering, and finally Advanced Malware Protection.

7. Encapsulation and Encryption: As packets are prepared to be forwarded across the fabric, the necessary VPN labels and tunnel encapsulations are performed.

8. Egress Interface ACL: As with ingress ACLs, local policy is able to create ACLs that are applied on egress as well. If traffic is denied or manipulated by the egress ACL, those changes will take effect before the packet is forwarded.

Summary

This chapter has discussed the basics of building Cisco SD-WAN policies. There are two main types of policies: centralized policies and localized policies. Policies are constructed from lists, which are used to identify groups of interest in both the control plane (such as prefix lists and site lists) as well as in the data plane (such as application lists and data prefix lists). Individual policies are structured sequences of match and action statements. These component policies are then assembled into a single centralized policy that is activated on the vSmart controller. The vSmart enforces the control policies and then encodes the necessary components of the data policies into OMP updates, which are advertised to the WAN Edge routers where they are enforced in the data plane.

Review All Key Topics

Review the most important topics in the chapter, noted with the Key Topic icon in the outer margin of the page. Table 5-1 lists these key topics and the page numbers on which each is found.

Define Key Terms

Define the following key terms from this chapter, and check your answers in the glossary:

Centralized policy

localized policy

control policy

data policy

Chapter Review Questions

1. 1. Which of the following are types of Cisco SD-WAN policies? (Choose all that apply.)

   1. Traffic engineering policy

   2. URL-Filtering policy

   3. Application-Aware Routing policy

   4. Centralized data policy

2. 2. Cisco SD-WAN policies use a “best match” (or most specific match) matching logic.

   1. True

   2. False

3. 3. Which of the following are types of lists used in Cisco SD-WAN policy? (Choose all that apply.)

   1. Prefix-List

   2. SLA-Class

   3. Application List

   4. VPN-List

   5. TLOC-List

   6. Site List

4. 4. A single list object can be used to match routes in the control plane and packets in the data plane.

   1. True

   2. False

5. 5. Which of the following can only be configured as part of a local policy?

   1. Forwarding a specific type of traffic over a specific transport link

   2. Filtering specific routes from a BGP peer

   3. Dropping all YouTube traffic

   4. Forwarding voice calls over a link that has less than 150ms of latency

6. 6. Which types of policies are applied to and enforced on the vSmart controller? (Choose all that apply.)

   1. VPN membership policies

   2. Topology (control) policies

   3. Zone-Based Firewall (ZBFW) policies

   4. Cflowd policies

7. 7. Which types of policies are applied to and enforced on the WAN Edge router? (Choose all that apply.)

   1. Application-Aware Routing policies

   2. VPN membership policies

   3. Security policies

   4. Localized data policies

   5. Topology policies

8. 8. Which types of policies are applied to the vSmarts and enforced on the WAN Edges?

   1. Application-Aware Routing policies

   2. VPN membership policies

   3. Security policies

   4. Localized data policies

   5. Topology policies

9. 9. In a typical Cisco SD-WAN deployment, all policies are administered on which device?

   1. WAN Edge

   2. vSmart

   3. vBond

   4. vManage

   5. vPolicy

10. 10. If a single flow matches sequences in both an Application-Aware Routing policy and a centralized data policy, the flow will be forwarded according to which policy?

    1. Application-Aware Routing policy

    2. Centralized data policy