* AP and controller infrastructures need redundancy, too
The last few newsletters have examined industry efforts to improve over-the-air uptime in wireless LANs. But the RF portion of the network is just part of the equation. The AP infrastructure and WLAN controllers require high-availability schemes, too, to ensure that WLANs perform comparably to good ole Ethernet.
As noted last week, if an AP fails, one of two things is likely to happen, depending on the vendor’s architecture: A nearby AP will increase its power output to fill in the gap, or the network will route around the failure to another AP, likely using a mesh setup. This brings up some questions:
1) Can you keep an AP (and its WLAN controller connection) from failing in the first place so as not to cause a ripple effect of increased loads and congestion in nearby APs?
2) If an AP does fail and a client re-associates to a new AP that’s connected to a different WLAN controller at the back end, what is the impact on availability?
A quick look at each of these issues follows, and the next newsletter will round out the WLAN high-availability series with a look at redundancy in controller architectures.
AP port and link redundancy
In controller-based architectures, most vendors dual-home an AP to two back-end WLAN controllers. Some designate one cable as the data path and the other as the power path. Most can load-share across the two connections while everything is working as it should, but then failover to one link or the other if one port or link should fail. This is one way to keep from losing an AP altogether because of a single port failure.
AP or AP-to-controller link failure
Depending on the network, this change might be a non-event or cause a hiccup or a disconnected session. Some setups, such as Trapeze Networks’ SmartMobile architecture, use the concept of a “mobility domain” to prevent a client from having to re-authenticate at the back end, which can create delay and disrupt sessions. Others – Aerohive, Colubris/HP Procurve and Xirrus, for example – don’t use controllers, so there is no potential for an AP-to-controller link failure or worries about a controller failure.
How vendors handle controller failures will be described in the next newsletter.
