Pages

Sunday, April 17, 2011

Cisco WLC 7.0.116.0 New Features

Cisco just released wireless LAN controller code version 7.0.116.0, which includes a laundry list of new features. Many of these new features have been in development for quite some time, and both partners and customers have been anxiously awaiting several.

Visit Cisco's website to see the full release notes for this code version.

Here are some of the notable new features and what they will mean for customers:
  • WIPS Enhanced Local Mode
    This feature places a subset of Adaptive WIPS capabilities into access points operating in Local or H-REAP modes. Traditionally, Cisco aWIPS required Monitor mode APs. Now customers can get most of the benefits of an in-depth aWIPS deployment with the same access points that service client connections, without having to spend additional money on dedicated monitor APs. The solution still requires the WCS and MSE platforms, but can reduce CapEx and OpEx costs for customers. It is designed primarily for retail customers with distributed branch offices needing to maintain PCI compliance in the face of expanding mobile retail initiatives.

    By my count, ELM supports detection of 35 of 48 attacks available in the full aWIPS solution (~73%). The majority of missing attack detections are comprised of some RF DoS and Zero-Day attack detection capabilities, which are arguably not the most severe attacks (DoS) and are notoriously hard to baseline against false-positives / negatives (Zero-Day).

    Additionally, the focus of ELM attack detection is on the current operating channel of the AP, and has limited visibility into off-channel attacks through RRM off-channel scanning. This makes sense since the network infrastructure is performing double-duty serving clients and detecting attacks. This should not be an issue for larger network deployments with multiple APs covering most or all of the available channels. For smaller installations, this could present a serious problem however, and reduce effectiveness of the solution. However, this solution is arguably aimed at the larger retail deployments where the expense of deploying dedicated Monitor mode APs has been a problem.

    All in all, larger customers should take a look, while smaller customers will probably opt for a dedicated WIPS solution.

  • H-REAP Fault Tolerance
    Cisco has been improving Hybrid REAP mode functionality in leaps and bounds in order to compete in distributed WLAN architecture scenarios, with the likes of Aerohive's Cooperative Control, Aruba's Instant virtual controller, Motorola's Adaptive APs, etc.

    H-REAP fault tolerance improves operation by removing the requirement for H-REAP mode APs to reboot when moving from standalone back to a connected state. Previously, H-REAP APs move into standalone mode without affecting locally-switched clients, but when re-joining a controller they were required to reboot and download a complete configuration which caused a service disruption during the fail-back process. Now the AP is able re-join the controller without impacting client service or rebooting, assuming it can verify the configuration matches.

    In addition, H-REAP WAN latency may now exceed 100ms (upwards of 2 seconds) provided customers use H-REAP Local Authentication of clients using the internal user list pushed to the access points.

  • H-REAP Opportunistic Key Caching (OKC)
    Previously, H-REAP access points only supported CCKM key caching for fast roaming. Now it supports both CCKM and OKC, which should provide much broader support for fast roaming with many more clients in typical customer environments. Note that both CCKM and OKC still require the 802.1x/EAP key derivation to be completed through the controller. Any keys derived while the H-REAP AP is in standalone mode (disconnected) will not support fast roaming between multiple APs.

    I will also be awaiting 802.11r Fast BSS Transition support in H-REAP APs once broader market support and adoption are achieved through the Wi-Fi Alliance Voice Enterprise Certification (due out in 2011).

  • Cisco Identity Services Engine (ISE) Support
    Cisco's next-generation ISE product provides context based access controls and integrates several services into a cohesive platform, including the Cisco Secure ACS authentication and Network Admission Control (NAC / Clean Access) products. This platform enables organizations to enforce network access policies based on a combination of user and device identity, and will be integrated into wireless, switch, and router platforms with software updates.

    ISE addresses customer needs for granular access control beyond VLANs and IP subnet policies, acknowledging the need for deeper insight into the context of the client session to drive policy enforcement. A common scenario for this today might be differential network and application access based on user and device, differentiating access by an employee on a laptop versus an iPad. ISE is part of the Cisco TrustSec solution.

  • VLAN Select
    This feature enables pooling of multiple VLANs into a group for assignment to a single WLAN SSID or AP Group. Large wireless installations have traditionally required a single large subnet and broadcast domain to accommodate the number of wireless clients on a single SSID, dynamic VLAN assignment, or the use of multiple SSIDs which can introduce roaming latency and problems. VLAN Select allows client connections to a single SSID to be round-robin load-balanced into multiple network VLANs to reduce subnet size and broadcast / multicast forwarding concerns.

    Another use-case for VLAN Select is with guest termination in a DMZ environment. Large guest networks also traditionally required large subnets or multiple anchor controllers to segment the client population into smaller broadcast domains. This resulted in additional CapEx to buy more anchor controllers, since a single anchor controller could only use a single VLAN attached to a WLAN. Now, multiple VLANs can be tied to the same WLAN through VLAN Select, reducing the need for multiple anchor controllers.
