Mesh networking employs Cisco Aironet outdoor mesh access points and indoor mesh access points along with Cisco Wireless Controller and Cisco Prime Infrastructure to provide scalability, central management, and mobility between indoor and outdoor deployments. Control and Provisioning of Wireless Access Points (CAPWAP) protocol manages the connection of mesh access points to the network.

End-to-end security within the mesh network is supported by employing Advanced Encryption Standard (AES) encryption between wireless mesh access points and Wi-Fi Protected Access 2 (WPA2) clients. For connections to a mesh access point (MAP) wireless client, such as MAP-to-MAP and MAP-to-root access point, WPA2 is applicable.

The wireless mesh terminates on two points on the wired network. The first location is where the root access point (RAP) is attached to the wired network, and where all bridged traffic connects to the wired network. The second location is where the CAPWAP controller connect to the wired network; this location is where the WLAN client traffic from the mesh network is connected to the wired network. The WLAN client traffic from CAPWAP is tunneled to Layer 2. Matching WLANs should terminate on the same switch VLAN on which the wireless controllers are co-located. The security and network configuration for each of the WLANs on the mesh depend on the security capabilities of the network to which the wireless controller is connected.

In the new configuration model, the controller has a default mesh profile. This profile is mapped to the default AP-join profile, which is in turn is mapped to the default site tag. If you are creating a named mesh profile, ensure that these mappings are put in place, and the corresponding AP is added to the corresponding site-tag.

Important

The following are the mesh supported scenarios in IRCM from Cisco IOS XE Amsterdam 17.3 release up to Cisco IOS XE Cupertino 17.9 release, for the Cisco Wave 1 APs that are not supported: Cisco Wave 1 APs are not supported in the releases post Cisco IOS XE Amsterdam 17.3. This includes mesh support as well. Therefore, it is not possible for a Cisco Wave 1 AP to join a Cisco Catalyst 9800 Series Wireless Controller (controller) with Cisco IOS XE Amsterdam 17.4 and later versions. We recommend the following deployment mode for Cisco Wave 1 APs. In the case of Cisco mesh deployments, the following are the deployment limitations to be aware of, when the system is deployed: MAP roaming is not allowed between Cisco Catalyst 9800 Series Wireless Controllers, if the controllers run different Cisco IOS XE versions (running on versions Cisco IOS XE Amsterdam 17.3 or Cisco IOS XE Cupertino 17.9) for any of the Cisco Wave 1 APs and Cisco Wave 2 APs. You cannot have Cisco Wave 1 APs and Cisco Catalyst 9124 Series APs in the same mesh tree, in the releases post Cisco IOS XE Amsterdam 17.3.x. This can be achieved in 17.3.x, beginning from the 17.3.6 (upcoming) release. The whole mesh tree containing Cisco Wave 1 APs must be joined to the 17.3 controller, by running the strict-bgn and mac filtering commands. Note The limitations mentioned above are not valid for the Cisco Industrial Wireless 3702 Series Access Points, which are supported until the Cisco IOS XE Cupertino 17.9 release.

Cisco Catalyst 9130AXE Access Points support Serial Backhaul with omni antenna using dart connectors.Cisco Catalyst 9130AXI APs supports Serial Backhaul, as the second 5-GHz radio is for macro and micro cell (the transmission power of the second 5-GHz radio cannot be changed).

The Mesh feature is supported only on the following AP platforms:

• Outdoor APs

  • Cisco Industrial Wireless 3702 Access Points (supported from Cisco IOS XE Gibraltar 16.11.1b).

  • Cisco Aironet 1542 Access Points

  • Cisco Aironet 1562 Access Points

  • Cisco Aironet 1572 Access Points

  • Cisco Catalyst IW6300 Heavy Duty Access Points

  • Cisco 6300 Series Embedded Services Access Points

  • Cisco Catalyst 9124AX Series Outdoor Access Points

  • Cisco Catalyst IW9167 Series Heavy Duty Access Points

• Indoor APs

  • Cisco Aironet 1815i Access Points

  • Cisco Aironet 1815m Access Points

  • Cisco Aironet 1815w Access Points

  • Cisco Aironet 1832i Access Points

  • Cisco Aironet 1852i Access Points

  • Cisco Aironet 1852e Access Points

  • Cisco Aironet 2802i Access Points

  • Cisco Aironet 2802e Access Points

  • Cisco Aironet 3802i Access Points

  • Cisco Aironet 3802e Access Points

  • Cisco Aironet 3802p Access Points

  • Cisco Aironet 4800 Access Points

  • Cisco Catalyst 9130AX (I/E) Access Points

The following mesh features are not supported:

• Serial backhaul AP support with separate backhaul radios for uplink and downlink.

• Public Safety channels (4.9-GHz band) support.

• Passive Beaconing (Anti-Stranding)

