What is the default ap mode?

If your network contains various Cisco-licensed devices, you might want to consider using the Cisco License Manager (CLM) to manage all of the licenses using a single application. CLM is a secure client/server application that manages Cisco software licenses network wide.

The license agent is an interface module that runs on the controller and mediates between CLM and the controller’s licensing infrastructure. CLM can communicate with the controller using various channels, such as HTTP, Telnet, and so on. If you want to use HTTP as the communication method, you must enable the license agent on the controller.

The license agent receives requests from CLM and translates them into license commands. It also sends notifications to CLM. It uses XML messages over HTTP or HTTPS to receive the requests and send the notifications. For example, CLM sends a license install command, and the agent notifies CLM after the license expires.

This section contains the following subsections:

Controllers and access points have a Certificate Authority (CA) certificate that is used to sign and validate device certificates. The controller is shipped with a Cisco-installed CA certificate. This certificate may be used by EAP-FAST (when not using PACs), EAP-TLS, PEAP-GTC, and PEAP-MSCHAPv2 to authenticate wireless clients during local EAP authentication. However, if you want to use your own vendor-specific CA certificate, it must be downloaded to the controller.

Note	For more information about configuring local EAP, see the "Configuring Local EAP" section.

Follow the instructions in this section to download CA certificates to the controller through the GUI or CLI. However, before you begin, make sure that you have a TFTP or FTP server available for the certificate download. Follow these guidelines when setting up a TFTP or FTP server:

• If you are downloading through the service port, the TFTP or FTP server must be on the same subnet as the service port because the service port is not routable, or you must create static routes on the controller.

• If you are downloading through the distribution system network port, the TFTP or FTP server can be on the same or a different subnet because the distribution system port is routable.

• A third-party TFTP or FTP server cannot run on the same computer as Cisco Prime Infrastructure because the Prime Infrastructure built-in TFTP or FTP server and the third-party TFTP or FTP server require the same communication port.

  Note	All certificates downloaded to the controller must be in PEM format.

If VLAN groups are in use, we recommend that you enable multicast VLAN to limit multicast on the air to a single copy on a predefined multicast VLAN.

With VLAN select and VLAN pooling, there is a possibility that you might increase duplicate packets. With the VLAN select feature, every client listens to the multicast stream on a different VLAN. As a result, the controller creates different MGIDs for each multicast address and VLAN. Therefore, the upstream router sends one copy for each VLAN, which results, in the worst case, in as many copies as there are VLANs in the pool. Since the WLAN is still the same for all clients, multiple copies of the multicast packet are sent over the air. To suppress the duplication of a multicast stream on the wireless medium and between the controller and access points, you can use the multicast VLAN feature.

Multicast optimization enables you to create a multicast VLAN which you can use for multicast traffic. You can configure one of the VLANs of the WLAN as a multicast VLAN where multicast groups are registered. Clients are allowed to listen to a multicast stream on the multicast VLAN. The MGID is generated using mulicast VLAN and multicast IP addresses. If multiple clients on the VLAN pool of the same WLAN are listening to a single multicast IP address, a single MGID is generated. The controller makes sure that all multicast streams from the clients on this VLAN pool always go out on the multicast VLAN to ensure that the upstream router has one entry for all the VLANs of the VLAN pool. Only one multicast stream hits the VLAN pool even if the clients are on different VLANs. Therefore, the multicast packets that are sent out over the air is just one stream.

If the WLAN is anchored, then the interface mapping at the anchored side is used for client connections. For anchored guest WLANs, it is a best practice to use a black hole dynamic interface at the foreign controller. For more information, see https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-6/b_Cisco_Wireless_LAN_Controller_Configuration_Best_Practices.html#concept_331FB2E819654D62BC998FF00BFA3FF3

This section contains the following subsections:

IPv6 Neighbor Discovery is a set of messages and processes that determine relationships between neighboring nodes. Neighbor Discovery replaces ARP, ICMP Router Discovery, and ICMP Redirect used in IPv4.

At any given time, only eight IPv6 addresses are supported per client. When the ninth IPv6 address is encountered, the controller removes the oldest stale entry and accommodates the latest one.

IPv6 Neighbor Discovery inspection analyzes neighbor discovery messages in order to build a trusted binding table database, and IPv6 neighbor discovery packets that do not comply are dropped. The neighbor binding table in the controller track each IPv6 address and its associated MAC address. Clients are expired from the table according to Neighbor Binding timers.

This section contains the following subsections:

The controllers contain an internal DHCP server. This server is typically used in branch offices that do not already have a DHCP server.

The wireless network generally contains a maximum of 10 APs or less, with the APs on the same IP subnet as the controller.

