Configure Transmit Power Control

This is one of the features of RRM on WLC and in this post we will see and learn the option under TPC.

This algorithm is responsible for reducing the power level on the APs to reduce excessive cell overlap and co-channel interference. TPC uses the RSSI calculations for the neighbor APs, and it determines effective changes only if there are more than three neighbor APs.

The TPC algorithm runs every 10 minutes (600Secs). The RF group leader runs TPC on a per-radio, per-AP basis. Therefore, a power adjustment on 802.11b/g has no bearing on the 802.11a power level settings for the same AP.

The minimum requirement for TPC is that a single AP needs to be heard by at least three other APs at -70 dBm or greater. Therefore, we must have at least four APs total. The logic behind the lowering of the power levels is that the third loudest neighbor is heard at -70 dBm or lower after the change.

The final purpose of the algorithm is to make sure that the third-loudest neighbor AP is heard at a signal level lower than the configured threshold (by default its –70 dBm).

***Note: The TPC algorithm is only responsible for turning power levels down.

TCP goes through these stages which decide if a transmit power change is necessary:

  1. Find out if there is a third neighbor, and if that third neighbor is above the transmit power control threshold (-70dBm).
  2. Determine the transmit power using this equation:

Tx_Max for given AP + (Tx power control thresh – RSSI of 3rd highest neighbor above the threshold).

  1. Compare the calculation from step two with the current Tx power level and verify if it exceeds the TPC hysteresis.
  • If Tx power needs to be turned down: TPC hysteresis of at least 6dBm must be met. OR
  • If Tx power needs to be increased: TPC hysteresis of 3dBm must be met.

***Note: When a brand new APs boot up for the first time, it transmit at their maximum power level (its 1). When AP is power cycled, it uses their previous power settings.

***Note: It is important to remember that decreases in AP radio power levels are gradual, whereas increases can take place immediately. Therefore, if we change the RRM configuration settings, do not expect to start seeing the APs changing channels and adjusting their power as soon as we click Apply.

Now we will see the configuration steps@TPC

Via GUI:

Go to Wireless -> 802.11a/n or 802.11b/g/n -> RRM ->TPC

On this screen we have these options:

Power Level Assignment Method: There are 3 ways to configure TPC algorithm:

  • Automatic: This is the default configuration and the TPC algorithm runs every ten minutes (600 seconds).
  • On Demand: The algorithm can be manually triggered if we click the Invoke Channel Update Now
  • Fixed

Min/Max Power: Maximum and minimum power level assignment and we can choose between -10 to 30dBm.

Power Threshold: Default value for this parameter is –70 dBm but can be changed when access points are transmitting at higher (or lower) than desired power levels.

Power Neighbor Count: The minimum number of neighbors an AP must have for the TPC algorithm to run.

Power Assignment Leader: This field displays the IP address of the WLC that is currently the RF Group Leader. Because RF Grouping is performed per-AP, per-radio, this value can be different for the 802.11a & 802.11b/g networks.

Last Power Level Assignment: The TPC algorithm runs every 600 seconds (10 minutes). This field only indicates the time (in seconds) since the algorithm last.


