To add a MAC filter entry for the mesh access point on the controller using the controller GUI, follow these steps:

To add a MAC filter entry for the mesh access point on the controller using the controller CLI, follow these steps:

To configure the role of a mesh access point using the GUI, follow these steps:

To configure the role of a mesh access point using the CLI, enter the following command:

config ap role {rootAP | meshAP} Cisco_AP

To install and trust the CA certificates on the RADIUS server, follow these steps:

To enable external authentication for a mesh access point using the GUI, follow these steps:

To enable external authentication for mesh access points using the CLI, enter the following commands:

To view security statistics for mesh access points using the CLI, enter the following command:

show mesh security-stats Cisco_AP

Use this command to display packet error statistics and a count of failures, timeouts, and association and authentication successes as well as reassociations and reauthentications for the specified access point and its child.

In case there is a configuration of RAPs in the Mobility Group it is always advised to use the same PSK Keys or one of the 5 allowable PSK keys on all controllers in the Mobility Group; this way when MAPs coming from a different controllers they will be able to authenticate. By looking at the time stamp of the PSK you can find out where the MAP and PSK Key came from.

You must enable Ethernet bridging before you can configure VLAN tagging.

To enable VLAN tagging on a RAP or MAP using the GUI, follow these steps:

To configure a MAP access port, enter this command:

config ap ethernet 1 mode access enable AP1500-MAP 50

where AP1500-MAP is the variable AP_name and 50 is the variable access_vlan ID

To configure a RAP or MAP trunk port, enter this command:

config ap ethernet 0 mode trunk enable AP1500-MAP 60

where AP1500-MAP is the variable AP_name and 60 is the variable native_vlan ID

To add a VLAN to the VLAN allowed list of the native VLAN, enter this command:

config ap ethernet 0 mode trunk add AP1500-MAP3 65

where AP1500-MAP 3 is the variable AP_name and 65 is the variable VLAN ID

A workgroup bridge (WGB) is used to connect wired networks over a single wireless segment by informing the mesh access point of all the clients that the WGB has on its wired segment via IAPP messages. In addition to the IAPP control messages, the data packets for WGB clients contain an extra MAC address in the 802.11 header (4 MAC headers, versus the normal 3 MAC data headers). The extra MAC in the header is the address of the workgroup bridge itself. This extra MAC address is used to route the packet to and from the clients.

WGB association is supported on both the 2.4-GHz (802.11b/g) and 5-GHz (802.11a) radios on all Cisco APs.

Supported platforms are autonomous 1600, 1700, 2600, 2700, 3600, 3700, 1530, 1550, and 1570, which are configured as WGBs can associate with a mesh access point. See the “Cisco Workgroup Bridges” section in Cisco Wireless LAN Controller Configuration Guide for configuration steps at https:/​/​www.cisco.com/​c/​en/​us/​support/​wireless/​8500-series-wireless-controllers/​products-installation-and-configuration-guides-list.html

The supported WGB modes and capacities are as follows:

• The autonomous access points configured as WGBs must be running Cisco IOS release 12.4.25d-JA or later.

  Note	If your mesh access point has two radios, you can only configure workgroup bridge mode on one of the radios. We recommend that you disable the second radio. Workgroup bridge mode is not supported on access points with three radios.

• Client mode WGB (BSS) is supported; however, infrastructure WGB is not supported. The client mode WGB is not able to trunk VLAN as in an infrastructure WGB.

• Multicast traffic is not reliably transmitted to WGB because no ACKs are returned by the client. Multicast traffic is unicast to infrastructure WGB, and ACKs are received back.

• If one radio is configured as a WGB in a Cisco IOS access point, then the second radio cannot be a WGB or a repeater.

• Mesh access points can support up to 200 clients including wireless clients, WGB, and wired clients behind the associated WGB.

• A WGB cannot associate with mesh access points if the WLAN is configured with WPA1 (TKIP) +WPA2 (AES), and the corresponding WGB interface is configured with only one of these encryptions (either WPA1 or WPA2):

  Figure 10. WPA Security Settings for a WGB
  
  

  Figure 11. WPA-2 Security Settings for a WGB
  
  

To view the status of a WGB client, follow these steps:

Encapsulations

