End of support for three types of regions

Overview of end of support for three types of regions

To streamline Multi-Region Fabric (MRF) architecture and simplify operations, Cisco Catalyst SD-WAN is phasing out three features. From Cisco Catalyst SD-WAN Release 20.15.1 and Cisco IOS XE Catalyst SD-WAN Release 17.15.1a, these MRF features are being phased out:

  • Secondary Regions

  • Subregions

  • Management regions

From Cisco Catalyst SD-WAN Release 20.15.1, we do not recommend using these features. If necessary, you can configure them by API. Later releases discontinue support for the features.

If your network uses any of these features, see the recommendations described here for the steps to take.

Secondary regions

In the most basic Multi-Region Fabric (MRF) architecture, each device belongs to a single region. Secondary regions were introduced to provide another facet to MRF architecture, enabling direct tunnel connections between edge routers in different primary regions. Defining a secondary region means that devices operate in two regions simultaneously, with different paths available through the device’s primary and secondary regions. Devices establish tunnels with peers in both the primary access region and the secondary region.

Figure 1. Comparison of a Direct Path Using a Secondary Region and a Multi-Hop Path Using Primary Regions and the Core Region

Ending support for secondary regions

Secondary regions can lead to networks that mix two types of environments:

  • A hierarchical network design regionalized, with isolated per-region control-planes, which is simple to manage, and is optimized for scale and fault-tolerance

  • A flat, non-hierarchical secondary region network without the safeguards of network hierarchy, control-plane isolation, and fault-tolerance

This can create numerous traffic forwarding paths and adds complexity to network operations. For this reason, secondary regions are not recommended from Cisco Catalyst SD-WAN Release 20.15.1, and support ends in a later release.

What to do next

For simple, optimized, scaled and fault-tolerant hierarchical network design, with the benefits of isolated per-region control and data planes, continue to use MRF. If you do not require a hierarchical network design, explore flat (non-MRF) network designs. If your network uses secondary regions, reconfigure to eliminate secondary regions.

Subregions

Subregions were introduced to enable subdividing access regions to separate edge routers into multiple distinct domains within a region. Devices in a subregion can have full-mesh connectivity to subregion peers without requiring full-mesh connectivity to all devices in the access region.

Figure 2. Subregion Scenario
Multi-Region Fabric network with two regions and three subregions.

Alternative: tunnel groups and affinity groups

You can achieve a similar subdivision of access regions using tunnel groups or affinity groups.

  • Tunnel groups: You can constrain tunnel connectivity by configuring tunnel groups, per TLOC. Devices establish Cisco Catalyst SD-WAN tunnels only with TLOCs that (a) have a matching tunnel group ID, or (b) do not have a tunnel group ID configured. Tunnel groups scale to 62 per WAN access region. When you reuse a tunnel group ID in different regions, the ID operates independently within each separate region.

  • Affinity groups (AG) and affinity group preference (AGP): You can use affinity groups and affinity group preference with or without tunnel groups to designate path preferences among distinct groups of devices within an access region. With affinity groups, you can configure Cisco SD-WAN Control Components to restrict TLOC and route advertisement according to affinity group. For example, you can use an affinity group to restrict route advertisement to devices within the same site.

Ending support for subregions

Subregion and affinity group configurations apply at the device level, encompassing all TLOCs on a device. By contrast, tunnel group configurations operate per TLOC.

Because the functionality is similar, and because tunnel groups and affinity groups offer simplicity, subregions are not recommended from Cisco Catalyst SD-WAN Release 20.15, and support ends in a later release.

What to do next

Replace subregion configurations with tunnel groups.

Replace Subregion Configurations with Tunnel Groups

Cisco Catalyst SD-WAN Release 17.15.x and Cisco Catalyst SD-WAN Control Components Release 20.15.x are the last releases to support subregions. If your network uses subregions, we recommend replacing them with tunnel groups.


Note

This procedure triggers a reset of control connections, which can cause a small amount of packet loss. Perform the procedure during a maintenance window.

Procedure

Step 1

For each configured subregion, choose a tunnel group ID to apply to each device in the subregion. The range of tunnel group IDs is 0 to 61.

Step 2

Remove the subregion ID configuration from the devices.

Step 3

Apply the tunnel group ID configuration to the devices.

Step 4

After the configuration takes effect, verify that devices form tunnels based on the new tunnel groups tunnel group IDs, and the affinity groups and affinity group preference configuration.

Management regions

Management regions were introduced to provide a distinct means, separate from individual access regions, for connecting to management gateways. Management gateways are devices that can carry device management traffic, such as simple network management protocol (SNMP), system logs, Cisco NetFlow data, and so on. Connectivity between devices and management gateways is by a hub-and-spoke architecture.

Ending support for a management region

To simplify MRF network configuration, management regions are not recommended from Cisco Catalyst SD-WAN Release 20.15.1, and support ends in a later release.

What to do next

Instead of management regions, we recommend using a management VRF to carry device management traffic.