(WLAN1) >show advanced 802.11a txpower
 Automatic Transmit Power Assignment
 Transmit Power Assignment Mode................. OFF
 Transmit Power Update Interval................. 600 seconds
 Transmit Power Threshold....................... -70 dBm
 Transmit Power Neighbor Count.................. 3 APs
 Min Transmit Power............................. -10 dBm
 Max Transmit Power............................. 30 dBm
 Transmit Power Update Contribution............. SNI..
 Transmit Power Assignment Leader............... WLAN1 (
 Last Run....................................... 98 seconds ago


In this post we will learn how to use ACL on WLC.
As we all know that we use ACL to prohibit/restrict the access from specific clients.

Mostly we use two type of ACL:

  1. CPU (Be careful before assigning)
  2. WLAN/Interface Based ACL
  3. Pre-Authentication ACL

Basic Info:


  • We can configure max 64 filters with 64 rules.
  • ACLs can impact the performance of the controller.
  • ACLs can’t block access to the virtual IP address ( of WLC. Therefore, DHCP cannot be blocked for wireless clients.
  • ACLs do not affect the service port of the WLC.
  • We can only block IP traffic

Parameter used in ACL:

Sequence: Here starts the order that ACL lines are processed against the packet. Even after creation of ACL with sequence number 1, we can replace it with new sequence. Means it also allows us to insert ACL lines anywhere in the ACL even after the ACL is created.

Source IP & Destination IP: Here we have to enter the host or subnet IP and mask (From & To, The masks of the ACL are not wild-masks but normal masks).

Protocol: We need to enter the Protocol to add this in IP packet header.

Here is the list of all which we can use: Any (all protocol numbers are matched)

TCP (6), UDP (17), ICMP (1), ESP (50), AH (51), GRE (47), IP (4), Eth Over IP (97), OSPF (89), Other (Specify)

Source & Destination Port: TCP or UDP can only be specified.

DSCP: Differentiated Services Code Point allows us to specify specific DSCP values to match in the IP packet header (Only 2 option available: Specific & Any).

Direction: Which direction to enforce: Inbound, Outbound and Any

Inbound: Packet sourced from the wireless client. (Client à WLC)

Outbound: Packets destined to the wireless client (Or from WLC à Client)

Any: Sourced from the wireless client and destined to the wireless client are inspected to see if they match the ACL line. We must apply to both Inbound & Outbound directions.

Action: Either Permit or Deny


  • We can only specify protocol numbers in the IP header (UDP, TCP, etc…) in ACL lines, because ACLs are restricted to IP packets only.
  • If the source AND destination is any, then the direction is also ANY.
  • If the source or destination is NOT any, then the direction must be specified.
  • The direction is faced FROM the controller.
  • Inbound: Wireless client To WLC
  • Outbound: WLC To wireless client
  • Remember that at last we have an implicit deny at the end.

Let’s start doing configuration.

First we will create an ACL and apply to either WLAN or Interface.

Login to WLC then Security > Access Control lists > Access Control lists, click on New.

Also check the Enable counter to see the statics.


CPU Access list

In my example:

  1. Block Telnet from a specific workstation on management interface


Create Access List and Apply it.

*** To remove this ACL either we have to uncheck “Enable CPU ACL” box or Via CLI we must use this command”config acl cpu none”. Remember this command if we stuck into the case where we can’t access WLC anymore then via console run this command to get the access back.

*** LWAPP/CAPWAP control traffic is not affected by CPU ACLs.

***By default Telnet is disabled on WLC, we must enable it for testing.(From Management > Telnet-SSH)

Here is my access List: We can see the hit numbers.


Apply it: Security > Access Control List > CPU Access List


How it looks in CLI:

(WLC2) >show acl cpu
 CPU Acl Name................................ TestACL
 Wireless Traffic............................ Enabled
 Wired Traffic............................... Enabled
(WLC2) >show acl summary
 ACL Counter Status               Enabled
 IPv4 ACL Name                    Applied
 -------------------------------- -------
 TestACL                          Yes
 IPv6 ACL Name                    Applied
 -------------------------------- -------
(WLC2) >show acl detailed TestACL
 Source                         Destination                 Source Port  Dest Port
 Index  Dir       IP Address/Netmask               IP Address/Netmask       Prot    Range       Range    DSCP  Action      Counter
 ------ --- ------------------------------- ------------------------------- ---- ----------- ----------- ----- ------- -----------
 1  In    6     0-65535    23-23     Any   Deny           3
 2 Any                 Any     0-65535     0-65535  Any Permit          14
 DenyCounter : 0
 URLs configured in this ACL
(WLC2) >

WLAN / Interface ACL


Where to Apply:

  1. Under WLAN


  1. Under Dynamic interface


Preauthentication ACL

As its name suggest that this kind ACL is used before any authentication

We usually create this type of pre-authentication ACL for web authentication. Such an ACL could be used to allow certain types of traffic before authentication is complete.

Creation or write an ACL is same as we did in above section, so I will not repeat the same steps here.

Where we can apply this ACL:

  • Go to WLANs > WLANs
  • Click the ID number of the WLAN to open the WLANs > Edit
  • Choose the Security and Layer 3 tabs to open the WLANs > Edit (Security > Layer 3) page
  • Preauthentication ACL drop-down box, choose the desired ACL and click Apply


That’s all  🙂

WLC Mesh Network Configuration

In this post we will learn about the configuration guide point to point wireless bridging using the Mesh Network solution from WLC.

This is my topology:


Right now I have both AP connected to WLC in local mode.

Remembering points:

  • An AP in mesh mode needs to be authorized to join a controller. So the first step is therefore to add there mac address.
  • Before converting to bridge mode we must add the mac address of the both APAP in Policies list or the MAC filtering list. From Security > AAA > AP Policies, click Add.
  • To configure Mesh, we will need to do multiple reboots of our APs. To reduce the number of reboots, configure all of the global Mesh settings first
  • Don’t use static IP address especially on MAP.

From Security > AAA > AP Policies, click Add.


Now place both AP into Bridge mode (just another name for Mesh mode).





After selection of Bridge mode we must apply it. Then both AP will reboot.

See the screenshot when both AP came as in Bridge Mode:


Once the AP reboots, a new MESH tab is available under:  Wireless > All APs, click on AP1 or AP2.


Here are few boxes which we should remember.

AP Role: Either RAP or MAP

Bridge Type: Indoor

Bridge Group Name (BGN): It’s like a workgroup name, allow the APs to know which AP are part of their group. (Here in my example we will take BGN as rscciew123)

Bridge Data Rates: Rate at which data is shared between the mesh access points. This is fixed for a whole network. Default data rate is 18 Mbps, which you should use for the backhaul. Valid data rates: for 802.11a: 6, 9, 12, 18, 24, 36, 48, and 54

Since AP2 will send its traffic through AP1, AP1 will be the RAP and AP2 will be the MAP. Don’t forget to configure an identical Bridge ID. (Otherwise leave it blank for both APs)

In Mesh tab, configure the rest of the AP settings.

  • Select RAP role to AP1 and assign BGN name (rscciew123)
  • Select MAP role to AP2 and assign BGN name (rscciew123)

And Apply. The APs will go through reboot again, and will take few minutes to rejoin to WLC.

*** MAPs use Adaptive Wireless Path Protocol (AWPP) to determine the best path through the mesh APs to their WLC. The protocol takes path decisions based on both link-quality and number of Mesh hops.

To prevent AP2 from simply connecting back up to the WLC through its wired port, Either place AP2 into VLAN 100(Not routable) or make the wired port shut for AP2, so that it has no path to the WLC except though its radios.

This is not mandatory- (When the APs come back up, AP1 will do another MAC auth. But AP2 will do a user auth. See the SNMP trap logs for the user name, and then create a local user with that name and make the password identical to the name.)We can see this error in trap log on WLC.

Now my Both AP is up.

Now check the status: Go to Wireless > All APs , far right on AP1 there is blue box ,click on that and select Neighbor Information




We can also check from AP1 and AP2 CLI:

On AP1:

AP001#sh mesh status
 show MESH Status
 RootAP in state Maint
 Uplink Backbone: FastEthernet0,  hw FastEthernet0
 Configured BGN: rscciew123, Extended mode 0
 Children: Accept child
 rxNeighReq 187 rxNeighRsp 0 txNeighReq 0 txNeighRsp 187
 rxNeighRsp 653 txNeighUpd 3333
 nextchan 0 nextant 0 downAnt 0 downChan 0 curAnts 0
 nextNeigh 1, malformedNeighPackets 0,poorNeighSnr 0
 excludedPackets 0,insufficientMemory 0, authenticationFailures 0
 Parent Changes 1, Neighbor Timeouts 0
 Vector through XXXX.XX96.3404:
 Vector ease 1 -1, FWD: XXXX.XX96.3404
AP001#sh mesh adjacency child
 show MESH Adjacency Child
 ADJ 1 Identity YYYY.YY03.e31c MA: 003a.9914.137f ver 0x20 minver 0x0 on device Dot11Radio:1 txpkts 754 txretries 420
 worstDv 255 Ant 0, channel 64, biters 0, ppiters 10, fwd_state 3
 Numroutes 0, snr 0, snrUp 10 snrDown 0 linkSnr 0 blistExp 3 bliters 0
 adjustedEase 0 unadjustedEase 0 stickyEase 0 txParent 0 rxParent 0
 BGN rscciew123
 Vector through YYYY.YY03.e31c:
 Per antenna smoothed snr values: 0 0 0 0
 Subordinate neighbors: YYYY.YY03.e31c
 Hop-Count Extension: ON, Version: 1

On AP2:

AP002#sh mesh status
 show MESH Status
 MeshAP in state Maint
 Uplink Backbone: Virtual-Dot11Radio0,  hw Dot11Radio1
 Configured BGN: rscciew123, Extended mode 0
 Children: Accept child
 rxNeighReq 0 rxNeighRsp 213 txNeighReq 372 txNeighRsp 0
 rxNeighRsp 1094 txNeighUpd 966
 nextchan 0 nextant 0 downAnt 0 downChan 0 curAnts 0
 nextNeigh 3, malformedNeighPackets 0,poorNeighSnr 44
 excludedPackets 0,insufficientMemory 0, authenticationFailures 0
 Parent Changes 7, Neighbor Timeouts 0
 Vector through XXXX.XX96.3404:
 Vector ease 1 -1, FWD: XXXX.XX96.3404
AP002#sh mesh adjacency parent
 show MESH Adjacency Parent
 ADJ 1 Identity XXXX.XX96.3404 MA: 0022.bd98.3a3f ver 0x20 minver 0x20 on device Dot11Radio:1 txpkts 712 txretries 247
 worstDv 0 Ant 0, channel 64, biters 0, ppiters 10, fwd_state 3
 Numroutes 1, snr 0, snrUp 13 snrDown 10 linkSnr 9 blistExp 2 bliters 0
 adjustedEase 512 unadjustedEase 512 stickyEase 2048 txParent 349 rxParent 199
 Authentication: EAP, Encryption: AES-CCMP, Fwd-state: OPEN/CONTROL
 BGN rscciew123
 Vector through XXXX.XX96.3404:
 Vector ease 1 -1, FWD: XXXX.XX96.3404
 Per antenna smoothed snr values: 9 0 0 0
 Hop-Count Extension: ON, Version: 1

*** MAP is in Maint state, which indicates it has found a parent.


(WLAN1) >show ap summary
 Number of APs.................................... 2
 Global AP User Name.............................. admin
 Global AP Dot1x User Name........................ Not Configured
 AP Name             Slots  AP Model              Ethernet MAC       Location          Port  Country  Priority
 ------------------  -----  --------------------  -----------------  ----------------  ----  -------  ------
 AP001                2     AIR-LAP1242AG-E-K9    XX.XX.XX:96:34:04  default Location  1        DE       4
 AP002                2     AIR-LAP1242AG-E-K9    YY.YY.YY:03:e3:1c  default location  1        DE       4
 (WLAN1) >
 (WLAN1) >
 (WLAN1) >show mesh ap tree
 ||  AP Name [Hop Counter, Link SNR, Bridge Group Name] ||
 [Sector 1]
 Number of Mesh APs............................... 2
 Number of RAPs................................... 1
 Number of MAPs................................... 1
 (WLAN1) >

This is all about basic configuration J

We can also force MAP to use specific RAP for the best path: How to configure it.

(WLAN1) > config mesh parent preferred <Cisco AP name> <mac address of preffered parent>

Configuring Global Mesh parameters

Wireless -> MESH


  • Range
    • Optimum distance that should exist between the RAP and the MAP
  • IDS
    • Normally this parameter applies to outdoor mesh access points to report Rouges to Controller.
    • IDS reports are generated for all traffic on the backhaul
  • Backhaul Client Access
    • It applies to APs with 2 or more radios.
    • When it’s disabled, 11a radio -> backhaul, 802.11b/g -> Client associations.
    • When enabled, Slot 1 can do both backhaul and client associations
    • When Extended Backhaul client access is enabled, even slot 2 can be used for client associations.
  • Mesh DCA Channel
    • When we change the channel under RRM then MAP will not detect this and they will continuously use that channel, so if we enable this feature the MAP will detect the channel change on RRM.
  • Global Public Safety
    • Disabled by default, we can enable this to use 4.9GHz range.(This range used by US Public Safety channels)
  • VLAN Transparent
    • It determines how VLAN tags are handled from the Ethernet bridged traffic
    • The VLAN tagging only works on non-backhaul Ethernet ports.
    • When enabled: VLAN tags are not supported and only 1 L2 VLAN ( Mesh AP vlan ) can be bridged when VLAN transparent is enabled
      • e the RAP , MAP ethernet ports must be configured as access ports on the switch
    • When this feature is disabled, all packets are tagged as non-VLAN transparent or VLAN-opaque . This implements VLAN tagging.
  • Security mode
    • PSK or EAP authentication can be enabled
      • EAP must be selected if external MAC authorization using a RADIUS server is configured
      • PSK or Local EAP authentication is performed within the controller if External MAC Filter authorization parameter is disabled.
    • External MAC filter authorization
      • If the MAC address is not found in the local MAC filter list, then the RADIUS server is checked.
      • Protects against rogue APs
    • Force External Authentication
      • When this is enabled along with External MAC filter authorization the RADIUS server decisions override the local MAC filter list.

Mesh Ethernet Bridging:


Ethernet Bridging: By default it’s disabled, traffic from MAP Ethernet is blocked on Backhaul. To allow traffic from MAP Ethernet we have to enable this feature on both RAP and MAP.

***Note: By default Ethernet bridging is not allowed, it’s dropped on RAP Ethernet port, untagged.   To allow VLAN tagging we must disable VLAN Transparent option (Wireless > Mesh). Once we disable it VLAN tag will be accepted.


RAP: Check the Ethernet Bridging Box and Apply

Now we will see the Ethernet interface under Mesh Tab, Click on it.






Same we have to do on MAP.


RAP: Native VLAN 80, Trunk VLAN 35

MAP: Native VLAN 100, Trunk VLAN 35

Make sure that port for RAP and MAP configured as Trunk.

That’s all about Ethernet bridging 🙂

SNMP Configuration on WLC

In this post we will see the SNMP configuration on WLC to add to WCS/NCS or Prime INfrastructure.

Simple Network Management Protocol (SNMP) is an application layer protocol that provides a message format for communication between SNMP managers and agents using UDP ports 161 and 162 for sending and receiving SNMP traps.

Configuration SNMP on cisco WLC via GUI & CLI.

First login to WLC (After configuration via CLI or GUI) then go to Management > Summary Tab: This shows the summary of management section.


General Tab:


As we are aware that to connect with WCS/NCS/PI, we must enable SNMP v2c / SNMP v3 mode and can fill/change other information like: Name, Location and Contact person.

We can also modify this information via CLI by using these commands:

(WLC1) >config snmp  syscontact Mr. Sandeep
(WLC1) >config snmp  syslocation MyTestLAB
(WLC1) >config snmp  version v1 ?
 enable         Enable SNMP version.
 disable        Disable SNMP version.
(WLC1) >config snmp  version v1 disable
(WLC1) >config snmp  version v2c ?
 enable         Enable SNMP version.
 disable        Disable SNMP version.
(WLC1) >config snmp  version v2c enable
(WLC1) >config snmp  version v3 ?
 enable         Enable SNMP version.
 disable        Disable SNMP version.
(WLC1) >config snmp  version v3 enable

Now let’s start with SNMP communities section.

In Management > SNMP > Communities Section:


Before creating a new SNMP community, we must delete old “Private” SNMP community due to security issues.

Now we will create a SNMP community and other information.

We must enter the NCS IP address (if some other IP then make sure that our NCS server must come in the range of IP we configured). Access mode can be Read only or Read/Write.

Here is the way to create SNMP community via GUI:


Via CLI:

(WLC1) >config snmp community create NCScciew
(WLC1) >config snmp community ?
 accessmode     Configure the access mode (read-only or read-write) for a SNMP community.
 create         Add a new SNMP community.
 delete         Delete a SNMP community.
 ipaddr         Configure the IP address and mask to be accessible for a SNMP community.
 mode           Enable or disable a SNMP community.
(WLC1) >config snmp community ipaddr NCScciew
(WLC1) >config snmp community mode enable NCScciew
(WLC1) >config snmp community accessmode rw NCScciew

Now we will the configuration for SNMP v3 user(Most secured way):

From a security point of view, it is recommended to run SNMPv3 with the default username changed or disabled or deleted. Keep in mind that our SNMP settings must match between the controller and the wireless/network control system (WCS/NCS). Also, we should use an encryption and hash keys that match our security policies.

Via GUI:

It’s the same procedure as we did for SNMP v2c. We need to enter a user profile name, Access mode, which type of authentication & privacy protocol and last one is auth & priv password. (I used cisco123456789 as auth and priv password)


Via CLI:

***Make sure that we must delete the default snmp v3 user profile due to security reasons.

How to delete it.

(WLC1) > config snmp v3user delete default
(WLC1) > config snmp v3user create rscciewWLC ro hmacsha aescfb128 cisco123456789


In the same section under Management > SNMP, we can also configure SNMP Trap receiver/Trap control/Trap logs.

Via GUI:


Via CLI:

(WLC1) > config snmp trapreceiver create NCS
(WLC1) > config snmp trapreceiver mode enable

We can control which SNMP traps we want to send to this trap receiver via Trap Control section under SNMP.


Now we will try to add our controller to WCS/NCS via SNMP v2c mode and SNMP v3 user.

Login to WCS/NCS and then go to Configure > Controller and then from right side drop down box select Add Controllers:


And then click on Go. This window will appear:


We must enter WLC ip address and community name which we created in WLC “NCScciew

1st we will try to add WLC to NCS via SNMP v2c community:SNMP10


Here is the screenshot from NCS:


Now we will remove again and try to add with SNMPv3 user name.


Screenshot from NCS after WLC successfully added:


That’s all about SNMP configuration.

Mobility Configuring on WLC

In this post we will learn how to configure WLC mobility on Cisco Controllers.

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.

More Info about Mobility/Roamin please visit This Section : Mobility Basics

A mobility group is a set of controllers, identified by the same mobility group name that make seamless roaming for wireless clients. By creating a mobility group, we can enable multiple controllers in a network to dynamically share information and forward data traffic when inter-controller or inter-subnet roaming occurs. Controllers in the same mobility group can share the context and state of client devices as well as their list of access points so that they do not consider each other’s access points as rogue devices.

First of All we need to configure Mobility Group name on each controller while setting up (Initial Config) the controller.

Virtual Gateway IP Address:
Multicast IP Address: / 3
Mobility/RF Group Name: Test
Network Name (SSID): Test

Via GUI:

To add an entry to a controller mobility configuration using the GUI, go to CONTROLLER > Mobility Management > Mobility Groups and click on New.



Here we enter the MAC address and IP address of the controller management interface we are adding along with the mobility group name of that controller.

In WLC1 we will add WLC2 mac and IP address.
In WLC2 we will add WLC1 mac and IP address.

Here I will posts the screenshot from WLC1, we also need to add same in WLC2.



Once we add the WLC MAC & management interface IP address the status will shows us as UP (Be aware sometime it take 20-30 seconds):



Note: For controllers to be in the same mobility group, they need to meet the following criteria:

Identical mobility group names: The mobility group name is case sensitive. A mobility group name of ABC is not the same as abc from the controller perspective.

Same virtual interface IP address: If the virtual IPs are not the same between the controllers, the handoff of the client database entry will not take place and the client will be disconnected for a short period.

Same version of code: This is true for supporting normal client mobility. Starting with the 5.2 release, a 5.2 or 6.0 controller supports auto-anchoring with 4.2 and higher code running on the anchor controller.

Network connectivity between the controller in the mobility group: We should be able to mping and eping between the controllers. These special pings will be discussed in other post.

Remembering points in brief before configuring Mobility:

  • IP connectivity must exist between the management interfaces of all controllers.
  • All controllers must be configured with the same mobility group name.
  • All controllers must be configured with the same virtual interface IP address.
  • We must have gathered the MAC address and IP address of every controller that is to be included in the mobility group. This information is necessary because we will be configuring all controllers with the MAC address and IP address of all the other mobility group members.
  • When we configure mobility groups using a firewall, for example, Cisco ASA, we must open port 16666, and IP protocol 97.

We have only 2 WLC so we will not configure Multicast Group IP address in this post.

If we have multiple controllers in Mobility Group then we must configure Multicast Group IP address on each controller.


Via CLI:

config mobility group domain domain_name

(WLC1) > config mobility group domain Test

config mobility group member add mac_address ip_address

(WLC1) > config mobility group member add 00:21:d8:fa:fd:a0

config mobility multicast-mode {enable | disable} local_group_multicast_address

(WLC1) > config mobility multicast-mode enable

config mobility group multicast-address group_name IP_address

(WLC1) > config mobility group multicast-address Test

See the verification of Mobility Summary by using this command:

Show mobility Summary

(WLC1) >show mobility summary
 Symmetric Mobility Tunneling (current) .......... Enabled
 Symmetric Mobility Tunneling (after reboot) ..... Enabled
 Mobility Protocol Port........................... 16666
 Default Mobility Domain.......................... Test
 Multicast Mode .................................. Disabled
 Mobility Domain ID for 802.11r................... 0x840e
 Mobility Keepalive Interval...................... 10
 Mobility Keepalive Count......................... 3
 Mobility Group Members Configured................ 2
 Mobility Control Message DSCP Value.............. 0
 Controllers configured in the Mobility Group
 MAC Address        IP Address       Group Name                        Multicast IP     Status
 00:21:d8:fa:66:00       Test                              Up
 00:21:d8:fa:fd:a0       Test                              Up
 (WLC1) >


WLC WebAuth configuration

In this post we will see how to implement and configure WLC to support internal Webauth.
Web authentication is a Layer 3 security feature that causes the controller to not allow IP traffic (except DHCP and DNS -related packets) from a particular client until that client has correctly supplied a valid username and password.
Web authentication is mostly used to deploy a guest-access network. We must remember that web authentication does not provide data encryption. Webauth is an authentication method without encryption.

Web authentication can be performed using:

  • Default login window on the WLC
  • Modification of the default login window on the WLC
  • A customized login window that we download to the controller
  • A customized login window that we configure on an external web server (External web authentication)

In this post we will only see the starting 3 ways because I don’t have any external webserver.

Let’s start with Configuration of WLC. We will follow these steps:

  1. Create a dynamic interface and fill all the required details.
  2. Create a WLAN and apply the settings.
  3. Configure WLC for Webauth (Internal).
  4. Create local user for testing.
  5. Verification

1. Create a dynamic interface and fill all the required details.

From WLC GUI, Choose Controller > Interface > New and fill the details:
IP Address—
Netmask— (24 bits)
Port Number—1
Primary DHCP Server— Management IP for internal DHCP server)



Click Apply to save the changes.

2. Create a WLAN and apply the settings:

From the WLC GUI, click WLAN in the menu at the top, and click New on the upper right side. This page will appear. Fill Profile name and SSID.


Click Apply.

A new WLANs > Edit window appears.
Check the status box to enable the WLAN.
From the Interface menu, select the name of the VLAN interface (webauth) that we created above.
Check the Broadcast SSID box.


Click on Security Tab
Click Layer 2 security and set to None.


Click the Layer 3 tab
Check the Web Policy box and choose the Authentication option.


Then click Apply from upper right side to save changes.

3. Configure WLC for Webauth(Internal).

Internal web authentication is the by default web authentication type on WLCs. NO need to change the configuration.

4. Create local user for testing:

We can use 3 ways:
Local authentication, RADIUS server, LDAP server
In this post we will tests with Local authentication.

WLC GUI, choose Security > AAA > Local Net Users > New
Enter the username, password and WLAN profile from drop down box.


Click Apply
Here we created 2 users:
Username: Sandeep, Password: webauth123
Username: Sandeep1, Password: webauth12345

5. Verification

Default login window on the WLC
1. Connect with Webauth WLAN.


2. Then a new browser will automatically open or we have to manually enter virtual interface IP from WLC : A Login window will appears
***In my WLC I have Virtual interface IP as

3. Enter the username and password of the Local Net User that we created:
Username: sandeep, Password: webauth123

Modification of the default login window on the WLC

1. Login to WLC and modify the default login window by choosing Security > Web Auth > Web Login Page and click on Apply to save it. I changed the headline and message content.


2. Now connect to webauth WLAN. Login page will appear like this.
3. Enter the username and password.


A customized login window that we download to the controller

1. To download a customized login page, first start a TFTP/FTP server and put the login page in their root directory then login to WLC GUI, click on Commands and the details.

2. Change the WLAN setting.
WLAN > click on WLAN ID then Security > Layer3,
Select the Over-ride Global Config box
Choose Customized (Downloaded) webauth type from drop down box and select the login and login failure page then click apply.

3. Connect to WLAN “webauth” then this login page will appear.


4. Enter the username/Password and click on I agree with Policy Above.


Here is the complete Web Authentication Process(How it works: )

• We open a web browser and enter a URL, The client sends out a DNS request for this URL to get the IP for the destination. The WLC bypasses the DNS request to the DNS server and the DNS server responds back with a DNS reply, which contains the IP address of the destination This, in turn, is forwarded to the wireless clients.
*** In my above post I used DNS server as

• The client then tries to open a TCP connection with the destination IP address. It sends out a TCP SYN packet destined to the IP address of

• The WLC has rules configured for the client and hence can act as a proxy for It sends back a TCP SYN-ACK packet to the client with source as the IP address of www. The client sends back a TCP ACK packet in order to complete the three way TCP handshake and the TCP connection is fully established.

• The client sends an HTTP GET packet destined to www. The WLC intercepts this packet and sends it for redirection handling. The HTTP application gateway prepares a HTML body and sends it back as the reply to the HTTP GET requested by the client. This HTML makes the client go to the default webpage URL of the WLC, for example, http://<Virtual-Server-IP>/login.html.

• The client closes the TCP connection with the IP address, for example, www.

• Now the client wants to go to Therefore, the client tries to open a TCP connection with the virtual IP address of the WLC. It sends a TCP SYN packet for to the WLC.

• The WLC responds back with a TCP SYN-ACK and the client sends back a TCP ACK to the WLC in order to complete the handshake.

• The client sends a HTTP GET for /login.html destined to in order to request for the login page.

• This request is allowed up to the Web Server of the WLC, and the server responds back with the default login page. The client receives the login page on the browser window where the user can go ahead and log in.

Fast SSID Change

Today I faced an issue on my iPhone while changing SSID, Here is the problem explanation and solution:


WLC have software version
WLC Model: AIR-WLC2106-K9

There are two SSID’s from same WLC / AP. If I connected to one and try to connect to other, iPhone shows unable to connect: see the screenshot:

Pic1: Handy connected with RSCCIEW SSID


Pic2: When I tried to change to different SSID its show this:


Debugs in WLC shows that it’s connected and getting an IP.

(WLC1) >*apfMsConnTask_0: Jun 05 13:56:04.571: 54:26:96:3e:4b:ee Association received from mobile on AP 00:22:bd:98:3a:30
 *apfMsConnTask_0: Jun 05 13:56:04.572: 54:26:96:3e:4b:ee Deleting client immediately since WLAN has changed
 *apfMsConnTask_0: Jun 05 13:56:04.572: 54:26:96:3e:4b:ee Scheduling deletion of Mobile Station:  (callerId: 50) in 1 seconds
 *apfMsConnTask_0: Jun 05 13:56:04.883: 54:26:96:3e:4b:ee Ignoring 802.11 assoc request from mobile pending deletion

But still it’s showing connected and getting IP.


There is an option in WLC to enable FAST SSID change. By default its disable.

When fast SSID changing is enabled, the controller allows clients to move between SSIDs. When the client sends a new association for a different SSID, the client entry in the controller connection table is cleared before the client is added to the new SSID. When fast SSID changing is disabled, the controller enforces a delay before clients are allowed to move to a new SSID.

Enable FAST SSID via GUI:

  1. Login WLC GUI: Go to Controller to open the General page.
  2. From the Fast SSID Change drop-down list, choose Enabled to enable this feature
  3. Click Apply
  4. Click Save Configuration on the right side on top.


Enable FAST SSID via CLI:

  1. Enable or disable fast SSID changing by entering this command:

config network fast-ssid-change {enable | disable}

(WLC1) >config network fast-ssid-change ?
 enable/disable] Enable or disables fast SSID changing for mobile stations
(WLC1) >config network fast-ssid-change enable
  1. Save your changes by entering this command:

save config

 (WLC1) >save config
 Are you sure you want to save? (y/n) y
 Configuration Saved!

Pic3: Just after change to enable I tried again and this was the resultJ


Thats all we need to switch quickly 🙂