Catalyst 9800 WLAN, Policy Profile and Policy Tag

The object chain

1. Create the WLAN profile

Set the PSK before enabling the PSK AKM. Use a unique 8-63 character ASCII key or a 64-character hexadecimal key; never deploy the sample text as a production secret.

2. Create and map the policy

3. Assign the policy tag to the AP

Replace the sample MAC with the AP's wired Ethernet MAC. A tag change can briefly make the AP disassociate and rejoin.

GUI workflow

1. Configuration → Tags & Profiles → WLANs: add NETEST-CORP, WLAN ID 10, WPA2/AES/PSK, then enable it.
2. Tags & Profiles → Policy: add NETEST-CORP-POLICY, enable it, select central switching and VLAN 30.
3. Tags & Profiles → Tags → Policy: map NETEST-CORP to NETEST-CORP-POLICY.
4. Wireless → Access Points → AP → Tags: select NETEST-POLICY-TAG and apply.

Exact labels can vary slightly by IOS XE release.

DHCP and end-to-end test

• Join NETEST-CORP and receive 10.30.30.x/24.
• Ping 10.30.30.1.
• Resolve a DNS name.
• Test internal and Internet access.
• Move between APs and verify roaming.

Design and Verification Tips

The policy object chain separates reusable wireless intent from the AP groups that consume it. Build names that explain purpose and location, such as a corporate WLAN profile, a branch policy profile and a branch policy tag. Clear names reduce mistakes when several similar objects appear in the controller.

Verify the chain from both directions. Confirm that the AP has the expected policy tag, inspect the tag mappings, and then test from a client. Check the VLAN, address assignment, default gateway and reachability. A green controller status alone does not prove that the client data path is correct.

Introduce changes with a pilot AP or test site. Wireless problems can be caused by a correct policy applied to the wrong location, so scope and assignment deserve the same attention as the WLAN settings.

Implementation Checklist

Before enabling a policy tag broadly, write down the expected result for an associated client: SSID, authentication method, VLAN, address range, gateway, DNS and permitted destinations. This gives the verification process a concrete target and makes a change review more useful than checking only that the object was accepted.

Keep a test tag separate from the production tag when possible. It allows the team to change a WLAN or policy mapping without affecting every AP. Once the client path is proven, promote the reviewed mapping in a controlled window and record which APs received it.