Note

Only Root APs support SSO. MAPs will disconnect and rejoin after SSO. The AP Stateful Switch Over (SSO) feature allows the access point (AP) to establish a CAPWAP tunnel with the Active controller and share a mirror copy of the AP database with the Standby controller. The overall goal for the addition of AP SSO support to the controller is to reduce major downtime in wireless networks due to failure conditions that may occur due to box failover or network failover. In a mixed regulatory domain mesh AP deployment, ensure that the Dynamic Channel Assignment (DCA) allowed channel list is supported by MAPs. When you disable the admin state on the 2.4-GHz radio of mesh APs, and the root AP (RAP) backhaul radio is switched to 2.4-GHz, RAP will still use 2.4-GHz radio to serve the mesh backhaul connections, inspite of 2.4-GHz radio being in the disabled state.

You must enter the MAC address of an AP in the controller to make a MAP join the controller. The controller responds only to those CAPWAP requests from MAPs that are available in its authorization list. Remember to use the MAC address provided at the back of the AP.

MAC authorization for MAPs connected to the controller over Ethernet occurs during the CAPWAP join process. For MAPs that join the controller over radio, MAC authorization takes place when the corresponding AP tries to secure an adaptive wireless path protocol (AWPP) link with the parent MAP. The AWPP is the protocol used in Cisco mesh networks.

The Cisco Catalyst 9800 Series Wireless Controller supports MAC authorization internally as well as using an external AAA server.

Customers with mesh deployments can see their MAPs moving out of their network and joining another mesh network when both these mesh deployments use AAA with wild card MAC filtering to allow the association of MAPs. Since MAPs might use EAP-FAST, this cannot be controlled because a security combination of MAC address and type of AP is used for EAP, and no controlled configuration is available. The preshared key (PSK) option with a default passphrase also presents a security risk.

This issue is prominently seen in overlapping deployments of two service providers when the MAPs are used in a moving vehicle (public transportation, ferry, ship, and so on.). This way, there is no restriction on MAPs to remain with the service providers' mesh network, and MAPs can get hijacked or getting used by another service provider's network and cannot serve the intended customers of the original service providers in the deployment.

The PSK key provisioning feature enables a PSK functionality from the controller which helps make a controlled mesh deployment and enhance MAPs security beyond the default one. With this feature the MAPs that are configured with a custom PSK, will use the PSK key to do their authentication with their RAPs and controller.

Local EAP is an authentication method that allows users and wireless clients to be authenticated locally on the controller. It is designed for use in remote offices that want to maintain connectivity with wireless clients when the backend system gets disrupted or the external authentication server goes down. When you enable local EAP, the controller serves as the authentication server and the local user database, which in turn, removes dependence on an external authentication server. Local EAP retrieves user credentials from the local user database or the LDAP backend database to authenticate users. Local EAP supports only the EAP-FAST authentication method for MAP authentication between the controller and wireless clients.

Local EAP uses an LDAP server as its backend database to retrieve user credentials for MAP authentication between the controller and wireless clients. An LDAP backend database allows the controller to query an LDAP server for the credentials (username and password) of a particular user. These credentials are then used to authenticate the user.

Note	If RADIUS servers are configured on the controller, the controller tries to authenticate the wireless clients using the RADIUS servers first. Local EAP is attempted only if RADIUS servers are not found, timed out, or were not configured.

Bridge group names (BGNs) control the association of MAPs to the parent mesh AP. BGNs can logically group radios to avoid two networks on the same channel from communicating with each other. The setting is also useful if you have more than one RAP in your network in the same sector (area). BGN is a string comprising a maximum of 10 characters.

A BGN of NULL VALUE is assigned by default during manufacturing. Although not visible to you, it allows a MAP to join the network prior to your assignment of your network-specific BGN.

If you have two RAPs in your network in the same sector (for more capacity), we recommend that you configure the two RAPs with the same BGN, but on different channels.

When Strict Match BGN is enabled on a MAP, it will scan ten times to find a matching BGN parent. After ten scans, if the AP does not find the parent with matching BGN, it will connect to the nonmatched BGN and maintain the connection for 15 minutes. After 15 minutes, the AP will again scan ten times, and this cycle continues. The default BGN functionalities remain the same when Strict Match BGN is enabled.

In Cisco Catalyst 9800 Series Wireless Controller, the BGN is configured on the mesh profile. Whenever a MAP joins the controller, the controller pushes the BGN that is configured on the mesh profile to the AP.

Mesh background scanning improves convergence time, and reliability and stability of parent selection. With the help of the Background Scanning feature, a MAP can find and connect with a better potential parent across channels, and maintain its uplink with the appropriate parent all the time.

When background scanning is disabled, a MAP has to scan all the channels of the regulatory domain after detecting a parent loss in order to find a new parent and go through the authentication process. This delays the time taken for the mesh AP to connect back to the controller.

