LAG is a partial implementation of the 802.3ad port aggregation standard. It bundles all the ports of the controller into a single 802.3ad port channel. The controller manages redundancy and load balancing of all the APs across the ports. See Figure 7-4 for an example of LAG implemented in a network. LAG does make managing your WLC a little easier. It reduces the number of IP addresses needed, and APs have a faster convergence time than if all four ports were up and connected. In addition, you do not need to configure primary and secondary ports for each interface. If a link fails, service is not interrupted. In the case of having all four ports up individually, an interruption of service would occur for APs using the failed link. The APs in this case would have to register again with the WLC. In the case of LAG, this would not occur.
Figure 7-4 A Typical LAG Setup
LAG was introduced in the WLC in Version 3.2. LAG is the only method of communication with the WiSM and the Foxhound 3750G. These are the 6500 and 3750 integrated WLC switches. If you are using a non-LAG setup, each port on the controller ideally supports up to 48 APs. You can configure LAG on a WLC and only enable one port but have 100 APs joined to the WLC. Although this is not preferred, it is possible. With LAG enabled, the WLC supports up to 50 APs on its logical port. A 4402 supports 50 APs, whereas the 4404 supports 100 APs on its logical port. A WiSM has two WLCs per blade. The WiSM supports 150 APs on the logical port for a total of 300 on the blade.
Note You can bundle all four ports on a 4404 controller (or two on a 4402 controller) into a single link.
When configuring bundled ports on the controller, you might want to consider terminating on two switch modules within a modular switch such as the Catalyst 6500; however, Cisco does not recommend connecting the LAG ports of a 4400 controller to multiple Catalyst 6500 or 3750G switches.
Terminating on two different modules within a single Catalyst 6500 switch provides redundancy and ensures that connectivity between the switch and the controller is maintained when one module fails. A 4402-50 controller is connected to two Gigabit modules (slots 2 and 3) within the Catalyst 6500. Port 1 of the controller is connected to Gigabit interface 3/1, and port 2 of the controller is connected to Gigabit interface 2/1 on the Catalyst 6500. Both switch ports are assigned to the same channel group.
When installing your WLC, if you plan to use load balancing, one of the key items to remember is that the controllers do their own form of load balancing, internally, for their APs. Other than that, they have no other form of port load balancing like your typical switches do. In addition, they do not use a mechanism for channel negotiation between the controller and the switch, such as Link Aggregation Control Protocol (LACP) or Cisco proprietary Port Aggregation Protocol (PAgP). Therefore, when you are configuring your EtherChannel on your switch, the mode is simply ON; it is nothing else. Configuring an option other than ON results in odd behavior. The WLC does not support LACP or Cisco PAgP. The load-balancing method configured on the Catalyst switch must be one that terminates all IP datagram fragments on a single controller port. Not following this recommendation can result in problems with AP registration and association. It is recommended that you specify src-dest-ip by using the following command:
If you are using a third-party switch and you are unable to configure the recommended load-balancing method, try disabling LAG. The only good way to still run LAG is to only enable one port so each packet has only one path for the source and destination.
Refer to the following LAG guidelines when installing your WLC. The LAG guidelines are as follows:
■ You cannot configure the ports of the controller into separate LAG groups. Only one LAG group is supported per controller. Therefore, you can connect a controller in LAG mode to only one neighbor device.
Note The two internal Gigabit ports on the controller within the Catalyst 3750G integrated WLC switch are always assigned to the same LAG group.
■ When you enable LAG or change the LAG configuration, you must immediately reboot the controller.
■ When you enable LAG, you can configure only one AP-Manager interface because only one logical port is needed. LAG removes the requirement for supporting multiple AP-Manager interfaces.
■ When you enable LAG, all dynamic AP-Manager interfaces and untagged interfaces are deleted, and all WLANs are disabled and mapped to the management interface. Also, the management, static AP-Manager, and VLAN-tagged dynamic interfaces are moved to the LAG port.
■ Multiple untagged interfaces to the same port are not allowed.
■ When you enable LAG, you cannot create interfaces with a primary port other than 29.
■ When you enable LAG, all ports participate in LAG by default. Therefore, you must configure LAG for all the connected ports in the neighbor switch.
■ When you enable LAG, port mirroring is not supported.
■ When you enable LAG, if any single link goes down, traffic migrates to the other links.
■ When you enable LAG, only one functional physical port is needed for the controller to pass client traffic.
■ When you enable LAG, APs remain connected to the switch, and data service for users continues uninterrupted.
■ When you enable LAG, you eliminate the need to configure primary and secondary ports for each interface.
■ When you enable LAG, the controller sends packets out on the same port on which it received them. If a Control and Provisioning of Wireless Access Points (CAPWAP) packet from an AP enters the controller on physical port 1, the controller removes the CAPWAP wrapper, processes the packet, and forwards it to the network on physical port 1. This might not be the case if you disable LAG.
■ When you disable LAG, the management, static AP-Manager, and dynamic interfaces are moved to port 1.
■ When you disable LAG, you must configure primary and secondary ports for all interfaces.
■ When you disable LAG, you must assign an AP-Manager interface to each port on the controller if you have multiple ports connected.
Note Depending on the platform, LAG is enabled or disabled by default and is the only option on the WiSM controller and the controller in the Catalyst 3750G-integrated WLC switch.
In summary, LAG can simplify life and is usually the preferred method of connecting for a few reasons. On the WiSM and the Catalyst 3750G, LAG is enabled by default and is the only option, similar to Layer 3 Lightweight Access Point Protocol (LWAPP) transport mode. LAG only operates in Layer 3 LWAPP transport mode. One of the benefits is that only one interface, AP-Manager, is needed to manage the ports. The purpose of having multiple links is additional bandwidth for connecting additional APs. If LAG was not used, you would have to create an AP-Manager for each interface you brought online. For instance, if your WLC had three out of the four gigabit links active, you would have three AP-Manager interfaces, one for each port.
Layer 2 and Layer 3 LWAPP Transport Modes of Operation
LWAPP communication between the AP and the WLC can be in native, Layer 2 Ethernet frames. This is known as Layer 2 LWAPP mode. Although defined in the RFC draft, Layer 2 LWAPP mode is considered deprecated in Cisco implementation. Layer 2 LWAPP mode is described in this section for completeness, but the rest of this deployment guide assumes the controller is operating in Layer 3 LWAPP mode.
As you can see from Figure 7-5, the LWAPP control and data messages are encapsulated in Ethernet frames using Ethertype 0xBBBB. In Layer 2 LWAPP mode, although the APs might get an IP address via Dynamic Host Configuration Protocol (DHCP), all LWAPP communications between the AP and WLC are in Ethernet encapsulated frames, not IP packets. The APs must be on the same Ethernet network as the WLC. For this reason, Layer 2 LWAPP mode might not be suitable for scalability purposes in most deployments.
Figure 7-5 LWAPP Layer 2 Mode
Furthermore, Layer 2 mode is supported only by the Cisco 410x and 440x series of WLCs and the Cisco 1000 series APs. Layer 2 LWAPP is not supported by lightweight Cisco Aironet 1200, 1252, 1130AG, or 1240AG APs, or the Cisco 2006, WiSM, or Wireless LAN Controller Module (WLCM) series WLCs.
Consider the scenario in Figure 7-5, where Host A is a wireless LAN (WLAN) client communicating with the wired device, Host B. The LWAPP control Messages, including the LWAPP header with the C-Bit set to 1, and the control message elements are Ethernet encapsulated in a frame that traverses the local network. The MAC addresses in the Ethernet MAC header are the AP Ethernet MAC address and the WLC MAC address.
The source and destination MAC addresses depend on the direction of the frame. An LWAPP control frame sent from the AP to the WLC uses the AP Ethernet MAC address as the source address and the WLC MAC address as the destination address. An LWAPP control frame sent from the WLC to the AP uses the WLC MAC address as the source address and the AP MAC address as the destination address.
Data packets between WLAN clients and other hosts are typically IP packets.
When Host A sends a packet to Host B, the following sequence occurs:
Step 1. An IP packet is transmitted by Host A over the 802.11 radio frequency (RF) interface after being encapsulated in an 802.11 frame with the MAC address of Host A as the source address and the radio interface MAC address of the AP as the destination address.
Step 2. At the AP, the AP adds an LWAPP header to the frame with the C-Bit set to 0 and then encapsulates the LWAPP header and 802.11 frame into an Ethernet frame. This Ethernet frame uses the AP Ethernet MAC address as the source MAC address and the WLC MAC address as the destination MAC address.
Step 3. At the WLC, the Ethernet and LWAPP headers are removed and the original 802.11 frame is processed.
Step 4. After processing the 802.11 MAC header, the WLC extracts the payload (the IP packet), encapsulates it into an Ethernet frame, and then forwards the frame onto the appropriate wired network, typically adding an 802.1Q VLAN tag.
Step 5. The packet then travels through the wired switching and routing infrastructure to Host B.
When Host B sends an IP packet to Host A, the following sequence occurs:
Step 1. The packet is carried from Host B over the wired switching and routing network to the WLC, where an Ethernet frame arrives with the MAC address of Host A as the destination MAC address. The IP packet from Host B is encapsulated inside this Ethernet frame.
Step 2. The WLC takes the entire Ethernet frame, adds the LWAPP header with the C-Bit set to 0, and then encapsulates the combined frame inside an LWAPP Ethernet frame. This LWAPP Ethernet frame uses the WLC MAC address as the source MAC address and the AP Ethernet MAC address as the destination MAC address. This frame is sent over the switched network to the AP.
Step 3. At the AP, the Ethernet and LWAPP headers are removed and processed.
Step 4. The payload (the IP packet) is then encapsulated in an 802.11 MAC frame and transmitted over the air by the AP to Host A.
You will read about the LWAPP discovery and join process in more detail later, but for now understand that a mechanism is included to determine if the path between the AP and WLC supports jumbo frames. If jumbo frames are not supported, a maximum transmission unit (MTU) of 1500 bytes is assumed. Both the AP and WLC handle fragmentation and reassembly of LWAPP-encapsulated packets. The architecture currently supports reassembly of a maximum of two LWAPP fragments, but it is highly unlikely that there will ever be more than two fragments with Layer 2 LWAPP.
LWAPP control messages are encrypted using the industry standard AES-CCM encryption method. The shared encryption key is derived and exchanged when the AP joins the WLC. The payloads of encapsulated LWAPP data messages are not specially encrypted. A trusted Ethernet-wired network is assumed and standard best practices for protecting Ethernet networks should be followed. Standards-based wireless Layer 2 encryption is handled at the AP.
Because the WLC is the point of ingress/egress for WLAN traffic on that IP network, the IP address of WLAN clients such as Host A comes from the pool of addresses on the network upstream of the WLC. This might not necessarily be the same network as the APs downstream from the WLC. For example, suppose that the packets bridged to and from the WLC are on the upstream side on network 192.168.1.0/24 and that the network between the WLC and AP is 192.168.2.0/24. The IP address of Host A is on the 192.168.1.0/24 network. The address of the WLAN client can be either statically assigned or dynamically assigned via DHCP.
LWAPP Layer 3 Transport Mode
Layer 3 LWAPP control and data messages are transported over the IP network in User Datagram Protocol (UDP) packets. This transport architecture is inherently more flexible and scalable than Layer 2 LWAPP and is the generally preferred solution. Layer 3 LWAPP is supported on all Cisco WLC platforms and lightweight APs (LAP). Figure 7-6 illustrates the topology for the discussion of Layer 3 LWAPP.
Figure 7-6 LWAPP Packet Breakdown
In this scenario, the LWAPP control and data messages are encapsulated in UDP packets that are carried over the IP network. The only requirement is established IP connectivity between the APs and the WLC. The LWAPP tunnel uses the IP address of the AP and the AP Manager interface IP address of the WLC as endpoints.. On the AP side, both LWAPP control and data messages use an ephemeral port that is derived from a hash of the AP MAC address as the UDP port. On the WLC side, LWAPP data messages always use UDP port 12222. On the WLC side, LWAPP control messages always use UDP port 12223.
The mechanics and sequencing of Layer 3 LWAPP are similar to Layer 2 LWAPP except that the packets are carried in UDP packets instead of being encapsulated in Ethernet frames. Figure 7-3 shows how LWAPP control messages, including the LWAPP header with the C-Bit set to 1, and the LWAPP control message elements are transported in UDP packets encapsulated in IP.
In Figure 7-6, Host A is a WLAN client communicating with the wired device, Host B. When Host A sends a data packet to Host B, the following sequence occurs:
Step 1. The packet is transmitted by Host A over the 802.11 RF interface. This packet is encapsulated in an 802.11 frame with the MAC address of Host A as the source address and the radio interface MAC address of the AP as the destination address.
Step 2. At the AP, the AP adds an LWAPP header to the frame with the C-Bit set to 0 and then encapsulates the LWAPP header and 802.11 frame into a UDP packet that is transmitted over IP. The source IP address is the IP address of the AP, and the destination IP address is the AP Manager address of the WLC. The source UDP port is the ephemeral port based on a hash of the AP MAC address. The destination UDP port is 12222.
Step 3. The IP packet is encapsulated in Ethernet as it leaves the AP and transported by the switching and routed network to the WLC.
Step 4. At the WLC, the Ethernet, IP, UDP, and LWAPP headers are removed from the original 802.11 frame.
Step 5. After processing the 802.11 MAC header, the WLC extracts the payload (the IP packet from Host A), encapsulates it into an Ethernet frame, and then forwards the frame onto the appropriate wired network, typically adding an 802.1Q VLAN tag.
Step 6. The packet is then transmitted by the wired switching and routing infrastructure to Host B.
When Host B sends an IP packet to Host A, the process is essentially reversed.
Step 1. The packet is delivered by the wired switching and routing network to the WLC, where an Ethernet frame arrives with the MAC address of Host A as the destination MAC address.
Step 2. The WLC removes the Ethernet header and extracts the payload (the IP packet destined for Host A).
Step 3. The original IP packet from Host A is encapsulated with an LWAPP header, with the C-Bit set to 0, and then transported in a UDP packet to the AP over the IP network. The packet uses the WLC AP Manager IP address as the source IP address and the AP IP address as the destination address. The source UDP port is 12222, and the destination UDP port is the ephemeral port derived from the AP MAC address hash.
Step 4. This packet is carried over the switching and routing network to the AP.
Step 5. The AP removes the Ethernet, IP, UDP and LWAPP headers and extracts the payload, which is then encapsulated in an 802.11 frame and delivered to Host A over the RF network.
Layer 3 LWAPP assumes a 1500-byte MTU. Both the AP and WLC handle fragmentation and reassembly of LWAPP-encapsulated packets based on the 1500-byte MTU assumption. The architecture currently supports reassembly of a maximum of two LWAPP fragments.
LWAPP control messages are encrypted using the industry standard AES-CCM encryption method. The shared encryption key is derived and exchanged when the AP joins the WLC. The payloads of encapsulated LWAPP data messages are not specially encrypted. A trusted wired network is assumed and standard best practices for protecting networks should be followed. Standards-based wireless Layer 2 encryption is handled at the AP.
Because the WLC is the point of ingress/egress for WLAN traffic on that IP network, the IP address of WLAN clients such as Host A comes from the pool of addresses on the network upstream of the WLC. This might not necessarily be the same network as the APs downstream from the WLC. For example, if the packets bridged to and from the WLC are on the upstream side on network 192.168.1.0/24, and the network between the WLC and AP is 192.168.2.0/24, the IP address of Host A will be on the 192.168.1.0/24 network. The address of the WLAN client can be either statically assigned or dynamically assigned through DHCP.
Some of the WLCs can operate in both Layer 2 and Layer 3 LWAPP transport mode. Layer 2 is old and is typically rarely used. (Please refer to Figure 7-5, which shows LWAPP Layer 2 mode.) Layer 2 support has been removed from newer versions of code because of its limitations. The WiSM, 3750 Foxhound, 2006, 2106, and Network Module Controller (NMC) are some of the WLCs that operate only in Layer 3 LWAPP transport mode. One of the major differences is that in Layer 2, the packets are encapsulated in Ethernet frames using Ethertype 0xBBBB, whereas in Layer 3 they are encapsulated in UDP packets. In the case of Layer 3, all the LWAPP control and data messages are transported over the IP network in UDP packets.
As far as configurations regarding LAG, you will have two setups for the controller and two for the switch.
Configure the port channel on the neighbor switch as follows:
The controller will be much easier as you only configure LAG on or off. Depending on the mode you choose, other configurations will be necessary.
Interfaces on the WLC
The WLC has multiple interfaces. This will be different from the newer-generation WLCs where only one IP address exists for the entire box. Before discussing this further, it is important to explore how the controller communicates using a handful of different interfaces. This can help you to understand how the controller communicates to the APs and general traffic flow.
Refer to Figure 7-7 to get an understanding of the relationships between the interfaces, WLANs, and ports. This can assist you in understanding overall flow.
As the current WLC design now stands, 440x and WiSM, you usually have a minimum of three interfaces and in most cases many more:
■ Management interface
■ AP-Manager interface
■ Dynamic interfaces
■ Virtual interface
■ Service port
Figure 7-7 Relationship Between WLANs, Interfaces, and Physical Ports
The management interface represents the entire unit on the network. This is the only interface on the controller that reliably responds to pings when the controller is up and operational. It is the interface that the network admin uses to manage the box via Telnet, Secure Shell (SSH), web-HTTP, HTTPS, and so on. For CAPWAP, starting with code revision 5.2.x and later, the controller requires one management interface to control all controller communications and one AP-Manager interface to control all controller-to-AP communications, regardless of the number of ports.
Note If the service port is in use, the management interface must be on a different super-net from the service-port interface.
The AP-Manager interface handles all controller-to-AP communications. If the controller is not using LAG, it has an AP-Manager for each physical port that is enabled. The reason for additional ports is for additional AP support. Because the port is going to handling AP communications, it needs an AP-Manager to handle the traffic flow. Each AP-Manager has a unique address. Cisco recommends that the AP-Manager and management interface reside on the same subnet. The interfaces are not required to be on the same subnet, but that is highly recommended. If they are in different subnets, you must make sure that the APs have IP connectivity to both the management and AP-Manager interfaces and allow CAPWAP/LWAPP to transverse these links.
Note If LAG is enabled, only one AP-Manager interface can exist. But when LAG is disabled, you must assign an AP-Manager interface to each port on the controller. If only one distribution system port can be used, you should use distribution system port 1.
Port redundancy for the AP-Manager interface is not supported. You cannot map the AP-Manager interface to a backup port.
Refer to the "Multiple AP-Manager Support" section earlier in this topic for information on creating and using multiple AP-Manager interfaces.
The AP-Manager interface communicates through any distribution system port by listening across the Layer 3 network for AP CAPWAP or LWAPP join messages to associate and communicate with as many LAPs as possible.
Dynamic interfaces, also known as VLAN interfaces, are created by users and designed to be analogous to VLANs for WLAN clients. A controller can support up to 512 dynamic interfaces (VLANs). Each dynamic interface is individually configured and allows separate communication streams to exist on any or all of the distribution system ports of a controller. Each dynamic interface controls VLAN and other communications between controllers and all other network devices, and each acts as a DHCP relay for wireless clients associated to WLANs mapped to the interface. You can assign dynamic interfaces to distribution system ports, WLANs, the Layer 2 management interface, and the Layer 3 AP-Manager interface, and you can map the dynamic interface to a backup port. You can configure zero, one, or multiple dynamic interfaces on a distribution system port. However, all dynamic interfaces must be on a different VLAN and IP subnet from all other interfaces configured on the port. If the port is untagged, all dynamic interfaces must be on a different IP subnet from any other interface configured on the port.
Note Configuring a dynamic interface with a secondary subnet is not supported.
Cisco recommends using tagged VLANs for dynamic interfaces.
This configuration enables you to manage the controller directly or through a dedicated operating system network, such as 10.1.2.x, which can ensure service access during network downtime. The service port can obtain an IP address using DHCP, or it can be assigned a static IP address, but a default gateway cannot be assigned to the service-port interface. Static routes can be defined through the controller for remote network access to the service port.
Note Only Cisco 4400 series controllers have a service-port interface.
You must configure an IP address on the service-port interface of both Cisco WiSM controllers; otherwise, the neighbor switch cannot check the status of each controller.
The virtual interface actually has a variety of tasks. The important fact to remember about this interface is that it is used only in communications within the controller and encapsulated in LWAPP/CAPWAP tunnel for client traffic in certain scenarios. It never appears as the source or destination address of a packet that goes out a distribution system port and onto a switched network. For the WLC and mobility functions to operate correctly, the virtual interface IP address must be set to a unique value, and no other device in the network realm can have the same IP address. The virtual IP address for the interface cannot exist, nor should it ever, in a routing table in the network. The only stipulation is that it cannot be the value of 0.0.0.0. This interface is not designed to respond to pings. In addition, the virtual interface must be configured with an unassigned and unused gateway IP address, which is why many network administrators use 1.1.1.1.
The virtual interface is never mapped to a backup port. The main roles of the virtual interface are to act as a DHCP server placeholder for the wireless clients that obtain their IP address from a DHCP server and to serve as the redirect address for the web authentication login page. The virtual interface is used for few tasks, such as to support mobility management, DHCP relay, and embedded Layer 3 security such as guest web authentication, and to maintains the Domain Name System (DNS) gateway host name used by Layer 3 security and mobility managers to verify the source of certificates when Layer 3 web authorization is used. All WLCs within the same mobility group should have the same virtual address for WLC communication to occur.
