Layer 2 & Layer 3 Controllers in Same Mobility Group

I want to upgrade the existing Layer 2 contollers 4100 and AP 1200 (in the same subnet) to Layer 3 (controller is different subnet from AP). Due to migration in phases, I need to have mix Layer 2 and Layer 3 controllers in short period of time. Any issue if there is mixed Layer 2 and Layer 3 controller in the same mobility group. Additionally, any concern if user roaming between Layer 2 and Layer 3 controllers in the same mobility group? Thank you.

On the controller page, General, there is a option LWAPP Transparent Mode to select Layer2 or Layer 3 mode of the controller. Not sure why can't convert from L2 to L3.
Actually I had converted few L2 controllers to L3 in the same mobility group in lab. I concern if there is any problem if mix L2 and L3 controler in the same mobility group. Thanks.

Similar Messages

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

4400 and 5500 in same mobility group

Hello
Has anyone experience or know if its possible to join 4400 wlc and 5508 to the same mobility group? Can't find much info out there, just want to find out if there are any gotchas.
Thanks

Yes you can but reference this link.
http://www.cisco.com/en/US/docs/wireless/controller/5500/tech_notes/Wireless_Software_Compatibility_Matrix.html#wp123314
Sent from Cisco Technical Support iPhone App

WLC 4400 - Different minor versions same mobility group?

Hi all,
i have 2 WLC 4400 integraded in 3750G.
One has 6.0.202 and the other 6.0.188.
They are in different places but now i want to put them in the same mobility group.
Will this difference be a problem?
BR
Anthony

Yes it will be an issue. You have to remember that the AP gets it firmware from the WLC image. So if an AP has to mi e from one to the other, it will either upgrade or downgrade each time. Best practice is to keep the firmware the same.
Sent from Cisco Technical Support iPhone App

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

WiSM redundancy, mobility groups and RF groups

Hi there
we would like to implement the following:
- Support for about 2000 LAP's
- 1 x Catalyst 6509
- 1 x Sup 720
- 7 x WiSM's
What I'm interesting is are the following points:
1. I thought that we would build the switch completly redudant, so we have to wlan switches (switch A and B) with 7 WiSM's eatch. So I can garanty a N+N redundancy --> each LAP's has a primary controller on switch A and it's secondary controller on switch B. The LAP's can be splitted on the two switches, but for your understanding there is a 1:1 redundancy. What do you think of this design, is the too much or is this appropriate?
2. As I know you can build up a mobility group of a maximum of 24 controllers or 12 WiSM's. I would put only these controllers in a mobility group, where Layer 2 roaming can occure.
3. But what is about the RF groups - there is a maximum of 1000 LAP's, so I can put only 3 WiSM's in one group. But this would not work form me, then I would have 2 WiSM's on switch A and only 1 WiSM on switch B in a RF group (not a 1:1 redundancy). First is it possible to put WiSM-A and WiSM-B into different RF groups, I think so because they are logically splitted, aren't they?
And what RF group design would be best (just as a reference)? I thought that it would make sense to form a RF group for each of the seven pairs (1 WiSM on switch A and 1 WiSM on switch B) for redundancy? What do you think of that approach?
4. So I would have 1 mobility group and 7 RF groups. Or do you recommend to form the mobility groups like the RF groups? But what happens with Layer 2 roaming in that case?
I'm sorry for the long and messy text, but I hope you can see my design questions?
Thanks a lot in advance.
Dominic

It sounds like you already have some good replies. Personally I like N+1 redundancy, but that is a designers choice. One thing I should point out is that the 6500 can only support 5 WiSM cards each. In this case a 4 WiSM x 3 chassis option would give your more spare capacity with only 12 total cards. The lower WiSM cost (12 vs 14) would help offset the cost of the extra chassis. You could also support 2400 APs with 8 WiSM cards even if one switch is down.
Not too long ago Cisco added the ability to set the priority of APs so your critical ones would join a controller and the less critical ones would go down if a controller failed and there were no redundancy. That is something to keep in mind when designing wireless. You may not need redundancy for all APs and that could affect your design and costs.
Randy

Can't put two 5508 WLCs in the same RF group

Hi experts,
I have two 5508 WLCs and I want them to be backup to each other. I put in the same "RF Group Name" and even the same "Default Mobility Domain Name" however under Wireless -> 802.11b/g/n -> RRM -> RF Grouping each controller still only have themselves as the only memter to the group.
Two controllers are having management IPs on the same subnet 192.168.161.x/24. AP-manager interfaces are in the same network as well. They can ping each other fine. The following screen shots show the current relavent config on the controller:
I do have two controllers in the same mobility group and they are both showing up...
Does anyone know why they can't add each other to the RF group? All other settings are pretty much default...
Thanks!

