which antenna gets deactivated when you provide less than full power to a Cisco 3700 ?

A question was asked on Cisco Support Community (CSC) enquiring about what antenna is deactivated when a Cisco 3700 access point doesn't receive a full 16.1 Watts. 

We have purchased 3702e and some of these access points can only get PoE (802.3af). Which antenna will be activated in this case?

802.3at                 4x4:3 on 2.4/5 GHz                         16,1W
802.3af                 3x3:3 on 2.4/5 GHz                         15,4W

Thats a good question and it had me thinking. So I tapped my Cisco CSE, Carlos. BTW Carlos is one of the best CSE’s you’ll find. I’m very fortunate to have him as our CSE. The guy has memory recall with such precision it’s scary. Not to mention he is a CCIE R/S and W. 

When an access point isn't provided full power it can deactivate some combination of radio chains and spatial streams. Manufactures can dial back the access points performance while still providing reliable WiFi communications. This allows flexibility with power at the switch power level (PoE).

We’ll focus on the Cisco 3700. The data sheet shows 802.3at and 802.3af power combinations. Less power, less chains and streams. More power, more chains and streams.

EXAMPLES

From a Cisco 3700 access point do:  show controllers dot11Radio X.

802.3at POWER PROVIDED TO CISCO 3700

In this example you will see the access point is fully powered. We can tell this because of the the number of antennas used for RX and TX. A,B,C and D.

Antenna:                        Rx[a b c d ]
                                    Tx[a b c d  ofdm all]

802.3af POWER PROVIDED TO CISCO 3700

In this example you will see the access point is not fully powered. The access point was provided .af power. We can tell this because of the the number of antennas used for RX and TX. A,B, and C and the mention “Radio on Low Power Mode due to PoE, restricted to 3 antennas”

Antenna:                        Rx[a b c ]
                                     Tx[a b c  ofdm all]

A,B,C, and D

You might be wondering which antenna port is D. On a Cisco 3700E look closely at the antenna bulk head. Each one is identified with A,B,C, and D. In this case the D antenna, it is located in the lower left of the 3700 access point. 

Client Debug Macro Change - Cisco code: 7.6.130.0 - 8.0.110.0

 A quick blog post on an observation I made while debugging in the lab. The command debug client enables a set variable of commands which enable muliple debugs. You can see what these commands are with the “show debug” command. 

Notice the change in the commands enabled between 7.6 and 8.0. 

Cisco client debug - 802.11 Association Status Code

When you enable client debug you can be hit with a ton of information. One of the things I look at is the 802.11 association status code. The status code is very telling. It can provide information about your client and if there is a connection issue. Another tool to add to your bag of tricks. 

Lets take a peek at a debug log

*apfMsConnTask_0: May 11 23:31:21.186: b4:f0:ab:e3:19:6a 0.0.0.0 8021X_REQD (3) DHCP Not required on AP 08:1f:f3:e1:8f:c0 vapId 4 apVapId 4for this client

*apfMsConnTask_0: May 11 23:31:21.186: b4:f0:ab:e3:19:6a Not Using WMM Compliance code qosCap 00

*apfMsConnTask_0: May 11 23:31:21.186: b4:f0:ab:e3:19:6a 0.0.0.0 8021X_REQD (3) Plumbed mobile LWAPP rule on AP 08:1f:f3:e1:8f:c0 vapId 4 apVapId 4

*apfMsConnTask_0: May 11 23:31:21.186: b4:f0:ab:e3:19:6a apfMsAssoStateInc

*apfMsConnTask_0: May 11 23:31:21.186: b4:f0:ab:e3:19:6a apfPemAddUser2 (apf_policy.c:223) Changing state for mobile b4:f0:ab:e3:19:6a on AP 08:1f:f3:e1:8f:c0 from Idle to Associated

*apfMsConnTask_0: May 11 23:31:21.186: b4:f0:ab:e3:19:6a Stopping deletion of Mobile Station: (callerId: 48)

*apfMsConnTask_0: May 11 23:31:21.186: b4:f0:ab:e3:19:6a Sending Assoc Response to station on BSSID 08:1f:f3:e1:8f:c0 (status 0) ApVapId 4 Slot 0

*apfMsConnTask_0: May 11 23:31:21.186: b4:f0:ab:e3:19:6a apfProcessAssocReq (apf_80211.c:5272) Changing state for mobile b4:f0:ab:e3:19:6a on AP 08:1f:f3:e1:8f:c0 from Associated to Associated

Our debug shows a status code of 0. Referencing our chart below we will find our association was a success. 

802.11 Association Status Codes

https://supportforums.cisco.com/docs/DOC-33185

