Ongoing Wireless (mainly) Blog from our Chief Consulting Engineer, Mike Dongvillo.

Blog Entry #9 - 3/29/2021 - Cisco Catalyst IOS-XE - Configuration/Deployment Summary


In the 7th and final (for now) post of this IOS-XE series, I'm going to discuss some deployment pointers and tips.


It's very important, as with any Project, to organize your data and configurations into something repeatable.
I've often found that using a simple 5-tab spreadsheet to organize the various WLAN parameters makes the deployment MUCH more logical.


For example:

   1. Building Wireless Info
   2. Policy Tags
   3. Site Tags
   4. RF Tags
   5. RLAN Info.


By organizing your necessary configuration parameters this way, you can keep track of all the components/objects you are working with.

Another note, I purposely showed all the CLI configuration here in this series of Blog posts, as that was the request. :)
Once you have the overall Tag, Policy, and Profile templates created, you can then programmatically roll out sites very quickly.
Depending on the platform, you can also utilize RESTCONF and NETCONF when deploying sites. Along with the simple copy/replace/paste methodology as well.

In summary, the main building blocks of a Cisco IOS-XE WLAN Controller are as such:


   1. Policy Tags
    A. WLAN Profile
    B. Policy Profile


   2. Site Tags
    A. AP Join Profile
    B. Flex Profile


   3. RF Tags
    A. 2.4G RF Profile
    B. 5G RF Profile


   4. RLAN Information
    A. RLAN Profile
    B. RLAN Policy

Blog Entry #8 - 3/2/2021 - Cisco Catalyst IOS-XE - Remote LANs (RLANs)


In the 6th post of this IOS-XE series, I'm going to layout the various RLAN configurations utilized in this install.

A Remote LAN (RLAN) is used for authenticating wired clients using the WLC, through the physical wires ports on the AP. Once the wired client successfully joins the controller,
the LAN ports switch the traffic between central or local switching modes. The traffic from wired client is treated as wireless client traffic.

The RLAN configured for the Access Point (AP) sends the authentication requests to authenticate the wired client.
The authentication of the wired clients in an RLAN is similar to the central authenticated wireless client process.

The RLAN Profile (RPRO) and RLAN Policy (RPOL) are then assigned to a Policy Tag (PT), similarly to how WLANs are assigned in the same way overall.
As shown below, the RLAN Policy configures the switching and security parameters for wired connections, such as:

   1. AAA Override
   2. Central or Local Switching
   3. Host-Modes, such as Multiple Hosts allowed, Single Host allowed, and which hosts are auth'd
   4. ACLs can be applied here
   5. PoE Settings and paremeters
   6. MAC Address violation responses
   7. VLAN assignment for the Wired port traffic



ap remote-lan profile-name UNIV-RLAN22-RPRO 22
   no shutdown



ap remote-lan profile-name UNIV-RLAN52-RPRO 52
   no shutdown



ap remote-lan-policy policy-name UNIV-RLAN22-RPOL
   aaa-override
   no central switching
   description UNIV-RLAN22-RPOL
   host-mode multihost
   poe
   violation-mode replace
   vlan 22
   no shutdown



ap remote-lan-policy policy-name UNIV-RLAN52-RPOL
   aaa-override
   no central switching
   description UNIV-RLAN52-RPOL
   host-mode multihost
   poe
   violation-mode replace
   vlan 52
   no shutdown



wireless tag policy UNIV-BLDGA-PT
   description UNIV-BLDGA-PT
   remote-lan UNIV-RLAN22-RPRO policy UNIV-RLAN22-RPOL port-id 1
   remote-lan UNIV-RLAN22-RPRO policy UNIV-RLAN22-RPOL port-id 2
   remote-lan UNIV-RLAN22-RPRO policy UNIV-RLAN22-RPOL port-id 3
   wlan UNIV_Guest policy UNIV-GUEST-PP
   wlan UNIV_Students policy UNIV-STUDENTS-PP
   wlan UNIV_Staff policy UNIV-STAFF-PP



wireless tag policy UNIV-BLDGB-PT
   description UNIV-BLDGB-PT
   remote-lan UNIV-RLAN52-RPRO policy UNIV-RLAN52-RPOL port-id 1
   remote-lan UNIV-RLAN52-RPRO policy UNIV-RLAN52-RPOL port-id 2
   remote-lan UNIV-RLAN52-RPRO policy UNIV-RLAN52-RPOL port-id 3
   wlan UNIV_Guest policy UNIV-GUEST-PP
   wlan UNIV_Students policy UNIV-STUDENTS-PP
   wlan UNIV_Staff policy UNIV-STAFF-PP

Blog Entry #7 - 2/16/2021 - Cisco Catalyst IOS-XE - Radio Frequency Tags (RFT)