The internal server provides DHCP addresses to wireless clients, direct-connect APs, and DHCP requests that are relayed from APs. Only lightweight access points are supported. When you want to use the internal DHCP server, ensure that you configure SVI for client VLAN and set the IP address as DHCP server IP address.

DHCP option 43 is not supported on the internal server. Therefore, the access point must use an alternative method to locate the management interface IP address of the controller, such as local subnet broadcast, Domain Name System (DNS), or priming.

Also, an internal DHCP server can serve only wireless clients, not wired clients.

When clients use the internal DHCP server of the controller, IP addresses are not preserved across reboots. As a result, multiple clients can be assigned to the same IP address. To resolve any IP address conflicts, clients must release their existing IP address and request a new one.

Wired guest clients are always on a Layer 2 network connected to a local or foreign controller.

Note	VRF is not supported in the internal DHCP servers. DHCPv6 is not supported in the internal DHCP servers.

This is an enhancement to the present implementation of the user idle timeout feature, which is applicable to all WLAN profiles on the controller. With this enhancement, you can configure a user idle timeout for an individual WLAN profile. This user idle timeout is applicable to all the clients that belong to this WLAN profile.

You can also configure a threshold triggered timeout where if a client has not sent a threshold quota of data within the specified user idle timeout, the client is considered to be inactive and is deauthenticated. If the data sent by the client is more than the threshold quota specified within the user idle timeout, the client is considered to be active and the controller refreshes for another timeout period. If the threshold quota is exhausted within the timeout period, the timeout period is refreshed.

Suppose the user idle timeout is specified as 120 seconds and the user idle threshold is specified as 10 megabytes. After a period of 120 seconds, if the client has not sent 10 megabytes of data, the client is considered to be inactive and is deauthenticated. If the client has exhausted 10 megabytes within 120 seconds, the timeout period is refreshed.

This section contains the following subsections:

Mobility, or roaming, is a wireless LAN client’s ability to maintain its association seamlessly from one access point to another securely and with as little latency as possible. This section explains how mobility works when controllers are included in a wireless network.

When a wireless client associates and authenticates to an access point, the access point’s controller places an entry for that client in its client database. This entry includes the client’s MAC and IP addresses, security context and associations, quality of service (QoS) contexts, the WLAN, and the associated access point. The controller uses this information to forward frames and manage traffic to and from the wireless client.

Note	The information about mobility in this section applies to APs in only Local Mode. For APs in FlexConnect mode, see the FlexConnect section.

The figure below shows a wireless client that roams from one local mode access point to another local mode access point when both access points are joined to the same controller.

When the wireless client moves its association from one access point to another, the controller simply updates the client database with the newly associated access point. If necessary, new security context and associations are established as well.

The process becomes more complicated, however, when a client roams from an access point joined to one controller to an access point joined to a different controller. It also varies based on whether the controllers are operating on the same subnet.

The figure below shows intercontroller Layer 2 roaming, which occurs when the wireless LAN interfaces of the controllers are on the same IP subnet.

When the client associates to an access point joined to a new controller, the new controller exchanges mobility messages with the original controller, and the client database entry is moved to the new controller. New security context and associations are established if necessary, and the client database entry is updated for the new access point. This process remains transparent to the user.

The figure below shows intercontroller Layer 3 roaming, which occurs when the wireless LAN interfaces of the controllers are on different IP subnets.

Layer 3 roaming is similar to Layer 2 roaming in that the controllers exchange mobility messages on the client roam. However, instead of moving the client database entry to the new controller, the original controller marks the client with an “Anchor” entry in its own client database. The database entry is copied to the new controller client database and marked with a “Foreign” entry in the new controller. The roam remains transparent to the wireless client, and the client maintains its original IP address.

If you enable conditional web redirect, the user can be conditionally redirected to a particular web page after 802.1X authentication has completed successfully. You can specify the redirect page and the conditions under which the redirect occurs on your RADIUS server. Conditions might include the user’s password reaching expiration or the user needing to pay his or her bill for continued usage.

If the RADIUS server returns the Cisco AV-pair “url-redirect,” then the user is redirected to the specified URL upon opening a browser. If the server also returns the Cisco AV-pair “url-redirect-acl,” the specified access control list (ACL) is installed as a preauthentication ACL for this client. The client is not considered fully authorized at this point and can only pass traffic allowed by the preauthentication ACL.

After the client completes a particular operation at the specified URL (for example, changing a password or paying a bill), the client must reauthenticate. When the RADIUS server does not return a “url-redirect,” the client is considered fully authorized and allowed to pass traffic.

Note	The conditional web redirect feature is available only for WLANs that are configured for 802.1X or WPA+WPA2 Layer 2 security.

After you configure the RADIUS server, you can then configure the conditional web redirect on the controller using either the controller GUI or CLI.

