You can assign tags from the following sources. The sources are listed in the order of priority.

• Static: You select an AP and assign tags. This configuration is saved on the controller based on the AP’s Ethernet MAC address. When an AP joins the specific controller, it is always assigned the specified tags.

• Location: This is a configuration construct internal to the Cisco Catalyst 9800 Series Wireless Controller (It is not the AP location that you can configure on each AP.), and is used primarily in the basic setup flow. A location allows you to create a group of three tags (policy, site, and RF) and assign APs to it.

• Filter: You can use a regular expression to assign tags to APs as they join the controller. You can set a filter based only on the AP name, so that this method cannot be used for out-of-the-box APs.

• AP: The AP itself carries the tag information learned through Plug-and-Play (PnP) or pushed from the controller.

• Default: This is the default tag source.

The first two methods of assigning tags (static and location) are static mapping configurations, and hence have the highest priorities. Filter allow you to define a dynamic mapping of APs-to-tags based on regular expressions. When the source is an AP, it means that this information is saved on the AP itself and will be presented to the controller when the AP joins it. If there is no tag mapping configuration on the Cisco Catalyst 9800 Series Wireless Controller, and if APs do not carry any tag information, these APs are assigned default tags.

Access Points are tagged based on the broadcast domain, the site it belongs to, and the desired RF characteristics. Once tagged, the AP gets a list of WLANs to be broadcast along with the properties of the respective SSIDs, properties of the APs on the local or remote site, and the RF properties of the network. By default, an AP is tagged with the default policy, site, and RF tag unless changed. When a tag associated with an AP is changed, the AP resets its CAPWAP connection.

APs are identified by the Ethernet MAC address, and the association to AP and tag is stored in the controller configuration.

Each AP is assigned three unique tags: a policy, site, and RF tag. By default, when an AP joins the controller, it gets default tags; the default policy tag, default site tag, and default RF tag. You can change to the default tags or create custom tags. Use the WebUI to view the tags configured on each AP.

The following conditions must be met when moving APs between controllers:

• If the AP does not have any tag information and there is no mapping configured for that AP on the controller to be joined, the AP is assigned default tags when moved to the controller.

• The AP retains the tag information when moving between the controllers, if both the controllers have the same mapping of AP to the tags. This can be done through static configuration, by assigning the AP to a location, or through filters.

• The AP retains its tag when moved between the two controllers if the tags are saved to the AP and the tags are defined on both controllers.

• If the AP has a saved tag assigned and joins a controller where these tags are not present, the AP is assigned default tags (assuming that no other mapping is configured on the controller that the AP is joining).

• If the AP retains its tag name assignment, but the settings within the tag are different on the two controllers, the AP is configured based on the settings present on the currently joined controller.

Note	The above information also applies to N+1 redundancy.

Modifying an AP tag results in the DTLS connection being reset, forcing the AP to rejoin the controller. If only one tag is specified in the configuration, default tags are used for other types. For example, if only policy tag is specified, the default site tag, and default RF tag are used for the site and RF tags.

Policy tags are used to verify the SSID that is being broadcast by an AP, and the type of policy, so that policy tags define the broadcast domain for a group of APs.

Roaming across two different policy tags (the same SSID, but different policy profile name) or intra-controller roaming will force a client to go through the full authentication and DHCP process to renew its IP address. The process is to prevent clients from jumping from one policy to another without a full reauthentication.

Note	If a policy profile associated to an SSID is the same (same name and content) in different policy tags, then roaming for that SSID is seamless. The slow roam happens if there is a change in the policy profile associated to the SSID.

RF Profiles allows you to group set of APs that share a common coverage zone together and selectively change how RRM operates the APs within that coverage zone. For example, a university might deploy a high density of APs in an area where a high number of users congregate or meet. This situation requires that you manipulate both data rates and power to address the cell density while managing the co-channel interference. In adjacent areas, normal coverage is provided and such manipulation would result in a loss of coverage.

Using RF profiles and RF tags allows you to optimize the RF settings for set of APs that operate in different environments or coverage zones. RF profiles are created for the IEEE 802.11 radios and are applied to all APs that are mapped to an RF tag, where all APs with that RF tag have the same profile settings.

AP filters are similar to the ACLs used in the controller, and are applied at the global level. You can add AP names as filters, and other attributes can be added as required. You can also add the filter criteria as part of the discovery requests.

The AP Filter feature organizes tag sources with the right priority, based on the configuration.

You cannot disable the AP filter feature. However, the relative priority of a tag source can be configured using ap filter-priority priority filter-name command.

Note	You can configure tag names at the Plug-n-Play (PnP) server (similar to the Flex group and AP group), and the AP stores and send the tag name as part of the discovery and join requests.