Code	802.11 definition	Explanation
0	Successful
1	Unspecified failure	For example : when there is no ssid specified in an association request
10	Cannot support all requested capabilities in the Capability Information field	Example Test: Reject when privacy bit is set for WLAN not requiring security
11	Reassociation denied due to inability to confirm that association exists	NOT SUPPORTED
12	Association denied due to reason outside the scope of this standard	Example : When controller receives assoc from an unknown or disabled SSID
13	Responding station does not support the specified authentication algorithm	For example, MFP is disabled but was requested by the client.
14	Received an Authentication frame with authentication transaction sequence number out of expected sequence	If the authentication sequence number is not correct.
15	Authentication rejected because of challenge failure
16	Authentication rejected due to timeout waiting for next frame in sequence
17	Association denied because AP is unable to handle additional associated stations	Will happen if you run out of AIDs on the AP; so try associating a large number of stations.
18	Association denied due to requesting station not supporting all of the data rates in the BSSBasicRateSet parameter	Will happen if the rates in the assoc request are not in the BasicRateSet in the beacon.
19	Association denied due to requesting station not supporting the short preamble option	NOT SUPPORTED
20	Association denied due to requesting station not supporting the PBCC modulation option	NOT SUPPORTED
21	Association denied due to requesting station not supporting the Channel Agility option	NOT SUPPORTED
22	Association request rejected because Spectrum Management capability is required	NOT SUPPORTED
23	Association request rejected because the information in the Power Capability element is unacceptable	NOT SUPPORTED
24	Association request rejected because the information in the Supported Channels element is unacceptable	NOT SUPPORTED
25	Association denied due to requesting station not supporting the Short Slot Time option	NOT SUPPORTED
26	Association denied due to requesting station not supporting the DSSS-OFDM option	NOT SUPPORTED
27-31	Reserved	NOT SUPPORTED
32	Unspecified, QoS-related failure	NOT SUPPORTED
33	Association denied because QAP has insufficient bandwidth to handle another QSTA	NOT SUPPORTED
34	Association denied due to excessive frame loss rates and/or poor conditions on current operating channel	NOT SUPPORTED
35	Association (with QBSS) denied because the requesting STA does not support the QoS facility	If the WMM is required by the WLAN and the client is not capable of it, the association will get rejected.
36	Reserved in 802.11	This is used in our code ! There is no blackbox test for this status code.
37	The request has been declined	This is not used in assoc response; ignore
38	The request has not been successful as one or more parameters have invalid values	NOT SUPPORTED
39	The TS has not been created because the request cannot be honored; however, a suggested TSPEC is provided so that the initiating QSTA may attempt to set another TS with the suggested changes to the TSPEC	NOT SUPPORTED
40	Invalid information element, i.e., an information element defined in this standard for which the content does not meet the specifications in Clause 7	Sent when Aironet IE is not present for a CKIP WLAN
41	Invalid group cipher	Used when received unsupported Multicast 802.11i OUI Code
42	Invalid pairwise cipher
43	Invalid AKMP
44	Unsupported RSN information element version	If you put anything but version value of 1, you will see this code.
45	Invalid RSN information element capabilities	If WPA/RSN IE is malformed, such as incorrect length etc, you will see this code.
46	Cipher suite rejected because of security policy	NOT SUPPORTED
47	The TS has not been created; however, the HC may be capable of creating a TS, in response to a request, after the time indicated in the TS Delay element	NOT SUPPORTED
48	Direct link is not allowed in the BSS by policy	NOT SUPPORTED
49	Destination STA is not present within this QBSS	NOT SUPPORTED
50	The Destination STA is not a QSTA	NOT SUPPORTED
51	Association denied because the ListenInterval is too large	NOT SUPPORTED
200 (0xC8)	Unspecified, QoS-related failure. Not defined in IEEE, defined in CCXv4	Unspecified QoS Failure. This will happen if the Assoc request contains more than one TSPEC for the same AC.
201 (0xC9)	TSPEC request refused due to AP’s policy configuration (e.g., AP is configured to deny all TSPEC requests on this SSID). A TSPEC will not be suggested by the AP for this reason code. Not defined in IEEE, defined in CCXv4	This will happen if a TSPEC comes to a WLAN which has lower priority than the WLAN priority settings. For example a Voice TSPEC coming to a Silver WLAN. Only applies to CCXv4 clients.
202 (0xCA)	Association Denied due to AP having insufficient bandwidth to handle a new TS. This cause code will be useful while roaming only. Not defined in IEEE, defined in CCXv4
203 (0xCB)	Invalid Parameters. The request has not been successful as one or more TSPEC parameters in the request have invalid values. A TSPEC SHALL be present in the response as a suggestion. Not defined in IEEE, defined in CCXv4	This happens in cases such as PHY rate mismatch. If the TSRS IE contains a phy rate not supported by the controller, for example. Other examples include sending a TSPEC with bad parameters, such as sending a date rate of 85K for a narrowband TSPEC.

How To - WISM1 to WISM2 Migration

I recently migrated our WISM1 solution to WISM2s.  I want to share my experience and project gotcha list to help you with your installation.

SUP 720 Firmware

A few things need to be addressed prior to your WISM 2 migration. 

1. You will need to make sure your SUPS are at 12.2(33)SXJ. This is a requirement for WISM2. Otherwise your SUPs wont recognize the WISM2s.
2. If your SUP was configured manually to support the WISM1, meaning not configured with the “auto” WISM commands you will need to redo the WISM commands after you upgrade the SUP. 
3. If you did the auto wism commands during your initial WISM1 installation and installed the WISM2. Your old port channels may still be present. You can check this with a #SHOW (WLAN-DIST-A#show etherchannel summary)
4. Each WISM2 blade will map to a single port channel. If you see more portchannels. You can simply “no” the auto WISM commands, reboot and the reapply the auto WISM commands. This should clean up your excess port channels. It did for me.

Config Transfer - WISM1 to WISM2 

There has been discussion in the past whether or not you can transfer WLC config from a WISM1 to a WISM2. You can but you should note the below. 

Follow the below guidelines: 

1. Make sure both controllers are on the same code prior to any code transfer
2. Pull the config from WISM1 by doing a TFTP transfer
3. Upload the config to WISM2 by doing a TFTP transfer 
4. Update the mobility group IP address on all controllers in mobility group adding new WISM2 and removing old WISM1
5. Remember to anchor your GUEST WLAN. 

Prerequisites

Requirements

This is a list of components that are required when deploying WiSM2 in the Catalyst chassis:

Device/Application	SW Versions
Catalyst 650X with 720 Sup*	12.2(33)SXJ or Higher
Ethernet Line-Cards - Tested and Compatible with WiSM2	6148, 6516, 6548, 6704-10Gb, 6708-10Gb, 6716-10Gb, 6748 and 6724
WiSM2 Controllers	7.0 MR1 ver 7.0.116.0
WCS	7.0 MR1 ver 7.0.172.0

* The Catalyst chassis on which the Cisco WiSM2 is installed needs a Supervisor 720 module.

Mobility Compatibility Matrix 

http://www.cisco.com/en/US/docs/wireless/controller/5500/tech_notes/Wireless_Software_Compatibility_Matrix.html#wp102554

WISM2 Deployment Guide

http://www.cisco.com/en/US/products/hw/modules/ps2706/products_tech_note09186a0080b7c904.shtml  

Thanks Scott, Leo and Steve for the edit ..

WLC: AP Managers Are Pingable - 7.x onwards

Since the very beginning the AP manager on a Cisco WLC would never respond to pings. Well that has all changed if you use LAG and an AP manager with 7.x code!

I like how Cisco hides little nuggets in their documentation. It states, in LAG mode, the management and AP manager uses the same base LAG MAC address.

---

Note With the 7.0 release onwards, the MAC address of the management interface and the AP-manager interface is the same as the base LAG MAC address.

LAB

A show ARP on the distribution switch you can see the MAC is identical for both the manager and AP manager.

NOTE --

This was tested on 4402,4404 and 5508 model controllers.

AP manager(s) aren't needed with a 5508.

This only applies to a WLC in LAG mode w/ AP Manager

Additional Reading Material:

http://www.cisco.com/en/US/docs/wireless/controller/7.0/configuration/guide/c70mint.html#wp1117168

Recover WEP, Admin, Guest account Password from WLC

Salil Prabhu from Cisco TAC did a great post on how to recover WEP, ADMIN and Guest account passwords. Note this will not yield the PSK key. As you can not pull the PSK from a WLC.

Procedure to Recover WEP,Admin,Guest account Password from WLC

Step 1 :

1. (Cisco Controller) >show switchconfig

802.3x Flow Control Mode......................... Disable
FIPS prerequisite features....................... Disabled
secret obfuscation............................... Enabled

(Cisco Controller) >config switchconfig secret-obfuscation disabled

Secret (de-)obfuscation may take a few minutes.

Please wait...  Done!

(Cisco Controller) >config passwd-cleartext enable

The way you see your passwds will be changed

You are being warned.

Enter admin password: ***********

Enabling cleartext viewing of passwords

Step 2:

