Teema 11 - WLAN arhitektuur.docx

IN THIS CHAPTER, YOU WILL LEARN ABOUT THE FOLLOWING: WLAN client devices 802.11 radio form factors 802.11 radio chipsets Client utilities Management, Control, and Data planes Management plane Control plane Data plane WLAN architecture Autonomous WLAN architecture Centralized network management...

IN THIS CHAPTER, YOU WILL LEARN ABOUT THE FOLLOWING: WLAN client devices 802.11 radio form factors 802.11 radio chipsets Client utilities Management, Control, and Data planes Management plane Control plane Data plane WLAN architecture Autonomous WLAN architecture Centralized network management systems Centralized WLAN architecture Distributed WLAN architecture Hybrid WLAN architecture Specialty WLAN infrastructure Enterprise WLAN routers WLAN mesh access points WLAN bridges WLAN array Real-time location systems VoWiFi Cloud networking Infrastructure management Protocols for management Application programming interface Transport and data formats WLAN APIs Common applications In Chapter 7, “Wireless LAN Topologies,” we discussed the various 802.11 WLAN topologies. You learned that both client and access point stations can be arranged in 802.11 service sets to provide wireless access to another medium. In this chapter, we discuss the multiple devices that can be used in 802.11 topologies. Many choices exist for client station radio cards that can be used in desktops, laptops, smartphones, tablets, and so on. We also discuss the three logical planes of network operation and where they apply in a WLAN. This chapter provides an overview of the many different WLAN architectures that are available today. We also explore the progression of WLAN infrastructure devices over the years. We also cover the purpose of many WLAN specialty devices that exist in today’s Wi-Fi marketplace. WLAN Client Devices The main hardware in a Wi-Fi network interface card (NIC) is a halfduplex radio transceiver, which can exist in many hardware formats and chipsets. All Wi-Fi client NICs require a special driver to interface with the operating system, as well as software utilities to interface with the end user. Laptop Wi-Fi radios can work with Windows, Linux, ChromeOS, and macOS, although they require a different driver and client software for each operating system. The drivers for many manufacturers’ radios may already be included in the operating system, but often newer radios require or can benefit from an updated driver installation. Many vendors will provide an online automated method to update drivers; however, some may require that the driver be installed manually in the operating system. First-generation Wi-Fi radio drivers are often buggy. An administrator or user should always ensure that the most current generation of drivers is installed. A large percentage of Wi-Fi issues are resolved by simply upgrading WLAN client drivers. With a software interface, the end user can configure a NIC to participate in a WLAN by using configuration settings that pertain to identification, security, and performance. These client utilities may be the manufacturer’s own software utility or an incorporated software interface built into the operating system. Next, we discuss the various radio NIC formats, the chipsets that are used, and software client utilities. 802.11 RADIO FORM FACTORS 802.11 radios are used in both client NICs and access points. The following sections focus mainly on how Wi-Fi radios can be used as client devices. 802.11 radios are manufactured in many form factors, meaning the NIC comes in different shapes and sizes. Many Wi-Fi radio form factors, such as USB, are meant to be used as add-on external devices, although the majority of Wi-Fi devices now use internal or integrated form factors. External Wi-Fi Radios When 802.11 WLANs were first deployed, the only option you had when purchasing an 802.11 client NIC was a standard PC Card adapter, which was a peripheral for laptop computers. The PC Card form factor was developed by the Personal Computer Memory Card International Association (PCMCIA). Three legacy PCMCIA adapters, also known as PC cards, are shown in Figure 11.1. The PCMCIA radio card could be used in any laptop or handheld device that had a PC card slot. Most PC cards had only internal integrated antennas, whereas others had both integrated antennas and external connectors. Laptops are no longer manufactured with PC card slots, and PCMCIA radios have become obsolete. FIGURE 11.1 PCMCIA adapter/PC card Courtesy of Cisco Systems, Inc. Unauthorized use not permitted. Eventually, other radio form factors hit the marketplace, including the ExpressCard format. ExpressCard was a hardware standard that replaced PCMCIA cards. Most laptop manufacturers replaced PCMCIA slots with the smaller ExpressCard slots. Secure Digital (SD) and CompactFlash (CF) were two peripheral radio form factors that were originally used with handheld personal digital assistants (PDAs). These radios typically required very low power and were smaller than the size of a matchbook. The use of the SD and CF formats with handheld devices quickly became obsolete because handheld devices integrated embedded form factor 802.11 radios directly into their products. We have discussed a few Wi-Fi radio form factors that can be used as external radios with laptops and other mobile devices. However, Universal Serial Bus (USB) 802.11 radios remain the most popular choice for external Wi-Fi radios because almost all computers have USB ports. USB technology provides simplicity of setup and does not require an external power source. 802.11 USB radios exist either in the form of a small dongle device (see Figure 11.2) or as an external wired USB device with a separate USB cable connector. The dongle devices are compact and portable for use with a laptop computer, and the external devices can be connected to a desktop computer with a USB extension cable and placed on top of a desk for better reception. FIGURE 11.2 802.11 USB radio 802.11n/ac radios are available in both USB 2.0 and USB 3.0 form factors and can operate in both the 2.4 GHz and 5 GHz frequency bands. Be aware that there are some disadvantages when using a USB radio form factor. USB 2.0 technology defines data transfers of only up to 480 Mbps, which will limit the available 802.11 data rates. USB 3.0 technology defines potential data transfers of up to 5 Gbps. USB 3.0 Wi-Fi radios can therefore take advantage of higher 802.11n/ac data rates. Please be aware that the circuitry in some USB 3.0 devices has been known to cause RF interference in the 2.4 GHz band. USB 3.0 devices of various types have been shown to raise the noise floor 5–20 dB, which can cause serious performance issues with internal 802.11 radios in a laptop. Internal Wi-Fi Radios For many years, external Wi-Fi radios were the norm because laptops did not have internal Wi-Fi radio capabilities. Laptops and other mobile devices now include internal Wi-Fi radios. An internal radio format that was initially used was the Mini PCI. The Mini PCI was a variation of the Peripheral Component Interconnect (PCI) bus technology and was designed for use mainly in laptops. A Mini PCI radio was often used inside access points and was also the main type of radio used by manufacturers as the internal 802.11 wireless adapter inside laptops. The next generation bus technology form factor is the smaller Mini PCI Express and even smaller Half Mini PCI Express. It is almost impossible to buy a new laptop today that does not have an internal Mini PCI or Mini PCI Express radio, as shown in Figure 11.3. A Mini PCI or Mini PCI Express radio card typically is installed from the bottom of the laptop and is connected to small antennas that are mounted along the edges of the laptop’s monitor. FIGURE 11.3 Mini PCI and Mini PCI Express radios ADVANTAGES OF USING AN EXTERNAL USB RADIO WITH A LAPTOP Although Mini PCI, Mini PCI Express, and Half Mini PCI Express radios are removable from some laptops, there is no guarantee that any of these form factors will work in another vendor’s laptop. One advantage of using USB Wi-Fi adapters is that they can be moved and used in different laptops. Additionally, a laptop with an older 802.11 internal radio can be instantly upgraded to newer 802.11 technology at a low cost using a USB radio. Also, WLAN engineers usually use a USB radio when running 802.11 protocol analyzer software and/or site survey software applications. These applications often require a special driver for the 802.11 radio that will overwrite and/or conflict with the radio’s original driver. Using an independent and external Wi-Fi radio for troubleshooting and site surveys is a common practice so that the driver of the internal Wi-Fi radio remains intact. Mobile Devices We have mainly discussed the various types of 802.11 radio NIC formats that are used with laptops. 802.11 radios are also used in many other types of handheld devices, such as smartphones, tablets, bar code scanners, and VoWiFi phones. Bar code scanners, such as the Honeywell mobile device pictured in Figure 11.4, have made use of 802.11 radios for many years. FIGURE 11.4 Bar code scanner Courtesy of Honeywell Although older handheld devices did use some of the previously mentioned form factors, manufacturers of most handheld devices use an embedded form factor 802.11 radio (usually a single chip form factor that is embedded into the device’s motherboard). Figure 11.5 shows a single chip Broadcom Wi-Fi radio that is found inside some models of the Apple iPhone. Almost all mobile devices such as smartphones and tablets use a single chip form factor that is embedded on the device’s motherboard. The embedded radios often use a combo chipset for both Wi-Fi and Bluetooth radios. FIGURE 11.5 Embedded 802.11 radio For many years, most people thought of only using their laptop for Wi-Fi connectivity. With the advent of smartphones and tablets, there has been a handheld client population explosion of mobile devices. In recent years, the number of mobile devices connecting to enterprise WLANs has exceeded the number of laptops connecting to the same enterprise WLANs. Technology research firm, 650 Group, (www.650group.com (http://www.650group.com)), estimates that by 2025, the number of smartphones, tablets, PCs and peripherals in use will reach over 12 billion units worldwide. Users now expect Wi-Fi connectivity with numerous mobile devices in addition to their laptops. Because of the proliferation of personal mobile devices, a bring your own device (BYOD) policy is often needed to define how employees’ personal devices may access the corporate WLAN. A mobile device management (MDM) solution might also be needed for onboarding both personal mobile devices and company-issued devices onto the WLAN. BYOD strategies and MDM solutions are discussed in great detail in Chapter 18, “Bring Your Own Device (BYOD) and Guest Access.” Wearables Another big technology trend has been wearable computers, simply known as wearables. A wearable computing device is worn on a person’s body and/or clothing. Wearables are meant to provide a constant interaction between a person and a computer, and the wearable becomes an extension of a user’s body or mind. Although the concept of wearable computers is not new, wearables with embedded Wi-Fi radios have begun to find their way into the marketplace. Examples of wearable computers include smart watches, wristbands, exercise sensors, and glasses. Much as with smartphones and tablets, users may want to connect to the company WLAN using their personal wearable computer devices. New challenges lie ahead for how IT administrators will manage the onboarding and access policies of wearables to the corporate WLAN. Additionally, wearables have the potential for numerous applications in enterprise verticals, such as healthcare and retail. Silicon Valley-based research firm, 650 Group, projects that the number of wearable devices shipped will rise from 1 billion in 2017 to over 5 billion in 2025. Internet of Things When speaking about RFID devices, the phrase Internet of Things (IoT) is usually credited to Kevin Ashton: www.rfidjournal.com/articles/view?4986 (http://www.rfidjournal.com/articles/view?4986) Over the years, most of the data generated on the Internet has been created by human beings. The theory of Internet of Things is that in the future, the bulk of the data generated on the Internet might be created by sensors, monitors, and machines. It should be noted that 802.11 radio NICs used as client devices have begun to show up in many types of machines and solutions. Wi-Fi radios already exist in gaming devices, stereo systems, and video cameras. Appliance manufacturers are putting Wi-Fi NICs in washing machines, refrigerators, and automobiles. The use of Wi-Fi radios in sensor and monitoring devices, as well as RFID, has many applications in numerous enterprise vertical markets. Technology research firm, 650 Group, estimates that by 2025, the number of wirelessly connected IoT devices will be 53 billion units worldwide, far exceeding the expected 28 billion number of PCs, tablets, smartphones and other connected personal devices. Could this be the beginning of the self-aware Skynet predicted by the Terminator movies? All kidding aside, a large portion of IoT devices will most likely connect to the Internet with a Wi-Fi radio. Once again, new challenges lie ahead; IT administrators must manage the onboarding, access, and security policies of IoT devices connecting to the corporate WLAN. The bulk of IoT devices with an 802.11 radio currently transmit in the 2.4 GHz frequency band only. Please understand that not all IoT devices use Wi-Fi radios. IoT devices may use other RF technology, such as Bluetooth or Zigbee. IoT devices may also have an Ethernet networking interface in addition to the RF interfaces. HOW DO I KNOW WHAT KIND OF RADIO IS IN MY LAPTOP OR MOBILE DEVICE? Often, a laptop or mobile device manufacturer will list the radio model in the specification sheet for the laptop or mobile device. However, some manufacturers may not list detailed radio specifications and capabilities. What if you want to find out if the radio is a 1x1:1 MIMO radio or maybe a 3x3:3 MIMO radio? Does the radio support 40 MHz channels or only 20 MHz channels? On laptops, you might find some of the radio’s capabilities by simply looking at the radio drivers from within the OS. Another method of identifying the Wi-Fi radio in your device is by the FCC ID. In the United States, all Wi-Fi radios must be certified by the Federal Communications Commission (FCC) government agency. The FCC maintains a searchable equipment authorization database at transition.fcc.gov/oet/ea/fccid (http://transition.fcc.gov/oet/ea/fccid). You can enter the FCC ID of your device into the database search engine and find documentation and pictures submitted by the manufacturer to the FCC. The FCC database is very useful in helping to identity Wi-Fi radio models and specifications if the information is not available on the manufacturer’s website. Client Device Capabilities In Chapter 13, “WLAN Design Concepts,” we will discuss the importance of understanding the capabilities of the clients you have deployed in an enterprise environment. We will also discuss the importance of upgrading your WLAN client population with newer 802.11 technology when you also upgrade your access points. Most businesses and corporations can eliminate many of the client connectivity and performance problems by simply upgrading company-owned client devices before updating the WLAN infrastructure. Sadly, the opposite is often more common, with companies spending many hundreds of thousands of dollars on technology upgrades with new access points while still deploying legacy clients. Always remember that all 802.11 client radios do not have the same capabilities. Legacy 802.11b radios have a maximum data rate of 11 Mbps, and legacy 802.11a/g radios have a maximum data rate of 54 Mbps. Laptop, smartphone, and tablet manufacturers now ship their products with 802.11n/ac radios, which are capable of much higher data rates. Be aware, however, that even modern client devices may not have the same capabilities. Some higher-end laptops may have 3x3:3 MIMO radios, but the bulk of laptops have 2x2:2 MIMO radios. Additionally, most smartphones and tablets now have 2x2:2 radios, but many older 802.11n mobile devices were 1x1:1. The first several generations of tablet PCs and smartphones had 1x1:1 radios that operated only in the 2.4 GHz frequency band. Most modern clients are dual-frequency with 2x2:2 MIMO radios that operate in both the 2.4 GHz and 5 GHZ frequency bands. Also, the majority of new clients will usually support 40 MHz channels. However, many other 802.11 technologies, such as 802.11k, 802.11r, and 802.11v, may not be supported, even in new client devices. IoT devices with an 802.11 radio usually operate only in the 2.4 GHz frequency band and very often may employ older 802.11g chipset technology to keep costs down. 802.11 RADIO CHIPSETS A group of integrated circuits designed to work together is often marketed as a chipset. Many 802.11 chipset manufacturers exist and sell their chipset technology to the various radio manufacturers and WLAN vendors. Legacy chipsets will obviously not support all the same features as newer chipset technologies. For example, a legacy chipset may support only 802.11a/b/g technology, whereas newer chipsets will support 802.11n/ac technology. Some chipsets may support the ability to transmit only on the 2.4 GHz ISM band; other chipsets can transmit on either the 2.4 GHz or 5 GHz unlicensed frequencies. Chipsets that support both frequencies are used in 802.11a/b/g/n/ac client radios. The chipset manufacturers incorporate newer 802.11 technologies as they develop. Many proprietary technologies turn up in the individual chipsets, and some of these technologies will become part of the standard in future 802.11 amendments. CLIENT UTILITIES An end user must have the ability to configure a wireless client NIC. Therefore, a software interface is needed in the form of client utilities. Much like a driver is the interface between a radio NIC and an operating system, the Wi-Fi client utility is effectively the software interface between the radio NIC and you. The software interface usually has the ability to create multiple connection profiles. One profile may be used to connect to the wireless network at work, another to connect at home, and a third to connect at a hotspot. Configuration settings for a client utility typically include the service set identifier (SSID), transmit power, WPA/WPA2 security settings, WMM quality-of-service capabilities, and power-management settings. Another technical term often used for WLAN client utilities is supplicant. The supplicant terminology is most often used when discussing 802.1X/EAP security. As mentioned in Chapter 7, some client NICs can also be configured for either infrastructure mode or ad hoc mode. Most good client utilities have some sort of statistical information display, along with some sort of received signal strength indicator (RSSI) measurement tool. Some client utilities also allow for the adjustment of client roaming thresholds. The following three major types, or categories, of client utilities exist: Integrated operating system client utilities Vendor-specific client utilities Third-party client utilities The software interface that is most widely used to configure a Wi-Fi radio is usually the integrated operating system Wi-Fi client utilities. Laptop users will most likely use the Wi-Fi NIC configuration interface that is a part of the OS running on the laptop. The client software utilities are different depending on the OS of the laptop being used. The capabilities of the Wi-Fi client utilities also vary between different versions of operating systems. For example, the Windows 8 client utility is different from the Windows 10 client utility. Older macOS client utilities are different from the macOS 10.13 (High Sierra) client utility. Figure 11.6 shows the Windows 10 Wi-Fi client utility. Some OSs, such as the macOS 10.13, offer Wi-Fi diagnostic tools and signal strength indicators, as shown in Figure 11.7. FIGURE 11.6 Integrated OS client utility for Windows 10 FIGURE 11.7 Wireless diagnostic tool for macOS 10.13 The operating systems of handheld devices usually also include some sort of Wi-Fi client utility. Figure 11.8 shows the client interface found in the Apple iOS 11.0, which runs on iPads and iPhones. FIGURE 11.8 Integrated OS client utility for iOS 11.0 Vendor-specific software client utilities are sometimes available for use instead of an integrated operating system software interface. SOHO client utilities are usually simplistic in nature and are designed for ease of use for the average home user. The majority of vendor-specific software utilities are for peripheral device WLAN radios. The use of vendor-specific client utilities has decreased dramatically in recent years as the use of peripheral Wi-Fi radios has also declined. Enterprise-grade vendor client utilities provide the software interface for the more expensive enterprisegrade vendor cards. Typically, the enterprise-class utilities support more configuration features and have better statistical tools. Figure 11.9 shows the Intel PROSet wireless client interface that can be used on Windowsbased laptops with an Intel Wi-Fi radio. FIGURE 11.9 Enterprise-class client utility The last type of software interface for an 802.11 radio card is a third-party client utility, such as SecureW2’s Enterprise Client for Windows, pictured in Figure 11.10. Much like any integrated OS client software, a third-party WLAN supplicant will work with radio cards from different vendors, making administrative support much easier. In the past, third-party client utilities often brought the advantage of supporting many different EAP types, giving a WLAN administrator a wider range of security choices. The main disadvantage of third-party client utilities is that they usually cost extra money. Because integrated client utilities have improved over the years, the use of third-party Wi-Fi client utilities has declined. FIGURE 11.10 Third-party client utility Management, Control, and Data Planes Telecommunication networks are often defined as three logical planes of operation: Management Plane The management plane is defined by administrative network management, administration, and monitoring. An example of the management plane would be any network-management solution that can be used to monitor routers and switches and other wired network infrastructure. A centralized network-management server can be used to push both configuration settings and firmware upgrades to network devices. Control Plane The control plane consists of control or signaling information and is often defined as network intelligence or protocols. Dynamic layer 3 routing protocols, such as OSPF or BGP, used to forward data would be an example of control plane intelligence found in routers. Content addressable memory (CAM) tables and Spanning Tree Protocol (STP) are control plane mechanisms used by layer 2 switches for data forwarding. Data Plane The data plane, also known as the user plane, is the location in a network where user traffic is actually forwarded. An individual router where IP packets are forwarded is an example of the data plane. An individual switch forwarding an 802.3 Ethernet frame is an example of the data plane. In an 802.11 environment, these three logical planes of operation function differently depending on the type of WLAN architecture and the WLAN vendor. For example, in a legacy autonomous AP environment, all three planes of operation existed in each standalone access point (although the control plane mechanisms were minimal). When WLAN controller solutions were first introduced in 2002, all three planes of operation were shifted into a centralized device. In modern deployments, the planes of operation may be divided between access points, WLAN controllers, and/or a wireless network management system (WNMS). MANAGEMENT PLANE The functions of the management plane within an 802.11 WLAN are as follows: WLAN Configuration Examples include the configuration of SSID, security, WMM, channel, and power settings. WLAN Monitoring and Reporting Monitoring of layer 2 statistics, such as ACKs, client associations, reassociations, and data rates, occurs in the management plane. Examples of upper-layer monitoring and reporting include application visibility, IP connectivity, TCP throughput, latency statistics, and stateful firewall sessions. WLAN Firmware Management The ability to upgrade access points and other WLAN devices with the latest vendor operational code is included here. CONTROL PLANE The control plane is often defined by protocols that provide the intelligence and interaction between equipment in a network. Here are a few examples of control plane intelligence: Adaptive RF Coordinated channel and power settings for multiple access points are provided by the control plane. The majority of WLAN vendors implement some type of adaptive RF capability. Adaptive RF is also referred to by the more technical term radio resource management (RRM). Roaming Mechanisms The control plane also provides support for roaming handoffs between access points. Capabilities may include layer 3 roaming, maintaining stateful firewall sessions of clients, and forwarding of buffered packets. Fast secure roaming mechanisms, such as opportunistic key caching (OKC) and fast BSS transition (FT), may also be used to forward master encryption keys between access points. Client Load Balancing Collecting and sharing client load and performance metrics between access points to improve overall WLAN operations happens in the control plane. Mesh Protocols Routing user data between multiple access points requires some sort of mesh routing protocol. Most WLAN vendors use layer 2 routing methods to move user data between mesh access points. However, some vendors are using layer 3 mesh routing. The 802.11s amendment did define standardized mesh routing mechanisms, but WLAN vendors are currently using proprietary methods and metrics. DATA PLANE The data plane is where user data is forwarded. The two devices that usually participate in the data plane are the AP and a WLAN controller. A standalone AP handles all data-forwarding operations locally. In a WLAN controller solution, data is normally forwarded from the centralized controller, but data can also be forwarded at the edge of the network by an AP. As with the management and control planes, each vendor has a unique method and recommendations for handling data forwarding. Data-forwarding models will be discussed in greater detail later in this chapter. WLAN Architecture While the acceptance of 802.11 technologies in the enterprise continues to grow, the evolution of WLAN architecture has kept pace. In most cases, the main purpose of 802.11 technologies is to provide a wireless portal into a wired infrastructure network. How an 802.11 wireless portal is integrated into a typical 802.3 Ethernet infrastructure continues to change drastically. WLAN vendors generally offer one of the following three primary WLAN architectures: Autonomous WLAN architecture Centralized WLAN architecture Distributed WLAN architecture The following sections describe these three architectures in greater detail. AUTONOMOUS WLAN ARCHITECTURE For many years, the conventional access point was a standalone WLAN portal device where all three planes of operation existed and operated on the edge of the network architecture. These APs are often referred to as fat APs or standalone APs. However, the most common industry term for the traditional access point is autonomous AP. All configuration settings exist in the autonomous access point itself, and therefore, the management plane resides individually in each autonomous AP. All encryption and decryption mechanisms and MAC layer mechanisms also operate within the autonomous AP. The data plane also resides in each autonomous AP because all user traffic is forwarded locally by each individual access point. As shown in Figure 11.11, legacy autonomous APs have few shared control plane mechanisms. FIGURE 11.11 Autonomous WLAN architecture An autonomous access point contains at least two physical interfaces: usually a radio frequency (RF) radio and a 10/100/1000 Ethernet port. The majority of the time, these physical interfaces are bridged together by a virtual interface known as a bridged virtual interface (BVI). The BVI is assigned an IP address that is shared by two or more physical interfaces. Access points operate as layer 2 devices; however, they still need a layer 3 address for connectivity to an IP network. The BVI is the management interface of an AP. An autonomous access point typically encompasses both the 802.11 protocol stack and the 802.3 protocol stack. These APs might support the following features: Multiple management interfaces, such as command line, web GUI, and SNMP WEP, WPA, and WPA2 security capabilities WMM quality-of-service capabilities Fixed or detachable antennas Filtering options, such as MAC and protocol Connectivity modes, such as access, mesh, bridge, or sensor Multiple radio and dual-frequency capabilities 802.1Q VLAN support 802.3af or 802.3at PoE support Autonomous APs might have some of the following advanced security features: Built-in RADIUS and user databases VPN client and/or server support DHCP server Captive web portals Autonomous APs are deployed at the access layer and typically are powered by a Power-over-Ethernet (PoE)-capable access layer switch. The integration service within an autonomous AP translates the 802.11 traffic into 802.3 traffic. The autonomous AP was the foundation that WLAN architects deployed for many years. However, most enterprise deployments of autonomous APs were replaced by a centralized architecture utilizing a WLAN controller, which is discussed later in this chapter. CENTRALIZED NETWORK MANAGEMENT SYSTEMS One of the challenges for a WLAN administrator using a large WLAN autonomous architecture is management. As an administrator, would you want to configure 300 autonomous APs individually? One major disadvantage of using the traditional autonomous access point is that there is no central point of management. Any intelligent edge WLAN architecture with 25 or more autonomous access points is going to require some sort of wireless network management system (WNMS). A WNMS moves the management plane out of the autonomous access points. A WNMS provides a central point of management to configure and maintain thousands of autonomous access points. A WNMS can be a hardware appliance or a software solution. WNMS solutions can be vender specific or vender neutral. As shown previously in Figure 11.11, the whole point of a WNMS server was to provide a central point of management for autonomous access points, which are now considered legacy devices. That definition has changed considerably over the years. Later in this chapter, you will learn about WLAN controllers, which are used as central points of management for controller-based APs. WLAN controllers can effectively replace a WNMS server as a central point of management for access points in small-scale WLAN deployments. However, multiple WLAN controllers are needed in large-scale WLAN enterprise deployments. Currently, most WMNS servers are now used as a central point of management for multiple WLAN controllers in large-scale WLAN enterprises. WNMS servers that are used to manage multiple WLAN controllers from a single vendor may in some cases also be used to manage other vendors’ WLAN infrastructure, including standalone access points. The term WNMS is actually outdated, because many of these centralized management solutions can also be used to manage other types of network devices, including switches, routers, firewalls, and VPN gateways. Therefore, network management system (NMS) is now used more often. NMS solutions are usually vendor specific; however, a few exist that can manage devices from a variety of networking vendors. The main purpose of an NMS is to provide a central point of management and monitoring for network devices. Configuration settings and firmware upgrades can be pushed down to all the network devices. Although centralized management is the main goal, an NMS can have other capabilities as well, such as RF spectrum planning and management of a WLAN. An NMS can also be used to monitor network architecture with alarms and notifications centralized and integrated into a management console. An NMS provides robust monitoring of network infrastructure as well as monitoring of wired and wireless clients connected to the network. As shown in Figure 11.12, NMS solutions usually have extensive diagnostic utilities that can be used for remote troubleshooting. FIGURE 11.12 NMS diagnostic utilities An NMS is a management plane solution; therefore, no control plane or data plane mechanisms exist within an NMS. For example, the only communications between an NMS and an access point are management protocols. Most NMS solutions use the Simple Network Management Protocol (SNMP) to manage and monitor the WLAN. Other NMS solutions also use the Control and Provisioning of Wireless Access Points (CAPWAP) protocol as strictly a monitoring and management protocol. CAPWAP incorporates Datagram Transport Layer Security (DTLS) to provide encryption and data privacy of the monitored management traffic. User traffic is never forwarded by an access point to an NMS; the 802.11 client associations and traffic can still be monitored. Figure 11.13 shows an NMS display of multiple client associations across multiple APs. NMS solutions can be deployed at a company data center in the form of a hardware appliance or as a virtual appliance that runs on VMware or some other virtualization platform. A network management server that resides in a company’s own data center is often referred to as an onpremises NMS. NMS solutions are also available in the cloud as a software subscription service. Many WLAN vendors now offer access to their NMS solutions via APIs. An application programming interface (API) is a set of subroutine definitions, protocols, and tools for building application software. Customers and partners can use the WLAN vendor APIs to build their own custom applications to monitor the WLAN. Custom applications can also be built for WLAN device configuration. APIs will be discussed in greater detail later in this chapter. FIGURE 11.13 NMS client monitoring CENTRALIZED WLAN ARCHITECTURE The next progression in the development of WLAN integration is the centralized WLAN architecture. This model uses a central WLAN controller that resides in the core of the network. In the centralized WLAN architecture, autonomous APs have been replaced with controllerbased access points, also known as lightweight APs or thin APs. Beginning in 2002, many WLAN vendors decided to move to a WLAN controller model where all three logical planes of operation would reside inside the controller. In a centralized WLAN architecture, the three logical planes exist in a WLAN controller. Management Plane Access points are configured and managed from the WLAN controller. Control Plane Adaptive RF, load balancing, roaming handoffs, and other mechanisms exist in the WLAN controller. Data Plane The WLAN controller exists as a data distribution point for user traffic. Access points tunnel all user traffic to a central controller. The encryption and decryption capabilities might reside in the centralized WLAN controller or may still be handled by the controller-based APs, depending on the vendor. The distribution system service (DSS) and integration service (IS) both typically function within the WLAN controller. Some time-sensitive operations are still handled by the AP. WLAN Controller At the heart of the centralized WLAN architecture model is the WLAN controller (see Figure 11.14). WLAN controllers are often referred to as wireless switches because they are indeed an Ethernet-managed switch that can process and route data at the Data-Link layer (layer 2) of the OSI model. Many of the WLAN controllers are multilayer switches that can also route traffic at the Network layer (layer 3). However, wireless switch has become an outdated term and does not adequately describe the many capabilities of a WLAN controller. FIGURE 11.14 Centralized WLAN architecture: WLAN controller A WLAN controller may offer many of the following features: AP Management As mentioned earlier, the majority of the access point functions, such as power, channels, and supported data rates, are configured on the WLAN controller. This allows for centralized management and configuration of APs. Some vendors use proprietary protocols for communications between the WLAN controller and their controller-based APs. These proprietary protocols can transfer configuration settings, update firmware, and maintain keep-alive traffic. A WLAN management protocol has gained acceptance. Many WLAN vendors use the Control and Provisioning of Wireless Access Points (CAPWAP) protocol for managing and monitoring access points. CAPWAP can also be used to tunnel user traffic between an AP and a WLAN controller. WLAN Management WLAN controllers are capable of supporting multiple WLANs, which are often called WLAN profiles or SSID profiles. Different groups of 802.11 clients can connect to a different SSID that is unique to each profile. The WLAN profile is a set of configuration parameters that are configured on the WLAN controller. The profile parameters can include the WLAN logical name (SSID), WLAN security settings, VLAN assignment, and quality-of-service (QoS) parameters. WLAN profiles often work together with role-based access control (RBAC) mechanisms. When users connect to a WLAN, users are assigned to specific roles or user profiles. User Management WLAN controllers usually provide the ability to control the who, when, and where in terms of using role-based access control (RBAC) mechanisms. Device Monitoring WLAN controllers provide visual AP monitoring and client device statistics in terms of connectivity, roaming, uptime, and more. VLANs WLAN controllers fully support the creation of VLANs and 802.1Q VLAN tagging. Multiple wireless user VLANs can be created on the WLAN controller so that user traffic can be segmented. VLANs may be assigned statically to WLAN profiles or may be assigned using a RADIUS attribute. User VLANs are usually encapsulated in an IP tunnel. Layer 2 Security Support WLAN controllers fully support layer 2 WEP, WPA, and WPA2 encryption. Authentication capabilities include internal databases as well as full integration with RADIUS and LDAP servers. Layer 3 and 7 VPN Concentrators Some WLAN controller vendors also offer VPN server capabilities within the controller. The controller can act as a VPN concentrator or endpoint for IPsec or SSL VPN tunnels. Captive Portal WLAN controllers have captive portal features that can be used with guest WLANs. Internal Wireless Intrusion Detection Systems Some WLAN controllers have integrated WIPS capabilities for security monitoring and rogue AP mitigation. Firewall Capabilities Stateful packet inspection is available with an internal firewall in some WLAN controllers. Automatic Failover and Load Balancing WLAN controllers usually provide support for Virtual Router Redundancy Protocol (VRRP) for redundancy purposes. Most vendors also offer proprietary capabilities to load-balance wireless clients between multiple controller-based APs. Adaptive RF Spectrum Management The majority of WLAN controllers implement some type of adaptive RF capability. A WLAN controller is a centralized device that can dynamically change the configuration of the controller-based access points based on accumulated RF information gathered from the access points’ radios. In a WLAN controller environment, the access points will monitor their respective channels as well as use off-channel scanning capabilities to monitor other frequencies. Any RF information heard by any of the access points is reported back to the WLAN controller. Based on all the RF monitoring from multiple access points, the WLAN controller will make dynamic changes to the RF settings of the APs. Some access points may be told to change to a different channel, whereas other APs may be told to change their transmit power settings. Adaptive RF is sometimes referred to as radio resource management (RRM) and is considered to be control plane intelligence. All WLAN vendors implement their own proprietary adaptive RF functionality. When implemented, adaptive RF provides automatic cell sizing, automatic monitoring, troubleshooting, and optimization of the RF environment. Bandwidth Management Bandwidth pipes can be restricted upstream or downstream. Layer 3 Roaming Support Capabilities to allow seamless roaming across layer 3 routed boundaries are fully supported. A more detailed discussion on layer 3 roaming and the Mobile IP standard can be found in Chapter 13, “WLAN Design Concepts.” Power over Ethernet (PoE) When deployed at the access layer, WLAN controllers can provide direct power to controller-based APs via PoE. However, most controller-based APs are powered by third-party edge switches. Management Interfaces Many WLAN controllers offer full support for common management interfaces, such as GUI, CLI, SSH, and so forth. Split MAC The majority of WLAN controller vendors implement what is known as a split MAC architecture. With this type of WLAN architecture, some of the MAC services are handled by the WLAN controller, and some are handled by the access point. For example, the integration service and distribution system service are handled by the controller. WMM QoS methods are usually handled by the controller. Depending on the vendor, encryption and decryption of 802.11 data frames might be handled by the controller or by the AP. You have already learned that 802.11 frames are tunneled between the controller-based APs and the WLAN controller. 802.11 data frames are usually tunneled to the controller because the controller’s integration service transfers the layer 3–7 MSDU payload of the 802.11 data frames into 802.3 frames that are sent off to network resources. Effectively, the WLAN controller is needed to provide a centralized gateway to network resources for the payload of 802.11 data frames. 802.11 management and control frames do not have an upper-layer payload and therefore are never translated into 802.3 frames. 802.11 management and control frames do not necessarily need to be tunneled to the WLAN controller, because the controller does not have to provide a gateway to network resources for these types of 802.11 frames. In a split MAC architecture, many of the 802.11 management and control frame exchanges occur only between the client station and the controllerbased access point and are not tunneled back to the WLAN controller. For example, beacons, probe responses, and ACKs may be generated by the controller-based AP instead of the controller. It should be noted that most WLAN controller vendors implement split MAC architectures differently. Many WLAN controller solutions use the Control and Provisioning of Wireless Access Points (CAPWAP) protocol for monitoring and management. CAPWAP also defines split MAC capabilities. The CAPWAP protocol can be used to tunnel 802.11 traffic between an AP and a WLAN controller. Controller Data-Forwarding Models A key feature of most WLAN controllers is that the integration service (IS) and distribution system services (DSSs) operate within the WLAN controller. In other words, all 802.11 user traffic that is destined for wired-side network resources must first pass through the controller and be translated into 802.3 traffic by the integration service before being sent to the final wired destination. Therefore, controller-based access points send their 802.11 frames to the WLAN controller over an 802.3 wired connection. The 802.11 frame format is complex and is designed for a wireless medium, not a wired medium. An 802.11 frame cannot travel through an Ethernet 802.3 network by itself. So, how can an 802.11 frame traverse between a controller-based AP and a WLAN controller? The 802.11 traffic is forwarded inside an IP-encapsulated tunnel. Each 802.11 frame is encapsulated entirely within the body of an IP packet. Many WLAN vendors use Generic Routing Encapsulation (GRE), which is a commonly used network tunneling protocol. Although GRE is often used to encapsulate IP packets, GRE can also be used to encapsulate an 802.11 frame inside an IP tunnel. The GRE tunnel creates a virtual point-to-point link between the controller-based AP and the WLAN controller. Although GRE is the most common choice, WLAN vendors might use IPsec or proprietary protocols for IP tunneling. The CAPWAP management protocol can also be used to tunnel user traffic. As shown in Figure 11.15, the controller-based APs tunnel their 802.11 frames all the way back to the WLAN controller, from the access layer all the way back to the core layer. The distribution system service inside the controller directs the traffic, whereas the integration service translates an 802.11 data MSDU into an 802.3 frame. After 802.11 data frames have been translated into 802.3 frames, they are then sent to their final wired destination. FIGURE 11.15 Centralized data forwarding Most WLAN controllers are deployed at the core layer; however, they may also be deployed at either the distribution layer or even the access layer. Exactly where a WLAN controller is deployed depends on the WLAN vendor’s solution and the intended wireless integration into the preexisting wired topology. Multiple WLAN controllers that communicate with each other may be deployed at different network layers, providing they can communicate with each other. There are two types of data-forwarding methods when using WLAN controllers: Centralized Data Forwarding Where all data is forwarded from the AP to the WLAN controller for processing. It may be used in many cases, especially when the WLAN controller manages encryption and decryption or applies security and QoS policies. Distributed Data Forwarding Where the AP performs data forwarding locally may be used in situations where it is advantageous to perform forwarding at the edge and to avoid a central location in the network for all data, which may require significant processor and memory capacity at the controller. As shown in Figure 11.15, centralized data forwarding relies on the WLAN controller to forward data. The AP and WLAN controller form an IP encapsulation tunnel, and all user data traffic is passed to the controller for forwarding (or comes from the controller). In essence, the AP plays a passive role in user data handling. As illustrated in Figure 11.16, with distributed forwarding scenarios, the AP is solely responsible for determining how and where to forward user data traffic. The controller is not an active participant in these processes. This includes the application of QoS or security policies to data. Generally speaking, the device that handles the majority of MAC functions is also likely to handle data forwarding. The decision to use distributed or centralized forwarding is based on a number of factors, such as security, VLANs, and throughput. One major disadvantage of distributed data forwarding is that some control plane mechanisms may be unavailable because they exist only in the WLAN controller. Control plane mechanisms that may be lost include adaptive RF, layer 3 roaming, firewall policy enforcement, and fast secure roaming. However, as the controller architecture has matured, some WLAN vendors have also pushed some of the control plane mechanisms back into the APs at the edge of the network. FIGURE 11.16 Distributed data forwarding As 802.11ac technology and bandwidth become increasingly prevalent in large, enterprise networks, centralized data forwarding may become more difficult and expensive due to the traffic loads that can now be generated on the WLAN. Larger controllers with 10 Gbps links will become more commonplace. Additionally, WLAN controller manufacturers are now beginning to embrace distributed data forwarding in different ways. Remote Office WLAN Controller Although WLAN controllers typically reside on the core of the network, they can also be deployed at the access layer, usually in the form of a remote office WLAN controller. A remote office WLAN controller typically has much less processing power than a core WLAN controller and is also less expensive. The purpose of a remote office WLAN controller is to allow remote and branch offices to be managed from a single location. Remote WLAN controllers typically communicate with a central WLAN controller across a WAN link. Secure VPN tunneling capabilities are usually available between controllers across the WAN connection. Through the VPN tunnel, the central controller will download the network configuration settings to the remote WLAN controller, which will then control and manage the local APs. These remote controllers will allow for only a limited number of controller-based APs. Features typically include Power over Ethernet, internal firewalling, and an integrated router using NAT and DHCP for segmentation. DISTRIBUTED WLAN ARCHITECTURE A recent trend has been to move away from the centralized WLAN controller architecture toward a distributed architecture. Some WLAN vendors, such as Aerohive Networks, have designed their entire WLAN system around a distributed architecture. Some of the WLAN controller vendors now also offer a distributed WLAN architecture solution, in addition to their controller-based solution. In these systems, cooperative access points are used, and control plane mechanisms are enabled in the system with inter-AP communication via cooperative protocols. A distributed WLAN architecture combines multiple access points with a suite of cooperative protocols, without requiring a WLAN controller. Distributed WLAN architectures are modeled after traditional routing and switching design models, in that the network nodes provide independent distributed intelligence but work together as a system to cooperatively provide control mechanisms. As shown in Figure 11.17, the protocols enable multiple APs to be organized into groups that share control plane information between the APs to provide functions such as layer 2 roaming, layer 3 roaming, firewall policy enforcement, cooperative RF management, security, and mesh networking. The best way to describe a distributed architecture is to think of it as a group of access points with most of the WLAN controller intelligence and capabilities mentioned earlier in this chapter. The control plane information is shared between the APs using proprietary protocols. FIGURE 11.17 Distributed WLAN architecture In a distributed architecture, each individual access point is responsible for local forwarding of user traffic. As mentioned earlier, since the advent of 802.11n, WLAN controller vendors have begun to offer distributed data-forwarding solutions to handle traffic load. Because a distributed WLAN architecture entirely eliminates a centralized WLAN controller, all user traffic is forwarded locally by each independent AP. In a distributed architecture, the data plane resides in the access points at the edge of the network. No WLAN controller exists; therefore, the data does not need to be tunneled to the core of the network. Although the control plane and data planes have moved back to the APs in a distributed WLAN architecture, the management plane remains centralized. Configuration and monitoring of all access points in the distributed model is still handled by an NMS server. The NMS server might be an on-premises server or might be offered as a cloud-based service. Most of the features mentioned in the earlier section about WLAN controllers can also be found in a distributed WLAN architecture even though there is no WLAN controller. For example, a captive web portal that normally resides in a WLAN controller instead resides inside the individual APs. The stateful firewall and RBAC capabilities found in a centralized WLAN controller now exist cooperatively in the APs. Back-end roaming mechanisms and adaptive RF are also cooperative. APs might also function as a RADIUS server with full LDAP integration capabilities. As mentioned earlier, all control plane mechanisms reside in communications between the access points at the edge of the network in a distributed WLAN architecture. The APs implement control plane mechanisms cooperatively using proprietary protocols. How VLANs are deployed in a WLAN environment depends on the design of the network as well as the type of WLAN architecture that is in place. One very big difference between using a controller-based model versus a noncontroller model is how VLANs are implemented in the network design. In the WLAN controller model, most user traffic is centrally forwarded to the controller from the APs. Because all the user traffic is encapsulated, a controller-based AP typically is connected to an access port on an Ethernet switch that is tied to a single VLAN. With a WLAN controller architecture, the user VLANs usually reside in the core of the network. The user VLANs are not available at the access layer switch. The controller-based APs are connected to an access port of the edge switch. The user VLANs are still available to the wireless users because all of the user VLANs are encapsulated in an IP tunnel between the controller-based APs at the edge and the WLAN controller in the core. The noncontroller model, however, requires support for multiple user VLANs at the edge. Each access point is therefore connected to an 802.1Q trunk port on an edge switch that supports VLAN tagging. All of the user VLANs are configured in the access layer switch. The access points are connected to an 802.1Q trunk port of the edge switch. The user VLANS are tagged in the 802.1Q trunk, and all wireless user traffic is forwarded at the edge of the network. Although the whole point of a cooperative and distributed WLAN model is to avoid centrally forwarding user traffic to the core, the access points may also have IP-tunneling capabilities. Some WLAN customers require that guest VLAN traffic not cross internal networks. In that scenario, a standalone AP might forward only the guest user VLAN traffic in an IP tunnel that terminates at another standalone access point that is deployed in a DMZ. Individual APs can also function as a VPN client or VPN server using IPsec encrypted tunnels across a WAN link. Another advantage of the distributed WLAN architecture is scalability. As a company grows at one location or multiple locations, more APs will obviously have to be deployed. When a WLAN controller solution is in place, more controllers might also have to be purchased and deployed as the AP count grows. With the controller-less distributed WLAN architecture, only new APs are deployed as the company grows. Many vertical markets such as K–12 education and retail have schools or stores at numerous locations. A distributed WLAN architecture be the better choice as opposed to deploying a WLAN controller at each location. HYBRID WLAN ARCHITECTURE It is important to understand that none of the WLAN architectures described in this chapter are written in stone. Many hybrids of these WLAN architectures exist among the WLAN vendors. As was already mentioned, some of the WLAN controller vendors are pushing some of the control plane intelligence back into the access points. One WLAN controller vendor has a cloud-based controller where much of the control plane intelligence exists in the cloud. Typically, the data plane is centralized when using WLAN controllers, but distributed data forwarding is also available. Some WLAN vendors have moved the data plane back to the edge of the network, with APs handling the data forwarding of user traffic. With a controller-less distributed WLAN architecture, all data is forwarded locally, but the ability to centralize the data plane is a capability of a distributed WLAN architecture. In general, most WLAN vendors now have the option to either centralize or locally forward the data plane depending on the location of the APs and the traffic routes available. In a distributed WLAN architecture, the management plane resides in an on-premises or cloud-based network management service. With the WLAN controller model, the management plane normally exists in the WLAN controller. However, the management plane might also be pushed into an NMS that not only manages the controller-based APs but also manages the WLAN controllers. Specialty WLAN Infrastructure In the previous sections, we discussed the progression of WLAN network infrastructure devices that are used to integrate an 802.11 wireless network into a wired network architecture. The Wi-Fi marketplace has produced many specialty WLAN devices in addition to APs and WLAN controllers. Many of these devices, such as bridges and mesh networks, have become extremely popular, although they operate outside of the defined 802.11 standards. You will look at these devices in the following sections. ENTERPRISE WLAN ROUTERS In addition to the main corporate office, companies often have branch offices in remote locations. A company might have branch offices across a region or an entire country, or they may even be spread globally. The challenge for IT personnel is how to provide a seamless enterprise wired and wireless solution across all locations. A distributed solution using enterprise-grade WLAN routers at each branch office is a common choice. Keep in mind that WLAN routers are very different from access points. Unlike access points, which use a bridged virtual interface, wireless routers have separate routed interfaces. The radio card exists on one subnet, whereas the WAN Ethernet port exists on a different subnet. Branch WLAN routers have the ability to connect back to corporate headquarters with VPN tunnels. Employees at the branch offices can access corporate resources across the WAN through the VPN tunnel. Even more important is the fact that the corporate VLANs, SSIDs, and WLAN security can all be extended to the remote branch offices. Employees at a branch office connect to the same SSID that they would connect to at corporate headquarters. The wired and wireless network access policies are therefore seamless across the entire organization. These seamless policies can be extended to the WLAN routers at each branch location. The enterprise-grade WLAN routers are very similar to the consumergrade Wi-Fi routers that most of us use at home. However, enterprise WLAN routers are manufactured with better-quality hardware and offer a wider array of features. The following security features are often supported by enterprise WLAN routers: 802.11 layer 2 security for wireless clients 802.1X/EAP port security for wired clients Network address translation (NAT) Port address translation (PAT) Port forwarding Firewall Integrated VPN client 3G/4G cellular backhaul WLAN MESH ACCESS POINTS Almost all WLAN vendors now offer WLAN mesh access point capabilities. Wireless mesh APs communicate with each other by using proprietary layer 2 routing protocols and create a self-forming and selfhealing wireless infrastructure (a mesh) over which edge devices can communicate, as shown in Figure 11.18. The main purpose of a mesh WLAN is to provide wireless client access in physical areas where an Ethernet cable cannot be connected to an AP. WLAN client traffic can be sent over wireless backhaul links with an eventual destination to mesh portals that are connected to the