Skip Links

Network World

  • Social Web 
  • Email 
  • Close

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
  • Comment
  • 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.

  • Share/Email
  • Comment
  • Print
Comment
Login
Forgot your account info?
Add comment
Anonymous comments subject to approval. Register here for member benefits.
Have a NetworkWorld account? Log in here. Register now for a free account.

Videos

rssRss Feed