Wireless Access

What is the current recommended practice for deploying redundant controllers for VIA clients.   At one time I thought I was told that using a VRRP address was not recommended due to an unknown issue to me; is that still the case?

The customer has 2 x 3600 controllers running 6.2, both licensed for PEF-V.  They are already deployed in a master-local pair, so a redundant master setup that is recommended in the VRD is not possible.   These controllers also service Campus APs and a handful for Remote APs; well within the capacity guidelines.    We have a few possible scenarios we could use.....wondering if any real world experience from others will help us decide the best approach for this customer.

1) VRRP between controllers; have external IP NAT'd to the VRRP address (I've used this method in the past, but as mentioned above, thought there may have been an issue along the way)

2) Use a load balancer (F5) in front of the controllers (either active/standby or even distribution)

3) Use round robin DNS pointing to unique NAT'd IPs for each controller

Whichever solution works best, is the same hold true for Remote APs?

Or, is it better to just define two VIA servers within the connection profile, and allow the client to automatically fail to the other?

For now, the only way is to provision two profiles.  The client will not automatically fail to the second, however.  I do not know if that is scheduled to change.

Thanks Colin.  Couple of follow ups:

1) I know the other methods I mention technically work, are you suggesting they technically are not supported?

2) The 6.2 user guide mentions the following for th e "Enable Controllers Load Balance" setting"

Enable this option to allow the VIA clientto failoverto the next available selected randomly from the list as configured in the VIA Servers option. If disabled,VIA will failover to the nextin the sequence ofordered list of VIA Servers.   

Also, the VIA AppNote has this description for the same setting:

This parameter enables load balancing of VIA clients by randomly choosing a controller from the list of available VIA controllers that can be used for connection. This feature does not take the current load of the controller into account.  NOTE: This option is available in VIA 2.1 with ArubaOS 6.1.3.1 and later

Unless I am interpreting it wrong, it sounds like it does have the ability to fail to the next by these descriptions.   I don't have the ability to test this however.

3) The VIA AppNote suggests an all master design is recommended (master/standby) for Aruba mobile access deployments (page 7).  

An all-master design is recommended for Aruba mobile access deployments. The use of redundant controllers and the SSL fallback option on VIA clients ensures high availability of this architecture.

But that's all it says, nothing further about how that redundancy is setup from a profile standpoint.    Since the Active/Standby state of an all-master deployment is dependent on VRRP; would that in essence be the same as using the VRRP between a master and local?  

Thanks....

It seems like someone was not even considering the fact that you might be talking about 6.2 ;)

We will get someone to answer your questions.

There is option in VIA connection profile "Enable Controllers Load Balance" which can be used. But this option is just for failover it doesnt do any "load balance". For this in the same connection profile you have to define all the controller IPs and you have to have the same configuration across these controllers.

The information in the APP note is correct.

I have used VRRP for VIA with (master/standby), and found things seem to work fine.

Let me know if you need any more info on the same.

Thanks for the reply.....

So......it sounds like using VRRP would be a viable option so long as the two controllers are setup the same.    If not, using two server definitions in the connection profile will allow the client to automaticaly fail to a second should one become unavailable.  

Would using a load balancer be considered "unsupported"?

I wont say it is unsupported. All I can say is I have not tried it.

I'll work with this particular customer and we'll explore each option in more detail to suit their requirements.   Was just hoping for an "Aruba Recommends" or "Doesn't Recommend"  type answer. 

Thanks again.