VPN Membership Policy

A second type of centralized data policy is VPN membership policy. It controls whether a Cisco IOS XE SD-WAN 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 IOS XE SD-WAN 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 vSmart Controller never forwards those routes to that driver.

Step 1: Start the Policy Configuration Wizard

1. In the Cisco vManage NMS, select the Configure > Policies screen.

2. Select the Centralized Policy tab.

3. Click Add Policy.

The policy configuration wizard appears, and the Create Applications or Groups of Interest screen is displayed.

Step 2: Configure Groups of Interest

In Create Groups of Interest, create lists of groups to use in a centralized policy:

1. Create new lists, as described in the following table:

   Table 1.

   List Type	Procedure
   Color	In the left bar, click Color. Click New Color List. Enter a name for the list. From the Select Color drop-down, select the desired colors. Click Add.
   Prefix	In the left bar, click Prefix. Click New Prefix List. Enter a name for the list. In the Add Prefix field, enter one or more data prefixes separated by commas. Click Add.
   Site	In the left bar, click Site. Click New Site List. Enter a name for the list. In the Add Site field, enter one or more site IDs separated by commas. Click Add.
   TLOC	In the left bar, click TLOC. Click New TLOC List. The TLOC List popup displays. Enter a name for the list. In the TLOC IP field, enter the system IP address for the TLOC. In the Color field, select the TLOC's color. In the Encap field, select the encapsulation type. In the Preference field, optionally select a preference to associate with the TLOC. Click Add TLOC to add another TLOC to the list. Click Save.
   VPN	In the left bar, click VPN. Click New VPN List. Enter a name for the list. In the Add VPN field, enter one or more VPN IDs separated by commas. Click Add.

2. Click Next to move to Configure Topology and VPN Membership in the wizard.

Step 3: Configure Topology and VPN Membership

When you first open the Configure Topology and VPN Membership screen, the Topology tab is selected by default:

To configure topology and VPN membership:

In the Topology tab, create a network topology:

Custom Control (Route & TLOC) - Centralized route control policy (for matching OMP routes)

1. In the Add Topology drop-down, select Custom Control (Route & TLOC).

2. Enter a name for the control policy.

3. Enter a description for the policy.

4. In the left pane, click Add Sequence Type. The Add Control Policy popup displays.

5. Select Route. A policy component containing the text string Route is added in the left pane.

6. Double-click the Route text string, and enter a name for the policy component.

7. In the right pane, click Add Sequence Rule. The Match/Actions box opens, and Match is selected by default.

8. From the boxes under the Match box, select the desired policy match type. Then select or enter the value for that match condition. Configure additional match conditions for the sequence rule, as desired. For an explanation of the match conditions, see the OMP Route Match Attributes section in the Configuring Centralized Control Policy topic for your software release.

9. Click Actions. The Reject radio button is selected by default. To configure actions to perform on accepted packets, click the Accept radio button. Then select the action or enter a value for the action. For an explanation of the actions, see the Action Parameters section in the Configuring Centralized Control Policy topic for your software release.

10. Click Save Match and Actions.

11. Click Add Sequence Rules to configure more sequence rules, as desired. Drag and drop to re-order them.

12. Click Add Sequence Type to configure more sequences, as desired. Drag and drop to re-order them.

13. Click Save Control Policy.

Custom Control (Route & TLOC) - Centralized TLOC control policy (for matching TLOC routes)

1. In the Add Topology drop-down, select Custom Control (Route & TLOC).

2. Enter a name for the control policy.

3. Enter a description for the policy.

4. In the left pane, click Add Sequence Type. The Add Control Policy popup displays.

5. Select TLOC. A policy component containing the text string TLOC is added in the left pane.

6. Double-click the TLOC text string, and enter a name for the policy component.

7. In the right pane, click Add Sequence Rule. The Match/Actions box opens, and Match is selected by default.

8. From the boxes under the Match box, select the desired policy match type. Then select or enter the value for that match condition. Configure additional match conditions for the sequence rule, as desired. For an explanation of the match conditions, see the OMP TLOC Match Attributes section in the Configuring Centralized Control Policy topic for your software release.

9. Click Actions. The Reject radio button is selected by default. To configure actions to perform on accepted packets, click the Accept radio button. Then select the action or enter a value for the action. For an explanation of the actions, see the Action Parameters section in the Configuring Centralized Control Policy topic for your software release.

