Wireless Math

 Hi guys, and happy thanks giving. Today I will keep the short for the sake of the holidays but topic in question is something that I find important to cover. We are going to learn how to do basic RF math. 

The reason behaind having to use this RF math is because in wireless we have attenuation while the signal propagates trough the medium, similar to the attenuation on the ethernet cables on long distances but in wireless we are far more suceptible and also far more tolerant to the decrese on the signal

As you know our most basic measurements are the RSSI, Noise floor and SNR, all of them usually measured on dBm but, do you know where this comes from? Well you might know that the Decibels are a comparative measurement value and you will be correct but what are we comparing to? As usual, let's take a step back and start on what are we actually measuring with this value.

Miliwatts (mw)

The miliwatts is a sub unit of the Watt that comes from the power an electrical system has, it is derived from the voltage times the amperage of the system and represent the potency of the system, you might have even seen it some car specs now that the electrical cars are so popular. Anyway, 1 miliwatt is 0.001 watts and you might be thinking, what can I do with this low power and the answer can be transmit a WiFi signal. In our world we don't need a massive amount of power to transmit, we are basically sending a electromagnetic signal with relatively good penetration across the airo, without any interference it can actually travel a very decent distant. To give you an ideap, on the CWNA text book it is mention that a 7 watt light bulb can be seen from a 50 mile distance on a clear night. other example that you might not see as much on today's world is the radio, you can see on lower frequencies a better penetration and even from miles away from the station you are able to hear your music on your radios even trough obstacles and interferences.

For use on indoors on north America the typical Wi-Fi device is allowed to use a max of 100mW to transmit the signal, you can find this kind of power level specially on infrastructure devices as the APs but the client signal is usually limited to somewhere around 20-30mW, so keep in mind this when designing so you don't encounter a near-far issue later on.

Decibel (dB)

As I mentioned before the decibel is comparative measurement, so knowing that we are actually measuring mW on the signal you might have figure out we are actually comparing the signal to a standard power level already defined, and that is 1mW; meaning that if you see a signal of 0 dBm it is actually 1mW what you are seeing there. In other words and traslating to something more typical, if you see a -30dBm signal it means you have a signal of 0.001mW measured on that point. 

The actual math

 So, I know the last example might be a bit confusing and I want to keep it simple so let's try again.There are 2 rules that you need to know by heart if you're doing RF math. 

First a 3dBm diference means a increase/decrease of the signal by double or half respectively; so if you see a +3dBm from a reference point you will see the signal has doubled and a -3dBm is that the signal has halfed.

The second rule is if you see the diference of 10dBm it either increse/decrese the signal time 10, similar to what we saw before a +10dBm is an increase of 10 time and -10dBm is a decrese to 1/10 of the signal

To ilustrate I will give you a couple examples

10mW + 10 dBm = 100mW

50mW - 3 dBm = 25mW

Up to this point everything should be fairly easy, but what happens when we encounter something like -12dBm, well it won't be as complicate as it might seem, you will only need to find the exact factor that you're dividing by 3 and by 10 and do the math secuentially, as an example:

100mW - 12dBm =  100mW - 3 dBm - 3 dBm - 3 dBm - 3 dBm = ((((100mW / 2) /2) /2) /2)  = 6.25mW

Let's use another example:

100mW - 13dBm = 100 mW -10dBm - 3dBm = (100mw ) /10 ) /2 ) = 5mW

As you can see up to this point it should be fairly easy, you just need to found the correct factors that when you add them you can see the exact number of dBm either summed or sustracted: and up to this point you will be thinking, well not everything is divisible by 3 and 10 and you will be rigth, keeping the 100mW example so keep comparing the perspective of the result let's do first and easy one -7dBm, what you will do here is first substrack 10dBm  and then add 3dBm and it will give use  something like this:

100mW - 7dBm = l00mW - 10 dBm + 3 dBm = (((100mW) /10 ) * 2) = 20mW

And that is how you break "complex" with logarithms into basic math, you will need to figure out how to break the number of dBm by adding or substracting multiples of 3 or 10. To close the article let's do one more