2. Download config from the WLC. Commands --> Upload configuration from
WLC to tftp server.

Step 3:
3. Open the file in notepad :

WEP :

config wlan security static-wep-key encryption 4 40 hex encrypt 0 0 0 128 313233343500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000  1

40 = 40 bit key

ADMIN :

config mgmtuser add encrypt admin1 0 0 0 8 436973636f31323300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 read-write

Guest-Account :

config netuser add encrypt username guest-1 password 0 0 0 7 67756573742d310000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000  wlan 0 usertype guest lifetime 86400

Step 4:

4. Use this tool to convert to Ascii : ( Use red colour digits ..)

http://www.dolcevie.com/js/converter.html

WEP : Key size = 40bit.
HEX :3132333435 
Ascii : 12345 ( using the tool ) 


ADMIN : Username : admin1 
HEX : 436973636f313233 
Ascii : Cisco123 

Guest-Account: Username: guest-1 
HEX: 67756573742d31  
Ascii : guest-1 

WLC: Configuring Dynamic Anchoring for Clients with Static IP Addresses

If you have a WLAN that requires a large mobility area for roaming and your client needs to be static. This feature is something you should consider! This will allow you to break up these large subnets into much smaller sizeable subnets while still allowing static address on your mobile devices. 

In Cisco 7.0.116.0 release a new feature "Configuring Dynamic Anchoring for Clients with Static IP Addresses" appears to have resolved my issue.

P.S. Below is a cut and paste from 7.0.116.0 config manual. Here is the link:

http://www.cisco.com/en/US/docs/wireless/controller/7.0MR1/configuration/guide/cg_mobility.html#wp1208318

Configuring Dynamic Anchoring for Clients with Static IP Addresses

At times you may want to configure static IP addresses for wireless clients. When these wireless clients move about in a network, they could try associating with other controllers. If the clients try to associate with a controller that does not support the same subnet as the static IP, the clients fail to connect to the network. You can now enable dynamic tunneling of clients with static IP addresses.

Dynamic anchoring of static IP clients with static IP addresses can be associated with other controllers where the client's subnet is supported by tunneling the traffic to another controller in the same mobility group. This feature enables you to configure your WLAN so that the network is serviced even though the clients use static IP addresses.

How Dynamic Anchoring of Static IP Clients Works 

 The following sequence of steps occur when a client with a static IP address tries to associate with a controller:

1. When a client associates with a controller, for example, WLC-1, it performs a mobility announcement. If a controller in the mobility group responds (for example WLC-2), the client traffic is tunneled to the controller WLC-2. As a result, the controller WLC 1 becomes the foreign controller and WLC-2 becomes the anchor controller.

2. If none of the controllers respond, the client is treated as a local client and authentication is performed. The IP address for the client is updated either through an orphan packet handling or an ARP request processing. If the client's IP subnet is not supported in the controller (WLC-1), WLC-1 sends another static IP mobile announce and if a controller (for example WLC-3) which supports the clients subnet responds to that announce, the client traffic is tunneled to that controller WLC-3. As a result, the controller WLC 1 becomes the export foreign controller and WLC-2 becomes the export anchor controller.

3. Once the acknowledgement is received, the client traffic is tunneled between the anchor and the controller (WLC-1).

---

Note If you configure WLAN with an interface group and any of the interfaces in the interface group supports the static IP client subnet, the client is assigned to that interface. This situation occurs in local or remote (static IP Anchor) controller.

---

---

Note A security level 2 authentication is performed only in the local (static IP foreign) controller, which is also known as the exported foreign controller.

---

---

Note Do not configure overridden interfaces when you perform AAA for static IP tunneling, this is because traffic can get blocked for the client if the overridden interface does not support the client's subnet. This can be possible in extreme cases where the overriding interface group supports the client's subnet.

---

---

Note The local controller must be configured with the correct AAA server where this client entry is present.

---

The following restrictions apply when configuring static IP tunneling with other features on the same WLAN:

•Auto anchoring mobility (guest tunneling) cannot be configured for the same WLAN.

•Hybrid-REAP local authentication cannot be configured for the same WLAN.

•The DHCP required option cannot be configured for the same WLAN.

---

Note You cannot configure dynamic anchoring of static IP clients with hybrid REAP local switching.

---

Using the GUI to Configure Dynamic Anchoring of Static IP Clients

To configure dynamic anchoring of static IP clients using the controller GUI, follow these steps:

---

Step 1 Choose WLANs to open the WLANs page.

Step 2 Click the ID number of the WLAN on which you want to enable dynamic anchoring of IP clients. The WLANs > Edit page is displayed.

Step 3 Choose the Advanced tab to open the WLANs > Edit (Advanced) page.

Step 4 Enable dynamic anchoring of static IP clients by selecting the Static IP Tunneling check box.

Step 5 Click Apply to commit your changes.

Using the CLI to Configure Dynamic Anchoring of Static IP Clients

To configure dynamic anchoring of Static IP clients using the controller CLI, use the following commands:

config wlan static-ip tunneling {enable | disable} wlan_id— Enables or disables the dynamic anchoring of static IP clients on a given WLAN.

To monitor and troubleshoot your controller for clients with static IP, use the following commands:

•show wlan wlan_id—Enables you to see the status of the static IP clients feature.

..............

Static IP client tunneling.............. Enabled

..............

•debug client client-mac

•debug dot11 mobile enable

•debug mobility handoff enable

Configuring Foreign Mappings

Auto-Anchor mobility, also known as Foreign Mapping, allows you to configure users that are on different foreign controllers to obtain IP addresses from a subnet or group of subnets.

Using the GUI to Configure Foreign MAC Mapping

To configure a foreign mapping using the controller GUI, follow these steps:

---

Step 1 Choose the WLANs tab.

The WLANs page appears listing the available WLANs.

Step 2 Click the Blue drop down arrow for the desired WLAN and choose Foreign-Maps.

The foreign mappings page appears. This page also lists the MAC addresses of the foreign controllers that are in the mobility group and interfaces/interface groups.

Step 3 Choose the desired foreign controller MAC and the interface or interface group to which it must be mapped and click on Add Mapping.

---

Using the CLI to Configure Foreign Controller MAC Mapping

To configure foreign controller MAC mapping, use this command:

config wlan mobility foreign-map add wlan-id foreign_ctlr_mac interface/interface_grp name

To configure a foreign mappings, use this command:

config wlan mobility foreign-map add wlan_id interface

WLC: How Cisco Virtualizes The Base Radio MAC ADDRESS On The WLC – Did you know?

This is a quick blog post on how Cisco uses the VIRTUAL MAC ADDRESS for BSSID(s).

As you add SSIDs (Service Set Identification(s)) to an access point each BSSID (Basic Service Set Identifier) receives a virtual mac address. This allows for wireless network segmentation as well as for wireless clients to communicate via LAYER 2 with each access point BSSID.

