AP redundancy with mobility groups

[roadhouse1387]

HI,

Quick question,..

I have two 4402 WLC's running 5.1.151.0 and a number of 1131AG ap's.

I have the two wlc's configured in a mobility group which is working fine.

Both interfaces, on both wlc's are connected to different pairs of switches with differing vlan loads. WLC1 has its management, AP-Mgr1 and AP-Mgr2 interfaces in vlan 'A' and WLC2 has its interfaces in vlan 'B'.

I have been testing this design out for a little while now and the inter-subnet roaming seems to be working fine.

The question I have is to do with AP failover behaviour.

If i pull the plug on port 2 of WLC1 for example, all the AP's which were using port 2 for their AP Manager interface jump to controller 2. Whilst this works, I would have thought it would simply move to port 1 on WLC1 ?

Without the mobility group, the AP would just move to port 1 on WLC1 which is faster than waiting for the AP to move controllers.

Is this normal behaviour ?

Cheers

Shaun

[#2]

Shaun configure the controller to have LAG ports and set up etherchannel on your switches.

http://www.cisco.com/en/US/docs/wireless/controller/5.1/configuration/guide/ccg51.html

Sample config for your switch---

----------------------------------------

interface Port-channel 1

description *********Connection to WLC****

switchport trunk encapsulation dot1q

switchport mode trunk

interface GigabitEthernet x/x or x/x/x

description *****to wlc *******

switchport trunk encapsulation dot1q

switchport mode trunk

speed 1000

duplex full

channel-group 1 mode on

!

interface GigabitEthernet x/x or x/x/x

description ***** To WLC *******

switchport trunk encapsulation dot1q

switchport mode trunk

speed 1000

duplex full

channel-group 1 mode on

-------------------------------------------

and then at global config also config this:

port-channel load-balance src-dst-ip

This is per best practices guide when using LAG (Link Aggregation)

Hope this helps

[roadhouse1387]

Hi Greg,

Thanks for that, it does help.

In my lab, I have stack switches, so LAG would mean connecting the WLC to a single switch. I was trying to avoid that if possible.

However, in deployment, these will be connected to a pair of cat6k's via single sup720-vss (no vss deployed but this sup has 3xSFP and the other blades are 10gig). So rather than trying to connect the wlcs between the 6ks'or even connecting them to an edge stack, I would be better off connecting one wlc to each 6k with LAG and use the mobility to provide the redundancy.

Losing a link in the bundle will not cause the the AP's to jump wlc's and if i lose the entire bundle then i have probably lost the sup anyway.

I think I was getting to caught up in my lab and LAG does look like the way forward.

Cheers Greg,

Shaun

[#4]

Shaun glad that i was able to help you. LAG is defantley the way to go. Once you do it that way you wont go back I promise.

And you hit the nail on the head put one wlc per controller that will work for you.

Also fyi found this in the release notes for you version of code:

CSCsi26248-After a failed link aggregation (LAG) link recovers, you might lose connectivity for approximately 30 seconds

I also looked at the next release 5.1.163 it was not fixed in there either

no in 5.2

Probally wont be a major issue with you though.

Thanks

Greg