Several encapsulations are used by the mesh system. These encapsulations include CAPWAP control and data between the controller and RAP, over the mesh backhaul, and between the mesh access point and its client(s). The encapsulation of bridging traffic (noncontroller traffic from a LAN) over the backhaul is the same as the encapsulation of CAPWAP data.

There are two encapsulations between the controller and the RAP. The first is for CAPWAP control, and the second is for CAPWAP data. In the control instance, CAPWAP is used as a container for control information and directives. In the instance of CAPWAP data, the entire packet, including the Ethernet and IP headers, is sent in the CAPWAP container.

Figure 20. Encapsulations

For the backhaul, there is only one type of encapsulation, encapsulating mesh traffic. However, two types of traffic are encapsulated: bridging traffic and CAPWAP control and data traffic. Both types of traffic are encapsulated in a proprietary mesh header.

In the case of bridging traffic, the entire packet Ethernet frame is encapsulated in the mesh header.

All backhaul frames are treated identically, regardless of whether they are MAP to MAP, RAP to MAP, or MAP to RAP.

Figure 21. Encapsulating Mesh Traffic

Note	Mesh Data DTLS encryption is only supported on the wave 2 Mesh AP such as 1540 and 1560 models only.

Queuing on the Mesh Access Point

The mesh access point uses a high speed CPU to process ingress frames, Ethernet, and wireless on a first-come, first-serve basis. These frames are queued for transmission to the appropriate output device, either Ethernet or wireless. Egress frames can be destined for either the 802.11 client network, the 802.11 backhaul network, or Ethernet.

AP1500s support four FIFOs for wireless client transmissions. These FIFOs correspond to the 802.11e platinum, gold, silver, and bronze queues, and obey the 802.11e transmission rules for those queues. The FIFOs have a user configurable queue depth.

The backhaul (frames destined for another outdoor mesh access point) uses four FIFOs, although user traffic is limited to gold, silver, and bronze. The platinum queue is used exclusively for CAPWAP control traffic and voice, and has been reworked from the standard 802.11e parameters for CWmin, CWmax, and so on, to provide more robust transmission but higher latencies.

The 802.11e parameters for CWmin, CWmax, and so on, for the gold queue have been reworked to provide lower latency at the expense of slightly higher error rate and aggressiveness. The purpose of these changes is to provide a channel that is more conducive to video applications.

Frames that are destined for Ethernet are queued as FIFO, up to the maximum available transmit buffer pool (256 frames). There is support for a Layer 3 IP Differentiated Services Code Point (DSCP), so marking of the packets is there as well.

In the controller to RAP path for the data traffic, the outer DSCP value is set to the DSCP value of the incoming IP frame. If the interface is in tagged mode, the controller sets the 802.1Q VLAN ID and derives the 802.1p UP (outer) from 802.1p UP incoming and the WLAN default priority ceiling. Frames with VLAN ID 0 are not tagged.

Figure 22. Controller to RAP Path

For CAPWAP control traffic the IP DSCP value is set to 46, and the 802.1p user priority is set to 7. Prior to transmission of a wireless frame over the backhaul, regardless of node pairing (RAP/MAP) or direction, the DSCP value in the outer header is used to determine a backhaul priority. The following sections describe the mapping between the four backhaul queues the mesh access point uses and the DSCP values shown in Backhaul Path QoS.

Note

The platinum backhaul queue is reserved for CAPWAP control traffic, IP control traffic, and voice packets. DHCP, DNS, and ARP requests are also transmitted at the platinum QoS level. The mesh software inspects each frame to determine whether it is a CAPWAP control or IP control frame in order to protect the platinum queue from use by non-CAPWAP applications.

For a MAP to the client path, there are two different procedures, depending on whether the client is a WMM client or a normal client. If the client is a WMM client, the DSCP value in the outer frame is examined, and the 802.11e priority queue is used.

If the client is not a WMM client, the WLAN override (as configured at the controller) determines the 802.11e queue (bronze, gold, platinum, or silver), on which the packet is transmitted.

For a client of a mesh access point, there are modifications made to incoming client frames in preparation for transmission on the mesh backhaul or Ethernet. For WMM clients, a MAP illustrates the way in which the outer DSCP value is set from an incoming WMM client frame.