Hi,
is there a chance that one of the 2 WLC doesn't contain any access point ? Or that the APs from one WLC are not physically close to the APs of the second WLC ?
The point of RF grouping is to exchange RF information, to make RRM decisions together and to know what ap is a rogue and which is not. RF group information travels over the air from AP to AP.
So if a wlc has no ap of if its APs are not close to those of the other WLC there is both no point in grouping with the other WLC in rf group and also no technical way of doing so.
Regards,
Nicolas
===
Don't forget to rate answers that you find useful

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.

Mobility groups with multicast - 7.4.100.60

Hello all,
I am not sure if this is a bug, but here we go. I configured 2 controllers in a mobility group using multicast signalling.
I expect that from the moment i enable multicast, the controller joins this group AND STAYS IN THIS GROUP so he will get messages from all other controllers.
On the first hop router, i can see the join:
#sh ip igmp mem 239.194.248.10
Flags: A - aggregate, T - tracked
       L - Local, S - static, V - virtual, R - Reported through v3
       I - v3lite, U - Urd, M - SSM (S,G) channel
       1,2,3 - The version of IGMP, the group is in
Channel/Group-Flags:
       / - Filtering entry (Exclude mode (S,G), Include mode (G))
Reporter:
       <mac-or-ip-address> - last reporter if group is not explicitly tracked
       <n>/<m>      - <n> reporter in include mode, <m> reporter in exclude
Channel/Group                  Reporter        Uptime   Exp. Flags Interface
*,239.194.248.10               10.102.78.98    00:00:05 02:54 2A     Vl350
However, this entry does not get refreshed. I have the impression that the controller does not reply to the IGMP general queries:
IGMP(0): Send v2 general Query on Vlan350 -> no replies
#sh ip igmp mem 239.194.248.10
Flags: A - aggregate, T - tracked
       L - Local, S - static, V - virtual, R - Reported through v3
       I - v3lite, U - Urd, M - SSM (S,G) channel
       1,2,3 - The version of IGMP, the group is in
Channel/Group-Flags:
       / - Filtering entry (Exclude mode (S,G), Include mode (G))
Reporter:
       <mac-or-ip-address> - last reporter if group is not explicitly tracked
       <n>/<m>      - <n> reporter in include mode, <m> reporter in exclude
Channel/Group                  Reporter        Uptime   Exp. Flags Interface
*,239.194.248.10               10.102.78.98    00:02:35 00:24 2A     Vl350
>> 20 seconds from expiry.
#sh ip igmp mem 239.194.248.10
Flags: A - aggregate, T - tracked
       L - Local, S - static, V - virtual, R - Reported through v3
       I - v3lite, U - Urd, M - SSM (S,G) channel
       1,2,3 - The version of IGMP, the group is in
Channel/Group-Flags:
       / - Filtering entry (Exclude mode (S,G), Include mode (G))
Reporter:
       <mac-or-ip-address> - last reporter if group is not explicitly tracked
       <n>/<m>      - <n> reporter in include mode, <m> reporter in exclude
Channel/Group                  Reporter        Uptime   Exp. Flags Interface
>> 20 seconds later, gone
>> At this moment the controller doesn't receive any messages anymore from remote controllers:
>>sh ip mroute 239.194.248.10
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group
       V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.194.248.10), 00:05:38/00:00:21, RP 10.102.90.20, flags: SP
Incoming interface: Port-channel30, RPF nbr 10.102.78.13, RPF-MFD
Outgoing interface list: Null
This is seen on 8500 platform running 7.4.100.60
We have also WISMs running at 7.0.230.0, and there it can be seen that the entry refreshes every minute (like it should be)
IGMP(0): Received v2 Report on Vlan950 from 10.96.9.67 for 239.194.240.1
IGMP(0): Received Group record for group 239.194.240.1, mode 2 from 10.96.9.67 for 0 sources
IGMP(0): Updating EXCLUDE group timer for 239.194.240.1
IGMP(0): MRT Add/Update Vlan950 for (*,239.194.240.1) by 0
Shouldn't the controller at all times stay joined in its mobiility group ?