A Cisco access point takes the base radio mac address and then virtualizes the mac address as additional SSIDs are added. What is interesting is how the virtual MAC addresses are selected. Pay very close attention to the 2.4GHz and 5 GHz radios and BSSIDs.

BASE RADIO MAC ADDRESS

You can find the base radio mac address under WIRELESS->Select Access Point

 Virtualized BSSID(s)

I configured a controller with 16 SSIDs. Each SSID named as 01,02,03,04,05,06, 07,08,09,10,11,12,13,14,15 and 16. I then enabled both the 2.4 GHz and 5 GHz radios. Cisco WLC access points have a limit of 16 SSIDs on each radio.

I then fired up AirMagnet WiFi Analyzer Pro to conduct a capture.

Note: The access point base radio mac address ends in A9:10.

2.4 GHz – Notice the first SSID ‘01’ is assigned the BASE RADIO MAC ADDRESS A9:10. The second SSID is appended with a .11 and so on. 

5GHz – Notice the sixteenth SSID ‘16’ is assigned the BASE RADIO MAC ADDRESS A9:10. The fifteenth SSID is appended with a .11 and so on.

NOTE: The VIRTUAL MAC ADDRESSES get reused by the access point on both the 2.4GHz and the 5GHz radios.

Virtualized BSSID Assignment

Keep in mind, the assignment or order in which the virtual mac addresses are assigned in the above example has nothing to do with the WLAN IDs that are configured in the WLC. Rather, the virtual mac addresses are assigned in order by how the SSID is assigned to the access point. Lets take a look at an AP Group for example.

AP GROUP EXAMPLE

In the below example I created an AP GROUP where I assigned SSIDs 01,05 and 10. Note the WLAN ID assignment from the WLC in the AP GROUP (see below). Then note the AirMagnet capture where SSIDs 01,05 and 10 are mentioned. As you can see, the BSSIDs did not take the WLC WLAN ID when compared to our last example. Rather the virtual mac address starts at the BASE RADIO mac for the first BSSID and the counts down for the 2.4GHz and starts on the opposite end for the 5 GHz.

 

CONCLUSION

As you apply SSIDs to an access point the base radio mac address is applied to the first BSSID on the 2.4GHz radio. If you enable the 5 GHz radio you will see that the same SSID is given the 'back end' of the HEX range from the base radio mac address and counts down in HEX positions as additional SSIDs are added. 

ENJOY!

WLC: Radius Statistics Command

It is always nice to get emails from twitter and blog peeps. I received an email from Bruce from Erie, PA asking:

 Hi George,

Have been enjoying reading the various information you have posted… but haven’t seen anything yet on one of my favorite autonomous commands that I haven’t found a WLC equivalent yet.

sh aaa server

Since we normally have 3 ACS servers defined on all implementations, this simple command lets me see quickly (after running “clear aaa counters server all”) which specific ACS server I should be looking on for failure/success logs.  On WCS/WLC, I have yet to find anything so simple to quickly get me that information.

If you are aware of a WLC version of it, would love to see it covered as a topic.  And if not, I still find my80211 to be very useful and enjoyable!  Keep up the good work.

Thanks,
Bruce

RADIUS Statistics

Bruce, my friend, you are in luck! The following commands are the equivalent commands on the WLC

>show radius auth statistics

>clear stats radius auth all

Good information

When troubleshooting radius issues these stats come in handy! When your radius server is on the blink or if there is a configuration issue somewhere in the 'line' you can see if anything is passing through the WLC.  Remember the WLC acts as the "authenticator" and simply passes the EAP packets between the client and the radius server "authentication server". No real heavy lifting is done by the WLC during this process.

show radius auth statistics output

(WiSM-slot3-1) >show radius auth statistics

Authentication Servers:

Server Index......................................... 1
Server Address...................................... 192.168.1.142
Msg Round Trip Time.............................. 4 (msec)
First Requests....................................... 5360993
Retry Requests...................................... 8772
Accept Responses.................................. 518894
Reject Responses................................... 64866
Challenge Responses.............................. 4777060
Malformed Msgs..................................... 0
Bad Authenticator Msgs........................... 0
Pending Requests................................... 0
Timeout Requests................................... 9299
Unknowntype Msgs................................. 0
Other Drops........................................... 321

Server Index........................................ 2
Server Address..................................... 192.168.1.100
Msg Round Trip Time.............................. 5 (msec)
First Requests....................................... 3722718
Retry Requests...................................... 5533
Accept Responses.................................. 371506
Reject Responses................................... 37869
Challenge Responses.............................. 3313262
Malformed Msgs..................................... 0
Bad Authenticator Msgs........................... 0
Pending Requests................................... 0
Timeout Requests................................... 5952
Unknowntype Msgs................................. 0
Other Drops...................................... 296



WLC: Management via Wireless – Did you know ?

In recent weeks, I fielded a number of questions on the forums about “WLC Management via Wireless”. I thought, I would follow up with a quick blog post on the subject.



How it works:

On the Cisco WLC there is a security feature that allows you to ENABLE or DISABLE WLC management via wireless. But, there is a catch in exactly what to expect and how it works. Folks new to Cisco WLCs may not catch this right away or scratch their head when a WLC is disabled, but yet they can still access the WLC over the wireless medium.  

When the management via wireless feature is disabled. Any wireless user (Admin or otherwise) will not be able to manage the Cisco WLC over wireless. HTTP,HTTPS,SSH and TELNET are ‘blocked’ from the wireless medium.

But, there is a catch:

When the management via wireless feature is DISABLE on the WLC, it only pertains to the WLC in which the wireless user is associated to. Wireless users can still manage (other) WLCs even though “Management via Wireless” is disabled.

Example:#1 ‘Management via Wireless Disabled’

The user in this example can not HTTP,HTTPS, SSH or TELNET into the controller management IP address in which they are associated to via the access point.

 
Example:#2 ‘Management via Wireless Disabled’

The user can access other WLCs (the ones he is not associated to), even though the management over wireless is disabled.

CLI Config:

In the CLI the >show network summary yields the status of the management via wireless

You can enable or disable management via wireless with the following CLI command:

> network mgmt-via-wireless

(WiSM-slot1-1) config>network mgmt-via-wireless ?

enable         Enables this setting.
disable        Disables this setting.

GUI Config:

In the GUI GO ->MANAGEMENT-> MGT Via WIRLESS -> (CHECK BOX)

 

WLC: Predownload the Image to the Access Points from the controller CLI

Why preload the image on the access points?

In a large wireless network, preloading the image to the access point may be something of interest to you. This process will lessen the overall downtime of your wireless network during the upgrade process. By preloading a new image to the access points in advance, negates the need to wait for your controllers to update the access points individually, which prolongs the upgrade process.

Normal Upgrade Process w/o preloading the access points

