How to get your 792x wireless phones performing reliably

Document

Sep 7, 2012 5:22 PM
Sep 7th, 2012

Voice over WLAN - a challenging technology

Voice over WLAN (VoWLAN) is one of the most challenging technologies that Cisco provides.  For VoWLAN to work satisfactorily - especially in the high-stress environments in which it is deployed, such as healthcare - the network, and the phone, must be able consistently to transport a real-time, bidirectional, securely encrypted audio stream, with almost no dropouts, while the endpoint moves across four dimensions (space and frequency).

This document explains how to get 792x wireless phones (7921G, 7925G, 7926G) to work well in a Cisco Unified Wireless Network.

Seven basic guidelines to making VoWLAN work well

Though delivering a reliable VoWLAN service is difficult, it is possible, provided that the network provider adheres to the following basic design guidelines. 

1. Have solid coverage in 5GHz - and lock your phones to 802.11a

Your network's ability to perform is fundamentally dependent on a solid physical layer.  VoWLAN uses both the 2.4GHz and 5GHz bands.  Of these, the 2.4GHz band's lower frequency signals carry further - however, the constrained bandwidth (only three non-overlapping channels) and ever increasing interference, render 2.4GHz, in most cases, unsuitable for reliable voice.  Network providers who want to deliver a reliable VoWLAN service will ensure that their design adheres to the following standard:

Every spot in the coverage area is serviced by at least two viable 5GHz access points, at -67dBm or stronger.

You can easily validate the necessary coverage by setting your phone into site survey mode, and walking throughout your coverage area.

Additionally, AP placement, antenna selection, building construction, etc. must be such that multipath distortion is kept to a minumum.  To ensure gap-free roaming, a moving phone must be able to hear each roamed-to AP at least 5 seconds before it needs to roam to it - so place all APs in the middle of halls, at corridor junctions, etc., rather than in blind spots.

2. Run 1.4.3 or above - nothing earlier

The 1.4.2 firmware introduced a greatly improved scanning and roaming algorithm in the 792x phones.  1.4.3 introduces other critical fixes.  If you are experiencing audio problems with your phones - never, ever run any firmware prior to 1.4.3.

Be aware that, for newer hardware revisions of the 792x phones, it is not possible to run any firmware prior to 1.4(3)SR1 - see the release notes.  Therefore, for new or RMAd phones, you can't run the old firmware, even if you want to.

3. Best to have access points in local mode, not Flexconnect (H-REAP) local switching

If using FlexConnect (H-REAP) local switching, watch out for the following:

  • CSCtz31572 HREAP local switching - ARP , broadcast key on standalone transition (affects 7.0 prior to 7.0.235.0 and all 7.2)
  • CSCul15555 FlexConnect AP - decryption errors after CCKM roaming (affects all releases)

Other reasons to avoid FlexConnect for 792x phones are:

  • Flex local switching does not support ARP caching (i.e. the AP cannot ARP on behalf of the wireless clients to the LAN.)  Therefore, ARP is unreliable, and battery lifetime on the phones is impaired.  (This limitation will be addressed via CSCty04398, in 8.0.)
  • Fast Secure Roaming via CCKM is supported only among APs within the same FlexConnect group.  As the number of APs within a Flex group is limited (for example, on the 5508 WLC, to 25 APs), FlexConnect is not suited to large deployments.

If your WAN link between the APs and the WLC is high latency, unreliable, or low bandwidth, then consider installing a WLC at the site where the phones are.

4. Use WPA2/AES EAP/CCKM or static WEP - beware TKIP and PSK

WPA2/AES Enterprise with CCKM is the recommended security scheme for 792x phones - it is the most secure method, and provides for the fastest roaming times.  You may use Local Authentication on the WLC, if you do not want to use an external RADIUS server.  (When using CCKM, use the WLC command "config wlan security wpa akm cckm timestamp-tolerance 5000" to increase the likelihood of performing a fast roam.)  (Also see the CCKM Client Disconnect Bugs in 7.0/7.2 tip.)

If security is not a concern, then static WEP will work well.

Avoid TKIP which is susceptible to MIC error triggered service interruptions.