In the 5th post regarding Cisco IOS-XE Catalyst controller deployment, I'm going to layout the various RF Tag (RFT) configurations.

The RF Tag contains the 2.4G and 5G RF Profiles. The default RF Tag contains the global configuration.
The RF Tag is a very convenient and flexible way to build your RF environment to your liking.

RF profiles contain the common radio configuration for the APs, such as Enabled/Disable/Mandatory speeds, RX-SOP thresholds and values, Tx Power settings.
RF profiles are applied to all the APs that belong to an AP group, where all the APs in that group have the same profile settings.




wireless tag rf UNIV-100-CORE-RFT
   24ghz-rf-policy UNIV-24G-HCD-RFP
   5ghz-rf-policy UNIV-5G-HCD-RFP
   description UNIV-100-CORE-RFT



wireless tag rf UNIV-101-AGG-RFT
   24ghz-rf-policy UNIV-24G-HCD-RFP
   5ghz-rf-policy UNIV-5G-HCD-RFP
   description UNIV-101-AGG-RFT



ap dot11 24ghz rf-profile UNIV-24G-HCD-RFP
   description "UNIV High Client Density RF Profile for 2.4G"
   high-density rx-sop threshold medium
   rate RATE_11M disable
   rate RATE_12M mandatory
   rate RATE_1M disable
   rate RATE_2M disable
   rate RATE_5_5M disable
   rate RATE_6M disable
   tx-power min 7
   no shutdown



ap dot11 5ghz rf-profile UNIV-5G-HCD-RFP
   description "UNIV High Client Density RF Profile for 5G"
   high-density rx-sop threshold medium
   rate RATE_6M disable
   rate RATE_9M disable
   tx-power min 7
   tx-power v1 threshold -65
   no shutdown

Blog Entry #6 - 2/10/2021 - Cisco Catalyst IOS-XE - Site Tags (ST)



In the 4th post regarding Cisco IOS-XE Catalyst controller deployment, I'm going to layout the various Site Tag (ST) configurations.

The Site Tag (ST) defines the properties of a site and also contains the Flex Profile (FP) and the AP Join Profile (APJP).
The configuration parameters that are specific to the corresponding Flex or Remote Site are part of the FP.

The ST also contains parameters that are specific to the physical site or location (and thus cannot be a part of the profile that is a reusable entity or object).
For example, the list of Primary APs and Secondary APs for upgrade processes is a part of the ST rather than of a FP.

If or when a FP name or an APJP name is changed in the ST, the AP is forced to rejoin the WLC by disconnecting the DTLS session.
The Site Tag is very important when designing redundancy and load-sharing, as the APJP component of the ST can be used to distribute APs amongst Primary and Secondary/Backup Controllers.

This is shown below, with the APJP-ODD and APJP-EVEN AP Profiles.



wireless tag site UNIV-100-CORE-ST
   ap-profile UNIV-APJP-EVEN
   description UNIV-100-CORE-ST
   flex-profile UNIV-FP-ALL
   no local-site



wireless tag site UNIV-101-AGG-ST
   ap-profile UNIV-APJP-ODD
   description UNIV-101-AGG-ST
   flex-profile UNIV-FP-ALL
   no local-site



ap profile UNIV-APJP-ODD
   capwap backup primary WLC-9800-B 10.100.200.11
   capwap backup secondary WLC-9800-A 10.100.200.3
   description UNIV-APJP-ODD
   hyperlocation ble-beacon 0
   hyperlocation ble-beacon 1
   hyperlocation ble-beacon 2
   hyperlocation ble-beacon 3
   hyperlocation ble-beacon 4
   hyperlocation
   mgmtuser username apadmin password 0 XXXXXXXX secret XXXXXXXX
   ntp ip 10.100.111.100
   ssh



ap profile UNIV-APJP-EVEN
   capwap backup primary WLC-9800-A 10.100.200.3
   capwap backup secondary WLC-9800-B 10.100.200.11
   description UNIV-APJP-EVEN
   hyperlocation ble-beacon 0
   hyperlocation ble-beacon 1
   hyperlocation ble-beacon 2
   hyperlocation ble-beacon 3
   hyperlocation ble-beacon 4
   hyperlocation
   mgmtuser username apadmin password 0 XXXXXXXX secret 0 XXXXXXXX
   ntp ip 10.100.111.100
   ssh



wireless profile flex UNIV-FP-ALL
   acl-policy Wireless_Guest_Access
      central-webauth
   no arp-caching
   description UNIV-FP-ALL
   native-vlan-id 14

Blog Entry #5 - 1/26/2021 - Cisco Catalyst IOS-XE - Policy Profiles (PP)



