WLAN availability: Beyond the air
AP and controller infrastructures need redundancy, too
Wireless Alert
By
Joanie Wexler
,
Network World
, 11/03/2008
Sign up for this newsletter now!
Joanie Wexler looks at how enterprises can take advantage of wireless LANs and WANs.
- Share/Email
- Tweet This
- Print
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.
Joanie Wexler is an independent networking technology writer/editor in Silicon Valley.
Comment