With 7925G phones, avoid WPA/WPA2 Preshared Key (PSK.)  This is because the 7925G phones suffer from the following problem, which intermittently prevents WPA key exchanges from completing:

    CSCtt38270 7925 sometimes takes 1+ second to respond to WPA M1 key message

This bug does not affect 7921G or 7926G phones.  It will not be fixed for the 7925G; if you must use PSK with 7925G, you can mitigate the impact to some extent with: config advanced eap eapol-key-timeout 250

Warning: the RM3000AC 802.11ac modules for the AP3600 do not support CCKM, and are not supported for use with 792x phones.  Having these modules enabled will cause problems for roaming - workaround: enable both TKIP and AES on the voice WLAN (which will keept the SSID from being enabled on the 11ac module) - track CSCui67756 and CSCuh82417 for a fix, expected in the 7.6 AireOS release.

5. Optimize channels, power, and data rates

  • channels:
    • use at least 8 channels (if available in your regulatory domain)
    • use channels from UNII-1 (36-48), UNII-2 (52-64), UNII-2 Extended (100-140), and/or UNII-3 (149-161 but not 165)
    • if coverage is weak, avoid channels with lower power limits
    • if radar detection is frequent, avoid the DFS channels (UNII-2, UNII-2 extended)
  • power:
    • in 5GHz, use a minimum power level of at least 11dBm
    • in all 5GHz deployments but the very densest ones, you can simply set a power level of 1 (maximum)
  • data rates:
    • set 6Mbps as the lowest mandatory rate, be sure that 12 and 24Mbps are enabled
  • remember to make any changes on all WLCs in the RF group

6. Enable continuous scan mode (in CUCM)

If 792x users roam from AP to AP frequently, then continuous scan mode should be enabled; however idle battery life can be reduced to some extent.  (A fresh battery should still last an 8-hour shift.)  Without continuous scan mode, the AP may be intermittently associated to an AP with a weak signal, which may have an rare impact on incoming calls and pages.

7. Configure all QoS, and everything else, exactly as documented in the 7925 DG

Go through the entire 7925G Deployment Guide, and configure the phones and the wireless network as per its recommendations.  In particular, make sure that all QoS configurations are set as per best practice, throughout your wireless and wired network.

Conclusion

With strict adherence to every single one of the above guidelines, there is a high probability that your VoWLAN service will meet your clients' performance expectations.

Average Rating: 4.9 (9 ratings)

Comments

briangormley Wed, 10/03/2012 - 02:18

Thanks for the info. This is a great summation of what is required.

I have identified something that you may have encountered and thought I would ask,

1x 7925G handset, with 3COM wireless deployment.

All wireless devices can connect fine and operate as expected, but the 7925G shows some funnies, one of which indicates a clear pattern.

After the phone connects, and registers with the CUCM, it can make and receive calls shortly after registration. If you leave the phone alone, but run a continual ping to it's IP address, without fail the phone disconnects from the network (and obviously unregisters) for a period of approx 2 minutes and 15 seconds, it then comes back up for a period of 55 to 60 seconds, and then drops off again for 2 minutes and 15 seconds, then back up for a minute, and so on.

Based on this finding, it clearly indicates a pattern.....some sort of timer.

I have exhausted the options available for configuration on the handset itself. I have used all your tips provided here and have gone through the 3COM controller agina and again looking for ways / options to change things further. But everything is set to "best practice" as per deployment guide.

Running out of ideas....Cisco TAC simply say it must be the 3COM wireless - but all other wireless devices, including my iPhone and iPads work fine.

Any thoughts or ideas I could try?

migilles Wed, 10/03/2012 - 04:49 (reply to briangormley)

Suggest to open a separate thread for your issues.

However, ensure you are using the 1.4(3)SR1 release for your 792x phones (firmware 1.4.3SR1.2) as it contains some critical fixes for 11n APs (see CSCtn75346).

We do not formally test interoperability between our Cisco 792x WLAN handsets and the 3COM WLAN solution, so we can not guarantee interoperability, but as long as standards are followed and not encountering a defect on either side, then basic call functionality should operate just fine.

andypenning Wed, 10/10/2012 - 07:45

Thank you, great doc! Regarding this statement:

Every spot in the coverage area is serviced by at least two viable 5GHz access points, at -67dBm or stronger

Up until now I've always been told to make sure there is roughly 25% overlap at -67dBm, which makes sense to me. Why two? I'm already blown away by the density of model-3600 APs required to satisfy the 25% overlap, especially on UNII-1 channels with the 6mW Tx power limit.

Andrew

Aaron Leonard Fri, 10/26/2012 - 10:30 (reply to andypenning)

Andrew,

Let me explain the thinking here in specifying "at least two viable 5GHz access points, at -67dBm or stronger".

First of all, the -67dBm level has always been our standard for voice coverage.  For one or two calls per cell, this is not strictly required, as long as you have lower data rates enabled, but this is specified in order to have the desired call capacity.

Now, the "20-30% overlap" at -67 between cells continues to be the standard as given in the 7925G DG.  This design will allow phones (with the improved scanning in 1.4.2 and above) to roam smoothly across cells.

The reason for the recommendation here for two APs at -67 dBm is for purposes of reliability - specifically for deployments where the phones are operationally critical, such as healthcare.  If much of your coverage area is served only by a single AP, then any phones in that location are going to have a problem in conditions such as the following:

  • the AP radio resets or the AP reboots (it happens ...)
  • the AP radio needs to change channels due to DCA, interference or radar detected, etc.
  • a phone associated to the serving AP decides that it is no longer viable (due to a momentary glitch - packet max retries, or BSS loss), so it needs to roam elsewhere.  If there is not another viable AP in the area, that phone will need to rescan before roaming back to the serving AP (costing typically 5-6 seconds)

For deployments that are not so critical - where the clients are tolerant of (rare) 2 to 6 second audio gaps - then the 7925G DG's recommendations stand.

scott.stapleton Thu, 12/27/2012 - 22:04

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.

Aaron Leonard Wed, 01/02/2013 - 09:40 (reply to scott.stapleton)

Scott,

This document's recommendations pertain very specifically to support for 792x clients only, and only in 5GHz (not 2.4GHz).  As you rightly note, 2.4GHz support is an entirely different story.

The feature that you are interested in (per-radio roles) is outside of the scope of this article.

As to addressing CSCtt38270 (7925 sometimes takes 1+ second to respond to WPA M1 key message) - for that to happen, the following sequence of events will need to occur:

  • a customer who is really insistent on using PSK, not EAP, must open a TAC case
  • that customer must keep the TAC case open till the problem is resolved
  • that customer must be willing to run experimental phone firmware, collect logs and wireless sniffs, etc.

Aaron

STEFAN CHRISTEN Tue, 01/15/2013 - 02:47 (reply to Aaron Leonard)

Hi Aaron

Thanks for these guidelines.

CSCtt38270 is listed as Terminated in the bug tool which usually means it will never be fixed since it can not be reproduced. So, will the bug ever be fixed? WPA2/PSK is used in most of our existing implementations (that have been implemented before this bug was first seen) and is still the prefered method for large deployments (WLANDefault.xml)

Regardig the Continuous Scan, do you know how this will affect the standby time?

Do you know if and when your guidelines will be included in the 7925 deployment guide?

Many thanks for your feedback

Regards

Stefan

Aaron Leonard Tue, 01/15/2013 - 07:32 (reply to STEFAN CHRISTEN)

Stefan,

Regarding CSCtt38270 - you are right that this bug is not open, so it won't get fixed unless something changes.  For this bug to get fixed, the following will need to occur:

  • there must exist a customer who is determined to use PSK
  • this customer must have a TAC case open
  • the TAC engineer must reopen the bug
  • the customer must be willing and able to reproduce the bug, and to collect over-the-air traces, debugs, logs, etc., and to run test code from engineering as needed

Regarding the impact of enabling continuous scan on battery life ... we haven't quantified this.  I guess I would say, "some impact, but it's not devastating".

Regarding the above recommendations being included in the DG - I don't believe there are any plans per se.

Best,

Aaron

migilles Tue, 01/15/2013 - 08:07 (reply to Aaron Leonard)

Aaron, in response to your comment below, if you believe there are items listed here that are not listed in the 792x Deployment Guides, ping me offline and we can discuss further where I can provide necessary page #s.