I have update my post on H-REAP Deployment Guidelines and Feature Limitations to include these new enhancements, as well as a few others including security feature integration with Cisco switches. It's worth a read to review the current state of H-REAP functionality and limitations with the new 7.0.116.0 code release.

Cheers,
Andrew

40 comments:

  1. Cool update sir- keep them coming...

    ReplyDelete
  2. boo, i didn't receive anything from the cisco notification service about this.

    ReplyDelete
  3. Brian,
    Did you just add the notification profile into your account? If so, it may take some time to become Active. It may show a status of "Pending" for a little while.

    Andrew

    ReplyDelete
  4. yeah i actually signed up for it a couple of months ago and forgot about it until your blog post the other day. oh well, thats why i pay attention to blogs too!

    ReplyDelete
  5. Thanks for this info, Andrew.

    In regards to the ISE integration... My company has been giving close consideration to purchasing NACs to install with our WLC clusters deployed in 9 locations around the country (and possibly more in down the road). Am I understanding correctly that this ISE integration will give WLCs the ability to perform compliance enforcement, which would eliminate the need for a separate NAC appliance? Or is this just wishful thinking?

    -Rob

    ReplyDelete
  6. Hi Rob,
    It is my understanding that the ISE solution will replace the current NAC (Clean Access) product portfolio. So you may want to contact your local Cisco account team to get more detail on the recommended path for your upcoming project.

    I am not positive on all the details yet, I am awaiting technical details from my Cisco team as well.

    Andrew

    ReplyDelete
  7. Great post Andrew, in a large university environment VLAN select option will come in very handy as it will reduce our broadcast domain and allow room for more subnets to be added only to WLANs that need it.

    ReplyDelete
  8. Andrew,

    Why is a large subnet for wireless clients a problem? I know typically you don't want more than 512 hosts on a subnet, but doesn't the WLC convert all client broadcasts to unicast?

    Steven

    ReplyDelete
  9. Hi Steven,
    Large subnets are still a concern in enterprise networks for a few reasons.

    First, the WLC does not convert broadcasts to unicast. Broadcast and multicast challenge are notoriously difficult to achieve adequate performance without careful WLAN design. This is because they are only sent once over the air and there is no guarantee or acknowledgment by clients that the transmission was received. There are some exceptions to this for multicast traffic such as Cisco's VideoStream and Aruba's Dynamic Multicast Optimization, where they can be converted to unicast. However, broadcasts are never converted.

    Another huge issue is RF performance and channel utilization. Since wireless is a shared medium, more broadcast traffic will result in more overhead on the network, higher channel utilization, and degrade performance for everyone on that frequency. This is definitely an issue with large wireless subnets.

    Another concern is the volume of client to client traffic if peer-to-peer blocking is disabled, especially as we continue to see more and more P2P apps proliferate, poorly written apps, chatty broadcast apps designed for consumers *ahem Apple*, and easier proliferation of viruses/worms.

    Because of these reasons, it is recommended to keep wireless subnet size within reason based on the applications in use in your environment. Additionally, many vendors now offer broadcast traffic filtering to prevent broadcast and multicast traffic from being sent over the air. Cisco WLCs do this by default because they implement Proxy ARP and DHCP (the only broadcast traffic most clients require to function).

    Cheers,
    Andrew

    ReplyDelete
  10. Hi Andrew,

    Very interesting post - thank you. Got a question re "Cisco WLCs do this by default because they implement Proxy ARP and DHCP" - is this documented by Cisco anywhere?

    ReplyDelete
  11. Wondering why there's no mention by Cisco of overall support for OKC for APs in local mode???

    ReplyDelete
  12. Hi Johnny,
    Cisco has supported OKC with Local mode APs for a long time. It's not a new feature in 7.0.116.0 code.

    Andrew

    ReplyDelete
  13. Ah, got it. OKC = PMK Caching in Cisco speak.

    ReplyDelete
  14. Johnny,
    Not quite...

    PMK Caching - client caches the PMK established with each individual AP. The client must have already auth'd to that specific AP to create the cache for future instances where it roams back to it.

    PKC/OKC - Proactive Key Caching or Opportunistic Key Caching is where the PMK is cached at the controller (or a central point) and is slightly modified using known variable for all controller APs (using each AP radio BSSID). Therefore, both the client and the controller can determine a unique PMK cache entry for each AP the client can roam to. A single PMK is established on any 1 AP and then dynamically distributed to individual APs as the client roams to them.

    WLC code 7.0.116.0 extended support for PKC/OKC to H-REAP APs. It was previously supported for Local mode APs only.

    Also, H-REAP already supported CCKM fast roaming too.

    Hope this helps,
    Andrew

    ReplyDelete
  15. Hi Andrew,

    As i heard LWAP doesn't support multiple vlans to multiple SSIDs, so is that fixed on new version? because right now im using 2 different ssids for 2 vlans, going to deploy 4402 and LWAPs replacing current Auton APs. Can ask you few questions related with this issue by chatting?

    ReplyDelete
  16. Hi Tulga,
    I think what you meant to say was WLCs don't support multiple VLANs assigned to a single SSID. That was correct previously, but WLC code version 7.0.116.0 now supports a feature called VLAN Select which allows definition of interface groups. By assigning an interface group to an SSID, the clients will then be round-robin load-balanced into multiple VLANs.

    Cheers,
    Andrew

    ReplyDelete
  17. Andrew,

    Thanks, on WLC possible to manage time restriction on SSID?

    ReplyDelete
  18. Hi Tulga,
    No, Cisco does not provide time restrictions on SSIDs in the WLC. However, a workaround is available in WCS to apply configuration templates to WLCs at specific times.

    Andrew

    ReplyDelete
  19. Hi Andrew,

    A very nice post.

    Just back to the topic about the "WLCs don't support multiple VLANs assigned to a single SSID".
    Actually we can achieve this even in verion 7.0.98.0.
    we setup different AP groups and use the WLANs SSID overwrite to achievement.
    From the other hand we also use the AAA overwrite to achieve that.

    Cheers,

    Edward

    ReplyDelete
  20. Hi Edward,
    Yes, you are correct with AP Groups and Dynamic VLAN Assignment. However, VLAN Select is solving a distinctly different problem, one in which we don't care what VLANs specific clients are placed into, just that the broadcast domain is not large and split up amongst several VLANs.

    AP Groups can also achieve this, as you stated. But that does not consider the Anchor controller case where the WLC is not controlling APs. VLAN Select provides a solution, and arguably does it in a simpler fashion than AP Groups for Local controllers too.

    Dynamic VLAN Assignment is completely different, and assigns different user groups to VLANs based on policy definitions attached to those users. It cannot really solve for situations where we need to seperate users in the same group, or we don't have or care about user group definitions.

    As always, there are always many ways to skin the cat. VLAN Select gives us a great tool for Anchor controllers and an arguably better tool for Local controllers than what exists today.

    Cheers,
    Andrew

    ReplyDelete
  21. Hi Andrew,

    Thank you kindly for your information.

    May I have one more question about the VLAN Select:
    Is there any potential DHCP black hole in the VLAN Select?

    Like if you put 3 different subnets into one group interface, if one of their dhcp ip pool is full. As WLC is running round-robin load-balanced.
    How does the WLC know that special vlan DHCP pool is full and avoid it?

    Cheers,

    Edward

    ReplyDelete
  22. When backing up the controller (WLC 4404) configuration to a TFTP server, does the controller require a reboot?

    ReplyDelete
    Replies
    1. No known system ever has required a reboot after backing up configurations and if they did the product should be kilt.

      Delete
  23. Hi Edward,
    If the VLANs are only wireless, then they should be utilized at the same rate and one should not get full without the others being in the same situation.

    There are a few cases where this would not be true, if wired clients shared the same VLANs or if DHCP lease times are different between VLANs.

    I'm not sure if the WLC can monitor DHCP responses or lack thereof and re-assign users to another VLAN. That is an interesting question that I will have to follow-up on.

    Thanks,
    Andrew

    ReplyDelete
  24. Hi,
    Backing up the WLC config does not require a reboot. Restoring or importing a config does, however.

    Andrew

    ReplyDelete
  25. Andrew,
    Is there any way to support DHCP reservations with VLAN Select? In my environment, we have devices that need stable IP addresses, so we are using reservations, but I'm seeing issues with the round robin dhcp assignments. The reserved address isn't mapped to the correct VLAN.

    ReplyDelete
  26. Hi Tom,
    In order to support DHCP reservations with VLAN Select, you will need to use Dynamic VLAN or WLC Interface assignment by the AAA RADIUS server. You have to assign a specific interface, not the interface group.

    See this link:
    http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080b78900.shtml#topic1

    Cheers,
    Andrew

    ReplyDelete
  27. tftp upgarding to this version fails after 82%.

    following error comes. pls suggest.



    Connection received from 10.113.9.250 on port 7705 [24/02 15:31:32.381]
    Read request for file <\/AIR-WLC4400-K9-7-0-116-0.aes>. Mode octet [24/02 15:31:32.381]
    Using local port 1888 [24/02 15:31:32.381]
    File <\AIR-WLC4400-K9-7-0-116-0.aes> : error 10054 in system call recv An existing connection was forcibly closed by the remote host. [24/02 15:32:23.100]

    ReplyDelete
  28. You should call TAC for assistance with upgrade issues.

    ReplyDelete
  29. hi everyone,

    Can someone tell about the roles of Interface groups and Multicast Vlan Feature in WLC 7.0.116?
    Secondly, how can i disable/block services according to AP Groups?

    ReplyDelete
    Replies
    1. Interface groups are useful so that one SSID can support multiple VLANs without using AAA override. It will round-robin load balance clients between multiple VLANs.

      I'm not sure it's possible to block services between AP Groups. They only define VLAN to SSID mappings and SSIDs that are advertised for users (replacing the older WLAN Override settings in individual AP configurations).

      Andrew

      Delete
  30. Hi, I used it to contain MultiCast in a specific VLAN. Very convenient when using VLAN Select and when you want to support AppleTV (to perform presentations wirelessly).

    ReplyDelete
    Replies
    1. Hi Paul,
      Yes, Cisco VLAN Select allows a single source VLAN for multicast. The problem with that is that all multicast must originate from that single VLAN, which limits applicability. With Bonjour services, for example, it would require all AirPrint printers, AirPlay AppleTVs / MacBooks / Airport Express units to be in that one VLAN. That's not realistic in a layer 3 enterprise network with printers and projectors scattered throughout the network. Also, AirDrop can't be used for client to client file sharing. It also doesn't support wired client subnets, so printers that are plugged into Ethernet won't work (which is probably the most common connection method for printers). It also can't filter Bonjour services by service type.

      Overall, it's a multicast hack that has limited applications in my opinion.

      Andrew

      Delete
  31. Hi Andrew,

    First up, a fantastic write-up!

    Is there a way we can bind Multiple SSIDs to a single VLAN. I understand Cisco by default deny's doing this as not being a good practice. I have a scenario where same VLAN/Network policy needs to apply to different authentication methods based on different SSIDs.

    Thanks.

    ReplyDelete
    Replies
    1. Yes, in Cisco WLCs simply select the same interface in each SSID.

      Andrew

      Delete
  32. Thanks Andrew. This worked great!! I additionally had to change my VLAN Mappings under flexconnect details to the same VLAN for both SSIDs to make it work.

    Thank you.

    ReplyDelete
  33. Hi Andrew. Can you elaborate on where Sticky Key Caching fits in with PKC/OKC? I know that SKC is beneficial in a intra-controller roaming scenario with Apple devices. It seems that there is limited information SKC though, any thoughts on it?

    ReplyDelete
    Replies
    1. Hi Armando,
      SKC is part of the 802.11i amendment. It essentially provides a method for a client an AP to cache a previous authentication through that individual AP only. The caching does not work across APs. Therefore, the client has to associate and authenticate to each individual AP before the cache can be established. This is not very effective, especially in larger environments. The client and AP also usually only provide support for a limited number of cache entries (for example 8 or 16).

      You can read more here:
      Wi-Fi Roaming Analysis Part 2

      Cheers,
      Andrew

      Delete