You can configure the backhaul on mesh access points to accept client traffic over its 802.11a radio. This feature is identified as Backhaul Client Access in the controller GUI (Monitor > Wireless). When this feature is disabled, backhaul traffic is transmitted only over the 802.11a or 802.11a/n radio and client association is allowed only over the 802.11b/g or 802.11b/g/n radio. For more information about the configuration, see the “Configuring Advanced Features” section on page 159.

Note	In rel 8.2 and higher the backhaul is also supported on 2.4 GHz.

1562 supported mesh in 8.4 release. 1542 AP (1542D and 1542I) models supported Mesh in 8.5 release. All these Aps should be able to support Flex Mesh as Flex Mesh designed on 1542 should be applicable to 1562 as well since Flex Mesh is a platform independent feature.

Flex Mesh feature is supported on the IOS based Mesh AP even prior to release 8.8; however in rel 8.8 this feature is officially supported on the COS based Mesh AP and supported by TAC starting with rel 8.8. In addition, the IPv6 is now supported on the COS based Mesh APs.

There are two new SKUs of 1542 that are developed. The AP1540 Series released in 8.5 meets most of the technical requirement, but does not have external antennas. AP1542E2 and AP1542E4 are hardware variants of 1541D/I AP. The 1542E2 is a dual band mode AP with dual-radio dual-band 2.4GHz (802.11b/g/n, 20MHz) & 5 GHz (802.11a/n/acW2, 20/40/80 MHz). The 1542E4 is a single band mode AP with antenna A and B to support 2.4G and C and D to support 5G. The Aps support minimum 2 TX & 2 RX chains, 2 spatial streams. AP expected to support minimum 22 dBm (2.4 GHz) and 24 dBm (5 GHz) conducted transmit output power per TX. Basic new PID additions and power table changes for this new platform will be done on both AP and WLC. New power tables for -D(INDIA) with external antennas.

The above HW changes have requirements for SW changes as well. The AP needs to support a flexible antenna port configuration. SW changes are done to let the user configure the antennas to support either in a single band mode or dual band mode. Software configurable Single Band Vs Dual Band mode. This is similar to the 1532 AP configuration. The user can configure the antenna band modes using WLC CLI or GUI.

Flex mesh COS AP can be running in connected or standalone mode. Standalone mode in flex connect will undergo some changes to inherit standalone functionality for a mesh network. There is also another mode called 'abandoned' mode discussed below in this section of the guide.

A COS Flex Mesh AP (Root AP or Child Mesh AP) is considered to be in connected mode when it can access and join the WLC and can exchange periodic keep alive messages with WLC. In this mode, Flex Mesh AP will be able support locally and centrally switched WLAN's. It shall allow regular client and Child mesh APs to join.

A COS Flex Mesh AP, is considered to be in standalone mode if it loses connection to the controller but it can access the local gateway. In this mode, the COS Flex+Mesh AP will disable all the centrally switched WLANs, and shall keep the locally switched WLANs up and running. It will also allow the new clients to join on local switched WLANs using local authentication as long as the authentication server is reachable in the local network. Child mesh APs will NOT be allowed to join in this mode.

A COS Flex+Mesh AP is in abandoned mode when it can no longer access the gateway IP and has no connectivity to the local network. Possible scenarios are:

• AP is still not locked on to any uplink wired or wireless.

• A wireless uplink has been established but has not been authenticated.

• An uplink is established and authenticated, but IP address has the gateway IP has not been configured.

• An uplink is established, authenticated and also IP address and gateway IP has been configured, but the gateway is not reachable for over a minute.

Neither Child Mesh APs nor the clients are allowed to join in this mode. Local as well as centrally switched WLANs will be disabled. AP may still be scanning for an uplink in this mode so no beacons will be transmitted during this time.

Note	For flex mesh COS APs, in abandoned mode, reboot timer shall be enabled so the AP will have rebooted after 40 minutes, if it does not transition to either standalone mode or connected mode.

• Flex Mesh mode COS AP will always boot up in abandoned mode, in which it would need to scan for the uplink (wired or radio).

• Once a new uplink is selected either during initial stage or during inter gateway roaming scenario, it is expected that the authentication should pass and the CAPWAP connection needs to be formed within 2 minutes, else the selected parent will be blacklisted. This function should be same as a regular Mesh mode COS AP.

• If a Flex mesh AP has a valid CAPWAP connection and it loses the CAPWAP connection it will transition to standalone mode, and will stay in standalone mode, as long as the gateway is reachable. A Flex Mesh AP will keep track of the IP mode (IPV6 or IPV4) used for the last successful CAPWAP connection and with track the reachability of the GW for that IP mode.