"Regarding the above recommendations being included in the DG - I don't believe there are any plans per se."

migilles Tue, 01/15/2013 - 08:05 (reply to STEFAN CHRISTEN)

All of this stuff is currently already listed in my 792xG Deployment Guides as this is where most of the content for this doc originated.

But is not in list format like this per se as this list touches on different sections of the guide providing highlights.

For #1, this is all covered in the guide already.  5 GHz has always been the preferred band for use.

For #2, we always recommend to use our latest code.

For #3, This is a bug on the WLC/AP side and not 792x specific plus we don't list caveats in design guides.  We only list the AP platforms we support, but not per se the operation mode (e.g. local or HREAP) as we qualify the radio only and what happens upstream once it hits the AP is out of the phone's hands.

For #4, WPA2+CCKM is definitely the preferred security type.  But we support various methods and up to the admin to select what suits them best.  As mentioned above, we don't list caveats in the design guide.  See below for more on CSCtt38370.

For #5, this is all covered in the guide currently.  But is not just as simple as enabling 6 Mbps for all deployments.  See below for more info.

For #6, it is currently stated to enable continuous scan mode if frequent roaming occurs or pico cells have been deployed.

For #7, as stated in this bullet, this is all documented in the guide already.

However, a few items are not hard requirements although they seem to indicate as such in this document.

1)  "Never PSK" is a bit harsh.  There are definitely scenarios where PSK can be used.  But if frequent roaming occurs, then obviously WPA2+CCKM utilizing PEAP or EAP-FAST is the recommendation.

2)  "Always 6 Mbps" is not the common recommendation.  For capacity, throughput and RF footprint reasons, the recommendation is to enable data rates 12 Mbps and higher.  And if the band used by 792x clients is for only voice applications, then could potentially disable 36-54 as there is no capacity or throughput gain.  But if data, video or other applications are utilizing the same band which can take advantage of the higher data rates, then by all means enable those rates.  As far as enabling 6 Mbps goes, you may want to enable this in an environment where mutlipath is inevitable or where you need max range on 5 GHz.  But as mentioned, enabling 6 Mbps is NOT the norm.

As or CSCtt38270, yes this is currently in U state as we have been unable to reproduce this in our labs.

We have had a couple of customers that have had issues with PSK, but once we have engaged, they have either switched over to CCKM or are unable to reproduce the issues any longer.

If you have a customer facing issues with PSK, please open a TAC case, where the TAC engineer can then engage the DE team to assist.  We have a special debug image available that we would need to get logs from in order to pursue further on this if there is truly an issue.

BTW, PSK is definitely NOT the preferred security type for large deployments.  As mentioned above, WPA2+CCKM utilizing PEAP or EAP-FAST is preferred.

PSK is for personal or home deployments; not enterprise grade like WPA2+CCKM.

FYI, you can utilize the WLANDefault.xml generated by the BDU for 802.1x deployments as well if you wanted all phones to have the same username & password.  If you want all phones to have unique accounts for better device management, that is also an option via the BDU, where you choose the Bulk export method vs Default export method, where you will be prompted to upload a CSV file containing the phone MAC and associated username and password to use for that phone.  The bulk method will generate files including the MAC address that can be uploaded to the TFTP server the same way as the default file.

As far as idle battery life when continuous scan mode is enabled, it is minimal (maybe around 10-15%).

Should sitll last for days depending on talk time, but definitely enough to cover an 8 hour work shift.

Continuous scan mode has no impact when on call as the 792x phone is already scanning all the time.

ryan.rose@wwt.com Wed, 01/16/2013 - 09:15

Aaron,

Has firmware 1.4.3 been submitted for FIPS approval yet?  As you may know, until this is done and approved, this is going to be a challenge in the Federal Government.

migilles Wed, 01/16/2013 - 10:02 (reply to ryan.rose@wwt.com)

There is no plan to submit 1.4(3) for FIPS approval at this time.

Believe the last version submitted and currently approved is 1.4(1).

We did submit a diff of all fixes that went in between 1.4(1) and 1.4(3)SR1 to inquire about getting approval.

