Most commonly the sessions timeout and user idle timeout are to blame. If you're interested in the specific details..... Cisco defaults the session timeout to 30 mins for WPA/WPA2 (from memory, Open authentication is a different timer). I can't see the pupose of the session timeout to be honest. I believe it is there for legacy (Dynamic WEP) to ensure unicast keys are rotated which made sense. For WPA/WPA2 I don't see the purpose of deliberately disconnecting a client after 30 min's as I'm happy enough with the security offered by disabling it (which doesn't disable it but sets it to 24 hrs). Broadcast keys are already rotated every hour. For all L2 WLANs I now disable session timeout and set user idle timeout to an increased value, dependant on the specific deployment (2 - 8 hrs, etc). For L3 WLANs, I set it based on customer requirements (30 mins is also typically too short). There are many defaults that are poor on the WLCs imo but having said that, Apple devices ability to associate, authenticate and quite possibly their channel scanning/probing behavior is not great. ... View more

Hi Aaron, Thanks for the response. I appreciate the effort of the post. Fair enough if it is just addressing voice-only deployments. You can't address all varieties of designs/deployments in a post after all but obviously we're often thinking of the bigger picture in designs. With regards to authentication, this is a topic George and I had discussed previously. His issue with 802.1X in this context is with the administrative burden of managing individual user accounts and I completely agree. It comes down to the usual security --> usability trade-off. The 802.1X alternative then is a single account; essentially a service account. My big issue with this is the significant risk in taking down your whole VoWLAN if something happens to that account. I have seen service accounts disabled and even deleted by ICT staff and scripts when performing clean-ups of AD and just fat-fingering of accounts. The network team generally doesn't even have access to AD, but systems, desktop and even service desk teams often do. Your VoWLAN continuing to function could potentially rest on often large numbers of often inexperienced ICT staff. Lately I have been thinking that a good middle-ground between these two issues and using PSK is to use 802.1X with a single service account but have that service account stored on the WLC(s) themselves. In this way, you limit the risk to only network teams who have access to the WLC. This risk is far, far smaller. This is essentially what you've proposed above! My only issue then comes back to the security. The irony of using the more secure PEAPv0 is that because BDU doesn't support pushing out root certificates, the phones will not be able to perform mutual authentication and risk a MiTM attack. Obviously you can enable mutual auth but per below, how do you get the root CA cert on the phones in a large scale, enterprise-friendly method (i.e. - not the web interface) on each individual phone. EAP-FAST using Phase 0 also means having to rely on anonymous PAC provisioning. The risk is very small I would expect, but still present… like most complex security risks, until of course someone goes and makes a GUI front-end script-kiddie friendly tool to automate the process (a la Firesheep). With the above in mind:   * Is there any easy way of getting private PKI root certificates on to the phones (does Wavelink support deployment of these)?   * Do the phones have public PKI root certificates installed on them, out of the box, if someone wants to go down this path?   * Is there a way to retrieve the PSK or account password on a 792x phone? If I could get the root CA certificate onto phones in an enterprise-friendly manner I would be happy running WPA2-Enterprise using PEAPv0+CCKM using a single service account hosted on the WLC! If not, then it is a toss-up between keeping the PSK secure vs. potential MiTM from not performing server authentication when using PEAPv0. Cheers again for the useful post. ... View more

Hi Aaron, My biggest problem with "two APs @ -67 (at 5 GHz)" is that the CCI at 2.4 GHz is significant. 802.11n 5 GHz-capable client support has been underwhelming and therefore there are obviously still plenty of 802.11g/n clients in use. As much as we'd all like to forget it, 2.4 GHz is still an important band to design for. I have designed for "two APs @ -67" and also for 15 - 20% overlap. Even when designing for 15 - 20% overlap (let alone two APs @ -67) some 2.4 GHz radios need to be disabled as the CCI is far too high. The problem with this solution is two-fold. In a VoWLAN environment you're often doing RTLS - by disabling that radio you lose RTLS accuracy. Yes, you could add an adjacent MM AP but you shouldn't have to bear the exta cost/mgmt overhead for what should be a software solution. The second issue is that the WLC hasn't really been designed with the thought that someone may want to deliberating and permanently disable radios. For example, the dashboard will show the number of 2.4 Ghz radios down, whether they have been administriviely disabled or have died making it hard to spot dead radios (rare as they may be). The solution is per-radio MM, which is apparently on the way; it can't come soon enough! This would allow the 5 GHz radio to serve clients whilst the 2.4 GHz radio in MM assists with RTLS. The 3600 + module could help here but this is extra cost, doesn't help existing deployments nor address the second issue. Limiting SSIDs / disabling low data rates of course helps with the CCI but limiting the amount of actual actual 2.4 GHz transmissions (i.e. - not having an AP density higher than required) is also a pretty important piece of the puzzle. I think you're on the money though - "two APs @ -67" in critical environments probably should be standard. The missing piece of the puzzle imo, for Cisco deployments at least, is per-radio MM. With that said, can you give any indication when we might see it? Lastly, any idea when we may see CSCtt38270 fixed? 802.1X-based VoWLAN deployments have their own problems from an administritive perspective. ... View more

