Enterprise controller design guide 4 21

tme:enterprise_controller_design_4.2 - wnbu-tme wiki http://wnbu-tme.cisco.com/dokuwiki/doku.php?id=tme:enterpri Cisco Confidential Cisco Campus Wireless LAN Controller Design Guide 4.2 Executive Summary The Cisco Unified Wireless Network (CUWN) supports business critical, mobile applications The base components of the CUWN are Wireless LAN (WLAN) controllers, wireless access points, and the Wireless Control System (WCS) management software This paper provides architectural understanding and design guidance for WLAN Controller deployments Key topics include Lightweight Access Point Protocol (LWAPP), WLAN security support, mobility, radio resource management, controller placement in the network, and support for network redundancy 1.0 Introduction Modern business-class Wireless LAN (WLAN) networks must support mission-critical data applications as well as important networked of 40 10/15/08 10:22 PM tme:enterprise_controller_design_4.2 - wnbu-tme wiki http://wnbu-tme.cisco.com/dokuwiki/doku.php?id=tme:enterpri services, such as Voice Over WLAN (VoWLAN), Location-Based Services (LBS), and converged applications Furthermore, these WLANs must be high-performance, resilient, scalable, manageable, and easy to deploy The Cisco Unified Wireless Network (CUWN) is designed to meet these challenges and represents the current generation of 802.11 WLANs from Cisco Systems Cisco customers are rapidly adopting the CUWN for a new level of WLAN performance, scalability, manageability, and services and application support This document reviews the fundamental architectural concepts and design considerations necessary to successfully plan for and design a CUWN This document covers architectural fundamentals of the CUWN and common design considerations The document targets Cisco Systems Engineers, Consulting Systems Engineers, Cisco Partners, and technical customer staff The document assumes an understanding of 802.11 WLAN fundamentals and basic Cisco networking This document is written assuming version 4.2 of the Cisco WLAN controller software Glossary of Terms and Acronyms Glossary of Terms and Acronyms Term or Acronym Definition 802.11 IEEE Protocol defining basic behavior of a Wireless Local Area Network IEEE Addendum to the 802.11 Protocol defining secure authentication and 802.11i encryption for data access A network device that acts as a translational bridge between a radio link and a AP/Access Point wired data link Acronym for “Control And Provisioning of Wireless Access Points,” and IETF Working Group effort to standardize a set of control and data access protocols CAPWAP for mobile networks, including 802.11 WLANs CAPWAP is based on the LWAPP RFC draft Cisco Centralized Key Management A Cisco proprietary technique for fast Cisco CKM re-authentication and re-keying of roaming client sessions CUWN Cisco Unified Wireless Network Ethernet in IP A protocol for rapid encapsulation of layer Ethernet frames EtherIP inside an IP tunnel EtherIP is defined by RFC 3378 Acronym for Hybrid Remote Edge Access Point An operational mode for H-REAP access points that allows local data traffic bridging instead of centralized bridging at a WLAN controller Acronym for Link Aggregation WLAN controller implementation of static LAG Etherchannel LAP/Lightweight An access point that is controlled by a WLAN Controller device via the LWAPP Access Point protocol Lightweight Access Point Protocol Control and data encapsulation protocol for LWAPP the CUWN A cluster of controllers that share client information for the purposes of Mobility Group seamless roaming Proactive Key Caching An extension to an optional component of the 802.11i PKC that allows for fast re-keying and re-authentication of roaming WLAN clients Self-forming cluster of WLAN controllers that cooperate in running RRM RF Group algorithms Radio Resource Management An advanced set of features in the CUWN for RRM dynamically managing radio transmit power and channel plans VoWLAN Voice Over IP Over Wireless Local Area Network WLAN Wireless Local Area Network WLAN Controller A intelligent layer-2 network device that controls a set of lightweight APs, enabling the WLAN network to operate as an intelligent WLC WLAN system with support for modern and advanced business applications and services Wi-fi Protected Access An interoperability certification for secure authentication and encryption for data access, based on IEEE 802.11i standards WPA/WPAv2 document, from the Wi-fi Alliance industry consortium This is the WLAN industry's baseline for data access security of 40 10/15/08 10:22 PM tme:enterprise_controller_design_4.2 - wnbu-tme wiki http://wnbu-tme.cisco.com/dokuwiki/doku.php?id=tme:enterpri Icon Reference This document assumes readers are familiar with Cisco icons for Campus routing and switching We provide a table of icons specific to the CUWN for those new to the technology area Icon Cisco Unified Wireless Network Icons Description 3750G Integrated WLAN Controller Switch Icon Dual-radio Lightweight Access Point Icon Single-radio Lightweight Access Point Icon RF Link Icon General WLAN Controller Icon WiSM Specific Icon 2.0 Understanding the Cisco Unified Wireless Network Architecture In this section, we will examine the fundamental building blocks of the CUWN and architecture After a brief overview of the CUWN, we will look at the Lightweight Access Point Protocol (LWAPP) in depth and examine how packets enter and traverse the network In later sections, we will look at how Cisco extends the architecture to support seamless mobility and advanced features Since this document focuses on practical design concepts of the Cisco Unified Wireless Network solution, a detailed, bit-and-byte discussion of the architecture and LWAPP is outside our scope We will however, review the fundamentals in some detail to provide the foundation for discussions to follow in the rest of the document 2.1 Basics of the Cisco Unified Wireless Network Architecture The basics of the Cisco Unified Wireless Network are illustrated in Figure 1: of 40 10/15/08 10:22 PM tme:enterprise_controller_design_4.2 - wnbu-tme wiki http://wnbu-tme.cisco.com/dokuwiki/doku.php?id=tme:enterpri The CUWN architecture centralizes WLAN configuration and control into a device called a WLAN Controller (WLC) This allows the entire WLAN to operate as an intelligent information network that uses wireless as the access medium to support advanced services, unlike legacy 802.11 WLAN infrastructures that are built from autonomous, discrete access points The CUWN simplifies operational management by collapsing large numbers of managed end-points—autonomous access points—into a single managed system comprised of the WLAN controller(s) and its corresponding, joined access points In the CUWN architecture, APs are “lightweight”, meaning that they cannot act independently of a WLC APs are typically “zero-touch” deployed and no individual configuration of APs is required The APs learn the IP address of one or more WLC via a controller discovery algorithm and then establish a trust relationship with a controller via a “join” process Once the trust relationship is established, the WLC pushes firmware to the AP if necessary and a run-time configuration APs not store a configuration locally Once joined to a controller, the APs are also lightweight in the sense that they handle only a subset of 802.11 MAC functionality Typically, this subset includes only real-time 802.11 MAC functionality, with the controller handling all non-real-time 802.11 MAC processing This division of 802.11 labor is called “Split MAC” and enables the architecture to seamless mobility and a number of advanced features in an elegant and scalable way As you can see from Figure 1, APs interact with the WLAN controller via the Lightweight Access Point Protocol (LWAPP) LWAPP defines the following: Control messaging protocol and format Data encapsulation LWAPP Control messages are exchanged between the WLC and AP for a variety of reasons, including the controller discovery and join process, AP configuration and firmware push from the controller, as well as statistics gathering and wireless security enforcement WLC control messages are also used to support wireless station access, authentication, and mobility WLAN client data packets are encapsulated in LWAPP between the AP and WLC When a WLAN client sends a packet, it is received by the AP and encapsulated with an LWAPP header and forwarded to the controller At the controller, the LWAPP header is stripped off and the frame switched from the controller onto a VLAN in the switching infrastructure When a client on the wired network sends a packet to a WLAN client, the packet first goes into the WLC where it is encapsulated with an LWAPP header and then forwarded to the appropriate AP The AP strips off the LWAPP header and then bridges the frame on to the RF medium This process will be explained in detail in Section 2.3 Certain network architectures require some level of “hybrid” deployment LWAPP supports an architecture called “Hybrid REAP”, or H-REAP REAP is an acronym for Remote Edge Access Point In the H-REAP architecture, more 802.11 MAC processing is pushed to the network edge at the AP and some data traffic may be bridged onto the Ethernet LAN at the AP instead of being encapsulated in LWAPP and carried to the controller The H-REAP architecture is described in more detail in Section 2.3 2.2 Understanding LWAPP Fundamentals This section reviews the fundamentals of LWAPP, but is not an in depth bit-and-byte discussion Rather, it is intended to provide necessary background for the design scenarios and set the tone for further discussions The LWAPP protocol is defined by an IETF RFC draft document that is included in the IETF Control and Provisioning of Wireless Access Points (CAPWAP) working group’s efforts Ultimately, the CAPWAP working group will produce an industry standard wireless protocol, but today, LWAPP is the most mature protocol available As defined in the RFC draft, LWAPP is a generic mobility protocol with a binding definition for the IEEE 802.11 WLAN protocol Our discussion assumes the 802.11 binding since the CUWN is based on 802.11 technology LWAPP, in simple terms, defines how access point(s) communicate with WLAN controller(s) The LWAPP RFC defines the following: Control protocol and message format Data encapsulation of 40 10/15/08 10:22 PM tme:enterprise_controller_design_4.2 - wnbu-tme wiki http://wnbu-tme.cisco.com/dokuwiki/doku.php?id=tme:enterpri Transport modes for LWAPP Messages System level operational state machine Split and Local MAC processing modes The following sections will examine these LWAPP definitions in greater detail 2.2.1 LWAPP Protocol Messages LWAPP defines how APs and WLCs communicate with each other in the CUWN LWAPP defines both control messages and a data encapsulation mechanism 2.2.1.1 LWAPP Control Messages The LWAPP Protocol defines a control protocol and message format The LWAPP control protocol is used for the following purposes: WLC discovery by APs Establishing a trust relationship between APs and the WLC Downloading firmware to the APs Downloading configurations to the APs Statistics collection from the AP by the WLC Mobility related tasks Event notifications from the AP to the WLC Other tasks LWAPP Control messages are marked with a “Control Bit” or C-bit in the LWAPP encapsulation header that, when set to one, indicates the LWAPP Message is a control message We will look at many of these LWAPP control messages in functional context throughout this document 2.2.1.2 LWAPP Data Messages An LWAPP data message is a forwarded data frame, encapsulated inside an LWAPP transport header The C-bit in the LWAPP header of LWAPP data packets is set to zero When the data frame is forwarded from the AP to the WLC, the entire 802.11 frame received by the AP is encapsulated with the LWAPP header and then transported to the WLC using the appropriate LWAPP transport technology When the data frame is forwarded from a host on the wired network through the WLC to the AP, the WLC receives an Ethernet encapsulated frame The WLC strips off the Ethernet header and builds an 802.11 frame This frame is then encapsulated with an LWAPP header and transported to the WLC using the appropriate transport technology This process is discussed in further detail in Section 2.3 According to the LWAPP specification, the sender of the LWAPP packet—either the AP or the WLC—is responsible for fragmenting the frame when the encapsulated frame exceeds the transport layer MTU Re-assembly of the original fragmented frame is handled by the receiver—either the AP or the WLC—before the frame is processed further The fragmentation and reassembly process is described in further detail in Section 2.3 2.2.2 LWAPP Transport LWAPP messages are encapsulated in UDP datagrams and transported between the AP and WLC in network layer, IP packets Technically, this is known as “Layer LWAPP”, but for the sake of brevity, just “LWAPP” is used in this document There is a “Layer LWAPP” defined by the LWAPP RFC, in which LWAPP control and data messages are encapsulated in Layer-2 Ethernet frames, but this transport architecture is deprecated and not supported on any current AP platforms so it is not discussed in this design guide In Layer LWAPP Mode, LWAPP Control and Data messages are transported over the IP network in UDP packets Figure illustrates Layer LWAPP transport: of 40 10/15/08 10:22 PM tme:enterprise_controller_design_4.2 - wnbu-tme wiki http://wnbu-tme.cisco.com/dokuwiki/doku.php?id=tme:enterpri As shown in Figure 2, the LWAPP Control and Data messages are encapsulated in UDP packets that are carried over the IP network The only requirement is established IP connectivity between the APs and the WLC The LWAPP tunnel uses the AP’s IP address and the WLC’s “AP Manager” interface IP address as end-points The AP Manager interface is explained in further detail in the Section 3.2 On the AP side, both LWAPP Control and Data messages use an ephemeral port that is derived from a hash of the AP Ethernet MAC address as the UDP port On the WLC side, LWAPP Data messages always use UDP port 12222 On the WLC side, LWAPP Control messages always use UDP port 12223 Figure shows how LWAPP Control Messages, including the LWAPP Header with the C-Bit set to one and the LWAPP Control Message elements are transported in UDP packets encapsulated in IP Figure also shows how LWAPP Data Messages are also transported in UDP packets, with the C-Bit in the LWAPP Header set to zero Since the WLC is the point of ingress/egress for WLAN traffic, the IP address of WLAN clients like Host A comes from the pool of addresses on the network upstream of the WLC Details on how WLCs connect to networks are considered in Section 3.2 How data frames are bridged on and off the wired network are considered in Section 2.3 2.2.3 LWAPP State Machine The LWAPP RFC defines a state machine The state machine explains how infrastructure devices—specifically APs and WLCs—interact with each other from start up through operations The LWAPP RFC explains the LWAPP State Machine in detail; this section explains only some of the key states in the LWAPP state machine for the sake of simplicity Figure shows the simplified LWAPP State Machine: of 40 10/15/08 10:22 PM tme:enterprise_controller_design_4.2 - wnbu-tme wiki http://wnbu-tme.cisco.com/dokuwiki/doku.php?id=tme:enterpri As can be seen from Figure 3, the key states considered in this document are: Discovery Join Image Data Config Run Reset When an AP powers up or is rebooted, it first enters the “Discovery” state During the Discovery state, the AP searches for one or more candidate WLCs, from which is will select one to “join” If the AP cannot find a WLAN controller while in the Discovery state, it resets and then starts the Discovery state again After an AP finds one or more candidate WLCs during the Discovery state, it transitions to the LWAPP Join state In the LWAPP Join state, the AP selects a WLC from the candidates found in the Discovery state and attempts to establish a trusted relationship via the LWAPP Join process If the AP fails to establish a trusted, LWAPP Join relationship with a WLC during the LWAPP Join state, it will transition to the Reset state and then enters the Discovery state again On the other hand, if the trusted relationship between the AP and WLC is successfully established, the AP will transition to the Image Data state to download code or to the Config state to receive a configuration from the WLC Once the AP is successfully configured by the WLC, it enters the Run state and begins to process data to and from wireless clients The Run state is the normal operational state for the AP 2.2.3.1 Discovery and Join Process In this section we will look at the details of the LWAPP Discovery and Join states shown in Figure As discussed in Section 2.2.2.2, the AP enters the LWAPP Discovery state after booting up In the Discovery state, two important LWAPP Control messages are used—the LWAPP Discovery Request and the LWAPP Discovery Response The AP sends LWAPP Discovery Request messages to one or more WLCs, expecting an LWAPP Discovery Response message from the WLC Each WLC that responds to the LWAPP Discovery Request with an LWAPP Discovery Response gets put into a “Candidate WLC” list by the AP The AP will select the WLC to join from the Candidate WLC list Before discussing the details of the LWAPP Join process, we need to fill in the details of how the AP determines where to send the LWAPP Discovery Request messages The LWAPP RFC does not define how APs discover WLCs Cisco LWAPP APs implement a WLC hunting and discovery algorithm that is defined as follows First of all, the AP attempts to acquires an IP address, typically via DHCP DISCOVER, unless of course, it has previously been configured with a static IP address Subsequently: The AP broadcasts an LWAPP Discovery Request on the local IP subnet Any WLC that is connected on the local IP subnet will receive the Layer LWAPP Discovery Request Each of the WLCs receiving the LWAPP Discovery Request reply with a unicast LWAPP Discovery Response message to the AP When a feature called Over-the-Air Provisioning (OTAP) is enabled on a WLC, APs that are joined to the WLC advertise their known WLCs in neighbor messages that are sent over the air New APs attempting to discover WLCs hear these messages and then unicast LWAPP Discovery Requests to each of the WLCs learned via OTAP WLCs receiving the LWAPP Discovery Request messages unicast an LWAPP Discovery Response to the AP The AP maintains previously learned WLC IP addresses locally in NVRAM The AP sends a unicast LWAPP Discovery Request to each of these WLC IP addresses Any WLC receiving the LWAPP Discovery Request respond by sending an LWAPP Discovery Response to the AP These WLC IP addresses are learned by the AP from previously joined controllers The stored WLC IP addresses include previously joined controllers and controller IP addresses from the “Mobility List” of previously joined controllers DHCP servers can be programmed to return WLC IP addresses in vendor specific “Option 43” in the DHCP Offer to lightweight Cisco APs When the AP gets an IP address via DHCP, it will look for WLC IP addresses in the Option 43 field in the DHCP Offer The AP will send a unicast LWAPP Discovery Request to each of the WLCs listed in the DHCP option 43 WLCs receiving the LWAPP Discovery Request messages unicast a LWAPP Discovery Response to the AP The AP will attempt to resolve the DNS name “CISCO-LWAPP-CONTROLLER.localdomain” When the AP is able to resolve this name to one or more IP address, the AP sends a unicast LWAPP Discovery Request to the resolved IP address(es) Each WLC receiving the LWAPP Discovery Request will reply with a unicast LWAPP Discovery Response to the AP If, after steps through 5, no LWAPP Discovery Response is received, the AP resets and restarts the hunting algorithm of 40 10/15/08 10:22 PM tme:enterprise_controller_design_4.2 - wnbu-tme wiki http://wnbu-tme.cisco.com/dokuwiki/doku.php?id=tme:enterpri The controller hunting process repeats ad infinitum until at least one WLC is found and joined It is important to understand that during the LWAPP WLC discovery, the AP will always complete steps through to build a list of candidate WLCs Once the AP has completed the LWAPP WLC Discovery steps, it selects a WLC from the candidate WLC list and attempts to join that WLC Two important LWAPP Control messages are used in the LWAPP Join process—the LWAPP Join Request and the LWAPP Join Response The LWAPP Join process is illustrated in Figure 4: The AP sends an LWAPP Join Request to the WLC The WLC validates and authenticates the LWAPP Join Request and then responds with an LWAPP Join Response The AP validates and authenticates the LWAPP Join Response from the WLC If the LWAPP Join Response is valid and authentic, the LWAPP Join process is considered complete and the AP will transition into an operational state But how does the AP select a WLC from the candidate WLC list? WLCs embed important information in the LWAPP Discovery Response, including: the controller’s sysName, the controller type, the controller AP capacity and its current AP load (how many APs are joined to the WLC), and something called the “Master Controller” status The AP uses this information to make a controller selection, using the following precedence rules: If the AP has previously been configured with a primary, secondary, and/or tertiary controller, the AP will select these controllers based on precedence If the AP finds a match, it then sends an LWAPP Join to the secondary controller If the secondary WLC cannot be found or the LWAPP Join fails, the AP repeats the process for its tertiary controller When no primary, secondary, and/or tertiary controllers have been configured for an AP, or these controllers cannot be found in the candidate list, or if the LWAPP Join Requests to those controllers have failed, the AP then looks at the “Master Controller” status field in the LWAPP Discovery Responses from the candidate WLCs If a WLC is configured as a Master Controller, the AP will select that WLC and send it an LWAPP Join Request If the AP is unsuccessful at joining a WLC based on the criteria in (1) and (2), it will attempt to join the WLC with the greatest excess capacity The greatest excess capacity is defined as the ratio of currently joined APs to the total controller capacity expressed as a percentage As previously stated, once the AP selects a WLC, it sends an LWAPP Join Request message to the WLC, expecting an LWAPP Join Response The LWAPP Join process provides for strong, standards-based mutual authentication and encryption key derivation The encryption key is used to encrypt the payload of LWAPP Control messages after the join process is completed The payload of LWAPP Control messages (other than the LWAPP Discovery and Join sequences) is encrypted using the AES-CCM algorithm As a basis for explaining how the LWAPP Control Plane is protected, we must first establish these key facts: The AP and WLC have X.509 certificates burned into protected flash The X.509 certificates are signed by a private key that is burned into the devices at time of manufacture Both the AP and WLC have the appropriate public encryption keys installed The AP and WLC have certificates installed that allow them to trust the issuing certificate authority (of the AP or WLC certificate) All of the appropriate certificates and keys are burned into the AP and WLC at the time of manufacture, with the exception of APs that are upgraded from autonomous IOS to LWAPP mode of 40 10/15/08 10:22 PM tme:enterprise_controller_design_4.2 - wnbu-tme wiki http://wnbu-tme.cisco.com/dokuwiki/doku.php?id=tme:enterpri As shown in Figure 4, when the AP sends the LWAPP Join Request to the WLC, it embeds its X.509 certificate in the LWAPP message It also generates a random session ID that is also included in the LWAPP Join Request When the WLC receives the LWAPP Join Request, it validates the signature of the X.509 certificate using the appropriate public key for the AP and checks that the certificate was issued by a trusted certificate authority (CA) It also looks at the starting date and time for the AP certificate’s validity interval and compares that date and time to its own date and time If the certificate is properly signed and issued by a trusted CA, and the WLC’s date and time are within the start and ending parameters of the certificate’s validity interval, the WLC declares the AP valid and authenticated If the X.509 certificate “checks out”, the WLC generates a random AES encryption key The WLC plumbs the AES key into its crypto engine so that it can encrypt and decrypt future LWAPP Control Messages exchanged with the AP The WLC next encrypts the key using the AP’s public key, concatenates the resulting ciphertext with the session ID in the LWAPP Join Request, and encrypts the concatenated value using its own private key The WLC copies the results into the LWAPP Join Response along with its own X.509 certificate When the AP receives the LWAPP Join Response, it validates the WLC certificate signature using the WLC’s public key and checks that the certificate was issued by a trusted certificate authority If the WLC certificate is validated, the AP extracts the encrypted key portion It decrypts the concatenated ciphertext using the WLC’s public key and validates the session ID It then decrypts the AES key using its private key Finally, it plumbs the AES key into its crypto engine to secure future LWAPP Control Message exchanges with the WLC At this point, the LWAPP Join process is completed The AP maintains a key lifetime timer When the timer expires, the AP generates a new session ID and embeds it in an LWAPP Key Update Request control message to the WLC The WLC repeats the previously described key generation and distribution process and embeds the new ciphertext in an LWAPP Key Update Response The key lifetime timer is eight hours The X.509 certificates, certificate authority stores and public and private key pairs are burned into protected flash on both the AP and WLC at the factory by Cisco On the AP, factory installed certificates are called manufacturing installed certificates (MIC) All Cisco access points manufactured after July 18, 2005 have MICs Cisco Aironet 1120, 1130, 1200, 1240, and BR1310 access points manufactured prior to July 15, 2005 that have been upgraded from autonomous IOS to LWAPP IOS will have generated a self-signed certificate (SSC) during the upgrade process SSCs are not trusted by default by WLCs, so a file containing a mapping of AP MAC addresses to public key hashes is created at upgrade time by the LWAPP Upgrade Utility supplied by Cisco This file must be imported into the WLC before an AP with an SSC is allowed to join The autonomous IOS to LWAPP upgrade process is described in detail in the following document: http://www.cisco.com/en/US/partner/products/hw/wireless/ps430/prod_technical_reference09186a00804fc3dc.html The rest of this document assumes a MIC implementation on the AP unless otherwise noted explicitly 2.2.3.2 LWAPP Operational States As shown in Figure 3, after the LWAPP Join process is completed, the AP transitions to either the Image Data state or the Config state The AP transitions to the Image Data state when the code version running on the AP is out-of-sync with the code version running on the WLC The AP will always synchronize its code revision with the WLC This means the AP will downgrade its code if it joins a WLC running a lower code revision than what is currently running on the AP Code is downloaded from the WLC to the AP in LWAPP control messages The AP requests chunks of code from the WLC in LWAPP Image Data Request messages and the WLC responds with LWAPP Image Data Response messages The payload of LWAPP Image Data Response Messages is chunks of the AP code The AP continues to send the LWAPP Image Data Request messages to the WLC until all code is downloaded It then assembles and installs the new software Once the new software is installed, it transitions to the Reset state as shown in Figure x and reboots The AP will run through the LWAPP Discovery and Join states again When the AP software revision is synchronized with the WLC, the AP transitions from the Join state into the Config state (see Figure 3) In the Config state, the WLC provisions the AP with the appropriate SSID, security, QoS, and other parameters that have been configured at the WLC The AP then transitions into the Run state and is ready to serve WLAN clients Once the LWAPP Join process is completed, the WLC starts a “Heartbeat” timer for the AP The WLC is expecting to receive an LWAPP Echo Request control message from the AP before the timer expires If it does not receive this message before the timer expires, the WLC removes the AP from its internal data structures The AP also maintains an LWAPP Heartbeat timer internally When the AP’s Heartbeat timer expires, the AP sends the LWAPP Echo Request message to the WLC and starts a timer called the NeighborDeadInterval timer The WLC responds to the LWAPP Echo Request with an LWAPP Echo Response When the AP receives the Echo Response, it stops the NeighborDeadInterval time and restarts the of 40 10/15/08 10:22 PM tme:enterprise_controller_design_4.2 - wnbu-tme wiki http://wnbu-tme.cisco.com/dokuwiki/doku.php?id=tme:enterpri Heartbeat timer When the NeighborDeadInterval timer expires, meaning the LWAPP Echo Response has not been received by the AP, the AP resends the LWAPP Echo Request message up to five times at second intervals If no acknowledgement is received after retries, the AP declares the controller unreachable, releases and renews its IP address, and transitions from the Run state to look for a new controller While the AP is in the Run state, the WLC periodically queries the AP for statistics in LWAPP Control messages These statistics are used for dynamic radio resource management (known as RRM), alarming, reporting, and other tasks 2.2.4 LWAPP MAC Modes The LWAPP RFC defines two modes for handling 802.11 MAC functionality—Split MAC Mode and Local MAC Mode This section describes these modes 2.2.4.1 Split MAC The default LWAPP Mode of operation is called “Split MAC” mode The term “Split MAC” derives from the fact that responsibility for processing the 802.11 MAC is divided between the AP and the WLC Figure illustrates LWAPP Split MAC mode: Conceptually, the “division of labor” is between real-time and non-real-time 802.11 MAC functionality 802.11 MAC functionality that requires direct, real-time access to the RF medium—for example, 802.11 control frames—are processed directly at the AP 802.11 MAC functionality requiring non-real-time access to the RF medium—for example, 802.11 association requests—is processed at the WLC When the system is operating in Split MAC mode, all wireless station data must traverse the network through the WLC Wireless data coming off the RF medium is encapsulated in LWAPP Data Messages and forwarded to the controller Data intended for any wireless client device is routed/switched to the WLC, where it is encapsulated in LWAPP and forwarded to the appropriate AP LWAPP Split MAC mode allows the CUWN to support scalable, secure client mobility as well as other interesting advanced services It is the default mode of operation in the CUWN Unless otherwise explicitly specified, LWAPP Split MAC mode is the assumed mode of operation in this document 2.2.4.2 Local MAC The LWAPP RFC also defines a operational mode called “Local MAC” Local MAC mode is illustrated in Figure 6: 10 of 40 10/15/08 10:22 PM tme:enterprise_controller_design_4.2 - wnbu-tme wiki http://wnbu-tme.cisco.com/dokuwiki/doku.php?id=tme:enterpri 3.2 Understanding How WLAN Controllers Work Figure 20 represents the CUWN controller architecture: Partitioning of data on the wireless medium is achieved by offering multiple BSSIDs, with 802.1Q translational bridging taking place on the WLC (assuming central switching of data traffic) LWAPP provides the link between AP and WLC for both control and data The architecture is transparent to the end-user wireless device though the WLC is acting as an 802.1Q bridge for data traffic From the perspective of the AP, the WLC terminates the LWAPP data tunnel and control channel To the network, the WLC is a Layer-2 device connected to a neighbor switch via one or more 802.1Q trunk interfaces 3.2.1 Understanding How WLAN Controllers Connect to Networks In this section we’ll look in a little more detail about how WLCs connect to networks Key WLC terms and concepts to understand are: Port Interface WLAN A WLC port is a physical entity that connects the WLC to the neighbor switch Each port on the controller is, by default, 802.1Q VLAN trunk port The VLAN trunking characteristics of the port are not configurable The Cisco 440x series WLC platforms also has a 10/100 copper service port The service port is reserved for out-of-band management of the WLAN controller and system recovery and maintenance; use of the service port is optional Integrated WLCs such as the Wireless Service Module (WiSM), 3750G, and WLAN Control Module (WLCM) connect to the backplane of their host device, but are port-wise, conceptually identical to the 440x Cisco 440x, WiSM, and 3750G controllers all support link aggregation (LAG) with software release 3.2 and higher LAG bundles all of the ports on the WLC into a single Etherchannel interface The system dynamically manages traffic load balancing and port redundancy with LAG An interface is a logical entity on the WLC An interface has multiple parameters associated with it, including IP address, defaultgateway (for the IP subnet), primary physical port, secondary physical port, VLAN tag, and DHCP server When LAG is not used, each interface is mapped to at least one primary physical port and an optional secondary port Multiple interfaces can be mapped to a single WLC port When LAG is used, the system dynamically maps the interfaces to the aggregated port channel There are multiple types of interfaces on the WLC, four of which are static types that must be present and are configured at setup time: Management interface (Static and configured at setup time; mandatory) AP-Manager interface (When operating using L3 LWAPP, static and configured at setup time; mandatory) Virtual interface (Static and configured at setup time; mandatory) Service-port interface (Static and configured at setup time; optional) Dynamic (User-defined) The Management interface is the default interface for in-band management of the WLC and connectivity to enterprise services such as AAA servers If the service port is in use, the management interface must be on a different subnet from the service port The management interface is also used for layer communications between the WLC and APs The Management interface is the only consistently “pingable” in-band interface IP address on the WLC A WLC has one or more AP Manager Interfaces that are used for all Layer communications between the WLC and the lightweight APs after the AP discovers the controller The AP Manager IP address is used as the tunnel source for LWAPP packets from the WLC to the AP, and as the destination for LWAPP packets from the AP to the WLC The AP Manager must have a unique IP address AP Manager interfaces can be configured on the same subnet as the Management interface, 26 of 40 10/15/08 10:22 PM tme:enterprise_controller_design_4.2 - wnbu-tme wiki http://wnbu-tme.cisco.com/dokuwiki/doku.php?id=tme:enterpri but this is not necessarily a requirement nor is it really recommended An AP Manager IP address is not pingable from outside the WLC The use of multiple AP Manager Interfaces is discussed in Section 3.2.1.1 The Virtual Interface is used to support mobility management, DHCP relay, and embedded layer security like guest web authentication and VPN termination The Virtual Interface must be configured with an unassigned, unused gateway IP address that should also be non-routable A typical virtual interface is “1.1.1.1” The Virtual Interface address will not be pingable and should not exist in any routing table in your network If multiple WLCs are configured in a mobility group, the Virtual Interface IP address must be the same on all WLC devices to allow seamless roaming The Service-port Interface is statically mapped by the system only to the physical service port The service port interface must have an IP address on a different subnet from the Management, AP-Manager, and any dynamic interfaces The service port can get an IP address via DHCP or it can be assigned a static IP address, but a default-gateway cannot be assigned to the Service-port interface Static routes can be defined in the WLC for remote network access to the Service-port The Service-port is typically reserved for out-of-band management in the event of a network failure It is also the only port that is active when the controller is in boot mode The physical service port of a 440x is a copper 10/100 Ethernet port and is not capable of carrying 802.1Q tags so it must be connected to an access port on the neighbor switch Dynamic Interfaces are created by users and are designed to be analogous to VLANs for WLAN client device The WLC will support up to 512 Dynamic Interface instances Dynamic Interfaces must be configured on a unique (to the WLC) IP network and VLAN Each Dynamic Interface acts as a DHCP relay for wireless clients associated to WLANs mapped to the interface A WLAN associates an SSID to an interface and is configured with security, QoS, radio policies, and other wireless network parameters There can be up to 16 AP WLANs can be configured per WLC Typically, a WLAN is mapped to a dynamic interface Figure 21 illustrates these concepts: Cisco WLC platforms are hardware programmed to support terminating no more than 48 LWAPP tunnels from access points on a single port This is by design to protect against over-subscribing a single port with traffic from access points There are two ways to support more than 48 APs on a WLC with this design parameter: 27 of 40 10/15/08 10:22 PM tme:enterprise_controller_design_4.2 - wnbu-tme wiki http://wnbu-tme.cisco.com/dokuwiki/doku.php?id=tme:enterpri Use Multiple AP Manager interfaces, with each mapped to a different port Use LAG-mode to connect the WLC to the network The following two sections discuss using multiple AP managers and add details regarding LAG-mode 3.2.1.1 Using Multiple AP Managers Figure 22 illustrates the use of multiple AP managers with the 4402-50 WLC: As you can see from Figure 22, one AP Manager interface is created and mapped to a physical port All AP Manager IP addresses are included in the LWAPP Discovery Response message from a WLC to an AP along with information on how many APs are currently using each AP Manager IP address The AP will select an AP Manager IP address to use for the LWAPP Join Request, preferring the least loaded AP Manager interface Therefore, the AP load is dynamically distributed across the multiple AP manager interfaces Multiple AP Manager interfaces can exist on the same VLAN and IP subnet, or they can be configured on different VLANs and IP subnets Cisco recommends that you configure all AP Manager Interfaces on the same VLAN and IP subnet Cisco recommends that you configure AP Manager Interface per connected port with the 440x WLC 3.2.1.2 Understanding LAG Mode When a WLC is configured for LAG mode, the 48 AP per port restriction is removed and you only need one AP Manager interface LAG bundles all the connected ports (excluding the service port) into a single Etherchannel LAG is the only supported mode on the WiSM and 3750G controllers Figure 23 illustrates LAG mode with a 4402-50 WLC: 28 of 40 10/15/08 10:22 PM tme:enterprise_controller_design_4.2 - wnbu-tme wiki http://wnbu-tme.cisco.com/dokuwiki/doku.php?id=tme:enterpri Though LAG bundles ports together into an Etherchannel, the WLCs not support either LACP or PaGP for Etherchannel negotiation Etherchannel mode is only on or off Therefore, the neighbor switch can only be configured for Etherchannel mode on One an IOS-based neighbor switch, each connected port should be configured as follows: interface GigabitEthernet switchport channel-group mode on no shutdown Configure the corresponding port-channel interface on the neighbor switch as follows: interface port-channel switchport switchport trunk encapsulation dot1q switchport trunk native vlan switchport trunk allowed vlan switchport mode trunk no shutdown When LAG is enabled on a WLC, the WLC forwards data frames on the same port on which they were received The WLC relies on the neighbor switch to load-balance traffic across the Etherchannel The WLC does not perform any Etherchannel load-balancing on its own WLCs re-assemble fragmented LWAPP packets in an FPGA on a per port basis So fragments must arrive at the WLC on the same port to be properly re-assembled The implication then, is that the Etherchannel load-balancing algorithm on the neighbor switch must guarantee delivery of fragments on the same port Therefore, Cisco supports ip-src-dst as the Etherchannel load-balancing algorithm for WLC neighbor switches when the WLC is configured for LAG To check the Etherchannel load-balancing algorithm in use on a Cisco switch, use the following command: show etherchannel load-balance To change the Etherchannel load balancing mode on the Cisco switch, use the following commands: configuration terminal port-channel load-balance src-dst-ip Consult Cisco.com for more details on Etherchannel load balancing 4.0 Campus Network Design with Cisco WLAN Controllers Armed with knowledge of the theory of operations of LWAPP and the CUWN and how controllers work, we can now look at campus network design with WLAN controllers This section will cover: 29 of 40 10/15/08 10:22 PM tme:enterprise_controller_design_4.2 - wnbu-tme wiki http://wnbu-tme.cisco.com/dokuwiki/doku.php?id=tme:enterpri WLAN resiliency and controller redundancy RF coverage redundancy WLAN controller placement IP address planning and management We will start with resiliency and controller redundancy 4.1 WLAN Resiliency Design The CUWN architecture provides significant flexibility for resilient system and network design This section reviews the design options for controller and RF coverage redundancy 4.1.1 WLAN Controller Redundancy and AP Load Balancing In this section, we will examine how the CUWN can be configured to support WLAN controller redundancy and dynamic AP load-balancing 4.1.1.1 Understanding WLAN Controller Redundancy and Dynamic AP Load Balancing The LWAPP protocol allows for dynamic redundancy and load balancing For example, if you specify more than one IP address for Option 43, an AP will send LWAPP discovery requests to each of the IP addresses it receives In the controller LWAPP discovery response, the controller embeds information on 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 The AP will then attempt to join the least loaded controller, defined as the controller with the greatest available AP capacity This dynamic load-balancing can be a basis for a dynamic controller redundancy scheme Once an AP joins a WLC, it sends an LWAPP heartbeat to its WLC at a pre-determined heartbeat interval, which is every 30 seconds by default The WLC responds to the LWAPP heartbeats from the APs in the form of unicast heartbeat acknowledgements When an AP misses a heartbeat acknowledgement, it resends up to heartbeat messages at second intervals If no acknowledgement is received after the resends, the AP resets and initiates a new WLC hunting and discovery process to find a new controller Remember that when an AP joins a controller, it learns the IP addresses of the other controllers in the Mobility Group from its joined WLC Subsequently, the AP sends LWAPP Primary Discovery Request messages to each of the WLCs in the Mobility Group The WLCs respond with a Primary Discovery Response to the AP The Primary Discovery Response includes information about the WLC type, total capacity, and current AP load As long as the joined WLC has the “AP Fallback” parameter enabled, the AP may decide to change over to a less loaded WLC This is how the system supports dynamic WLC redundancy This algorithm helps dynamically balance the AP load across the mobility group However, it is important to consider how it could also have some unintended consequences For example, suppose we have configured two controllers management interfaces in Option 43 in the DHCP scope When we deploy our first AP, it may join one controller Now when we deploy our second AP, it may join the second controller The next AP will join one of the two controllers; the fourth AP may join the other controller and so on By the time we’ve completed the AP deployment for the area, some of the APs will have joined one controller and the other APs will have joined the other controller The APs will likely be joined to controllers in a random “salt-and-pepper” fashion, where APs are joined to the controllers in no particular order or sequence This random joining has several potential challenges First of all, more client roaming across controller boundaries is inevitable While client roaming across controllers is highly optimized, intra-controller roaming is still more efficient than inter-controller roaming The random, salt-and-pepper layout makes operational tasks like troubleshooting and code upgrading more challenging The client load-balancing feature also works on a per-controller basis, so when this feature is not useful when the AP RF coverage layout assumes the salt-and-pepper configuration Typically, Cisco recommends that customers override the dynamic behavior of LWAPP by assigning APs to specific controllers to balance the load and engineer AP layout by assigning APs a primary, secondary, and/or tertiary controller to each AP By doing this, WLC redundancy behavior is deterministic Figure 24 illustrates deterministic WLC redundancy: 30 of 40 10/15/08 10:22 PM tme:enterprise_controller_design_4.2 - wnbu-tme wiki http://wnbu-tme.cisco.com/dokuwiki/doku.php?id=tme:enterpri When an AP declares its primary controller unreachable due to missed heartbeat acknowledgements, it will attempt to join the secondary controller If it fails to join the secondary controller, it attempts to join the tertiary controller If neither the primary, secondary, nor tertiary controllers are available, APs will resort to the dynamic LWAPP algorithms to connect to the least-loaded available controller The WLC has a configurable parameter for “AP Fallback” When the WLC “AP Fallback” option is enabled, APs will return to their primary controllers after a failover event when the primary controller comes back online This feature is enabled by default and many administrators choose to leave the AP Fallback default value in place However, when an AP “falls back” to its primary controller, there will be a brief window of time, usually on the order of 30 seconds, during which service to wireless clients is interrupted because the APs are re-joining the primary WLC Also, if connectivity to the primary WLC has become unstable for some reason, the AP might end up “flapping” back and forth between a primary and the backup WLCs Many WLAN administrators prefer to disable AP Fallback and move the APs back to the primary in a controlled manner during a scheduled service window 4.1.1.2 N:1 Redundancy A popular WLC redundancy option is an “N:1” redundant configuration This is a good option when there are many WLC controller devices and capital expenditure costs are a big consideration Figure 25 illustrates N:1 redundancy: In this configuration, the redundant controller is placed in a NOC or data center and acts a backup for multiple WLCs Each AP is configured with a WLC as primary and all APs point to the “1” redundant controller as secondary As you can probably see, the redundant controller could become “oversubscribed” with APs if there are multiple primary WLC failures, which is usually unlikely Once a WLC has reached the maximum number of joined APs, it accepts no more LWAPP Join requests So when the backup WLC becomes “oversubscribed”, some APs might be stuck with no WLC When designing an N:1 redundant solution you should assess the risks of multiple WLC failures and the consequences of an oversubscribed backup WLC 31 of 40 10/15/08 10:22 PM tme:enterprise_controller_design_4.2 - wnbu-tme wiki http://wnbu-tme.cisco.com/dokuwiki/doku.php?id=tme:enterpri 4.1.1.3 N:N Redundancy The Cisco Unified Wireless Network architecture gives you flexibility in WLC redundancy options For example, Figure 26 illustrates an “N:N” redundancy configuration: In this configuration, there are 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 In this design, you should try to load balance the AP capacity across both controllers But you should also try to logically group APs on controllers to minimize intercontroller roaming events For example, if you are supporting a four floor building with two redundant controllers, you might configure the APs on floors and to use one controller as primary and the APs on floors and to use the other controller as primary It may seem obvious, but it needs to be noted: be sure that there is enough excess capacity on each controller to handle a failover situation 4.1.1.4 N:N:1 Redundancy Another redundancy option is an “N:N:1” configuration as illustrated in Figure 27: 32 of 40 10/15/08 10:22 PM tme:enterprise_controller_design_4.2 - wnbu-tme wiki http://wnbu-tme.cisco.com/dokuwiki/doku.php?id=tme:enterpri In this configuration, some of the APs are configured with controller A as primary and controller B as secondary and all 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 “1” tertiary controller placed in a NOC or data center Multiple distribution blocks can be configured with the same tertiary controller When selecting a redundancy option, you should consider the risks of WLC failure and the service-level-agreement (SLA) required to be maintained by your wireless LAN The higher the SLA, the more robust of a redundancy scheme your designed solution should provide 4.1.2 WLAN RF Coverage Redundancy One of the key design considerations for any WLAN is to be sure that there is sufficient RF coverage that can support individual AP failures, while minimizing co-channel interference This section discusses some strategies for RF redundancy, though a detailed discussion of the topic is somewhat outside the scope of this document 4.1.2.1 Designing Cell Sizes For Coverage Redundancy RRM is designed to compensate for catastrophic AP failure through the coverage hole detection and mitigation feature However, since the coverage hole detection and mitigation feature raises AP transmit power to compensate for coverage holes, APs should be deployed such that they never run at maximum transmit power Normally, Cisco's AP placement recommendations for supporting voice and location-based services will have APs at 30-50 foot (10-18 meter) centers, so these APs will rarely run at maximum transmit power However, in many deployments, APs have been placed to maximize coverage and minimize AP count To support RF coverage redundancy, it may be necessary to add additional APs 4.1.2.2 "Checker-board" and "Salt-and-Pepper" AP Layouts The Cisco Unified Wireless Network architecture supports “checker-board” AP designs, where adjacent APs are joined to different controllers, and “salt-and-pepper” AP layouts, where APs in the coverage area are randomly joined to different controllers However, Cisco recommends against using these “checker-board” and “salt-and-pepper” AP layouts Figure 28 illustrates the checker-board AP design concept In Figure 28, every odd numbered AP is joined to WLC1 and every even numbered AP is joined to WLC2 33 of 40 10/15/08 10:22 PM tme:enterprise_controller_design_4.2 - wnbu-tme wiki http://wnbu-tme.cisco.com/dokuwiki/doku.php?id=tme:enterpri In theory, this checker-board and salt-and-pepper designs provide for dynamic traffic load-balancing across WLCs and RF coverage redundancy in the event of a WLC failure However, in reality, these designs have fewer appreciable advantages and in fact have some disadvantages When an AP loses its connection with the WLC, it resets and searches for a new controller All of its clients lose their connection because the client state is maintained on the controller and is thus lost in the event of a controller failure So there is no high-availability achieved with a salt-and-pepper or checker-board design Furthermore, these designs result in more inter-controller roaming events that use system resources inefficiently The aggressive client load-balancing feature is not available with a these designs either since client load-balancing is run per controller Furthermore, the traffic patterns from wireless clients will be unpredictable making it difficult to implement stateful security mechanisms in the infrastructure and take advantage of some other Cisco switching features You can get equivalent performance and resiliency without a salt-and-pepper or checker-board design Cisco generally recommends not using salt-and-pepper or checker-board AP layouts Cisco recommends instead, that you group APs into logical coverage areas per controller and use deterministic deployments For example, a building floor would be joined to one controller, while another floor in the building is joined to a different controller 4.2 WLAN Controller Placement This section presents conceptual design ideas for “Places in the Network” for controllers We present ideas for: Enterprise Wiring Closets Distribution Layer Deployments Services Block Deployments Campus H-REAP Design principles are presented Enterprise architects should select the design that best fits their needs 4.2.1 Enterprise Wiring Closet Deployment One option for controller placement is in the Enterprise wiring closet as shown in the following figure 29: Typically, these deployments use the 3750G Integrated WLAN controller as a “top-of-stack” solution, but can also be implemented with the 440x series controller Controller redundancy can be achieved in an N:N fashion within the switch stack Some advantages of these deployments are that access layer traffic is kept at the access layer taking advantage of the integrated 3750G switch access layer features There is also the advantage of having cost effective, layer-3 uplink redundancy from the edge of the network Also, the 3750G has 802.3af capable PoE ports that can power APs 34 of 40 10/15/08 10:22 PM tme:enterprise_controller_design_4.2 - wnbu-tme wiki http://wnbu-tme.cisco.com/dokuwiki/doku.php?id=tme:enterpri However, this architecture may present challenges in supporting inter-controller roaming across wiring closets This can be quite common in a typical enterprise campuses 4.2.2 Distribution Layer Deployments Another option is to deploy controllers at the distribution layer, as shown in Figure 30 Since the distribution layer is where traffic is aggregated and policies enforced in campus LAN design, the distribution layer is a natural place to deploy controllers Typically, these deployments are done with WiSM blades in distribution layer Catalyst 6500 switches, or with 440x series standalone controllers The 3750G Integrated WLC can also fit into distribution block deployments easily Redundancy and AP load-balancing is easy to implement when the controllers are deployed at the distribution layer, as shown in Figure 30 Distribution layer deployments naturally fit into a N:N and N:N:1 redundancy architecture From the campus LAN design perspective, these deployments in effect collapse the access layer (WLAN) into the distribution layer So, consideration should be given to what access layer switching features need to be implemented in the distribution layer swithches and applied to the WLAN traffic ingressing and egressing the controller 4.2.3 Service Block Deployments The most common campus controller deployments for large campuses are in “service blocks” Figure 31 shows several service block options 35 of 40 10/15/08 10:22 PM tme:enterprise_controller_design_4.2 - wnbu-tme wiki http://wnbu-tme.cisco.com/dokuwiki/doku.php?id=tme:enterpri Typically, service block deployments use one or more WiSM blades deployed in Catalyst 6500 switches deployed as “appliances”, but can also be deployed with 440x controllers Service block deployments are especially good for integration with other Catalyst 6500 services modules These deployments usually lead to highly efficient inter-controller mobility and simplified network management For large campuses, there is also an incremental economy of scale as the network grows larger Where to place a services block is another design problem Often, services blocks are deployed in data centers where there is high availability routing and switching and power Also, data centers also tend to be managed and operated by the most skilled network staff On the other hand, when deploying a services block in a data center, all WLAN data traffic must traverse the network core, so core bandwidth and latency are important considerations In many large campuses, services blocks can be deployed in a redundant arm off of distribution switches These are particularly valuable when core bandwidth is at a premium, such as when there are several large distributed campuses connected via a MAN 4.2.4 Campus H-REAP Another option is to deploy APs in H-REAP mode with local switching of some or all data traffic These deployments typically locally switch authenticated data traffic while centrally switching guest WLAN traffic This type of deployment, with locally switched, authenticated traffic, and centrally switched guest access is shown in Figure 32: Campus H-REAP has some design parameters that should be taken into consideration Cisco CKM is supported for fast secure layer-2 roaming, but PKC is not A layer-2 roaming domain should not exceed 25 access points Furthermore, Layer-3 roaming is not supported 36 of 40 10/15/08 10:22 PM tme:enterprise_controller_design_4.2 - wnbu-tme wiki http://wnbu-tme.cisco.com/dokuwiki/doku.php?id=tme:enterpri with locally switched traffic Call admission control (CAC) is also not supported for locally switched traffic Campus H-REAP is a suitable solution for small satellite sites where the cost of deploying a controller on-site is prohibitive Locally switched data traffic can also be optimized with WAAS for more efficient core and WAN traversal Campus H-REAP is not suited for medium to large campuses 4.2.5 Selecting a Solution Cisco's general recommendation is to deploy controllers in a services block for Enterprise campuses However, this is more of a general recommendation than network design dogma Network architects designing for the CUWN should select the controller placement architecture that makes the most sense for their networks and applications 4.3 IP Address Planning and Management IP address management is an important design consideration Nothing irritates users and causes more avoidable support desk calls like DHCP scope exhaustion This section reviews your options for IP address management 4.3.1 Normal Deployments Let’s review how IP addresses are assigned to wireless clients Remember that a wireless client gets an IP address on the same IP network as the WLAN’s assigned interface You need to be sure to allot enough address space to support your users User network IP address allocation should be calculated based on worst-case scenarios, and even then, it may make sense to allow for extra IP addresses For example, if you have 50 APs joined to the WLC and you’re operating on a worst-case assumption of 20 simultaneous users per AP for the WLAN, you need to allocate enough IP addresses for 1000 users (50 APs * 20 users) So you would, at a minimum, select an IP subnet with a /22 subnet mask, which would yield 1022 total usable IP addresses Once you subtract out the routed interfaces and the WLC interface from the 1022 addresses, you have a buffer (beyond the 1000 users) of only about 15 IP addresses If an unexpectedly high number of users attach to the network at some point in time, you could run out of IP addresses for your wireless clients Therefore, you might choose to allocate a /21 IP subnet instead Of course, a /21 subnet mask yields 2046 usable IP addresses so there could be a large number of unused IP addresses that might be considered “wasted.” You’ll need to engineer an IP address space that best meets the needs of your network 4.3.2 Using Smaller IP Subnets With AP Groups In a default deployment, a WLAN is mapped to a single interface per WLC, which is then bridged on and off of a single VLAN on the wired network Consider a deployment scenario, where you have a 4404-100 WLC supporting the maximum number of APs—100 Now, let’s consider a near-worst case scenario with 25 users associated to each AP In the default configuration then, you have 2500 users on the same VLAN This may not be such a big deal since LWAPP is an overlay architecture; there’s no spanning tree that has to span all 100 APs and the WLC does proxy-arp so broadcast traffic is not a concern However there could be broadcast or multicast intensive applications running on the WLAN end-clients Also, you may want to distribute the end-client load across multiple interfaces in the infrastructure 2500 users on a VLAN would also require a /20 IP subnet and you may not have blocks of IP addresses that large available To create smaller user domains, you should make use of the AP Groups feature Figure 33 illustrates the AP Groups feature: 37 of 40 10/15/08 10:22 PM tme:enterprise_controller_design_4.2 - wnbu-tme wiki http://wnbu-tme.cisco.com/dokuwiki/doku.php?id=tme:enterpri In Figure 33, there are three dynamic interfaces configured, mapping to three “site specific VLANs”—VLANs 61, 62, and 63 These site specific VLANs apply to the “secure” SSID for normal corporate users A corporate user associating to the SSID “secure” on an AP in the AP Group corresponding to VLAN 61 will get an IP address on VLAN 61’s IP subnet A corporate user associating to the SSID “secure” on an AP in the AP Group corresponding to VLAN 62 will get an IP address on VLAN 62’s IP subnet A corporate user associating to the SSID “secure” on an AP in the AP Group corresponding to VLAN 63 will get an IP address on VLAN 63’s IP subnet Intra-controller roaming between site specific VLANs with AP Groups is handled internally by the WLC, so the WLAN client will maintain it's original IP address, even when roaming to an AP in another AP Group Inter-controller roaming between site specific VLANs is handled as layer-3 roaming, but symmetric tunneling is required with AP Groups 5.0 Conclusion In this paper, we provided architectural details and design guidance for WLAN Controller deployments Key topics included Lightweight Access Point Protocol (LWAPP), WLAN security support, mobility, radio resource management, controller placement in the network, and support for network redundancy These fundamental architectural concepts and design considerations are necessary to successfully plan for and design a CUWN Particularly important is understanding Lightweight Access Point Protocol (LWAPP), and how the products, including WLAN Controllers and lightweight access points work together as a comprehensive WLAN system Cisco customers have a wide number of controllers to select from, including the 440x Series, WiSM, 3750G Integrated WLAN Controllers, WLCM, and 2106 These controllers can be deployed at the access layer, distribution layer, and in the network core via services blocks to support full mobility and dynamic radio management Ultimately, the CUWN is necessary for a modern business-class Wireless LAN (WLAN) that supports mission-critical data applications as well as important networked services, such as Voice Over WLAN (VoWLAN), Location-Based Services (LBS), and converged applications Furthermore, these WLANs must be high-performance, resilient, scalable, manageable, and easy to deploy The Cisco Unified Wireless Network (CUWN) is designed to meet the challenges of high-performance, resilience and scalability Appendix A: Protocols and Ports Used By The Cisco Unified Wireless Network When the Cisco Unified Wireless Network Solution is deployed in the network, it may be necessary to allow protocols and protocol ports through firewalls and/or access control lists This Appendix section reviews the protocol ports that must be opened and where they should be opened This section does not contain security best practices and/or recommendations It simply lists the protocols and ports used in the Cisco Unified Wireless Network Solution Best practices for securing your network should always be followed LWAPP Protocols and Ports All packets transmitted between the WLC and its joined APs are LWAPP encapsulated The WLC(s) use(s) UDP port 12222 for LWAPP Data Packets and UDP port 12223 for LWAPP Control Messages The AP uses an ephemeral port that is derived from a hash of its MAC address So an LWAPP Data Packet transmitted from the AP to the WLC would be transported in a UDP packet using the ephemeral port as the source port and UDP port 12222 as the destination port An LWAPP Data Packet traveling the reverse path from WLC to the AP uses UDP port 12222 as source and the AP ephemeral port as the destination port An LWAPP Control Message sent from the WLC to an 38 of 40 10/15/08 10:22 PM tme:enterprise_controller_design_4.2 - wnbu-tme wiki http://wnbu-tme.cisco.com/dokuwiki/doku.php?id=tme:enterpri AP uses UDP port 12223 as the source port and the AP ephemeral port as the destination port An LWAPP Control Message sent from the AP to the WLC uses the AP ephemeral port as source and UDP port 12223 as the destination Mobility Protocols and Ports Forwarded data traffic, including data traffic forwarded as a result of layer roaming and the “guest tunneling” feature, between WLCs in a mobility group is carried in Ethernet in IP (EtherIP) tunnels EtherIP is defined in RFC 3378 EtherIP defines a simple mechanism whereby Ethernet frames are encapsulated in IP packets The IP packet headers have the 8-bit protocol field set to a decimal value of 97 (0×61) IP Protocol 97 must be allowed through any firewalls and ACLs Mobility control messages are exchanged between WLCs in UDP packets The mobility protocol ports are UDP 16666 and 16667 UDP ports 16666 and/or 16667 must be bi-directionally opened to support Mobility Groups If you have chosen to enable the “Secure Mobility Group” feature, you must allow IP Protocol 50 (IP Encapsulated Security Protocol, RFC 1827) and UDP port 500 through any firewall or ACL However, since the mobility control packets exchanged between controllers are encapsulated in ESP, there is no need to open ports 16666 and 16667 when using Security Mobility Groups RF Group Protocols and Protocol Ports The members of an RF Group will exchange RRM messages At the RF Group update interval (by default, every 600 seconds), the RF Group leader and members exchange RRM messages during a re-evaluation of the current radio and channel plan Between the update intervals, the non-leader members of the RF Group send heartbeat messages and data to the RF Group leader All messages are carried in UDP datagrams For all 802.11b/g RRM messages the UDP datagrams use UDP ports 12124 and 12134 for both source and destination For all 802.11a RRM messages, the UDP datagrams use UDP ports 12125 and 12135 for both source and destination UDP ports 12124, 12125, 12134, and 12135 must be allowed between all WLCs belonging to an RF Group WLAN Controller Management Protocols and Ports WCS communicates with the WLCs using SNMP for both polling and configuration WLCs send asynchronous SNMP Traps to the WCS to notify the WCS of certain events SNMP uses UDP as transport and the well known UDP ports 161 and 162 You may override the default ports if you choose to so In the default case, you need to allow bi-directional traffic using UDP port 161 as the destination port between the WCS and each WLC for SNMP polling and configuration You’ll need to allow traffic using UDP port 162 from the WLC to the WCS to allow SNMP traps through If you’ve configured a WLC to send SYSLOG messages to a SYSLOG server, you’ll need to make sure you allow the messages through any firewall or ACL between the WLC and SYSLOG server SYSLOG uses the well-known UDP port 514 so you’ll need to open that port for SYSLOG messages from the WLC to the SYSLOG server If you’ve configured the WLCs to use NTP for time, then you need to allow the NTP synchronizations between the WLC and the NTP server NTP is assigned the well-known port 123 (both TCP and UDP), so you’ll need to allow bi-directional traffic using port 123 between the WLC and NTP server When you’re using 802.1X authentication, you’ll need to allow RADIUS communications between the WLC Management Interface and the RADIUS Server RADIUS is assigned UDP port 1812 for authentication and port 1813 for RADIUS accounting Cisco ACS also uses ports 1645 for authentication and 1646 for accounting Other RADIUS servers may use non-standard ports Consult your vendor documentation for the RADIUS ports used by the product The WLC also acts as a DHCP proxy for WLAN clients by forwarding broadcast client DHCP requests to the DHCP server You’ll need to allow these DHCP messages DHCP is assigned well-known port 546 (both TCP and UDP) for DHCP clients and port 547 (both TCP and UDP) for DHCP servers You need to allow DHCP between the WLC and DHCP server You’ll also want to allow TFTP from the WLC to the TFTP servers you use to upgrade code and backup configurations This could be the WCS, or some other TFTP server TFTP uses UDP port 69 so this needs to be allowed Management Access Protocols and Ports WCS can only be accessed remotely only via web browser using HTTPS The default (and well-known) port for HTTPS is TCP port 443 This can be overridden at the time WCS is installed Whichever port is used, web browser access needs to be allowed to the port for TCP traffic WLC devices are only accessible via console port, SSH and secure HTTP by default The default HTTPS port is TCP port 443 This cannot be overridden in the case of the WLC, although HTTPS access can be disabled As long as HTTPS access is enabled, you need to allow web browser access to TCP port 443 on the WLC You can also disable SSH if you want But if you leave SSH enabled, you need 39 of 40 10/15/08 10:22 PM tme:enterprise_controller_design_4.2 - wnbu-tme wiki http://wnbu-tme.cisco.com/dokuwiki/doku.php?id=tme:enterpri to allow SSH traffic to TCP port 22 Telnet and HTTP can also be enabled on the WLC If you enable HTTP, you need to allow web browser access to TCP port 80 When you enable telnet on the WLC, you need to allow access to TCP port 23 40 of 40 10/15/08 10:22 PM ... 44 04 supports up to 100 APs and 5000 connected clients Table compares the 44 0x Series Controller options Part Number AIR-WLC 440 2-12-K9 AIR-WLC 440 2-25-K9 AIR-WLC 440 2-50-K9 AIR-WLC 440 4-100-K9 44 0x... on each of these controller options 3.1.1 44 0x Series WLAN Controllers The 44 0x Series WLAN Controllers come in two configurations–the 44 02 and 44 04 Series The 44 02 Series WLAN Controller has x... AIR-WLC 440 4-100-K9 44 0x Series WLAN Controllers Gbps SFP Product Throughput Ports 44 02 Series WLAN 2 Gbps Controller 44 02 Series WLAN 2 Gbps Controller 44 02 Series WLAN 2 Gbps Controller 44 04 Series WLAN 4 Gbps