Mobility Groups query

[Daniel Anderson]

Hi,

We have a Guest Wireless solution in place whereby we have 4 remote WLCs and an Anchor Controller providing the termination point for the Guest internet tunnels.

We currently have an inconsistent issue, whereby idle clients are seemingly dropping their connections for no apparent reason (The session timeout and User Idle timeout have been modified accordingly). Another possible option I'm now looking at is the Mobility Groups configuration, having read something on another thread. We currently have all 5 (4 x Remote and 1 x Anchor) configured in the same Mobility Group. From what I've read, I should have the 4 x Remote WLCs in one Mobility Group and the Anchor device in its own group. Is someone able to clarify this.

Also, if we have all 5 device in the same group, what are the implications of this? Obviously, only the Remote devices would be managing the Access Points, so the roaming would be happening between these 4 devices, rather than the additional Anchor also configured in the Group.

Thanks in advance.

[Scott Fella]

You can setup your mobility either way. Best practice is to have them different, but that will not improve your issue. Can you be more specific as to devices that you see that timeout?

[Stephen Rodriguez]

The reason you put the anchor in a different group, is so that the AP won't join it if the internal ones fail. Other than that, you can have them all in the same mobility group, if you want to.  Just be advised the DMZ may have AP try to join it.

Steve

[Daniel Anderson]

That's good to know. Our Access Points have no visibility of the Anchor Controller, so I'm not concerned about any device trying to join it.

To extend on our current issue; we have an SSID created for a Guest network with Layer 3 authentication configured (across all 4 controllers). Clients are able to connect and authenticate (via AD) as expected, but we're seeing issues whereby clients are dropping off the network at intermittant intervals, and having to re-authenticate when they next connect. The devices connecting are a mixture of Android and iOS handsets.

The Session timeout for the WLAN isn't enabled on any of the SSIDs, and the User Idle timeout on all controllers is set to 8 hours. I've not as yet managed to perform any debugs to see what's causing the disconnects, but plan to do this tomorrow morning. I believe the above mentioned handsets are generally clean with regards Wireless connectivity when they're in power save mode, but was hoping modifying the timeouts mentioned would potentially resolve the issues we're seeing.

TIA

[Scott Fella]

Well... I know for one, the iOS devices don't roam as well as a laptop or macbook.  The issues I have seen with these devices is that they are "Sticky" and seem to like to stay connected to an ap that they have already associated with.  I don't think its the timeouts, you might just want to see if roaming is the issue which causes the timeout mechanism to start.

[Saravanan Lakshmanan]

WLC foreign and anchor code ?

is it open auth and AD?

onboard or external dhcp used for guest?

get debug client from foreign(s) and anchor, if possible with mobility-handoff enabled.

[Daniel Anderson]

Foreign and Anchors are all running 7.0.220.0. Layer 3 Auth is using AD via a configured Radius box.

DHCP is handed out from the Guest Anchor controller.

We have some other Guest Internet networks in place, these are mainly utilised by laptops, we're not seeing any particular issues on these.

I'm planning on running some Debugs today, to try and get a better understand of why the devices appear to be dropping off.