• For Flex mesh AP in standalone mode, Mesh control will start a timer (20 second) to periodically refresh the ARP entry for GW IP (IPV4 or IPV6) and to also query the GW reachability status from the Path Control Protocol. PCP will maintain the gateway reachability status from that AP either reported by the Root AP via PCP messages or if it is Root AP by doing an ARP lookup for the gateway IP address. If the GW is unreachable for over a minute, the Flex Mesh AP will blacklist the parent and will transition to abandoned mode and will re-scan for a new uplink.

• To come out of the abandoned mode, AP must connect to the WLC and transition to the connected mode. Transition from abandoned mode directly to standalone mode is not supported and needs to be considered in future design enhancements.

• When the Flex AP is in standalone mode, it will stick to the same parent and will NOT try to discover or roam to a better neighbor, even if it is a preferred parent. The reason is that there is no guarantee that the security will pass with the new parent and the roaming will be successful. If the security fails, the perspective parent may get blacklisted unnecessarily. It is best to consider standalone roaming once standalone security is supported for Mesh APs in future design enhancements.

• BGN timer will be stopped in standalone mode. So, if the child mesh AP is in standalone mode and it joins a parent with a different BGN and goes back into standalone mode after that, BGN timer will be stopped so that the child Mesh AP does not go into re-scan mode after 15 minutes (BGN timer expiry).

• In standalone mode, reboot timer will be stopped so that the AP does not reboot after 40 minutes, in the absence of a CAPWAP connection.

• After moving back to connected mode, from standalone mode, best neighbor selection timer and BGN timer will be restarted, so allow the child mesh AP to roam to the best possible neighbor.

In this mode the SSID will be broadcasted always (Persistent SSID). In addition, after reboot, when this special Persistent mode is enabled, Flex Mesh RAP should be able to start broadcasting the SSID even if the gateway is not reachable.

• Locally switched WLANs are stored in config.flex file and Flex-connect AP broadcasts the local WLAN SSIDs as long as it is standalone mode.

• On boot up Flex-connect AP would only start broadcasting the locally switched WLANs if the gateway provisioned.

• If for a COS Flex connect AP, gateway information is removed at some point, it moves out of the standalone mode and stops broadcasting the locally switched SSIDs and waits for gateway to be provisioned again.

• Once the gateway is provisioned, Flex AP again transitions into the standalone mode and starts broadcasting the locally switched SSIDs again.

• Without a valid gateway, flex-connect AP eventually stops broadcasting SSIDs, since the local network is not reachable so no reason to connect the clients.

Parts of the existing Flex-connect AP mode design is used to retain WLAN configuration during reboot and to be able to start broadcasting Local SSIDs etc. However, for Flex RAP we have a special standalone mode requirement for NBN deployment as stated below:

• Flex RAP should be able to boot up directly into the standalone mode and start broadcasting SSIDs, even if the gateway is not reachable.

• Flex RAP will continue to be in standalone mode and keep broadcasting SSIDs if the gateway was reachable earlier and becomes unreachable at some point.

• Even if the Flex RAP cannot support any real clients, it still needs to broadcast SSID so that the operator can check if the AP is UP and running.

• Flex RAP should join the controller at least once to download the WLAN configuration that gets stored in the config.flex file. This WLAN is a local switched one.

• Once the configuration is stored in the config.flex file, it will become persistent across the reboots and AP does not need to join WLC again as long as the configuration is not erased.

• A new configuration that is needed for the RAP to maintain the wired link is supported and will be stored in mesh configuration file i.e. "strict_wired_uplink".

• If the following conditions are true, FLEX Mesh AP will broadcast the local WLANs stored in flex configuration file even if the gateway is not reachable.

  • AP is a Flex Mesh Root AP

  • AP is configured with strict_wired_uplink as true.

• A new AP CLI command will be supported to configure a Flex Mesh AP as a strict wired AP.

  # CAPWAP ap mesh strict-wired-uplink <true/false>

• New configuration parameter "strict_wired_uplink" will be stored in config.mesh file in storage directory so that it is persistent across the reboots. Default value of this parameter will be false.

• Strict wired uplink configuration is only valid if the AP is configured as Flex-Mesh Root AP. For all other AP modes and for Mesh AP role, strict wired uplink configuration will not be effective, even if configured.

