Troubleshooting Wireless Network

Physical Connections and LEDs

Trouble usually happens between Layer 1 and Layer 3 of the OSI reference model. That is not to say that trouble does not occur at Layers 4 through 7, but Layers 1 through 3 are the layers where network administrators have the most hands on. Working your way up can often prove to be a time saver. Starting at Layer 1, physical connectivity can often save valuable time. You can begin by visually examining the physical connections. Keep in mind all that is involved in the path of your traffic. This can include areas related to the following:

• AP to switcch
• Switch to switch
• Switch to controller
• Controller to distribution

While you are examining the physical connectivity, note the port LED status of each device. What do the LEDs indicate? Are they green? Are they amber? Are they red? Each device has different LEDs; for example, the LEDs on a controller are different from the LEDs on an AP, yet they all have somewhat of a common color coding. Usually red is bad, amber is not so good, and green is okay. Look up the Cisco documentation for details for each product that you work with. The “References” section at the end of this chapter in- cludes some valuable links that can help you determine issues in the network and correct them, some using the port LEDs for verification.

After you have verified the physical connections, you can work in one of two directions:

• Verification from the client back to the controller

• Verification from the controller to the client

In either case, common issues arise. You might find that connectivity issues are not related to the wireless network at all, but rather the distribution network, gateway, or Internet service provider (ISP). Regardless, the ability to isolate problems is a requirement of those seeking the CCNA Wireless certification. The next section explores some common client- side issues.


Common Client-Side Issues

Client-side issues arise frequently and are often expressed in vague ways, for example, “I cannot get to the Internet.” “Okay,” you might think, “What does that mean?” The answer might not always be clear, but you can verify some values to quickly restore connectivity for end users.

Some of the more common issues that you can verify include the following:

• Check that the client card is enabled. Many laptops have a hardware switch that dis- ables the wireless card internally, which can cause issues.

• Check that service set identifiers (SSIDs) are not incorrectly configured.

• Verify whether the client is using a radio that is not enabled on the AP.

• Verify whether the MAC address of the client is being “blacklisted” on the network.

• If using 802.1x, verify whether the client side is configured to support the network method, such as Extensible Authentication Protocol-Transport Layer Security (EAP- TLS) with certificates.

• Verify whether the client is getting an IP address that is blocked by an access control list (ACL) somewhere else in the network.

• Check the client firewall or antivirus software, because it might be blocking access. There might not be much you can do other than asking the client to turn each of these off temporarily for testing.

• If performing Network Access Control (NAC), check whether the client is posturing properly. Check the Authentication, Authorization, and Accounting (AAA) server or the Monitoring, Analysis, and Response System (MARS) logs to determine this. From a wireless perspective, there is not much you can do except have the users access a “Guest” type of network that does not require security posturing.

• If you are using preshared keys for wireless authentication, verify that they are cor- rectly configured on the client side. Also, verify that they are configured for the cor- rect length.

Authentication and Encryption

Now that you understand some of the methods used to authenticate users, it’s time to ex- plore some encryption methods. The beginning of this chapter discussed WEP. The prob- lem with WEP is that it can be broken easily. Therefore, other methods have been established in an effort to provide more strength in encryption. In the following sections, you will learn about Wi-Fi Protected Access (WPA) and Wi-Fi Protected Access 2 (WPA2).


WPA Overview

WPA was introduced in 2003 by the Wi-Fi Alliance as a replacement for WEP. WPA uses Temporal Key Integrity Protocol (TKIP) to automatically change the keys. TKIP still uses RC4; it just improves how it’s done. This is a major improvement over static WEP. WPA can optionally support Advanced Encryption Standard (AES), but it’s not mandatory. WPA is based on 802.11i draft version 3. WEP uses RC4 encryption, which is very weak. The better alternative was to use AES encryption, but that would have required an equip- ment upgrade. To avoid an equipment upgrade, WPA was developed to use TKIP and a larger IV than WEP. This would make it more difficult to guess the keys while not requir- ing new hardware. Instead, you could simply perform a firmware upgrade in most cases.

WPA offers two authentication modes:

• Enterprise mode: Enterprise mode WPA requires an authentication server. RADIUS is used for authentication and key distribution, and TKIP is used with the option of AES available as well.