I will follow up on this.

Can you have your assigned Cisco Account SE reach out to the BU product manager and myself to discuss this matter further?

Thanks.

George Stefanick Mon, 01/21/2013 - 13:32

I have to be honest here. I have issues with these comments.

1. PSK is starting to be the more preferred means of security because large enterprises don't want 1 single AD account on all phones and they dont want individual AD account on phones because of the amount of time to takes to manage these accounts through RMAs and deployment.

This talk about going to EAP is poop. Sounds more like "we have a issue, but since we really cant figure it out lets just say you should be using EAP". Lets not kid ourselves PSK is very secure if you manage the KEY properly.

Regarding CSCtt38270 - you are right that this bug is not open, so it won't get fixed unless something changes.  For this bug to get fixed, the following will need to occur:

  • there must exist a customer who is determined to use PSK
  • this customer must have a TAC case open
  • the TAC engineer must reopen the bug
  • the customer must be willing and able to reproduce the bug, and to collect over-the-air traces, debugs, logs, etc., and to run test code from engineering as needed

2. I have thousands of phones and we are starting our upgrade next week. I have to say Im worried. Im very worried. My organization has spent millions as a customer of Cisco I shouldnt feel this way.

I am one of many orgs that have more cisco phones then the population of some small towns.

I think its very poor for this to be communicated in this manner.

Sorry - I have nothing but love for ya .. but this is poop just my 2 cents

migilles Mon, 01/21/2013 - 14:41 (reply to George Stefanick)

WPA2+CCKM has been a recommended security type for enterprise deployments ever since the 7921 started to ship in January 2007.

Even with the 1st gen 7920, the recommendation was WPA+CCKM; once CCKM was added.

PSK is primarily for home or small/business deployments, which is why  PSK is also   referred to as WPA/WPA2 Personal and why 802.1x methods  are called WPA/WPA2   Enterprise.

I have spoken to many customers around the world over many years with   enterprise deployoments where users are roaming frequently and almost   all of them have implemented CCKM.

And the reason for recommending WPA2+CCKM is to take advantage of the seamless roaming via CCKM and not per se from a security perspective.

This should not come as a surprise to anyone.

However, we are not saying that PSK is not secure, but it definitely doesn't have the additional security level of potentially having unique 802.1x accounts per device, where an account can be revoked as necessary preventing that device from accessing the network.

Sure you could enable MAC based authentication, but that is pretty much considered as legacy security; plus would need to either manage the lists ont the WLC, AP or RADIUS were the list is stored anyways as with 802.1x.

So why not go with WPA2+CCKM which offers better seamless roaming and less chance of a packet exchange during a roam (less packets exchanged).

There are certainly deployment types that should go with PSK vs WPA2+CCKM, hence my reply in regards to the "Never PSK" comment in the thread above.

1)  "Never PSK" is a bit harsh.  There are definitely scenarios where  PSK can be used.  But if frequent roaming occurs, then obviously  WPA2+CCKM utilizing PEAP or EAP-FAST is the recommendation.

Customers may go with PSK if they do not want to manage or purchase a RADIUS server, or the size of the deployment doesn't warrant it. 

However local radius is an option in the Cisco WLAN Controller and Cisco Autonomous AP, so that is an option for the smaller deployments.

Or maybe even a slim chance that the deployed AP doesn't support WPA/WPA2 Enterprise methods.

As for CSCtt38270, there were some customers encountering some intermittent roaming gaps and it seemed that it may have been due to an interop issue with the 792x and PSK.  After design review and the need for a quick solution, some customers decided to move to WPA2+CCKM, which is better for highly mobile users; less voice gap during roaming as there is no need to redo the key handshake.  With CCKM, just a reassociation request and reassociation response; less than 100 ms voice gap, typically 50-80 ms.

So in some situations, it was a win-win, where the issue faced was resolved and using a feature eliminates the need for re-keying, therefore diminishes the chance of any frame during the key exchange to fail to get to the other end and avoid any EAP timeouts, etc.

In other situations, the issue with PSK was not reproducible.

So what Aaron stated, is spot on.

Since we can't reproduce this in Cisco labs, we would more than likely need to rely on the customer deployment to troubleshoot any issues related to this.