When background scanning is enabled, a MAP can avoid scanning across the channels to find a parent after detecting a parent loss, and select a parent from the neighbor list and establish the AWPP link.

Cisco mesh access points (MAPs) are interconnected over wireless links in a tree topology. A MAP that is connected to a network through the Ethernet uplink is the root MAP, which is also known as a root access point (RAP). Adaptive Wireless Path Protocol (AWPP) is used to form the tree topology and maintain that topology. When a MAP comes up, it tries to look for another MAP (parent) to join and reach the gateway through a RAP. The same happens when a MAP loses connectivity with its existing parent. This procedure is known as mesh tree convergence.

A child MAP maintains uplink with its parent using the AWPP adjacency request/response messages that act as keepalive. If there is a consecutive loss of response messages, a parent is declared to be lost and the child MAP tries to find a new parent. A MAP maintains a list of neighbors of the current ON channel, and when the AP loses its current parent, it roams to the next best potential neighbor. If no other neighbors are found, the AP scans or seeks across all the channels or subset channels to find a parent. This is time consuming.

With the help of the Background Scanning feature, the AP avoids searching for a parent across the channel set by scanning or seeking. This feature helps the child MAP to be updated about its neighbors across all the channels, helps to switch to a neighbor of any channel, and uses that neighbor as its next parent for uplink.

Background scanning allows MAPs to save time during the scan-and-seek phase while looking for a new parent, but it does not save time on the authentication to the parent.

Enabling the MAP Fast Ancestor Finding feature enables a novel method to reduce the need for sending or receiving beacons at the network formation, while starting or deploying a new mesh network.

Note

The Background Scanning and MAP Fast Ancestor Finding feature support in Cisco IOS XE Dublin 17.11.1, is not compatible with the legacy Background Scanning feature that is supported in the Cisco Wave 1 APs. When you enable Background Scanning on the APs that are not equipped with RHL radio, a performance penalty is imposed in terms of the bandwidth available in the backhaul. This performance penalty is high at system startup and lower after the system reaches the steady-state.

A backhaul is used to create only the wireless connection between MAPs. The backhaul interface is 802.11a/n/ac/g depending upon the AP. The default backhaul interface is 5-GHz. The rate selection is important for effective use of the available radio frequency spectrum. The rate can also affect the throughput of client devices. (Throughput is an important metric used by industry publications to evaluate vendor devices.)

Mesh backhaul is supported at 2.4-GHz and 5-GHz. However, in certain countries it is not allowed to use mesh network with a 5-GHz backhaul network. The 2.4-GHz radio frequencies allow you to achieve much larger mesh or bridge distances. When a RAP gets a slot-change configuration, it gets propagated from the RAP to all its child MAPs. All the MAPs get disconnected and join the new configured backhaul slot.

This section provides information about mesh backhaul at 2.4-GHz. By default, the backhaul interface for mesh APs is 802.11a/ac/ax. Certain countries do not allow the use of mesh network with a 5-GHz backhaul network. Even in countries where 5-GHz is permitted, we recommend that you use 2.4-GHz radio frequencies to achieve much larger mesh or bridge distances.

The Mesh backhaul at 2.4-GHz is supported on the following access points:

• Cisco Catalyst 9124AX Series Outdoor Access Point

• Cisco Aironet 1540 Series Outdoor Access Points

• Cisco Aironet 1542D Outdoor Access Points

• Cisco Aironet 1562D Outdoor Access Points

• Cisco Aironet 1562E Outdoor Access Points

• Cisco Aironet 1562I Outdoor Access Points

• Cisco Aironet 1562PS Access Points

• Cisco Aironet 1570 Series Outdoor Access Points

• Cisco Aironet 1815i Access Points

• Cisco Aironet 1815m Series Access Point

• Cisco Aironet 1830 Series Access Points

• Cisco Aironet 1850 Series Access Points

• Cisco Aironet 2800e Access Points

• Cisco Aironet 2800i Access Points

• Cisco Aironet 3800 Series Access Points

• Cisco Aironet 4800 Access Points

• Cisco Catalyst IW6300 DC Heavy Duty Access Point

• Cisco Catalyst IW6300 DCW Heavy Duty Access Point

• Cisco Catalyst IW6300 Series Heavy Duty Access Points

• Cisco 6300 Series Embedded Services Access Points

Note	In Israel, you must ensure that you run the ap country IO command to enable the outdoor country code for the selected radio. After you configure using the ap country IO command, the 2.4-GHz radio is enabled and 5-GHz radio is disabled.

The Mesh Serial Backhaul feature in a mesh access point (MAP), allows different channels for uplink and downlink access, thus improving backhaul bandwidth and extending universal access. One radio is used as the uplink radio and a different one is used as the downlink radio. This allows the in-bound and out-bound traffic to flow through exclusive communication channels, thereby improving performance and avoiding problems associated with a shared access medium.

