Clustering of virtual controller?

[BigRic]

We’ve got a new deployment of (8) 8533 AP’s and (8) 7632 AP’s. We’d like to set up two of the 8533’s as redundant virtual controllers (like a typical “cluster” of vx9000’s or older WM3600’s). I can’t seem to find any way to do this officially and I’m wondering if it’s only possible via the CLI (or if it’s possible at all). I’ve only done this once before on a full blown controller. If it is possible, can it be done in the UI? Are there any gotcha’s to look out for?

Thanks

Eric

[Christopher_Fra · Accepted solution]

Hello Rick,

      You can have all of the AP8533s in the same AP Profile and instead of using static IP addressing on VLAN 67 and use DHCP (possibly reservations). Have the AP76xx in their own AP Profile and I would disable rf-domain capable on this AP profile. 

When you configure auto-elect VC feature for the AP8533s, you can use the ,21 as the virtual IP and whatever AP is the VC at the time you try to access .21, only that AP will respond. This way you do not need to keep track of what AP is the VC.  

[BigRic]

Thanks @Christopher Frazee. How will this impact a new / backup VC? I’m assuming it’ll adopt on L2 (same as the initial one I setup manually) using MINT, then apply the profile which will eliminate the dependence on V1 by only having the trunk and vlan settings mentioned? A problem I have is that this client installed 7 of the 8 8533’s to the warehouse ceiling so I can only physically get to one of them (they didn’t run a console cable to the others). I can pretty quickly access and fix the controller settings on the first unit, but I’m worried that if one of the others comes online and anything is awry, I may get into a sticky situation trying to recover. Thinking I can use a provisioning rule that only puts the auto-VC profile on 2 specific AP’s, that way I avoid having them jump around based on MINT id...When we typically do these I have console access to all of them, so I’m being extra careful trying to plan this out. Thanks again for the detailed responses!

[Christopher_Fra]

Hello Rick,

     I would bypass the install wizard and configure the VC interfaces at device level. You will need to perform the same for the AP profiles.

The following is CLI syntax, after successful login on VC:

enable [enter]
self [enter]
interface vlan 67 [enter]
ip address xxx.xxx.xxx.xxx/yy [enter] (x represents ip address and y represent subnet)
exit [enter]
interface ge1 [enter]
switchport mode trunk
switchport trunk native vlan 67
no switchport trunk native tagged
switchport trunk allowed vlan 60,67-68
exit [enter]
commit write [enter] 

You will want to remove VLAN 1 reference on the AP profiles. 

[BigRic]

Just went through the docs. Very helpful. Still, seem to have problems in our vlan / trunking config. Is anyone able to provide a suggestion for the steps to make this work:

• AP ports are untagged on v67, tagged on 60/68
• v67 is adoption network. DHCP coming from firewall subinterface on this vlan
• Example, DHCP scope is 10.66.140.50-100, we’ll assign controller on .21 in same subnet
  • All AP LAN interfaces will be DHCP
• We are bridging at the GE1 port on each AP

If we leave all of the AP wizard settings as V1 (doesn’t matter, since we’re untagged on the adoption network anyway), it works - I just have a pet peeve when it comes to the actual vlan being different. Perhaps the wizard is just kind of funky when setting up non default vlans?