10. Click Save Match and Actions.

11. Click Add Sequence Rules to configure more sequence rules, as desired. Drag and drop to re-order them.

12. Click Add Sequence Type to configure more sequences, as desired. Drag and drop to re-order them.

13. Click Save Control Policy.

To use an existing topology:

1. In the Add Topology drop-down, click Import Existing Topology. The Import Existing Topology popup appears.

2. Select the type of topology.

3. In the Policy drop-down, choose the name of the topology.

4. Click Import.

Click Next to move to Configure Traffic Rules in the wizard.

Click Next to move to Apply Policies to Sites and VPNs in the wizard.

Step 4: Apply Policies to Sites and VPNs

In Apply Policies to Sites and VPNs screen, apply a policy to sites and VPNs:

1. In the Policy Name field, enter a name for the policy. This field is mandatory and can contain only uppercase and lowercase letters, the digits 0 through 9, hyphens (–), and underscores (_). It cannot contain spaces or any other characters.

2. In the Policy Description field, enter a description of the policy. It can contain up to 2048 characters. This field is mandatory, and it can contain any characters and spaces.

3. From the Topology bar, choose the type of policy block. The table then lists policies that you have created for that type of policy block.

4. Associate the policy with VPNs and sites. The choice of VPNs and sites depends on the type of policy block:

   1. For a Topology policy block, click Add New Site List and VPN List or Add New Site. Some topology blocks might have no Add buttons. Choose one or more site lists, and choose one or more VPN lists. Click Add.

   2. For an Application-Aware Routing policy block, click Add New Site List and VPN list. Choose one or more site lists, and choose one or more VPN lists. Click Add.

   3. For a Traffic Data policy block, click Add New Site List and VPN List. Choose the direction for applying the policy (From Tunnel, From Service, or All), choose one or more site lists, and choose one or more VPN lists. Click Add.

   4. For a cflowd policy block, click Add New Site List. Choose one or more site lists, Click Add.

5. Click Preview to view the configured policy. The policy appears in CLI format.

6. Click Save Policy. The Configuration > Policies screen appears, and the policies table includes the newly created policy.

Step 5: Activate a Centralized Policy

Activating a centralized policy sends that policy to all connected Cisco vSmart controllers. To activate a centralized policy:

1. In the Cisco vManage NMS, select the Configure > Policies screen. When you first open this screen, the Centralized Policy tab is selected by default.

2. Choose a policy.

3. Click the More Actions icon to the right of the row, and click Activate. The Activate Policy popup appears. It lists the IP addresses of the reachable Cisco vSmart Controllers to which the policy must be applied.

4. Click Activate.

Following are the structural components required to configure centralized control 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)

Lists

Centralized control policy uses the following types of lists to group related items. In the CLI, you configure lists under the policy lists command hierarchy on Cisco vSmart Controllers.

Sequences

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

In the Cisco vManage NMS, you configure sequences from:

• Configuration > Policies > Centralized Policy > Add Policy > Configure Traffic Rules > (Application-Aware Routing | Traffic Data | Cflowd) > Sequence Type

• Configuration > Policies > Custom Options > Centralized Policy > Traffic Policy > (Application-Aware Routing | Traffic Data | Cflowd) > Sequence Type

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

Each sequence in a centralized control policy can contain one match condition (either for a route or for a TLOC​) and one action condition.

Match Parameters

Centralized control policy can match OMP route or TLOC route attributes.

In the Cisco vManage NMS, you configure match parameters from:

• Configuration > Policies > Centralized Policy > Add Policy > Configure Topology and VPN Membership > Add Topology > Custom Control (Route & TLOC) > Sequence Type > (Route | TLOC) > Sequence Rule > Match

• Configuration > Policies > Custom Options > Centralized Policy > Topology > Add Topology > Custom Control (Route & TLOC) > Sequence Type > (Route | TLOC) > Sequence Rule > Match

In the CLI, you configure the OMP route attributes to match with the policy control-policy sequence match route command, and you configure the TLOC attributes to match with the policy control-policy sequence match tloc command.

Each sequence in a policy can contain one match section—either match route or match tloc​.