100mW - 17dBm = 100mW - 10dBm -10 dBm + 3dBm = ((((100mW ) /10 ) /10 ) * 2)  = 2mW

Easy right? Ok, so now you know the 0 dBm is equal to 1 dBm, let's translate to something more familiar again, let's say we measure our Wi-Fi at -53dBm and you don't get any extra information; well,  now you now your reference level is 1mW which would mean something like this

1mw - 53dBm = 1mW - 10dBm - 10dBm - 10dBm - 10dBm - 10dBm - 3dBm 

1mw - 53dBm = (((((1mW / 10 ) / 10 ) / 10 ) / 10 ) / 10 ) / 2 ) = 0.0000005 mW

And that's all my friends, as you can see the math is fairly easy.

Thanks for reading 

Dan

Rolling upgrade - Hitless upgrade N+1 for 9800

 Hello guys, feels like it has been a while, work has been crazy lately so I apologize for taking so long to update. 

Today I wanted to show you a cool feature for your upgrades on the 9800 that I have been using a lot lately due the vulnerability from last post, is how to do a hitless code upgrade.Remember this one is used for N+1 deployments.

How it works

This one is recommended to avoid impact an zero down time on service scenario; the rolling upgrade (how it is also called), first keep in mind that to have a zero down time you will need to have a mirror AP as a back up for the one you're upgrading, this means also having the same code version so APs don't have to reboot when joining to the mirror WLC. 

Basically you will install the image on your mirrror WLC, once ready activate, commit and reload the WLC; once ready you will install the new version on your active WLC, remember not to reboot it yet, finally continuing with the AP predownload.

A useful command to review how the predowload is going is 

Show ap image

Ap image predownload

Once the predownload is done you will move the AP from the active WLC in a staggered to the mirror controller that is already upgrade, the way to do it is with an automatic command which will take 3 steps to do it:

Select APs to be moved via RF feedback from RRM and Cleanair.

Client steering

Move of the AP to reload and re-join the mirror WLC 

 

As you migth figure the AP will review the % of APs you ask it to move and check the closer neighbors, depending on the % you  select is how many APs will start moving from one WLC to another.

Before moving to the next WLC the active WLC will do a client steering for the clients so they join other AP to avoid any impact.

Finally the APs will move to the other WLC by rebooting and then joining the new one. It is worth mentioning that once triggered this process will be done automatically by the controller without user intervention, so if you're looking for a less disruptive upgrade even if takes longer I would recommend to go 5% of the AP to move at the time.

There are other factors that can be configure as how many AP per iteration need to join the mirror controller before going to the next one and what to do if the iteration fails.

Configuration

CLI

Keep in mind some of this commands (for the option configuration) might be version dependant event tough this is available from the 16.x versions.

After you upgrade the mirror WLC manually you can go to the main WLC cli and apply

ap image site-filter any-image add <site-tag> (add as manyas needed by repeating the command)

ap image move destination <WLC name>  <WLC IP address>

ap image site-filter fila any-image apply

To remove the filter for site tagas you can use the  

ap image site-filter file any-image clear 

or

ap image site-filter file any-image remove-all

 Optional commands are on the configure terminal mode 

#no ap upgrade staggered client-steering  (disable client steering, will make it faster but more disruptive I don't recommend it)

#ap upgrade staggered iteration completion <min-percent>  (default is 90%)

#ap upgrade staggered iteration error action <stop> (configure what to do when the iteration fail)

#ap upgrade staggered iteration timeout <timeout-duration> (timeout per iteration in minutes)

GUI

From the Controller GUI go to Administration -> Software management

The following screen will appear.

 

 

Click on hitless upgrade and more options should show, fill the option as follows:

Note: You can upload the code to the controller with HTTPS from your PC

 

On Site Filter you can use custom and move only certain site-tags for hitless upgrades or select all sites for every site-tag on the WLC.

Add the WLC IP and Name, on the AP upgrade configuration section set the AP Upgrade per Iteration to 5% for the slowest but less disruptive upgrade; make sure to select the Client Steering option so the WLC suggest the clients to move and avoid any extra impact and leave the rest as default.