Cisco TrustSec enables organizations to secure their networks and services through identity-based access control to anyone, anywhere, anytime. The solution also offers data integrity and confidentiality services, policy-based governance, and centralized monitoring, troubleshooting, and reporting services. You can combine Cisco TrustSec with personalized, professional service offerings to simplify the solution deployment and management, and is a foundational security component to Cisco Borderless Networks.

The Cisco TrustSec security architecture helps build secure networks by establishing domains of trusted network devices. Each device in the domain is authenticated by its peers. Communication on the links between the devices in the domain is secured with a combination of encryption, message integrity check, and data path replay protection mechanisms. Cisco TrustSec uses a device and user credentials that are acquired during authentication for classifying the packets by security groups (SGs), as they enter the network. This packet classification is maintained by tagging packets on an ingress to the Cisco TrustSec network. This is because they can be correctly identified to apply security and other policy criteria along the data path. The tag, called the security group tag (SGT), allows the network to enforce the access control policy by enabling the endpoint device to act upon the SGT to filter traffic. Note that the Cisco TrustSec security group tag is applied only when you enable AAA override on a WLAN.

One of the components of Cisco TrustSec architecture is the security group-based access control. In the security group-based access control component, access policies in the Cisco TrustSec domain are topology-independent, based on the roles (as indicated by the security group number) of source and destination devices rather than on network addresses. Individual packets are tagged with the security group number of the source.

The Cisco TrustSec solution is implemented across the following three distinct phases:

• Client classification at ingress by a centralized policy database (Cisco ISE) and assigning unique SGT to clients based on client identity attributes such as the role and so on.

• Propagation of IP-to-SGT binding to neighboring devices using the SGT Exchange Protocol (SXP) or inline tagging methods or both.

• Security Group Access Control List (SGACL) policy enforcement. Cisco AP is the enforcement point for central or local switching (central authentication).

For more information about deploying the Cisco TrustSec solution, see the Wireless TrustSec Deployment Guide at:

A Security Group is a group of users, endpoint devices, and resources that share access control policies. Security groups are defined by the administrator in the Cisco ISE. As new users and devices are added to the Cisco TrustSec domain, the authentication server assigns these new entities to the appropriate security groups. Cisco TrustSec assigns each of the security group a unique 16-bit number whose scope is global in a Cisco TrustSec domain. The number of security groups in a wireless device is limited to the number of authenticated network entities. You do not have to manually configure the security group numbers.

After a device is authenticated, the Cisco TrustSec tags any packet that originates from that device with an SGT that contains the security group number of the device. The packet carries this SGT everywhere in the network, in the Cisco TrustSec header.

As the SGT contains the security group of the source, the tag can be referred to as the source SGT (S-SGT). The destination device is also assigned to a security group (destination SG) that can be referred to as the destination SGT (D-SGT), although the Cisco TrustSec packet does not contain the security group number of the destination device.

You can control the operations that users can perform based on the security group assignments of users and destination resources, using the Security Group Access Control Lists (SGACLs). Policy enforcement in a Cisco TrustSec domain is represented by a permission matrix, with the source security group on one axis and destination security group numbers on the other axis. Each cell in the matrix body contains an ordered list of SGACLs, which specifies the permissions that must be applied to packets originating from the source security group and destined for the destination security group. When a wireless client is authenticated, it downloads all the SGACLs in the matrix cells.

When a wireless client connects to the network, the client pushes all the ACLs to the controller.

This figure shows an example of a Cisco TrustSec permission matrix with three defined user roles, one defined destination resource, and three SGACL policies that control access to the destination server based on the user roles.

Figure 1. Example of an SGACL Policy Matrix

Cisco TrustSec achieves role-based topology-independent access control in a network by assigning users and devices in the network to security groups and applying access control between the security groups. The SGACLs define access control policies based on the device identities. As long as the roles and permissions remain the same, changes to the network topology do not change the security policy. When a user is added to the wireless group, you simply assign the user to an appropriate security group and the user immediately receives permissions to that group.

The size of ACLs is reduced and their maintenance is simplified with the use of role-based permissions. With Cisco TrustSec, the number of Access Control Entities (ACEs) configured is determined by the number of permissions that are specified, resulting in a much smaller number of ACEs.

Note

By default, the following predefined SGACL policies are downloaded: Default policy—This is applied when source and destination SGTs are available, but SGACLs are not defined for a cell or column. Unknown policy—This is applied when the source SGT is unknown. You can use the session group named Unknown and apply the unknown policy on that traffic.

The following are examples of SGACLs that are on Cisco ISE and downloaded on a controller and tested:

Generic SGACL

• Web_SGACL

  permit tcp dst eq 80

  permit tcp dst eq 443

  deny ip

