Wireless Network Logical Architecture

The logical architecture of a network refers to the structure of standards and protocols that enable connections to be established between physical devices, or nodes, and which control the routing and flow of data between these nodes.

Since logical connections operate over physical links, the logical and physical architectures rely on each other, but the two also have a high degree of independence, as the physical configuration of a network can be changed without changing its logical architecture, and the same physical network can in many cases support different sets of standards and protocols.

The logical architecture of wireless networks will be described in this chapter with reference to the OSI model.


The OSI Network Model

The Open Systems Interconnect (OSI) model was developed by the International Standards Organisation (ISO) to provide a guideline for the development of standards for interconnecting computing devices. The OSI model is a framework for developing these standards rather than a standard itself — the task of networking is too complex to be handled by a single standard.

The OSI model breaks down device to device connection, or more correctly application to application connection, into seven so-called “layers” of logically related tasks (see Table 2-1). An example will show


how these layers combine to achieve a task such as sending and receiving an e-mail between two computers on separate local area networks (LANs) that are connected via the Internet.

The process starts with the sender typing a message into a PC e-mail application (Figure 2-1). When the user selects “Send”, the operating system combines the message with a set of Application layer (Layer 7) instructions that will eventually be read and actioned by the corresponding operating system and application on the receiving computer.

The message plus Layer 7 instructions is then passed to the part of sender’s operating system that deals with Layer 6 presentation tasks. These include the translation of data between application layer formats as well as some types of security such as Secure Socket Layer (SSL) encryption. This process continues down through the successive software layers, with the message gathering additional instructions or control elements at each level.

By Layer 3 — the Network layer — the message will be broken down into a sequence of data packets, each carrying a source and destination



Wireless Network Physical Architecture


Wired Network Topologies — A Refresher

The topology of a wired network refers to the physical configuration of links between networked devices or nodes, where each node may be a computer, an end-user device such as a printer or scanner, or some other piece of network hardware such as a hub, switch or router.

The building block from which different topologies are constructed is the simple point-to-point wired link between two nodes, shown in Figure 3-1. Repeating this element results in the two simplest topologies for wired networks — bus and ring.

For the ring topology, there are two possible variants depending on whether the inter-node links are simplex (one-way) or duplex (two-way). In the simplex case, each inter-node link has a transmitter at one end and a receiver at the other, and messages circulate in one direction around the ring, while in the duplex case each link has both transmitter and receiver (a so-called transceiver) at each end, and messages can circulate in either
direction.

Bus and ring topologies are susceptible to single-point failures, where a single broken link can isolate sections of a bus network or halt all traffic in the case of a ring.

The step that opens up new possibilities is the introduction of specialised network hardware nodes designed to control the flow of data between

other networked devices. The simplest of these is the passive hub, which is the central connection point for LAN cabling in star and tree topologies, as shown in Figure 3-2. An active hub, also known as a repeater, is a variety of passive hub that also amplifies the data signal to improve signal strength over long network connections.

For some PAN technologies, such as USB, star and tree topologies can be built without the need for specialised hardware,


because of the daisy-chaining capability of individual devices (see Figure 2-11).

An active or passive hub in a star topology LAN transmits every received data packet to every connected device. Each device checks every packet and decodes those identified by the device’s MAC address. The disadvantage of this arrangement is that the bandwidth of the network is shared among all devices, as shown in Figure 3-3. For example, if two PCs are connected through a 10 Mbps passive hub, each will have on average 5 Mbps of bandwidth available to it.

If the first PC is transmitting data, the hub relays the data packets on to all other devices in the network. Any other device on the network will have to wait its turn to transmit data.

A switching hub (or simply a switch) overcomes this bandwidth sharing limitation by only transmitting a data packet to the device to which it is addressed. Compared to a non-switching hub, this requires increased memory and processing capability, but results in a significant improvement in network capacity.

The first PC (Figure 3-4) is transmitting data stream A to the printer and the switch directs these data packets only to the addressed device. At the same time, the scanner is sending data stream B to the second PC.