• Personal mode: Personal mode WPA uses preshared keys, making it the weaker op- tion, but the one that is most likely to be seen in a home environment.

Figure 17-15 shows the process of WPA authentication.


At the beginning of negotiations, the client and AP must agree on security capabilities. After the two agree on the same level of security, the 802.1x process starts. This is the standard 802.1x process, as outlined previously. After successful 802.1x authentication, the authentication server derives a master key and sends it to the AP. The same key is de- rived from the client. Now the client and the AP have the same Pairwise Master Key (PMK) , which will last for the duration of the session.

Next, a four-way handshake occurs (see Figure 17-16), in which the client and authentica- tor communicate and a new key called a Pairwise Transient Key (PTK) is derived. This key confirms the PMK between the two, establishes a temporal key to be used for message encryption, authenticates the negotiated parameters, and creates keying material for the next phase, called the two-way group key handshake.


When the two-way group key handshake occurs, the client and authenticator negotiate the Group Transient Key (GTK), which is used to decrypt broadcast and multicast trans- missions.

In Figure 17-16, you can see that the AP first generates a random number and sends it to the client. The client then uses a common passphrase along with this random number to derive a key that is used to encrypt data to the AP. The client then sends its own random number to the AP, along with a Message Integrity Code (MIC), which is used to ensure that the data is not tampered with. The AP generates a key used to encrypt unicast traffic to the client. To validate, the AP sends the random number again, encrypted using the de- rived key. A final message is sent, indicating that the temporal key (TK) is in place on both sides.

The two-way handshake that exchanges the group key involves the generation of a Group Master Key (GMK) , usually by way of a random number. After the AP generates the GMK, it generates a group random number. This is used to generate a Group Temporal Key (GTK) . The GTK provides a group key and a MIC. This key changes when it times out or when a client leaves the network.

Threats to Wireless Networks

Throughout this book, you have learned about the many threats to wireless networks. If you really wanted to simplify the threats, you could think of it like this: You want legiti- mate clients to connect to legitimate APs and access corporate resources. Some attacks are formed from the perspective of an AP trying to gain information from clients. Other attacks are from the perspective of getting illegitimate clients onto the network to use corporate resources at no charge or to actually steal data or cause harm to the network.

These threats include the following:

• Ad hoc networks
• Rogue APs
• Client misassociation
• Wireless attacks

Ad Hoc Networks

An ad hoc network is a wireless network formed between two clients. The security risk in- volves bypassing corporate security policies. An attacker could form an ad hoc network with a trusted client, steal information, and even use it as a means of attacking the corpo- rate network by bridging to the secure wired LAN.


Rogue APs

A rogue AP is not part of the corporate infrastructure. It could be an AP that’s been brought in from home or an AP that’s in a neighboring network. A rogue AP is not always bad. It could be an AP that’s part of the corporate domain yet still operating in au- tonomous mode. Part of an administrator’s job is determining if the AP is supposed to be there. Fortunately, you don’t have to do all the work yourself. A few functions of the AP’s software can detect rogue APs and even indicate if they are on your network.

Something to consider when looking for rogue APs is what happens to clients that can connect to those rogue APs. If a client connects to a rogue AP, it should be considered a rogue client. The reason is that rogue APs typically are installed with default configura- tions, meaning that any client that connects bypasses any corporate security policy. So you do not know if the client is a corporate user or an attacker.


Client Misassociation

When a client connects to an AP, operating system utilities normally allow the client to save the SSID. In the future, when that SSID is seen again, the client can create a connec- tion automatically. There is a possibility that clients will be unaware of the connection. If the SSID is being spoofed, the client could connect to a potentially unsafe network. Con- sider the following scenario. An attacker learns the SSID of your corporate network. Us- ing this information, he sends beacons advertising your SSID. A wireless station in the range of the rogue AP connects to the AP. The AP allows connectivity to the Internet but is not actually on your corporate wired network. Using tools that are easily available on the Internet, another client connected to the same rogue AP attacks the misassociated client and steals valuable corporate data.

This scenario employs multiple attack methods. It uses a method known as management frame spoofing as well as an active attack against a misassociated client. So how can this be prevented? The answer begins with a function called Management Frame Protection.


Management Frame Protection