And to get to the BU, TAC must escalate to the BU; therefore the need for a TAC case.

And of course, we would need the traces/logs capturing the issue to get to any root cause.

If you have a customer impacted by an issue, then please raise a TAC case.

Sometimes, there are  things in the wireless world that are just seen at a single location and not reproducible in labs or other deployments.

WLAN is much more complex and has many more influences than a wired solution.

Hope this helps!

If should you have any further concerns, please provide some detailed info about your concern and we will be happy to help.

George Stefanick Mon, 01/21/2013 - 15:55 (reply to migilles)

I appreciate the quick response as always.

Understand I'm not trying to bust your chops, you and Aaron have my full respect and attention. But something needs to be said if we think making accounts for each device or one account for all phones is the answer to this problem. Let me be frank and tell you as a wifi engineer managing thousands of phones it is not the answer.

Large customers are now looking at PSK and moving to PSK because of the amount of management and excess overhead it requires to manage AD accounts. In fact in the last 12 months I have personally spoken to 3 other very large Cisco customers with thousands of phones (most Im sure you know) who they themselves are moving to PSK. (One of which actually contacted me about my thoughts about this thread because they are in the middle of their EAP to PSK conversion). One customer in fact has 4,000 AD accounts for phones, but they can only account for 3,000 phones. Over the years as phones were replaced due to RMA and other means they were never deleted because of the management burden.

As for the recommendation -- I read the deployment guides and I dont recall any of the guides stating "Cisco Recommendation." Rather it states, if you are deploying 802.1X, it is recomended to use CCKM.

My point is this. WPA(2) PSK is by far a better choice of roaming on phones. Is it not? It negates the new of a MSK key, PMK Key, radius servers, AD accounts and the over head associated with the management of the radius accounts. Clearly PSK shouldn't be deployed on all devices. But there are means and ways to deploy Cisco phones with a PSK in a secure manner for example with Wavelink whereby the PSK key is protected from end users.

My organization is moving our thousands of phones away from EAP for the very reasons noted above.

I have an upgrade plan for next week to SR1 and I sure hope we dont get hit with this bug as most of our phones are WPA2/PSK. It is comforting to know <I think, that you can not reproduce the problem>. Im opening a TAC case tomorrow, perhaps you can grab it and we can discuss further.

migilles Mon, 01/21/2013 - 17:18 (reply to George Stefanick)

We are simply promoting use of CCKM for enterprise deployments where frequent roaming occurs.

As you are aware, CCKM requires an 802.1x account, but this doesn't mean you have to have an account for each device. 

We have 792x customers using the traditional method where each device has its own account and we have customers where they have a single account for all devices.

And in the unique account scenarios (e.g. healthcare & retail), the accounts would be IT managed with complex passwords.

Per your comments, it appears that you appear to fall into the category of "not wanting to manage a RADIUS server" as outlined in my previous statement.

Customers may go with PSK if they do not want to manage or purchase a  RADIUS server, or the size of the deployment doesn't warrant it. 

We have the Cisco Bulk Deployment Utility (BDU) available, which can help deploy common or unique credentials easily.  Can reference a CSV file containing MAC address, username & password to create unique templates.

It doesn't support certs, but doesn't appear that EAP-TLS or PEAP with server validation is a concern for you.

FYI, PSK is NOT a better choice than CCKM in regards to roaming performance.

As mentioned, CCKM is 2 frames, where PSK has those 2 frames plus the 4-way and 2-way for the key exchange, therefore more time off-network and creating a larger audio gap during the roaming event.

PSK is simply a secure method that is easy to deploy.

If the pre-shared key is compromised, then any device can access the network.

Where as if you use unique accounts, you can disable an account on a 1 by 1 basis as needed vs having to change the key for the entire network.

Anyways, not trying to push WPA2+CCKM on you.

Simply stating that it is the preferred security method for enterprise deployments where frequent roaming occurs.

FYI, I am the author of the Cisco WLAN Endpoint Deployment Guides (792x, 9971, Cius).

Yes, definitely should enable CCKM if using 802.1x to avoid doing  the full EAP handshake for each roam; not only to take that load off of  the RADIUS but to also decrease roam times (reduce voice gaps while  roaming).