• When strict wired uplink is true for Flex Mesh Root AP:

  • Wired uplink will be immediately selected on mesh restart.

  • Wired uplink will never be blacklisted

  • CAPWAP up timer will not run

  • Mesh Reboot timer will not run

  • Seek of the wired adjacency will always return true, even if the interface is down

  • Wireless backhaul can never be selected as an uplink

  • Wireless backhaul can still be used as downlink to provide connectivity to the Mesh child nodes

• To avoid issues due to gateway configuration checks, static IP and gateway must be configured on the Flex RAP (even if it just a dummy IP or gateway).

  • Having Static IP and Gateway configuration will allow the Flex RAP to transition into standalone mode after reboot even when there is no connectivity to the local network (i.e. no DHCP server to provision IP and gateway). Flex RAP will then continue broadcasting the locally switched SSIDs even in absence of any network connectivity.

  • If the IP and gateway are not valid, and once AP has connectivity to DHCP server, DHCP IP overwrites the static IP configuration and DHCP IP and gateway configuration takes over.

• A Simple WLC CLI to enable/disable the 'Persistent SSID' feature will be provided. The WLC and AP should have communication for this configuration to take effect.

• The AP 'show mesh config' will also dump the current status of this feature.

In order to test the setup best is to configure one RAP with perrsistant SSID or in abandoned mode and one in a regular RAP mode. Connect a client to both RAP and observe behavior when RAPs lose their connectivity to the controller.

• Client with Persistent Mode enabled should maintain connectivity to the RAP, since RAP continues to transmit the SSID.

• Client that connected to the regularly configured RAP will lose connectivity since SSID will stop being transmitted.

Certain Cisco customers have plans to deploy Cisco Wifi Mesh solution across very large geographical areas with a Flex+Mesh (with local switching) tree. A RAP (Root Access Point) with a wired backhaul to the centralized WLC shall forms a mesh tree serving wireless clients. Lawful Intercept feature is a process of lawful interception and monitoring of mobile phones, landlines, and wireless internet traffic if administration decides to set up a Centralized Monitoring System (CMS) .

There will be a mesh network in Flex+Mesh mode setup and as part of LI, export the client flow information for each flow will be provided.

RAP will do the NAT/PAT as well as LI record generation and sending to LI server via WLC. For all flows, a record will be created in the NAT/PAT. At that point, RAP will create the Syslog record for that flow. RAP will send those Syslog packets through CAPWAP-DATA to the WLC.

Note	Any peer to peer client traffic within mesh tree which does not go via RAP (only MAP handles locally) will not be considered to be reported to LI server.

WLC will update the syslog packet with its own MAC and IP and will forward the Syslog packets to the Syslog server in the network. These packets will not be encrypted.

This will be the typical workflow:

1. Admin has to configure Syslog server config.

   Either IPv4 or IPv6 is only supported.

   If IPv6 is configured then WLC should be IPv6 enabled.

   The existing “config ap syslog global “ command will be functional.

2. LI will be enabled/disabled only Globally.

   Prerequisite for this will be Syslog server config.

3. AP saves the syslog server configuration (IP address and enable/disable) received from WLC on RAP.

4. IPv4 packets to be NAT/PAT(in case of internal DHCP) on the packets.

   IPv6 packets and also IPv4 packets (in case of external DHCP) will:

   1. Identify flows based on packet Source/dest IP/port.

   2. Save the flows in a FlowTable entry.

5. LI Reporter element will:

   1. Receive and save new flow records pushed by NAT element/FlowTable element.

   2. It will run a periodic timer (typically 1 minute).

   3. c. On expiry of this timer, all the flow records in its table are flushed and converted to syslog records containing both v4 and v6 flows together. Syslog format is given in next section.

6. Only at the beginning of the flow creation, it will be sent. Subsequently, no other flow records will be sent.

7. AP will form the syslog packet

8. 8) WLC will recognize whether it is LI packet or not.

   Update the contents,

   IP: Dst IP: LI IP (v4 or v6)

   Source IP: Mgmt IP

   Dst Mac: GW Mac

   Source Mac: Mgmt Mac

   UDP Source Port: 514

   UDP Dest Port: 514

9. Based on the Inner IP packet, WLC will update the Mgmt IP.

   If it is IPv4 then Mgmt IP will be updated.

   If it is IPv6 then Mgmt IPv6 will be updated

10. WLC will not store any records.

11. Stats will be recorded for the incoming messages from AP.

    Stats will also be recorded for the outgoing messages from WLC to syslog server.

    Also, other stats if the packet is dropped.

12. Whenever show command is executed it will show the log.

The syslog record is then encapsulated inside UDP/IP header from AP to LI server based on the config received from WLC.