• PCI_Servers_SGACL

  deny tcp dst eq 4444

  deny tcp dst eq 4446

  deny tcp dst eq 443

  permit ip

• PCI_Zone_SGACL

  deny tcp dst eq 4444

  deny tcp dst eq 4446

  deny tcp dst eq 443

  permit ip

• Deny_SSH_RDP_Telnet_SGACL

  deny tcp dst eq 23

  deny tcp dst eq 23

  deny tcp dst eq 3389

  permit ip

• Deny_JumpHost_Protocols

  deny tcp dst eq 23

  deny tcp dst eq 23

  deny tcp dst eq 3389

  permit ip

Anti-Malware SGACLs

• Anti-Malware-ACL

  deny icmp

  deny udp src dst eq domain

  deny tcp src dst eq 3389

  deny tcp src dst eq 1433

  deny tcp src dst eq 1521

  deny tcp src dst eq 445

  deny tcp src dst eq 137

  deny tcp src dst eq 138

  deny tcp src dst eq 139

  deny udp src dst eq snmp

  deny tcp src dst eq telnet

  deny tcp src dst eq www

  deny tcp src dst eq 443

  deny tcp src dst eq 22

  deny tcp src dst eq pop3

  deny tcp src dst eq 123

  deny tcp match-all -ack +fin -psh -rst -syn -urg

  deny tcp match-all +fin +psh +urg

  permit tcp match-any +ack +syn

Collaboration SGACLs

• rbacl:Gateway_sig

  permit udp dst eq 5060 log

  permit tcp dst eq 5060 log

  permit tcp dst eq 5061 log

  permit udp dst range 32768 61000

  permit tcp dst range 32768 61000

  deny ip log

• rbacl:Intra_Jabber

  permit udp dst range 16384 32767 log

  permit tcp dst range 49152 65535 log

  permit tcp dest eq 37200 log

  deny ip log

• rbacl:Jabber_sig

  permit tcp dst eq 6970 log

  permit tcp dst eq 6972 log

  permit tcp dst eq 3804 log

  permit tcp dst eq 8443 log

  permit tcp dst eq 8191 log

  permit tcp dst eq 5222 log

  permit tcp dst eq 37200 log

  permit tcp dst eq 443 log

  permit tcp dst eq 2748 log

  permit tcp dst eq 5060 log

  permit tcp dst eq 5061 log

  permit tcp dst range 30000 39999 log

  permit udp dst range 5070 6070 log

  deny ip log

• rbacl:Phone_sig

  permit udp dst eq 69 log

  permit tcp dst eq 8080 log

  permit tcp dst eq 2445 log

  permit tcp dst eq 3804 log

  permit tcp dst eq 5060 log

  permit udp dst eq 5060 log

  permit tcp dst eq 5061 log

  permit tcp dst eq 6970 log

  deny ip log

• rbacl:UC_endpoint_media

  permit udp dst range 16384 32767 log

  deny ip log

Cisco TrustSec access control is implemented using ingress tagging and egress enforcement. At the ingress point to the Cisco TrustSec domain, the traffic from the source is tagged with an SGT containing the security group number of the source entity. The SGT is propagated across the domain with the traffic. At the egress point of the Cisco TrustSec domain, an egress device uses the source SGT (S-SGT) and the security group of the destination entity (D-SGT) to determine the access policy to apply from the SGACL policy matrix.

You can apply policy enforcement to both central and local switched traffic on an AP. If wired clients communicate with wireless clients, the Cisco AP enforces the downstream traffic. If wireless clients communicate with wired clients, the Cisco AP enforces the upstream traffic. This way, the Cisco AP enforces traffic in both downstream and wireless-to-wireless traffic. You require S-SGT, D-SGT, and ACLs for enforcement to work. Cisco APs get the SGT information for all wireless clients from the information available on the Cisco ISE server.

Note	A Cisco AP must be in either Listener or Both (Listener and Speaker) mode to enforce traffic as the Listener mode maintains the complete set of IP-SGT bindings. After you enable enforcement on a Cisco AP, the corresponding policies are downloaded and pushed to the Cisco AP.

The Allow Authentication, Authorization, Accouting (AAA) Override option of a WLAN enables you to configure the WLAN for authentication. It enables you to apply VLAN tagging, QoS, and ACLs to individual clients based on the returned RADIUS attributes from the AAA server.

AAA overrides for FlexConnect access points introduce a dynamic VLAN assignment for locally switched clients. AAA overrides for FlexConnect also support fast roaming (Opportunistic Key Caching [OKC]/ Cisco Centralized Key management [CCKM]) of overridden clients.

VLAN overrides for FlexConnect are applicable for both centrally and locally authenticated clients. VLANs can be configured on FlexConnect groups.

