When you integrate more than one Catalyst Center cluster with a single Cisco ISE system, each Catalyst Center cluster is independent. No information is shared among the clusters. In this scenario, when you deploy Cisco Software-Defined Access (SD-Access) on Catalyst Center, the set of virtual networks (VNs) and all other SD-Access is local to each cluster.

Catalyst Center provides a mechanism to coordinate SD-Access and Group-Based Policy (GBP) elements across multiple Catalyst Center clusters integrated with a single Cisco ISE system. To enable global administration of SD-Access across multiple Catalyst Center clusters with a consistent set of VNs, the Multiple Catalyst Center feature leverages the existing secure connection with Cisco ISE to propagate VNs, security group tags (SGTs), Access Contracts, and Group-Based Access Control (GBAC) Policy from one cluster to another cluster. Cisco ISE takes the information learned from one cluster (known as the Author Node) and propagates it to the other clusters (known as the Reader Nodes).

The Multiple Catalyst Center feature is available when you integrate it with Cisco ISE Release 3.2 or later.

Note

The Multiple Catalyst Center operation is disabled by default. To use this feature, select the Enable Multiple Catalyst Center operation (under Advanced Settings) when integrating Catalyst Center with Cisco ISE. You can enable this feature during the initial configuration or at a later time (after Cisco ISE is already integrated). After this functionality is enabled, only deleting the Cisco ISE integration can disable the functionality. If you are using earlier releases of Cisco ISE, contact your account team to submit a request to the Cisco SDA Design Council for inclusion in the Limited Availability program. A Multiple Catalyst Center Limited Availability package is provided to allow access to the limited availability (LA) version of this functionality. For more information, see the Multiple Cisco DNA Center to Single Cisco ISE Prescriptive Deployment Guide.

The Multiple Catalyst Center feature has specific role designations for the clusters:

• Author Node cluster

• Reader Node cluster

The Author Node role is assigned to the first cluster with the Multiple Catalyst Center option enabled that integrates with the Cisco ISE deployment, or the first cluster which enables the Multiple Catalyst Center option. The Author Node cluster is the administration point for the Group-Based Policy (GBP) and for Cisco SD-Access global data. The Author Node cluster manages VNs, SGTs, Access Contracts, and GBAC Policy. You can create, modify, or delete VNs and GBP components only on the Author Node cluster.

The Author Node cluster pushes VN and GBP information to Cisco ISE via ERS (REST) APIs, allowing Cisco ISE to use this information and publish to all other Cisco Catalyst Center Clusters in the Reader Node role through Cisco ISE pxGrid.

Only one cluster can be designated as the Author Node. It’s the only node where GBP and user-defined global SDA data (such as VNs or extranet policy) can be managed.

If SGTs or VNs are operational on the Author Node, it is not possible to delete them.

All other Catalyst Center clusters which have the Multiple Catalyst Center feature enabled are assigned the role of Reader Node cluster. Reader Node clusters have a read-only view of VNs and SGTs.

Even though Reader Node clusters consume and persist the same VNs, SGTs, Access Contracts, and GBAC Policies that are defined on the Author Node cluster, a Reader Node cluster does not display Access Contracts or policies.

You can create VNs only on the Author Node cluster. After creating VNs, they propagate to Reader Node clusters for use in fabric provisioning operations. The Reader Node clusters configure the associated network attributes such as Virtual Network Identifiers (VNID), Route Targets (RT), and Route Distinguishers (RD) which are local to that cluster.

Except for the VN and GBP features, each Reader Node cluster is an independent cluster that manages its own network infrastructure.

The Multiple Catalyst Center feature enables global policy administration across multiple Cisco Catalyst Center clusters integrated to a single Cisco ISE. This capability doesn’t change the underlying limitations of managing virtual networks and fabrics on multiple Cisco Catalyst Center clusters. A VN may have the same name across multiple Cisco Catalyst Center clusters, which allows it to support consistent security group-VN associations across multiple clusters. But at the individual cluster level, the actual network attributes to associate with a VN (VRF, route target, route distinguisher, and so on) aren’t identical across clusters. This is the same as when operating independent Catalyst Center clusters.

You can add up to four Catalyst Center clusters as Reader Node clusters. Before adding a Catalyst Center node as a Reader, you must remove all admin-created Cisco SD-Access global data on the Reader Node cluster for Catalyst Center to integrate with Cisco ISE. This includes nondefault VNs (any VNs other than “DEFAULT_VN” and “INFRA_VN”, Extranet Policy, and so on). In the event there’s any nondefault GBP data (SGTs, Access Contracts, GBP), the user has the option to automatically clean up (delete) all nondefault GBP data, or to merge any GBP data not already present in Cisco ISE.

Note

You can integrate only five Catalyst Center clusters with a single Cisco ISE deployment. This includes one Author Node cluster and up to four Reader Node clusters. It is possible to delete SGTs or VNs on the Author Node even when they are in use on Reader Nodes. In that event, you must delete the stale SGTs or VNs manually on the Reader Nodes (after removing any references).