The Mesh Serial Backhaul feature is supported in the controller from Cisco IOS XE Cupertino 17.7.1 onwards, for Cisco Catalyst 9124AXE outdoor APs. A new knob is introduced under the radio profile, and that radio profile is associated with a radio frequency (RF) tag to enable the Mesh Serial Backhaul feature. When you enable this feature, the mesh configuration is shared by all the APs that share the same mesh profile. Radio configuration is shared by all the APs that are configured with the same radio profile.

Basic client access functionality is offered on the 2.4-GHz radio and the 5-GHz radio, which are not used in serial backhaul. Universal access is made available on the downlink radio.

Note	Slot 1 and slot 0 are supported as mesh backhaul. Slot 2 is not supported as a mesh backhaul. You can utilize slot 2 for client serving or for serial backhaul downlink.

Channel Assignment

For the Mesh Serial Backhaul feature, channels are assigned according to the following rules:

• Uplink and downlink channels are different.

• All the 5-GHz radios maintain a frequency guard between their operating channels. For example, 100-MHz channel spacing between radios in Cisco Catalyst 9124AXE outdoor APs.

• Dynamic Frequency Selection (DFS) channels are supported.

In a root access point, because the uplink is wired, channels are assigned by the controller. On the other hand, a mesh access point uses the last channel configured by the controller for this radio, or uses the default channel. If the channel used by MAP is not compatible with the uplink, MAP picks a valid random channel and notifies the controller. In another scenario, MAP randomly picks a new downlink channel when it receives a channel change alert on the uplink radio. MAP checks the validity of the downlink radio and picks a random channel if the current channel is not compatible.

Note	Ensure that the following prerequisites are met before channel assignment: Enable tri-radio globally by running the Device# ap tri-radio command. Enable the dual radio on the APs by running the Device# ap name ap-name dot11 5ghz dual-radio mode enable command.

Root access points (RAPs) choose backhaul channels to operate in mesh networks. Until Cisco IOS XE Cupertino 17.8.1, this operation occurred by an explicit configuration, a least congested scan during RAP boot time, during the initial radio resource management (RRM) run without mesh access points (MAPs) connected, or a backhaul channel that was chosen at random. As a result, a poor backhaul channel selection resulted in poor performance.

From Cisco IOS XE Cupertino 17.9.1 onwards, RRM DCA is run on mesh backhaul, in auto mode, in FlexConnect or centralized networks. For APs that do not have dedicated (RHL) radios, DCA is triggered by running commands in the privilege EXEC mode.

RRM continuously evaluates the channel conditions to ensure that the network utilizes the least congested channels. The network uses the transmission static power if it is configured, or falls back to the default level. This is supported on APs that have dedicated radios to scan channel conditions, without any user perceptible interruption to the mesh network traffic.

In the mesh backhaul RRM feature, the RRM DCA decides all the downlink channels in a steady network. However, if an AP detects a change in its uplink roam or radar detection response, the AP chooses the best downlink to converge faster.

Note	APs choosing the best possible downlink is limited to serial backhaul enabled APs only.

To avoid a poor channel backhaul selection, from Cisco IOS XE Dublin 17.14.1 onwards, the RRM DCA optimizes the RAP backhaul radio channel of a mesh subtree by considering the noise, interference, load, and the RF parameter measurements only from the RAP. The RRM DCA on Mesh Backhaul feature enables DCA to make better channel assignment for a mesh subtree, by having continuous measurements and inputs from the whole mesh tree required to run DCA.

To enable RRM DCA on a full mesh tree run the wireless mesh backhaul rrm auto-dca command. To trigger DCA once, run the ap dot11 [5ghz | 2.4 ghz] rrm channel-update mesh command.

To understand what happened during a DCA run on the mesh backhaul, use the show wireless mesh rrm dca status and show wireless mesh rrm dca changed commands.

Note

In a topology with mixed APs (RF ASIC capable and non-capable APs), only inputs from the RF ASIC capable APs apply for auto-dca. All mesh APs in a subtree should be configured to belong to the same site-tag for DCA to work properly. This feature is limited to RF ASIC capable APs, such as Cisco Catalyst 9124 Series APs and Cisco Catalyst 9130 Series APs.

To protect the existing radar services, the regulatory bodies require that devices that have to share the newly opened frequency sub-band behave in accordance with the Dynamic Frequency Selection (DFS) protocol. DFS dictates that in order to be compliant, a radio device must be capable of detecting the presence of radar signals. When a radio detects a radar signal, the radio should stop transmitting for at least 30 minutes to protect that service. The radio should then select a different channel to transmit on, but only after monitoring it. If no radar is detected on the projected channel for at least one minute, the new radio service device can begin transmissions on that channel. The DFS feature allows mesh APs to immediately switch channels when a radar event is detected in any of the mesh APs in a sector.