Figure 23. MAP to RAP Path

The minimum value of the incoming 802.11e user priority and the WLAN override priority is translated using the information listed in Table 3 to determine the DSCP value of the IP frame. For example, if the incoming frame has as its value a priority indicating the gold priority, but the WLAN is configured for the silver priority, the minimum priority of silver is used to determine the DSCP value.

If there is no incoming WMM priority, the default WLAN priority is used to generate the DSCP value in the outer header. If the frame is an originated CAPWAP control frame, the DSCP value of 46 is placed in the outer header.

With the 5.2 code enhancements, DSCP information is preserved in an AWPP header.

All wired client traffic is restricted to a maximum 802.1p UP value of 5, except DHCP/DNS and ARP packets, which go through the platinum queue.

The non-WMM wireless client traffic gets the default QoS priority of its WLAN. The WMM wireless client traffic may have a maximum 802.11e value of 6, but it must be below the QoS profile configured for its WLAN. If admission control is configured, WMM clients must use TSPEC signaling and get admitted by CAC.

The CAPWAPP data traffic carries wireless client traffic and has the same priority and treatment as wireless client traffic.

Now that the DSCP value is determined, the rules described earlier for the backhaul path from the RAP to the MAP are used to further determine the backhaul queue on which the frame is transmitted. Frames transmitted from the RAP to the controller are not tagged. The outer DSCP values are left intact, as they were first constructed.

Bridging Backhaul Packets

Bridging services are treated a little differently from regular controller-based services. There is no outer DSCP value in bridging packets because they are not CAPWAP encapsulated. Therefore, the DSCP value in the IP header as it was received by the mesh access point is used to index into the table as described in the path from the mesh access point to the mesh access point (backhaul).

Bridging Packets from and to a LAN

Packets received from a station on a LAN are not modified in any way. There is no override value for the LAN priority. Therefore, the LAN must be properly secured in bridging mode. The only protection offered to the mesh backhaul is that non-CAPWAP control frames that map to the platinum queue are demoted to the gold queue.

Packets are transmitted to the LAN precisely as they are received on the Ethernet ingress at entry to the mesh.

The only way to integrate QoS between Ethernet ports on AP1500 and 802.11a is by tagging Ethernet packets with DSCP. AP1500s take the Ethernet packet with DSCP and places it in the appropriate 802.11e queue.

AP1500s do not tag DSCP itself:

• On the ingress port, the AP1500 sees a DSCP tag, encapsulates the Ethernet frame, and applies the corresponding 802.11e priority.

• On the egress port, the AP1500 decapsulates the Ethernet frame, and places it on the wire with an untouched DSCP field.

Ethernet devices, such as video cameras, should have the capability to mark the bits with DSCP value to take advantage of QoS.

Note	QoS only is relevant when there is congestion on the network.

Use the commands in this section to view details on voice and video calls on the mesh network:

Figure 24. Mesh Network Example

• To view the total number of voice calls and the bandwidth used for voice calls on each RAP, enter this command:

  show mesh cac summary

  Information similar to the following appears:

  
    
  AP Name          Slot#   Radio  BW Used/Max  Calls
  ------------    -------  -----  -----------  -----
  SB_RAP1              0   11b/g     0/23437    0
                       1   11a       0/23437    2
  SB_MAP1              0   11b/g     0/23437    0
                       1   11a       0/23437    0
  SB_MAP2              0   11b/g     0/23437    0
                       1   11a       0/23437    0
  SB_MAP3              0   11b/g     0/23437    0
                       1   11a      0/23437    0?  
  

• To view the mesh tree topology for the network and the bandwidth utilization (used/maximum available) of voice calls and video links for each mesh access point and radio, enter this command:

  show mesh cac bwused {voice | video} AP_name

  Information similar to the following appears:

  
  AP Name       Slot#    Radio      BW Used/Max
  ------------- -------  -----      -----------
  SB_RAP1         0      11b/g       1016/23437
                  1      11a         3048/23437
  |SB_MAP1        0      11b/g       0/23437
                  1      11a         3048/23437
  ||  SB_MAP2     0      11b/g       2032/23437
                  1      11a         3048/23437
  ||| SB_MAP3     0      11b/g       0/23437
                  1      11a         0/23437
  

  Note	The bars (|) to the left of the AP Name field indicate the number of hops that the MAP is from its RAP.

  Note

  When the radio type is the same, the backhaul bandwidth utilization (bw used/max) at each hop is identical. For example, mesh access points map1, map2, map3, and rap1 are all on the same radio backhaul (802.11a) and are using the same bandwidth (3048). All of the calls are in the same interference domain. A call placed anywhere in that domain affects the others.

