Cisco APIC Getting Started Guide, Release 6.2(x)

PDF

Contract the APIC cluster using the REST API

Updated: January 12, 2026

Overview

Use this procedure to shrink the cluster size by removing controllers, utilizing the new 'shrink' and 'force' properties in Cisco APIC Release 6.0(2) to automate the decommissioning process, ensuring a smooth transition to a smaller cluster configuration.

Use this procedure to shrink the cluster size by removing controllers. For more information about contracting the cluster size, see Cisco APIC cluster contractions .

Note
Beginning with Cisco APIC Release 6.0(2), two additional properties are added to the API command to allow forcing the decommission operation. The new object properties are:

  • infraClusterPol:shrink

    • false : (default) If the target cluster size ( infraClusterPol:size ) is less than the current operational cluster size, the APICs to be removed must be decommissioned manually, as in earlier releases.

    • true : If the target cluster size is less than the current operational cluster size, a cluster shrink decommission is triggered. The APICs to be removed are decommissioned automatically, beginning with the APIC with the highest controller ID number.

  • infraWiNode:force

    • false : (default) The decommission proceeds only if the cluster is not in an unhealthy or upgrade state, where a decommission may not be proper.

    • true : The decommission proceeds regardless of the cluster state.

This example shows how to contract the cluster from three APIC controllers to a single controller. To achieve a target size of one, APIC3 and APIC2 must be decommissioned, in that order.

Procedure

1.

Set the target cluster size so as to contract the APIC cluster size.

When the cluster size is reduced with shrink='true' , the APICs to be removed are decommissioned automatically. Otherwise, they must be decommissioned manually.

Example:

Cisco APIC Release 6.0(1) and earlier:

POST
						https://<IP address>/api/node/mo/uni/controller.xml
						<infraClusterPol name='default' size=1 />

You must now manually decommission the APICs to be removed, as shown in the next steps.

Example:

Cisco APIC Release 6.0(2) and later, using 'shrink' property:

POST
						https://<IP address>/api/node/mo/uni/controller.xml
						<infraClusterPol name='default' size=1 shrink='true' />

With shrink='true' , the following steps can be skipped. The APICs to be removed are decommissioned automatically. 

POST
						https://<IP address>/api/node/mo/uni/controller.xml
						<infraClusterPol name='default' size=1 shrink='false' />

With shrink='false' , you must now manually decommission the APICs to be removed, as shown in the next steps.

2.

Decommission APIC 3 on APIC 1 for cluster contraction.

Example:

Cisco APIC Release 6.0(1) and earlier:

POST
						https://<IP address>/api/node/mo/topology/pod-1/node-1/av.xml
						<infraWiNode id=3 adminSt='out-of-service'/>

The decommission proceeds only if the cluster is in a healthy state.

Example:

Cisco APIC Release 6.0(2) and later, using 'force' property:

POST
						https://<IP address>/api/node/mo/topology/pod-1/node-1/av.xml
						<infraWiNode id=3 adminSt='out-of-service' force='true' />

With force='true' , the decommission proceeds regardless of the cluster state.

3.

Decommission APIC 2 on APIC 1 for cluster contraction.

Example:

Cisco APIC Release 6.0(1) and earlier:

POST
						https://<IP address>/api/node/mo/topology/pod-1/node-1/av.xml
						<infraWiNode id=2 adminSt='out-of-service'/>

The decommission proceeds only if the cluster is in a healthy state.

Example:

Cisco APIC Release 6.0(2) and later, using 'force' property:

POST
						https://<IP address>/api/node/mo/topology/pod-1/node-1/av.xml
						<infraWiNode id=2 adminSt='out-of-service' force='false' />

With force='false' , the decommission proceeds only if the cluster is in a healthy state.

The operation cluster size shrinks only after the last appliance is decommissioned, and not after the administrative size is changed. Verify after each controller is decommissioned that the operational state of the controller is unregistered and that the controller is no longer in service in the cluster.

Note

If a decommissioned APIC controller is not promptly removed from the fabric, it might be rediscovered, which could cause problems. In that case, follow the instructions in Cluster size reductions to remove the controller.