15 January 2013
Cisco 5700 Series Wireless LAN Controller
A new Wireless LAN Controller by Cisco called the 5760 ? While browsing around the product support page looking for a document, I stumble upon the page as shown below:
Not much details on it yet apart from the download software link. The software available to download is ct5760-ipservicesk9.SPA.03.02.00.SE.150-1.EX.bin Version 3.2? and IPServices? Is this a whole new product range or are they changing the way WLC works?
It resembles the 5508 WLC with some interfaces changes. With 6 ports for SFPs, it could probably be 10 gigabit links?
Time will tell..
Labels: 5700 series, 5760, Cisco WLC
29 December 2012
Wired Guest on WLC, Ingress/Egress?
Was going through my studies for the CCIE Wireless, in particular Wired Guest on the WLC. I have heard of this feature, read about it a lot of times but never had to configure this feature before. I thought I lab it out so I can get my head around it. I followed the Cisco configuration guide from http://www.cisco.com/en/US/docs/wireless/controller/7.0/configuration/guide/c70users.html#wp1066125
Most of it was straightforward but the one thing I find very confusing is the Ingress and Egress interface.
The figure below shows the Ingress and Egress configuration.
So what is the difference? What is required to be configured? Well it depends if you are configured the guest wired on a single WLC or you are configuring it on two WLC with foreign and anchor WLCs.
Single WLC
Ingress Interface: The L2 VLAN that the wired guest user computer is connected to. This VLAN is configured on the Ingress Interface and the switch port.
Egress Interface: The L3 Dynamic Interface VLAN where the guest user gets put into after L3 authentication (usually web auth). The guest user will be in this subnet and get a DHCP address from.
Two WLC
Foreign WLC
Ingress Interface: Similar to Single WLC Ingress Interface above. This is where the guest user starts and comes in.
Egress Interface: Technically, this does not need to be configured. As the foreign WLC will create an EOIP tunnel to the anchor WLC, this interface should never be used. To test it out, I configured it on the management interface, it works. I then try configuring this to an interface that goes no where, wired guest still works.
Anchor WLC
Ingress Interface: This is not required and cannot be configured. On the Anchor WLC, you do not need to create the Guest LAN interface, so nothing should appear hear and should default to none. This is because the Anchor receives the guest VLAN from the Foreign WLC through the EOIP tunnel.
Egress Interface: Similar to Single WLC Egress Interface. This is where the guest user ends up after successful L3 authentication.
The following are some screenshots of configuration with two WLC.
Creating the Guest LAN interface on the foreign WLC.
Configuring the wired guest "WLAN" on the foreign WLC. Ingress interface to "99", the interface create above and Egress interface to management which doesn't really matter what is configured as EOIP will be used.
The figure below shows the wired guest client on the anchor WLC. Notice the mobility role of "Export Anchor".
Most of it was straightforward but the one thing I find very confusing is the Ingress and Egress interface.
The figure below shows the Ingress and Egress configuration.
So what is the difference? What is required to be configured? Well it depends if you are configured the guest wired on a single WLC or you are configuring it on two WLC with foreign and anchor WLCs.
Single WLC
Ingress Interface: The L2 VLAN that the wired guest user computer is connected to. This VLAN is configured on the Ingress Interface and the switch port.
Egress Interface: The L3 Dynamic Interface VLAN where the guest user gets put into after L3 authentication (usually web auth). The guest user will be in this subnet and get a DHCP address from.
Two WLC
Foreign WLC
Ingress Interface: Similar to Single WLC Ingress Interface above. This is where the guest user starts and comes in.
Egress Interface: Technically, this does not need to be configured. As the foreign WLC will create an EOIP tunnel to the anchor WLC, this interface should never be used. To test it out, I configured it on the management interface, it works. I then try configuring this to an interface that goes no where, wired guest still works.
Anchor WLC
Ingress Interface: This is not required and cannot be configured. On the Anchor WLC, you do not need to create the Guest LAN interface, so nothing should appear hear and should default to none. This is because the Anchor receives the guest VLAN from the Foreign WLC through the EOIP tunnel.
Egress Interface: Similar to Single WLC Egress Interface. This is where the guest user ends up after successful L3 authentication.
The following are some screenshots of configuration with two WLC.
Creating the Guest LAN interface on the foreign WLC.
Configuring the wired guest "WLAN" on the foreign WLC. Ingress interface to "99", the interface create above and Egress interface to management which doesn't really matter what is configured as EOIP will be used.
Configuring the wired guest "WLAN" on the anchor WLC. Ingress interface as mentioned above can't be configured and left to none as EOIP will be used. Egress interface configured to VLAN where guest user will be placed after successful L3 authentication.
The figure below shows the wired guest client on the foreign WLC. Notice the mobility role of "Export Foreign".
Labels: Anchor WLC, Egress Interface, Foreign WLC, Guest, Ingress Interface, Wired Guest, WLC
05 September 2012
Cisco Virtual Wireless LAN Controller (vWLC) - Installing and Troubleshooting
On the 30th of August 2012, Cisco released the Wireless LAN Controller release 7.3.101. which also includes support of the Virtual Wireless LAN Controller (vWLC). The release notes can be found from Cisco at http://www.cisco.com/en/US/partner/docs/wireless/controller/release/notes/crn73.html
The following post is the experienced I had installing and troubleshooting the vWLC. I followed this guide by Cisco http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080bd2d04.shtml#NetPro but ran into a few issues.
Points To Keep In Mind on the vWLC:
Open the vSphere client. I currently use ESXi 4.1.
Select the .ova file.
As you can see here the vWLC only requires 8GB of HDD space.
Give this VM a name or leave it at the default.
Select a datastore to installe the vWLC.
Select thick provision format.
Review and click finish.
It only takes about a minute or two to deploy.
Power On vWLC Host For The First Time
Power on the vWLC host.
Basic Configuration (configure the time correctly or the certificates will be invalid)
It takes roughly about four minutes to get to the Configuration Wizard Tool form power on. Go through the wizard like any other WLC. When asked to configure NTP, make sure that your NTP is working correctly. If it is not or you are unsure, manually configure the time instead of using NTP. This is important as it will affect the generation of the self-signed certificate. (Also check the time on the ESX server is right)
Logging On To vWLC and Activating Evaluation License
Log on to the vWLC with the credentials configured before.
As you can see the main page states 0 Access Points supported.
Got to Management then Software Activation then Licenses.
I am not sure why the only way to get the EULA to come up, is to change the priority and click 'Set Priority'.
Reboot the vWLC.
Configure DHCP Option 43 For WLC Discovery
I have configured a DHCP pool/server on the switch. I then add Option 43 which contains the vWLC IP address in hex format for the access point to find the vWLC.
Access Point Must be 7.3 Or Above To Join vWLC
The statement above is stated in the deployment guide by Cisco. This is interesting as if you don't have an existing WLC that is on release 7.3 or above, the access point will not join the vWLC. This has to do with the vWLC using a self-signed certificate and the access point not being able to verify the certificate.
I then started looking at Cisco's website to see if there is a way around it but couldn't find anything. I realised that there is a new lightweight image for the Cisco 3500 access point I used that was released on the same date as the vWLC. I gave that a go to see if the access point would join the vWLC.
It actually works and the vWLC shows that the access point joined and started downloading the full image.
Invalid Certificate Caused By Incorrect Time
After downloading the joining the vWLC and downloading the image, I thought the access point would join the vWLC without a problem. Instead I got the error message below.
I checked the self-signed certificate and realised that the certificate was invalid due to the clock. I updated the time but couldn't find a way to re-generate the self-signed certificates used to authenticate the access points (you can re-generate the SSL self-signed certificates). I had no choice but to rebuild the vWLC and making sure I have the time right. It turned out that the vWLC could not contact my NTP server. I ended up manually configuring the time during the wizard at the start.
After rebuilding and re-configuring the vWLC, I checked that the self-signed certificates is valid and that the access point could join the vWLC.
Access Point Must Be In FlexConnect Mode
When the access point showed up on the vWLC, for some reason it is in FlexConnect mode. I changed it to local mode. I created a test SSID to see if the clients cant connect to the access point controlled by the vWLC. The SSID does not broadcast at all. The error message I am getting is from the access point stating '*Sep 5 13:56:19.186: %LWAPP-3-CLIENTERRORLOG: Delete VAP: received a delete request for an invalid WLAN ID 1' I have tried to remove the SSID (WLAN ID1), rebooting both the vWLC and access point without any luck.
The next day I read up the guide and release notes again and found this 'APs will be operating in FlexConnect mode only.' That was the problem, vWLC will only work with access points in FlexConnect mode.
Testing Wireless Connection
I went back to the vWLC change the access point back to FlexConnect mode.
After the access point rebooted in FlexConnect mode, the test SSID started broadcasting and I could connect to it.
Wireless client connected to vWLC on Android device.
Wireless client connected shown in the vWLC.
The following post is the experienced I had installing and troubleshooting the vWLC. I followed this guide by Cisco http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080bd2d04.shtml#NetPro but ran into a few issues.
Points To Keep In Mind on the vWLC:
- Could not configure Telnet session to vWLC ESX host on ESXi 4.1
- Cisco Access Point not on code 7.3 and above would not join vWLC
- Incorrect time configure initially caused the self-signed certificate (SSC) on the vWLC to be invalid
- Access points only work in FlexConnect mode
vWLC Requirements
The following are the vWLC requirements extracted from the .ova template:
Downloading The vWLC
The following are the vWLC requirements extracted from the .ova template:
- 1 CPU
- 2GB RAM
- 8GB HDD
- 2 NICs (probably can get away with one and not using the service port)
Downloading The vWLC
The vWLC software (AIR-CTVM-7-3-101-0.ova) from Cisco is a .ova file. This is a package that will unpack and create the virtual machine.
Deploy OVA Template
Open the vSphere client. I currently use ESXi 4.1.
Select the .ova file.
As you can see here the vWLC only requires 8GB of HDD space.
Give this VM a name or leave it at the default.
Select a datastore to installe the vWLC.
Select thick provision format.
Review and click finish.
It only takes about a minute or two to deploy.
Power on the vWLC host.
Basic Configuration (configure the time correctly or the certificates will be invalid)
It takes roughly about four minutes to get to the Configuration Wizard Tool form power on. Go through the wizard like any other WLC. When asked to configure NTP, make sure that your NTP is working correctly. If it is not or you are unsure, manually configure the time instead of using NTP. This is important as it will affect the generation of the self-signed certificate. (Also check the time on the ESX server is right)
Logging On To vWLC and Activating Evaluation License
Log on to the vWLC with the credentials configured before.
As you can see the main page states 0 Access Points supported.
Got to Management then Software Activation then Licenses.
I am not sure why the only way to get the EULA to come up, is to change the priority and click 'Set Priority'.
Reboot the vWLC.
Configure DHCP Option 43 For WLC Discovery
I have configured a DHCP pool/server on the switch. I then add Option 43 which contains the vWLC IP address in hex format for the access point to find the vWLC.
Access Point Must be 7.3 Or Above To Join vWLC
The statement above is stated in the deployment guide by Cisco. This is interesting as if you don't have an existing WLC that is on release 7.3 or above, the access point will not join the vWLC. This has to do with the vWLC using a self-signed certificate and the access point not being able to verify the certificate.
I had to use the recovery method to get the new lightweight image on.
It actually works and the vWLC shows that the access point joined and started downloading the full image.
After downloading the joining the vWLC and downloading the image, I thought the access point would join the vWLC without a problem. Instead I got the error message below.
I checked the self-signed certificate and realised that the certificate was invalid due to the clock. I updated the time but couldn't find a way to re-generate the self-signed certificates used to authenticate the access points (you can re-generate the SSL self-signed certificates). I had no choice but to rebuild the vWLC and making sure I have the time right. It turned out that the vWLC could not contact my NTP server. I ended up manually configuring the time during the wizard at the start.
After rebuilding and re-configuring the vWLC, I checked that the self-signed certificates is valid and that the access point could join the vWLC.
Access Point Must Be In FlexConnect Mode
When the access point showed up on the vWLC, for some reason it is in FlexConnect mode. I changed it to local mode. I created a test SSID to see if the clients cant connect to the access point controlled by the vWLC. The SSID does not broadcast at all. The error message I am getting is from the access point stating '*Sep 5 13:56:19.186: %LWAPP-3-CLIENTERRORLOG: Delete VAP: received a delete request for an invalid WLAN ID 1' I have tried to remove the SSID (WLAN ID1), rebooting both the vWLC and access point without any luck.
The next day I read up the guide and release notes again and found this 'APs will be operating in FlexConnect mode only.' That was the problem, vWLC will only work with access points in FlexConnect mode.
Testing Wireless Connection
I went back to the vWLC change the access point back to FlexConnect mode.
After the access point rebooted in FlexConnect mode, the test SSID started broadcasting and I could connect to it.
Wireless client connected to vWLC on Android device.
Wireless client connected shown in the vWLC.
Labels: AP can't join vWLC, Cisco Virtual Wireless LAN Controller, vWLC, vWLC requirements, vWLC self signed certificate, vWLC time, WLC 7.3
29 November 2011
Upgrading Cisco Wireless Control System from Version 4 to 7
Background:
The current Cisco Wireless Control System (WCS) is running version 4.2.128.0 and the plan is to upgrade it to the latest 7.0.220.0. This WCS is also running on a Cisco WLSE, which means the WCS is running on Linux. After going through the different versions of release notes, I have decided to chose the path of version 4.2.128.0 to 6.0.132.0 then to 7.0.220.0.
Pre-upgrade:
Started by downloading the two versions of WCS, WCS-STANDARD-K9-6.0.132.0.bin and WCS-STANDARD-K9-7.0.220.0.bin. The extension of .exe is for Windows while .bin is for Linux. Prepared a FTP server that is reachable by the WCS with the above WCS .bin files. Backup WCS preferable to an external server.
Upgrade 1:
SSH into the WCS and used FTP to get the .bin files using the following commands:
ftp 10.10.100.100
binary
hash
get WCS-STANDARD-K9-6.0.132.0.bin
Ctrl + Z (to get out of FTP when transfer is done)
Changed the privllages of the transferred file with the following command:
chmod 755 WCS-STANDARD-K9-6.0.132.0.bin
Started the install script with the following command:
./WCS-STANDARD-K9-6.0.132.0.bin
Followed the prompts and the script backed up existing WCS and installed the new version of WCS. The installation completed and the WCS service started and I could access it through the web management page. All the data, maps and configuration were there as before.
Upgrade 2:
Now it is time to repeat the steps above for version 7.0.220.0. Everything was pretty much the same except towards the end. The WCS service couldn't be started. Tried uninstalling version 7.0.220.0, restarting the appliance and installing WCS again, twice but still same the problem. I was thinking it could be something wrong with the database. Tried the "reinitdb" script to reinitialise the database and that didn't work too.
Didn't really have much time to troubleshoot this so I decided to download and try version 7.0.164.3. Uninstalled version 7.0.220.0 and installed version 7.0.164.3. It works! without any of the problem earlier. Not too sure why.. Went to the web management page and all the data, maps and configuration were there.
Decided to restart the appliance (being paranoid and just want to check stability) and I couldn't believe it! A brand new, blank WCS without any configuration. SSH into the WCS and found out that everything has been deleted. Again, no idea why it did that.
Good thing there were two backups made and I could restore the configuration. SSH into the WCS and went to the directory /opt/WCS7.0.164.3 . Ran the ./Restore script, followed the prompts and the script restore the configuration successfully! Rebooted the WCS again and it is now working with version 7.0.164.3.
Version 7.0.164.3 is good enough for me because it is the minimum requirements needed to migrate WCS to NCS.
The current Cisco Wireless Control System (WCS) is running version 4.2.128.0 and the plan is to upgrade it to the latest 7.0.220.0. This WCS is also running on a Cisco WLSE, which means the WCS is running on Linux. After going through the different versions of release notes, I have decided to chose the path of version 4.2.128.0 to 6.0.132.0 then to 7.0.220.0.
Pre-upgrade:
Started by downloading the two versions of WCS, WCS-STANDARD-K9-6.0.132.0.bin and WCS-STANDARD-K9-7.0.220.0.bin. The extension of .exe is for Windows while .bin is for Linux. Prepared a FTP server that is reachable by the WCS with the above WCS .bin files. Backup WCS preferable to an external server.
Upgrade 1:
SSH into the WCS and used FTP to get the .bin files using the following commands:
ftp 10.10.100.100
binary
hash
get WCS-STANDARD-K9-6.0.132.0.bin
Ctrl + Z (to get out of FTP when transfer is done)
Changed the privllages of the transferred file with the following command:
chmod 755 WCS-STANDARD-K9-6.0.132.0.bin
Started the install script with the following command:
./WCS-STANDARD-K9-6.0.132.0.bin
Followed the prompts and the script backed up existing WCS and installed the new version of WCS. The installation completed and the WCS service started and I could access it through the web management page. All the data, maps and configuration were there as before.
Upgrade 2:
Now it is time to repeat the steps above for version 7.0.220.0. Everything was pretty much the same except towards the end. The WCS service couldn't be started. Tried uninstalling version 7.0.220.0, restarting the appliance and installing WCS again, twice but still same the problem. I was thinking it could be something wrong with the database. Tried the "reinitdb" script to reinitialise the database and that didn't work too.
Didn't really have much time to troubleshoot this so I decided to download and try version 7.0.164.3. Uninstalled version 7.0.220.0 and installed version 7.0.164.3. It works! without any of the problem earlier. Not too sure why.. Went to the web management page and all the data, maps and configuration were there.
Decided to restart the appliance (being paranoid and just want to check stability) and I couldn't believe it! A brand new, blank WCS without any configuration. SSH into the WCS and found out that everything has been deleted. Again, no idea why it did that.
Good thing there were two backups made and I could restore the configuration. SSH into the WCS and went to the directory /opt/WCS7.0.164.3 . Ran the ./Restore script, followed the prompts and the script restore the configuration successfully! Rebooted the WCS again and it is now working with version 7.0.164.3.
Version 7.0.164.3 is good enough for me because it is the minimum requirements needed to migrate WCS to NCS.
Labels: Upgrade WCS, WCS 7.0.220.0
