|
|
Table Of Contents
Cisco Catalyst 6500 Series Wireless LAN Services Module: Detailed Design and Implementation Guide
AP-based WDS and Switch-based WDS
New Concept—VLAN on the Access Point
Scalability of the WLSM Solution
AP-based WDS and Switch-based WDS—Can They Coexist?
RADIUS-based Dynamic Mobility Group Assignment
IP Addressing Scheme Recommendations
GRE and Issues with Fragmentation
Design Limitations and Caveats
Implementing Quality of Service
Applying Catalyst 6500 Features to Wireless Traffic
Catalyst 6500 Service Module Integration
Cisco Catalyst 6500 Series Wireless LAN Services Module: Detailed Design and Implementation Guide
Introduction
This is the first of a series of documents on the design and implementation of a wireless network with the Cisco Catalyst 6500 Series Wireless LAN Services Module (WLSM).
Audience
This document is intended primarily for system engineers who are responsible for designing and implementing wireless network solutions with the Cisco Catalyst 6500 Series WLSM. The audience should be familiar with terms such as the Cisco Structured Wireless-Aware Network (SWAN), Wireless Domain Services (WDS), Fast Secure Roaming (FSR), and with terminology associated with the Cisco Catalyst 6500.
Document Objectives
This document provides design and deployment recommendations for the implementation of a campus wireless solution with the WLSM. All the recommendations given in this document are based on proof of concept tests.
The document includes the following sections:
•
Overview
Overview
Cisco SWAN provides the framework to integrate and extend wired and wireless networks to deliver the lowest possible total cost of ownership for companies deploying WLANs. Cisco SWAN extends "wireless awareness" into important elements of the network infrastructure, providing the same level of security, scalability, reliability, ease of deployment, and management for wireless LANs that organizations have come to expect from their wired LANs. The Cisco SWAN framework includes the following components:
•
•
•
•
•
This section includes the following topics:
•
Cisco SWAN WDS
Cisco SWAN uses WDS to deliver wired and wireless integration. WDS is a collection of Cisco IOS Software features that enhance WLAN client mobility and simplify WLAN deployment and management. A WDS device can be a Cisco AP, switch, or router. Cisco SWAN delivers different functionality depending upon where WDS is located.
When AP-based WDS is used, Cisco SWAN supports Layer 2 FSR, scalable WLAN management, advanced radio management (RM) capabilities, and enhanced wireless security. When switch-based WDS is used, Cisco SWAN supports Layer 2/Layer 3 FSR, advanced RM capabilities, end-to-end security, and end-to-end quality of service (QoS) in campus WLAN deployments. This document addresses Cisco Catalyst switch-based WDS on a Cisco Catalyst 6500 Series WLSM.
AP-based WDS and Switch-based WDS
Using switch-based WDS and the Cisco Catalyst 6500 WLSM blade provides enhanced capabilities for the design and deployment of the Cisco WLAN architecture. Reviewing the features of a Cisco SWAN AP-based WDS deployments helps to better understand these changes.
Cisco SWAN AP-based WDS provides a Layer 2 mobility solution with the following considerations from a network design perspective:
•
•
•
As shown in Figure 1, the implementation of AP-based WDS FSR requires a WDS AP per subnet, which requires configuration, management, and monitoring one WDS per roaming domain, with the AP-based WDS supporting a maximum of 60 APs (the number goes down to 30 if the AP acting as the WDS also accepts clients associations).
Figure 1 Fast Secure Roaming Implementation
With AP-based WDS, FSR is available when the client roams between two APs that are configured with the same VLAN on the wired side. This is Layer 2 roaming because the client remains part of the same subnet. As a consequence of such an implementation and to provide a campus-wide roaming solution, the VLAN to which the client belongs must be configured on every access switch where the APs are attached.
Cisco does not recommend spanning a VLAN across the entire campus. VLANs must be terminated at the distribution switch or first hop router to limit the Spanning Tree and broadcast domain.
The introduction of switch-based WDS and the WLSM facilitates Layer 3 FSR and provides a highly-scalable solution for Layer 3 mobility in the campus. By centralizing the functionality of WDS in the WLSM blade in a central switch, switch-based WDS provides the following benefits:
•
•
•
•
•
•
Figure 2 shows all these advantages.
Figure 2 WLSM Advantages
Required Components
Cisco SWAN Catalyst switch-based WDS consists of the following components:
•
•
•
•
•
•
In addition to the hardware requirements, the minimal software requirements for this solution are the following:
•
•
•
•
The software requirements for Cisco Secure ACS are dependent on the type of Extensible Authentication Protocol (EAP) desired. For full support of all the EAP types including EAP-Flexible Authentication via Secure Tunneling (FAST), use release 3.2.3 or higher.
Solution Description
This section includes the following topics:
•
Centralized WDS
The WLSM embeds the functionality of WDS in a service module of the Cisco Catalyst 6500 Series. With the addition of this module, the Catalyst 6500 integrates wireless and wired traffic on the same platform.
With AP-based WDS, the WDS resides on one of the APs in the subnet, and is Layer 2-connected to all the other APs that are authenticated to that WDS.
With switch-based WDS using the WLSM, the functionality of WDS is moved from the AP in one subnet to the WLSM blade in a centralized location in the network. The centralized WDS now defines the roaming domain; a subsequent section of this document explains that Layer 3 seamless roaming is provided only if the APs are part of the same roaming domain.
All the APs belonging to the same roaming domain must use Cisco LEAP to authenticate to the RADIUS server through the central WDS. This defines the infrastructure authentication. During this phase, all the APs are the clients in respect to the 802.1X authentication, and they authenticate to the network through the WLSM that acts as the Network Access Server (NAS) for the network. The WLSM also discovers all the APs that will use its service during this phase. Thus, the infrastructure authentication is not changed when either an AP-based WDS or a switch-based WDS is used.
With switch-based WDS, the Wireless LAN Context Control Protocol (WLCCP) has been modified to run on top of a Layer 3 infrastructure. The WDS and the APs are thus no longer Layer 2 adjacent, and the entire campus network is between them. Therefore, with switch-based WDS, a management VLAN does not need to span the entire campus for the APs to communicate with each other and with the WDS at Layer 2. Also, with switch-based WDS, the network administrator has only one WDS to configure and manage, reducing the management overhead.
The centralized WDS of the switch-based WDS also acts as the NAS for all the client authentications. In this way, the WDS gains knowledge of more than just all the APs in the roaming domain. This information is shared with the Layer 3 Mobility Manager on the Supervisor 720 (Sup720) and used to build the internal database.
Layer 3 Mobility Manager
The Layer 3 Mobility Manager (L3MM) is the new software subsystem that runs on the Sup720 Route Processor (RP). L3MM interacts on one side with the WDS software running on the WLSM through a new protocol called Layer 3 Control Protocol (LCP) over the Ethernet Out of Band Channel (EOBC). On the other side, the L3MM interacts with the other components of the Catalyst 6500, mainly the hardware subsystem for the implementation of generic routing encapsulation (GRE) tunnel interfaces and the programming of the forwarding table and the Dynamic Host Configuration Protocol (DHCP) snooping, all of which are for handling client registrations.
The L3MM is responsible for creating and maintaining the mobility database that contains the list of all the wireless clients registered with the WLSM. Each mobility record includes the IP and MAC address, and the AP with which it is associated.
Mobility Groups
The concept of the mobility group is one of the most important concepts introduced in Cisco SWAN switch-based WDS. With switch-based WDS, a wireless client experiences a seamless roaming (maintaining all its IP sessions) when moving between two APs configured to be part of the same mobility group.
A mobility group is defined on the AP by a unique mapping between the service set identifier (SSID) for the radio side and the network ID for the wired side. The network ID is the new element of this solution. The network ID represents the overlaid logical network built on top of the existing infrastructure using GRE tunnels, and its mapping to the SSID replaces that between the SSID and the VLAN ID.
A subsequent section of this document explains that for IP unicast traffic there is no need to define an 802.1q trunk connection between the AP and the access switch to separate the traffic coming from a different SSID. In other words, the VLAN is no longer used for traffic segmentation on the wired side of the AP. In this case, with the definition of the mobility group, the traffic from different SSIDs is carried on the wired side over different GRE tunnels to the central switch.
The mobility group is in fact also identified on the Sup720 by the configuration of a GRE tunnel interface. This interface is assigned to the mobility group by configuring the corresponding network ID. The tunnel interface acts as the default gateway for all the wireless traffic belonging to the wireless logical network and represents the single point of ingress and egress for IP unicast traffic to and from the wired network.
Multipoint GRE Technology
The mobility group represents the logical wireless subnet where the clients reside. This overlaid network is built using the mGRE technology, which enables Cisco IOS to have one GRE tunnel interface that has a manually-configured tunnel source but with dynamic tunnel destinations. In the case of a WLSM deployment, this allows the GRE tunnels to be built dynamically from the APs belonging to a mobility group to the unique tunnel interface.
The APs learn the mobility group and tunnel destination IP address mapping from the WDS via WLCCP messages during infrastructure authentication. With this information, the AP is able to create the corresponding GRE tunnel and send the traffic over it after it receives the traffic from a wireless client belonging to a certain mobility group and thus a certain SSID. On the central switch, the multipoint GRE configuration allows the supervisor to accept any tunnel dynamically created by the AP.
All the Layer 3 interfaces on the Catalyst 6500, such as routed ports and tunnel interfaces, are virtual interfaces and are assigned an internal VLAN number by the switch to manage the traffic. This VLAN is taken from the pool of the non-client VLANs; basically, any number in the range of 1025-4096. The implementation of the Sup720 for GRE tunnel interfaces requires two internal VLANs to be allocated for every tunnel interface defined on the box. To determine how many tunnels and thus mobility groups are configurable on the supervisor, use the following equation:
4096 - (1025 + number of L3 interfaces in use)/2
There is a times 2 factor for each tunnel interface present.
The number of mobility groups is currently limited by the WDS, which supports only16 on switch-based WDS.
Layer 3 Roaming with the WLSM
This section includes the following topics:
Layer 3 Roaming Overview
Mobility in a wireless LAN environment can present a challenge as the physical reach of the network grows. Applications such as voice require sub-150 ms roam times and expect IP address continuity, regardless of the Layer 3 boundaries that are crossed. Deploying a large and flat Layer 2 network can subject user traffic to delays and loss of service because of issues such as broadcast storms and Spanning Tree Protocol (STP) reconvergence times.
The Cisco Catalyst 6500 Series WLSM blade and Cisco SWAN define a Layer 3 mobility solution. This section defines Layer 3 roaming as supported by this new architecture to differentiate this solution from other possible L3 mobility solutions such as Mobile IP.
With Layer 2 roaming, the wireless client roams between two APs that are part of the same subnet on the wired side. This functionality is provided by AP-based WDS, in which the APs must be configured to be in the same VLAN (the AP management VLAN) as a result of the following design constraints:
•
•
With Layer 3 roaming, the wireless client roams between two APs that reside in two different subnets and thus two different VLANs on the wired side. This removes the creation of VLANs that span the entire campus, as are created by AP-based WDS. This is explained in more detail in the "Design Considerations" section.
Layer 3 mobility as provided by switch-based WDS provides better performance and a more scalable approach. APs may be deployed in any location in a large Layer 3 network without requiring a single VLAN to be carried throughout the wired switch infrastructure. An overlay of mGRE tunnels allows clients to roam to other APs residing on different Layer 3 subnets without loss of connectivity or a change in IP addressing.
When a mobile user associates with an access point under the control of the WLSM, the user registers with the network and is assigned to a particular mobility group. At the system level, the network ID internally defines this mobility group. The system uses the network ID to associate the user with a particular GRE tunnel. As the user roams, the system tracks the movement of the user to ensure the association is maintained with the same mobility group.
Fast Secure L3 Roaming
Fast Secure Roaming (FSR) enables wireless clients to quickly roam across or between APs. Using Cisco Centralized Key Management (CCKM), the WDS caches session credentials (security keys) derived for a client session and uses them for re-authentication when a client roams. Caching this information rather than forcing the client to do a full authentication, authorization, and accounting (AAA) authentication reduces the authentication time and therefore the total time required for roaming.
The roaming is always defined from a client perspective because the client initiates roaming. In this document, client roaming is defined as "fast" if the whole handoff process happens in less than 100 ms; this guarantees support for low latency applications such as voice over IP (VoIP). In addition, the handoff is declared "seamless" if there is no impact on existing L3 connections. The roaming time is measured from the last successful packet sent or received on one AP to the first successful frame exchanged with the new AP.
The following two conditions must occur for the roaming to be fast and seamless in a WLAN deployment with the WLSM:
•
•
The best way to describe seamless Layer 3 roaming with the WLSM is to define it as a Layer 2 roaming across a Layer 3 infrastructure: the wireless client roams between the two APs that reside in different wired subnets but are part of the same mobility group. The client remains in the same wireless logical subnet created by the mGRE tunnel architecture and thus maintains the same IP address.
The use of CCKM guarantees a very fast handoff (less than 100ms), thus the client maintains all IP sessions and does not experience any lost connectivity. At present, CCKM is supported with LEAP and EAP-FAST authentication algorithms.
Putting It All Together
This section includes the following topics:
•
•
Configuration Overview
This section describes all the basic steps required to configure a wireless solution with the WLSM. This is not meant to be a configuration guide with details on the commands to use but instead a description of how all the concepts introduced to this point come together into a working solution. The next section describes the details of how IP data traffic flows through this architecture.
Consider a simple scenario in which two APs are configured in the same mobility group. Separate the configuration into the following three steps:
1.
2.
3.
Control path traffic is considered to be all the traffic that is sourced from or destined to the AP; this includes all the management traffic and the WLCCP traffic between the AP and the WDS on the WLSM. Data traffic is defined as the traffic to and from the wireless client. The traffic is encapsulated by the AP using GRE and is sent to the central switch.
Configuring the IP Connectivity
The first requirement of the Layer 2 connection is a VLAN defined on the AP as native; this is also known as the management VLAN or the default VLAN. The AP uses this VLAN to source its traffic; WLCCP, Simple Network Management Protocol (SNMP), HTTP, and Telnet for the management traffic, and GRE for unicast IP data traffic. The same VLAN must be defined on the access switch and on the first hop router or Layer 3 switch. The IP address assigned to the AP in the native VLAN is chosen from the local addressing scheme.
Following are some IP connectivity recommendations:
•
•
•
Configuring the Control Path
After configuring the WLSM to act as the WDS, the only other step required is to manually configure the AP with the IP address of the WDS. No auto-discovery mechanism is supported for the switch-based WDS.
Figure 3 shows the configuration through the GUI.
Figure 3 AP Configuration
Only one WDS IP address can be specified on the AP. This means that all the SSIDs that are WDS-enabled refer to the same WDS. Also, because the IP address is manually configured and WDS auto-discovery is disabled, there is no fallback to an AP-based WDS when the connection to the WLSM is lost. In this case, all the data traffic is dropped at the AP. Through WLCCP, the AP learns all the information needed to set up the data path, which is mainly the IP address of the GRE tunnel destination for each configured mobility group.
The steps seen so far are shown in Figure 4.
Figure 4 Control Path Configuration
Configuring the Data Path
The last step in the setup of the WLSM is the configuration of the mobility group. This step defines the wireless subnet to be assigned to the wireless users and is built through the use of GRE tunnels. The mobility group is identified on the AP by the mapping between an SSID and a network ID. On the central switch, a tunnel interface must be configured with the corresponding network ID (that is, mobility group) and assigned the IP address and subnet where the wireless clients are going to reside.
After this is done, when the AP receives a packet from a client on a particular mobility group, it forwards this traffic over the corresponding GRE tunnel to the central switch. The supervisor is responsible for stripping off the GRE header and forwarding the packet to the original destination. All these processes are hardware-accelerated. Figure 5 shows these steps.
Figure 5 Configured Data Path
Traffic Flow
This section includes the following topics:
•
Traffic Flow Overview
One of the most important changes introduced by switch-based WDS and the WLSM is the way wireless traffic flows to and from the wireless users across the network infrastructure. This section describes in detail how the unicast and broadcast traffic is carried into the GRE tunnels and how the wireless network integrates with the wired infrastructure. Understanding the traffic flow in switch-based WDS is not only fundamental in correctly designing a wireless solution with the WLSM, but also helps in addressing broadcast domain definitions.
Switch-based WDS with the Cisco Catalyst 6500 WLSM and GRE tunnel technology is an IP-only solution. All the traffic that is not IP (IPX, NetBIOS, and so on) that belongs to a certain SSID is bridged by the AP on the corresponding VLAN in the same way as is done in AP-based WDS with no WLSM.
This section describes how the traffic flows for the data path; that is, the traffic to and from the wireless users. This is the traffic that is encapsulated into GRE by the AP and then switched in hardware by the Cisco Catalyst 6500. The control path, which is all the traffic originated or terminated on the AP, flows through the native infrastructure and is not covered in this section. The separation of data and control path is explained in much more detail in subsequent sections.
Unicast Traffic
All the IP unicast traffic to and from a wireless client belonging to a certain mobility group is sent over the corresponding GRE tunnel from the AP to the GRE tunnel interface on the central switch and back again the same way. As explained in the previous sections, the tunnel interface on the supervisor represents the default gateway for all the wireless traffic belonging to the wireless logical subnet identified by the mobility group.
Consider a common scenario with a wireless client and a target host somewhere in the wired network. When the wireless client sends an IP packet, the AP receives it and looks at the source MAC address. Based on the internal forwarding database, the AP determines to which GRE tunnel to forward the packet (which basically means to which network ID the client belongs). The content of the mobility forwarding table of the AP can be shown on the command-line interface (CLI) of the AP with the following command:
AP-B#sh wlccp ap mobility forwardingWireless Control(0002.7e07.8000) IPv4 Forwarding TableMAC Address IP address Tunnel address000d.bcfe.33f6 172.16.1.100 10.10.200.1000a.b74c.af0b 172.16.1.101 10.10.200.1The AP then strips off the 802.11 header, encapsulates the IP packet in GRE, adds the IP/Ethernet header sourced from its own IP/MAC address, and finally sends it to the Cisco Catalyst 6500.
After receiving the GRE-encapsulated packet from one of its physical interfaces, the supervisor processes it in hardware. This means that after the Ethernet header has been stripped off, the Policy Feature Card (PFC) performs a first lookup and decapsulates the packet. The adjacency points the packet to a second recursive lookup in which the PFC determines where to forward the packet. Finally, the Ethernet header is added and the frame is sent out the physical interface to the next hop.
Figure 6 shows all these steps.
Figure 6 Unicast Traffic—From Wireless Client to Target Host
The return traffic takes a similar path, as shown in Figure 7.
Figure 7 Unicast Traffic—Return Traffic
After receiving the traffic destined to the wireless user, the central switch looks at the mobility database to determine to which mobility group and thus over which GRE tunnel to send the packet. The central switch then encapsulates the packet with a new header using the AP IP address and forwards it to the AP. The AP first strips off the GRE header and then performs a mobility forwarding table lookup based on the received destination IP address of the original packet. In this way, the AP learns the MAC address to use to form the 802.11 header and then forwards the packet into the air.
All unicast traffic sourced from wireless users always goes over the GRE tunnel to the central switch where the forwarding decision is made. To better clarify the traffic flow, consider these two other scenarios:
•
•
In the first scenario (see Figure 8), Mobile Node 1 and 2 are associated to the same AP and have the same SSID configuration; thus they are part of the same logical wireless subnet.
Figure 8 Traffic Between Wireless Clients—Same AP and Same Mobility Group
Mobile Node 1 sends a packet to Mobile Node 2. The AP gets the frame and forwards it over the GRE tunnel associated to the mobility group. When the supervisor gets the packet and sees that the destination is on the same wireless subnet, it then makes a L2 switching decision and sends the packet back over the same tunnel from which it came. The AP decapsulates it and forwards it into the air.
In the second scenario (see Figure 9), Mobile Node 1 and 2 belong to two different wireless subnets (mobility group "blue" and "green" with SSID Engineering and Marketing respectively).
Figure 9 Traffic Between Wireless Clients—Different AP and Different Mobility Group
The traffic from Mobile Node 1 is forwarded over the blue GRE tunnel to the central switch. In this case, because the destination resides in another mobility group, a full L3 routing decision occurs. The supervisor first determines from which interface to send the packet out; it then examines its mobility database and determines which other interface tunnel to use to forward the packet. The supervisor uses the AP IP address to form the GRE packet and sends it to the AP where Mobile Node 2 is associated.
Broadcast Traffic
This section includes the following topics:
Broadcast Traffic Overview
To roam seamlessly, the wireless client must move between APs that belong to the same mobility group. In this way, the client remains in the same wireless subnet and is able to maintain that same IP address while roaming.
Cisco SWAN switch-based WDS with the WLSM supports up to 6000 users, who can be part of the same mobility group and thus part of the same wireless subnet or broadcast domain.
Concerns may arise about the amount of broadcast traffic this generates on the network and on how the solution scales with such a large broadcast domain. Understanding how IP broadcast traffic is managed by the WLSM solution is fundamental not only to a correct deployment of a wireless LAN solution with the Cisco Catalyst 6500 WLSM but also to address these concerns. The following sections examine the different types of broadcast packets and how they flow across this architecture.
Note
ARP Traffic
One of the significant architectural changes brought by the introduction of the switch-based WDS and the WLSM is related to how the AP manages Address Resolution Protocol (ARP) frames received by locally associated wireless clients. Before the introduction of the WLSM, the AP acted as a bridge for ARP frames, simply forwarding the broadcast frame to the local VLAN corresponding to the client SSID. With Cisco SWAN switch-based WDS and for the SSIDs that are WLSM-enabled, two different AP behaviors can be identified, based on the types of ARP frame sent by the wireless clients and received by the AP: ARP requests and gratuitous ARP (GARP) queries.
When the wireless client sends a broadcast ARP request frame to map an IP address to the corresponding MAC address, the AP intercepts this frame and replies to the client with the supervisor MAC address. The AP proxies all the wireless ARP requests and replies with the same MAC address it learns during the infrastructure authentication from the WDS. The reason for this behavior is that all the unicast IP traffic, no matter what the destination, must go through the supervisor, even if the destination is another wireless client associated to the same AP. As a consequence, no broadcast ARP traffic is sent over the GRE tunnel, which limits the amount of broadcast traffic allowed on the wired infrastructure.
The solution is automatically protected from malicious attacks based on a Layer 2 port scan. If a wireless attacker performs a Layer 2 port scan to discover who else is on the same subnet, the attacker gets only one single MAC address, which renders the attack useless.
With the GARP frame, for example, a wireless client sends the broadcast ARP message after being assigned a DHCP address to avoid IP address duplication. In this case, when the AP receives this message and identifies it as a GARP message, it forwards it over the tunnel. The supervisor receives it and checks its mobility database for any duplication. If no other client has the specified IP address, the supervisor drops the packet. Otherwise, it replies on behalf of the other wireless node. At this point, the operating system of the client that originated the GARP triggers the warning that a "duplicated IP address" exists in the network.
Another important thing to notice here is that with wireless traffic, the supervisor forwards traffic based on the mobility database, not the local ARP cache. Thus, an attack aimed at poisoning the ARP cache of the central switch (for example, a man-in-the-middle type of attack) has no effect on wireless traffic. This provides enhanced security for the WLAN.
DHCP Traffic
DHCP traffic is another very common type of broadcast traffic. This section explains how DHCP is managed by the AP and the Sup720 for the wireless client in a WLSM deployment.
When the client sends a DHCP request, the AP forwards it into the tunnel to the supervisor. If configured, the central switch relays this traffic to the DHCP server where the network administrator has configured the scope for wireless clients belonging to that mobility group. The other option is to configure the DHCP server directly on the Cisco IOS of the supervisor.
The important thing to notice here is that no DHCP traffic coming from an AP is going to be forwarded over the other GRE tunnels to an AP that is part of the same mobility group. This reduces the amount of broadcast traffic on the network.
IP Broadcast Traffic
Some wireless applications use a general broadcast or a subnet-directed broadcast to communicate to the clients. Consider this packet flow: the wireless client sends a packet destined to 255.255.255.255; the AP receives it and then forwards it over the GRE tunnel to the supervisor. By default, the switch drops this traffic, which prevents the broadcast from reaching other APs in the same mobility groups and thus other wireless clients in the same wireless subnet. If forwarding the broadcast traffic is desired, you can manually instruct the supervisor to duplicate all the broadcast packets received from one GRE tunnel to all the other GRE tunnels belonging to the same mGRE interface. You do this by configuring "mobility broadcast" directly under the tunnel interface.
By default in Cisco IOS, the tunnel interfaces have the no ip directed-broadcast command enabled, which prevents any broadcast from being forwarded through that interface. Remember to issue the ip directed-broadcast command together with the mobility broadcast command.
For broadcast traffic originating from the wired network and destined to all the clients in the wireless subnet (such as the case of a subnet-directed broadcast), the supervisor receives the packet and if the tunnel interface for that mobility group is configured with mobility broadcast, the supervisor duplicates the packets to all the GRE tunnels that belong to the mGRE interface that has received the broadcast.
IP Multicast Traffic
This section includes the following topics:
•
•
IP Multicast Traffic Overview
The introduction of the WLSM significantly changes how the AP manages IP multicast traffic, and has important consequences for the design of a multicast-enabled wireless network solution.
To understand how IP multicast traffic flows, important distinctions need to be made between the following types of traffic:
•
•
All the multicast traffic generated from a wireless client belonging to a certain mobility group is received by the AP and forwarded into the corresponding GRE tunnel to the central switch. Thus, all the IP multicast traffic enters the wired network through a single point, which is the mGRE tunnel interface on the Sup720. This makes it easy for a network administrator to control and manage this traffic with the use of ACLs and QoS policies.
Downstream multicast traffic is delivered in the same way for wireless and wired clients. This means that traffic originating from a wired multicast source and directed to a mobile node is not delivered through the GRE tunnel, but instead is forwarded using the native infrastructure.
The reason for this asymmetric behavior is in the unicast nature of GRE. For example, consider a mobility group that consists of 300 APs, each configured with a wireless client that requests the same multicast stream. When the traffic gets to the wireless switch from the wired source, the supervisor must duplicate the multicast stream to as many GRE tunnels as there are APs with a client interested in that multicast program; 300 GRE tunnels in this case.
This would be a very inefficient way to deal with the network bandwidth; an incoming multicast stream of 10 Mbps becomes a 300 * 10 Mbps = 3 Gbps worth of traffic by the time it leaves the wireless switch. In addition, there is also the supervisor processing overhead involved in the actual duplication of each multicast packet. The next paragraph describes in detail how the multicast traffic is delivered downstream.
Delivering Downstream Multicast Traffic with the WLSM
In a Cisco SWAN deployment with the WLSM, the IP multicast traffic downstream from a wired source to a wireless client is delivered outside the GRE tunnel leveraging the existing network infrastructure. This section explains what changes are required in the AP to achieve this, and the consequences from a design perspective.
Figure 10 shows how the AP processes the Internet Group Management Protocol (IGMP) join message received from the client. A similar behavior is applied to the IGMP leave message.
Figure 10 AP Processing of the IGMP Join Message
The AP has been configured with SSID = Engineering, which has been mapped to a certain network ID and also to a local VLAN: VLAN = Red. The connection between the AP and the access switch has also been configured as a 802.1q trunk. VLAN Red is carried to the switch and then to a first hop router.
The step-by-step process is as follows:
1.
2.
3.
4.
5.
6.
Note
The following additional configuration is required to enable multicast traffic with the WLSM when compared to a unicast-only solution:
•
•
You must assign an IP address to this L3 interface, and you must enable a multicast routing protocol, such as IP PIM, for example, for the router to forward the multicast traffic.
An important consequence of the multicast implementation with the WLSM, and in particular the fact that the traffic is delivered outside the tunnel, is that wireless multicast traffic cannot take advantage of the L3 seamless roaming provided by the mGRE infrastructure. As the client roams to a different AP in the same mobility group, it has to allow the time for the multicast network to reconverge before it can resume receiving the multicast traffic. This results in an interruption of traffic, and thus not in seamless roaming.
The roaming time can be improved in the following two ways:
•
•
New Concept—VLAN on the Access Point
In an AP-based WDS deployment, the AP is responsible for defining the integration between the wireless and the wired network. This integration is represented by the unique mapping between SSID and VLAN. As explained in the previous paragraph, with the switch-based WDS with the WLSM and the concept of the mobility group, this mapping is replaced by the other unique mapping between the SSID and the network ID. On the wireless side, the SSID continues to represent the method of segmenting the wireless media, but with switch-based WDS this segmentation is brought to the wired side through a GRE tunnel that is represented by the network ID. The VLAN is no longer used for this purpose. To understand the new role of the VLAN as defined on the AP, IP unicast and IP multicast traffic must be considered separately.
As previously explained in the "Traffic Flow" section, all the IP unicast traffic with the WLSM is encapsulated in GRE, and the tunnel is always sourced from the AP IP address. Thus, all the traffic is sourced from the native VLAN of the AP, where the AP IP address is defined. Unicast traffic from different SSIDs (and thus different mobility groups) is carried on different GRE tunnels using different tunnel destinations, but always sourced from the same IP address. In such a scenario, it is clear that the native VLAN is the only VLAN needed on the wired side.
This does not mean that you no longer need VLANs on the AP; the Cisco Aironet AP implementation requires that the broadcast key and security cipher be derived from the VLAN associated to a defined SSID. A unique mapping between SSID, network ID, and VLAN on the AP allows the network administrator to segment the broadcast traffic in the air and to use a different security policy for each mobility group.
Note
The situation is different for IP multicast traffic. To deliver the multicast traffic downstream from a wired source to a wireless client, a multicast VLAN must be defined not only on the AP but must also be known to the wired network. This means that the VLAN must be defined on the access switch and carried on an 802.1q trunk connection, and it also needs a L3 interface.
In summary, Cisco recommends a unique mapping between the SSID, the network ID, and the VLAN that must be configured locally to the AP. You can choose whether this VLAN must be known on the wired side of the network. This choice depends on whether or not you intend to support multicast for the mobility group.
Design Considerations
This section includes the following topics:
•
•
•
•
•
•
Scalability of the WLSM Solution
This section of the document describes how switch-based WDS achieves scalability and how it affects design of a wireless solution with the WLSM.
This section includes the following topics:
•
WLSM and Cisco Catalyst 6500 Scalability
This section includes the following topics:
•
•
WLSM and Cisco Catalyst 6500 Scalability Overview
One of the most important concepts to understand about the WLSM solution and its integration with the Cisco Catalyst 6500 is the separation between control and data traffic. It is not only important to learn how packets flow through the wireless switch and thus be able to troubleshoot issues that can arise when deploying the solution, but it is also particularly important to understand how the WLSM can scale in a very large wireless implementation. By keeping the control path and the data path completely separated, the WLSM can scale to very large numbers of APs and associated clients.
The WLSM acts as the centralized WDS for the network. The WDS talks WLCCP to the APs on one side, and RADIUS to the RADIUS server on the other side. Internally, the WLSM communicates with the supervisor (and in particularly with the L3MM on the RP using L3-Mobility Control Protocol (LCP). WDS is also responsible for RM aggregation and reporting to the CiscoWorks WLSE. All this traffic is defined as control path and serves a different functionality, as described in the following:
•
–
–
–
–
–
–
•
•
Note
All the control traffic goes through the WLSM blade, and this is the only traffic that goes through the blade.
Data traffic, defined as the traffic to and from the wireless clients, never goes through the blade. All data traffic uses the switching capabilities of the Sup720 and its distributed forwarding architecture, which delivers 400 million packets per second. 802.11g or 802.11a APs can carry an average of 25 Mbps of real data traffic each. Considering an enterprise campus deployment with a large number of clients and hundreds of APs, it is very easy to reach an aggregated traffic of gigabits per second that arrives at the supervisor through the mGRE tunnel interfaces. For this solution to scale to those numbers, it is vital to have hardware-assisted switching capabilities for wireless traffic and GRE packets in particular. The Sup720 provides this functionality.
These two different paths for control and data path are described in Figure 11 where the following abbreviations have been used:
•
•
•
Figure 11 Two Control and Data Paths
WLSM and Cisco Catalyst 6500—Scalability Numbers
As described in the previous paragraph, the scalability of a wireless deployment with the WLSM comes primarily from the following two factors:
•
•
Because of the hardware resources of the WLSM (processing power, CPU, and memory), the WLSM can support a maximum number of APs and client devices, with their associated roams per second.
The WLSM hardware architecture is based on the Komodo Plus line card and it includes the following features:
•
•
As with all hardware devices, the hardware capabilities of this blade impose a limit on the processing power of the WLSM as the WLSM manages the database of all the APs and clients registered with the WDS and supports the roaming of clients. The following roaming events and actions occur in which the WLSM WDS is involved:
1.
2.
3.
4.
5.
The WLSM must also support the wireless architecture in the case of failures; a power outage or a failure in a critical part of the network infrastructure causes all the APs and clients to register at the same time.
These and other considerations were taken into account when Cisco scalability tests were conducted to arrive at the numbers that the switch-based WDS with WLSM can support. These are also the official numbers that are supported by the Cisco Technical Assistance Center (TAC):
•
•
•
If you want to scale above these numbers, you must use a second blade. Keep in mind that the roaming domain is completely separated; there is no support for inter-WLSM roaming. If a client roams from an AP registered to WLSM-1 to another AP registered to WLSM-2, the client must go through a full 802.1X authentication and renew the IP address, because all client connections are dropped and must be re-initiated when roaming occurs between two WLSMs.
See Figure 12 to understand more of these numbers.
Figure 12 Roaming Distribution Results
Figure 12 shows the numbers of roaming events that were recorded at one university during a normal day of operation. The diagram shows for each event the corresponding number of occurrences for this event that happened, identified by the "number of roams/sec". For example, you can see that during the whole day the "1 roam/sec" was recorded 9510 times. The event "27 roams/sec" happened just twice. The average number of roams/sec was 1.5. This means that the number of roams in this example can be easily supported by the WLSM within its maximum limits.
If 20 roams/sec is exceeded at any point in time when using the WLSM, the expected behavior (which has not been tested) is for some of the wireless clients to experience a longer than usual roaming time. This means that under these stressed conditions, the advertised roaming time for FSR (<100 ms) is not guaranteed. However, it is expected that the client should still be able to roam and keep the same IP address without having to re-authenticate.
ACS Scalability
The AAA server scalability plays an important role in an 802.1X deployment. In particular, for a large wireless or wired 802.1X implementation, the AAA server can be a bottleneck if the solution is not designed properly. All the AAA authentication traffic must go through the server, and it is important to design and configure the AAA correctly to meet network needs. In case of a power outage or network failure, all the clients try to authenticate at the same time, which can easily overload the AAA server. This section describes the Cisco Secure Access Control Server (ACS), but similar consideration can be made for any other server used as the RADIUS server.
The number of authentications per second (both worst case and average scenarios) must be considered when assessing the appropriate scalability and availability for the AAA server. These numbers change with the type of EAP protocol being used. For example, Cisco Secure ACS with LEAP authentication has been tested to perform 40-60 authentications per second. When you consider other EAP types such as PEAP and EAP-TLS, then the number is likely to decrease, given the increased computation requirements of public key infrastructure (PKI) infrastructure over LEAP. Though formal testing on Cisco Secure ACS using EAP-TLS has not been performed, preliminary testing indicates a performance reduction of 20-30 percent in the number of authentications per second compared to LEAP.
Ideally, considering LEAP and 6000 clients, it takes 150 seconds to authenticate all the users if you assume the worst case scenario of 40 authentications per second. If the server receives more requests than it can manage, it immediately sends an Accept-Deny message back to the NAS and the authentication fails.
To avoid overloading the Cisco Secure ACS server and slowing down the performance of the network, a solution is needed to load balance the AAA requests across multiple servers. Cisco Secure ACS does not provide any clustering solution in which you can have multiple active servers and other servers used as backup. A load balancing solution must be implemented to redistribute all the RADIUS requests from the clients across different servers.
In a wireless architecture with the WLSM, the blade acts as an NAS for all the registered clients by relaying all the AAA requests from all the APs and mobile nodes to the RADIUS server. All the RADIUS messages carrying the EAP information are generated by the same IP address (the physical IP address of the blade), and using the same UDP ports. A load balancing solution must go deeper into the RADIUS packet to find information that is unique to each AAA request and thus can be used to load balance the traffic across multiple servers.
A possible solution is for the load balancer to examine the RADIUS headers and load balance based on Calling-Station-ID. The Calling-Station-ID in this case is the MAC address of the client. The server load balancing Cisco IOS code, starting from Release12.1E, supports this type of functionality. Following is a sample configuration for the implementation of server load balancing based on Calling-Station-ID:
ip slb serverfarm ACS-SLBnat serverreal 10.245.1.2 <<< Real Radius Server's IP Addressinservice!real 10.245.1.3 <<< Real Radius Server's IP Addressinservice!ip slb vserver Radius_AUTHvirtual 10.1.1.4 udp 1812 service radius <<< Radius Server's Virtual IP Addressserverfarm ACS-SLBsticky radius calling-station-id group 1sticky radius framed-ip group 1inservice!ip slb vserver Radius_ACCTvirtual 148.1.1.4 udp 1813 service radiusserverfarm ACS-SLBsticky radius calling-station-id group 1sticky radius framed-ip group 1inserviceCurrently, other platforms such as the Content Service Module do not support the ability to load balance based on parameters such as Calling-Station-ID.
AP-based WDS and Switch-based WDS—Can They Coexist?
With the introduction of the WLSM, Cisco SWAN provides the possibility for WDS functionality to be switch-based or AP-based, depending on the scalability requirements. In the first scenario, as we have discussed, the WDS runs on the WLSM blade in the Catalyst 6500, is usually placed in a centralized position in the network, and serves up to 300 APs in a roaming domain with 6000 associated clients. In the second scenario, the WDS is run on one of the APs, serving a maximum of 60 APs located in the same subnet.
The Cisco IOS Software release12.2.(15)XR provides the access point code to support switch-based WDS. This code allows the administrator to specify one WDS IP address for access points. This means that the AP is able to register only one WDS in the network for all the SSIDs where the WDS functionality is needed. As a consequence, when switch-based WDS is used, it is not possible to configure the AP in such a way that it falls back to an AP-based WDS solution when the switch-based WDS with the WLSM is not available. Using a combined switch-based WDS and AP-based WDS is not recommended in any case.
With the switch-based WDS and the WLSM, the AP sends all client traffic into GRE tunnels that source it from the AP native VLAN. It is easy to identify this traffic and control it, and unless multicast is configured, the connection to the switch is not a 802.1q trunk. If the WLSM fails, the AP starts bridging the traffic. The administrator loses control of the traffic and all the QoS and security policies must change to adapt to the new network configuration.
RADIUS-based Dynamic Mobility Group Assignment
As discussed previously, Cisco recommends mapping each SSID/network_ID to a unique VLAN that is locally defined on the AP. This VLAN allows the network administrator to define different security policies (802.11 encryption/authentication methods) for each mobility group.
The IT administrator may wish to assign the same 802.1X and encryption mechanisms for WLAN user access belonging to different mobility groups. In this scenario, the IT administrator may also consider imposing RADIUS-based mobility group access control, to ensure that the users are assigned to the correct mobility group.
For example, if the WLAN is set up such that all SSIDs use 802.1X and similar encryption mechanisms for WLAN user access, then a user can hop from one mobility group to another by simply changing the SSID and successfully authenticating to the AP using 802.1X. This may not be preferred if the WLAN user must be confined to a particular mobility group where certain security or QoS policies apply.
The ideal solution to this situation is to dynamically assign the user to the mobility group by providing the correct network ID after successful 802.1X authentication by the client. In the current RADIUS and WLSM release, RADIUS-based dynamic network ID assignment is not supported. A temporary solution is to use the RADIUS-based VLAN access control currently available in the AP and WDS code. There are two different ways to implement RADIUS-based mobility group access control features, as described in the next paragraphs.
The first method is to use RADIUS-based SSID access control. After successful 802.1X or MAC address authentication, the RADIUS server passes back the allowed SSID list for the WLAN user to the AP. If the user used an SSID on the allowed SSID list, then the user is allowed to associate to the WLAN. Otherwise, the user is disassociated from the AP.
To configure this option, you simply need to program the Cisco Secure ACS server to pass back to the access point the cisco-av-pair with the SSID setting assigned to the user, using the following steps:
Step 1
Figure 13 Interface Configuration
Step 2
ssid=<name>Be careful not to add any additional spaces.
Figure 14 User Setup
The second option is to use RADIUS-based VLAN assignment. After successful 802.1X or MAC address authentication, the RADIUS server assigns the user to a predetermined VLAN-ID. The SSID used for WLAN access does not matter because the user is always assigned to this predetermined VLAN-ID. The AP uses the VLAN internally to assign the user to the corresponding mobility group.
For this second option, consider an example of RADIUS-based VLAN assignment with related configuration. Both "Engineering" and "Marketing" mobility groups are configured to allow only 802.1X authentication (LEAP, EAP-TLS, PEAP, and so on) and to use the same cipher method, Cisco Temporal Key Integrity Protocol (TKIP) or WPA TKIP. On the AP, the mobility groups have the following configuration (only the interesting configuration is shown):
interface Dot11Radio0!encryption vlan 2 mode ciphers ckip!encryption vlan 7 mode ciphers ckip!ssid engineeringvlan 7authentication openauthentication network-eap eap_methodsauthentication key-management cckmmobility network-id 173!ssid marketingvlan 2authentication openauthentication network-eap eap_methodsauthentication key-management cckmmobility network-id 172As shown above, the SSIDs are configured with the same parameters except the network ID and VLAN. Following is the corresponding configuration on the supervisor:
interface Tunnel172description to_wireless_marketingip address 172.16.1.1 255.255.255.0ip helper-address 10.1.1.11no ip redirectsip dhcp snooping packetstunnel source Loopback200tunnel mode gre multipointmobility network-id 172interface Tunnel173description to_wireless_engineeringip address 173.32.1.1 255.255.255.0ip helper-address 10.1.1.11no ip redirectsip dhcp snooping packetstunnel source Loopback202tunnel mode gre multipointmobility network-id 173On the Cisco Secure ACS, two users are defined: John from Marketing is going to be assigned to VLAN 2, and Dave from Engineering is going to be assigned to VLAN 7. This is done by configuring the following user RADIUS attributes:
•
•
•
You first must enable the setting of the RADIUS attributes on a user basis, as in the following procedure,
Step 1
Figure 15 Interface Configuration
Step 2
For example, see Figure 16.
Figure 16 User Setup
If Dave from Engineering uses the "marketing" SSID to gain access to the wireless LAN, then after authentication, the RADIUS server sends back VLAN-ID 7, which corresponds to the correct mobility group to which the user belongs. The AP uses this information to assign Dave to the Engineering mobility group and Dave receives a DHCP address, in the subnet 173.32.1.x/24 in this example.
Using this method, a user is mapped to a fixed wired VLAN, and thus a mobility group, throughout an enterprise network.
IP Addressing Scheme Recommendations
This section provides some general guidelines on how to design the IP addressing scheme for a wireless deployment with the WLSM to minimize the number of addresses needed for the solution, and to provide a seamless integration into the existing IP infrastructure. This section includes the following topics:
•
•
Assigning IP Addresses to the Supervisor Interfaces and to the WLSM
A VLAN must be assigned to the blade for the WLSM to communicate to the rest of the network. As described in [1], you achieve this by entering the following command in Sup720 global configuration mode:
wlan module <slot number> allowed-vlan <VLAN number>The WLSM needs an IP address and a default gateway on this VLAN/subnet. The VLAN must be defined locally from the supervisor pool of available VLANs, but the corresponding VLAN interface can be configured on any box where that VLAN is terminated. Cisco recommends choosing the WLSM VLAN and configuring the VLAN interface on the same box where the blade is allocated. There are many reasons to do this, including the following:
•
•
•
•
When deciding on the IP address and mask to assign to the VLAN interface and to the WLSM itself, it is important to consider WLSM redundancy. As explained subsequently in the "Implementing Redundancy" section, a Hot Standby Routing Protocol (HSRP)-like redundancy implementation is available for the WLSM. Given the HSRP constraints, the active and standby WLSM and the corresponding VLAN interfaces must be on the same subnet, and the VLAN must be shared between the two supervisors. This means that five IP addresses are needed on that subnet: two for the WLSMs, two for the VLAN interfaces, and one for the virtual IP (VIP) address.
To minimize the IP addressing used, a subnet mask of 255.255.255.248 (or /29) is recommended. The subnet can be chosen from the ones available on the local supervisor. For example, the configuration of one of the two wireless switches can be the following (WLAN-1 configuration):
wlan vlan 10standby address 10.10.10.10ip add 10.10.10.11 255.255.255.248gateway 10.10.10.9adminThe following is an example of Sup720-1 configuration:
wlan module 3 allowed-vlan 10!interface vlan 10ip address 10.10.10.9 255.255.255.248Now consider the IP address to assign to the mobility group and the corresponding GRE tunnel interface, and thus the subnet or subnets where the wireless clients will reside. In this case, you have the following two options:
•
•
In the first case, you need only to configure the GRE tunnel interface that identifies the mobility group with an IP address and to dimension the subnet mask to include all the wireless hosts. One single mobility group can serve all the supported wireless clients for a maximum of 6000 users in the same subnet. In this case, a mask of 255.255.224.0 or /19 is needed. If the mobility group is untrusted, which means that only DHCP clients are allowed to connect, and assuming that the DHCP server is not local to the Cisco IOS, then the following additional configuration for DHCP is needed:
•
•
If the administrator does not want to change the previously assigned address ranges of the wireless users, it is possible to assign multiple subnets to the same mobility group. To do this, you can assign multiple secondary IP addresses to the GRE tunnel interface. If you are considering untrusted mobility networks, you must be aware of an additional configuration and limitation that goes with it. For the supervisor to be able to relay DHCP requests from multiple IP secondary addresses, you must enable the DHCP smart relay feature by issuing the following global configuration command:
ip dhcp smart-relayThis command instructs the Cisco IOS to consider the secondary addresses when receiving requests on one interface configured with ip helper-address. For example, assume the following tunnel interface configuration:
interface Tunnel1description to_Internal_employeesip address 172.28.1.1 255.255.255.0ip helper-address 10.1.1.11ip address 172.28.2.1 255.255.255.0 secondaryip address 172.28.3.1 255.255.255.0 secondary<snip>In this case, the supervisor, when receiving a DHCP request on Tunnel 1 interface, relays the request to the configured DHCP server using the primary address in the relay field. The clients in this example are assigned an address in the subnet network 172.28.1.0.
The DHCP relay agent continues to use the primary address until depletion of the primary DHCP pool or DHCP server timeout. After three request attempts and no response, the relay agent automatically starts forwarding the DHCP requests with the first secondary address configured. In this example, the clients are assigned an address in subnet 172.28.2.0. The DHCP smart relay feature supports a maximum of two secondary IP addresses.
Finally, you must consider how to select the IP address to be assigned to a mobility group. The subnets you assign to the wireless users must be advertised in the routing table if you want the mobile users to be reached by the rest of the network. This means that if you are performing summarization on the distribution layer switch where the tunnel interface is configured, Cisco recommends choosing a subnet in the summary block assigned to that switch. In this way, you do not increase the numbers of routes sent to the core upstream routers.
Assigning VLAN and IP Addresses to the AP and First Hop Router
All the unicast traffic originated from the AP is sourced from the AP IP address and is thus received by the switch on the AP native VLAN. When deciding the VLAN and IP address to assign to the AP, Cisco recommends that you choose a VLAN/subnet that is not shared by any other traffic on the access switch. There are many reasons to do this, including the following:
•
•
•
For the subnet mask, only two IP addresses are needed on that AP subnet: the IP address of the Bridge Virtual Interface (BVI) of the AP, and the IP address of the first hop router where that subnet is terminated. You need only a 255.255.255.252 (or /30) subnet.
You must take a different approach when implementing multicast. As explained earlier, for multicast to work, you must do the following:
•
•
•
•
When assigning the IP address to the first hop router multicast interface, the only requirement is that the IP address be routable, because it has to receive the client IGMP join message and build the PIM multicast tree. No other devices must be on that subnet; a /32 subnet mask can be used to save addressing space. The Cisco IOS does not let you configure a /32 address unless the interface is a loopback. Cisco then recommends using a 255.255.255.252 (or /30) mask when configuring the IP address of the L3 multicast interface.
GRE and Issues with Fragmentation
This section introduces the issues that may arise in your network after the WLSM solution is in place. All the packets from the AP to the supervisor with the WLSM are GRE-encapsulated; each packet has an extra 24 bytes that are added to the original payload. With the default IP maximum transfer unit (MTU) over Ethernet being 1500 bytes, this increases the chances of fragmentation, especially for big packets.
This section includes the following topics:
•
•
Fragmentation and Supervisor 720
Both the AP and the Catalyst 6500 do fragmentation and reassembly in software, which may or may not affect the performance of the box, depending on the traffic load.
Because of a hardware buffer space limitation and the fact that the Sup720 performs GRE packet decapsulation in hardware, received GRE fragments may not be correctly reassembled by the Sup720 if the GRE packets arrive in fragments. This is because the Sup720 must first reassemble the fragments before it is able to take off the GRE header. Because buffer space is required, but not available to storethe fragments, the Sup720 may not correctly reassemble the GRE fragments.
To minimize the effects of this situation, efforts should be made to prevent the Sup720 from receiving fragments of GRE packets. If fragmentation is needed, the fragmentation must be performed on the original packet before the GRE encapsulation, given the size of the packets and the extra 24 bytes of the GRE encapsulation. When this is done, the supervisor receives normal GRE packets and the decapsulation is successfully completed in hardware. The decapsulated packets are then switched in hardware, ignoring the fact that they are IP fragments, and the packets are reassembled by the end station.
To achieve this outcome, manually calculate the IP MTU of the path between the AP and the supervisor, checking all the switches, routers, and the connecting links along the path. Perform this for both the upstream (from the AP to the supervisor) and the downstream direction. After the minimum IP MTU has been determined, the supervisor GRE tunnel interface must be configured accordingly, as follows:
IP MTU of the tunnel = (IP MTU) min - 24 bytes
The configuration is needed only on the supervisor tunnel interface. After this is done, the L3MM informs the WDS, which in turn generates a WLCCP message update to the AP with the configured IP MTU value. This is done automatically, and you do not need to do any other AP configurations. By setting the IP MTU on both the APs and the tunnel interfaces of the supervisor to this value, you help to ensure that if fragmentation is needed, it is performed before encapsulating in GRE. The default IP MTU on a tunnel interface of both the AP and supervisor is 1476 bytes.
For example, if the minimum IP MTU along the path is 512 bytes, then you must set the IP MTU on the tunnel interface to be 512 - 24 = 488 bytes. Use the following interface command:
sup720(config-if)#ip mtu 488To go back to the default settings, use the no ip mtu command. To verify that the configuration works, you can use the show ip interface tunnel command on the supervisor, or use the show wlccp wds mobility command on the WLSM CLI. Following is the output of these commands:
sup720#sh ip int tunnel 172Tunnel172 is up, line protocol is upInternet address is 172.16.1.1/24Broadcast address is 255.255.255.255Address determined by non-volatile memory