• To view the mesh tree topology for the network and display the number of voice calls that are in progress by mesh access point radio, enter this command:

  show mesh cac access AP_name

  
  Information similar to the following appears:
    
  AP Name             Slot#   Radio     Calls
  -------------      -------  -----    -----
  SB_RAP1              0      11b/g      0
                       1      11a        0
  |   SB_MAP1          0      11b/g      0
                       1      11a        0
  ||  SB_MAP2          0      11b/g      1
                       1      11a        0
  ||| SB_MAP3          0      11b/g      0
                       1      11a        0
    
  

  Note

  Each call received by a mesh access point radio causes the appropriate calls summary column to increment by one. For example, if a call is received on the 802.11b/g radio on map2, then a value of one is added to the existing value in that radio’s calls column. In this case, the new call is the only active call on the 802.11b/g radio of map2. If one call is active when a new call is received, the resulting value is two.

• To view the mesh tree topology for the network and display the voice calls that are in progress, enter this command:

  show mesh cac callpath AP_name

  
  Information similar to the following appears:
    
  AP Name             Slot#   Radio     Calls
  -------------      -------  -----    -----
  SB_RAP1              0      11b/g      0
                       1      11a        1
  |   SB_MAP1          0      11b/g      0
                       1      11a        1
  ||  SB_MAP2          0      11b/g      1
                       1      11a        1
  ||| SB_MAP3          0      11b/g      0
                       1      11a        0
    
  

  Note

  The calls column for each mesh access point radio in a call path increments by one. For example, for a call that initiates at map2 (show mesh cac call path SB_MAP2) and terminates at rap1 by way of map1, one call is added to the map2 802.11b/g and 802.11a radio calls column, one call to the map1 802.11a backhaul radio calls column, and one call to the rap1 802.11a backhaul radio calls column.

• To view the mesh tree topology of the network, the voice calls that are rejected at the mesh access point radio due to insufficient bandwidth, and the corresponding mesh access point radio where the rejection occurred, enter this command:

  show mesh cac rejected AP_name

  Information similar to the following appears:

  
    
  AP Name             Slot#   Radio     Calls
  -------------      -------  -----    -----
  SB_RAP1              0      11b/g      0
                       1      11a        0
  |   SB_MAP1          0      11b/g      0
                       1      11a        0
  ||  SB_MAP2          0      11b/g      1
                       1      11a        0
  ||| SB_MAP3          0      11b/g      0
                       1      11a        0
    
  

  Note	If a call is rejected at the map2 802.11b/g radio, its calls column increments by one.

• To view the number of bronze, silver, gold, platinum, and management queues active on the specified access point, enter this command. The peak and average length of each queue are shown as well as the overflow count.

  show mesh queue-stats AP_name

  Information similar to the following appears:

  
  Queue Type  Overflows  Peak length  Average length
   ----------  ---------  -----------  --------------
   Silver      0          1            0.000
   Gold        0          4            0.004
   Platinum    0          4            0.001
   Bronze      0          0            0.000
   Management  0          0            0.000
    
  

  Overflows—The total number of packets dropped due to queue overflow.

  Peak Length—The peak number of packets waiting in the queue during the defined statistics time interval.

  Average Length—The average number of packets waiting in the queue during the defined statistics time interval.

To enable multicast mode on the mesh network to receive multicasts from beyond the mesh networks, enter these commands:

config network multicast global enable

config mesh multicast {regular | in | in-out}

To enable multicast mode only the mesh network (multicasts do not need to extend to 802.11b clients beyond the mesh network), enter these commands:

config network multicast global disable

config mesh multicast {regular | in | in-out}

Note	Multicast for mesh networks cannot be enabled using the controller GUI.

