VoWLAN HREAP Designs

We're looking to deploy a retail location with VoWLAN using HREAP APs that will talk back to a WiSM. This is the first store, but I'd like to design it so it will scale well in the future should more locations get similar setups down the line.  I'm having trouble coming up with a solid design that I'm happy with.
For VoWLAN Cisco seems to recommend CCKM to allow for faster roams, which from what I read it looks like it is only supported in HREAP when using HREAP Groups. I started looking into HREAP Groups and it appears that there is a limit of 20 groups with 25 aps per group (Is this still the case in the 6.0.196.0 code, or has this number increased?) From a design perspective, many of these future stores may only have one or two APs and there are hundreds of store locations. So I'm having trouble coming up with a logical way to group these in HREAP Groups.
I can't create a group per store because of the limitation on number of groups, and I'm not sure if there are any negative effects of grouping together APs in different stores that clients will never be able to roam between.
I would really like to use some type of user based authentication like EAP-FAST instead of using a PSK because it would give me the ability to kill a device remotely if I needed to rather than update the key on potentially hundreds of devices in the future.
The cost of a controller is too much to justify putting one in a location with only one or two APs, but the HREAP solution doesn't seem to fit when you have a huge number of locations either.
Has anyone done any large scale deployment of HREAP/VoWLAN and what security methods have you used or how did you organize the groups and APs?

Well, you could use FlexConnet like that and all should work fine, for the most part.
For VoWiFi, you need to be careful with roaming.  You can only have so many AP per group.  It will be important to make sure your groupings are correct so that the group can get the PMK if you are doing CCKM/802.1x on the phones.
Other than that....where are the resources going to be that the users will be accessing?
If they are up in the Distribution  or Core, you will still have the traffic flowing to or through there.  So you wouldn't really gain anything by using FlexConnect.
HTH,
Steve
Please remember to rate useful posts, and mark questions as answered