After a Cisco WLC is upgraded and rebooted. Access points drop into the discovery mode. When the access point rejoins the controller, it determines the access point code is different from the WLC. The access point will download the new code from the WLC. The access point upgrade process only takes a minute or so and then an additional minute for the access point to reboot and rejoin a WLC, so you are looking at 2 minutes of downtime for that access point.

The problem with this process, Cisco WLCs can not upload to all the access points at once, unless you have a 5508 WLC! The below list shows how many access points, can be upgraded concurrently, by controller model.

2100-XX                   10 access point max
4402-XX                   10 access point max
4404-XXX                 10 access point max
WiSM                       10 access point max (per controller)
5508-XXX               500 access point max

So, what is the big deal ?

Lets pick on a WiSM, shall we. Suppose you have 150 access points on a controller and the controller can only upgrade 10 access points concurrently at a time.  Your controller would have to go through the upgrade process x15 times. This means access points would be offline not servicing clients until they take the upgrade. Potentially, it could take up to 15 minutes or longer to upgrade all 150 access points in this manner.

How Preloading The Image Speeds Up Your Upgrade Process and Limits Downtime

Certainly, if you have a controller model that is limited to the 10 AP download limit. The preload process will speed up your upgrade and lessen your downtime. I’ll go into the details below, but how it works is simple.

You push the new code to the WLC. Then from the WLC you push the new code to the access points while still in a live environment.

PRELOAD STEPS

1.     Upgrade your WLC with your new image

2.     Preload the image to the access points

3.     Check image “positions” on the WLC and access points

Preload the image to the access points

You can do this via WCS or in the WLC CLI. I will show you the WLC CLI process.

(WiSM-slot1-1) >config ap image predownload ?

primary        Predownload an image to a Cisco AP from the controller's Primary image.
backup         Predownload an image to a Cisco AP from the controller's Backup image.

You have 2 positions where you can install the code (primary or backup). I call them positions, they are spots in memory stored in the access point.  The primary position is the image that will get loaded when the access point reboots.

Check the current images and image positions on the controller and access points

ACCESS POINTS – Cisco access points (model dependency) allow you to store 2 images on the AP. You can use the following command to see the images on the access points and the position they are in.

(WiSM-slot8-2) >show ap image all

Total number of APs..............................2
Number of APs
Initiated............................................. 0
Predownloading................................... 0
Completed predownloading................... 0
Not Supported..................................... 0
Failed to Predownload........................... 0

AP Name            Primary Image      Backup Image   Status          Version        Next Retry Time  Retry

------------------ -------------- -------------- --------------- -------------- ---------------- ------------
TEST1               6.0.196.159            0.0.0.0                  None            None           NA               NA        

TEST2               6.0.196.159            0.0.0.0                  None            None           NA               NA       

*Primary Image – This is the image that loads when the AP is booted
*Backup Image – This is the image that is stored as a backup

CONTROLLERS  -  Cisco controllers allow you to store 2 images as well. You can see the images and their positions with the show boot command from the WLC CLI.

(WiSM-slot8-2) >show boot

Primary Boot Image............................... Code 7.0.98.0 (active)
Backup Boot Image................................ Code 6.0.196.159

Caution 

When you upgrade your WLC the new image goes into the (active) position. If your intentions are to do the upgrade at a later time. It is important to “swap” the image from the primary location to the backup location. This is in case the controller reboots by accident. This goes for the access point images as well. 

Controller and Access Point Image Swap

Access Point - Swapping the image can done by a single access point or by all access points

(WiSM-slot8-2) >config ap image swap all

(WiSM-slot8-2) >show ap image all      

Total number of APs.............................. 2

Number of APs
Initiated............................................ 0
Predownloading.................................. 0
Completed predownloading.................. 2
Not Supported.................................... 0
Failed to Predownload.......................... 0

AP Name            Primary Image  Backup Image   Status          Version        Next Retry Time  Retry

------------------ -------------- -------------- --------------- -------------- ---------------- ------------

TEST1                        7.0.98.0            6.0.196.159    Complete        7.0.98.0       NA               NA        
TEST2                        7.0.98.0            6.0.196.159    Complete        7.0.98.0       NA               NA        

Controller- Swapping the image on the controller

(WiSM-slot8-2) >config boot primary (backup)

(WiSM-slot8-2) >show boot          

Primary Boot Image............................... Code 7.0.98.0 (active)
Backup Boot Image................................ Code 6.0.196.159

Things you should know…

When you do a preload push there is a maximum number of concurrent predownloads. It is limited to half the number of concurrent normal image downloads (10 normally / half is 5). The access points not taking the download will then receive a random timer between 180 and 600 seconds. So this means your 4400s will do a preload of 5 access points at a time. The other 95 receive back off timers.

Dependency Homework

Guidelines and Limitations for Predownloading Images (from controller manual)

Keep these guidelines in mind when you use image predownloading:

• Maximum predownload limit: The maximum number of concurrent predownloads is limited to half the number of concurrent normal image downloads on 4400 series controllers; it is limited to 25 concurrent downloads on 5500 series controllers. This limitation allows new access points to join the controller during image downloading.
  
• If you reach the predownload limit, access points that cannot get an image back off and wait for a time between 180 to 600 seconds and then re-attempt the predownload.
  
• For predownloading to be effective, all controllers (primary, secondary, and tertiary) that your access points can join should use the same images for primary and backup images. For example, if you have three controllers, all three should use software release x as the primary image and release y as the backup image. This consistency is important because some controllers reboot more slowly than others, and access points rejoin a controller as soon as they reboot. If a 4400 controller reboots before a 5500 controller, it is important that both controllers are running the same images in case an access point joins one rather than the other.
  
• Before you enter the predownload command, Cisco recommends that you change the active controller boot image to the backup image. This step ensures that if the controller reboots for some reason, it comes back up with the earlier running image, not the partially downloaded upgrade image.
  
• Access points with 16MB total available memory (1130 and 1240 access points) sometimes do not have enough free memory to download an upgrade image, and they automatically delete crash info files, radio files, and any backup images to free up space. However, this limitation does not affect the predownload process because the predownload image replaces any backup image on the access point.
  
• These access point models do not support predownloading of images: 1120, 1230, and 1310.

I hope this helps with yout predownload efforts !

WLC:Generate Third Party Web Authentication Certificate for a WLC

It’s that time of year and our Cisco WLC Web Authentication Certificate is close to expiration. Certificates are not my strong point and its not often I have to deal with them outside of ACS and the controllers. So I wanted to document these steps for my benefit for next go around.

This is a step by step “how to” creating a CSR (Certificate Signing Request) with OPENSSL, processing a third-party certificate that is CHAINED and download it to the Cisco WLC.

Dependency Homework

Its always important to check your dependencies and NEVER assume.

1) WLC versions earlier than 5.1.151.0, web authentication certificates can be only device certificates and DO NOT support chained certificates, ONLY ROOT SIGNED certificates

2) WLC versions 5.1.151.0 and later support chained certificates (up to a level of 2)