The switch is able to process both data stream concurrently, so that the full network bandwidth is available to every device.

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.

Access Points

As previously mentioned, there are two types of access points:

• Autonomous APs

• Lightweight APs

Some APs are built into modules and deployed in ISR routers at branch sites; other APs are deployed as just standalone devices. Cisco APs are known to offer the best range and throughput in the industry, as well as a number of security features that you do not find with other vendors.

Cisco APs offer multiple configuration options. Some of them support external antennas, some support internal antennas, and some are to be deployed outdoors. Still others are de- signed to be deployed indoors. Some APs are designed to be implemented for wide-area networking and bridging purposes and, while operating as a bridge, may also allow client connections. The point is that Cisco APs can serve a number of purposes.

The benefit of the CUWN APs is that they are zero-touch management, assuming that Layer 2 connectivity is already in place. As soon as they are plugged in and powered on, you don’t have to do anything else at the AP level. The models that you need to be familiar with for the CCNA Wireless exam include the 1130AG, 1240AG, 1250AG, 1300, and 1400 series wireless bridges.

The 1130, 1240, and 1250 can be both autonomous and lightweight APs. Whereas the 1300 and 1400 series are designed to operate as bridges, the 1300 series can also sup- port wireless clients. In turn, the 1400 series supports bridging only. Another model is the outdoor mesh 1500 series, which supports only LWAPP, so that would be designed for a lightweight scenario only.

Cisco is known for being ahead of the curve. That’s where the special functionality of the 1250AG comes in. The 1250AG is one of the first access points to support the 802.11n draft version 2.0 standard and is the basis for all 802.11 Wi-Fi interoperability testing. For a client vendor to get the v2.0 stamp of approval, it must be validated against the 1250, and the 1250 is the only AP used during this validation.

The 1130AG

The 1130AG, shown in Figure 10-3, is a dual-band 802.11 a/b or g AP that has integrated antennas.

The 1130AG can operate as a standalone device or in lightweight AP mode. It also can op- erate as a Hybrid Remote Edge AP (H-REAP) device. An H-REAP device operates on the far side of a WAN, and its controller is back at the core site.

The 1130AG is 802.11i/WPA2-compliant, and it has 32 MB of RAM and 16 MB of flash memory. The 1130 AP typically is deployed in office or hospital environments. Naturally, the internal antennas do not offer the same coverage and distance as APs that are designed for external antennas. Consider the 1130s. They have 3 dB gain and 4.5 dB gain for the 2.4- and 5-GHz frequencies, respectively. If you were to compare the 1131 to the 1242 with the 2.2 dipole antennas, you would see a larger coverage area than with the 1242.


The 1240AG


The 1240AG series AP, shown in Figure 10-4, is also a dual-band 802.11 a/b or g device, similar to the 1130AG; however, it supports only external antennas.

Those external antennas would connect using the RP-TNC connectors. The 1240AG can operate as an autonomous AP and in lightweight AP mode. Like the 1130AG, it also can operate in H-REAP mode. It too is 802.11i/WPA2-compliant.


The 1250 Series AP

Shown in Figure 10-5, the 1250 series AP is one of the first enterprise APs to support the 802.11n draft version 2.0.

Because it supports the 802.11n draft standard, you can get data rates of about 300 Mbps on each radio and the 2-by-3 multiple input and multiple output technology. The 2-by-3 is discussed in Chapter 6, “Overview of the 802.11 WLAN Protocols.” Also, because the 1250 is modular, it can easily be upgraded in the field. It operates in controller-based and standalone mode and is also 802.11i/WPA2-compliant.

The 1250 is designed for a more rugged type of indoor environment. You might see this at more hazardous locations such as packaging plants, or in situations where you might need


to place an antenna in a hazardous location and the AP elsewhere. You might see this type of AP in factories and hospitals. It has 64 MB of DRAM and 32 MB of flash memory. It has 2.4-GHz and 5-GHz radios.