One method of Management Frame Protection (MFP) is Infrastructure MFP. With this method, each management frame includes a cryptographic hash called a Message In- tegrity Check (MIC). The MIC is added to each frame before the Frame Check Sequence (FCS). When this is enabled, each WLAN has a unique key sent to each radio on the AP. Then, the AP sends management frames, and the network knows that this AP is in protec- tion mode. If the frame were altered, or if someone spoofs the SSID of the WLAN and doesn’t have the unique key, it invalidates the message. This causes other APs that hear the invalid frames to report them to the controller.

The other method of MFP is called Client MFP. If the client is running Cisco Compatible Extensions (CCX) 5 or better, it can talk to the AP and find out what the MIC is. Then it can verify management frames it hears in addition to the APs that provide this function. The major benefit of this mode is the extension of detection. In Figure 17-1, the APs are in the middle of the network, and clients are on the outside. The clients can detect the AP called BAD_AP that is generating invalid frames, even though BAD_AP is out of the range of the APs that are in protection mode.

With MFP version 1, all local mode APs are protectors. They digitally sign all frames they send. Any other AP, or the same local mode AP, for that matter, could be a validator.

With MFP version 2, clients must run the Cisco Secure Services Client (CSSC) or a client that is capable of CCXv5. This enables the client to hear the rogue and report illegitimate frames. You don’t have to worry about your client associating with the rogue AP, because it drops invalid frames.

Client MFP has another benefit. Suppose a neighboring AP performed containment as a denial-of-service (DoS) method against your network because it’s a deauthentication frame that is used for containment. The client would see that the containment frame does- n’t have the MIC and would ignore the deauthentication frame. This would keep people from containing your network as a form of DoS attack.


To enable MFP, choose SSEECCUURRIITTYY >> WWiirreelleessss PPrrootteeccttiioonn PPoolliicciieess >> AAPP AAuutthheennttiiccaa-- ttiioonn//MMFFPP . You view MFP with the Wireless LAN Controller by choosing SSEECCUURRIITTYY >> WWiirreelleessss PPrroot teeccttiioonn PPoolliicciieess >> MMaannaaggeemmeenntt FFrraammee PPrrootteeccttiioonn , as shown in Figure 17-2.


Wireless Attacks

It’s not news that networks in general are constantly bombarded with attacks. Some of these attacks are unique to wireless networks, as is the case with management frame spoofing. With management frame spoofing, a rogue AP advertises an SSID known to the


client in an attempt to get the client to connect to the rogue AP. Other attacks apply to both wired and wireless networks:

• Reconnaissance attacks: An attacker attempts to gain information about your net- work. Initially, the method of mitigating recon attacks involved hiding the SSID by not broadcasting it in beacon frames.

• Access attacks: An attacker tries to gain access to data, devices, and/or the net- work. Initially the method of preventing access to the network involved MAC-based authentication as well as static Wired Equivalent Privacy (WEP). The problem with WEP today is that the keys can be broken in 4 to 7 minutes.

• Denial-of-service (DoS) attacks: An attacker attempts to keep legitimate users from gaining services they require. Today, the use of intrusion detection system/in- trusion prevention system (IDS/IPS) sensors on the wired network can help mitigate these attacks. You also can use MFP to prevent containment DoS attacks.

• The mitigation methods used to prevent attacks mentioned here are not very advanced and are considered weak by today’s standards. However, you might be wondering how these methods work. What alternatives are there if these mitigation methods are weak? What other options exist? The following sections discuss these aspects.

Types of Roaming

Before we dive into roaming as a Layer 2 or 3 process, let’s define it. Roaming is the move- ment of a client from one AP to another while still transmitting. Roaming can be done across different mobility groups, but must remain inside the same mobility domain. Con- sider the following examples.

Figure 12-4 shows a client transmitting data and moving from AP1 to AP2. These two APs are in the same mobility domain. This is roaming.


Figure 12-5 shows a client transmitting data and moving from AP2 to AP3. These two APs are in different mobility groups but are in the same mobility domain. This too is roaming.

Now here is where roaming breaks. In Figure 12-6, a user is transmitting data and decides to go work at a local coffee shop that offers wireless network access. After buying a $5 cup of coffee and settling down into a cushy sofa, he fires up his laptop and continues surfing the net. This is not roaming. In this case, the user has a new IP address, and any sessions that were active before need to be restarted.

The following must occur for your controllers to support roaming:

• The controllers need to be in the same mobility domain.

• The controllers need to run the same code version.

• The controllers need to operate in the same LWAPP mode.

• Access control lists (ACL) in the network need to be the same.

• The SSID (WLAN) needs to be the same.

The following section takes a closer look at the Layer 2 roaming process.



The Layer 2 Roaming Process

As previously discussed, Layer 2 roaming happens when a user moves to another AP but stays on the same VLAN and the same IP subnet. As far as the user is concerned, nothing special has happened. The client isn’t notified that he is roaming. He also keeps his IP ad- dress, and all active transmissions stay active. This process is handled within a single con- troller. This process is called intracontroller roaming and takes less than 10 ms. Behind the scenes, the client, when roaming to a new AP, sends a query to request authentication. The query is sent from the AP to the controller, where the controller realizes that the client is already authenticated, just via another AP. The client is then registered as roaming in the controller, although you do not see this in the controller or in the WCS, and life goes on. Figure 12-7 depicts this scenario.


Now take that same scenario and add another controller, as shown in Figure 12-8. Here, the client associated with Controller1 is on VLAN10. Upon roaming to AP3, which is managed by Controller2, the connection stays active. What happened? In this situation, intercontroller roaming happened. This occurs when a user roams from one controller to another but remains on the same VLAN and does not have to perform a DHCP process again, which would force the session to break. The two controllers are configured with the same mobility group. The two controllers then exchange mobility messages. Using mobil- ity messages, the client database entry on Controller1 is moved to Controller2. This hap- pens in less than 20 ms. Again, the process is transparent to the user. He roams, data keeps flowing, sessions stay active, and life is good.


Both intracontroller roaming and intercontroller roaming allow the user to roam and re- main on the same IP subnet. This is Layer 2 roaming. Now let’s explore Layer 3 roaming.


The Layer 3 Roaming Process

As with Layer 2 roaming, the goal of Layer 3 roaming is for a client to roam transparently. The difference is that you are working with multiple controllers on different subnets. The catch is that although the controllers are on different subnets, the user does not change IP addresses. Instead, the controllers tunnel the traffic back to the original controller. So it’s a smoke-and-mirrors configuration. You are literally making the network believe that the user hasn’t roamed. The two tunneling methods are as follows:

• Asymmetric tunneling: In asymmetric tunneling, traffic from the client is routed to the destination, regardless of its source address, and the return traffic is sent to its original controller, called an anchor, and is tunneled to the new controller.

• Symmetric tunneling: In symmetric tunneling, all traffic is tunneled from the client to the anchor controller, sent to the destination, returned to the anchor controller, and then tunneled back to the client via the foreign controller.

Asymmetric Tunneling

When a client roams in an intercontroller roam, the database entry moves to the new con- troller. That’s not the case with Layer 3 roaming. In the case of Layer 3 roaming, the client’s entry in the original controller is marked as an anchor entry. Then the database en- try is not moved; instead, it is copied to the foreign controller. On the foreign controller, the entry is marked “Foreign.” The client is then reauthenticated, the entry is updated in the new AP, and the client is good to go. The client’s IP address doesn’t change. All this is transparent to the user. Figure 12-9 depicts this process.


Normally when a client sends traffic, it is sent to a default gateway, assuming that it is leav- ing the subnet, and then on to the destination. The traffic makes its way back to the client, taking the reverse path that it traveled to get there. This means that if Controller1 sends traffic to Router1 and then to Server1, Server1 returns the traffic via Router1 and then Controller1, as shown in Figure 12-10.

After the client roams to a new controller and a new AP, the return traffic is not delivered to the correct controller. So the anchor controller sees that the return traffic is for a client with an entry marked anchor and knows that it needs to tunnel it to the foreign controller. The foreign controller, upon receiving the packet, forwards it to the client, and all is well. This is how asymmetric tunneling works.

However, this configuration has some problems. Today’s networks are taking more and more security precautions; one of these precautions is Reverse Path Filtering (RPF), a function used by routers. The router examines all packets received as input on that inter- face to make sure that the source address and source interface appear in the routing table and match the interface on which the packet was received. Also, following RFC 3837 and some other antispoofing ACL recommendations, the source address would not match what is expected to be seen, and it would be dropped. So what do you do when this hap- pens? The answer is symmetric tunneling.