3)   ** Certificate Levels **

Level 0 – Use of only a server certificate on WLC
Level 1 – Use of server certificate on WLC and a CA root certificate
Level 2 – Use of server certificate on WLC, one single CA intermediate certificate, and a CA root certificate.
Level 3 -  Use of server certificate on WLC, two CA intermediate certificate, and a CA root certificate. 

4) Entrust does not support root signed certificates (unchained) as of 12/31/2010. Since my anchors are on 4.2.x, looks like I will be upgrading my controller code.

5) When anchoring, the remote and anchor controllers connect using EoIP tunnels. Below is a quick look at supported code levels . Although, Cisco will tell you its best practice to have your Anchors and Remote WLCs on the same version of code.

 

Why a signed certificate on the Cisco Anchor WLC?

The Anchor WLC is configured with HTTPS. When a guest user connects to the wireless guest network they will be presented with a WLC self signed certificate or an expired certificate. As such, this will cause the “please accept” this certificate screen.

By installed a signed CA certificate, you negate this screen and users move directly to the accept screen. Its really a inconvenience to the end user.

OPENSSL

If this is your first time using OPENSSL, it could be a little intimidating, but it isn’t really as bad as you think. Everything is scripted.

Before starting, you will need to download and unzip OPENSSL. You will notice a number of versions. I used windows version ,0.9.8.a to create my CSR.  I unzipped OPENSSL in a folder off my C: drive

C:\openssl>

http://www.openssl.org/

Generate a CSR

A CSR stands for certificate signing request. This is the first step in the certificate process.

After you have OPENSSL installed you want to launch openssl.exe. You then enter the following script.

1)   C:\openssl\bin>openssl.exe

OpenSSL> req –new –newkey rsa:2048 –nodes –keyout mykey.pem –out myreq.pem
Note: The WLC supports a maximum key size of 2048

2)   You will be presented with a number of questions. Your company name, state, country, common name etc. Its important to enter this information correctly. This data gets checked against the CA information on file. It is also important the CN (common name) matches the DNS A record for your virtual IP.

You will also be prompted to enter an optional password. This is important, as it adds an extra layer of security and prevents someone compiling the certificate without the password.

OpenSSL>req −new −newkey rsa:2048 −nodes −keyout mykey.pem −out myreq.pem

Loading 'screen' into random state − done Generating a 2048 bit RSA private key ................................................................++++++ ...................................................++++++

writing new private key to 'mykey.pem'
−−−−−
You are about to be asked to enter information that will be incorporated into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank

For some fields there will be a default value, If you enter '.', the field will be left blank.
−−−−−
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some−State]:TX
Locality Name (eg, city) []:Houston
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Mycompany
Organizational Unit Name (eg, section) []:IT
Common Name (eg, YOUR name) []:guest.yourhospital.org
Email Address []:it@mycompany.com

Please enter the following 'extra' attributes to be sent with your certificate request

A challenge password []:TESTEST
An optional company name []:

OpenSSL>

 3)   Once you are complete. You will find 2 files in the bin folder.

1. mykey.pem
2. myreq.pem

The mykey.pem is your portion of the CSR which will be used later. Keep this in a safe place.

The myreq.pem is your CSR ,which is sent to your CA. If you change the file type from .pem to .txt you will see something similar to this:

 

4) The CA will reply with a digitally signed certificate chain. You will receive three certificates.

1. Root Certificate
2. Intermediate Certificate
3. Device Certificate

5)   The next step, you will want to take the 3 certificates and change the extension to .txt.

Entrust.cer
L1Cchainroot.cer
L1Croot.cer

Once the extensions are converted to .txt. Open notepad and cut and paste the certificates in this order:

−−−−−−BEGIN CERTIFICATE−−−−−−
*Device cert*
−−−−−−END CERTIFICATE−−−−−−
−−−−−−BEGIN CERTIFICATE−−−−−−
*Intermediate CA cert *
−−−−−−END CERTIFICATE−−−−−−−−
−−−−−−BEGIN CERTIFICATE−−−−−−
*Root CA cert *
−−−−−−END CERTIFICATE−−−−−−

 **NOTE THESE ARE NOT REAL CERTIFICATES**

 It is important you put the certs in the correct order -- device, intermediate, root.

1. Device Certificate
2. Intermediate Certificate
3. Root Certificate

 Specific to Entrust … your cert order would be the following:

1. Device Certificate ------------------ L1Croot
2. Intermediate Certificate-----------L1Cchainroot
3. Root Certificate----------------------Entrust

 **NOTE IF YOU OPEN THE ROOT CERTIFICATE THIS WILL CONTAIN YOUR CN (COMMON NAME) **

 6)   Save the file as All-certs.pem

 7)   In this step you will combine your mykey.pem and the All-certs.pem. Open up OPENSLL again. Enter the following:

C:\openssl\bin>openssl.exe

OpenSSL> pkcs12 -export -in All-certs.pem -inkey mykey.pem -out All-certs.p12 -clcerts -passin pass:TESTTEST -passout pass:TESTTEST

Loading 'screen' into random state - done

OpenSSL> pkcs12 -in All-certs.p12 -out final-cert.pem -passin pass:TESTTEST -passout pass:TESTTEST

MAC verified OK

OpenSSL>

**NOTE YOU ENTER THE PASSWORD YOU CREATED DURING THE CSR CREATION **

8)   When you are done you will have 1 file, called final-cert.pem. This is the certificate you will download to your Anchor WLC.

9) Enter your WLC Security ->Web Auth -> Certificate

Check, check box “Download SSL Certifciate” and enter your TFTP information and your certificate password.

WLC: Schedule Reboot Of The WLC From The CLI

Did you know you can schedule a reboot of the WLC in the CLI? This comes in handy if you don’t have a WCS. Lets cover the different automatic reboots . Also this is only in newer code releases. This is not an option in 4.2 releases.

(Cisco_4402_WLC) >reset system ?
at             Reset the system at a specified time.
in             Reset the system after a specified delay.
cancel         Cancel a scheduled reset.
notify-time    Configures trap generation prior to scheduled resets.

Reset System In ->

The (rest system in) command allows you to enter a specific time to have the controller reboot. Also you can call out what image (primary / backup) to load.

(Cisco_4402_WLC) >reset system in 00:01:30 image no-swap reset-aps save-config
System reset is scheduled for Oct 16 22:58:56 2010.
Current local time and date is Oct 16 22:57:26 2010.
Trap will not be generated as total delay is less than the trap time.
Use 'reset system cancel' to cancel the reset.
Configuration will be saved before the system reset.
(Cisco_4402_WLC) >

Rest System At ->

The (rest system at) command allows you to enter a specific date and time to have the controller reboot.  Like reset system in, you can call out the image as well.

 (Cisco_4402_WLC) >reset system at 2010-10-16 23:05:00 image no-swap reset-aps save-config