Click on Download & Install a new section will appear to the right and you will be able to see the image uploading. 

Wait for the image to install, when it goes to the section AP Image Upgrade and Move you will be able to see the APs start moving between controllers.

Wait for the image to commit and the WLC to reboot, once that is done the APs will start to come back to this WLC.

And that's pretty much it! 

Reference articule: Cisco Catalyst 9800 Series Wireless Controller Software Configuration Guide, Cisco IOS XE Cupertino 17.9.x, from cisco.com.

Thanks for reading today

Dan

New vulnerability in IOS-XE CVE-2023-20198

Hello guys, hope you’re doing great!

As you might have noticed there has been a new PSIRT released today (October 16 2023) for the IOS-XE devices; the PSIRT has been identified with he ID CVE-2023-20198 and bug ID CSCwh87343.

 

Symptoms

In summary the bug can allow any remote and unathenticated attacker to create an priviledge account level 15 into your IOS-XE devices, then by using the new account the attacker can gain admin access to your devices.

 

How to mitigate

At the moment there aren’t any normal or escalation version to mitigate the issue so Cisco is recommending in general to disable the HTTP server (HTTP/HTTPS). For the IOS-XE switches this should be simple enough with the following commands:

no ip http server

no ip http secure-server

copy running-configuration startup-configuration

 

Wireless

Now, while the switches we are more used to managed via CLI I do understand than disabling HTTP/HTTPS access to the C9800 WLC might mean a bigger deal than with the switches you should consider the following:

 

• Does any management interface is reachable via the internet?
• Do we have any way to filter traffic from the internet to reach the ports for HTTP/HTTPS into our management vlan?
• How likely is from an attacker to gain access to the management vlan and reach the IOS-XE devices from there

 

Ultimately the recommendation remains to disable the HTTP server out of the WLC but the decision to do so if you feel your environment is secure enough to run the server until a hot patch is released you can take the risk accounting for it. 

There is not expected timeline for a fix to come out, taking this into account in my expert opinion I would try to configure anything that needs to be configured and disable the server, only enabling it in case there is a extreme case that you need to access the GUI re-enable it for a limited time and disable it again once is done.

On the case of your wireless C9800 in case you are using web auth remember to use the following command too so you don't break the process.

parameter-map type webauth global

webauth-http-enable 

One more thing, about DNAC

Remember you can always access to the monitoring part of the controller and have even more insight via DNAC assurance. So, as long as you’re not planning to do any config changes you should be ok.

 

Update from Oct 24rd 2023

A new version has been released for most of the IOS-XE devices which includes the C9800, the version 17.9.4a has the hot fix for this vulnerability. Now, it does not come w/o a price, this version does not let you install the AP service packs from the 17.9.4 which fix other vulnerabilities that were published on September. 

I took a bit more time to update to investigate a little and there is a SMU patch for the 17.9.4 that also fixes the vulnerability already available in cisco.com dowload for all the platforms.  I suggest you that if you are going to install a patch go with this option.

Unfortunately, this only works on the 17.9 train and the fix is still pending to be publish for other train versions. 

I'll keep you posted!

Thanks for reading 

Dan

Wireless config analyzer express

 

Hello everyone, so this is a post I promise sometime back. Today I want to talk about the config analyzer express, this tool is like the config analyzer that we already talk about but for the C9800.

 

To get to it you can go to this link

You can watch this video for reference on what is on the report, let me apologize for the audio before hand. seems my mic was a bit muffled but I will try to improve the audio an re-upload it.

Let’s get to it, so for this one you have two options, either install the config analyzer on your PC or go to the cloud version, I usually use the second since the output is exactly the same on both tool so my recommendation is to use it too. For this one instead of a “show run-config” output but the “show tech wireless” output to make it work.

 

For the installation you need to access the github page from here:

From there you can download either of the versions and install it as any other app:

Now for how to use the cloud version you will need to access it from this link:

Now you can drag and drop the show tech wireless on the space for it and click on Run, you will need to wait a minute or two for it to process depending on what you have on the config. 

When it finishes loading you can download the results here or read the info scrolling down