Controllers and APs are designed for use in many countries having varying regulatory requirements. The radios within the APs are assigned to a specific regulatory domain at the factory (such as -E for Europe), but the country code enables you to specify a particular country of operation (such as FR for France or ES for Spain). Configuring a country code ensures that each radio’s broadcast frequency bands, interfaces, channels, and transmit power levels are compliant with country-specific regulations.

In certain countries, there is a difference in the following for indoor and outdoor APs:

• Regulatory domain code

• Set of channels supported

• Transmit power level

The Cisco Intrusion Detection System/Intrusion Prevention System (CIDS/CIPS) instructs controllers to block certain clients from accessing a wireless network when attacks involving these clients are detected in Layer 3 through Layer 7. This system offers significant network protection by helping to detect, classify, and stop threats, including worms, spyware or adware, network viruses, and application abuse.

Interoperability can be maintained between AireOS and the Cisco Catalyst 9800 Series Wireless Controller with the following support:

• MAPs can join an AireOS controller through a mesh network formed by APs connected to a Cisco Catalyst 9800 Series Wireless Controller.

• MAPs can join a Cisco Catalyst 9800 Series Wireless Controller through a mesh network formed by APs connected to as AireOS controller.

• MAP roaming is supported between parent mesh APs connected to AireOS and the Cisco Catalyst 9800 Series Wireless Controller by using PMK cache.

Note	For seamless interoperability, AireOS controller and the Cisco Catalyst 9800 Series Wireless Controller should be in the same mobility group and use the image versions that support IRCM.

Note	This feature is applicable for Cisco Aironet 1542 series outdoor access points only.

The access points associated to a mesh network can play one of the two roles:

• Root Access Point (RAP) - An access point can be a root access point for multiple mesh networks.

• Mesh Access Point (MAP) - An access point can be a mesh access point for only one single mesh network at a time.

Mesh convergence allows MAPs to reestablish connection with the controller, when it loses backhaul connection with the current parent. To improve the convergence time, each mesh AP maintains a subset of channels that is used for future scan-seek and to identify a parent in the neighbor list subset.

The following convergence methods are supported.

For security reasons, the Ethernet port on all the MAPs are disabled by default. They can be enabled only by configuring Ethernet bridging on the root and its respective MAP.

Both tagged and untagged packets are supported on secondary Ethernet interfaces.

In a point-to-point bridging scenario, a Cisco Aironet 1500 Series MAP can be used to extend a remote network by using the backhaul radio to bridge multiple segments of a switched network. This is fundamentally a wireless mesh network with one MAP and no WLAN clients. Just as in point-to-multipoint networks, client access can still be provided with Ethernet bridging enabled, although if bridging between buildings, MAP coverage from a high rooftop might not be suitable for client access. To use an Ethernet-bridged application, enable the bridging feature on the RAP and on all the MAPs in that sector.

Ethernet bridging should be enabled for the following scenarios:

• Use mesh nodes as bridges.

• Connect Ethernet devices, such as a video camera on a MAP using its Ethernet port.

Note	Ensure that Ethernet bridging is enabled for every parent mesh AP taking the path from the mesh AP to the controller.

In a mesh environment with VLAN support for Ethernet bridging, the secondary Ethernet interfaces on MAPs are assigned a VLAN individually from the controller. All the backhaul bridge links, both wired and wireless, are trunk links with all the VLANs enabled. Non-Ethernet bridged traffic, as well as untagged Ethernet bridged traffic travels along the mesh using the native VLAN of the APs in the mesh. It is similar for all the traffic to and from the wireless clients that the APs are servicing. The VLAN-tagged packets are tunneled through AWPP over wireless backhaul links.

Mesh multicast modes determine how bridging-enabled APs such as MAP and RAP, send multicast packets among Ethernet LANs within a mesh network. Mesh multicast modes manage only non-CAPWAP multicast traffic. CAPWAP multicast traffic is governed by a different mechanism.

Three different mesh multicast modes are available to manage multicast and broadcast packets on all MAPs. When enabled, these modes reduce unnecessary multicast transmissions within the mesh network and conserve backhaul bandwidth.

The three mesh multicast modes are:

• Regular mode: Data is multicast across the entire mesh network and all its segments by bridging-enabled RAP and MAP.

• In-only mode: Multicast packets received from the Ethernet by a MAP are forwarded to the corresponding RAP’s Ethernet network. No additional forwarding occurs, which ensures that non-CAPWAP multicasts received by the RAP are not sent back to the MAP Ethernet networks within the mesh network (their point of origin), and MAP to MAP multicasts do not occur because such multicasts are filtered out.