ok, some more debugging.
I loaded up 7.4.100.60 on a 5500 controller and got the same result.
NOTE: my global multicast settings are:
Controller->General: AP Multicast Mode: UNICAST
Controller->Multicast->Global Multicast is NOT enabled
Controller->Mobility->Multicast Messaging: enabled and group is 239.194.240.3
With this config, the IGMP entry is not retained, and i see on the controller the message (debug bcast all):
>>processEthernetIGMPpacket Received IGMP Pkt from DS when either igmp snooping or global multicast is disabled.
So, i then enabled Global Multicast (Controller->Multicast->Global Multicast to enable), and then the IGMP entry is refreshed:
bcastReceiveTask: Sep 05 13:11:17.734: IGMP packet received over vlanid = 102 from DS side
*bcastReceiveTask: Sep 05 13:11:17.734: received an IGMP query for multicast vlan = 102 address 0.0.0.0 intfnum = 3
*bcastReceiveTask: Sep 05 13:11:17.734: IGMP report scheduled for grp=0xefc2f003, vlan=102, intf=3, slot=70, maxRespTime=100
>>sh ip igmp membership 239.194.240.3
004586: Sep 5 15:11:50.710 CEST: IGMP(0): Send v2 general Query on Vlan101
Flags: A - aggregate, T - tracked
       L - Local, S - static, V - virtual, R - Reported through v3
       I - v3lite, U - Urd, M - SSM (S,G) channel
       1,2,3 - The version of IGMP, the group is in
Channel/Group-Flags:
       / - Filtering entry (Exclude mode (S,G), Include mode (G))
Reporter:
       - last reporter if group is not explicitly tracked
       /      - reporter in include mode, reporter in exclude
Channel/Group                  Reporter        Uptime   Exp. Flags Interface
*,239.194.240.3                10.102.180.218 00:38:51 02:28 2A     Vl102
Now, on the 5500 controller i can enable global multicast, while AP multicast mode is in UNICAST.
However, on the 8500 controller, running the same firmware (7.4.100.60), when i try to enable "Global Multicast", i get:
"Multicast-Unicast mode does not support IGMP/MLD snooping. Config mode to multicast-multicast first". I did not get this message on the 5500.
So when switching to Multicast->Multicast mode, and then enabled "Global Multicast", then it works.
This means that in order to have mobility messaging working on 8500 in multicast, you MUST put the AP Multicast Mode to Multicast AND you must enabled "Global Multicast", otherwise it won't work.

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 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?

Guest anchor mobility group

I have 2 anchor controllers in a DMZ to provide redundancy for guest access. They are configured with the same default Mobility group name which is different from the local controller Mobility names. My local controllers include both anchor controllerss in their mobility groups configuration. The anchor controllers provide DHCP for guest access, but with different IP subpool addresses.
Do I have to include both DMZ anchor controllers as well as the local controllers in the mobility groups which are configured on the DMZ controllers?
Would the DMZ controllers communicate with each other - if so, what information would be exchange e.g. client status?
Does symmetric tunnelling have to be configured?
Thanks

I would add both DMZ controller to eachother's mobility group list. This way if a client roams from a controller that is anchored to WLC-A to a controller anchored to WLC-B the client's session could be handed off.

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

How man wirelesslancontrollers are permited configure into the same mobility group?

Hi Ricardo,
Just to add a clip to the good info from David and Larry (5 points to both of you!);
A mobility group can include up to 24 controllers of any type. The number of access points supported in a mobility group is bound by the number of controllers and controller types in the group.
Examples:
1. A 4404-100 controller supports up to 100 access points. Therefore, a mobility group consisting of 24 4404-100 controllers supports up to 2400 access points (24 * 100 = 2400 access points).
2. A 4402-25 controller supports up to 25 access points, and a 4402-50 controller supports up to 50 access points. Therefore, a mobility group consisting of 12 4402-25 controllers and 12 4402-50 controllers supports up to 900 access points (12 * 25 + 12 * 50 = 300 + 600 = 900 access points).
From this good doc;
http://www.cisco.com/en/US/docs/wireless/controller/4.0/configuration/guide/c40mobil.html
Hope this helps!
Rob

Wireless 5508 WLC's in a Mobility Group

All,
Scenario: Would like redundancy on 2 x 5508's but unable to utilise HA (SSO) due to internal WLC DHCP requirements.
Mobility groups - Can 2 controllers in the same mobility group share a DHCP scope? I.E overlapping addresses or would the scope need to be split across controllers?
If scopes are slit hat happens to DHCP requests once the primary DHCP server has allocated all leases? Also what happens if a clients joined controller A receives valid IP address then controller A goes off line? AP's re-establish with controller B but client has invalid scope IP?
Cheers,
Jay

Hi,
Actually in the Mobility Group you enable the user to move form one WLC APs coverage to other WLC APs coverage with same client IP configuration.. so if we make groups then obviously we should make different DHCP scope to avoid network address range exhausted.
As far as controller A is up, IP configuration on wireless client would be remain same, but if your controller A goes off then the client will acquire the new IP from different DHCP scope which is assigned to controller B.

Layer 2 & Layer 3 Controllers in Same Mobility Group

Similar Messages

Maybe you are looking for