After integrating Catalyst Center with Cisco ISE and performing GBP synchronization policy information is synchronized between Catalyst Center and Cisco ISE. The policy authoring privileges reside within Catalyst Center. The Cisco ISE windows for management of SGTs, Security Group ACLs (SGACLs), and Egress Policy become read-only.

You can manage group-based policy (Security Groups, Access Contracts, and GBAC Policy) in Cisco ISE instead of in Catalyst Center.

In the Catalyst Center GUI, click the menu icon and choose Policy > Group-Based Access Control > Policies > GBAC Configuration > Manage Group-Based Access Control in Cisco ISE.

In a multiple Catalyst Center environment, we recommend to run the same Catalyst Center software version across all Author and Reader Node clusters, except during the process of cluster upgrades. Upgrade all Reader Node clusters before upgrading the Author Node cluster to avoid feature disparity and feature incompatibility across software versions. Avoid the promotion of a Reader Node cluster to the Author Node role in the middle of an upgrade cycle. All Catalyst Center clusters should be upgraded and run the same software version before promoting a Reader Node cluster.

Note

The basic functionality of the Multiple Catalyst Center feature does not require the same software version in all the participating Author and Reader Node clusters. However, using mismatched code versions may result in a difference in fixes, capabilities, and features between the clusters. The same Catalyst Center software version is recommended across all Author and Reader Node clusters.

There are two options for deployment of multiple Catalyst Center.

• A new deployment of multiple Catalyst Center clusters that are not currently integrated with Cisco ISE.

• An existing Catalyst Center cluster that is integrated with Cisco ISE and new additional Catalyst Center clusters without Cisco ISE Integration.

The Author Node cluster does not know of Virtual Network (VN) usage on the Reader Node cluster. You must remove all references to a VN on all the Reader Node clusters before attempting to delete that VN on the Author Node cluster. If you delete a VN on the Author Node cluster, the VN is deleted on the Author node and on the Reader Node clusters which do not have references to it. But if one of the Reader Nodes is using that VN, the status of such a VN then displays as Out of sync with Author. You must remove all the references (for example, VN Addition in Host Onboarding Section or static port assignment) of the VN on the Reader Node cluster and then proceed to delete that VN on the Reader Node cluster.

The Author Node cluster is not aware of security group usage on a Reader Node cluster. You must remove all references to the security group on all the Reader Node clusters before attempting to delete that security group on the Author Node cluster. If you delete a security group on the Author Node cluster, that security group is deleted on the Author Node cluster, Cisco ISE, and on the Reader Node cluster if there are no references to it. If one of the Reader Node clusters is using that security group, the status of such a security group then displays as Out of sync with Author. You must remove all the references of the security group on the Reader Node cluster and then proceed to delete that security group on the Reader Node cluster.

The Multiple Catalyst Center solution architecture has multiple Catalyst Center clusters and only one cluster can be the policy Author. There may be instances where the Administrator needs to promote a Reader Node cluster to take over the role of the Author Node cluster. This promotion should only be done when:

• You are taking the Author Node cluster out of service or making it unavailable for an extended period of time.

• The Author Node cluster is permanently unavailable or unresponsive for an extended period of time and policy changes are required during that time.

This promotion of a Reader Node to an Author Node can be done in two ways:

1. Graceful Promotion of a Reader Node to the Author role.

2. Force Promotion of a Reader Node to the Author role.

Force promotion is a manual process designed specifically to promote the current Reader Node cluster to the Author Node role in the following situations:

• The current Author Node cluster is out of service.

• The current Author Node cluster is non-responsive.

• The graceful promotion of a Reader Node to the Author Role is taking more than five minutes.

Do not use the force promotion option while the existing Author Node cluster is in service with a GBP authoring activity, as this may result in data loss and the Author Node cluster going out of sync with Cisco ISE. Force promotion is only recommended if you must restore service immediately and you are willing to risk losing data. After the forced promotion, the promoted Reader Node cluster will become the new Author Node cluster for the deployment. When the former Author Node cluster becomes available, it will transition to a reader role and download the latest configuration data from Cisco ISE.

When you initiate the promotion of a Reader Node cluster, the Reader Node cluster initiates a request to Cisco ISE for a Role change (in other words, Reader to Author). When Cisco ISE receives the role change request, it requests the current Author Node to release the role of policy Author. If the current Author Node is unresponsive and if the administrator selects Force Promotion, the Reader Node cluster ACA initiates a request to force the change of the Reader Node cluster to the Author Role and vice versa immediately in Cisco ISE. This configuration update message is sent to all the nodes.

The steps to force promote a Reader Node cluster to Author Node cluster are exactly the same as explained in the graceful promotion of a Reader Node to the Author Role. There is an additional step at the end to initiate the Force Promotion function.