OMP Route Match Attributes

For OMP routes (vRoutes), you can match these attributes:

TLOC Route Match Attributes

For TLOC routes, you can match these attributes:

Action Parameters

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

In the Cisco vManage NMS, you configure match parameters from:

• Configuration > Policies > Centralized Policy > Add Policy > Configure Topology and VPN Membership > Add Topology > Custom Control (Route & TLOC) > Sequence Type > (Route | TLOC) > Sequence Rule > Action

• Configuration > Policies > Custom Options > Centralized Policy > Topology > Add Topology > Custom Control (Route & TLOC) > Sequence Type > (Route | TLOC) > Sequence Rule > Action

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

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

In the action, you first specify whether to accept or reject a matching route or TLOC:

Then, for a route or TLOC that is accepted, you can configure the following actions:

Default Action

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

In the Cisco vManage NMS, you modify the default action from Configuration > Policies > Centralized Policy > Add Policy > Configure Topology and VPN Membership > Add Topology > Custom Control (Route and TLOC) > Sequence Type > (Route | TLOC) > Sequence Rule > Default Action.

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

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 IOS XE SD-WAN overlay network domain.

Traffic Engineering

This example of traffic engineering forces all traffic to come to a Cisco IOS XE SD-WAN device using a device hub instead of directly.

One common way to design a domain in a Cisco IOS XE 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 IOS XE 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 vSmart 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 vSmart 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 vSmart 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 vSmart 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 vSmart Controller as an outbound policy, as indicated by the out option in the apply-policy site command. This option means the Cisco vSmart 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 vSmart 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 vSmart 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 vSmart 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 vSmart 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.

Step 1: Start the Policy Configuration Wizard

To start the policy configuration wizard:

1. In the Cisco vManage NMS, select the Configure > Policies screen.

2. Select the Localized Policy tab.

3. Click Add Policy.

The policy configuration wizard opens, and the Create Groups of Interest screen is displayed.

Step 2: Configure Groups of Interest

In Create Groups of Interest, create lists of groups to use in localized policy:

1. Create new lists, as described in the following table:

1. Click Next to move to Configure Forwarding Classes/QoS in the wizard.

2. Click Next to move to Configure Access Control Lists in the wizard.

3. Click Next to move to Configure Route Policies in the wizard. 

Step 3: Configure Route Policies

In Configure Route Policies, configure the routing policies:

1. In the Add Route Policy tab, select Create New.

2. Enter a name and description for the route policy.

3. In the left pane, click Add Sequence Type. A Route box is displayed in the left pane.

4. Double-click the Route box, and type a name for the route policy.

5. In the right pane, click Add Sequence Rule to create a single sequence in the policy. The Match tab is selected by default.

6. Click a match condition.

7. On the left, enter the values for the match condition.

8. On the right enter the action or actions to take if the policy matches.

9. Repeat Steps 6 through 8 to add match–action pairs to the route policy.

10. To rearrange match–action pairs in the route policy, in the right pane drag them to the desired position.

11. To remove a match–action pair from the route policy, click the X in the upper right of the condition.

12. Click Save Match and Actions to save a sequence rule.

13. To rearrange sequence rules in an route policy, in the left pane drag the rules to the desired position.

14. To copy, delete, or rename an route policy sequence rule, in the left pane, click More Options next to the rule's name and select the desired option.

15. If no packets match any of the route policy sequence rules, the default action is to drop the packets. To change the default action:

    1. Click Default Action in the left pane.

    2. Click the Pencil icon.

    3. Change the default action to Accept.

    4. Click Save Match and Actions.

16. Click Next to move to Policy Overview in the wizard.

17. Click Preview to view the full policy in CLI format.

18. Click Save Policy.

Step 4: Apply a Route Policy in a Device Template

1. In the Cisco vManage NMS, select the Configuration > Templates screen.

2. If you are creating a new device template:

   1. In the Device tab, click Create Template.

   2. From the Create Template drop-down, select From Feature Template.

   3. From the Device Model drop-down, select one of the devices.

   4. In the Template Name field, enter a name for the device template. This field is mandatory and can contain only uppercase and lowercase letters, the digits 0 through 9, hyphens (–), and underscores (_). It cannot contain spaces or any other characters.

   5. In the Description field, enter a description for the device template. This field is mandatory, and it can contain any characters and spaces.

   6. Continue with Step 4.