If a VLAN on the AP is configured using the WLAN-VLAN, the AP configuration of the corresponding ACL is applied. If the VLAN is configured using the FlexConnect group, the corresponding ACL configured on the FlexConnect group is applied. If the same VLAN is configured on the FlexConnect group and also on the AP, the AP configuration, with its ACL takes precedence. If there is no slot for a new VLAN from the WLAN-VLAN mapping, the latest configured FlexConnect group VLAN is replaced.

If the VLAN that was returned from the AAA is not present on the AP, the client falls back to the default VLAN configured for the WLAN.

Before configuring a AAA override, the VLAN must be created on the access points. These VLANs can be created by using the existing WLAN-VLAN mappings on the access points, or by using the FlexConnect group VLAN-ACL mappings.

When an access point boots up, it looks for a controller. If it finds one, it joins the controller, downloads the latest software image and configuration from the controller, and initializes the radio. It saves the downloaded configuration in nonvolatile memory for use in standalone mode.

Note	Once the access point is rebooted after downloading the latest controller software, it must be converted to the FlexConnect mode.

Note	802.1X is not supported on the AUX port for Cisco 2700 series APs.

A FlexConnect access point can learn the controller IP address in one of these ways:

• If the access point has been assigned an IP address from a DHCP server, it can discover a controller through the regular CAPWAP or LWAPP discovery process.

  Note	OTAP is not supported.

• If the access point has been assigned a static IP address, it can discover a controller through any of the discovery process methods except DHCP option 43. If the access point cannot discover a controller through Layer 3 broadcast, we recommend DNS resolution. With DNS, any access point with a static IP address that knows of a DNS server can find at least one controller.

• If you want the access point to discover a controller from a remote network where CAPWAP or LWAPP discovery mechanisms are not available, you can use priming. This method enables you to specify (through the access point CLI) the controller to which the access point is to connect.

When a FlexConnect access point can reach the controller (referred to as the connected mode), the controller assists in client authentication. When a FlexConnect access point cannot access the controller, the access point enters the standalone mode and authenticates clients by itself.

Note	The LEDs on the access point change as the device enters different FlexConnect modes. See the hardware installation guide for your access point for information on LED patterns.

When a client associates to a FlexConnect access point, the access point sends all authentication messages to the controller and either switches the client data packets locally (locally switched) or sends them to the controller (centrally switched), depending on the WLAN configuration. With respect to client authentication (open, shared, EAP, web authentication, and NAC) and data packets, the WLAN can be in any one of the following states depending on the configuration and state of controller connectivity:

• central authentication, central switching—In this state, the controller handles client authentication, and all client data is tunneled back to the controller. This state is valid only in connected mode.

• local authentication, local switching—In this state, the FlexConnect access point handles client authentication and switches client data packets locally. This state is valid in standalone mode and connected mode.

  In connected mode, the access point provides minimal information about the locally authenticated client to the controller. The following information is not available to the controller:

  • Policy type

  • Access VLAN

  • VLAN name

  • Supported rates

  • Encryption cipher

    Local authentication is useful where you cannot maintain a remote office setup of a minimum bandwidth of 128 kbps with the round-trip latency no greater than 100 ms and the maximum transmission unit (MTU) no smaller than 576 bytes. In local authentication, the authentication capabilities are present in the access point itself. Local authentication reduces the latency requirements of the branch office.

  • Notes about local authentication are as follows:

    • Guest authentication cannot be done on a FlexConnect local authentication-enabled WLAN.

    • Local RADIUS on the controller is not supported.

    • Once the client has been authenticated, roaming is only supported after the controller and the other FlexConnect access points in the group are updated with the client information.

• authentication down, switch down—In this state, the WLAN disassociates existing clients and stops sending beacon and probe requests. This state is valid in both standalone mode and connected mode.

• authentication down, local switching—In this state, the WLAN rejects any new clients trying to authenticate, but it continues sending beacon and probe responses to keep existing clients alive. This state is valid only in standalone mode.

When a FlexConnect access point enters standalone mode, WLANs that are configured for open, shared, WPA-PSK, or WPA2-PSK authentication enter the “local authentication, local switching” state and continue new client authentications. In controller software release 4.2 or later releases, this configuration is also correct for WLANs that are configured for 802.1X, WPA-802.1X, WPA2-802.1X, or Cisco Centralized Key Management, but these authentication types require that an external RADIUS server be configured. You can also configure a local RADIUS server on a FlexConnect access point to support 802.1X in a standalone mode or with local authentication.

Other WLANs enter either the “authentication down, switching down” state (if the WLAN was configured for central switching) or the “authentication down, local switching” state (if the WLAN was configured for local switching).