Thanks very much for the reply. With the DB backend I imagined it would be possible to do, but even if I could edit the table it wouldn't be supported, no doubt so I won't venture there. For now, I will just have the users log in and I will modify their homepage and then let them take it from there. I will get in contact with our SE and see how we go. Thanks again for your help. ... View more

G clients won't be connecting to that 5 GHz radio as they don't have a 5 GHz radio in them. I assume what you mean is that a/b/g clients are connecting to the 5 GHz radio, therefore the making use of their 5 GHz capability. Cisco doesn't support the ability to exclude 802.11a clients at the moment (hopefully some day) and therefore I am preventing their connection with a script that disables the 802.11a radio forcing them to use their 2.4 GHz radio and connect to the 2.4 Ghz SSID I have setup. ... View more

I have looked at a similar (although larger) centralised H-REAP deployment and found the controllers unable to support such a deployment. The limitations show that H-REAP has not been designed for such large deployments and as per the Cisco H-REAP guide, has been designed for a small number of branch offices. SPOF: As you mentioned, the controllers are a single point of failure as you would want all of the controllers to contain all of the H-REAP groups which does not appear possible. RRM: You cannot adjust DCA & TPC per H-REAP group - the settings are controller-wide. RADIUS: Maximum of 17 RADIUS servers. Not an issue if you have centralised authentication - we do not however. Model of controller: We would either require a rack of 5508s or utilise 4400 WiSMs in 6500s. I would obviously prefer modules but I do not wish to utilise 4400s with the 5500s out. Hopefully a 5500 module for the controller comes out in the near future. A capacity of >250 on the 5500 would be good also. QoS: Cisco recommends QoS over the WAN to prioritise controller packets and sub 100ms from H-REAP to controller. Possibly not an issue for yourself. Roaming: Does not support Proactive Key Caching and presumably also Opportunistic Key Caching. I really wish this sort of deployment was feasible however I have my fingers crossed that it will be in the future. ... View more

I tried that a few weeks ago with 54 Mbps the only 802.11a speed. I had a few issues at the time and added back those lower rates although from memory there was actually another issue. However in the past I have seen some clients have problems connecting when lower rates are removed. The other issue is that with this new deployment, the majority of clients will be able to acheive a 54 Mbps connection. I think I will just wait for Cisco to start supporting Greenfield and see how I go with that. ... View more

Well the reason this thread exists is because you cannot just disable the 802.11a rates. ... View more

Thanks for the reply Dennis. I probably should have given more details but the environment I am concerned with is an enterprise comprising hundreds of sites / tens of thousands of machines. Obviously any driver setting changes are not scalable across (pretty much any) enterprise environment. I would expect that scripting such changes would be a nightmare even on a single chipset, let alone many of them. I have a list of the almost 100 chipsets detected in our environment and so was planning to use this as the basis a script (not more than 10 of those chipsets would be 802.11n however). Of this 100, not more than 20 would be relevant to sites where this deployment it to take place. The script I am referring to would not change the band select of the driver (many drivers don't even seem to support it) but would detect the chipset and place the computer object in the correct OU, hence getting the relevant GPO and therefore SSID. I can't see a better solution than this at this point in time. Yes maintaining this would be a pain, but for the time being I see it as the best option. As you say, band steering is a very important feature but I can't see it steering 802.11a/g clients into the "preferred" band anytime soon but would love to hear otherwise. Preferred in this case, in most deployments where capacity is a major factor, is the 2.4 GHz band. Like you have mentioned, I have tested clients with a single SSID and the results were not pretty. My preferred solution is to prevent 802.11a clients on the 5 GHz radio by disabling all 802.11a rates. This obviously works to prevent 802.11b clients from connecting in 2.4 GHz so the same support would be nice at 5 GHz. I could then advertise the 2 x SSIDs in a GPO and the clients (should) connect correctly, with any luck. I have done this previously and it works with the 802.11n and 802.11g clients... just not the 802.11a clients. ... View more

Clientlink was enabled on both the autonomous 1140 and the WLC for the 1140. I can't see how it will improve performance in this case however. The client is within a few metre's of the AP and the signal and snr are both plenty for a 54 Mbps rate. If the client was some distance from the AP, sure. The b rates are disabled and an AirMagnet packet capture does not show RTS/CTS or CTS-to-Self protection being used. I did notice in some cases beacons showing "Non-ERP station present: No" / "Use protection: Yes"). Why the AP would be telling clients to use protection if no b-clients were present, I do not know. Regardless these results were consistent and if the autonomous 1230 was "hearing" b-clients I would expect the 1140 to be doing so also. ... View more

jbarger: b-rates enabled are going to be the major reason for you achieving 11 Mbps. You also really need to use iperf, ixchariot or some other bandwidth testing software to get accurate numbers. leolaohoo: I was just reading that - whilst interesting, it provides no clues as to what I am seeing. ... View more