3. If you are editing an existing device template:

   1. In the Device tab, click the More Actions icon to the right of the desired template, and click the pencil icon.

   2. Click the Additional Templates tab. The screen scrolls to the Additional Templates section.

   3. From the Policy drop-down, select the name of a policy that you have configured.

4. Click the Additional Templates tab located directly beneath the Description field. The screen scrolls to the Additional Templates section.

5. From the Policy drop-down, select the name of the policy you configured in the above procedure.

6. To apply a route policy to BGP:

   1. Scroll to the Service VPN section.

   2. In the Service VPN drop-down, type the service VPN number (a VPN number other than 0 or 512).

   3. From Additional VPN Templates, select BGP.

   4. From the BGP drop-down, click Create Template or View Template.

   5. Select the Neighbor tab, click the plus sign (+), and click More.

   6. In Address Family, change the scope to Device Specific. Then, Click On to enable Address Family, Click On to enable Route Policy In, and specify the name of a route policy to apply to prefixes received from the neighbor, or Click On to enable Route Policy Out, and specify the name of a route policy to apply to prefixes sent to the neighbor. This name is one that you configured with a policy route-policy command.

   7. Click Save to save the neighbor configuration, and then click Save to save the BGP configuration.

7. To apply a route policy to routes coming from all OSPF neighbors:

   1. Scroll to the Service VPN section.

   2. In the Service VPN drop-down, type the service VPN number (a VPN number other than 0 or 512).

   3. From Additional VPN Templates, select OSPF.

   4. Click Create Template or View Template.

   5. Select the Advanced tab.

   6. In Policy Name, specify the name of a route policy to apply to incoming routes. This name is one that you configured with a policy route-policy command.

   7. Click Save.

8. To apply a route policy before redistributing routes into OSPF:

   1. Scroll to the Service VPN section.

   2. In the Service VPN drop-down, type the service VPN number (a VPN number other than 0 or 512).

   3. From Additional VPN Templates, select OSPF.

   4. Click Create Template or View Template.

   5. Select the Redistribute tab, click the plus sign (+), and select the protocol from which to redistribute routes into OSPF.

   6. Specify the name of a route policy to apply to the routes being redistributed. This name is one that you configured with a policy route-policy command.

   7. Click Save.

9. Click Save (for a new template) or Update (for an existing template).

Lists

Route policy uses the following types of lists to group related items. You configure lists under the policy lists command hierarchy on Cisco IOS XE SD-WAN 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 vManage NMS, 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 vManage NMS, 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 vManage NMS, 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 vManage NMS, 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 vManage NMS, you modify the default action from Configuration > Policies > Localized Policy > Add Policy > Configure Route Policy > Sequence Type > Sequence Rule > Default Action.

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 vManage 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 Device Access Policy:

1. In the Cisco vManage, select the Configure > Policies screen.

2. Select the Localized Policy tab.

3. From Custom Options > Localized Policy pane, select Access Control Lists.

4. Click Add Device Access Policy drop down list to add a device. The options are Add IPv4 Device Access Policy and Add IPv6 Device Access Policy.

5. Select Add IPv4 Device Access Policy from the drop-down list to add IPv4 ACL Policy. The Edit Device IPv4 ACL Policy page displays.

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

7. Click Add ACL Sequence to add a sequence. The Device Acces Control List page displays.

8. Click Sequence Rule. Match and Actions options display.

9. From the Match pane, 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.
   Destination VPN	Enter a VPN ID.

10. From the Actions tab, 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.

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

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

13. If no packets match 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 IOS XE SD-WAN devices. When you try to configure IPv6 prefix match on these devices, Cisco vManage fails to generate device configuration.

To configure ACL statistics and counters using yang:

Yang file: Cisco-IOS-XE-acl-oper.yang
 
  grouping ace-oper-data {
    description
      "ACE operational data";
    leaf match-counter {
      type yang:counter64;
      description
        "Number of matches for an access list entry";
    }
  }

Example configuration using yang model:

Router#config-t
Router(config)# ip access-list extended ACL-1        
Router(config-ext-nacl)# 1 permit ip 10.10.10.1 0.0.0.0 any
Router(config-ext-nacl)# 2 deny ip 20.20.0.0 0.0.255.255 any
Router(config-ext-nacl)# commit                            
Commit complete.                                           
 