Symmetric Tunneling

In general, when a client sends a packet for Server1, much like what is shown in Figure 12- 10, the following occurs:

The foreign controller tunnels the packet to the anchor controller rather than forwarding it. Then the anchor controller forwards the packet to Server1. Server1 replies, sending the traffic back to the anchor controller. The anchor controller tunnels it back to the foreign


controller. The foreign controller delivers the packet back to the client. If the client roams to another foreign controller, the database is moved to the new foreign controller, but the anchor controller does not change.

Understanding Roaming

It’s probably safe to say that most people understand the concept of roaming at a high level. You want to move from your desk to the conference room. The conference room is on the other side of the building, but you are in the middle of a large upload. You don’t sweat it because you are on a wireless network and wireless is...“everywhere”!

That sounds nice, and that’s what wireless networks have to offer, but how does wireless get “everywhere”? From what you have learned so far, you know that a wireless signal can’t travel “everywhere” because of absorption, refraction, scattering, and more. You’ve also learned a little about roaming and how an AP needs some overlap to facilitate the process. But there is still more to it. If you step back and look at the big picture, you start to see that the controller has to be involved in this lightweight AP deployment. How is the controller involved? To understand that, you need to understand mobility groups.


Understanding Mobility Groups

In simple terms, a mobility group is a setting on a controller that defines the controller as a member of a group. Other controllers would also be members of that group. These controllers share information about the clients that are roaming. In Figure 12-1, two controllers are in the same mobility group. They can exchange information about the client that is roaming. Figure 12-2 shows a network with three controllers. Controller1 and Controller2 are in the same mobility group, and Controller3 is in a different one. When this scenario occurs, the three controllers are considered to be in the same mobility domain. A controller can be aware of another controller in a different mobility group as long as they are in the same mobility domain. This allows them to exchange information regarding their clients. This allows clients in different mobility groups to roam between the different mobility domains. If the controllers were in different mobility groups and did not have knowledge of each other, roaming could not occur. To provide this knowledge, you as an administrator need to enter the MAC address and management IP address of the other controller in the first controller, and vice versa. In other words, Controller2 needs to be configured with Controller3’s MAC and management IP addresses, and Controller3 needs to be configured with Controller2’s MAC and IP addresses.

To set this up in the controller, first you need to configure the controller’s mobility domain. Remember that multiple controllers share the same mobility group, and controllers in different mobility groups can communicate with each other if they are part of the same mobility domain. To configure the mobility domain using the controller web interface, choose CONTROLLER > General.

A controller can be in only one mobility group and one mobility domain. To configure the mobility group, choose CONTROLLER > Mobility Management. Controllers that are in the same mobility group have the same virtual gateway IP address. You can add these controllers by clicking New and then adding the IP address, MAC address, and mobility group of the other controller, as shown in Figure 12-3. In Figure 12-3, Controller2 is added to Controller1. If you have more than one controller to add, you can do it all at once.

How an LWAPP AP Discovers a Controller

When an AP discovers and joins a controller, the AP proceeds through several states. In Figure 11-2, you can see these states and when they happen.


The process begins with the discovery of a controller. Because the lightweight APs are by definition “zero-touch” when deployed, you should only need to plug them in and let them do the rest. On the back end, the part you do not see is a little more complex. The steps in this process, beginning with discovery, are as follows:

Step 1. The APs send LWAPP discovery request messages to WLCs. This is broadcast at Layer 2. Because Layer 3 mode is what you want to use, this should fail.

Step 2. Upon failing, the AP proceeds to Layer 3 by checking its configuration for an IP address. If no IP address exists, the client uses DHCP to obtain one.

Step 3. The AP uses information obtained in the DHCP response to contact a con- troller.

Step 4. Any WLC receiving the LWAPP discovery request message responds with an LWAPP discovery response message. If no controller responds, the AP reverts to Layer 2 broadcasts and starts the process again.

The Cisco implementation uses the hunting process and discovery algorithm to find as many controllers as possible. The AP builds a list of WLCs using the search and discovery process, and then it selects a controller to join from the list. The controller search process repeats continuously until at least one WLC is found and joined. IOS-based APs only do a Layer 3 discovery.

The Layer 3 discovery process follows a certain order:

Step 1. The AP does a subnet broadcast to see if a controller is operating in Layer 3 mode on the local subnet.

