The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Use these use cases to learn about wireless network configuration.
For information about optimal network management using wireless automation, see Leveraging Cisco Catalyst Center Wireless Automation for Optimal Network Management.
These topics help you understand the wireless controller management use cases for wireless networks.
Catalyst Center provides flexibility and intelligence when managing SSIDs across complex site hierarchies. Catalyst Center dynamically selects the WLAN profile and policy profile names from either network settings or network profiles based on the design intent and the specific site context.
When an SSID is defined at the Global site without any overrides at the site hierarchy, the WLAN profile and policy profile names are based on the network profile for that site.
Catalyst Center automatically detects conflicts when the same SSID is associated with the same WLAN profile and policy profile names but
configured with different configuration flavors across multiple network profiles. For example, the SSID store_wifi with WLAN profile and policy profile name store_wifi_area1 is defined as Flex in the network profile attached to Site1 and non-Flex in the network profile attached to Site2. If Site1 and Site2 are managed by the same wireless controller, it is a conflicting configuration.
To resolve conflicts, update each network profile to have unique WLAN profile and policy profile names. For example, update
the network profile for Site2 with the WLAN profile and policy profile name as store_wifi_area1_site2.
When an SSID is overridden at child sites, Catalyst Center determines the WLAN profile and policy profile names based on either the network setting or network profile, based on these conditions:
|
Profile name selection |
Criteria |
|---|---|
|
From network settings |
|
|
From network profile |
Multiple network profiles exist, each with a unique WLAN profile and policy profile name. |
Catalyst Center automatically detects conflicts when the same SSID and WLAN profile or policy profile names are used with different configurations in two or more network profiles.
For example, a wireless controller manages a network with the SSID store_wifi and this hierarchy:
Area1
Site1 (store_wifi_area1)
Building-01
Floor1
Floor2
Site2 (store_wifi_area1)
Building-02
Floor1
Floor2
This table lists the conflict configuration examples and resolutions.
|
Example |
Resolution |
|---|---|
|
The WLAN profile or policy profile name is
The wireless controller detects a conflict as it manages both the sites. |
Update each network profile to use a unique WLAN or policy profile name (for example, |
|
The wireless controller manages only the buildings from the hierarchy using two network profiles, one for each floor.
Overrides are configured at two sites but with same WLAN profile and policy profile name Catalyst Center finds granular-level profile names at The wireless controller detects a conflict as the SSID is overridden at |
|
Catalyst Center automatically detects the migrated SSIDs when the wireless controller is reprovisioned without any intent change. Catalyst Center reuses the WLAN profile and policy profile name based on these conditions:
The site level override is same as before migration.
The WLAN profile or policy profile name is same as before migration in either the network profile or network settings.
These conditions are also applicable to non-migrated SSIDs which are created in Release 2.3.7.7 and reprovisioned with a WLAN profile or policy profile name change.
If you change the WLAN profile or policy profile name of an SSID at either the site hierarchy () or the network profile and then reprovision the wireless controller, Catalyst Center tries to reuse the provisioned WLAN profile or policy profile names for a site if the SSID is already provisioned to the wireless controller for the same site with a WLAN profile or policy profile name that matches either the WLAN profile or policy profile name defined in the network profile or network settings. Catalyst Center ignores the updated profile name and continues to use the existing profile name.
For example, a wireless controller manages a network with the SSID store_wifi created at the Global level using WLAN profile or policy profile name store_wifi_profile. The network hierarchy under Global is:
Area1
Site1
Building-01
Floor1
Floor2
Site2
Building-02
Floor1
Floor2
Example 1:
The network profile Network Profile-1 is assigned to all floors of Site1/Building-01 with the WLAN profile or policy profile name store_wifi_area1_np1.
The network profile Network Profile-2 is assigned to all floors of Site2/Building-02 with the WLAN profile or policy profile name store_wifi_area1_np2.
When you provision the wireless controller, the WLAN profile and policy profiles store_wifi_area1_np1 and store_wifi_area1_np2 are created on the wireless controller.
To use a new WLAN profile or policy profile name (for example, store_wifi_area1_np1_1) for the sites using Network Profile-1, you can update the profile name in Network Profile-1 and then reprovision the wireless controller. The new profile name is used. Similarly, if you change the profile name in Network Profile-2 to store_wifi_area1_np2_1 and reprovision the wireless controller, it uses the updated profile name.
Example 2: A single network profile Network Profile-1 with store_wifi_profile as the WLAN profile and policy profile names is used for all the floors.
When you provision the wireless controller managing all the floors, the WLAN profile and policy profile store_wifi_profile is applied to all the floors.
To update the WLAN profile or policy profile name used by the wireless controller, you must update the name in Network Profile-1 and the SSID configuration in global network settings to ensure that the new profile name is correctly applied.
This section helps you understand the Wi-Fi 7 configuration use case for wireless networks.
Use this procedure to enable the Wi-Fi 7 configuration on Catalyst Center.
Ensure that the Wi-Fi 7 APs are available in the window.
The Wi-Fi 7 APs include:
Cisco Wireless 9171I Series Access Points running Cisco IOS XE Release 17.18 or later,
Cisco Catalyst 9172H Series Access Points,
Cisco Catalyst 9172I Series Access Points,
Cisco Catalyst 9176D1 Series Access Points running Cisco IOS XE Release 17.17.1 or later,
Cisco Catalyst 9176I Series Access Points running Cisco IOS XE Release 17.17.1 or later, and
Cisco Catalyst 9178I Series Access Points.
The devices must be running Cisco IOS XE Release 17.15.2 or later.
Wi-Fi 7 APs use CNS licenses. If these APs don't meet the license requirements, they operate in worldwide safe mode (WWSM).
To disable WWSM and meet the license requirements, enable the CNS licenses in the License Manager window. For more information, see "Manage Licenses" in the Cisco Catalyst Center Administrator Guide.
|
Step 1 |
Enable the 802.11be status for the 2.4-GHz, 5-GHz, and 6-GHz radio bands in the Dot11be Status Configuration feature template. You can use the existing default profiles or create custom profiles for each radio band. For more information, see Create a feature template for Dot 11be status configuration. |
||
|
Step 2 |
Create an RF profile with the necessary settings and configure the required Wi-Fi 7 settings.
For more information, see Create a wireless radio frequency profile. |
||
|
Step 3 |
Create a 802.11be profile.
For more information, see Create an 802.11be profile. |
||
|
Step 4 |
In the associated wireless network profile,
|
||
|
Step 5 |
(Optional) In the corresponding SSID, check the AP Beacon Protection check box to enable AP beacon protection. For more information, see Create SSIDs for an enterprise wireless network and Create SSIDs for a guest wireless network. |
||
|
Step 6 |
Configure the Wi-Fi 7 APs. For more information, see Configure APs. |
||
|
Step 7 |
Provision the Wi-Fi 7 APs with the associated network profile. For more information, see Provision Cisco APs on day 1. |
These topics help you understand the high availability (HA) use cases for wireless networks.
Cisco Wireless Controller HA allows you to use a wireless controller as a backup for a primary wireless controller. The active wireless controller handles all the APs, client traffic, and shares the AP and client database with the standby wireless controller. If there is a failover, the standby wireless controller takes over immediately, resulting in zero client service downtime and zero SSID outage.
Ensure that both the wireless controllers are of the same form factors.
Ensure that both the wireless controllers are running the same software version.
Wireless controller HA supports a maximum redundancy port link latency of 80 ms round-trip time (RTT), minimum bandwidth of 60 Mbps, and minimum maximum transmission unit (MTU) of 1500.
Ensure that you connect the redundancy ports of both the wireless controllers physically or through a Layer 2 virtual network. If you connect redundancy ports through a Layer 2 virtual network, ensure that the link latency, bandwidth, and MTU requirements are met.
For the Cisco Catalyst 9800-CL Wireless Controllers running on ESXi, KVM, and Hyper-V, ensure that the redundancy port connects to the same vswitch.
|
Step 1 |
Ensure that you have the wireless controller in your inventory. For more information, see About Inventory and Add a network device. If the wireless controller isn’t available in the inventory, use the Discovery feature to discover it. For more information, see Discover Your Network. |
||
|
Step 2 |
Ensure that both the wireless controllers are in the Managed state in the inventory. For more information, see Display information about your inventory. |
||
|
Step 3 |
Use the show redundancy command to verify that the operating redundancy mode is Non-redundant on both the wireless controllers. |
||
|
Step 4 |
From the main menu, choose . |
||
|
Step 5 |
Check the check box next to the required wireless controller, and then click . |
||
|
Step 6 |
Enter the Redundancy Management IP and the Peer Redundancy Management IP addresses. You must configure the IP addresses used for redundancy management IP and peer redundancy management IP in the same subnet as the management interface of the wireless controller. Ensure that these IP addresses are unused IP addresses within that subnet range. |
||
|
Step 7 |
Enter the Netmask. |
||
|
Step 8 |
From the Select Secondary WLC drop-down list, choose the secondary wireless controller. |
||
|
Step 9 |
Since the Cisco Catalyst 9800-CL Wireless Controller doesn't have a dedicated redundancy port, choose the interface that will be used for the redundancy port.
|
||
|
Step 10 |
Click Configure HA. |
To verify the status of HA, use the show redundancy command. This is a sample output of the command:
To verify the Priority of the primary wireless controller, use the show chassis command. The Priority of the primary wireless controller is changed to 2 to ensure that its role is Active. This is a sample output of the command:
Cisco Wireless Controller N+1 HA allows you to use a wireless controller as a backup for multiple primary wireless controllers. Catalyst Center doesn't support stateful switchover for N+1 HA and each wireless controller must be managed separately.
 Note |
|
|
Step 1 |
Ensure that you have the wireless controller in your inventory. For more information, see About Inventory and Add a network device. If the wireless controller isn’t available in the inventory, use the Discovery feature to discover it. For more information, see Discover Your Network. |
|
Step 2 |
Ensure that both the wireless controllers are in the Managed state in the inventory. For more information, see Display information about your inventory. |
|
Step 3 |
Create enterprise and guest wireless SSIDs. For more information, see Create SSIDs for an enterprise wireless network and Create SSIDs for a guest wireless network. |
|
Step 4 |
If you created a wireless network profile during SSID creation, assign it to the primary wireless controller-managed site. From the main menu, choose , and then click the corresponding Assign Site option for the wireless network profile. |
|
Step 5 |
Provision the primary wireless controller. Choose the role as Active Main WLC. For more information, see Provision a Cisco AireOS Controller and Provision a Cisco Catalyst 9800 Series Wireless Controller. |
|
Step 6 |
Provision the secondary wireless controller. Choose the role as Active Main WLC and choose the secondary managed AP location same as the managed AP location for the primary wireless controller. For more information, see Provision a Cisco AireOS Controller and Provision a Cisco Catalyst 9800 Series Wireless Controller. |
|
Step 7 |
Provision the APs. For more information, see Provision Cisco APs on day 1. |
These topics help you understand the mobility configuration use cases for wireless networks.
Two newly added wireless controllers with the same mobility group: The two wireless controllers are newly added to Catalyst Center and are not yet provisioned.
Two existing wireless controllers with the same mobility group: The wireless controllers are already added and provisioned on Catalyst Center and have the same mobility group name.
Two existing wireless controllers with different mobility group: The wireless controllers are already added and provisioned on Catalyst Center and have different mobility group name.
Two existing wireless controllers with a third wireless controller: Adding a new wireless controller to an existing mobility group between two wireless controllers.
Ensure that you have the Cisco Wireless Controllers in your inventory and they are in Managed state. For more information, see About Inventory and Display information about your inventory.
For more information on wireless mobility configuration, see Mobility configuration overview.
|
Step 1 |
For newly added wireless controllers with the same mobility group, do these steps: |
|
Step 2 |
For two existing wireless controllers with same mobility group, do these steps: |
|
Step 3 |
For two existing wireless controllers with different mobility group, do these steps: |
|
Step 4 |
For adding a new wireless controller to an existing mobility group between two wireless controllers, do these steps: |
After provisioning, run the show wireless mobility summary command on each of the controllers to verify the mobility tunnel status. This is a sample output of the command:
Configuring two newly added wireless controllers - one anchor and one foreign wireless controller.
Configuring three newly added wireless controllers - one anchor and two foreign wireless controllers.
Configuring three newly added wireless controllers - one foreign and two anchor wireless controllers.
Deleting the anchor/foreign setup.
Ensure that you have the Cisco Wireless Controllers in your inventory and they are in Managed state. For more information, see About Inventory and Display information about your inventory.
Use the show wireless mobility summary command to verify that there’s no existing mobility tunnel between the wireless controllers.
|
Step 1 |
Create an SSID for the wireless network and associate it with a new wireless network profile. For more information, see Create SSIDs for an enterprise wireless network or Create SSIDs for a guest wireless network. In the Associate SSID to Profile step, choose the Add Profile option and complete this configuration:
|
|
Step 2 |
For a scenario with one anchor and one foreign wireless controller, do these steps: |
|
Step 3 |
For a scenario with one anchor and two foreign wireless controllers, do these steps: |
|
Step 4 |
For a scenario with one foreign and two anchor wireless controllers, do these steps: |
After provisioning, Catalyst Center automatically creates a mobility tunnel between the anchor and foreign wireless controllers. Use the show wireless mobility summary command on each of the controllers to verify the mobility tunnel status. This is a sample output of the command:
Verify these mobility configurations on the wireless controllers:
Both wireless controllers have the same WLAN and policy profile.
The policy tag is created on foreign wireless controller and mapped to the AP.
The VLAN interface is created for the anchor wireless controller and is mapped to the policy profile.
Delete the anchor/foreign setup
To delete the anchor and foreign setup, do these steps:
Ensure that the mobility tunnel between the anchor and foreign wireless controllers is in up state.
Delete the SSID that was created for the wireless network.
From the main menu, choose
Click the Wireless tab.
From the left hierarchy tree, choose Global.
In the SSID table, choose the SSID and click Delete.
Provision the foreign wireless controllers.
In the provision Summary window, ensure that the SSID details are removed.
After provisioning, Catalyst Center automatically deletes the mobility tunnel between the anchor and foreign wireless controllers and the WLAN and policy profile is deleted on all the wireless controllers.
These topics help you understand the AP management use cases for wireless networks.
You can do these tasks for APs in Catalyst Center:
Configure AP-level parameters and radio-level parameters for APs.
Schedule recurring events for APs.
Configure APs using existing templates.
For more information, see AP configurations in Catalyst Center.
You can replace old AP models with new AP models using Catalyst Center. You can replace both provisioned and unprovisioned old APs with new ones in Catalyst Center. For more information, see AP Refresh workflow.
When you provision a wireless controller for the first time, Catalyst Center also provisions the associated APs. When you reprovision the wireless controller, Catalyst Center detects if there are any changes to these AP intent configurations:
VLAN configurations: local VLAN, native VLAN, and AAA VLAN.
Tag configurations: policy tag, site tag, AP profile name, flex profile name, and site tag load count.
Failed AP wireless configuration parameters from the previous provisioning attempts.
If there are no changes to these AP intent configurations, Catalyst Center skips the provisioning of associated APs. If there are changes to the AP intent configurations, you can use the Skip AP Provision option to skip the AP provisioning during wireless controller reprovisioning. If you check the Skip AP Provision check box, Catalyst Center doesn't reprovision the existing APs and the APs managed by the wireless controller. However, the newly added APs are provisioned.
The selective AP group Resource Facing Service (RFS) translate feature optimizes wireless controller reprovisioning for AP-related configurations (such as AP tag mapping, RF tags, and flex or RF profiles) by translating only the AP intent that has changed. Out-of-band AP configurations are not automatically corrected during reprovisioning unless a compliance report explicitly flags them. To correct the AP-related out-of-band configurations to match your network intent, perform a wireless controller resynchronization and compliance run. For example, if you manually update the static tag mapping:
With resynchronization and compliance run, the manual change is corrected to match the intent configuration.
Without resynchronization and compliance run, the manual change is not corrected and only the new intent changes are applied.
To disable the selective AP group RFS translate feature, contact Cisco Technical Assistance Center (TAC).
Catalyst Center uses policy tags, site tags, and RF tags to push the wireless network configurations to individual APs through Cisco Catalyst 9800 Series Wireless Controllers.
For the first-time provisioning, Catalyst Center configures both the custom and Catalyst Center-generated site tags, policy tags, and RF tags only during the AP provisioning. For more information about the tag and flex profile configurations, see Overview of AP groups, flex groups, site tags, and policy tags.
This figure shows how Catalyst Center processes the tags.
For information about the tags on the wireless controller, see Understand Catalyst 9800 Wireless Controllers Configuration Model.
This table lists the tags and the associated tag information during the first-time provisioning of wireless controller and APs:
|
Tag |
Design window |
Wireless Controller provision (with the Skip AP Provision unchecked) |
AP provision |
||
|---|---|---|---|---|---|
|
Policy tag |
|
Autogenerated names for WLAN profile and policy profile are created. |
Policy tags with the required WLAN profiles are created. |
||
|
Site tag |
AP profile: Custom site tag and flex profile: |
For nonflex configurations, an AP profile mapped to the custom site tag is created.
|
For nonflex:
|
||
|
For flex configurations, intent configurations defined in the feature template with IP Overlap enabled and native VLAN configurations are created. |
For flex, a nondefault flex profile is created. |
||||
|
RF tag |
|
No change |
RF tag and RF profiles are created. |
This table lists the tags and the associated tag information during the wireless controller and AP reprovisioning when there are changes to the AP intent configurations:
|
Tag |
Design window |
Wireless Controller provision (with the Skip AP Provision unchecked) |
AP provision |
|---|---|---|---|
|
Policy tag |
|
|
|
|
Site tag |
AP profile: Custom site tag and flex profile: |
Updates to site tags are configured for the provisioned APs. |
Site tag, flex profile, and AP profile are created or configured. |
|
RF tag |
|
Updates to the RF profile are configured. |
RF tags are configured. |
Note |
If there are no provisioned APs on a floor, tags aren’t configured on the floor during the wireless controller reprovisioning. |
Catalyst Center supports automated tagging for flapping APs. When an AP flaps more than 10 times in 6 minutes, Catalyst Center assigns the AUTO_INV_EVENT_SYNC_DISABLED tag to the AP automatically. When the AP is assigned with this tag, any event on that AP is discarded. This tag prevents the unnecessary wireless controller synchronization to update the AP information for flapping APs.
If this AP doesn't flap for 10 minutes, Catalyst Center removes the AUTO_INV_EVENT_SYNC_DISABLED tag automatically.
You can view the logs for the tagging and untagging of APs on the Audit Logs window.
After the underlying cause of the AP flapping is resolved, we recommend that you perform a manual synchronization to immediately reflect the most current AP details. Alternatively, wait for the next scheduled synchronization to update the AP information.
Use this procedure to configure the Rest of World (ROW) domain APs.
|
Step 1 |
Create an AP profile with the necessary country code and configure custom site tags. For more information, see Configure additional settings for an AP profile for Cisco IOS XE devices and Add AP groups, flex groups, site tags, and policy tags to a network profile.
|
||
|
Step 2 |
Add support for the country of operation to the country list on the wireless controller. You must configure at least one site from the country of operation as the managed AP location for the wireless controller. For more information, see Provision a Cisco Catalyst 9800 Series Wireless Controller. |
||
|
Step 3 |
If the wireless controller is not already provisioned with the configurations in Step 1 and Step 2, provision the wireless controller. For more information, see Provision a Cisco Catalyst 9800 Series Wireless Controller. |
||
|
Step 4 |
Configure the AP parameters. For more information, see Configure APs. |
||
|
Step 5 |
Provision the AP. For more information, see Provision Cisco APs on day 1.
|
To verify the AP configuration, use the show ap summary command. This is a sample output of the command.
This command displays the country code (CC) and regulatory domain (RD) for the APs. For ROW APs, the regulatory domain is -RW.
Note |
For a ROW AP, if the country code in the command output is --, it indicates that the country code is not available for the AP. The operational status of all the radios for the ROW APs without a country code is down. You must provision the ROW AP to configure the country code for the ROW AP. |
In a Cisco wireless mesh network architecture, APs operate in one of these ways:
Root APs (RAP): Connected to the wired network.
Mesh APs (MAP): Communicates with other MAPs and RAPs using wireless connections.
The workflow for configuring a wireless mesh network involves these main steps:
Wireless controller provisioning: Configure a mesh profile, configure the AP authorization list and provision the wireless controller.
AP configuration: Configure AP in bridge mode and deploy.
AP provisioning: Configure the mesh role for AP (RAP or MAP) and provision the AP.
All APs are configured and shipped as MAPs. To use the AP as a RAP, you must reconfigure it as a RAP during AP provisioning. A mesh network must contain at least one RAP. For more information on Cisco Wireless Controller configuration and AP configuration for wireless mesh networks, see About wireless mesh networks.
|
Step 1 |
In the Catalyst Center device inventory (), ensure that the wireless controllers and APs are in managed state and assigned to the respective sites. |
|
Step 2 |
Create an AP profile with mesh settings. For more information, see Configure mesh settings for an AP profile for Cisco IOS XE devices and Configure mesh settings for an AP profile for Cisco AireOS devices. |
|
Step 3 |
Add the AP Ethernet MAC address to the AP authorization list. For more information, see Create an AP authorization list. |
|
Step 4 |
Provision the Cisco Wireless Controller. For more information, see Provision a Cisco Catalyst 9800 Series Wireless Controller and Provision a Cisco AireOS Controller. In the provision configuration window, select the AP Authorization List defined in Step 3 and choose the option for authorizing only the mesh access points. |
|
Step 5 |
(Optional) In the Configure Access Points workflow, select the APs and change the AP mode to Bridge/Flex+Bridge mode if they are in Local/Flexconnect mode. For more information, see Configure APs. |
|
Step 6 |
Provision the APs. For more information, see Provision Cisco APs on day 1.
|
AP Ethernet MAC address: show run | inc username.
AP mesh role (MAP/RAP) after provisioning: show wireless mesh ap summary.
Site tag details: show wireless tag site detailed <site tag name>.
AP profile: show run | section ap profile.
Wireless mesh configurations:
show wireless profile mesh summary
show wireless profile mesh detailed <mesh profile name>
You can migrate APs from one wireless controller to another wireless controller with the same floors in the network hierarchy. For more information, see Migrate APs from a Wireless Controller to another Wireless Controller.
You can replace a faulty access point in the network using the Catalyst Center Return Material Authorization (RMA) feature. The RMA workflow lets you replace failed devices quickly, thus improving productivity and reducing operational expense. For wireless APs, the replacement device is assigned to the same site, provisioned with primary wireless controller, RF profile, and AP group settings, and placed on the same floor map location in Catalyst Center as the failed AP.
For more information, see Replace a faulty access point.
Use this procedure to onboard and provision APs using Plug and Play (PnP) for deployments that:
do not use intent-based configurations and
are not provisioned with a network profile from Catalyst Center
The non-intent-based configurations include the Assurance use case and Per-Device Configurations.
Ensure that the Cisco Catalyst 9800 Series Wireless Controller is added to the inventory.
Configure the DHCP server with Option 43 for PnP. This option informs the network device of the IP address of the Catalyst Center controller.
Ensure that the APs are in the factory reset state.
Ensure the network connectivity between APs, Catalyst Center, and wireless controller.
|
Step 1 |
Create a regular day-zero template for onboarding APs using PnP. |
|
Step 2 |
Claim the APs using PnP.
For more information, refer to Provision a wireless controller. |
After PnP claim, the configuration is pushed to AP and it joins the corresponding wireless controller. The AP appears in the inventory.
In the AP console, use the show pnp log to verify the PnP claim. A sample output of the command is:
#show pnp log
722 - pnp.agent - DEBUG - Setting sid from stored value 551de96a-c719-44f0-8964-16b150f7325d
APC414.A2FB.0CB0#
PNP CONFIG - HOST NAME : APC414.A2FB.0CB0
PNP CONFIG - PRI WLC IP : 10.0.0.1
PNP CONFIG - SEC WLC IP : 10.0.0.5
PNP CONFIG - PRI WLC NAME: Primary-WLC
PNP CONFIG - SEC WLC NAME: Secondary-WLC
PNP CONFIG - Policy Tag : default-policy-tag
PNP CONFIG - Site Tag : default-site-tag
PNP CONFIG - RF Tag : default-rf-tag
PnP: Config Upgrade received. Start CAPWAP discoveryCatalyst Center can learn configurations from an existing Cisco Catalyst 9800 Series Wireless Controller and save the configurations as configuration profiles. Configuration profiles can be learned from wireless controllers that are provisioned using either Per-Device Configurations, provisioned using intent-based network configurations, or available in the inventory without being provisioned. You can provision multiple wireless controllers using configuration profiles, ensuring consistent settings and standardized deployment.
Note |
This feature is in beta and requires feature enablement. To enable the feature, contact Cisco TAC. If this feature is not enabled, the options for wireless controller-related configurations are unavailable or dimmed. |
Configuration profiles are version-specific. The profiles learned from a wireless controller running a specific Cisco IOS XE Release can be applied only to wireless controllers running the same version. Configuration profiles are not associated with site or network and can be used across different networks.
For more information about campus networks, refer to Provision Campus Networks.
Wireless controllers must be running Cisco IOS XE Release 17.12 or later.
Per-Device Configurations must be enabled on the wireless controllers included in the campus network. For more information, refer to Enable Per-Device Configuration for a Cisco Catalyst 9800 Series Wireless Controller.
Wireless controllers and APs must be added to inventory and assigned to the required sites.
Ensure uniform initial configuration for all wireless controllers in your network by copying device configurations from an existing wireless controller and standardizing the setup.
Refer to Campus networks configuration use cases for Cisco Catalyst 9800 Series Wireless Controllers.
Use this procedure to copy the configurations from a wireless controller and apply them to all other wireless controllers in your network to ensure uniform day-zero configurations.
|
Step 1 |
Create a network and add the wireless controllers that need to be included in the network. For information about creating a network with wireless controllers, refer to Create a network. |
|
Step 2 |
Learn configuration profiles from an existing wireless controller. For more information, refer to Learn configuration profiles from a wireless controller. |
|
Step 3 |
Standardize the configuration for wireless controllers in the network. |
|
Step 4 |
Verify that the configuration is pushed to the wireless controllers.
|
|
Step 5 |
Configure the tags (site tag, policy tag, and RF tag) for APs associated with the wireless controllers using Per-Device Configurations. For more information, refer to Manage APs associated with a Cisco Catalyst 9800 Series Wireless Controller. |
Apply and customize partial configuration profiles for wireless controllers, ensuring only required configurations are provisioned during initial deployment.
Use this procedure to customize configuration profiles learned from existing wireless controllers. For example, if a learned profile includes ten SSIDs but only two are needed for a site, modify the profile to match site requirements.
Refer to Campus networks configuration use cases for Cisco Catalyst 9800 Series Wireless Controllers.
|
Step 1 |
Create a network and add the wireless controllers that need to be included in the network. For information about creating a network with wireless controllers, refer to Create a network. |
|
Step 2 |
Learn configuration profiles from an existing wireless controller. For more information, refer to Learn configuration profiles from a wireless controller. |
|
Step 3 |
Standardize the partial configuration for the required wireless controllers in the network. |
|
Step 4 |
Verify that the configuration is pushed to the wireless controllers.
|
Maintain, update, or remove configurations for wireless controllers by updating configuration profiles.
Use this procedure to add, edit, or delete a setting in a configuration profile for a wireless controller on day n. For example, use this procedure to create an SSID for Wi-Fi 7 clients.
|
Step 1 |
Manage your configurations in the configuration profile. |
|
Step 2 |
Verify that the configuration is pushed to the wireless controllers.
|
Feedback