Introduction

This document is a Quick start guide for Simplified configuration and policies in Catalyst SD-WAN.

Summary

With Cisco Catalyst SD-WAN Software Release 20.12/17.12, it is recommended that users start migration from traditional configuration based on device and feature templates, to the new configuration approach based on Configuration Groups and Policy Groups. In this document, important details for the new configuration approach are described.

The main goal of this document is to serve as a guide for starting with using new constructs for Configuration, Policies and Onboarding, with the 20.12 golden release. The document does not cover explanations of individual features.

New Deployments

To successfully utilize the new configuration approach, you need to execute these steps:

1. Network: Define the Network Hierarchy and System Constructs
2. Configuration: Create Configuration with Configuration Groups using Workflow
3. Applications: Define Custom Applications, if required, using the Application Catalog
4. Policies: Create Policies using Policy Groups
5. Topology: Define Topology
6. Onboard: Onboard and Tag devices
7. Deploy: Associate and Deploy Configuration Groups and Policy Groups. Activate Topology.

Flowchart for New Deployments

Existing Deployments

1. Execute the steps mentioned in the Existing Deployments section
2. Use the Conversion tool to convert existing configuration/policies to new Configuration/Policies

Enhancements to User Experience and Operational Simplification

Cisco Catalyst SD-WAN offers an enhanced User Experience and simplifies Operations.

• Common UI: A new UX framework has been introduced in Catalyst SD-WAN Manager and other Cisco products, to be about consistency in the User eXperience and providing a common look and feel across products.
• Configuration: Simplified configuration and policy creation & deployment with intuitive intent-based workflows and the use of Cisco-recommended smart defaults.
• Monitoring: Rich insights into network and application performance & health with new widgets and customizable & enhanced dashboards.
• Troubleshooting: Dynamic site & network topology views, context-based troubleshooting tools access, Reports on network & application performance on a scheduled basis.

Benefits

Define your Network Hierarchy and System Constructs

Network Hierarchy

Provides a notion of ‘hierarchy’, that is, Sites, Regions and Areas, for the network. You can create this based on your network.

Example:

Network Hierarchy Manager (NHM)

This helps to define user-friendly site names which helps to achieve operational simplification.

System Constructs

These pools automate System-IP and Site-ID assignments during device configuration deployment.

You can define the IP pool for System-IP auto assignments. Site ID is assigned from the Global_Site pool.

Add Pool Parameters

View and Manage Pools

Workflows

A workflow is a collection of guided steps to help you perform a certain task easily.

• The goal of a workflow is to help Novice users easily create configurations and deploy them to the device.
• Most of the configuration knobs/settings are set to Cisco-recommended smart defaults.
• Users need to specify a few configurations only.
• Advanced configuration knobs are available outside of the workflow, where the configuration group can be manually edited.

A Workflow Library lists all the available workflows.

Workflow Library

Configuration Groups

Configuration Groups is a fresh approach to fabric configuration that is based on principles of simplicity, re-usability and structure.

https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/config-groups/configuration-group-guide/using-config-groups.html

Configuration Groups Structure

Configuration Groups

• Logical grouping of devices that share a common purpose within the WAN.
• The user defines and can customize this grouping based on their business needs.

For example; East/West, Americas/APJC/EMEAR, Retail Store/Distribution Centre

Feature Profiles

• Flexible “buckets” of configuration that can be shared across Configuration Groups.
• Create Feature Profiles based on features that are required
• Put profiles together to complete device configuration, like building blocks
• Build, save, and reuse

For example; Basic Profile, WAN Profile, LAN Profile

Configuration Group Deployment Examples

Note:

• Configuration Groups are Device Model Agnostic
• Feature Profiles can be shared across Configuration Groups    

Use-case 1: Government Customer

Example Usecase 1 - Configuration Groups

Configuration Group HUB

Execute the Create Configuration Group Workflow.

Create Configuration Group Workflow Option

