Replacing a Cluster Root Switch with no Backup Switch
If you replace a cluster root switch that does not have a backup switch, the new cluster root switch creates its
own self-signed certificate. You then need to reboot each switch in the hierarchy in a specific order to certify all
APs with that new certificate:
1. Remove the old cluster root from the network.
2. Install and configure the new cluster root.
3. Connect the new cluster root to the network so it can access cluster masters and local switches.
4. If necessary, reconfigure the cluster masters and local switches with their new cluster root IP and master IP
addresses.
5. Reboot every cluster member switch. The cluster member begins using a new certificate signed by the
cluster root.
6. Reboot every local switch. Each local switch begins using a new certificate signed by the cluster member.
7. Because the cluster root is new, it does not have a configured campus AP whitelist. Access the campus AP
whitelist on any local switch or cluster master, and change all APs in a “certified” state to an “approved”
state. The APs get re-certified, reboot, and create new IPsec tunnels to their switch using the new certificate
key.
If a cluster root switch does not have any cluster master or local switches, you must recreate the campus AP
whitelist on the cluster root by turning on automatic certificate provisioning or manually reentering the
campus AP whitelist entries.
Replacing a Redundant Cluster Root Switch
Best practices is to use a backup switch with your cluster root switch. If your cluster root has a backup switch,
you can replace the backup cluster root without having to reboot all cluster master and local switches,
minimizing network disruptions.
The control plane security feature requires you to synchronize databases from the primary switch to the
backup switch at least once after the network is up at running. This ensures that all certificates, keys, and
whitelist entries are synchronized to the backup switch. Because the AP whitelist may change periodically, you
should regularly synchronize these settings to the backup switch. For details, see Configuring Networks with a
Backup Master Switch on page 72.
When you install a new backup cluster root, you must add it as a lower priority switch than the existing primary
switch. After you install the backup cluster root on the network, resynchronize the database from the existing
primary switch to the new backup switch to ensure that all certificates, keys, and whitelist entries required for
control plane security are added to the new backup switch configuration. If you want the new switch to act as
the primary switch, you can increase that switch’s priority after the settings have been resynchronized.
Configuring Control Plane Security after Upgrading
When you initially deploy a switch running AOS-W 6.0 or later, create your initial control plane security
configuration using the initial setup wizard. However, if you are upgrading to AOS-W 6.0 from AOS-W 3.4.x or
earlier releases, or if you are upgrading from AOS-W 5.0 but did not yet have control plane security enabled
before the upgrade, then you can use the strategies described in Table 24 to enable and configure control plane
security feature.
If you upgrade a switch running AOS-W 5.0.x to AOS-W 6.0 or later, then the switch’s control plane security settings
do not change after the upgrade. If control plane security was already enabled, then it remains enabled after the
upgrade. If it was not enabled previously, but you want to use the feature after upgrading, then you must manually
enable it.
AOS-W 6.5.3.x | User Guide Control Plane Security | 76
To Next Page
Loading...