When FlexConnect access points are connected to the controller (rather than in standalone mode), the controller uses its primary RADIUS servers and accesses them in the order specified on the RADIUS Authentication Servers page or in the config radius auth add CLI command (unless the server order is overridden for a particular WLAN). However, to support 802.1X EAP authentication, FlexConnect access points in standalone mode need to have their own backup RADIUS server to authenticate clients.

Note	A controller does not use a backup RADIUS server. The controller uses the backup RADIUS server in local authentication mode.

You can configure a backup RADIUS server for individual FlexConnect access points in standalone mode by using the controller CLI or for groups of FlexConnect access points in standalone mode by using either the GUI or CLI. A backup server configured for an individual access point overrides the backup RADIUS server configuration for a FlexConnect.

When web-authentication is used on FlexConnect access points at a remote site, the clients get the IP address from the remote local subnet. To resolve the initial URL request, the DNS is accessible through the subnet's default gateway. In order for the controller to intercept and redirect the DNS query return packets, these packets must reach the controller at the data center through a CAPWAP connection. During the web-authentication process, the FlexConnect access points allows only DNS and DHCP messages; the access points forward the DNS reply messages to the controller before web-authentication for the client is complete. After web-authentication for the client is complete, all the traffic is switched locally.

Note

If your controller is configured for NAC, clients can associate only when the access point is in connected mode. When NAC is enabled, you need to create an unhealthy (or quarantined) VLAN so that the data traffic of any client that is assigned to this VLAN passes through the controller, even if the WLAN is configured for local switching. After a client is assigned to a quarantined VLAN, all of its data packets are centrally switched. See the Configuring Dynamic Interfaces section for information about creating quarantined VLANs and the Configuring NAC Out-of-Band section for information about configuring NAC out-of-band support.

When a FlexConnect access point enters into a standalone mode, the following occurs:

• The access point checks whether it is able to reach the default gateway via ARP. If so, it will continue to try and reach the controller.

If the access point fails to establish the ARP, the following occurs:

• The access point attempts to discover for five times and if it still cannot find the controller, it tries to renew the DHCP on the ethernet interface to get a new DHCP IP.

• The access point will retry for five times, and if that fails, the access point will renew the IP address of the interface again, this will happen for three attempts.

• If the three attempts fail, the access point will fall back to the static IP and will reboot (only if the access point is configured with a static IP).

• Reboot is done to remove the possibility of any unknown error the access point configuration.

Once the access point reestablishes a connection with the controller, it disassociates all clients, applies new configuration information from the controller, and allows client connectivity again.

The 802.11ac radio module for the Cisco Aironet 3600 Series access point and Cisco Aironet 3700 Series access point provides enterprise-class reliability and wired-network-like performance. It supports three spatial streams and up to 160 MHz-wide channels for a maximum data rate of 2.5 Gbps.

The 802.11ac radio in slot 2 is a subordinate radio for which you can configure specific parameters. Because the 802.11ac is a subordinate radio, it inherits many properties from the main 802.11a/n radio on slot 1. The parameters that you can configure for the 802.11ac radio are as follows:

• Admin status—Interface status of the radio that you can enable or disable. By default, the Admin status is in an enabled state. If you disable 802.11n, the 802.11ac radio is also disabled.

• Channel width—You can choose the RF channel width as 20 MHz, 40 MHz, 80 MHz, or 160 MHz. If you choose the channel width as 160 MHz, you must enable the 802.11ac mode on the High Throughput page.

  Note	The 11ac Supported field is a nonconfigurable parameter that appears for the 802.11ac subordinate radio in slot 2.

Note	When the Cisco Aironet 3600 Series access point with 802.11ac radio module is in unsupported mode such as Monitor and Sniffer, Admin Status and Channel Width will not be configured.

This section provides instructions to manage 802.11ac devices such as the Cisco Aironet 3600 Series Access Points and Cisco Aironet 3700 Series Access Point on your network.

Note

For the Cisco Aironet 3600 Series APs: With default AP group—Only WLAN IDs 1 to 8 are advertised on the 5-GHz radios; there is no limit on the 2.4-GHz radios. With user-defined AP group—Only the first 8 WLAN IDs are advertised on the 5-GHz radios regardless of the ID number; there is no limit on the 2.4-GHz radios.

Changing the 802.11n radio channel also changes the 802.11ac channels.

On the Cisco WLC GUI, the 802.11ac clients that are connected to the 802.11n radio are displayed 802.11an clients, and the 802.11ac clients that are connected to the 802.11ac radio are displayed as 802.11ac clients.

Ensure that your WLAN has WMM enabled and open or WPA2/AES for 802.11ac to be supported. Otherwise, the speed of 802.11ac is not available, even on 802.11ac clients.

For more information about the 802.11ac module on the Cisco Aironet 3600 Series access point, see http://www.cisco.com/c/en/us/products/wireless/aironet-3600-series/relevant-interfaces-and-modules.html.

