When I first started researching how to configure the 9800, I was completely lost. Coming from a “Wi-Fi standard deployment” of AireOS controllers where all the buildings on a controller were configured with AP Groups, none of what I was reading or watching made any sense. I needed to understand how to architect and design the controller configuration first. The problem is I didn’t understand how to configure the controller, therefore I could not design a configuration for it. Enterprise deployments are usually designed and configured to company standards that are adhered to across the organization. Standard naming conventions of buildings using city/campus/building/floor/closets for access points, city/campus for controllers and switches needed to be translated from the old AP Groups configurations to the new AP tags that I knew absolutely nothing about.
Everyone told me about the Cisco Config converter, and then the next sentence was, “but don’t use it”. In order to learn how to configure a 9800, I did exactly what everyone told me. I used the converter to migrate a standard controller configuration, then reverse engineered it piece by piece. While reverse engineering the converted configuration, I discovered the conversion tool put a LOT of extra lines of code into the configuration. I found it useful that I also watched Youtube videos and Chris Avants’ online 9800 classes.
I spent about two months learning the config, reverse-engineering it from the top down, then realized I should have started at the bottom. I found that architecting the configuration from the tag level (bottom) up toward the top of the configuration helped me understand how to build it.
During those two months, I had other projects, meetings, etc, but my focus was to learn this controller platform. Some of the things I had to figure out: how to configure SSO, what to do with former AP Groups, how to convert WLAN profiles, and more importantly, why I could not see the SSID being broadcasted?
One of the things I wish I could have grasped early on is quite simple. Former “global settings” are now configurable down to the AP level, and the tags have profiles in them that are customizable so that the configuration scales quite easily across an entire campus and each building/floor/AP might have a configuration tailored to it.
An AP needs three tags in order to function. An RF tag, a Site tag, and a Policy tag. These tags contain a lot of information that used to be in many of the global settings on the AirOS controllers. We need to understand what is in tags – I like to think of it as each tag may have two or three buckets of settings.
Think of it another way. An AP is a plate. It can act as a dinner plate, a lunch plate, or a breakfast plate. You “tag” your plate with eggs, oatmeal and pineapple, making it a breakfast plate. Tag it with steak, a potato and roll, and it is now a dinner plate. But if nothing gets tagged on your plate, it’s just an empty plate – translation: no SSIDs being broadcast.
An RF tag has exactly that. Two “Profiles” or buckets containing information on how this AP is going to act from an RF perspective. In this case, it has a 2.4 GHz Profile and a 5 GHz profile. Here is the CLI to create our RF Tag for our site code atl001:
wireless tag rf atl001_RF_Tag ß This creates the tag that will be associated to the AP
24ghz-rf-policy atl001_24GHz_RF_Profile
5ghz-rf-policy atl001_5GHz_RF_Profile
What if there are ten buildings on campus, and each has its own RF requirement? We can create ten 2.4 GHz profiles, and 5 GHz profiles for ultimate flexibility. Yes, that seems like a lot of work, but if you’re using the CLI, it really isn’t. Simply create the first building’s RF Profiles for both frequencies, then copy/edit/paste and create the other nine. For instance:
ap dot11 24ghz rf-profile atl001_24GHz_RF_Profile ß name of the actual 2.4 GHz RF Profile.
channel add 1
channel add 6
channel add 11
description atl001_24GHz_RF_Profile
rate RATE_11M disable
rate RATE_12M mandatory
rate RATE_1M disable
rate RATE_24M mandatory
rate RATE_2M disable
rate RATE_5_5M disable
rate RATE_6M disable
rate RATE_9M disable
trap threshold clients 20
trap threshold utilization 60
tx-power max 20
tx-power min 1
tx-power v1 threshold -67
no shutdown
In this example, atl001 is a building’s site code. Simply open up notepad, copy/paste and change atl001 to the next building atl002 and paste it into the config. Do that eight more times and then there are ten RF Profiles that can be modified in the future so that each building can have its own customized RF settings. There might be a library, a football stadium, hospital, warehouse, office space, etc, and they might each have their own requirements. It’s the easiest thing to do when setting up the controller so that in the future, the RF tags can be modified to meet new requirements. The best part is that the AP names will likely have that building site code atl001 in it, so it will be obvious how to assign the tags if they are being done manually.
The next thing we need are Site Tags. Since we have determined we have ten buildings on campus, we will need ten site tags. Site tags can have two buckets in it – an AP Join Profile and a Flex Profile, for FlexConnect APs. This is a campus controller, so the latter is not needed since the APs are all in local mode.
The campus APs might be able to be tagged by a single AP Join profile. Since there are ten buildings, the most you would have would be ten ap profiles. Let’s see what’s in an AP Profile:
ap profile atl001_AP_Profile
capwap timers fast-heartbeat-timeout 1
capwap timers primary-discovery-timeout 30
description atl001_AP_Profile
mgmtuser username alincoln password 8 f^JaaGS_OI[LO^S2D^L=NLS_DIIaTfOAAB secret 8 YCdW^[EN\JHHTQWgMLHOJMJBaZGfAAB
preferred-mode ipv4
ssh
syslog host 10.155.60.148
There is the possibility that someday the timers may need to be tweaked for a specific building. If we create one AP join profile, we won’t be able to do that unless we create more join profiles and site tags and then re-tag the APs. That said, if we created them now, it’s easy to do, and its standardized so future modifications will be made to individual profiles.
Here we create the Site Tag, and we will associate the AP Join profile into it.
wireless tag site atl001_Site_Tag
ap-profile atl001_AP_Profile
description atl001_Site_Tag
Simply copy/edit/paste, changing the site code (building code) and we can simply create all of the profiles and tags from the start so the configs can be modified in an orderly fashion in the future.
The last set of tags are called Policy Tags. There are two buckets in the Policy Tag, one is for the SSID, and the other for the SSID’s Policy Profile. I’m not a fan of the wording, and maybe it’s because I haven’t been working enough with the 9800 to understand the naming convention. I would have preferred “SSID Advanced Settings”, or something else.
Just like in the previous examples, we will create a Policy Tag for each site on the campus for future flexibility. Like the others, we will create the first one via CLI, then copy/paste and simply edit the site name to create the other buildings on this campus controller.
The Policy Tag’s name indicates which building it is on campus, which matches the description field. In this tag, it ties each SSID to be broadcasted, and the Policy Profile for that WLAN/SSID together. This is a campus controller – specifically meaning that it is not in a data center where it might have 3,000 big box retail stores on it, each with 15-20 APs and each store having local DHCP servers, VLANs, etc. In that case, each SSID would likely have a Policy Profile for each building – since that is where VLANs are specified, and other configurations that might be for that site’s address. Note how the contents of the tag call out the SSID and the “mapping” to the SSID’s Policy Profile, which could possibly have different settings if this were not a controller on a campus. The point I am trying make is that you might think both the WLAN and the Policy Profile could have been in the same WLAN config, since that is how it was in the AirOS controller. However that is not flexible enough if this controller was going to be deployed in a data center with 3500 big box stores – therefore this is separated into two different configurations and tied together with the Policy Tag. Clear as mud?
wireless tag policy atl001_Policy_Tag
description atl001_Policy_Tag
wlan Contractor policy Contractor_Pol_Prof
wlan Telemetry policy Telemetry_Pol_Prof
wlan Voice policy Voice_Pol_Prof
wlan BYOD policy BYOD_Pol_Prof
wlan GuestWiFi policy GuestWiFi_Pol_Prof
wlan Wireless policy Wireless_Pol_Prof
Here’s a sample of a WLAN config and a Profile Policy config:
wlan Wireless 1 Wireless
assisted-roaming prediction
band-select
no chd
no dot11ax
no dot11ax downlink-mumimo
no dot11ax downlink-ofdma
no dot11ax uplink-mumimo
no dot11ax uplink-ofdma
dtim dot11 24ghz 2
dtim dot11 5ghz 2
radio policy dot11 24ghz
radio policy dot11 5ghz
security dot1x authentication-list Wireless_Auth
no shutdown
wireless profile policy Wireless_Pol_Prof
aaa-override
accounting-list Wireless_Acct
description "Policy profile for Wireless"
dhcp-tlv-caching
no exclusionlist
http-tlv-caching
idle-timeout 3600
ipv4 flow monitor wireless-avc-basic input
ipv4 flow monitor wireless-avc-basic output
ipv6 flow monitor wireless-avc-basic-ipv6 input
ipv6 flow monitor wireless-avc-basic-ipv6 output
multicast vlan 34
service-policy input silver-up
service-policy output silver
session-timeout 86400
vlan Wireless_Group
no shutdown
The folks at Cisco obviously have their act together and figured out that there needs to be a WLAN Profile and a Policy Profile. Notice how the policy profile has the VLAN the WLAN is mapped to (or group), the multicast vlan, AAA override, etc. That’s where the flexibility comes in – the policy profile allows the AP to map client devices to different VLANs on campus, creating flexibility and scalability.
