Coverage hole algorithm thresholds

You know the coverage hole algorithm, triggered when some clients get below a certain SNR, and configured here:

 Now here is a question: I have wireless clients that do not react well when their AP signal gets too low... could you configure the Coverage Hole algorithm to be triggered if any client signal on AP1 gets below 19 dBm SNR? Oh, AP1 power level is statically set to 2  (and level 2, as you could see if you ran the show run-config command on my EUROPEAN controller, is 14 dBm).

Can you find what the threshold should be?

Ok, here is the solution. First, Coverage Minimum Exception Level is to be set to 1 (as the algorithm as to be triggered if "any client"...).

The harder part is the Coverage value. The client SNR cutoff triggering the coverage hole algorithm is calculated as follows:

Client SNR Cutoff Value (|dB|) = [AP Transmit Power (dBm) – Constant (17 dBm) – Coverage Profile (dB)]

My AP power level is set to 14 dBm, and as you can see on the above picture, the default Coverage Profile value is set to 12. So we have:

Client SNR Cutoff Value (|dB|) = 14 -17 -12 = -15

Although this number is negative, we are looking at an SNR cutoff of 15 dBm.

You want 19 instead (so result must be -19)?

The only value we can change is the Coverage Profile, setting it to 16 solves the problem...

Easy he? Yeah, I know...

In code 5.2, it gets a little better, you can also set RSSI values etc...

Do you need DHCP Option 60?

When configuring a DHCP scope for your LWAPP access points, you can return, along with an IP address, the controller Management IP address. This is called option 43, Vendor Specific Option. It is vendor specific in the sense that, in our case, only an access point would know what to do with Controller Management IP address information.
If you have read older papers, you may also have seen the option 60, Vendor Class Identifier. Do you need it, or not?
This is what it is about: when you AP boots, it sends a DHCP discover message. This message contains, among other things, a section that identifies what kind of device is requesting that IP address:

As you can see from this packet capture, in this case the AP says "I am a Cisco AP c1250. Can I get an IP address please?"
When you define an option 60 in your DHCP scope in combination with the option 43, you say "IF client is a Cisco AP c1250, then return the Vendor Specific Option defined in option 43". In other words, the content of option 43 is returned only to those clients that present the right option 60.

When using Windows DHCP server, you do not have much of a choice. The right process is to
- first define the Vendor Class Identifier
- then for this vendor class identifier define what kind of Vendor Specific Option you want to return. In our case, the option is always "option 241: controller Management IP Address" for Aironet APs and "option 102 (also controller Management IP address" for 1000 series Airespace APs
- Last, define the value of this option 241 or 102 (that is, the controller Management Interface IP address you want to send back).
So, with Windows DHCP server, you use option 60 without any real good way to avoid it.

When using an IOS DHCP scope, you do not need to specify an option 60. You can specify only the option 43, which will be option 102 if returned in ASCII and option 241 if returned in Hex.
If you specify an option 60 for that scope, the content of option 43 is returned only to those clients that present the right option 60. If you do not specify an option 60 for that scope, the content of option 43 is returned to any DHCP client asking for an IP address in that subnet.

What is the recommended practice? Or: why do some papers describing option 43 for the IOS mention the option 60, while some (many) others don't?

Well, the answer is quite simple: in the lab, I would try to put my option 60 whenever I can...
In real life, well, option 60 is cleaner: you do not send the content of option 43 to clients that do not need it. On the other hand, you should have a infrastructure addressing space, and a client addressing space. This means that your APs should be in one subnet/VLAN (the AP VLAN on that switch), and clients should be in other subnets. This makes that only APs should be in the subnet for which you provide this option 43. So there should NOT be any client NOT needing this option 43 and still getting an IP address in that scope: all clients of that scope are supposed to be APs! This is why you find many papers without this option... not to mention the fact that this option may be cumbersome to use when you have different APs of different models in the same subnet... but the lab is of course not about what is nice and simple, but what can technically be done, right?
:-)