System reset is scheduled for Oct 16 23:05:00 2010.
Current local time and date is Oct 16 23:02:06 2010.
Trap will not be generated as total delay is less than the trap time.
Use 'reset system cancel' to cancel the reset.
Configuration will be saved before the system reset.
(Cisco_4402_WLC) >

Reset System Cancel ->

Of course, if you scheduled a system reset and you need to cancel it. You would need to apply the reset system cancel command

(Cisco_4402_WLC) >reset system ?
at             Reset the system at a specified time.
in             Reset the system after a specified delay.
cancel         Cancel a scheduled reset.
notify-time    Configures trap generation prior to scheduled resets.

Show Reset ->

To double check your schedule reset you can do the “show rest” command. It outlines the data and events.

(Cisco_4402_WLC) >show reset
System reset is scheduled for Oct 18 10:00:00 2010.
Current local time and date is Oct 16 23:28:15 2010.
All APs will also be reset.
A trap will be generated 10 minutes before each scheduled system reset.
Configuration will be saved before the system reset.

WLC: Debug Transfer Trace

The WLC has a wealth of debug commands. I ran into image problems in my lab this weekend.  If you run into TFTP or IMAGE transfer issues a handy debug is the debug transfer trace / tftp enable.

If you have issues contacting the TFTP server from the WLC or image mounting issues this debug will alert you as to the issue.

debug transfer trace enable

debug transfer tftp enable

Here is an example of the debug transfer trace:

(Cisco_4402_WLC) >debug transfer trace enable
*Oct 17 21:44:25.925: RESULT_STRING: TFTP Code transfer starting.
*Oct 17 21:44:25.925: RESULT_CODE:1
*Oct 17 21:44:29.928: Locking tftp semaphore, pHost=10.10.53.24 pFilename=/SWISMK9-6-0-199-4.aes
*Oct 17 21:44:29.929: Semaphore locked, now unlocking, pHost=10.10.53.24 pFilename=/SWISMK9-6-0-199-4.aes
*Oct 17 21:44:29.929: Semaphore successfully unlocked, pHost=10.10.53.24 pFilename=/SWISMK9-6-0-199-4.aes
*Oct 17 21:52:01.997: tftp rc=0, pHost=10.10.53.24 pFilename=/SWISMK9-6-0-199-4.ae pLocalFilename=/mnt/download/local.tgz
*Oct 17 21:52:01.998: tftp = 6, file_name=/SWISMK9-6-0-199-4.aes, ip_address=10.10.53.24, msg=Unknown error - refer to log
*Oct 17 21:52:01.998: upd_get_code = 6 (target=268435457 msg=Unknown error - refer to log)
*Oct 17 21:52:01.999: RESULT_STRING: TFTP receive complete... extracting components.
*Oct 17 21:52:01.999: RESULT_CODE:6
*Oct 17 21:52:07.022: RESULT_STRING: Executing Product Check TLV.
*Oct 17 21:52:07.023: RESULT_STRING: Executing init script.
*Oct 17 21:52:07.131: RESULT_STRING: Executing backup script.
*Oct 17 21:53:29.209: RESULT_STRING: Writing new RTOS to flash disk.
*Oct 17 21:53:31.577: RESULT_STRING: Writing new Code to flash disk.
*Oct 17 21:53:56.451: RESULT_STRING: Writing new APIB to flash disk.
*Oct 17 21:55:05.911: RESULT_STRING: Executing install_apib script.
*Oct 17 21:56:52.738: RESULT_STRING: Executing fini script.
*Oct 17 21:56:53.037: RESULT_STRING: TFTP File transfer is successful.
Reboot the controller for update to complete.
 Optionally, pre-download the image to APs before rebooting to reduce network downtime.
*Oct 17 21:56:53.037: RESULT_CODE:11
*Oct 17 21:56:57.039: ummounting: <umount /mnt/download/>  cwd  = /mnt/application
*Oct 17 21:56:57.077: finished umounting
(Cisco_4402_WLC) >

WLC: TACACS+ Config Note!

  

Quick note about Cisco WLC and TACACS+. Got a call from a colleague who spent 2 hours on this issue. It is his first WLC install. 

When you configure Cisco TACACS+ on a Cisco WLC you need to add your TACACS+ server IP and secret information in 2 sections (authentication and authorization).  This is required for TACACS+ to work on a WLC.

 First you need to be authenticated and then authorized whereby you receive your (role). 

*The accounting section is not required for TACACS+ to work 

If you fail to enter only one section or not at all and run a debug “aaa tacacs enable” you will see: 

(WiSM-slot1-2) >debug aaa tacacs enable
(WiSM-slot1-2) >*Sep 06 15:02:25.495: tplusServerStateSet(), index=1 state=1
*Sep 06 15:17:13.343: Forwarding request to 10.10.10.100 port=49
*Sep 06 15:17:15.157: tplus response: seq_no=2 session_id=f058fe68 length=16 encrypted=0
*Sep 06 15:17:15.157: TPLUS_AUTHEN_STATUS_GETPASS
*Sep 06 15:17:15.157: auth_cont get_pass reply: pkt_length=25
*Sep 06 15:17:15.157: processTplusAuthResponse: Continue auth transaction
*Sep 06 15:17:15.171: tplus response: seq_no=4 session_id=f058fe68 length=6 encrypted=0
*Sep 06 15:17:15.172: tplus_make_author_request: athr server not found

Configure TACACS+ on WLC 

Use these commands to configure a TACACS+ authentication server:

•config tacacs auth add index server_ip_address port# {ascii | hex} shared_secret—Adds a TACACS+ authentication server.

•config tacacs auth delete index—Deletes a previously added TACACS+ authentication server.

•config tacacs auth (enable | disable} index—Enables or disables a TACACS+ authentication server.

•config tacacs auth server-timeout index timeout—Configures the retransmission timeout value for a TACACS+ authentication server.

Use these commands to configure a TACACS+ authorization server:

•config tacacs athr add index server_ip_address port# {ascii | hex} shared_secret—Adds a TACACS+ authorization server.

•config tacacs athr delete index—Deletes a previously added TACACS+ authorization server.

•config tacacs athr (enable | disable} index—Enables or disables a TACACS+ authorization server.

•config tacacs athr server-timeout index timeout—Configures the retransmission timeout value for a TACACS+ authorization server.

Use these commands to configure a TACACS+ accounting server:

•config tacacs acct add index server_ip_address port# {ascii | hex} shared_secret—Adds a TACACS+ accounting server.

•config tacacs acct delete index—Deletes a previously added TACACS+ accounting server.

•config tacacs acct (enable | disable} index—Enables or disables a TACACS+ accounting server.

•config tacacs acct server-timeout index timeout—Configures the retransmission timeout value for a TACACS+ accounting server. 

Use these commands to see TACACS+ statistics:

•show tacacs summary—Shows a summary of TACACS+ servers and statistics.