To configure LSC, you must first gather and install the appropriate certificates on the controller. The following steps show how to accomplish this using Microsoft 2003 Server as the CA server.

To get the certificates for LSC, follow these steps:

To configure a locally significant certificate (LSC), follow these steps:

The following commands are related to LSCs:

• config certificate lsc {enable | disable}

  • enable—To enable an LSC on the system.

  • disable—To disable an LSC on the system. Use this keyword to remove the LSC device certificate and send a message to an AP, to do the same and disable an LSC, so that subsequent joins could be made using the MIC/SSC. The removal of the LSC CA cert on the WLC should be done explicitly by using the CLI to accommodate any AP that has not transitioned back to the MIC/SSC.

• config certificate lsc ca-server url-path ip-address

  Following is the example of the URL when using Microsoft 2003 server:

  http:<ip address of CA>/sertsrv/mscep/mscep.dll

  This command configures the URL to the CA server for getting the certificates. The URL contains either the domain name or the IP address, port number (typically=80), and the CGI-PATH.

  http://ipaddr:port/cgi-path

  Only one CA server is allowed to be configured. The CA server has to be configured to provision an LSC.

• config certificate lsc ca-server delete

  This command deletes the CA server configured on the controller.

• config certificate lsc ca-cert {add | delete}

  This command adds or deletes the LSC CA certificate into/from the controller's CA certificate database as follows:

  • add—Queries the configured CA server for a CA certificate using the SSCEP getca operation, and gets into the WLC and installs it permanently into the WLC database. If installed, this CA certificate is used to validate the incoming LSC device certificate from the AP.

  • delete—Deletes the LSC CA certificate from the WLC database.

• config certificate lsc subject-params Country State City Orgn Dept Email

  This command configures the parameters for the device certificate that will be created and installed on the controller and the AP.

  All of these strings have 64 bytes, except for the Country that has a maximum of 3 bytes. The Common Name is automatically generated using its Ethernet MAC address. This should be given prior to the creation of the controller device certificate request.

  The above parameters are sent as an LWAPP payload to the AP, so that the AP can use these parameters to generate the certReq. The CN is automatically generated on the AP using the current MIC/SSC "Cxxxx-MacAddr" format, where xxxx is the product number.

• config certificate lsc other-params keysize

  The default keysize value is 2048 bits.

• config certificate lsc ap-provision {enable | disable}

  This command enables or disables the provisioning of the LSCs on the APs if the APs just joined using the SSC/MIC. If enabled, all APs that join and do not have the LSC will get provisioned.

  If disabled, no more automatic provisioning will be done. This command does not affect the APs, which already have LSCs in them.

• config certificate lsc ra-cert {add | delete}

  We recommend this command when the CA server is a Cisco IOS CA server. The controller can use the RA to encrypt the certificate requests and make communication more secure. RA certificates are not currently supported by other external CA servers, such as MSFT.

  • add—Queries the configured CA server for an RA certificate using the SCEP operation and installs it into the controller database. This keyword is used to get the certReq signed by the CA.

  • delete—Deletes the LSC RA certificate from the WLC database.

• config auth-list ap-policy lsc {enable | disable}

  After getting the LSC, an AP tries to join the controller. Before the AP tries to join the controller, you must mandatorily enter this command on the controller console. By default, the config auth-list ap-policy lsc command is in the disabled state, and the APs are not allowed to join the controller using the LSC.

• config auth-list ap-policy mic {enable | disable}

  After getting the MIC, an AP tries to join the controller. Before the AP tries to join the controller, you must mandatorily enter this command on the controller console. By default, the config auth-list ap-policy mic command is in the enabled state. If an AP cannot join because of the enabled state, this log message on the controller side is displayed: LSC/MIC AP is not allowed to join.

• show certificate lsc summary

  This command displays the LSC certificates installed on the WLC. It would be the CA certificate, device certificate, and optionally, an RA certificate if the RA certificate has also been installed. It also indicates if an LSC is enabled or not.

• show certificate lsc ap-provision

  This command displays the status of the provisioning of the AP, whether it is enabled or disabled, and whether a provision list is present or not.

• show certificate lsc ap-provision details

  This command displays the list of MAC addresses present in the AP provisioning lists.