I will add some more verbiage in the Roaming and CCKM  sections in the guide to make it clear that CCKM is the recommended  deployment model for enterprise deployments where frequent roaming  occurs.

If you are currently using 1.4(2) or later and not encountering any issues with PSK, then you should not encounter any issues with 1.4(3)SR1.

If you do encounter any issues, simply open a TAC case for assistance.

FYI I am not a member of Cisco TAC, but the folks that are including Aaron know how to contact me if necessary (i.e. there is an issue requiring BU assistance).

Darren Ramsey Tue, 05/14/2013 - 21:06 (reply to George Stefanick)

Going to agree with George on this one, PSK should work correctly.

We are a Cisco shop utilizing Catalyst 3/4/6K, Nexus, UCS, MDS, ONS, ASA, CUCM and over the years had more cases with Wireless than all the others platforms combined. I would classify us as a medium sized healthcare system (6000+ employees and around 1000 beds) and have always used PSK for 792x and Vocera. Sure we could use PEAP/Radius like we do with our laptops/tablets/carts etc, but PSK is just easier for phones and our key is protected. Been running Aironet since 2002 and WLC since just after the Airespace acquisition and have found plenty of bugs for the WBU over the years, (GLBP compatibility and several 7.4 SSO bugs to name a few) and have wasted more than our fair share of time playing the "convince TAC we really have a problem so that we might escalate this to WBU" game.

So if Cisco knows there is a problem with 792x/PSK and has not fixed it, then I'll call that out as blatant negligence around a device that is used to provide patient care and improve life safety in our environment. It's not like we are using Aruba and 7921, or WLC and Spectralink, we are using Cisco on Cisco...So dust off the gear used for the useless AssureWave program, run some debugs and find and fix the darn bug. Show us some value for being a loyal Cisco customer and using Cisco for both WLC and VoWLAN.

migilles Tue, 05/14/2013 - 21:28 (reply to Darren Ramsey)

Hello Darren.

We appreciate your comments on this matter.

Are you responding to this post because you have users that are currently experiencing issues with their 792x phones when using PSK?

For CSCtt38270, the due diligence has been performed by our BU and unfortunately this rare issue falls into the small bucket which can not be resolved on the 7925 platform. 

This issue is specific to the 7925G & 7925G-EX platforms when using PSK; does not exist with the 7921G or 7926G platforms.  This issue is also not Cisco AP specific.

Originally this thread was worded in a way where it sounded like this issue occurs very frequently / for every roam if using PSK, but that is definitely not the case!  I can personally attest to that as I have performed 1000s of roams in our lab environments with our 7925 phones using PSK and have been unable to reproduce the issue.

This issue is very rare indeed!

But if this issue does occur, then worse case is there could be a 1 second gap if on call assuming that the default EAP settings are used. 

With PSK, EAPOL data retries could potentially occur in regular scenarios even when the CSCtt38270 signature is not matched.

As per my 7925G Deployment Guide, if using PSK it is recommended to reduce the EAPOL key timeout from 1000 ms (default) to 400 ms and increase the EAPOL key max retries from 2 (default) to 4 on the Cisco WLAN Controller.

Please refer to the details outlined in the bug for more info.

Also FYI, the WLAN endpoints such as 792x, 9971, DX650 are from the Telepresence and IP Phone BU.

The Wireless Networking BU is responsible for the wireless infrastructure (APs, WLAN Controllers, etc.) who we work very closely with.

Thank you.

Aaron Leonard Wed, 01/23/2013 - 07:49 (reply to George Stefanick)

Hi George,

Regarding this:

"Large customers are now looking at PSK and moving to PSK because of the  amount of management and excess overhead it requires to manage AD  accounts. In fact in the last 12 months I have personally spoken to 3  other very large Cisco customers with thousands of phones (most Im sure  you know) who they themselves are moving to PSK."

There is certainly no requirement that, just because you're using WPA2-Enterprise, your user credentials have to reside in AD.  Certainly if your security model is that each phone has to have unique credentials, then it makes sense to have AD be your identity store.  (But then, if that's your security model, you couldn't possibly use PSK!)