WAN profile

Example Usecase 1 - WAN Profile 1

Using the workflow, the complete WAN profile configuration for this use case, can be generated.

Entities like actual Static IP, Static Default route IP/subnet/Next-Hop and so on, can be specified as Global or Device-specific.

The device-specific option can be specified with actual values during deployment of the Configuration-group to the devices.

LAN profile

Example Usecase 1 - LAN Profile 1

Using the workflow, most of the LAN profile configuration for this use-case, can be generated.

• 2 VPNs
• BGP routing in each of the VPNs (AS number, network prefixes, neighbors)

Entities like actual Dot1Q sub-interfaces and any other entity marked as Device-specific, can be specified with actual values during deployment of the Configuration-group to the devices.

System Profile

Example Usecase 1 - System Profile 1

Using the workflow, most of the System profile configuration for this use-case, can be generated – OMP, AAA, NTP, Logging and so on.

Configuration Group SiteType1

Execute the Create Configuration Group Workflow.

WAN profile

Example Usecase 1 - WAN Profile 2

Using the workflow, most of the WAN profile configuration for this use-case, can be generated. Ethernet interfaces for Internet and Starlink. DHCP.

LAN profile

Example Usecase 1 - LAN Profile 2

Using the workflow, some of the LAN profile configuration for this use-case, can be generated. 2 VPNs, DIA static route.

Entities like actual Dot1Q sub-interfaces and any other entity marked as Device-specific, can be specified with actual values during deployment of the Configuration-group to the devices.

System Profile

Example Usecase 1 - System Profile 2

Using the workflow, most of the System profile configuration for this use-case, can be generated – OMP, AAA, NTP, Logging and so on.

CLI Profile

Example Usecase 1 - CLI Profile 2

Features not supported via GUI, like App/Flow Visibility (NBAR) enabling, can be configured using a CLI profile.

App/Flow visibility

To enable app-visibility and flow-visibility, use CLI profile/parcel.

(In 20.13 and later, it is available under Advanced Settings in Policy Group)

However, in 20.12, if a AAR policy is configured then, App/Flow Visibility is enabled. And configuring this using CLI profile/parcel, is not required.

Configuration Group SiteType2

Execute the Create Configuration Group Workflow.

WAN profile

Example Usecase 1 - WAN Profile 3

Using the workflow, most of the WAN profile configuration for this use-case, can be generated. Ethernet interface for Internet. DHCP.

LAN profile

Example Usecase 1 - LAN Profile 3

Using the workflow, some of the LAN profile configuration for this use-case, can be generated. 1 VPN, DIA static route.

Entities like actual Dot1Q sub-interfaces and any other entity marked as Device-specific, can be specified with actual values during deployment of the Configuration-group to the devices.

System Profile

Same as Configuration Group SiteType1

CLI Profile

Same as Configuration Group SiteType1

Configuration Group SiteType3

Execute the Create Configuration Group Workflow.

WAN Profile

Same as Configuration Group SiteType2

LAN Profile

Example Usecase 1 - LAN Profile 4

Using the workflow, some of the LAN profile configuration for this use-case, can be generated. 1 VPN, DIA static route.

Entities like actual Dot1Q sub-interfaces and any other entity marked as Device-specific, can be specified with actual values during deployment of the Configuration-group to the devices.

System Profile

Same as Configuration Group SiteType1

CLI Profile

Same as Configuration Group SiteType1

Use-case 2: Retail Customer

Example Usecase 2 - Configuration Groups

Configuration Group HQ and Warehouse

Execute the Create Configuration Group Workflow.

WAN profile

Using the workflow, all of the WAN profile configuration for this use-case, can be generated.

LAN Profile

Using the workflow, all of the LAN profile configuration for this use-case, can be generated.

Entities like actual Dot1Q sub-interfaces and any other entity marked as Device-specific, can be specified with actual values during deployment of the Configuration-group to the devices.