•show tacacs auth stats—Shows the TACACS+ authentication server statistics.

•show tacacs athr stats—Shows the TACACS+ authorization server statistics.

•show tacacs acct stats—Shows the TACACS+ accounting server statistics.

WLC: Carrier Busy Test

  

** UPDATE:  Carrier Busy is also enabled on a CAPWAP / LWAPP AP **

Back in the day when I couldn’t afford a spectrum or packet analyzer I would often use the next best free thing available. Its called the "carrier busy" test and it’s built into the Cisco Autonomous Access Point and can be used from a CAPWAP / LWAPP Access Point.

The carrier busy test will allow you to see what is going on in an environment from 50,000 feet, but that’s about where it ends. It doesn’t have details like a professional analyzer will provide. You could incorporate other commands like frame retries etc to help better interpret “carrier busy”.

Needless to say, it’s a fun command and if you don’t have the proper tools could help you in a pinch. If you do outdoor bridges, you may already use this command to assist on channel assignment.

What is "Carrier Busy"

On a Cisco autonomous access point you can run a command called 'carrier busy'. The AP will shutdown the respected radio interface and will scan all respected channels and report back with a percentage of channel activity. The channel activity collected includes activity from both 802.11 traffic and interference also sometimes called RFI (Radio Frequency Interference).

What this means, if there is 802.11 traffic and suppose there is interference it will compute a  (percentage) to this value. Things to note when you run the carrier busy test the radio will do a shut and all associated clients will lose connectivity between 5 - 8 seconds during the test. After the test the radio will no shut itself and return to production allowing clients to associate again.

I have not found any detailed documentation stating exactly how the access point computes these values. If you have any info please do share!

Autonomous Command for "Carrier Busy"

If your access point has both 802.11g <dot11Radio 0> and 802.11a <dot11Radio 1> radios you can run busy test on either the 2.4 GHz or the 5 GHz spectrums.

ap#dot11 <Radio Interface> carrier busy

ap#show dot11 carrier busy

802.11g = dot11Radio 0
802.11a = dot11Radio 1

ap#dot11 dot11Radio 0 carrier busy

WLC: CAPWAP / LWAPP Command for "Carrier Busy"

wlc-ap#debug dot11 <Radio Interface> carrier busy

802.11g = dot11Radio 0
802.11a = dot11Radio 1

wlc-ap#debug dot11 dot11Radio 0 carrier busy

Example # 1 - Carrier Busy (Normal)

This example is a neighboring access point on channel 11 only sending management frames

ap#dot11 dot11Radio 0 carrier busy

*Mar  2 09:07:33.173: %LINK-5-CHANGED: Interface Dot11Radio0, changed state to reset
*Mar  2 09:07:34.173: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to down

Frequency  Carrier Busy %
---------  --------------
2412          0
2417          3
2422          0
2427          0
2432          0
2437          0
2442          0
2447          4
2452          5
2457          2
2462          5

*Mar  2 09:07:38.695: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to up
*Mar  2 09:07:39.695: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to up

Example # 2 - Carrier Busy (Microwave)

 I introduced a microwave oven into the mix. You can see there is a significant increase in channel activity from 2447 - 2462. 

ap#dot11 dot11Radio 0 carrier busy

*Mar  2 09:05:52.664: %LINK-5-CHANGED: Interface Dot11Radio0, changed state to reset
*Mar  2 09:05:53.664: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to down

Frequency  Carrier Busy %
---------  --------------
2412          1
2417          7
2422          5
2427          1
2432          11
2437          13
2442          10
2447          31
2452          36
2457          42
2462          45

*Mar  2 09:05:58.186: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to up
*Mar  2 09:05:59.186: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to up

ap#

Example # 3 - Carrier Busy (ISO Download)

In this example I introduced 2 laptops and conducted an ISO download for the purpose of creating 802.11 traffic.

ap#dot11 dot11Radio 0 carrier busy

*Mar  2 09:07:33.173: %LINK-5-CHANGED: Interface Dot11Radio0, changed state to reset
*Mar  2 09:07:34.173: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to down

Frequency  Carrier Busy %
---------  --------------
2412          0
2417          3
2422          0
2427          0
2432          0
2437          0
2442          3
2447          9
2452          19
2457          21
2462          23

*Mar  2 09:07:38.695: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to up
*Mar  2 09:07:39.695: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to up

Conclusion

If you don’t have tools and you are in a pinch the carrier busy test may be a tool you might find helpful. Keep in mind, you will need to incorporate other commands to interpret the carrier busy results.

WLC: Configuring Fast SSID Changing

 

So when you jump between different SSIDs on your WLC are you noticing a delay connecting right away to the new SSID? If you answered, YES.... Do you have fast ssid enabled?

When fast SSID changing is enabled, the controller allows clients to move between SSIDs quicker. 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.

Keep in mind this is a global setting.

CLI COMMAND:

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

GUI COMMAND:

Step 1 Choose Controller to open the General page.

Step 2 From the Fast SSID Change drop-down box, choose Enabled to enable this feature or Disabled to disable it. The default value is disabled.

Step 3 Click Apply to commit your changes.

Step 4 Click Save Configuration to save your changes.

Cisco Output Interpreter - New this month Wireless LAN Controller - show & debug commands

 

I wanted to share this in case you may have a use for it. I've used it in the past, its a little hit or miss on what is supported and how the code is sometimes read. It was recently updated to support the Cisco WLCs show & debug commands

Output Interpreter is a troubleshooting tool that reports potential problems by analyzing supported "show" command output. Output Interpreter supports various "show" command output from your router, switch, PIX/ASA firewall, IOS® wireless access point, or Meeting Place Platform.

The Output Interpreter continues to support new features to better serve you. This month's list of new features includes support for GOLD diagnostics and other outputs, including:

• Cisco 12000 IOS XR Firmware, Hardware and Software Readiness Assessment (Up to version 3.8)
• Wireless LAN Controller - show & debug commands
• GOLD diagnostics - show diagnostic result
• ASA Commands - show tech-support, show running-config

https://www.cisco.com/cgi-bin/Support/OutputInterpreter/home.pl 

WLC: Show run-config [no-ap]

 

If you ever did a show run-config on a WLC with a 100 access points then you know where I am going! 

A show run config [no-ap] will omit the access point information. Why is this important? Well suppose you have a WiSM with a 150 access points joined to a controller do you want to see 400 pages of configs of APs when you only want to see the run-config ? BINGO!

(Cisco_2006_WLC) >show run-config ?

[no-ap]        Display running configuration of controller without AP configuration

WLC - Cisco LWAPP/CAPWAP QoS Tagging Slide

 

In coming weeks I will share with you a number of QoS labs with LWAPP/CAPWAP and autonomous access points and controllers. In advance to that, I wanted to share this LWAPP/CAPWAP QoS Tagging slide. 

This slide comes from the config guide.