Router#
Router#
Router#request platform software system shell
Activity within this shell can jeopardize the functioning of the system.
Are you sure you want to continue? [y/n] y                              
[Router:/]$                                                                                                                                  
[Router:/]$                                                                                        
 [Router:/]$                                                                                                                                       

[Router:/]$                                                                                                                                        
[Router:/]$ confd_cli -C -P 3010 -noaaa -g sdwan-oper
 
root connected from 127.0.0.1 using console on Router
 
Router# show access-lists access-list ACL-1
ACCESS
CONTROL
LIST     RULE  MATCH
NAME     NAME  COUNTER
------------------------
ACL-1    1     0
         2     0
 
Router# show access-lists access-list ACL-1 | display xml
<config xmlns="http://tail-f.com/ns/config/1.0">
  <access-lists xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-acl-oper">
  <access-list>
    <access-control-list-name>ACL-1</access-control-list-name>
    <access-list-entries>
      <access-list-entry>
        <rule-name>1</rule-name>
        <access-list-entries-oper-data>
          <match-counter>0</match-counter>
        </access-list-entries-oper-data>
      </access-list-entry>
      <access-list-entry>
        <rule-name>2</rule-name>
        <access-list-entries-oper-data>
          <match-counter>0</match-counter>
        </access-list-entries-oper-data>
      </access-list-entry>
    </access-list-entries>
  </access-list>
  </access-lists>
</config>
Router#

To configure ACL statistics and counters using CLI, use the command show ip access-list [access-list-number | access-list-name].

Example configuration using CLI:

show ip access-list [access-list-number | access-list-name]
 
Example:
Router# show ip access-list ACL-1
Extended IP access list ACL-1
10 permit ip host 10.1.1.1 any (3 matches) 30
30 permit ip host 10.2.2.2 any (27 matches)
 
 

To clear counters in ACL stats:
 
clear ip access-list counters {access-list-number | access-list-name}

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 folllwoing example shows the policy details of a conter.

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-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

Yang Model for the command snmp-server community . Following is the ACL settings sample from Cisco-IOS-XE-snmp.yang:

container community {
          description
            "Configure a SNMP v2c Community string and access privs";
          tailf:cli-compact-syntax;
          tailf:cli-sequence-commands;
          leaf community-string {
            tailf:cli-drop-node-name;
            type string;
          }
          container access {
            tailf:cli-drop-node-name;
            tailf:cli-flatten-container;
            leaf standard-acl {
              tailf:cli-drop-node-name;
              tailf:cli-full-command;
              type uint32 {
                range "1..99";
              }
            }
            leaf expanded-acl {
              tailf:cli-drop-node-name;
              tailf:cli-full-command;
              type uint32 {
                range "1300..1999";
              }
            }
            leaf acl-name {
              tailf:cli-drop-node-name;
              tailf:cli-full-command;
              type string;
            }
            leaf ipv6 {
              description
                "Specify IPv6 Named Access-List";
              tailf:cli-full-command;
              type string;
            }
            leaf ro {
              description
                "Read-only access with this community string";
              type empty;
            }
            leaf rw {
              description
                "Read-write access with this community string";
              type empty;
            }
          }
        }

Following is the ACL settings sample from Cisco-IOS-XE-line.yang:

// line * / access-class
    container access-class {
      description
        "Filter connections based on an IP access list";
      tailf:cli-compact-syntax;
      tailf:cli-sequence-commands;
      tailf:cli-reset-container;
      tailf:cli-flatten-container;
      list acccess-list {
        tailf:cli-drop-node-name;
        tailf:cli-compact-syntax;
        tailf:cli-reset-container;
        tailf:cli-suppress-mode;
        tailf:cli-delete-when-empty;
        key "direction";
        leaf direction {
          type enumeration {
            enum "in";
            enum "out";
          }
        }
        leaf access-list {
          tailf:cli-drop-node-name;
          tailf:cli-prefix-key;
          type ios-types:exp-acl-type;
          mandatory true;
        }
        leaf vrf-also {
          description
            "Same access list is applied for all VRFs";
          type empty;
        }
      }
    }