System Profile

Using the workflow, all of the System profile configuration for this use-case, can be generated.

Configuration Group Stores

Execute the Create Configuration Group Workflow.

WAN profile

Using the workflow, most of the WAN profile configuration for this use-case, can be generated.

LAN Profile

Using the workflow, all of the LAN profile configuration for this use-case, can be generated.

Entities like actual Dot1Q sub-interfaces and any other entity marked as Device-specific, can be specified with actual values during deployment of the Configuration-group to the devices.

System Profile

Same as Configuration Group HQ and Warehouse.

Associate

In the Configuration Group edit page (Configuration -> Configuration Groups), you can Associate devices with the Configuration Group.

Click on Associate Devices and go through the steps in the workflow.

Associate Device - Configuration Groups

Deploy

Execute the Deploy Configuration Group Workflow.

Deploy Configuration Group Workflow

Re-usability

1. Configuration Groups are device model agnostic.

Configuration Group - Device Model Agnostic

2. Use Configuration variables – device-specific values

Configuration Group - Device Specific Variables

A Feature profile can have some configuration defined as device-specific, similar to template variables.

Example: Interface IP Address, port numbers, Interface name and so on.

These device-specific values can be supplied at deploy time. And it can be different for different devices.

Configuration Group - Device Specific Variables Example 1

Configuration Group - Device Specific Variables Example 2

Configuration Group - Device Specific Variables Example 3

3. Re-use Feature Profiles

Feature profiles can be re-used across configuration groups.

Illustration:

For several devices, if the WAN and System configurations are the same and they differ only in the LAN configuration, for example, then, the WAN and system profiles can be re-used across their Configuration groups while having a different LAN profile in each.

Re-use Feature Profiles - 1

LAN profile 1

Re-use Feature Profiles - 2

LAN profile 2

Re-use Feature Profiles - 3

LAN profile 3

Application Catalog

Traditional devices were able to manipulate traffic flows by conditional matching of source and/or destination IP addresses, source/destination ports, and protocols.   As more and more applications are dependent upon DNS or embedded in HTTP it is harder to accurately identify network traffic at the application level.

Cisco’s Network Based Application Recognition (NBAR) engine has the ability to classify over 1500 applications providing network engineers the ability to classify and manipulate traffic flows with more granularity.    Cisco’s Catalyst SD-WAN Manager contains the ability to connect to a Cisco application repository where signatures for applications can be updated quickly; which has significance for when cloud providers change hosting locations or traffic patterns.

The Application catalog provides the ability to create custom applications based upon the matching of server name, ip address, ports, or protocol.  The application is then defined to a specific Application Family, Application Group, Traffic Class, and Business Relevance.

Application Catalog

Applications can be dragged and dropped to the appropriate business relevance and/or traffic classification.  Upon saving the changes, the definitions are updated in the database.

Policy Groups

Similar to the Configuration Groups, a Policy Group is a grouping of policies that are deployed to devices associated with the Policy Group.

https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/Policy-Groups/policy-groups/m-policy-groups.html

Policy Group approaches policy creation and deployment based on intent. A simplified UI and workflow makes the creation of a policy, grouping policies and deploying to devices, an easy task.

Policy Groups

Application Priority & SLA

With this policy intent, you can specify:

• Application Aware Routing and SLA policy
• QoS policy
• Traffic Data policy
• DIA policy
• SIG policy

Two modes are provided.

Simple mode

This is the Default mode.

Simple Mode

This provides a quick and easy way to define the Application priority and SLA for your network.

Advanced mode

This is a full and flexible mode.

Advanced Mode

Quality of Service

In the QoS Queue option, you can add a QoS policy:

Add QoS Policy

Queuing Models

Next you can define the Traffic data policy (Add Traffic policy).

Add rules to match desired traffic and redirect to appropriate Forwarding classes.

QoS Policy 2

Application Aware Routing

