WLC4402 mobility group for failover

Anyone know what the return time is for an AP to jump back to the primary controller from the secondary controller once it comes back online? I have a backup controller over a WAN connection that I'm using to backup four different locations. WLC is runnign 3.2.78 code. APs are 1000 series.

We're trying to figure this out as well; we have a WiSM, and try to get the APs to fail over from one side to the other. They do, but it takes them a good 30 seconds and obviously no traffic is passed during this time. Both controllers share a mobility group, and each mobility group peer can ping the other.
The APs are converted 1131AGs an 12xx series. We've used http://www.cisco.com/warp/public/102/wlc_failover.pdf to set this up, but there reregistration is hardly immediate, and the APs don't seem to ever switch back to the primary controller once it comes back up. Any suggestions?

Similar Messages

  • WLC 5500 mobility group failover

    Hey
    I have a Question i am testing  mobility group with
    Failover for redundend connection between 2
    Cisco 5500 Wlc.
    On both the controllers i got the mobility working
    And both the controllers have the same version
    And configuration.
    But when i unplug the main controller the access-
    Points don't convers to the second one
    The just keep on creaming can't find the main controller
    Also with this thus the second wlc need to have the same
    Interface ip address like managment..??
    Thanks

    What do you mean by "convers". An AP will only join one wlc and when that primary wlc is no longer available, should failover to the other/secondary wlc. Mobility is required for an AP to know about all the other APs in that mobility group. And if not configured correct, your AP will only be able to join that wlc.
    Thanks,
    Scott Fella
    Sent from my iPhone

  • N+1 redundancy and different mobility groups

    Is it possible to backup 2 controllers with 2 different mobility groups (for example GROUP1 and GROUP2) to the same backup controller (running HA SKU N+1 (7.4)) ?
    Since a controller can only be configured in 1 mobility group, this doesn't seem to be possible. Can someone confirm ?
    regards,
    Geert

    Hello,
    As per your query i can suggest you the following solution-
    In all Wireless LAN Controller (WLC) versions earlier than 4.2.61.0, when a WLC goes "down," the LAP registered to this WLC can failover only to another WLC of the same Mobility Group, if the LAP is configured for failover. From Cisco WLC version 4.2.61.0 and later, a new feature called Backup Controller Support is introduced for access points to failover to controllers even outside the Mobility Group. Refer to Wireless LAN Controller and Light Weight Access Points Failover Outside the Mobility Group Configuration Example for more information.
    Hope this will help you.

  • 2 WLCS for failover

    Hi,
    I want to buy a second WLC. The equipment hasn't been ordered yet so I just trying to think a head.
    As I understand it if I buy the second WLC and put it in the same mobility group then enable AP fallback that is all I have to do. Is that really it? They will be 2504's. The APs are Air Cap 36021-A-k9.
    What about adding the access points etc etc does that happen automatically and the config gets replicated? Again sorry to ask what might be a stupid question for many but I really know very little about wireless at the moment.
    Also is there an idiots guide somewhere for setting up guest wireless lans?
    Thanks,

    Consider a scenario where there are two Wireless LAN Controllers (WLCs) named WLC1 and WLC2. These WLCs are configured in the same subnet in one WLAN. In order to achieve high availability, this is how the WLAN is configured:
    WLC1 and WLC2 are configured within the same mobility      group.
    Half of the access points are configured to use WLC1 as      the primary WLC and use WLC2 as the secondary WLC.
    The other half of the access points are configured to      use WLC2 as the primary WLC and use WLC1 as the secondary WLC.
    The fallback feature is enabled on both WLC1 and WLC2.
    Network Diagram
    Resolution
    If any of the WLCs go down, the access point that is joined to the failed WLC  recognizes this (keep alive (heartbeat) between access point and WLC). Therefore, the access point begins to join the good WLC, which still runs. This is not stateful failover, which means that the access point has to join the new WLC and therefore the wireless clients.
    Also, if either of the WLCs do not work and the affected access points re-register to the other WLC, then the wireless clients have to re-associate and therefore lose wireless connection during failover as it is not stateful failover. The failover is not transparent to the WLAN client. That is, the WLAN clients lose their WLAN connectivity during access point failover.
    Access points and clients are not effected on the WLC that runs. This means that the fallback of the access point is not transparent to the clients. Only access points and clients on the failed WLC are effected.
    In order to configure the WLAN Controller failover for Lightweight Access points, the Access Point must be configured correctly in a mobility group for the AP failover and each Wireless LAN Controller (WLC) must have the AP failover feature enabled.
    Configure the Fallback Feature on WLC
    The last step is to configure the Fallback feature on the controller. This feature ensures that the AP switches return to the first WLC when the WLC that comes back on line. Complete these steps:
    From the GUI, choose Controller > General.A      list of options appears on the General screen.
    For the AP Fallback option, choose Enabled from      the drop-down menu.
    Click Apply.Note: It is sufficient to      enable the Fallback feature on the secondary controller alone. But it is      recommended to configure it on the primary WLC as well because it can be      configured as a secondary controller for other access points
    http://www.cisco.com/image/gif/paws/69639/wlc_failover-12.gif
    After you complete these steps, the setup is configured for WLC failover. When the primary controller (WLC-1, in this case) goes down, the APs automatically get registered with the secondary controller (WLC-2). The APs register back to the primary controller when the primary controller comes back on line. AP switching between the primary and secondary controllers also affects the wireless clients associated with these APs.
    In controller software release 5.1.151.0, you can configure the wireless network so that the backup controller recognizes a join request from a higher-priority access point and, if necessary, disassociates a lower-priority access point as a means to provide an available port. In order to configure this feature, failover priority must be enabled on the network and assign priorities to the individual access points. By default, all access points are set to priority level 1, which is the lowest priority level.
    Note: Be aware that Failover priority takes effect only if there are more association requests after a controller failure than there are available backup controller ports.
    Wireless LAN Controller Failover Priority
    During installation, Cisco recommends you connect all lightweight access points to a dedicated controller, and configure each lightweight access point for final operation. This step configures each lightweight access point for a primary, secondary, and tertiary controller and allows it to store the configured mobility group information. When sufficient controllers are deployed, if one controller fails, active access point client sessions are momentarily dropped while the dropped access point associates with another controller, which allows the client device to immediately reassociate and reauthenticate.
    You can also follow the below link(WLAN Controller Failover for Lightweight Access Points Configuration Example)
    http://www.cisco.com/en/US/tech/tk722/tk809/technologies_configuration_example09186a008064a294.shtml

  • WLC mobility group between 4404 and 5508 controllers

    Mobility 'Control and Data Path Down' between 4404 and 5508 WLC's.
    Hello, we have 5 x 4404 WLC's running 7.0.240.0 with mobility configured fine between them.
    We have installed a 5508 with HA running 7.4.110.0, and have tried to add it to the mobility group, however we see 'Control and Data Path Down' between the new 5508 and all the 4404 controllers.
    All controllers have:
    The same virtual address
    Management interfaces are in the same VLAN, and indeed all the controllers connect via the same pair of 3750X stacked switches.
    The default mobility domain name is the same
    4404 output when issung the command 'show mobility summary'
    Symmetric Mobility Tunneling (current) .......... Enabled
    Symmetric Mobility Tunneling (after reboot) ..... Enabled
    Mobility Protocol Port........................... 16666
    Default Mobility Domain.......................... SGH-Mobility
    Multicast Mode .................................. Disabled
    Mobility Domain ID for 802.11r................... 0xe209
    Mobility Keepalive Interval...................... 10
    Mobility Keepalive Count......................... 3
    Mobility Group Members Configured................ 6
    Mobility Control Message DSCP Value.............. 0
    5508 ouput when issueing the command 'show mobility summary'
    Mobility Architecture ........................... Flat
    Mobility Protocol Port........................... 16666
    Default Mobility Domain.......................... SGH-Mobility
    Multicast Mode .................................. Disabled
    Mobility Domain ID for 802.11r................... 0xe209
    Mobility Keepalive Interval...................... 10
    Mobility Keepalive Count......................... 3
    Mobility Group Members Configured................ 6
    Mobility Control Message DSCP Value.............. 0
    I've spent quite some time double checking all the configurations to no avail.
    Has anybody seen this problem before?
    Kind regards
    Dave Bell

    Thanks Sandeep.
    I am well versed with WLC's and mobility, however trying to add a 5508 to a mobility group with 4404's has come up with a bit of a curve ball.
    All the 4404 controllers all joined the mobility group fine, no problems at all - its only the 5508 I am struggling with.
    In theory its simple, populate the IP address, and MAC addres of the management interface of the remote WLC, as long as the management interfaces are in the same VLAN, and the Default Mobility Domain Name are the same it should come up.
    Interestingly I have found the 5508 reports its own management interface MAC address incorrectly when viewing the Mobility Groups:
    For example:
    {Screen shot WLC1.jpg}
    5508 management address is 10.95.x.x and when viewing the Mobility Management screen it shows its own MAC address as bc:16:65:f9:37:60.
    however!
    From our router is I do an sh arp | i 10.95.x.x (controller management address), I see:f872.eaee.becf.
    {Screen shot wlc2.jpg}
    Hence the WLC reports as: bc:16:65:f9:37:60
    and
    The network reports as: f872.eaee.becf for the same IP address.
    I have changed the other WLC's to the MAC adress seen on the network for the new controller, aka changed from
    bc:16:65:f9:37:60
    to
    f8:72:ea:ee:be:cf
    I now see the controllers reporting the mobility with the new controller as 'Control Path Down', however I am at a loss as to what may be causing this?
    Kind regards
    Dave Bell

  • Create 2nd mobility group on 5508

    Hi all,
    We are running all our APs in H-REAP mode connecting to WLC 5508 (7.2.xxx)
    Each H-REAP AP has local switched SSID, as  well as a guest SSID (centrally switched), which is 'tunneled' to the WLC, with Internet only access through the DC.
    All the AP's connecting to the WLC using the managment interface, which is also the local mobilty group.
    To route traffic different for the guest WLAN, I'd like to create a new Interface on WLC and use this as local mobility group for the guest WLAN.
    Is this possible, or is the managment interface always the local monility group?
    Appreciate your feedback.
    Thanks,
    Stefan      

    Hi Rasika,
    Each of our branch sites have 2 WAN connections. 1 MPLS (critical traffic), 1 IPsec (non critical).
    While the managment interface of WLC is reachbale  through MPLS, I'd like to route traffic for Guest WLAN over IPsec.
    Therefore I would need create a 2nd Interface on WLC (different IP range) and terminate centrally switched traffic on that interface.
    As you've mentioned the local mobility group is always the controller MAC (management int), so not sure if there's another way to solve this?
    H-REAP AP,s register to managmnet int      --> routed through MPLS
    centrally switched traffic to different int          --> routed through IPsec
    Thanks,
    Stfean

  • Mobility Group Requirements for Guest Anchor WLC

    Hello -
    I've alway assumed you can't create a guest tunnel between a local WLC and an anchor WLC that are in different mobility groups.   However, I was told recently (without much detail) that this is possible.  So I have set out to test this.  
    I am trying to point one of my local WLCs guest SSIDs to a guest anchor WLC in a different mobility group.   I have a maintenance window coming up and I am looking to anchor the clients on one campus to the anchor WLC on the other campus so guest service does not go down.   Each campus is it's own mobility group.   In trying to set this up I went to the "mobility anchors" screen for the guest SSID on one of the local WLCs and I am unable to add the anchor WLC from the other campus because it's non in the drop-down menu.  This is because it's not in the same mobility group.   So my question is how do I anchor clients coming through a local WLC in one mobility group to an anchor WLC in another mobility group?
    To me it doesn't seem possible without significant configuration changes.   I don't want to reconfigure/recreate mobility groups. 
    Thanks
    Chuck

    Not only is it possible, I would recommend it. However, you may be confusing some concepts.
    The Mobility Group is different than the Mobility Domain.  I generally refer to the Mobility Group as those WLCs with the same Default Mobility Group Name, and the Mobility Domain as the entire Mobility List (where you can define up to 72 controllers from various mobility groups).
    The point is that if WLCs 1-10 are GroupA, and WLCs 11-20 are GroupB, for anchoring to work you at least need to add the anchor to the mobility list of the foreign wlc, and vice versa.
    If you notice, when you add a mobility entry to the list, it should ask you for mobility group. If you leave it blank, it should default to that of that WLC,  but on GroupA controllers, you could define GroupB controllers (and specific GroupB) and then you should now have mobility established between your controllers and the Anchor configuration will have your anchors in the drop-down....
    Does that make sense?

  • Mobility group membership

    I have 4 WLC's deployed :
    1. AnchorWLC - WLC4402 anchor in a DMZ for guest access
    2. WLCA1 - WLC4402 on SiteA
    3. WLCB1 - WLC2006 on SiteB
    4. WLCB2 - WLC2006 on SiteB
    SiteA & SiteB are geographically separated.
    On all WLC's there is the same mobility group 'group1' with the following group members:
    1.on AnchorWLC: group1 members:WLCA1,WLCB1,WLCB2
    2.on WLCA1: group1 members: anchorWLC
    3.on WLCB1: group1 members: WLCB2,anchorWLC
    4.on WLCB2: group1 members:WLCB1,anchorWLC
    As SiteA and SiteB are geographically separated I have not included internal(non-anchor) WLC's that are on siteA in the mobility group created on WLC's on SiteB and vice versa . The only WLC that has all controllers added to his mobility group is the AnchorWLC as guest access is needed from both siteA and siteB.
    Is this a valid config(anayway it is working...) or is it recommended to have 2 different mobility groups, one for each site(A & B) and create 2 seperate mobility groups on the anchorWLC ?

    I would recommend going for two separate mobility groups. Even though it is working since it is geographically separated, its always better to have different mobility groups.

  • Mobility Group Issue

    I have a WiSM configured with the same mobility group name and all pre-reqs are ok but the roaming does not works and the client lost connection when change of access-point.
    I saw that RF-group are diferents and bootloader version is diferent too.
    Does any one Know if bootloader and RF-group diferent can be the reason for that.
    thanks a lot

    An incorrect or incomplete mobility group configuration should be the most common reason for your problem. In order to overcome this, you need to ensure that your WiSM mobility group is configured correctly as follows:
    The mobility group name configured must be the same on all the controllers that belong to a particular mobility group. This mobility group name is case sensitive.
    The mobility group members list configured on each controller needs to contain all the controllers of that particular mobility group.
    These configurations ensure that the failover occurs seamlessly and also that when the primary controller comes back on, the previously registered APs fall back to it.

  • Mobility group -without layer 3 roaming

    Hi all,
    With a N+1 WLC deployment, is it possible to disable layer 3 roaming while enabling Mobility group feature on the backup controller ?
    based on the network setup layer 3 mobility is not required.However,  we need to both controllers to exchange all security related  parameters so that excluded clients info etc  will be in sync during a failover scenario.
    I do not  intend to use ACLs as such.
    Any thoughts much appreciated.
    cheers,
    Janesh

    Hi Nicolas,
    Many thanks for the  reply.
    Let me throw some light on the matter
    -Why exactly do you want to block layer 3 roaming ?
    Buildings are miles apart so roaming  will only happen within a building and it will be  intra controller.
    Also  I have seen on cisco doco that Layer 3 roaming is not preferred.
    How does it impact you as anyway it's transparent for the network ?
    As I mentioned layer 3 roaming is not required so I don't see a point enabling it.Why tax the controller unnecessarily?
    One controller serves all the APs at one data centre and the other is the backup.No salt and pepper  scenario.
    -Does that mean that you're ok with layer 2 roaming ? If yes, just configure all WLCs to serve the same subnets for the clients
    Layer2 roaming will happen  within the controller as  primary and backup controllers are Layer -3 separated.
    There is no layer 2 adjacency between the controllers.
    over to you
    cheers,
    Janesh

  • Bandwidth requirement between controllers in mobility group

    We have a potential project spanning two sites a few miles apart. We are hoping of putting 1 controller at each site in a single mobility group to provide AP failover if one controller is to fail. We are planning on a total of 25-30 APs, roughly half at each site.
    Questions:
    Whats the minimum bandwidth required between sites?
    If bandwidth isn't adequate can this be done with both controllers at one site and H-Reap access points for the other site? Am I correct in thinking that you can have no more than 8 H-Reap access points per WLAN (16 Reap APs per WLAN)?
    Thanks!

    Thanks! I think it will be fine. I was more worried about the event of a failed controller which would cause more traffic between the other APs and the backup controller at the other site. However with all the APs in H-Reap local switching mode it should work.

  • Assigning Mobile Group to a User

    I plan to use the <i>Mobile Group</i> filter for a SyncBO, to avoid too large data volumes on clients - BUT I find it very hard to administer through MEREP_PD and impossible to assign a user to a mobile group in advance of application deployment.
    We are dealing with approx. 30 users and they should be allocated to 6 different Mobile Groups. Is there a way to allocate Users to Mobile Groups in advance of application deployment ?
    Thanks.
    Lars

    after creating user in OID (which creates a user for portal also) You shold run the procedure in the portal schema:
    PROCEDURE setdefgroup (
    p_username varchar2,
    p_groupname varchar2) IS
    v_group_id number;
    BEGIN
    v_group_id := WWSEC_API.GROUP_ID
    (p_name => upper(p_groupname));
    wwsec_api.set_defaultgroup
    (p_groupid => v_group_id,
    p_username => upper(p_username));
    END;
    to asign the default group to a user.

  • Mobility Group Table *MUST* be populated in each WLC in same mobility group

    For what it's worth,
    I recently discovered that when you have multiple controllers and want to implement Mobility Groups, more is needed than simply entering the same Default Mobility Group Name for each controller within the mobility group. The following is required:
    a) The IP address of the "Virtual" interface on each controller must be identical on each controller within the mobility group.
    b) The Default Mobility Group Name must be identical on each controller within the mobility group (case sensitive).
    c) The mobility table must be populated with an entry for each controller within the mobility group.
    Otherwise, you will see some inexplicable behavior such as:
    * LWAP access points refusing to change to a different controller, even if their primary controller is explicitly set and the LWAP is rebooted.
    * LWAP access points unable to find any other wireless controller other than the one pointed to by the "CISCO-LWAPP-CONTROLLER" DNS entry (presumably, this would also be the case if DHCP Option 43 is used to point the LWAP to a controller). Once the first controller reaches its max. capacity of LWAPs, no more LWAPs can join.
    * Even MASTER CONTROLLER MODE has no effect.
    Cisco TAC was able to explain the great mystery of the Mobilty Group Table to me. However, unless you know your problem is related to mobility groups issues, you might not know to start there (I know I didn't).
    The least difficult method I have found for populating the mobility group table is as follows:
    Build a text file with one entry for each controller in the mobility group as follows:
    Log into the GUI for each controller and selecting: Controller -> Mobility Management -> Mobility Groups, click the "EDIT ALL" button and copy the MAC and IP address from the text box into a text file using NOTEPAD. Repeat this for each controller, creating a new line for each:
    The format for the entries is as follows:
    00:1a:6c:91:22:A0 192.168.20.44
    00:1a:6c:91:22:B4 192.168.20.45
    Once the text file is completed (one entry for each controller in the mobilit group), click the EDITALL button and copy the entire contents of the text file and paste it into the text box on the controller GUI, click the APPLY button and click Save Changes. Repeat for each controller.
    Again, make sure that the following settings are IDENTICAL in each of the controllers in the Mobility Group:
    * The IP address of the "virtual" interface ( Controller -> interfaces ) must be the same on all controllers.
    * The "Default Mobility Domain Name" ( Controller -> General ) must be identical on each controller in the mobility group (note: the Mobility Domain Name is case sensitive).
    After making changes directly to the controllers, a "refresh from controller" in the WCS might be needed to get the WCS to attempt to synchronize itself with the controllers.
    Here is a link to the 4.2 Wireless Controller Configuration Guide which discusses this in greater detail.
    http://www.cisco.com/en/US/products/ps6366/products_configuration_guide_chapter09186a00808e638b.html
    It is unfortunate that there are currently no mechanisms in the WCS 4.2 to make these changes in bulk (i.e.: The WCS has no Controller Template to do this).
    Also, if you ever need to replace a controller, you will need to update the Mobility Group Table in each controller in the Mobility Group (since the tables will have the MAC address of the old controller which will now be different in the new replacement controller).
    Despite having used the "unified" product for some time now, there are still surprises from time to time. I just thought that I would share my experience for those who may want avoid it and/or who may be encountering any of odd the behavior described above.
    - John

    Hi John,
    Nice work with this very relevant info! Please post a short reply here so that we can give this the nice rating it deserves :)
    Thanks again!
    Rob

  • WLC 5508 * 2 & Mobility Group

    What I am trying to configure is Mobility Groups.
    My understanding is that this will allow AP to successfully register and fail over over seamlessly if any of the WLC had to fail ?
    It could be I am confusing two things into one :( & I am totally confused and not understanding the benefits of mobility group mentioned above.
    Also when a AP starts up and registers with the WLC ......I click on a registered AP > High Availability ( Primary / Sec / Tertiary ) all fields are blank...
    Initially I also thought that once my SSO is all setup and working than those options "AP > High Availability" will get populated automatically but clearly not unless something is not working.
    My current config is as follows:-
    WLC 5508 * 2
    WLC 1 - Primary
    WLC 2 - HA SKU (Secondary )
    Redundancy = SSO (Both AP and Client SSO)
    =============
    (Cisco Controller) >show sysinfo
    Manufacturer's Name.............................. Cisco Systems Inc.
    Product Name..................................... Cisco Controller
    Product Version.................................. 7.6.130.0
    Bootloader Version............................... 1.0.20
    Field Recovery Image Version..................... 7.6.101.1
    Firmware Version................................. FPGA 1.7, Env 1.8, USB console 2.2
    Build Type....................................... DATA + WPS
    System Name...................................... WLC5508
    System Location..................................
    System Contact...................................
    System ObjectID.................................. 1.3.6.1.4.1.9.1.1069
    Redundancy Mode.................................. SSO (Both AP and Client SSO)
    IP Address....................................... 10.31.66.21
    Last Reset....................................... Software reset
    System Up Time................................... 0 days 22 hrs 39 mins 57 secs
    System Timezone Location......................... (GMT) London, Lisbon, Dublin, Edinburgh
    System Stats Realtime Interval................... 5
    System Stats Normal Interval..................... 180
    Configured Country............................... GB  - United Kingdom
    Operating Environment............................ Commercial (0 to 40 C)
    --More-- or (q)uit
    Internal Temp Alarm Limits....................... 0 to 65 C
    Internal Temperature............................. +38 C
    External Temperature............................. +21 C
    Fan Status....................................... OK
    State of 802.11b Network......................... Enabled
    State of 802.11a Network......................... Enabled
    Number of WLANs.................................. 1
    Number of Active Clients......................... 0
    Burned-in MAC Address............................ F8:72:EA:EE:5B:B2
    Power Supply 1................................... Present, OK
    Power Supply 2................................... Absent
    Maximum number of APs supported.................. 500
    ============================================
    TA

    TA,
    Mobility and mobility groups are used for the wireless users roaming. What we know that a wireless users can roam between different APs within the same WLC, but when the SSID is used within multiple WLCs, and the client wanted to roam to an AP joined to another WLC, you would need to configure WLC mobility to maintain seamless roaming. For more info:
    http://www.cisco.com/c/en/us/td/docs/wireless/controller/8-0/configuration-guide/b_cg80/b_cg80_chapter_010001101.html
    Now, I understand that your purpose is to have high availability for your APs. No this is done traditionally from the AP page, under HA tab, where you configure the WLCs names and IPs there. This can be done manually on each AP (you can use CLI to make it easier) or you can push a configuration template using a management server (WCS/NCS/CPI).
    Configuring HA on the AP:
    http://www.cisco.com/c/en/us/td/docs/wireless/controller/8-0/configuration-guide/b_cg80/b_cg80_chapter_01110000.html
    http://www.cisco.com/c/en/us/td/docs/wireless/controller/8-0/configuration-guide/b_cg80/b_cg80_chapter_01110001.html
    Using CPI to push AP configuration templates:
    http://www.cisco.com/c/en/us/td/docs/wireless/prime_infrastructure/2-0/configuration/guide/pi_20_cg/temp.html
    Now mobility may play a role in this, as if you have already configured mobility for your WLCs, then you won't need to configure a "name" for the WLCs when you add them under the HA tab in AP configuration page. That's it.
    BR, Ala

  • What will happen when I remove controllers from mobility groups?

    Hi,
    I'm wondering what exactly will happen when I remove a controller from a mobility group?
    1) Will it require a reboot? (I don't think so, nothing I've found says so)
    2) Will it deauth/reauth the AP's connected (I don't think so, nothing I've found says so)
    3) Will it do anything else goofy?
    I have 2 RF groups spanning continents over low speed links. All that is transmitted over mobility groups is session data correct? Not usernames, not ??? What am I missing here? I'm banging my head against the wall because I can't figure out why someone would configure the system in this way.
    Setup:
    WLC 4404, WLC 2100's
    WCS 5.2.148
    11xx series AP's
    Radius Auth for domain users
    a few SSID's, one guest SSID, no DHCP on any of the controllers
    Thanks in advance,

    Hi,
    I'm wondering what exactly will happen when I remove a controller from a mobility group?
    1) Will it require a reboot? (I don't think so, nothing I've found says so)
    2) Will it deauth/reauth the AP's connected (I don't think so, nothing I've found says so)
    3) Will it do anything else goofy?
    I have 2 RF groups spanning continents over low speed links. All that is transmitted over mobility groups is session data correct? Not usernames, not ??? What am I missing here? I'm banging my head against the wall because I can't figure out why someone would configure the system in this way.
    Setup:
    WLC 4404, WLC 2100's
    WCS 5.2.148
    11xx series AP's
    Radius Auth for domain users
    a few SSID's, one guest SSID, no DHCP on any of the controllers
    Thanks in advance,

Maybe you are looking for

  • BB Curve backup from old harddrive?​?

    Lastnight my BB Curve was stolen from work. How sad is that, I mean really?! Brand new, only 3 months old, totally had to spend another $400 on a new one today! My question however is, I recently redid my computer and added a new harddrive, using my

  • Latest firmware

    For the HP Officejet Pro 8600 e-All-in-One Printer - N911a, which is the latest firmware version: CLP1CN1416AR or VersionCLP1CN1322CR, 29.13M? This question was solved. View Solution.

  • Convert Formula from BSO to ASO

    "Rate"=(1-@POWER ((1-("Total Net Surrender Amt"->"JAN"/(@mdSHIFT("ACCOUNT_VALUE",-1,"Years",,11,"Periods",)))),(12/1))) ;

  • ASE 15.7 new feature : In-row LOB

    We are trying to implement In-row LOB in our environment. We already have a POC for this feature. But all the testings' are done on a non-replicated environment. I want to know if this is already in use in production replicated environment. And any i

  • How would you do uneven distribution of objects?

    I whish the Transform Each... tool had a feature allowing specified number of copies along with the Skew feature that is available in the Grid tool. So far I've been doing this by using the Grid tool as a reference and manually arranging objects whic