In the 3rd post regarding Cisco IOS-XE Catalyst controller deployment, I'm going to layout the various Policy Profile (PP) configurations.

The Policy Profile, as you see below, consists of a multitude of different parameters and configuration knobs.
At a high-level, it consists of the network/switching policies and details.
Anything that is a policy for a client that is applied on an AP or WLC is moved to the PP.


At a low-level, the following are some of the items setup with the Policy Profile:

   1. VLAN
   2. ACL
   3. QoS
   4. Session Timeout
   5. Idle Timeout
   6. AVC Profile
   7. Bonjour Profile
   8. Local Profiling
   9. Device Classification
   10. BSSID QoS



To be clear, all the wireless-related security attributes and features on the WLAN are grouped under the WLAN profile, which we've discussed already.


wireless profile policy UNIV-GUEST-PP
   aaa-override
   aaa-policy CWA_AAA_Policy
   accounting-list UT_ISE
   autoqos mode enterprise-avc
   no central association
   no central dhcp
   no central switching
   description UNIV-GUEST-PP
   et-analytics enable
   nac
   passive-client
   radius-profiling
   service-policy input AutoQos-4.0-wlan-ET-SSID-Input-AVC-Policy
   service-policy output AutoQos-4.0-wlan-ET-SSID-Output-Policy
   session-timeout 0
   vlan 224
   no shutdown



wireless profile policy UNIV-STUDENTS-PP
   aaa-override
   autoqos mode enterprise-avc
   no central association
   no central dhcp
   no central switching
   description UNIV-STUDENTS-PP
   et-analytics enable
   nac
   passive-client
   radius-profiling
   service-policy input AutoQos-4.0-wlan-ET-SSID-Input-AVC-Policy
   service-policy output AutoQos-4.0-wlan-ET-SSID-Output-Policy
   session-timeout 0
   vlan 192
   no shutdown



wireless profile policy UNIV-STAFF-PP
   aaa-override
   autoqos mode enterprise-avc
   no central association
   no central dhcp
   no central switching
   description UNIV-STAFF-PP
   et-analytics enable
   nac
   passive-client
   radius-profiling
   service-policy input AutoQos-4.0-wlan-ET-SSID-Input-AVC-Policy
   service-policy output AutoQos-4.0-wlan-ET-SSID-Output-Policy
   session-timeout 0
   vlan 184
   no shutdown

Blog Entry #4 - 1/11/2021 - Cisco Catalyst IOS-XE - WLAN/SSID Profiles



In the 2nd post regarding Cisco IOS-XE Catalyst controller deployment, I'm going to layout the various SSID configurations.


WLAN profiles can be configured with the same or different SSIDs. An SSID, as we all know, identifies the specific wireless network for controller and Clients to access.
When you create WLAN Profiles with the same SSID value, it allows you to assign different L2 security parameters within the same wireless LAN.

To distinguish between WLANs having the same SSID value, you create a unique profile name for each WLAN. Note: WLANs with the same SSID must have unique L2 security policies,
so that Clients can select a WLAN based on the information advertised in Beacon/Probe responses.
The switching and network policies are not part of the WLAN definition, those are configured in the Policy Profile (next blog post).


As you'll see below, the WLAN Profile contains settings dealing with: 802.11r, Band Select, Aironet IE extensions, Media Stream, MFP/PMF, and the various L2/L3 security mechanisms.


wlan UNIV_Staff 1 UNIV_Staff
   assisted-roaming dual-list
   band-select
   ccx aironet-iesupport
   description UNIV_Staff
   media-stream multicast-direct
   multicast buffer 30
   security wpa psk set-key ascii 0 XXXXXXXX
   security dot1x authentication-list UNIV-ISE-DOT1X
   security pmf optional
   no shutdown



wlan UNIV_Students 2 UNIV_Students
   assisted-roaming dual-list
   band-select
   ccx aironet-iesupport
   description UNIV_Students
   security wpa psk set-key ascii 0 XXXXXXXX
   security dot1x authentication-list UNIV-ISE-DOT1X
   security pmf optional
   no shutdown



wlan UNIV_Guest 3 UNIV_Guest
   assisted-roaming dual-list
   band-select
   ccx aironet-iesupport
   description UNIV_Guest
   mac-filtering ISE_AUTH
   peer-blocking drop
   no security wpa
   no security wpa wpa2 ciphers aes
   no security wpa akm dot1x
   security dot1x authentication-list UNIV-ISE-DOT1X
   no shutdown

Blog Entry #3 - 12/29/2020 - Cisco Catalyst IOS-XE - Policy Tags (PT)