Now the output of both reports is identical so make sure to check each the menu on all pages depending on what you’re looking for.

 

For a bit more information on the tabs you can check this video on my channel that is at the top of the post. 

But here is the main tabs you can access on the report, make sure to check them out, specially the best practices and the client stats are great ones:

Thanks guys for your attention today, this was a short article but I hope it helps like it does to me to get more insight in my WLCs.

See you soon 

Dan Lopez

About Roaming solutions

Ok... so today was one of those days when someone reach me out because he got to me confused about a concept, and, since there is so much information about the topic the concept got mixed up on his head, so now I’m writing this for future reference in case it happens again.

First, let's start defining what roaming is on Wi-Fi terms, basically is the movement of a wireless client from one AP to another with everything it implies, the association, authentication, derivation of the encryption keys if there are any. Long time ago that last part implied an interruption in the service since there was no methods to “fast roam”; thankfully on today’s world that has been fixed

Cultural parenthesis that I learned on my CWSP, the 802.11 standard name of roaming is “transition”, no one uses it, but is good for you to know in case you suddenly start reading the protocol as it once happened to me.

Roaming on open SSIDs

Let’s take a step back, when a client connects to an Open SSID the process is straight forward since there is no encryption, it will just perform an open system authentication a then an association. So, what happens when the connected client roams? It needs a re-association process and reauthentication, these are the frames that control the roaming are similar but they are not the same and it’s expected from a wireless expert to know the differences on them. On the case you are on an Open SSID, you will only need these frames to re-connect to the next AP without any hiccups in your connection.

Image from cisco.com

Roaming on open PSK

Following the line of stepping back, let’s explain a few concepts youneed to be aware to understand roaming.  From CWSP-206 book

PMKSA – Pairwise Master Key Security Association. The context resulting from a successful 802.1X authentication exchange between the peer and Authentication Server (AS), or from a pre-shared key (PSK)

PMKID – Pairwise Master Key Identifier. The PMKID is an identifier of a security association.

PTKSA – Pairwise Transient Key Security Association. The context resulting from a successful 4-Way Handshake exchange between the peer and Authenticator.

Now that you know these concepts exist let’s start from the simple and go our way up, we already covered open SSIDs so let’s go to PSK. With WPA/WPA2 the client will perform a 4-way handshake after the Open Authentication and associaton, in this case when you roam you will need something similar to the first scenario described, reassociation frame and re-authentication frame, in this type of roaming you won’t need any reauthentication enhancements, since the auth is local it should take about 50-100ms, all this thanks that the authenticator will handle the whole authenticaiton process; this we call a slow roaming.

Slow roam steps

1.     Open System authentication

2.     Association

3.     802.1X/EAP authentication

4.     4-way handshake

 

Roaming with 802.1x 

Here is where the confusion starts, when you use 802.1x authentication we start using fast roaming enhancements; why? Because the normal roaming or the so called slow roaming would be in use otherwise, with 802.1x we are using RSN or a robust security network, that is more complex. On an 802.1x network roaming you have three parts, the client device or supplicant, the AP/WLC or authenticator and the authentication server, the interaction between the 3 parts on a good day will take about 200-300 ms (which should be fine) but it can up to 500ms or more in case the authentication server is not local, which on a live network with voice and video will cause some issues.

If you have work with VoIP or Video networks, you might already know this but UDP traffic does not see a benefit to resend any of the lost packets in a transmission, now if you have a delay of half a second on your roaming you can figure how many packets, we are going to lose that will traduce in choppy voice, audio/video loss or even full drop.

I could keep talking about topics to provide context about roaming for a while so I’ll be selective and add only one more before moving into our solutions, so in wireless we can have intracontroller roaming and intercontroller roaming; the first is when the client roams between APs on the same controller and the second is when you roam between APs connected to different controllers. Why you should care about this? Because whenever you roam between controllers the roaming gets more complex and it will take longer. Same is the case between L2 roaming and L3 roaming, L2 happens when the client stays on the same VLAN and addressing domain when roaming but L3 happens when the AP that you move to can’t provide a IP address on the same addressing space you were working and add an extra factor to our whole process, the DHCP request, we are going to skip that last concept and fix ourself on the security part.

