Trapeze Networks MX-2XX-HA-LIC Data Sheet

enabled on which access points throughout the 
network. It is a holistic approach that is both 
more efficient and more comprehensible.

Once the service profiles have been defined and 
created, they are pushed down to one primary 
controller, known as the “seed” controller, which 
in turn distributes the unified configuration to 
all other controllers in the Virtual Controller 
Cluster. Any controller may be the “seed”. 
Primary and secondary “seed” controllers are 
defined during the initial setup of the Virtual 
Controller Cluster. Should the primary “seed” 
fail, the secondary “seed” takes over.

Members of the Virtual Controller Cluster col-
laborate with one another to intelligently deter-
mine the optimal balance for the operational 
load. Working as a community, the controllers 
in the cluster use load-balancing and capacity 
planning algorithms to efficiently and dynami-
cally share access-point control. 

If a new controller is added to the cluster it is 
equivalent to adding a slice of capacity to the 
pool.  Access Points simply get redistributed to 
spread the load more evenly across the greater 
pool of resources. Similarly, if a controller is 
removed from the cluster - either for mainte-
nance or due to failure - the access points are 
again redistributed for optimal loading.

In the traditional hot-standby mode of redun-
dancy configuration, each access point “boots” 
from, and is thereafter controlled by, a primary 
controller, but also has a secondary controller 
defined from which it will “boot” if the primary 
controller is unavailable. This sense of having 
“fixed” devices that an access point is tied to, 
has its merits. For one thing, on a large campus 
with more than one data center, or physically 
distributed controllers, it lets administrators 
keep traffic local and avoid wasting backbone 
bandwidth with control-plane traffic. The High 
Availability Module allows these benefits to be 
preserved even in a clustering mode, by option-
ally allowing the APs to use a “preferred” group 
of controllers from within the cluster.

In a traditional Hot-Standby redundancy con-
figuration, when a controller goes offline, so 
do its APs. Even if APs are dual homed (either 
directly or indirectly) to another controller, 
they must drop all sessions, before reconnect-
ing to a “hot standby” controller.  This typically 
takes 15-20 seconds. Regardless how short the 
boot time, for a user that was in a phone call, 
or a doctor in the middle of reviewing patient 
records, the interruption is more significant. 
Many disrupted applications will require not 
only re-authentication of the devices, but also 
logging again at the application level. 

The Virtual Controller Cluster approach, avoids 
these service interruptions altogether.  In a con-
troller down scenario – any event that takes the 
controller out of service - the many-to-many 
redundancy allows the APs previously assigned 
to the offline controller to be redistributed 
among remaining controllers in the cluster, 
instantaneously.  Without losing a single active 
session - not even voice calls.  

Since the reliability is so robust, it means 
administrators can perform in-service upgrades, 
adds, moves and changes, at their convenience, 
without any risk of downtime. There is no need 
to schedule downtime - ever.  This is a great 
bonus for 24/7 operations such as hospitals and 
factories. 

When adds, moves and changes are effected, 
there is no secondary maintenance to be per-
formed - not so with the hot-standy approach, 
in which every change on a primary controller, 
must also be replicated (and tested) on the   
hot-standby.