You can define SLA classes and use them in a Traffic policy to realize the intent of an AAR policy.

AAR Policy

App/Flow visibility

To enable app-visibility and flow-visibility, use CLI profile/parcel in Configuration Group.

(In 20.13 and later, it is available under Advanced Settings in Policy Group)

However, in 20.12, if a AAR policy is configured then, App/Flow Visibility is enabled. And configuring this using CLI profile/parcel, is not  required.

Traffic policy

Traffic policy can also be used to create a DIA policy, SIG redirection and so on. Add Rules as required.

Traffic Policy

Embedded Security

Defines the security policy for on-box NGFW, IPS, Malware, and content filtering

Secure Internet Gateway/Secure Service Edge

Defines settings required to establish tunnels to cloud based content and security entities, like Cisco Secure Access.

DNS Security

Define settings to allow the usage of cloud-based DNS security services for content filtering.

Groups of Interest

Define the object lists to use in your policies. Example: Application lists, VPN lists, Site lists, Prefixes list and so on.

Additionally, for Security policies, define your profiles like Advanced inspection profiles, SSL decryption policy and so on.

Policy Groups - Groups of Interest

Associate and Deploy

Similar to Configuration Groups, associate devices to Policy Group and deploy.

Localized policies

Localized policies like ACL, Route policy, Device access policy and so on, are defined in Configuration groups.

Topology

Define your Network Topology.

Start with a Full mesh or Hub-n-Spoke and customize it if required.

Topology menu

Topology and VPN

Keep in mind these design changes while creating Topology and specifying VPNs.

The new design allows dynamic mapping of VPN name to VPN ID, instead of 1:1 mapping.

A VPN name mapping to multiple VPN IDs

Illustration:
Say there is a VPN with the name Corporate in two different Configuration Groups.

One has VPN ID 10 and the other has VPN ID 20.

The Topology workflow VPN list shows one instance of Corporate VPN only.

Once you select Corporate VPN, the SD-WAN Manager determines the VPN IDs based on the Topology.
Say there are 2 devices in 2 sites:
1. Device1 in site 100 with Corporate as VPN 10
2. Device2 in site 200 with Corporate as VPN 20

If both site 100 and site 200 are part of the Topology then, SD-WAN Manager creates a VPN list that will have both VPN IDs (10 and 20).
If only site 100 is part of the Topology then, SD-WAN Manager creates a VPN list that will have VPN ID 10 only.
If only site 200 is part of the Topology then, SD-WAN Manager creates a VPN list that will have VPN ID 20 only.

Muliple VPN names mapping to the same VPN ID

You can configure multiple Topology policies with same VPN name that are mapped to different VPN IDs in different sites.

SD-WAN Manager determines the actual mapping based on which Topology is associated to which sites.

Illustration:

Two users can create two different Configuration Groups.

One specifies VPN ID 100 as Finance VPN and the other specifies it as Engineering VPN.

Then they can create Topology using their respective VPN names.

Onboarding

For onboarding your physical routers, use the Quick Connect Workflow.

Using this workflow, pre-define the Hostname, System-IP, and Site-name/ID for the devices to be onboarded. Manager auto-generates these but you can modify them if you wish to do so. You can also tag the devices which can then be used to auto-associate the devices to Configuration Groups.

During the PnP ZTP onboarding process, the devices establish the control plane tunnel connections to the SD-WAN Manager. SD-WAN Manager now pushes the pre-defined fabric configuration to the devices and the devices join the SD-WAN fabric.

Quick Connect Workflow

Quick Connect Workflow Description

Tagging

Devices can be associated with user-defined Tags.

Tags can be used for grouping, describing, finding, or managing devices.

Tags enables grouping of devices which can then be used in other features.

Tagging Examples

Example: Association of Configuration Groups to devices.

Configuration Group rules can be set to enable devices with specific Tags to be automatically associated with that Configuration Group.

Add Tag

