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

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 

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

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!

 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





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)

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 !

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.

(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.

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) >