Step 2. The AP does an over-the-air provisioning (OTAP).

Step 3. When other APs exist and are in a joined state with a controller, they send messages that are used for resource management. These messages have the IP address of the controller in it. The AP can listen to these messages and get the controller IP address. The AP can then send a directed discovery message to the controller.

Step 4. The next process is called AP priming.


How an LWAPP AP Chooses a Controller and Joins It

Now that the AP potentially has numerous controllers to join, it must choose one and send it a join request message. Figure 11-3 illustrates this portion of communication.

A join request message contains the following information:

• Type of controller

• MAC of controller

• AP hardware version

• AP software version

• AP name

• Number and type of radios

• Certificate payload (x.509)

• Session payload to set up the session values

• Test payload to see if jumbo frames can be used

How an LWAPP AP Receives Its Configuration

After joining, the AP moves to an image data phase, as shown in Figure 11-6, but only if the image on the AP is not the same as the image on the controller. If they are the same, this step is skipped and the image is used.


The controller upgrades or downgrades the AP at this point, and then it resets the AP. Af- ter a reset, the process begins again. The code is downloaded in LWAPP messages.

After the process of discovery and join happen and the image is the same on the controller and the AP, the AP gets its configuration from the controller. This happens during the con- fig data stage, as illustrated in Figure 11-7.


The AP then prompts the controller for a config by sending an LWAPP configure request message that contains parameters that can be configured as well as any values that are currently set; however, most of these values are empty.

When the controller gets the request, it sends a configure response message, which has the configuration values.

The AP then applies the configuration values in RAM. It is important to understand that these values are not stored in flash. If the AP reboots, the process begins again.

After applying the configuration, the AP is up and running.

Wireless Network Management

In very large networks, a single wireless controller isn’t enough to manage all your APs. This type of scenario might call for the Cisco Wireless Control System (WCS). The WCS is a single point of management for up to 3000 lightweight APs and 1250 autonomous APs. The WCS runs on a Windows or Red Hat Linux server. To scale beyond 3000 APs, you would need the WCS Navigator. The WCS Navigator enables you to navigate between different wireless control systems. It is a manager of managers, so to speak. You can use the WCS Navigator to navigate between different WCS servers. You can then scale it up to 30,000 APs in a single deployment and support up to 20 WCS deployments, all within the WCS Navigator. There is also an additional appliance you can use, called the Cisco Wireless Location Appliance, as shown in Figure 10-13.


This is designed to do location tracking for Wi-Fi devices and RFID tags. It helps track thousands of devices.


Controller Discovery and Association

When a lightweight AP boots up, it cannot function without a controller. In this chapter, you will learn about the Lightweight Access Point Protocol (LWAPP) and the modes in which it can operate. You will also learn about how an AP finds controllers on the net- work, chooses one to join with, and then retrieves its configuration. In addition, you will look at the ways to provide redundancy for your AP in the event that a controller goes down. Finally, when an AP is joined with a controller, it can operate in certain modes that can be used for different reasons. You will learn these operational modes and when they are used.


Understanding the Different LWAPP Modes

LWAPP can operate in either Layer 2 LWAPP mode or Layer 3 LWAPP mode. The Layer 2 mode is considered out of date, and Cisco prefers and recommends Layer 3 mode. Layer 3 mode is the default LWAPP mode on most Cisco devices.

At a high level, and after the AP has an IP address, the phases of LWAPP operation include these:

Step 1. An AP sends an LWAPP discovery request message. This is a broadcast that is sent at Layer 2.

Step 2. Assuming that a controller is operating in Layer 2 LWAPP mode, the wireless LAN controller (WLC) receives the LWAPP discovery request and responds with an LWAPP discovery response message.

Step 3. The AP chooses a controller based on the response received and sends a join request.

Step 4. The WLC receiving the LWAPP join request responds to the AP join request with an LWAPP join response. This process is going to include a mutual au- thentication. An encryption key is created to secure the rest of the join process and any future LWAPP control messages.

Step 5. After the AP has joined the WLC, LWAPP messages are exchanged, and the AP initiates a firmware download from the WLC (if the AP and WLC have a version mismatch). If the onboard firmware of the AP is not the same as that of the WLC, the AP downloads firmware to stay in sync with the WLC. The firmware download mechanism utilizes LWAPP.