The simplest method for deploying WPA2-Enterprise as recommended with the 792x phones, is to configure the WLC as the local EAP authentication server for the voice WLAN.  The WLC does a good job of handling EAP-FAST or PEAP authentications for the phones, in large deployments.  (In very large deployments, it is a good idea to tune the "advanced eap" and client exclusion settings, so that 802.1X exclusion kicks in if needed, so that you can effectively perform admission control after a widespread outage ... [note to self: document this in a tech tip].)

All that said ... I agree that WPA2/PSK should work well.  If we have a large deployment that is moving to PSK, then let's make sure that it does work well ... if you should encounter the CSCtt38270 syndrome, then be sure to open a TAC case, and we'll work with the BU to get this resolved.  (It may well involve extensive debugging on the WLCs, APs, and in the phones, with coordinated over the air sniffs, and will likely involve running test firwmare on the phones.)

Aaron

migilles Wed, 01/23/2013 - 07:56 (reply to Aaron Leonard)

Yeah I think local radius feature in the Cisco WLC would be fine for smaller deployments, but for larger 802.1x deployments, one would want to go with Cisco ACS as that is a central storage point, which can get replicated to other servers (i.e. don't have to worry about entering the accounts into every WLC).

As far as CSCtt38270 goes, I have just reopened this as this is under further investigation currently.

It would no't be resolved before 1.4(4) goes out though.

As Aaron mentioned, if using PSK, you would want to decrease the EAPOL key timeout from 1000 ms to 400 ms and increase the # of retries from 2 to 4 as outlined in the 7925 Deployment Guide.

George Stefanick Wed, 01/23/2013 - 08:41 (reply to migilles)

Thank you ..

All good discussion around a very important topic that impacts a lot of us. I think someone coming across this tread can learn from the various input.

Migilles thank you for considering the reopening of the bug.

migilles Sun, 02/17/2013 - 07:35 (reply to migilles)

It was thought that a customer was encountering CSCtt38270, therefore it was reopened, but after further investigation it appears that there are other issues (design and config) that are attributing to voice gaps.

This is currently in I state but it could very well be put back in U state.

scott.stapleton Sat, 02/16/2013 - 20:34

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.

migilles Sun, 02/17/2013 - 07:47 (reply to scott.stapleton)

Server Validation (requiring root CA cert on client) with PEAPe is optional.

This is simply to prevent communicating with a rogue RADIUS sever.

Currently certificates must be installed through the 792x phone's web interface.

The CSR for a client cert must be run from the 792x phone's web interface.

The manufacturing certificate (MIC) is pre-installed which can be used as the client cert for EAP-TLS.

The CA chain that signed the MIC is also pre-installed and can be exported to enable in the trust list go the RADIUS server.

The PSK or password can not be exported from flash.

A template containing the network profile config can be exported but an encryption key must be specified where that template will be encrypted and can only be imported to another 792x phone.

Also if production 802.1x accounts are being deleted intentionally or accidentally then there are bigger issues in play.

muranskycotech Thu, 03/21/2013 - 14:18

I'm a little more interested in the 2.4Ghz information, since I currently don't have the luxury of dual-band APs. I'm pretty extensively Aironet 1242G APs at this point with plans to implement (at least) 1262AGN APs next year.

What guidance should be considered in that scenario?

Darren Ramsey Tue, 05/14/2013 - 21:44 (reply to migilles)

Thanks for the quick reply. Not sure if we have seen the issue as our customer base (nurses) would likely just complain amongst one another and drive on rather than calling in a ticket to the help desk. We are around 80% 7921 and as they are retired/replaced with 7925 over time, I could see the probability of the condition increasing.

Didn't mean to give you a hard time,  but still waiting on a stable 7.4 to run on 4 WLC HA-SKUs that have been sitting idle since purchased in January. 7.0.x has been very stable for us and just don't need any trouble with PSK right now nor 7.4/7.5 bugs....

Actions

Login or Register to take actions

This Document

Posted September 7, 2012 at 5:22 PM
Stats:
Comments:29 Avg. Rating:4.9
Views:15031 Contributors:13
Shares:0
Tags: No tags.

Documents Leaderboard