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.

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)

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.

One way to direct all the device spoke router traffic to a Cisco hub router is to create a policy that changes the TLOC associated with the routes in the local network. Let’s consider the topology in the figure here:

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.

Lists

Route policy uses the following types of lists to group related items. You configure lists under the policy lists command hierarchy on Cisco vEdge devices.

Sequences

A localized control policy contains sequences of match–action pairs. The sequences are numbered to set the order in which a route is analyzed by the match–action pairs in the policy.

In Cisco SD-WAN Manager, you configure sequences from:

• Configuration > Policies > Localized Policy > Add Policy > Configure Route Policy > Sequence Type

• Configuration > Policies > Custom Options > Localized Policy > Route Policy > Sequence Type

In the CLI, you configure sequences with the route-policy sequence command.

Each sequence in a localized control policy can contain one match condition and one action condition.

Match Parameters

In Cisco SD-WAN Manager, you configure sequences from:

• Configuration > Policies > Localized Policy > Add Policy > Configure Route Policy > Sequence Type > Sequence Rule > Match

• Configuration > Policies > Custom Options > Localized Policy > Route Policy > Sequence Type > Sequence Rule > Match

In the CLI, you configure sequences with the route-policy sequence match command.

For route policy routes, you can match these attributes:

Action Parameters

For each match condition, you configure a corresponding action to take if the packet matches.

In Cisco SD-WAN Manager, you configure match parameters from:

• Configuration > Policies > Localized Policy > Add Policy > Configure Route Policy > Sequence Type > Sequence Rule > Action

• Configuration > Policies > Custom Options > Localized Policy > Configure Route Policy > Sequence Type > Sequence Rule > Action

In the CLI, you configure actions with the policy control-policy action command.

Each sequence in a localized control policy can contain one action condition.

When a route matches the conditions in the match portion of a route policy, the route can be accepted or rejected:

Then, for a route that is accepted, the following actions can be configured:

To display the OMP and OSPF tag values associated with a route, use the show ip routes detail command.

Action Parameters

For each match condition, you configure a corresponding action to take if the packet matches.

In Cisco SD-WAN Manager, you configure match parameters from:

• Configuration > Policies > Localized Policy > Add Policy > Configure Route Policy > Sequence Type > Sequence Rule > Action

• Configuration > Policies > Custom Options > Localized Policy > Configure Route Policy > Sequence Type > Sequence Rule > Action

In the CLI, you configure actions with the policy control-policy action command.

Each sequence in a localized control policy can contain one action condition.

When a route matches the conditions in the match portion of a route policy, the route can be accepted or rejected:

Then, for a route that is accepted, the following actions can be configured:

To display the OMP and OSPF tag values associated with a route, use the show ip routes detail command.

Default Action

If a route being evaluated does not match any of the match conditions in a localized control policy, a default action is applied to this route. By default, the route is rejected.

In Cisco SD-WAN Manager, you modify the default action from Configuration > Policies > Localized Policy > Add Policy > Configure Route Policy > Sequence Type > Sequence Rule > Default.

In the CLI, you modify the default action with the control policy default-action accept command.

To configure localized device access control policies, use the Cisco SD-WAN Manager policy configuration wizard.

Configure specific or all components depending on the specific policy you are creating. To skip a component, click the Next button. To return to a component, click the Back button at the bottom of the screen.

To configure a device access policy:

1. From the Cisco SD-WAN Manager menu, choose Configuration > Policies.

2. Click Localized Policy and from the Custom Options drop-down, under Localized Policy, select Access Control Lists.

3. From the Add Device Access Policy drop-down list, select Add IPv4 Device Access Policy or Add IPv6 Device Access Policy option to add a device.

   Note

   Beginning with Cisco IOS XE Catalyst SD-WAN Release 17.9.1a and Cisco vManage Release 20.9.1, if you configure an IPv4 or an IPv6 device access policy with no policy sequences and only a default action of Accept or Drop, the device access policy creates an SSH and an SNMP configuration. You can now create a device access policy with only a default action and with no policy sequences to create a device configuration or a Cisco SD-WAN Manager configuration for both SSH and SNMP. If you do not create an SNMP server configuration, the SNMP configuration created by the device access policy is unused. Prior to Cisco IOS XE Catalyst SD-WAN Release 17.9.1a and Cisco vManage Release 20.9.1, if you configured a device access policy with only a default action of Accept or Drop and with no policy sequences, the device access policy would not create a device configuration or a Cisco SD-WAN Manager configuration.

4. Select Add IPv4 Device Access Policy from the drop-down list to add an IPv4 ACL Policy. The edit Device IPv4 ACL Policy page appears.

5. Enter the name and the description for the new policy.

6. Click Add ACL Sequence to add a sequence. The Device Access Control List page is displayed.

7. Click Sequence Rule. Match and Actions options are displayed.

8. Click Match, select and configure the following conditions for your ACL policy:

   Match Condition	Description
   Device Access Protocol (required)	Select a carrier from the drop-down list. For example SNMP, SSH.
   Source Data Prefix	Enter the source IP address. For example, 10.0.0.0/12.
   Source Port	Enter the list of source ports. The range is 0-65535.
   Destination Data Prefix	Enter the destination IP address. For example, 10.0.0.0/12.
   VPN	Enter the VPN ID. The range is 0-65536.

9. Click Actions, configure the following conditions for your ACL policy:

   Action Condition	Description
   Accept
   Counter Name	Enter the counter name to be accepted. The maximum length can be 20 characters.
   Drop
   Counter Name	Enter the counter name to drop. The maximum length can be 20 characters.