Step 6. After the WLC and AP match firmware revisions, the WLC provisions the AP with the appropriate settings. These settings might include service set identi- fiers (SSID), security parameters, 802.11 parameters such as data rates and sup- ported PHY types, radio channels, and power levels.

Step 7. After the provisioning phase is completed, the AP and WLC enter the LWAPP runtime state and begin servicing data traffic.

Step 8. During runtime operations, the WLC might issue various commands to the AP through LWAPP control messages. These commands might be provisioning commands or requests for statistical information that the AP collects and maintains.

Step 9. During runtime operations, LWAPP keepalive messages are exchanged be- tween the AP and WLC to preserve the LWAPP communication channel. When an AP misses a sufficient number of keepalive message exchanges, it at- tempts to discover a new WLC.

Wireless LAN Controllers

The entire design of the Wireless LAN Controllers is for scalability. The communication between a lightweight AP can happen over any type of Layer 2 or Layer 3 infrastructure using LWAPP. There are integrated controller platforms designed for installation in switches. The 3750-G actually comes as an integrated 2RU switch with either a 25 or 50 AP controller, as well as the WiSM and the WLCM. These are both modular controllers that can be installed in 6500 series switches or in Integrated Services Routers (ISR). There are also appliance-based controllers, which include the 44xx series WLC as well as the 2100 series WLC. Which controller you require depends on how many APs you need de- ployed. This can be anywhere from six to 300 access points per controller. This is a fixed value and can’t be upgraded via licensing. If you need to support more APs, you need an- other controller or a controller that supports more APs.


The Cisco 44xx Series WLC

The Cisco 44xx series Wireless LAN Controller, shown in Figure 10-8, is a standalone appliance.


It is designed to take up one rack unit. It has either two or four Gigabit Ethernet uplinks, and they use mini-GBIC FSG slots. It can support 12, 25, 50, or 100 APs, depending on the model. And it can support up to 5000 MAC addresses in its database.

The 4400 series has a 10/100 interface called a service port; it is used for SSH and SSL connections for management purposes. The service port can be used for out-of-band management, but it is not required to manage the device. You can manage the device via the controller’s logical management interface. There is also a console port that you can use to connect via HyperTerminal or Teraterm Pro.

Depending on the country you are in, power requirements vary, but the chassis has two power supply slots.

The controller code version used for the CCNA Wireless exam is version 5.x, and the AP runs the same version. It’s actually a requirement that they run the same version, so when an AP joins with a controller, the controller upgrades or downgrades the AP. The con- troller upgrades four APs at a time. The 4400 series can support up to 100 access points. So, a 4400 would upgrade ten APs at a time until they are all upgraded.


The Cisco WiSM

The Cisco WiSM, shown in Figure 10-10, is a services module that installs in the 6500 se- ries switch or 7600 series router with the Cisco Supervisor Engine 720.


It has the same functionality as the 4400 series standalone controllers; the difference is that it supports up to 300 APs. The WiSM supports 150 access points per controller, with each blade having two controllers. Thus, you can have a total of 300 access points. You can also cluster 12 of them into a mobility domain. This allows up to 7200 lightweight APs in a mobility domain.


The Cisco 2106 WLC

The Cisco 2106 Wireless LAN Controller, shown in Figure 10-11, is also a single-rack unit design with eight 10/100 Ethernet ports.


It can support up to six primary access points. It has an RJ-45 console port and two RJ-45 ports that support PoE. It has nearly all the same features as the 4400 series controllers but has eight built-in switch ports. You can expect to see this controller in a small branch environment.


The Cisco WLCM

The Wireless LAN Controller Module (WLCM), shown in Figure 10-12, is designed for the ISR routers. You would see this controller in a small office.


It has the same functionality as the 2106, but it does not have the directly connected AP and console port. It supports six APs. The WLCM-Enhanced (WLCM-E) supports eight or 12 APs, depending on which module you get.

Of course, some limitations apply. Most of the features are similar to the 4000 series:

• LWAPP

• RF control

• The ability to be a DHCP server

• Layer 2 security

The differences are things such as the following:

• Lack of PoE ports

• The number of APs supported

• The LWAPP modes supported

Wireless LAN Controller Summary

Table 10-3 summarizes the Cisco Wireless LAN Controller models.