Upgrading Cisco 4400 Wireless Controllers

Leave a reply

Make sure you absolutely check the release notes for the software as changes to the behaviour of the wlans and settings can occur between releases.

I found it is better to ssh into the controller and upgrade it from the CLI. This gives you a running output of what is going on at each stage.

debug transfer trace enable
transfer download datatype code
transfer download mode tftp
transfer download serverip 10.1.1.10
transfer download path /
transfer download filename AIR-WLC4400-K9-6-0-196-0.aes 
transfer download start

After a successful download of the new image you should see something like:

TFTP File transfer is successful.
                                   Reboot the switch for update to complete.

Sat Jun 19 15:47:00 2010: Still waiting!  Status = 2 Sat Jun 19 15:47:03 2010: Still waiting!  
Sat Jun 19 15:47:04 2010: finished umounting

(Cisco Controller) >

Issue a ‘reset system’ and say yes to saving the config before rebooting. Remember to repeat for the bootloader file should the release notes say to do so. It takes about 2 mins for the WLC to reboot. If there are access points registered to the WLC before rebooting, they will migrate to another controller.

Check release notes of the main image re bootloader. Similar procedure, however the version on the cisco web site has a ‘BOOT’ after the name. The example below was for version 5.2.

debug transfer trace enable
transfer download datatype code
transfer download mode tftp
transfer download serverip 10.1.1.10
transfer download path /
transfer download filename AIR-WLC4400-K9-5-2-157-0-ER.aes 
transfer download start

The following output (show sysinfo) after reboot verifies the versions:

Manufacturer's Name.............................. Cisco Systems Inc.
Product Name..................................... Cisco Controller
Product Version.................................. 6.0.196.0
RTOS Version..................................... 6.0.196.0
Bootloader Version............................... 4.1.171.0
Emergency Image Version.......................... 5.2.157.0
Build Type....................................... DATA + WPS

VLAN groups for fwsm and ace on 6513

Leave a reply

With the data centre move, I took the opportunity to clean up some of the 6513 config which had got out of control.

The original groupings looked all over the place:

svclc vlan-group 1 27,28,40,76
svclc vlan-group 2 44,45,48
svclc vlan-group 42 42
svclc vlan-group 43 43
svclc vlan-group 400 402
svclc vlan-group 427 427,428
svclc vlan-group 500 527,528,544,545,548
svclc vlan-group 600 612,614,618,620,621,622,623,624,625,626,628,632,636,699
svclc vlan-group 602 602
svclc vlan-group 700 720,721,724,725,732
svclc vlan-group 990 996,997
svclc vlan-group 999 9,999
svclc module 2 vlan-group 2,43,400,427,500,600,602,700,999,
firewall module 1 vlan-group 1,42,427,428,600,990,999,

….YUK. However I decided to break the FWSM and ACE’s visible vlans into groups with more meaning; specifically:

Group 1 = specific to FWSM
Group 2 = common to both
Group 3 = specific to ACE

In the end the config gets cleaned up and looks like:

svclc vlan-group 1 27,28,40,42,76,612,614,618,622,623,626,628,636,699,996,997
svclc vlan-group 2 9,427,428,620,621,624,625,632,999
svclc vlan-group 3 43,44,45,48,402,527,528,544,545,548,602,720,721,724,725,732

firewall module 1 vlan-group 1,2
svclc module 2 vlan-group 2,3

…much better ! A few of the other commands that got me out of a few dramas:

firewall autostate
firewall multiple-vlan-interfaces
svclc autostate
svclc multiple-vlan-interfaces

(The autostate command helps the devices track the loss of an access link).

Moved Data Centre

Leave a reply

The Data Centre move happened last weekend – all went well and we did it (a team of 11) in 24 hours. I had to look after the firewalls, ACEs, proxy, WAAS as a priority and chipped in whereever else when required. For a business that does several hundred million dollars of business through its web site (as one example) – It was a great effort to have the business back online 2 days prior to expectation. Some of the guys I work with really showed their expertise and planning skills.

One thing I learned was that if unsure, always bring up the standby FWSM or ACE when :

A. The primary unit is online and functional and is active.

B. The underlying network (vlans, switch configs etc) are up and stable.

I had a few dramas where the failover states of the FWSM or ACE seemed ok, but because a few things were changed during the move things started to go awry. In some cases both FWSMs or ACEs were up, but because of some underlying changes to the network they would both think they are active and the network can get turned into a banana. (eg. failover vlan removed!)

In hindsight, I should have left the secondary modules out until all other network work was completed. Just because you think the modules are working at one point in time doesn’t mean they will be behaving as expected at a later point if there are changes being made to the network.