Moving on, up to this point I think you know that what we want is to implement a “good” roaming, for that we need it to work seamless. As a clarificaiton in this post I will assume that you have a proper cell overlap and a good RF health. 

So what are our options to manage the roaming better.

Preauthentication

In the battle to remove the delay in the roaming process this is the first method that came out,  this IEEE standard method is used by the client station when scanning APs it might choose to move, it basically performs a full 802.1x authentication over the ethernet infrastructure for the purpose of remaining connected on-channel with its current AP while preparing the connection to the possible next AP. It does have a couple inconveniences as that it does need to do a full authentication to each of the potential APs that the client can roam to, while doing this for typical roaming conditions if you move around the whole building it might not work as well as we wish and that it might authenticate to APs you will never roam too since the client can’t predict where are you moving too.

Some extra information is that it uses EAPoL frames that are treated as data frames and forwarded to the distribution system, it uses a special Ethertype value of 88-C7 to distinguish this frames as roaming.

The good part about this is that is standard way to roam, so it can be used on any WLAN architecture, but at the end is not very efficient since it will only cut a few milliseconds of roaming time (1 to 3) and as you might figure it does not scale well.

PMK Catching

Pairwise master key (PMK) catching is another method to improve roaming, also known as “Fast Roam-back”, so as you might get from the alternative name it works when you already connected to an AP roam out of the service area and then come back to it.

Basically, it catches the PMKSAs or the security associations on the AP for a certain period of time with the purpose that whenever an client comes back it does not need to complete a full re-authentication but to use the previous keys that were negotiated on the first authentication. To make this work the client must have and keep an PMKID and transmit it to the AP on the re-association request, knowing that the PMKID will be associated with the PMKSA the authentication will be skipped and will move into the 4-way handshake directly.

This is another method that is not considered very effective since it only provides a fast roam back to a previous AP and new APs require a full authentication, on the bright side it does a better job decreasing the roaming time and it does not cause overhead to the network, it scales well and it’s standardized by the IEEE so it is supported on all the WLAN deployments.

Opportunistic Key Caching (OKC)

One of my favorites (I shouldn’t say this… is not standardized!) or at least it was for a while, is a solution that came out a while ago, it needs the interaction of the AP and the client side. The PMK and PMKID are retrieved from the initial authentication to the first AP the client connects, these are distributed to each APs that are possible candidates for the roam; remember that the PMKID is based on the BSSID the AP is using.

Once the key and ID is distributed the client can roam just using a re-association and it can either show it’s PMKID on the frame or the AP can provide it to the client, it makes not much difference on the administrator side since the AP at the end will use the MAC address to recognize the client, match it to a PMKID; now if the client is identified it goes to the 4-way handshake where it indicates that it found a match, if the client is not recognized it sends an EAPoL-Start frame and starts a full auth.

Unfortunately, this method is not supported by every deployment since is not standard; it is widely spread but you might find clients or infrastructure that do not support it, on the bright side it does only use the initial 802.1x authentication so it scales well.

Fast Transition (FT) or 802.11r

This is one of the latest standard on the 802.11, it is a bit complicated so I will try to summarize it as best as I can and will assume you’re familiar with the concepts. Here is a quick list on what you should be familiar with:

PMK, PTK, GMK, GTK, Fast basic service set (BSS) transition, Fast BSS transition 4-way handshake, Fast BSS initial mobility domain, mobility domain, Over-the-air, Over-the-DS, all these concepts can be found with one look into the 802.11 standard and easily found via google, just to let you know the recommendation to be familiar with this does not only comes from me but by the CWNP gurus Lee Badman and Robert Bartz. Spoiler alert, they are right.