• In-out mode: The RAP and MAP both multicast but in a different manner.

  • If multicast packets are received at a MAP over Ethernet, they are sent to the RAP; however, they are not sent to other MAP over Ethernet, and the MAP-to-MAP packets are filtered out of the multicast.

  • If multicast packets are received at a RAP over Ethernet, they are sent to all the MAPs and their respective Ethernet networks. When the in-out mode is in operation, it is important to properly partition your network to ensure that a multicast sent by one RAP is not received by another RAP on the same Ethernet segment and then sent back into the network.

The Radio Resource Management (RRM) software embedded in the controller acts as a built-in RF engineer to consistently provide real-time RF management of your wireless network. RRM enables the controller to continually monitor the associated lightweight APs for information on traffic load, interference, noise, coverage, and other nearby APs:

The RRM measurement in the mesh AP backhaul is enabled based on the following conditions:

• Mesh AP has the Root AP role.

• Root AP has joined using Ethernet link.

• Root AP is not serving any child AP.

The Air Time Fairness (ATF) on Mesh feature is conceptually similar to the ATF feature for local access points (APs). ATF is a form of wireless quality of service (QoS) that regulates downlink airtime (as opposed to egress bandwidth). Before a frame is transmitted, the ATF budget for that SSID is checked to ensure that there is sufficient airtime budget to transmit the frame. Each SSID can be thought of as having a token bucket (1 token = 1 microsecond of airtime). If the token bucket contains enough airtime to transmit the frame, it is transmitted over air. Otherwise, the frame can either be dropped or deferred. Deferring a frame means that the frame is not admitted into the Access Category Queue (ACQ). Instead, it remains in the Client Priority Queue (CPQ) and transmitted at a later time when the corresponding token bucket contains a sufficient number of tokens (unless the CPQ reaches full capacity, at which point, the frame is dropped). The majority of the work involved in the context of ATF takes place on the APs. The wireless controller is used to configure the ATF on Mesh and display the results.

In a mesh architecture, the mesh APs (parent and child MAPs) in a mesh tree access the same channel on the backhaul radio for mesh connectivity between parent and child MAPs. The root AP is connected by wire to the controller, and MAPs are connected wirelessly to the controller. Hence, all the CAPWAP and Wi-Fi traffic are bridged to the controller through the wireless backhaul radio and through RAP. In terms of physical locations, normally, RAPs are placed at the roof top and MAPs in multiple hops are placed some distance apart from each other based on the mesh network segmentation guidelines. Hence, each MAP in a mesh tree can provide 100 percent of its own radio airtime downstream to its users though each MAP accessing the same medium. Compare this to a non-mesh scenario, where neighboring local-mode unified APs in the arena next to each other in different rooms, serving their respective clients on the same channel, and each AP providing 100% radio airtime downstream. ATF has no control over clients from two different neighboring APs accessing the same medium. Similarly, it is applicable for MAPs in a mesh tree.

For outdoor or indoor mesh APs, ATF must be supported on client access radios that serve regular clients similarly to how it is supported on ATF on non-mesh unified local mode APs to serve the clients. Additionally, it must also be supported on backhaul radios which bridge the traffic to/from the clients on client access radios to RAPs (one hop) or through MAPs to RAPs (multiple hops). It is a bit tricky to support ATF on the backhaul radios using the same SSID/Policy/Weight/Client fair-sharing model. Backhaul radios do not have SSIDs and it always bridge traffic through their hidden backhaul nodes. Therefore, on the backhaul radios in a RAP or a MAP, the radio airtime downstream is shared equally, based on the number of backhaul nodes. This approach provides fairness to users across a wireless mesh network, where clients associated to second-hop MAP can stall the clients associated to first-hop MAP where second-hop MAP is connected wireless to first-hop MAP through backhaul radio even though the Wi-Fi users in the MAPs are separated by a physical location. In a scenario where a backhaul radio has an option to serve normal clients through universal client access feature, ATF places the regular clients into a single node and groups them. It also enforces the airtime by equally sharing the radio airtime downstream, based on the number of nodes (backhaul nodes plus a single node for regular clients).

The Spectrum Intelligence feature scans for non-Wi-Fi radio interference on 2.4-GHz and 5-GHz bands. The feature supports client serving mode and monitor mode. The Cisco CleanAir technology in mesh backhaul and access radios provides an Interference Device Report (IDR) and Air Quality Index (AQI). Two key mitigation features (Event-Driven Radio Resource Management [EDRRM] and Persistence Device Avoidance [PDA]) are present in CleanAir. Both rely directly on information that can only be gathered by CleanAir. In the client-access radio band, they work the same way in mesh networks as they do in non-mesh networks in the backhaul radio band, the CleanAir reports are only displayed on the controller. No action is taken through ED-RRM.

Note that no specific configuration options are available to enable or disable CleanAir for MAPs.