Similar Messages

  • HREAP VLAN Mapping

    /* Style Definitions */
    table.MsoNormalTable
    {mso-style-name:"Table Normal";
    mso-tstyle-rowband-size:0;
    mso-tstyle-colband-size:0;
    mso-style-noshow:yes;
    mso-style-priority:99;
    mso-style-parent:"";
    mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
    mso-para-margin-top:0cm;
    mso-para-margin-right:0cm;
    mso-para-margin-bottom:10.0pt;
    mso-para-margin-left:0cm;
    line-height:115%;
    mso-pagination:widow-orphan;
    font-size:11.0pt;
    font-family:"Calibri","sans-serif";
    mso-ascii-font-family:Calibri;
    mso-ascii-theme-font:minor-latin;
    mso-hansi-font-family:Calibri;
    mso-hansi-theme-font:minor-latin;
    mso-bidi-font-family:"Times New Roman";
    mso-bidi-theme-font:minor-bidi;
    mso-fareast-language:EN-US;}
    Hi,
    I've searched around to see if someone else has experienced the same issue regarding HREAP AP's losing their VLAN mappings; however I could not find any related topics.
    Scenario
    I've got a 5508 WLC running ver 7.0 with local VLANs assigned as follow:
    VLAN 241 - Data Users
    VLAN 253 - Voice Users
    The HREAP AP's (Cisco 1242AG) running at the remote branches is mapped to the following:
    VLAN 2 - Data Users
    VLAN 253 - Voice
    The Problem...
    HREAP works perfect; users get the local DHCP addresses at the branch office and have no issues with connectivity. Once and a while some of the HREAP AP's will lose the VLAN mapping I've assigned to them. In this case I've mapped VLAN 2 to the SSID for the Data Users, I will get complaints that users can't connect to the network when I go check the HREAP AP's VLAN mapping it defaulted back to VLAN 241 (the same VLAN the local AP's at head office use for the same SSID). Of course with the Voice SSID I don't have this problem as it's using the same VLAN ID as head office.
    Once I've corrected the mapping everything works perfect.
    Why...
    I just want to know why this happens, I've rebooted the AP's to see if they retain the mappings and they did. I've seen in the HREAP design deployment that it is preferred to use the same VLAN ID's of the head office where the WLC is located as for the same to the branch offices where the HREAP AP's are located.
    I can see why as this will resolve my problem, however this network was designed without the knowledge of HREAP being deployed to the remote sites and I would like to minimize change from a LAN perspective.
    Will this be my only solution by standardizing the branch office VLAN ID's the same as the head office network or should I be able to use different VLAN ID's for the branch offices?
    Thanks for your time reading this and for your input. If you know any discussion regarding this, please add the url.
    Regards
    Jurgens

    Hi,
    I'm having the same problem. And I have two WLCs (WISM) with 7.0.220 version.
    I think because of this BUG: http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtw92394&from=summary
    Anyone knows how can I solve this problem?
    I Have 42 HREAP APs, and when I have some link problem on the remote Branch and the AP lose for a few seconds Connectivity to the 1º Controller its loses the VLAN Mappings (all turned to the Native VLAN).

  • Slow сlient roaming when HREAP used (local swithing)

    We have standart  wireless deployment with 24 APs (1240G model) and wireless controller 4402-25 placed on same site.
    Most of clients (WMS RF terminals ) works with one  WLAN (WPA2-PSK)  and  constantly roam over warehouse , and that works great.
    But for better survivability(when controller dies) we are trying to configure HREAP on our APs with local swicthed local auth WLAN. And that also work , but client roaming occur much more slowly and RDP connection to WMS APP server sometimes stuck for 2-5 sec.
    Disabling "local switching" checkbox  for WLAN make  roaming almost momental.
    Is that normal behavior ? And slow roaming are price for controllerless  HREAP design ? And for fast roaming and  survivability we must use N+1 wlc?
    I'll be
    appreciate for any opinions
    and comments!

    Local switching should be okay since the AP will be doing the encryp/decrypt when using PSK. How does the traffic flow? Does everything come back to where the wlc sits or not? What I would try to determine is if it's a certain application having issues, a certain device or just overall all devices roam slow.
    Thanks,
    Scott Fella
    Sent from my iPhone

  • H-REAP Mode

    Hi,
    Does anyone know the limitations or guidance for large H-REAP deployments.
    Any Cisco documents on Cisco's recommended quantity of access points per remote site using H-Reap mode in either central or local switching instances, H-group limits, deployment considerations that might sway a design to install local WLC's per remote site and not adopt the centralised approach.
    Potentially six remote sites with 60 - 120 H-REAP access points per site.
    Thanks in advance for your replies.
    Jay

    Hi,
    here is the HREAP Design and Deployment guide which may help you..
    http://www.cisco.com/en/US/products/ps6087/products_tech_note09186a0080736123.shtml
    Also.. its a Good design if we dont go more than 50 APs per site.. huge # of hreaps in one location not only means a
    significant amount of management traffic overhead, its also not a very good design.
    lemme know if this answered your question..
    Regards
    Surendra
    ====
    Please dont forget to rate the posts which answered your question and mark it as answered or was helpfull

  • A VoWLAN Design Guide Rulebook - The Rules (Potentially)

    Hi all,
    I have just been doing some reading from the Cisco web site and would like to summarise what I saw as the important factors in the documentation in reference to some basic guidelines to providing a successful VoWLAN deployment. This is the first time I have looked at the VoWLAN deployment and there are some points I don't fully understand, and maybe some points I have completely missed out. I will need to translate all of these summary points at a later stage to a design document to start looking at a potential VoWLAN design so just thought I'd get a couple of notes down on paper. It may help some other people also, in summarising (I sure hope so, as its nice to share this stuff with you guys - if correct).
    Anyway, if you kind people would take time to read this and maybe comment on it, that would be fantastic. The points started out in order but as I write this and few points at the bottom should be near the top, but I think I need a beer and cant think about re-numbering them at the mo :))
    Opps, the post is above the 4000 chars (I can't have written that much can I) so now have attached it to a word file.
    Pls see attached word doco.
    Guys and girls, would you mind looking at points 5, and points 18. And if anyone could add anything else to this, or correct any of this information (all gleaned from the white-papers) if I have got it wrong, which is quite likely :))
    Many kind regards as always and hope all is well :)
    Ken

    Hi Ken,
    Looks like a great doc so far! I wanted to send you these links to address Point #5;
    VoWLAN Call Capacity
    An important parameter in VoWLAN planning is call capacity-the number of simultaneous VoWLAN calls that can be supported in an area. This value can vary depending upon the RF environment, the VoWLAN handset features, and the WLAN system features. For example, the VoWLAN maximum capacity for a Cisco Unified IP Phone 7921G using a WLAN that provides optimized WLAN services (such as the Cisco Unified Wireless Network), the capacity is expected to be 14 simultaneous VoWLAN calls per 2.4 GHz channel and 20 simultaneous VoWLAN calls per 5 GHz channel. These capacity values are based on assuming no competing high priority WLAN traffic and normal background noise. Note that because the 5 GHz spectrum generally features less noise and interference, there can be greater capacity with the higher carrier frequency implementation. The additional non-overlapping channels available in the 5 GHz spectrum also provides a great deal more call capacity for a given area.
    Note The call capacities are quoted per non-overlapping channel because the channel capacity is the limiting factor-not the number of access points (AP). This is explained in more detail in the following section. The purpose of providing these maximum call capacity figures is general planning purposes. The call capacity specified by the actual VoWLAN handset should be used for deployment since this is the supported capacity of that handset.
    From this excellent VoWLAN SRND doc;
    http://www.cisco.com/en/US/docs/solutions/Enterprise/Mobility/vowlan/41dg/vowlan_ch3.html#wpxref96879
    Choosing Between IEEE 802.11b/g and IEEE 802.11a
    http://www.cisco.com/en/US/docs/solutions/Enterprise/Mobility/vowlan/41dg/vowlan_ch10.html#wp1046004
    Design Principles for Voice Over WLAN
    The 802.11 wireless networking protocol uses a contention-based access algorithm. Based on this access methodology, protocol overhead, bandwidth calculations, and wireless voice network testing, Cisco has determined that with the IEEE's 11-Mbps throughput limitation on 802.11b, a single 802.11b wireless access point can support up approximately to seven active voice streams using the G.711 codec or eight active voice streams using G.729 codec and also handle a reasonable level of data traffic. An active phone session is one carrying on a conversation. A voice client that is associated with an access point and not carrying on a VoIP session (that is, conversation) is not considered active.
    http://www.cisco.com/en/US/solutions/collateral/ns340/ns394/ns348/net_implementation_white_paper0900aecd804f1a46.html
    For Point# 18, I didn't think Cisco Wireless deployments supported 802.11f and actually use a proprietary IAPP Protocol?
    Hope this helps and keep up the great work here!
    Rob

  • Design Tradeoffs with Remote WLC vs HREAP

    Can anyone tell me what the rule of thumb is for deciding whether to place a controller in a remote office or going with HREAP there instead?
    Thanks
    Gene

    As long as your connection between the remote site and the WLC is less than 100ms then you can do HREAP. Else centralized location
    Here are some notes:
    Hybrid REAP Guidelines
    Keep these guidelines in mind when using hybrid REAP:
    •A hybrid-REAP access point can be deployed with either a static IP address or a DHCP address. In the case of DHCP, a DHCP server must be available locally and must be able to provide the IP address for the access point at bootup.
    •Hybrid REAP supports a 500-byte maximum transmission unit (MTU) WAN link at minimum.
    •Roundtrip latency must not exceed 100 milliseconds (ms) between the access point and the controller, and LWAPP control packets must be prioritized over all other traffic.
    •The controller can send multicast packets in the form of unicast or multicast packets to the access point. In hybrid-REAP mode, the access point receives multicast packets only in unicast form.
    •Hybrid REAP supports CCKM full authentication but not CCKM fast roaming.
    •Hybrid REAP supports a 1-1 network address translation (NAT) configuration. It also supports port address translation (PAT) for all features except true multicast. Multicast is supported across NAT boundaries when configured using the Unicast option.
    •VPN, IPSec, L2TP, PPTP, Fortress authentication, and Cranite authentication are supported for locally switched traffic, provided that these security types are accessible locally at the access point.

  • Design Help.... WLCs / HREAP?

    Here is my scenario...
    We have two offices and the each have a WLC 2112 and 1130ag APs.
    SITE A (Main Office):
    1 - WLC 2112
    4 - 1130ag APs
    IP: 192.168.0.x/24 (VLAN1)
    IP: 192.168.100.x/24 (VLAN10)
    VLAN10 is setup for the Guest wireless network using Web Auth and ACLs etc...
    SITE B (Branch Office):
    1 - WLC 2112
    2 - 1130ag APs
    IP: 192.168.1.x/24 (VLAN1)
    SITE A connected to SITE B via Private T1
    Each site also has their own internet...
    Okay, so what I want to do is basically setup each controller to back the other one up in case of a failure at either end.
    I tested HREAP and it worked great except SITE B clients receive an IP address that is on SITE A's network. They could surf the internet but it was going through SITE A's internet etc...
    I can't have that and the clients need to use the internet based out of their location and be assigned an IP from their local network.
    Is there a way to do this?
    Each site obviously had the same SSID which is fine or they can be different. It doesn't matter... I just want to make sure if one of the WLCs go off the air, the other one picks up the APs and the clients do not notice a difference nor do they receive an IP from the site that would be remote to them.
    Also I do not want each site to see the other's SSID if using different SSID's. I only want the SSID to be seen by clients at their respective site. They can use the same SSID and in fact i would like to do that, but not sure if that would work in this scenario.
    If this is unclear, please let me know. i am trying to describe this as best as possible...
    Thanks,
    Ed

    This is what you need to do. First of all, make sure the wlan ssid is set to local switching and that you use the same vlan on both sites. On the ap, I figured you already changed the ap from local to h-reap.... if not, then that is what you hvae to do. Then after the ap reboots and is back up, click on the ap and you will have a tab named h-reap. Click that and check the native vlan. Now the ap will be trunked so you need to make sure the ip of the ap is on a seperate vlan than the ssid's. The vlan the ap belongs to would be configured as native vlan on the trunk. On th eh-reap ap, set the vlan that will be the native vlan. exit out of that screen and go back to the h-reap tab. Now you will see the wlans that you specifed as local switching with a box in which you can specify the local vlan in which the user will get an ip address locally and will reside on. You will also see wlans that will not have the entry box, since you don't have local switching enabled. This means the traffic will tunnel back to the wlc it's joined with. This is why you fail one wlc and the ap goes to the other site... failover works, but users are getting address from the new site, which means you are not locally switched.
    Example
    Site A
    Management/AP Manager vlan 100 (native) 192.168.100.x
    H-REAP AP vlan 100 (native) 192.168.100.x
    * AP can be on a different vlan if you want
    Internal Users vlan 110 192.168.110.x
    Guest Users vlan 120 192.168.120.x
    Site B
    Management/AP Manager vlan 100 (native) 192.168.200.x
    H-REAP AP vlan 100 (native) 192.168.200.x
    * AP can be on a different vlan if you want
    Internal Users vlan 110 192.168.210.x
    Guest Users vlan 120 192.168.220.x

  • Branch Office & HREAP & local Internet breakout

    Hi,
    I´m planning right now a local Guest Access breakout for a Branch Site which is connected over
    a HREAP AP to a centraliced WLC . If I have it correctly understand then  I´ve to do following:
    1. Creat a Guest SSID on the centralized WLC ( 5508 )  / enable local switching for this SSID
    2. Create a Guest VLAN on the Branch Site with a local Internet breakout
    3. Configure a Trunk port for the HREAP AP on the Branch site ( 1 VLAN for  Corportate SSID/ local switching   and 1x VLAN for Guest
    with local Internet breakout )
    Can I use the WLC as DHCP server for the Guest  SSID or should I use a local DHCP server ? I know about a feature
    "central DHCP Processing "  but I never used this before and it is not 100% clear if this can help me in this case.
    Thanks for help.

    Check these docs:
    http://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/81680-hreap-modes.html
    http://www.cisco.com/c/en/us/support/docs/wireless/5500-series-wireless-controllers/71250-h-reap-design-deploy.html
    Regards

  • Ask the Expert: Cisco's 802.11ac Solutions - Deployment, Design, and Interop

    Ask your Questions on Cisco’s 802.11ac Solutions - Deployment, Design, and Interop with Cisco Experts: Richard Hamby and Shankar Ramanathan.
    Monday, March 30th, 2015 to Friday, April 10th, 2015
     Richard Hamby is a senior technical support engineer and Team Lead of the Cisco Technical Assistance Center in Richardson, Texas.  He is an expert in Indoor and Outdoor wireless for the full line of Cisco Unified and Converged Access Wireless products, as well as TAC Engineering Engagement Engineer liaison to project engineering teams for new Cisco wireless products.  Prior to his current role, Richard was a customer support engineer with the AAA Security TAC team supporting Cisco identity management solutions and been with Cisco since 2009.
    Shankar Ramanathan is a Customer Support Engineer at the Cisco Technical Center. He is a Technical Content Engineer and Subject Matter Expert for Cisco Enterprise Unified and Converged Access wireless mobility solution including Wireless LAN Controller  2500/5500/WISM2/7500/8500, Converged access 5760/3650/3850 switches,  Access Points Lightweight and Autonomous, VoWLAN (792x/9971) , Cisco Prime Infrastructure SNMP management, Cisco Mobility Services Engine(MSE/ CMX). Prior to joining Cisco in  November 2011, he worked as a wireless network engineer at Elan Technologies, responsible for RF wireless network planning, simulation, propagation path analysis, and optimization of Wi-Fi 802.11 mesh and WiMax (802.16 d/e) networks for various system  integration and automation projects. Shankar holds a master of science degree in electrical engineering specializing in communications and signal process from the State University of New York, Buffalo. Shankar has a CCIE in Wireless(#40548) and CCNA  certified (number 410004168640IMZF) and has over six years of industry experience.
    Find other  https://supportforums.cisco.com/expert-corner/events.
    **Ratings Encourage Participation! **
    Please be sure to rate the Answers to Questions

    A common question we are asked is 'why is my device not achieving 11ac data rates?'
    One of the most common answers relates to client compatibility/capability. To get the highest possible data rates of 11ac (assuming proper distance and RF health), the AP and the client device must both be capable supporting the requirements - 5GHZ, 80MHz Channel, short guard interval, 3 spatial streams. Each spatial stream has a max of 433.3Mb/s (at 80MHz, short GI).
    The majority of 11ac-capable wireless cards on the market do not support 3 spatial streams. Most adapters in wireless-capable devices are 1SS or 2SS.  For example, the Intel 7260 11ac adapter used in many devices is a 2SS adapter - therefore it's max possible data rate is 866.7.  Another common adapter in use is the 11ac Broadcom 3SS that Apple uses in the newer Macbooks.  These devices can achieve the 1.3GBs PHY data rate.
    This guidance is the same for 11n adapters as well.  To achieve max rate, your 11n AP and adapter must both support 40MHz channels, 3SS, short GI.
    Note: The 11n and 11ac standards both define support for 4SS.  4SS-capable devices are rare, so 3SS is essentially our reality.
    One of the most useful references for questions related to this topic is the AP Data Sheet for each AP.  Here's the AP3700 for example:
    http://www.cisco.com/c/en/us/products/collateral/wireless/3700-series-access-point/data_sheet_c78-729421.html
    Table 1 lists the expected data rate per MCS Index value by #SS at each channel width and GI. Indexes 0-7 are the same for 11n and 11ac (11n limited to 40MHz channels of course).  And MCS 8 & 9 are 11ac-only 256-QAM modulations. 

  • WLC 5508 - WGBs & HREAP on LAN

    So, I really have two questions here.  For some background information, I have a wireless network with two WLC 5508 controllers and 220 LWAPs in the same location as the controllers.  All APs are currently in local mode.  I run a few guest networks as well as some other client networks.  One client in particular uses their network to connect mobile machines to their VLAN.  The only issue is that the machines do not have wireless adapters.  Instead, the manufacturer put inside the chassis, a D-Link WGB, which has an ethernet cable, you then have to plug into the ethernet port.  These devices cannot seem to connect to the network.  I have found, the WGBs do associate on the network, but the wired client behind it cannot pass traffic onto the VLAN.  I have also tried connecting PCs with different SOHO style WGBs from different manufacturers with the same result.
    After going through Cisco's documentation, I found that using 1230s in WGB mode can resolve this issue since they use IAPP to communicate the MAC table of the wired side clients they service back to the controller.  I have configured a 1230, and used it as the WGB for the client machine instead of the D-Link and it does seem to work, but this would mean configuring a considerable number of 1230s to hand over to the client.
    The first question would be, Is there something I am missing that I would need to do in order to allow SOHO style WGBs to forward wired side client traffic onto the network while LWAPs are in local mode? Or would the WGB NEED to support IAPP?
    The second question is that, I may have found another solution to this already, but would like some input prior to committing.
    This client also uses these same machines with the same WGBs inside the chassis at another location where the client operates the network themselves.  They also use the same WLC model with the same version, and same APs.  The only difference is that they use H-REAP mode with local switching.
    I also tested this idea, and it seemed to work.  With the AP in H-REAP mode, and the client's WLAN set to local switching, the machine and WGB connected with no problem.
    So the question with this, would be; would there be any disadvantages in running all 220 APs at this location in H-REAP mode?  What would I be losing if anything?  Also, I would like to keep all other WLANs centrally switched.
    I understand what the difference would be for this client's WLAN if I ran in H-REAP mode with local switching, but what would the difference be in the other guest WLANs if I set them to be centrally switched?  (Is there any difference between running APs in local mode vs running APs in H-REAP with central switching?)

    Hey,
    I read your quesiton quickly so I might miss some points, but I think you need to do some more configuraiton for your passive clients behind the WGB:
    '''snip'''
    Passive Clients Behind a WGB
    The controller might not be able to see passive clients behind a WGB. Clients (such as cameras and programmable logic devices) do not initiate a traffic stream unless they are connected. Complete these steps in order avoid this issue:
    Add a static MAC filter entry for the passive WGB device and MAC filter entry for the devices that are behind it.
    Use this command in order to enable MAC filtering on the WLAN along with aaa override:config macfilter ipaddress MAC_address IP_address
    Add a static entry on the WGB IOS-based device: bridge 1 addressxxxx.xxxx.xxxx forward FastEthernet0Note: In addition, increase the dot11 activity timer.
    Add a static ARP entry on the L3 router:
    hostname(config)#arp
          arpa
    '''snip'''
    Reference: http://tiny.cc/cjsxu
    Also, know please that WGB is not supported with hybrid REAP (H-REAP).
    Even if it worked with you sometimes, it is not supported and cisco did not design it to work with HREAP.
    http://bit.ly/yLn9D1
    I am only aware about one difference between central switching HREAP and local mode; which is that any limitation applied to HREAP will be applied if it is central switching. just like our situation with WGB with HREAP.

  • Making a wireless VoWLAN only

    Hello,
    I was wondering if there is a way to make WLAN available only for Voice; i.e. excluding all data traffic from the WLAN. Can i make an access list based on Jabber NBAR? Does any version of the WLC have this functionality?
    My thought is since i will be designing the new wireless solution + BYOD (ISE), it would be good to put one SSID for VoWLAN. Is it feasible?
    TIA,
    Nicos Nicolaides       

    Hi Snyder,
    I agree with you. If I look into detail this is how I see it
    A. Upstream traffic (from wireless client)
    1. Client -> AP (if client support WMM & correct classification then only any sort of QoS or prioratization)
    2. AP -> WLC (In the current model, CAPWAP DSCP depend on WMM-UP value)
    3. WLC -> Wired (AVC could change QoS & imposed beyond this point)
    B. Downstream (to wireless client)
    1. wired -> WLC ( wired QoS determine what value goes to WLC)
    2. WLC -> AP ( if needed AVC could change QoS based on recongnised application )
    3. AP -> Client (WLC can control - Convert to WMM-UP values as per 802.1p -802.11e mapping table)
    When Implementing QoS end to end, few points to remember
    A-1 : cannot control at all (from WLC or network perspective)
    A-2 : In current unified deployment model cannot do much, but with Converged Access (3850) you can implment your normal wired QoS for the wireless packets as well. No CAPWAP beyond access switch.
    A-3 : Trusting CoS is the only option if you have to enforce WLC QoS
    For downstream direction , you can better control it as outlined & wireless QoS is primaraly focusing that.
    So in my view there is no 100% correct solution here, you have to configure QoS to improve the services as much as you can within the capability of these deployment methods & technologies.
    HTH
    Rasika

  • One ssid to multiples vlan without hreap, flex connect

    Hi my name is Ivan
    I have a question about a wireless solution
    I have one cisco wlc 2112 with ios 7.0.230.0 with license to support 12 access points. My access points are nine (9) lap1231ag  and one (1) lap1310
    I just have one wlan (ssid). My scenario of deployment is in layer 3. I have one interface management and ap manager in the WLC. All my Access Points
    have differents ip address that WLC. I need to configure a unique ssid to associate my six (6) dynamics interfaces (each dymanic interface with different vlan subnet).
    Each wlan profile (ssid) should have the same security in phase 2 (wpa2/psk).  My cisco access points don't support hreap. My wlc  support only (4)
    interface into an interface group, and i need six (6) dynamics interfaces.
    Is this possible to configure this scenario?
    I have a research about  it, and i found this link:
    https://supportforums.cisco.com/thread/2180009
    They mention there, that i need HREAP, but my AP's dont support it.
    How can i do it?
    Regards

    1°  It doesn't matter that my buildings are connected between layer 3 links, having my WLC in a different VLAN/Subnet.
    Correct.  The APs do not have any requirement of being L2 adjacent to the WLC.  If your APs are already joined, they will no how to find the WLC once you move them to their new network.  I would suggest making sure you have High Availability configured specifying the APs primary WLC.  Regardless, if joined already, the AP "knows" the controller it wants to join.  If you have "new" APs that are installed at a different L3 network, you just want to make sure you have discovery methods for these new APs to find the WLC (option 43, dns, etc)
    2° It doesn't matter what interface is associated to the WLAN in the WLAN profile.
    That depends on your design.  "IF" you have "all" your APs placed in to respective custom AP groups, then no it doesn't matter as the group interface assignment will override the WLAN interface assignment.  "IF" you still have APs in the "default group" that are not being placed in a new AP group, then these APs will inherit the WLAN configuration so the interface should be assigned accordingly.  In some cases, customers may choose to build a dummy/blackhole interface that the WLAN is bound to in the event an AP winds up in the default group.  Just make sure any dummy interfaces you create are non-routable on your network.
    3° It is not necessary to create an interface group.
    No.  An interface group will bundle multiple dynamic interfaces in to a single group that can be assigned. For instance, if you bundle all these in to a group and then assign, via an AP group, for a WLAN to use the new interface "group", then clients will be placed on the respective dynamic interfaces within that group in a round-robin fashion (or whatever algorithim is in use depending on code release), therefore clients at site A may end up on any of the 6 interfaces.  The interface group is traditionally used when customers are running out of usable space and would like to expand through the use of additional network segments, rather than increasing a subnet size through a mask reduction.

  • HREAP vs LOCAL modes

    after reading through numerous docs from Cisco - it seems that latest firmware on WLC provides HREAP functions similar to that of using local mode. So what if the APs on a LAN are all set to HREAP giving you the benefit of redundancy and also network local switching avoiding that local traffic needs to traverse the WLC ? I know Cisco are still recommneding use of HREAP for WAN remote sites - but why not use it on LAN too ? The limitations are very few and most either relate to WAN type (which on LAN these do not apply) or else refer to when LAP looses WLC communication (at least it works in limited mode better than not at all like when it is set for 'local' mode. The HREAP does not use CAPWAP tunnel to encapsulate data traffic so I agree some security is lost but if security at the LAP end is not a big issue for client I still see all other features work with HREAP - like RRM / Roaming etc . so you get full benefits of WLC whne HREAP is in connect mode and keep some if WLC is down .. can anyine convince me otherwise ? : )

    As per my usual on this type of question.
    It all depends on what you want to do.
    Yes, you can use the AP like they were autonomous, and bridge all the traffic down to the LAN if you want.  Or you can backhaul it to the WLC.  It's all up to what you need to support.
    For example, if you were using Air Fortress, you would have to use HREAP, because of how that applicaiton interacts.
    If you're only doing standard, web and email, there is no real need to.
    Both designs are valid, all depending on what you want to do.
    As for the security aspect of it, the traffic on the LAN isn't encrypted anyway.  So once the traffic egresses the WLC, it's raw, if you have a protocol analyzer you can get the data.  So that comes down to physicl security more than anything, not wired vs. wireless.
    Cheers,
    Steve
    If  this helps you and/or answers your question please mark the question as "answered" and/or rate it, so other users can easily find it.

  • Mobility between HREAP and NON HREAP does not work..

    HREAP Local Switch and Auth has been enabled on SSID.
    Indoor AP is in HREAP mode.
    Outdoor AP does not support HREAP mode.
    Client connects to indoor AP....continous PING breaks after client roams to outdoor AP. The state of the client is RUN.
    Disable HREAP Local Auth and the issue goes away.  Why?

    Without HREAP config, you will not be able to do local-auth on the AP
    The design guid says roam between a HREAP and non-HREAP will not work,
    Thanks
    NikhiL

  • HREAP Question

    Hi,
    i am designing a centralised wirless network which consists of a AIR-WLC4404-100-K9 at the HQ and 50 sites which contain 1 or 2 AIR-LAP1131AG-E-K9.
    Could you please confirm that HREAP comes with these AP's and that additional software does not need to be purchased. I know that with Aruba this is the case
    Thanks

    Hi Nathan
    H-REAP is supported only on the LWAPP-based 1131AG and 1242AG Access Points. Running 4.0 code or later, the 2000 and 4400 Series Controllers, Catalyst 3750G Integrated Controller Switch, Catalyst 6500 Series Wireless Services Module (WiSM), and Wireless LAN Controller Module (WLCM) for Integrated Services Routers (ISRs) all support this H-REAP functionality.
    While there are limitations on how many H-REAPs can reside at a single site, there are no similar limitations on the number of H-REAPs supported by controllers. H-REAPs are treated the same as other access points when it comes to how many a given controller can support.
    For more info:
    http://www.cisco.com/en/US/products/ps6521/products_tech_note09186a0080736123.shtml
    Hope this helps

Maybe you are looking for