10. Click Save Match And Actions to save all the conditions for the ACL policy.

11. Click Save Device Access Control List Policy to apply the selected match conditions to an action.

12. If no packets match, then any of the route policy sequence rules. The Default Action in the left pane is to drop the packets.

Note	IPv6 prefix match is not supported on Cisco vEdge devices. When you try to configure IPv6 prefix matches on these devices, Cisco SD-WAN Manager fails to generate device configuration.

Yang model for the command device-access-policy-counters :

list device-access-policy-counters {
        tailf:info "IPv6 Device Access Policy counters";
        when "/viptela-system:system/viptela-system:personality = 'vedge'";
        tailf:callpoint device-access-policy-counters-v6; // _nfvis_exclude_line_
        key "name";
        tailf:hidden cli;

        leaf name {
          tailf:info "Device Access Policy name";
          type viptela:named-type-127;
        }
        config false;
        list device-access-policy-counter-list {
          tailf:info "Device access policy counter list";
          tailf:callpoint device-access-policy-counter-list-v6; // _nfvis_exclude_line_
          tailf:cli-no-key-completion;
          tailf:cli-suppress-show-match;
          key "counter-name";
          tailf:hidden cli;

          leaf counter-name {
            tailf:info "Counter name";
            tailf:cli-suppress-show-match;
            type viptela:named-type;
          }
          leaf packets {
            type yang:counter64;
            tailf:cli-suppress-show-match;
          }
          leaf bytes {
            type yang:counter64;
            tailf:cli-suppress-show-match;
          }
        }

The following example shows the policy details of a counter.

show policy device-access-policy-counters

                  COUNTER
NAME          NAME        PACKETS   BYTES
-----------------------------------------------------------
dev_pol       ssh_packs      -       - 
snmp_policy   snmp_packs     0       0 

Yang model for the command device-access-policy :

list device-access-policy {
      tailf:info "Configure IPv4 device-access policy";
      key "name";
      when "/viptela-system:system/viptela-system:personality = 'vedge'";

      leaf name {
        tailf:info "Name of IPv4 device-access policy";
        type viptela:named-type-127;
      }

      list sequence {
        tailf:info "List of sequences";
        key "seq-value";

        leaf seq-value {
          tailf:info "Sequence value";
          type uint16 {
            tailf:info "<0..65530>";
            range "0..65530";
          }
        }

        container match {
          tailf:info "Match criteria";
          tailf:cli-add-mode;

          choice source {
            case prefix {
              leaf-list source-ip {
                tailf:info "List of source addresses";
                tailf:cli-flat-list-syntax;
                tailf:cli-replace-all;
                type inet:ipv4-prefix;
              }
            }

            case prefix-list {
              leaf source-data-prefix-list {
                tailf:info "Source prefix list";

                type leafref {
                  path "../../../../lists/data-prefix-list/name";
                }
              }
            }

          choice destination {
            case prefix {
              leaf-list destination-ip {
                tailf:info "List of destination addresses";
                tailf:cli-flat-list-syntax;
                tailf:cli-replace-all;
                type inet:ipv4-prefix;
              }
            }

            case prefix-list {
              leaf destination-data-prefix-list {
                tailf:info "Destination prefix list";

                type leafref {
                  path "../../../../lists/data-prefix-list/name";
                }
              }
            }
          }

          leaf-list source-port {
            tailf:info "List of source ports";
            tailf:validate port_range {
              tailf:call-once 'true';
              tailf:dependency '.';
            }
            tailf:cli-flat-list-syntax;
            tailf:cli-replace-all;
            type viptela:range-type {
              tailf:info "<0..65535> or range";
            }
          }

          leaf-list destination-port {
            tailf:info "List of destination ports";
            tailf:validate port_range {
              tailf:call-once 'true';
              tailf:dependency '.';
            }
            tailf:cli-flat-list-syntax;
            tailf:cli-replace-all;
            type viptela:range-type {
              tailf:info "<0..65535> or range";
            }
          }

          leaf-list destination-vpn {
            tailf:info "List of VPN ID";
            tailf:validate port_range {
              tailf:call-once 'true';
              tailf:dependency '.';
            }
            tailf:cli-flat-list-syntax;
            tailf:cli-replace-all;
            type viptela:range-type {
              tailf:info "<0..65535> or range";
            }
          }

        }
          
        container action {
          tailf:cli-add-mode;
          tailf:cli-incomplete-command;
          tailf:info "Accept or drop";
              
          leaf action-value {
            tailf:cli-hide-in-submode;
            tailf:cli-drop-node-name;
            tailf:cli-show-with-default;
            type action-data-enum;
          } 

          leaf count {
            tailf:info "Number of packets/bytes matching this rule";
            type string {
              tailf:info "<1..32 characters>";
              length '1..32';
            }     
          }     
        }     
      }     
          
      leaf default-action {
        tailf:cli-show-with-default;
        tailf:info "Accept or drop";
        type action-data-enum;
      }
    }

Yang model for the command device-access-policy-names :

list device-access-policy-names {
        tailf:info "IPv6 device access policy names";
        when "/viptela-system:system/viptela-system:personality = 'vedge'";
        tailf:callpoint device-access-policy-names-v6; // _nfvis_exclude_line_
        tailf:cli-no-key-completion;
        key "name";
        tailf:hidden cli;

        leaf name {
          tailf:info "Device Access Policy name";
          type viptela:named-type-127;
        }
        config false;
      }

The following example shows the list of configured policies:

show policy device-access-policy-names

NAME
-------------
dev_pol
snmp_policy