A Syslog record will be formatted as below:

“syslog header+’:’+ LI Header +’:’+ LI Record 1+’|’+ LI Record 2 +’|’+….”

Syslog Header

• Facility: Syslog facility code.

• Severity: Syslog Severity.

• Timestamp: Time at which the AP sends out the syslog message. This is sent in human readable date format : mmm dd yyyy hh:mm:ss

• Hostname: Name of the AP (RAP Name)

• Tag: The Tag field is a string that signifies what type of message is carried in the payload. (AP_LI_V4_FLOW/ AP_LI_V6_FLOW)

LI Header:

“VVTTTTTTTTMMMMMMMMMMMM”

• VV: Version, currently it is always “01”

• TTTTTTTT: Time in seconds when this logging is created, Hex values

• MMMMMMMMMMMM: AP’s mac address. (RAP mac address)

LI record (for IPv4):

“MMMMMMMMMMMM AAAAA’A’A’A’BBBBCCCCCCCCCC’C’C’C’C’C’C’C’DDDDDDDDTTTTTTTTHHHHHHHH”

• MMMMMMMMMMMM : Client MAC Address (6 bytes)

• AAAA–source port in HEX (2 bytes)

• A’A’A’A’ – NAT source port in HEX (2 bytes) (this will be same as above for no-nat case)

• BBBB–dest port in HEX (2 bytes)

• CCCCCCCC – source ip address in HEX (4 bytes)

• C’C’C’C’C’C’C’C’ – NAT source ip address in HEX (4 bytes) (this will be same as above for no-nat case)

• DDDDDDDD–dest ip address in HEX (4 bytes)

• TTTTTTTT-Time in seconds, time when flow was created (4 bytes)

• HHHHHHHH–RAP IP in HEX (4 bytes or 16 bytes)

LI record (for IPv6) (will not have NAT ip and ports):

“MMMMMMMMMMMM AAAABBBB CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDTTTTTTTTHHHHHHHH”

• F – 0 for IPv4, 1 for IPv6

• MMMMMMMMMMMM : Client MAC Address (6 bytes)

• AAAA – source port in HEX (2 bytes)

• BBBB – dest port in HEX (2 bytes)

• CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC– source ipv6 address in HEX (16 bytes)

• DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD – dest ipv6 address in HEX (16 bytes)

• TTTTTTTT - Time in seconds, time when flow was created (4 bytes)

• HHHHHHHH – RAP IP in HEX (4 bytes or 16 bytes)

New command will be added for LI enable and Disable.

(Cisco Controller) >config flexconnect lawful-interception ?
disable        Disable Lawful-Interception.
enable         Enable Lawful-Interception.
syslog         Configure Lawful-Interception syslog.
timer          Configure Lawful-Interception timer value. Timer is periodic interval [60sec - 600sec] 

Pre-requisite: Ap Syslog should be configured else it will not allow.

1. Existing command is modified to reflect LI changes.

   # config ap syslog host global <ipv4/ipv6>

   Pre-requisite: If IPv6 is trying to configure we need to check whether IPv6 is enabled and Management is configured with IPv6 address.

2. There is a new show command to show the stats.

   (Cisco Controller) >show flexconnect lawful-interception ?
   summary        Display Lawful-Interception summary.
   Example of the LI show command on the controller:
   (Cisco Controller) >show flexconnect lawful-interception sum
   Lawful Interception Status: Disabled
   Lawful Interception Timer: 60       
   Lawful Interception IPv4 Addr: 192.201.1.1
   Lawful Interception IPv6 Addr: Not Configured
   

Note	There will be show commands on AP to display the configured LI server IP and status.

Example of the show LI command on the AP.

AP-2802#show lawful-intercept 
Enable: false
Interval(sec): 60
AP IPv4 Address: 1.5.39.108
AP IPv6 Address: ::
Max records: 15
syslog src ip: 192.201.1.2
syslog src ipv6: ::syslog 
src mac: 00:01:02:03:04:09
extlog server ip: 0.0.0.0
extlog server ipv6: ::
extlog server mac: 00:8E:73:56:24:C7
ap name: AP-2802

(WLC)config wlan apgroup custom-web global enable/disable <apgroup_name>

(WLC)config wlan apgroup custom-web ext-webauth-url add <ext-webauth-url> <apgroup_name>

 (WLC)config wlan apgroup custom-web ext-webauth-url delete <apgroup_name>

Configured redirect-URL shall be listed in existing show dump:

(WLC)show wlan apgroups