As you might know the robust security networks (RSN) and authentication and key management (AKM) follow a process to derive the keys (I will write a post on this later for your reference), from this process is where you will get the PMK-R0 that derives from the PSK, PMK-R1 that derives from the PMK-R0. So basically the 802.11r standard is about allowing non-AP stations to preauthenticate with the AP to which it might roam later, the difference with the “Preauthentication” method is that in a FT BSSID won’t need to do a full authentication to the next AP, instead it will take a PTK (derived from the PMK, an to be more specific the PMK-R1) to communicate with the client, so it basically will take a previously negotiated PMK and derive it’s own keys to talk between AP and client.

Image from cisco.com

I know… this is a bit confusing, but the takeaway is that it takes advantage of what it was already negotiated on the network and skip some steps to save time, let’s say it skips ahead to the point it takes generates the keys to encrypt the communication. One last thing on this idea, the preauth is optional on the standard but the method is normally adopted with it to save even more time while roaming.

Now, to close the idea why I ask you to read about over-the-air and over-the-ds? Quite simple, these are the methods you can share the keys with the next AP. On the over-the-air we send the credential between target AP to roam as its name describes, it simplifies the process reducing the frames for the re-association from 8 to 4 with the fast transition cutting the time to roam in about a half. 

Image from cisco.com

Over-the-DS as you might know send the frames to the AP you’re connected; these are forwarded to the target AP to roam via your wired infrastructure and the new PTK will be created by the client and the new AP.

Image from cisco.com

As complicated as it is this is very advantageous and easy to implement, it is standard and even required by now days voice-enterprise certification, it is considered the most effective roaming method available an to be honest you only need a couple of commands to enable it, the only problem is that the adoption has been slow.

Other roaming solutions

And here you have, you can see the confusion between the methods since all of them are called fast roaming, but some are better than others. There is one other solution that is a single channel architecture, this is a proprietary solution that the controller will manage the roaming between APs where the client will think all the time it is connected to the same AP. I won’t dig deep into this since I’m not a big fan due to the disadvantage that the use of this architecture might have on the RF, must be used discretionally.

P.S. 

If you hang out up to this point you might figure the confusion I talked at the start it was between OKC and 802.11r

Reference articule: Cisco employeer, "Chapter: Chapter 12 - Configuring Mobility Groups", from cisco.com,  September 28, 2011

Reference book: CWSP-206: Certified Wireless Security Professional: Study and Reference Guide by Tom Carpenter. Certitrek publisher.

Thanks for reading 

Dan Lopez

 

Transmission power and data rates

Hello guys, today I have an experience that made me think about a common misconception we as a wireless community have when adjusting our RF for green and brownfields, this post will be regarding how the data rate change really affects our RF designs.

To start on this let me state that I thought this was correct for a while and I think were the myth started, with this kind of images (credits to the owner):

Credits of the image to whom it might belong to. I have seen it several sites

The image, as you might already know, represents how the data rates get demodulated according to the physical distance, it exemplifies how the closer it is to the transmitter the easier it might demodulate a higher data rate and to be honest it makes perfect sense, it basically shows the physical range according to were the that data rate can work, right?

So, where is the misconception? I guess as me, you might have noticed forums, recommendations, and other places where it’s casually mention that increasing the minimum data rate to let’s say 24Mbps or 36Mbps will decrease the cell size and stop the interference; well that’s what I want to talk about.

 Transmit power

First, let’s do a refresh on the Co-channel interference concept. The interference occurs when there are devices close enough to “hear” each other and operate on the same channel, when this happens is not uncommon to see the to see the two devices contend for the medium access, this can also be called Co-channel contention (CCC).  

To mitigate or even avoid this issue there are two solutions, the obvious but difficult one: move to another channel; difficult because it will be so hard in today world to find a Wi-Fi channel that does not have another devide using it, maybe 6GHz?

The second solution is to plan and reduce your cell size; now just for you to be aware, there are two types of “boundaries” on a Wi-Fi cell, the association boundary and the CCI boundary.

Let’s start with the CCI, this boundary exists as the area where the listening stations (STA) that are or not part of the cell must be silent, this because they detected a signal over the minimum threshold; this behavior comes from the CSMA/CA that we have mentioned before, therefore this boundary can be won't necesarily be affected by low data rate signals, even when the lower data rates are disabled.