For more information about Spectrum Intelligence, see section.

Interoperability of indoor MAPs with outdoor APs are supported. This helps to bring coverage from outdoors to indoors. However, we recommend that you use indoor MAPs for indoor use only, and deploy them outdoors only under limited circumstances such as a simple short-haul extension from an indoor WLAN to a hop in a parking lot.

Mobility groups can be shared between outdoor mesh networks and indoor WLAN networks. It is also possible for a single controller to control indoor and outdoor MAPs simultaneously. Not that the same WLANs are broadcast out of both indoor and outdoor MAPs.

A workgroup bridge (WGB) is used to connect wired networks over a single wireless segment by informing the corresponding MAP 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 (four MAC headers, versus the normal three 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 a packet to and from the corresponding clients.

APs can be configured as workgroup bridges. Only one radio interface is used for controller connectivity, Ethernet interface for wired client connectivity, and other radio interface for wireless client connectivity.

In Cisco Catalyst 9800 Series Wireless Controller, WGB acts as a client association, with the wired clients behind WGB supported for data traffic over the mesh network. Wired clients with different VLANs behind WGB are also supported.

A link test is used to determine the quality of the radio link between two devices. Two types of link-test packets are transmitted during a link test: request and response. Any radio receiving a link-test request packet fills in the appropriate text boxes and echoes the packet back to the sender with the response type set.

The radio link quality in the client-to-access point direction can differ from that in the access point-to-client direction due to the asymmetrical distribution of the transmit power and receive sensitivity on both sides. Two types of link tests can be performed: a ping test and a CCX link test.

With the ping link test, the controller can test link quality only in the client-to-access point direction. The RF parameters of the ping reply packets received by the access point are polled by the controller to determine the client-to-access point link quality.

With the CCX link test, the controller can also test the link quality in the access point-to-client direction. The controller issues link-test requests to the client, and the client records the RF parameters (received signal strength indicator [RSSI], signal-to-noise ratio [SNR], and so on). of the received request packet in the response packet. Both the link-test requestor and responder roles are implemented on the access point and controller. Not only can the access point or controller initiate a link test to a CCX v4 or v5 client, but a CCX v4 or v5 client can initiate a link test to the access point or controller.

Mesh APs have the capability to daisy chain APs when they function as MAPs. The daisy chained MAPs can either operate the APs as a serial backhaul, allowing different channels for uplink and downlink access, thus improving backhaul bandwidth, or extend universal access. Extending universal access allows you to connect a local mode or FlexConnect mode Mesh AP to the Ethernet port of a MAP, thus extending the network to provide better client access.

Daisy chained APs must be cabled differently depending on how the APs are powered. If an AP is powered using DC power, an Ethernet cable must be connected directly from the LAN port of the Primary AP to the PoE in a port of the Subordinate AP.

The following are the guidelines for the daisy chaining mode:

• Primary MAP should be configured as mesh AP.

• Subordinate MAP should be configured as root AP.

• Daisy chaining should be enabled on both primary and subordinate MAP.

• Ethernet bridging should be enabled on all the APs in the Bridge mode. Enable Ethernet bridging in the mesh profile and map all the bridge mode APs in the sector to the same mesh profile.

• VLAN support should be enabled on the wired root AP, subordinate MAP, and primary MAP along with proper native VLAN configuration.

You can configure a MAP with lower performance to work only as a leaf node. When the mesh network is formed and converged, the leaf node can only work as a child MAP, and cannot be selected by other MAPs as a parent MAP, thus ensuring that the wireless backhaul performance is not downgraded.

Flex+Bridge mode is used to enable FlexConnect capabilities on mesh (bridge mode) APs. Mesh APs inherit VLANs from the root AP that is connected to it.

Any EWC capable AP in Flex mode connected to a MAP, should be in CAPWAP mode (AP-type CAPWAP).

You can enable or disable VLAN trunking and configure a native VLAN ID on each AP for any of the following modes:

• FlexConnect

• Flex+Bridge (FlexConnect+Mesh)

When Backhaul Client Access is enabled, it allows wireless client association over the backhaul radio. The backhaul radio can be a 2.4-GHz or 5-GHz radio. This means that a backhaul radio can carry both backhaul traffic and client traffic.

When Backhaul Client Access is disabled, only backhaul traffic is sent over the backhaul radio, and client association is performed only over the access radio.

Note	Backhaul Client Access is disabled by default. After the Backhaul Client Access is enabled, all the MAPs, except subordinate AP and its child APs in daisy-chained deployment, reboot.

The Call Admission Control (CAC) enables a mesh access point to maintain controlled quality of service (QoS) on the controller to manage voice quality on the mesh network. Bandwidth-based, or static CAC enables the client to specify how much bandwidth or shared medium time is required to accept a new call. Each access point determines whether it is capable of accommodating a particular call by looking at the bandwidth available and compares it against the bandwidth required for the call. If there is not enough bandwidth available to maintain the maximum allowed number of calls with acceptable quality, the mesh access point rejects the call.

• When client roams from one MAP to another in same site, bandwidth availability is checked again in the new tree for the active calls.

• When MAP roams to new parent, the active calls are not terminated and it continues to be active with other active calls in the sub tree.

• High Availability (HA) for MAPs is not supported; calls attached to MAP’s access radio are terminated on HA switchover.

• HA for RAP is supported, hence calls attached to RAP’s access radio continues to be active in new controller after switchover.

• Mesh CAC algorithm is applicable only for voice calls.

• For Mesh backhaul radio bandwidth calculation, static CAC is applied. Load-based CAC is not used as the APs do not support load-based CAC in Mesh backhaul.

• Calls are allowed based on available bandwidth on a radio. Airtime Fairness (ATF) is not accounted for call admission and the calls that fall under ATF policy are given bandwidth as per ATF weight.

Mesh CAC is not supported for the following scenarios.

• APs in a Mesh tree assigned with different site tags.

• APs in a Mesh tree assigned with the default site tag.

• Ensure that you have configured the AP role as root AP.

• Ensure that you have enabled Ethernet Bridging and Strict Wired Uplink on the corresponding AP.

• Ensure that you have disabled VLAN transparency.

• To enable VLAN support on each root AP for bridge mode APs, use the ap name name-of-rap mesh vlan-trunking [native] vlan-id command to configure a trunk VLAN on the corresponding RAP.

• To enable VLAN support on each root AP, for Flex+Bridge APs, you must configure the native VLAN ID under the corresponding flex profile.

• Ensure that you use a 4-pair cables that support 1000 Mbps. This feature does not work properly with 2-pair cables supporting 100 Mbps.

• This feature is applicable to the Cisco Industrial Wireless 3702 AP and Cisco Catalyst 9124 Series APs.

• This feature is applicable to APs operating in Bridge mode and Flex+Bridge mode only.

• In Flex+Bridge mode, if local switching WLAN is enabled, the work group bridge (WGB) multiple VLAN is not supported.

• To support the Ethernet daisy chain topology, you must not connect the Cisco Industrial Wireless 3702 PoE out port to other Cisco Industrial Wireless 3702 PoE in the port, and the power injector must be used as power supply for the AP.

• The network convergence time increases when the number of APs increase in the chain.

• Any EWC capable AP which is part of daisy chaining and has been assigned the RAP role, must be in CAPWAP mode (ap-type capwap).

In all 802.11ac Wave 2 APs, the speed of mesh network recovery mechanism is increased through fast detection of uplink gateway reachability failure. The uplink gateway reachability of the mesh APs is checked using ICMP ping to the default gateway, either IPv4 or IPv6.

Mesh AP triggers the reachability check in the following two scenarios:

• After a new uplink is selected, until the mesh AP joins the controller

  After a new uplink is selected, the mesh AP has a window of 45 seconds to reach gateway (via static IP or DHCP) through the selected uplink. If the mesh AP still fails to reach the gateway after 45 seconds, the current uplink is in blocked list and the uplink selection process is restarted. If the AP joins the controller within this 45-second window, the reachability check is stopped. Subsequently, there is no gateway reachability check during normal operations.

• As soon as the mesh AP times out its connection with the controller

  After the mesh AP times out its connection with the controller and the AP fails to reach the gateway in 5 seconds, the current uplink is immediately added to the blocked list and the uplink selection process is restarted.

In mesh deployments, sometimes a root access point connects to the controller through a nonreliable link such as a wireless microwave link. If a data uplink failure occurs, client loses connectivity to detect the cause of the failure. The feature allows you to detect the root access point uplink failure faster in a mesh deployment and address fast teardown of the mesh network when uplink failure occurs on the root access point.

Note	Fast Teardown for Mesh APs is not supported on Cisco Industrial Wireless (IW) 3702 Access Points.

The Flex Resilient with Flex and Bridge Mode Access Points describe how to set up a controller with Flex+Bridge mode Access Points (APs) and Flex Resilient feature. The Flex Resilient feature works only in Flex+Bridge mode APs. The feature resides in Mesh link formed between RAP - MAP, once the link is UP and RAP loses connection to the CAPWAP controller, both RAP and MAP continue to bridge the traffic. A child Mesh AP (MAP) maintains its link to a parent AP and continues to bridge till the parent link is lost. A child MAP cannot establish a new parent or child link till it reconnects to the CAPWAP controller.

Note	Existing wireless clients in locally switching WLAN can stay connected with their AP in this mode. No new or disconnected wireless client can associate to the Mesh AP in this mode. Client traffic in Flex+Bridge MAP is dropped at RAP switchport for the locally switched WLANs.