The AP 1850 supports standards-based Explicit Compressed Beamforming Feedback (ECBF) as defined in the 802.11ac standards. With ECBF the client provides estimates of the wireless channel conditions to the access point. As these are based on explicit channel measurements from the client, both the AP and the client must support it. For 802.11ac, the access point’s ECBF is typically referred to as Transmit Beamforming or TxBF for short.

While both TxBF and ClientLink 3.0 improve the performance of wireless client devices, ClientLink3.0 provides an additional advantage over TxBF. ClientLink3.0 technology does not depend on any client-side hardware or software capabilities and operates seamlessly in mixed-mode environments where 802.11ac and 802.11a/n clients coexist on the same access point. In comparison, TxBF requires client-side support to take advantage of the performance improvements of beamforming and therefore benefits only 802.11ac clients that support TxBF.

The Cisco 1850 AP supports TxBF but not beamforming to legacy client devices. Therefore, Cisco 1850 AP does not support ClientLink 3.0.

Note	ClientLink 3.0 is supported on the Cisco Aironet 2700 and 3700 Series 802.11ac APs.

Note	You can disable TxBF only on the APs that support ClientLink 1.0. It cannot be disabled on the APs that supports ClientLink 2.0 and above.

Cisco Wireless Release 8.4 provides the Parallel Redundancy Protocol (PRP) enhancement to improve wireless network availability for wired clients behind Workgroup Bridge (WGB), and improve the roaming performance by allowing wired clients to have dual wireless connections.

PRP allows a data communication network to prevent data transmission failures by providing two alternate paths for the traffic to reach its destination. Two Ethernet networks (LANs) with similar topology are completely separated.

A device that requires protection for data across the network connects to the two independent networks (LAN-A and LAN-B) is called a Dual Attached Node implementing PRP (DANP). A DANP source sends two frames simultaneously on both LANs. A DANP destination receives both frames and discards the duplicating. If one LAN fails, a DANP destination can still receive a frame from the other LAN.

Non-redundant endpoints in the network that attach only to either LAN-A or LAN-B are known as Singly Attached Nodes (SANs). A Redundancy Box (RedBox) is used when a single interface node must be attached to both networks. Such a node can communicate with all other nodes. The switch implements RedBox functionality is a PRP switch.

To implement the PRP function for this release, you need to connect the AP and WGB to a PRP switch. The PRP switch is to offload PRP processing. AP or WGB is to keep dual wireless connections. You can have two WGBs interconnected through an external PRP switch and wirelessly connected to a single fixed AP or two fixed APs. Two WGBs can roaming between APs. Redundant packet transmissions can be supported over either single or both 2.4 GHz and 5 GHz. The infrastructure side also needs a PRP switch for AP side.

For the application where both WGBs may roam at the same time, the roaming coordination feature is introduced to avoid roaming gaps and guarantee staggered roaming. In this release, only dual radio links roaming coordination across two WGBs is supported for roaming coordination.

Supported platforms and AP mode:

• WLC and AP on the infrastructure side—FlexConnect AP mode (central authentication, local switching), the following IOS based platforms are supported: IW3702, 2700, 3700, and 1570 series.

• WGB on the client side—Only supported for IW3700 Series

• Roaming coordination—Only supported for IW3700 Series

General guidelines for this configuration:

• Separation of expected redundancy in the network:

  • Traffic expecting redundancy mapped to two reserved SSID A and SSID B each with specified VLAN.

  • Each WGB is configured to connect either SSID A or SSID B.

  • Others traffic without expectation of redundancy is recommended to be mapped to other SSID.

• WGB supports unified VLAN function and it is recommended that wired clients not to use VLANs assigned to SSID A or SSID B.

• Wired clients connected to WGB are source and recipients of redundancy traffic.

The following figure shows a topology of concurrent wireless transmission via two WGBs paired with one PRP switch, commonly used in train transportation.

On the train side, the PRP switch (in this example, Cisco IE2000U) duplicates upstream packets and sends both packets simultaneously via two different ports, Gi0/1 and Gi0/2. The dual packets will pass from different WGBs or APs, to ensure that at least one packet reaches the destination. On the track side, one more PRP switch is added to each aggregating endpoint along the track. The PRP switch on the track side will remove the duplicating for upstream packets. The same redundancy for downstream packet is also available by the pair of PRP switches.

Note	The throughput of this solution depends on the network elements depicted in the diagram. Each element along the wired and wireless transmission path should validate its throughput to avoid being the throughput bottleneck.

Figure 8. Concurrent Wireless Transmission via Two WGBs Paired With One PRP Switch

To enable or disable PRP on a WLAN (new command):

