Controller Redundancy Design

Recall that the AP discovery and join decision process first looks for a defined primary, secondary, or tertiary WLC (as specified by the controller's sysName). An AP's second choice is to join a

WLC configured as a master controller. This is typically used only on initial AP deployment to find an initial controller, at which time the AP should be configured with its deterministic controllers.

The last choice in the AP join decision algorithm is to try to dynamically choose a WLC based on the greatest availability for AP associations. Using this process, WLCs can support either dynamic or deterministic redundancy.

Dynamic Controller Redundancy

The LWAPP protocol supports dynamic controller load balancing and redundancy. In the controller LWAPP Discovery Response, the WLC embeds information about its current AP load (defined as the number of APs joined to it at the time), its AP capacity, and the number of wireless clients connected to the controller.

With dynamic load balancing, an AP attempts to join the least-loaded controller, defined as the controller with the greatest available AP capacity. Dynamic load balancing works best when the controllers are clustered in a centralized design.

This dynamic load balancing can also be the basis for a dynamic controller redundancy scheme. Recall that when an AP misses a heartbeat acknowledgment from a WLC, the AP resends the heartbeat messages up to five times at 1-second intervals. If no acknowledgment is received after five retries, the AP declares the controller unreachable, releases and renews its IP address, and looks for a new controller. The advantages of dynamic controller redundancy are that it is easy to deploy and configure, and that APs dynamically load-balance across WLCs. Disadvantages include the following:

■ More intercontroller roaming

■ More operational challenges because of the unpredictability of traffic patterns

■ Longer failover times (than with deterministic redundancy)

With dynamic load balancing, the APs can join controllers in no particular order or sequence, which might be acceptable if there are not many roaming clients. However, if many clients are roaming, many intercontroller roaming events can have a potential impact on aggregate network performance.

Traffic patterns from wireless clients are unpredictable, making it difficult to implement stateful security mechanisms in the infrastructure and take advantage of some other security features in Cisco switches. For example, if the APs are enabled sequentially with dynamic redundancy, the network can develop a "salt and pepper" AP design, where adjacent APs are joined to different controllers, as shown in Figure 9-26. Every odd-numbered AP is joined to WLC1, and every even-numbered AP is joined to WLC2. In theory, this design provides for dynamic traffic load-balancing across WLCs and coverage redundancy in the event of a WLC failure. However, in actual practice, this type of design can result in a large number of intercontroller roaming events and therefore generally is not widely recommended or deployed.

Figure 9-26 Dynamic WLC Redundancy May Result in a "Salt and Pepper" Design

Figure 9-26 Dynamic WLC Redundancy May Result in a "Salt and Pepper" Design

NOTE LAG supports dynamic controller redundancy.

Deterministic Controller Redundancy

With deterministic controller redundancy, the network administrator statically configures a primary, a secondary, and, optionally, a tertiary controller. Advantages of using deterministic controller redundancy include the following:

Predictability (easier operational management) Higher network stability

More flexible and powerful redundancy design options

Faster failover times

Fallback option in the case of failover

When an AP determines, from missed heartbeat acknowledgments, that its primary controller is unreachable, it attempts to join the secondary controller. If the AP fails to join the secondary controller, it attempts to join the tertiary controller. If the primary, secondary, and tertiary controllers are not available, the AP resorts to the dynamic LWAPP algorithms to connect to the least-loaded available controller.

KEY POINT

Failover to a defined secondary or tertiary controller is more rapid than dynamic failover to the least-loaded controller.

With this process, the network administrator can deterministically predict the results of an AP reassociation, resulting in easier operational management of the WLAN. The network can be designed for WLC infrastructure redundancy, and extra capacity on the secondary and tertiary controllers can be provisioned to be available in the event of catastrophic WLC failures.

WLCs have a configurable parameter for AP fallback. When the WLC AP fallback option is enabled, APs return to their primary controllers when the primary controller comes back online after a failover event. This feature is enabled by default, and some administrators choose to leave the AP fallback default value in place. However, when an AP falls back to its primary controller, there is a brief window of time, usually approximately 30 seconds, during which service to wireless clients is interrupted because the APs are rejoining the primary WLC. Also, if connectivity to the primary WLC has become unstable for some reason, the AP might "flap" back and forth between a primary and the backup WLCs. Many WLAN administrators prefer to disable the AP fallback option and move the APs back to the primary WLC in a controlled manner, during a scheduled service window.

A disadvantage of deterministic controller redundancy is that it requires more upfront planning and configuration. The configuration of primary, secondary, and tertiary WLCs can be performed somewhat laboriously on each AP, or more easily using templates with the Cisco WCS.

Figure 9-27 shows three APs configured with primary, secondary, and tertiary WLCs. If WLC-B fails, its attached AP connects to WLC-C. If WLC-A fails while WLC-B is down, its APs connect to WLC-C.

Figure 9-27 Deterministic WLC Redundancy

WLAN-Controller-A

WLAN-Controller-B

WLAN-Controller-C

Figure 9-27 Deterministic WLC Redundancy

WLAN-Controller-A

WLAN-Controller-B

WLAN-Controller-C

Primary: WLAN-Controller-A Secondary: WLAN-Controller-B Tertiary: WLAN-Controller-C

Primary: WLAN-Controller-B Secondary: WLAN-Controller-C Tertiary: WLAN-Controller-A

Primary: WLAN-Controller-C Secondary: WLAN-Controller-A Tertiary: WLAN-Controller-B

Primary: WLAN-Controller-A Secondary: WLAN-Controller-B Tertiary: WLAN-Controller-C

Primary: WLAN-Controller-B Secondary: WLAN-Controller-C Tertiary: WLAN-Controller-A

Primary: WLAN-Controller-C Secondary: WLAN-Controller-A Tertiary: WLAN-Controller-B

KEY POINT

Cisco recommends using deterministic controller redundancy with predefined primary, secondary, and tertiary controllers, rather than using dynamic controller redundancy.

Deterministic Redundancy Options

There are three options for the design of deterministic controller redundancy, as described in the following sections.

N + 1 Redundancy Design

KEY POINT

In an N + 1 configuration, the one redundant controller in a network operations center (NOC) or data center acts as a backup for multiple other WLCs.

This scenario is illustrated in Figure 9-28. Each AP is configured with a WLC as primary; all APs are configured with the one redundant controller as secondary.

Figure 9-28 N + 1 Deterministic WLC Redundancy

Figure 9-28 N + 1 Deterministic WLC Redundancy

WLAN-Controller-1

WLAN-Controller-2

APs Configured with:

Primary: WLAN-Controller-1 Secondary: WLAN-Controller-BKP

APs Configured with:

Primary: WLAN-Controller-2 Secondary: WLAN-Controller-BKP

WLAN-Controller-n

APs Configured with:

Primary: WLAN-Controller-n Secondary: WLAN-Controller-BKP

One issue with this design is that the redundant controller could become oversubscribed in the unlikely event of multiple primary WLC failures. When a WLC has reached the maximum number of joined APs, it does not accept any more LWAPP Join requests. Consequently, if the backup WLC becomes oversubscribed, some APs might not be able to join with a WLC. Therefore, when designing an N + 1 redundant solution, you should assess the risks of multiple WLC failures and the consequences of an oversubscribed backup WLC.

N + N Redundancy Design

KEY POINT

In an N + N redundancy configuration, N controllers back up N controllers.

For example, Figure 9-29 has two controllers. Some of the APs are configured with controller A as primary and controller B as secondary; the other APs are configured to use controller B as primary and controller A as secondary.

Figure 9-29 N + NDeterministic WLC Redundancy

Figure 9-29 N + NDeterministic WLC Redundancy

In this design, the AP capacity across both controllers should be balanced. APs should also be logically grouped on controllers to minimize intercontroller roaming events. For example, in a four-floor building with two redundant controllers, the APs on floors 1 and 2 could be configured to use one controller as primary and the APs on floors 3 and 4 could be configured to use the other controller as primary. Enough excess capacity must be provisioned on each controller to handle a failover situation.

N + N +1 Redundancy Design

KEY POINT

In an N + N + 1 redundancy configuration, N controllers back up N controllers as secondary, and one additional controller backs up all N controllers as tertiary.

For example, in Figure 9-30 some of the APs are configured with controller A as primary and controller B as secondary; the other APs are configured with controller B as primary and controller A as secondary. All the APs are configured to use the same backup controller as tertiary. Typically, the primary and secondary controllers are placed at the network distribution level, and the single tertiary controller is placed in a NOC or data center. Multiple distribution blocks can be configured with the same tertiary controller.

Figure 9-30 N + N + 1 Deterministic WLC Redundancy

Figure 9-30 N + N + 1 Deterministic WLC Redundancy

APs Configured with:

Primary: WLAN-Controller-A Secondary: WLAN-Controller-B Tertiary: WLAN-Controller-BKP

APs Configured with:

Primary: WLAN-Controller-B Secondary: WLAN-Controller-A Tertiary: WLAN-Controller-BKP

APs Configured with:

Primary: WLAN-Controller-A Secondary: WLAN-Controller-B Tertiary: WLAN-Controller-BKP

APs Configured with:

Primary: WLAN-Controller-B Secondary: WLAN-Controller-A Tertiary: WLAN-Controller-BKP

When selecting a redundancy option, consider the risks of WLC failure and the service level agreement (SLA) required to be maintained by the WLAN. The higher the SLA, the more robust redundancy scheme your designed solution should provide.

Was this article helpful?

+7 -1

Post a comment