Important note: Remember that just because a signal cannot be decodified or processed by the STAs does not mean that a signal cannot be detectedor hear if you willl, this initiates the backoff timer to transmit, we have talked about this too before.

Give a check to my QoS out of the box post!

 

Now, the association or data rate boundary, this one work depending on the data rates enabled on the cell; basically, if you disable slower rates as 6Mbps or even 12Mbps, the physical range where the signal can be decoded decreases an it gives you the feel that your coverage is smaller; is it true that it is smaller? Well yeah! You won’t be able to "work" on that cell if you walk further away from where the signal can be decoded, this can be easily checked walking to the edge of your deployment, verify your coverage, then disable lower data rates and try again.  But, here is the misconception, as stated before, even while you can’t connect on that cell that does not mean that the signal is "heard" and triggers the backoff timers.

How does it look, here is an image from CWDP-303 book to make it easier to understand:

Ok so I gave you something to think about but not a solution, right? That doesn’t sound like me at all… I do know a way to make the CCI boundary smaller; the old fashion way is to make your cell smaller limiting the TxPower on your infrastructure devices, that will determine how far away you will be able to see the signal over your threshold signal.

Other ways to mitigate it is to increase the threshold but for this there is a small inconvenience; you can’t control the threshold of all the client devices, nevertheless I want to talk about it because from this idea there is one of the enhancements of Wi-Fi6, BSS coloring; while it will not be discussed in depth on this post I can tell you that basically with coloring you will be able to increase that threshold and ignore other signals as if they were not part of your deployment due to it’s “color”, of course to make it work properly a full Wi-Fi deployment it’s recommended and that can be expensive.

Note: For the CCI boundary we can’t overlook that the client has its own boundary and needs to be taken into account when doing the channel planning design.

 Data rates

As a small P.S. I wanted to talk about data rates, in this post so far, we have talked about how disabling them won’t decrease the CCI boundary but the association boundaries, does that mean it doesn't matter and we should enable all the lower rates? Not really.

There are many things that depend on the data rates and the cell lower-highest mandatory data rate, as beacons, multicast, sometimes I have seen roaming been affected by it. So, while it can’t fix the co-channel interference there must be a balance between the transmit power and how you don’t want that the beacons hog the medium with a slower data rate since it will take longer to send management frames.

My recommendation is before changing them always double check what are you designing for, voice, video, data. Keep in mind that the end application and the end devices will help your design and the more you keep those in mind the more accurate it will be, check the data sheet of your older devices, or for your special IOT devices, that’s a good guide.

I usually leave the lowest rate enable to be 12 or 24 on most deployments but I have used 36 too as the lowest mandatory rate on high density deployments with directional antennas, again always think on your use case.

Now a fun fact that I have seen it been overlooked, take a careful look at the lowest rates on the following image:

Credits of the image to whom it might belong to. I have seen it several sites

If you don’t know the index about acronyms on the top of the table, I will leave it at the end of the post, right now focus on the data rates; can you see how MCS 0 can be as low as 6.5 or 7.2 Mbps? Newer protocols use MCS data rates and those need to be enabled or disabled too for some use cases so always keep in mind not to only check the legacy rates but the newer too.

Am I saying you should always disable MCS 0? No, I’ll be honest, historically I have seen a lot of cases where a bad client-side driver can mess up your communication, that was sometime ago and should be better now, the point here is try to keep these new 802.11 revision in account too. 

Thanks for reading.

Dan Lopez

 

And as promise here is a quick reference for the data rate table I loved how simple this page explain it so take it with you if you want to learn more 

Reference articule: Panagiotis Vouzis, "What is the MCS Index?", from netbeez.net,  September 16, 2020

Reference book: CWDP-303 Certified Wireless Design Professional: Official Study Guide by Tom Carpenter. Certitrek publisher.

WLC config analyzer

So we meet again

I been a bit swamp on the last couple weeks, but I wanted to take time today to tell you about a great tool I use a lot on my work; this is a public tool and can be used for anyone with a computer.

The tool is pretty self-explanatory in the installing and using (I will give a quick glance on that anyway); the tool gives you a lot of insight of your Cisco controllers configuration; here is he link to download and a quick tutorial.  