In Configuration->Devices, Tags can be created / added to / removed from the devices.

Tag Rules in Configuration Group

In the Configuration Group -> Associated Devices page, Tag rules can be added/edited.

Illustration

Tagging Illustration

Existing Deployments

In the SD-WAN network, devices which use the Legacy Configuration and Policies can co-exist with devices using the Simplified Configuration and Policies.

This section offers some recommendations for customers who want to take advantage of the Simplified Configuration and Policies, this section offers some recommendations.

The first step is that devices need to be migrated from Device Templates to Configuration Groups.   Once that is done, policy groups and/or topology can be deployed. 

Configuration Groups

Device templates and configuration groups provide the edge device configuration.   So it is easy for co-existence to occur.    The steps for migrating from a device template to a configuration group are:

Maintaining a consistent naming scheme for variables simplifies device-specific settings.  If all the device values are in a single CSV then you only have to rename the column headers once..

Policy Groups

Devices that are configured via configuration groups can use a Centralized Policy, or migrate towards a Policy Group; but not both at the same time for the same application.  In essence, the goal is to keep the same underlying policy for the edge devices.  Policy Groups combine the original AAR and Data policies into a single Application Priority & SLA PG component.  In essence, we are just changing how the configuration for policies is built (but not sent to the SD-WAN Manager).

It’s important to note that you cannot have a Data Policy or AAR policy reference a site list with a site that has the Application Priority & SLA component as they both configure the same setting.  

It is possible to have Centralized Policy with only a Control Policy reference a site that uses a Policy Group with Application Priority & SLA) as they configure different components of a centralized policy.

The steps to migrate a device from a Centralized Policy to a Policy Group involves these steps:

Topology

Devices that are configured via configuration groups can use a Centralized Policy, or migrate towards a Topology. In essence, the goal is to keep the same underlying control policy for the SD-WAN controllers. Topology is the latest iteration of Control Policies.  

It’s important to note that you cannot have a Control Policy policy reference a site list with a site that has a Topology associated with it, as they both configure the same setting.  

It is possible to have a Centralized Policy with only a Data Policy and/or AAR policy, and a topology policy as they configure different components.

Steps to migrate a device from a Centralized Policy to a Policy Group:

Conversion Tool

Scope

The Conversion Tool does a 1-to-1 conversion of templates to configuration groups. The tool collects the templates from an SD-WAN Manager instance, converts them to configuration groups (including feature profiles and feature parcels), and uploads the newly converted constructs to the SD-WAN Manager.

* Conversion of policies to policy groups is tentatively expected to be available in the Conversion Tool in October 2024.

Access Details

A beta version of the tool is available. Please reach out to sdwan-ux-conversion-tool@cisco.com for more information.

How to Use

Prerequisite

Before using the tool, ensure that your SD-WAN Manager is running 20.12.x. If not, upgrade to 20.12 before proceeding.

Conversion Tool Workflow

Post-Conversion

Your new constructs are now ready to use. Execute the steps in the ‘Existing Deployments’ section to migrate your devices to the newly converted configuration groups.

Considerations

• The conversions provided by the tool are meant to serve as guidance. Please analyze and test before deploying in a production environment.
• The tool does not consider the device-agnostic capability of configuration groups. Users can analyze their templates before selecting which to convert or analyze the converted configuration groups and associate devices accordingly to benefit from the device-agnostic capability.
• Variable names and global values from legacy constructs are copied over to the newly converted constructs.
• The tool does not push configuration to devices. After performing the conversions, the user is responsible for detaching devices from templates and associating them to the new configuration groups.

20.12 Considerations

Related Information

• Cisco SD-WAN and Cloud Networking YouTube Channel: https://www.youtube.com/@CiscoSDWANandCloudNetworking
• UX2.0 - Operational Simplification: 1. Configure a Single Router Site: https://www.youtube.com/watch?v=98z-d3knd
• Cisco Technical Support & Downloads