This is going to be the first in a long series of blog posts about the new(ish) Cisco Catalyst IOS-XE WLCs.
I've had a lot of questions and inquiries about posting sample config snippets, with some brief explanation about what each section does.
So that is what I will do! :) All the configs to be posted in the coming blog entries have been completely scrubbed from a previous deployment.
Placeholder text and values have been used to replace any sensitive or identifying information, so the naming might seem a bit "odd".


This first entry is going to layout the Policy Tag (PT) construct, which ties together the WLAN Profiles (SSIDs) and Policy Profiles (PP) in IOS-XE.


The WLAN Profile component of the Policy Tag defines the overall characteristics and parameters of the WLAN itself.
Then, the WLAN Profile is tied to a Policy Profile, the Policy Profile defines the network and switching policies for the Clients attaching to the WLAN.


wireless tag policy UNIV-ALL-PT
   description UNIV-ALL-PT
   wlan UNIV_Guest policy UNIV-GUEST-PP
   wlan UNIV_Students policy UNIV-STUDENTS-PP
   wlan UNIV_Staff policy UNIV-STAFF-PP



In the next post(s), I will breakdown each of the WLANs utilized in the Policy Tag(s) and the Policy Profile(s) specifics. See you then!

Blog Entry #2 - 12/15/2020 - Strange Happenings #2



The second peculiarity I was tasked with fixing was not overly complex and is somewhat entertaining. There was a very busy and highly utilized conference room on a floor of an existing building that the client occupied. Every now and then, and seemingly with no pattern, the wireless connections and performance for end users in that conference room would be horrible: dropped connections and choppy video and audio - the standard problems that result from wireless interference. Unfortunately, a lot of the end user devices experiencing this issue were older systems, older radios and chipsets, and older drivers that would often times only connect in the 2.4GHz band. Many were only ERP (802.11g) and HT (802.11n) capable.



In order to dig up some more info on this problem, I again ran some packet captures with my WLAN Pi and did notice a high number of retransmissions. But that information didn’t really confirm the true source of the problem. Additionally, I also ran my Chanalyzer application, and very quickly saw a typical Microwave oven-like pattern in the 2.4GHz band. This took a while to pin down, as there wasn’t a kitchen or breakroom nearby, and no regularity to the pattern. I sat near the conference room for almost a day to gather data. Eventually, I noticed people walking around with hot soup and drinks. I asked them where they were getting this from and, apparently, one of the Executive Assistants had a microwave and a toaster oven under her desk. The closest kitchen/breakroom was several floors away or in another building altogether. Once I had finished my investigative work, I asked her to not run her appliances for one day. And as expected, the complaints from the conference room users ceased immediately.



The client decided to convert a seldom-used office in a corner of that floor into a kitchen for the employees. Yes, this was a very weird situation, but in the end the problem was ultimately resolved. “One for the books,” as they say.

Blog Entry #1 - 12/1/2020 - Strange Happenings #1



While working on a long-term wireless upgrade project for a major client, I ran into a couple very strange issues. The main scope on this project wasn’t actually monitoring or troubleshooting at first, it was actually to help build-out a new five building campus network (including wired switching, campus routing, QoS, Internet ingress/egress, etc.). However, this client was experiencing a some hard-to-pin-down problems and they asked me for assistance.



The first peculiarity was that a whole subset of laptops was not able to connect to the various wireless LANs in any of the US-based offices. These were all new Lenovo VHT-capable (802.11ac) systems running Windows10 mainly, current driver updates, current OS patches, and standard productivity applications such as Office 365, Adobe Acrobat, Visio, Project, and so forth. Point being, nothing out of the ordinary, plenty of RAM, disk, CPU as well. When wired into the network, these same laptops performed flawlessly, with no problems whatsoever.



After running into dead end after dead end with driver changes, wireless profile deletions and re-creations, and the other usual troubleshooting steps you would take (as outlined in various CWAP and CWSP materials), I decided to run a wireless packet capture near the offending and problematic laptops. I setup my WLAN Pi in the vicinity of several of the laptops in the build area that the desktop and server teams used before deploying the systems out to the end-users. It didn’t take long to see the problem: the laptops that were being imaged were, for some reason, only transmitting and receiving in the 2.4GHz Band on Channel 5. After talking with the desktop build team, and the server team as well, it turns out there was an errant Active Directory Group Policy Object parameter being pushed to the laptops as part of their image. Apparently, a current administrator had been toying around with the idea of locking the laptops onto a particular channel for use mainly in Europe. Without getting into the details of the laptop build process, these new systems were being put into that Active Directory Organizational Unit and thus having their radios configured incorrectly. Once the laptops were removed from that Organizational Unit the “normal” behavior returned to the wireless adapters in the laptops, and connectivity was fully restored.



Next issue discussed in an upcoming blog entry, thanks for reading.