https://developer.cisco.com/docs/wireless-troubleshooting-tools/#!wireless-config-analyzer/wireless-lan-config-analyzer

As you might figure out it divides in two, AireOS and IOS-XE this articule will dedicate for AireOS software only.

 

WLCCA for AireOS

The tool needs to be installed on your computer, to use it, to do so you can do it as any other program, use the download link and use the setup.

Follow the installation instructions and open the program, it will look something like this

Now as the documentation says, it needs to use a “show run-config” output on a txt file and won’t work with backups done by tftp or show tech. So let’s load a config and see what do we get. Click in File -> Open, a new window will emerge; my suggestion here is leave it as default unless you’re using voice specialized devices (not computers or smartphones), click Ok.

Look for your data an select it, there is going to show you a loading screen and then the interesting output we are looking for, on the left menu you can find information about the controllers config you input (as the documentation says you can add more than one config file while opening it).

Unfortunately, I won’t be able to show you any specifics on the configuration I’m using since it’s confidential, but I think I can explain a bit on each point of the menu. To me it does seem intuitive and easy to navigate so I’m not going to fixate on explaining each one but maybe on some of the useful tricks I have found while exploring the tool.

Best practice check

My first recommendation is do not overlook the best practices part, it shows you a compliance level of the current best practices and you can even break it down to AP, General, Mobility, RF and security depending on what you’re interested. Now, remember this is NOT a must configuration that you should have and some of the values can be tweaked depending on your specific requirements but, the closer you’re to a 100% the more we can guarantee the network will perform on most cases.

Example of RF compliance check

Example of Security check:

 

Troubleshooting pointers

If you’re troubleshooting roaming issues, slowness and disconnections, I can give you some pointer you can verify from the config analyzer fairly quick and that will give you some insight, my examples are for 2.4 GHz but this applies for 5 GHz

Client distribution – SNR

Check how many client below 20-25 dBm you have on the WLC, anything below that:

Client distribution – RSSI

Similar to the SNR, if you see a low RSSI you might want to check your Tx power level or sticky client behavior.

Channel distribution

Check how evenly are the channels distributed on your AP groups, if you see something loaded to a few channels you can check the clean air for inference.

RF Health – AP groups

This will show you a summary of how many APs you have with low, medium, and high health. If you need more specifics for the bad health just open ap group in question and if find the bad health AP, double click on the name and you will be redirected to the RF status to that specific AP and will show what’s going on.

 

 

Charts

Now lets’ talk about some useful buttons on the Analyzer; did you can make charts of the RF statistics of the WLC? Click on the following button and you will get a new page, on the right menu you can select many options for charts that can be a graphical way to understand the information

 

 

I’m putting the channel examples but I recommend you to navigate around the graphs shown there and play with it a little bit check what you can find

 

AP graphs

You can even see the interaction of the APs to each other in a “who hears who” kind of matter. Mine will look like a conspiracy theory diagram due to the large number of APs but I encourage you to try it on smaller deployments, it can be pretty helpful.

 

Roaming prediction

Finally, I want to show you something that it’s a neat feature on the config analyzer and probably overlook, on the top menu there is a RF Analysis section, in there you can find a roaming prediction tool that if you click a set of neighbors it can predict how a client will roam (or should roam), you can even personalize things as the walk speed and the roaming RSSI values. I recommend you to try it, is pretty cool.

 

One last thing – Report Center

If it’s easier for you to look to this in excel to manipulate data, on the top menu on the report center you can export the information to many different formats, this can be easier on your eyes if you’re doing an deep analysis on many APs, keep it in mind.

 

 P.S.

Well I wanted to show you about how I use this tool and the coolest features in it, this does not mean I talked about everything so again, I encourage to explore it on your own and do some simulated tshoots; the developer team put a great effort on this and to be honest it does perform amazingly for a “simple tool” so don’t sleep on it.

Reference articule: Cisco employee, "Wireless LAN Config analyzer", from developer.cisco.com,  

 

Hope you enjoyed the post, the tool and the wireless world. Till next time

Dan Lopez