(Cisco Controller)> config wlan wgb prp {enable|disable} <wlan id> enable Enable Parallel Redundancy Protocol (PRP) feature on a WLAN disable Disable Parallel Redundancy Protocol (PRP) feature on a WLAN

Note	This feature is disabled by default.

This CLI will enable two WLANs to allow dual associations in flex-connect mode. It will also enable the AP to forward packets to or from WGB wired clients with double tags in flex-connect mode.

Note	To enable unified VLANs in the WGB, the existing command config wgb vlan enable should also be executed. You should configure the inner VLAN (VLAN for wired client) on WLC as well.

For Parallel Redundancy Protocol (PRP), wired client traffic will be duplicated to transmit in dual radio links in two WGBs. Dual radio links without any radio link coordination have the possibility to trigger roaming at the same time, so that the traffic will be broken in a short window time.

The following figure is a typical PRP scenario of train transportation. AP like IW3702 has two physical Ethernet ports. Gig0 will be exclusively used to bridge PRP traffic. Gig1 will be used for internal communication. Gig 1 will connect to a non-PRP port on the PRP switch or connect to a peer Gig1 port directly.

Figure 9. Peer Link Between Two WGBs

Note	For more information about WLC configuration for FlexConnect, see the FlexConnect Chapter in the Cisco Wireless Controller Configuration Guide.

Follow these steps to configure the wireless controller for FlexConnect:

1. Create two WLANs with the SSID PRP1 and PRP2.

2. Enable local switching for each WLAN.

Note	For any wired client within the service vlan, you need to create a corresponding dynamic interface with the same service vlan on WLC.

You can configure the controller to allow a Cisco Wave 1 (IOS-based) FlexConnect AP in standalone mode to perform LEAP, EAP-FAST, PEAP, or EAP-TLS authentication for up to 100 statically configured users. The controller sends the static list of usernames and passwords to each FlexConnect access point when it joins the controller. Each access point in the group authenticates only its own associated clients.

Note	This feature is not supported on Wave 2 and 802.11ax APs.

Note	If you want to enable FlexConnect local authentication, you have to enable FlexConnect AP Local Authentication in the Local Authentication tab. If the FlexConnect APs act as an 802.11X authenticator (RADIUS client), then configure the RADIUS servers in the General tab.

This feature is ideal for customers who are migrating from an autonomous access point network to a lightweight FlexConnect access point network and are not interested in maintaining a large user database or adding another hardware device to replace the RADIUS server functionality available in the autonomous access point.

Note	You can configure LEAP, EAP-FAST, PEAP, or EAP-TLS authentication only if AP local authentication is enabled.

You have to provision a certificate to the AP because the AP has to send the certificate to the client. You must download the Vendor Device Certificate and the Vendor Certification Authority Certificate to the controller. The controller then pushes these certificates to the AP. If you do not configure a Vendor Device Certificate and the Vendor CA Certificate on the controller, the APs associating with the FlexConnect group download the self-signed certificate of the controller, which may not be recognized by many wireless clients.

With EAP-TLS, AP does not recognize and accept client certificate if the client root CA is different from the AP root CA. When you use Enterprise public key infrastructures (PKI), you must download a Vendor Device Certificate and Vendor CA Certificate to the controller so that the controller can push the certificates to the AP in the FlexConnect group. Without a common client and AP root CA, EAP-TLS fails on the local AP. The AP cannot check an external CA and relies on its own CA chain for client certificate validation.

The space on the AP for the local certificate and the CA certificate is around 7 Kb, which means that only short chains are adapted. Longer chains or multiple chains are not supported.

Note

This feature can be used with the FlexConnect backup RADIUS server feature. If a FlexConnect is configured with both a backup RADIUS server and local authentication, the FlexConnect access point always attempts to authenticate clients using the primary backup RADIUS server first, followed by the secondary backup RADIUS server (if the primary is not reachable), and finally the FlexConnect access point itself (if the primary and secondary are not reachable).

For information about the number of FlexConnect groups and access point support for a Cisco WLC model, see the data sheet of the respective Cisco WLC model.

Band select enables client radios that are capable of dual-band (2.4 and 5-GHz) operations to move to a less congested 5-GHz access point. The 2.4-GHz band is often congested. Clients on this band typically experience interference from Bluetooth devices, microwave ovens, and cordless phones as well as co-channel interference from other access points because of the 802.11b/g limit of 3 nonoverlapping channels. To prevent these sources of interference and improve overall network performance, configure band selection on the controller.

Band select works by regulating probe responses to clients and it can be enabled on a per-WLAN basis. It makes 5-GHz channels more attractive to clients by delaying probe responses to clients on 2.4-GHz channels. In an access point, the band select table can be viewed by running the show dot11 band-select command. It can also be viewed by running the show cont d0/d1 | begin Lru command.