Saturday, November 30, 2013

Outdoor WLAN site survey


Last year I wrote a blog post because I thought I was going to be doing a lot of outdoor WLAN site surveying.  That post went through all the details of how to set your PC up, step by step, to get you up and running with outdoor surveying.  Fast forward to this month, when we were tasked with designing and installing some outdoor WLAN coverage for a manufacturing plant.


Since the area was not too large, I decided to survey it twice.  The first survey was the regular walkabout – the way you would site survey an indoor area.  As you can see, I went with the default settings for signal propagation on the walkabut – and if I were to do it all over again, I would set it at fifty feet or so.


There are four Cisco 1552 series mesh access points in this design, and they’re not meshed together.  They are all in local mode, which means they are not using backhaul radios – both radios are for client access.  One thing I want to point out is that one is pole mounted, one is mounted to building with wood siding, and the other two mounted to metal skinned buildings.  All four access points have the dynamite stick antennas, too.  Can you tell which ones are which?



I really should have changed the survey propagation when I did this walkabout(above), since it makes it look like we provided coverage inside those buildings.  By the way, those buildings are in the 200,000 – 400,000 square foot range.


By looking at the same survey (below) at -50dBm, you can see where the access points are.  My guess is that you can also make a better guess as to which ones are mounted to metal buildings and which ones are not.





Here’s the same area(below) – the only changes are that I am doing a GPS survey this time, and a few days later.  I’m letting RRM control the power, just like the walkabout survey above.  The power on three of the APs was set at three, and one of them was set to full power – which is where the controller thought they needed to be.  The original site survey was done at power level three for -75dBm 2.4 GHz coverage.  I surveyed it that way because I wanted to see the coverage area that the controller thought I needed.  All of the buildings in this coverage area have Wi-Fi inside them – however the metal skinned buildings tend to block most of the signals from escaping.   I recently did a WLAN survey in a Quonset building (corrugated metal building in the shape of a 55 gallon drum cut in half length-wise) and when we walked out of that building, all signals were blocked entirely.  If I ever need a Faraday cage, I will remember to ask them if I can borrow their building.


Here’s -75dBm 2.4 GHz coverage.  Three APs power level three, one AP power level of one:




After changing the power to level three on the access point that was set to level one (and statically setting the other three so they would not change) I surveyed again.  It’s amazing how your feet don’t get tired when you drive around with a laptop on your dashboard and a GPS receiver taped to the roof of your car.


You might think that dropping the power level on the AP set to power level one would make a big difference in the -75dBm coverage.  Each power level is a 3dB change in the WLAN controller.  Dropping the power level two notches effectively cuts the power in half, and then cuts that power in half again.  The AP that was on full power was the AP closest to the bottom of the screenshot.  I expected something a little more dramatic, actually.  We were aiming to cover that parking lot directly below the access point.  The controller must have thought we wanted to cover both parking lots.  You can see the coverage area decrease slightly in the survey below.


Here’s -75dBm 2.4 GHz coverage.  All APs set to power level one:



All in all, we covered the two parking lots we were aiming to cover, along with the area between the buildings so that WLAN client devices could roam from one building to another when the human did.  One thing to note – see that “main drag” where I drove from the top of the map to the bottom -  the signal seems to drop off immediately for some reason?  That street is lined with very large trees that stay green all year long.  I  could cover it with Wi-Fi, but what’s the point?  You should be looking at those gorgeous trees!










Thursday, November 21, 2013

Upgrading Cisco Prime 1.2 to 3.0

I am writing this for myself and anyone else that might be upgrading your Cisco Prime Infrastructure (PI) in the future.  After doing all the research, I discovered I needed to first patch our PI and make backups.


Not knowing which day I was going to do the upgrade, I decided to configure PI to back itself up daily so I would always have a fresh backup and not have to wait to create one if I decided to the upgrade that day.


I browsed here:  Administration  >  Background Tasks >  Other Background Tasks  >  Prime Infrastructure Server Backup


I created a backup repository and configured it to do daily backups at 03:30 in the morning.



Next step was to copy the patches to PI.  I downloaded these two files from CCO:  pi_1.2.1.12_update.tar.gz  and  PI_1_2_1_12u-Update.1.tar.gz


I figured I would use WinSCP, so I tried to login with the file protocol = SCP and my root credentials and was denied.  Bummer.  Something about an incompatible version.  Next I tried FTP, but now my credentials were not working.  Research showed that I needed to create an FTP account on PI.


I logged in via SSH and created an FTP account.  Here’s how: (FTP Username – “ftpaccount”, password = My8l0gpw0rD


CiscoPI/admin# ncs password ftpuser ftpaccount password My8l0gpw0rD



Updating FTP password.

This may take a few minutes...

Successfully updated location ftp user



That was all it took to create the FTP account.  Now I used WinSCP to copy the two patch files to PI from my workstation.




Now that the patches are in PI, verify they are there and then run them.


CiscoPI/admin# show repository localftp






CiscoPI/admin# patch install PI_1.2.1.12u_update.tar.gz localftp

Save the current ADE-OS running configuration? (yes/no) [yes] ? yes

Generating configuration...

Saved the ADE-OS running configuration to startup successfully

Initiating Application Patch installation...


Patch successfully installed


CiscoPI/admin# patch install pi_1.2.1.12_update.tar.gz localftp

Save the current ADE-OS running configuration? (yes/no) [yes] ? yes

Generating configuration...

Saved the ADE-OS running configuration to startup successfully

Initiating Application Patch installation...


Patch successfully installed

CiscoPI/admin# sh version


Cisco Application Deployment Engine OS Release: 2.0

ADE-OS Build Version:

ADE-OS System Architecture: x86_64


Copyright (c) 2005-2010 by Cisco Systems, Inc.

All rights reserved.

Hostname: CiscoPI


Version information of installed applications


Cisco Prime Network Control System


Version :

Patch: Update for Prime Infrastructure 1.2.0 - backup,restore,upgrade improvements Version:

Patch: PI Patch - includes backup, restore and upgrade related updates Version:



A month passed and the decision was made to try an “inline upgrade” – which is basically copying the PI 2.0 software to the virtual machine and executing an upgrade.  We went with this way for a variety of reasons.  I had read that the best was to backup your existing PI, create a new VM with the PI 2.0 OVA and restore your backup into that VM.  I had also read about some inline upgrades that were having disk space issues, but decided to try it anyway.


This time I used the 3CDaemon TFTP/FTP application to FTP the upgrade file to PI.  The application is free, and I have had a much luck with it over the years.   If you haven’t used it, you’ll need to download and install it, and then run the application.  Click on FTP Server and create a username and password – you will need this for PI to login to your FTP server app.



Now log back into your PI via SSH and copy the upgrade file from your FTP application.  Here is a line by line step, with output, comments and commands in red:


copy disk:/defaultRepo

Username: <from FTP app>

Password:  <from FTP app>

<the FTP server is now transferring the upgrade file.  Be patient>



<Verify file is where you told it to go>


CiscoPI/admin# dir disk:/defaultRepot


Directory of disk:/defaultRepo

1700049411 Nov 12 2013 18:01:45  PI-Upgrade-  <Here’s the file you just transferred.  Looks right>


           Usage for disk: filesystem

                74685308928 bytes total used

                42612486144 bytes free

                123677184000 bytes available


<Now shutdown NCS and run the upgrade>


CiscoPI/admin# ncs stop

Stopping Network Control System...

This may take a few minutes...

Network Control System successfully shutdown.

SAM daemon process id does not exist

DA daemon process id does not exist

DA syslog daemon process id does not exist


<now run the upgrade>

CiscoPI/admin# application upgrade PI-Upgrade- defaultRepo

Save the current ADE-OS running configuration? (yes/no) [yes] ? yes

Generating configuration...

Saved the ADE-OS running configuration to startup successfully

Initiating Application Upgrade...

  Stage 1 of 7: Transferring file ...

  -- complete.

  Stage 2 of 7: Unpacking file ...

  -- complete.

  Stage 3 of 7: Executing pre-install ...


[WARNING] System will reboot after a successful installation of this package (after Stage 7).

After reboot, please login again into the server to check status.

No action required at this time. Continuing with Stage 3.


<These steps took over 12 hours.  Be patient.  I thought it was stuck, so I went home and let it run all night and was pleasantly surprised the next morning>


  -- complete.

  Stage 4 of 7: Upgrading binaries ...

  -- complete.

  Prime Infrastructure Application installation completed


  Stage 5 of 7: Retrieving system version ...

  -- complete.

  Stage 6 of 7: Updating Database Schema ...

              : This could take long time based on the existing data size.

                  Stage 1 of 5: Pre Migration Schema Upgrade ...

                                        -- completed at: 2013-11-12 19:20:50.923

, Time Taken : 0 hr, 5 min, 31 sec

                  Stage 2 of 5: Schema Upgrade ...

                                : This could take long time based on the existing data size.

                                        -- completed at: 2013-11-12 19:43:22.763

, Time Taken : 0 hr, 22 min, 31 sec

                  Stage 3 of 5: Post Migration Schema Upgrade ...

                                        -- completed at: 2013-11-13 01:14:27.926

, Time Taken : 5 hr, 31 min, 5 sec

                  Stage 4 of 5: Enabling DB Constraints ...

                                        -- completed at: 2013-11-13 04:16:54.362

, Time Taken : 3 hr, 2 min, 21 sec

                  Stage 5 of 5: Finishing Up ...

                                        -- completed at: 2013-11-13 04:17:22.815

, Time Taken : 0 hr, 0 min, 28 sec

  -- complete.

  Stage 7 of 7: Re-enabling Database Settings ...

  -- complete.

Upgrade Finished. Server is  restarting . Please wait ..


% This application Install or Upgrade requires reboot, rebooting now...


Broadcast message from root (pts/0) (Wed Nov 13 04:24:36 2013):


The system is going down for reboot NOW!


Application upgrade successful



<Now you are finished.  Don’t forget to upgrade your MSE if you have one>




























































Wednesday, November 20, 2013

Upgrading your MSE (Licenses change)

I am writing this for myself and anyone else that might be upgrading your MSE 3355 in the future.  I found the two documents (links will need CCO account) below, but my varied a little – so here goes.  I went with the first option, since I didn’t require data migration.


Step one was to “back up the existing database using the Prime Infrastructure.”  There was no link or other direction on how to do this, and I didn’t feel the need, so I didn’t do it.  A link to how to do it would have been nice, however.  I believe they wanted you to log into Prime Infrastructure and go here:

Services > Mobility Services Engines > smonmsep01 > System > Maintenance > Backup Operation


Step two and three was Transfer the *.tar file fro to the MSE appliance and place it in the /opt/installers folder.

The step said to use “CISCO-MSE-L-K9-7-4-110-0-64bit.db.tar”. 


I found the file to be named “CISCO-MSE-L-K9-7-4-110-0-64bit.bin.gz” on CCO, which I downloaded.  I used WinSCP to simply and painlessly FTP the file from my desktop to the MSE.  You’ll need the username, password and IP address of your MSE.




Step four was to decompress the file.  I used TeraTerm to SSH into the appliance.


[root@CiscoMSE /]# cd opt


[root@CiscoMSE opt]# ls (next step change to OPT)

data  installers  lsi  MegaRAID  mse  oracle  ORCLfmap


[root@CiscoMSE opt]# cd installers

[root@CiscoMSE installers]# ls





The directions stated step four was to “Untar the file: tar -xvf CISCO-MSE-K9-7-4-110-0-64.bit-db.tar”. 

My file was .gz, so I skipped that step and when right to gunzip.


Now we can actually unzip the file with the gunzip command.  


[root@CiscoMSE installers]# gunzip CISCO-MSE-L-K9-7-4-110-0-64bit.bin.gz

[root@CiscoMSE installers]# ls





Next we change the permissions of the file so we can execute the installation.


[root@CiscoMSE installers]# chmod +x CISCO-MSE-L-K9-7-4-110-0-64bit.bin


Now stop the MSE.



[root@CiscoMSE installers]# service msed stop

Stopping MSE Platform

Shutting down framework and services ...

Shutting down framework and services ....................

Flushing firewall rules: [  OK  ]

Setting chains to policy ACCEPT: nat filter [  OK  ]

Unloading iptables modules: [  OK  ]


The next step was to uninstall the existing MSE software.  There were no directions, links, etc, on how to do it, so I skipped that step and went to the next one, which was “invoke the MSE Installer”.  I will also include the output of the CLI just as a reference.  This took less than a half hour to complete.


[root@CiscoMSE installers]# ./CISCO-MSE-L-K9-7-4-110-0-64bit.bin

Preparing to install...

Extracting the JRE from the installer archive...

Unpacking the JRE...

Extracting the installation resources from the installer archive...

Configuring the installer for this system's environment...


Launching installer...


Preparing CONSOLE Mode Installation...



Cisco Mobility Services Engine    (created with InstallAnywhere by Macrovision)




InstallAnywhere will guide you through the installation of Cisco Mobility

Services Engine.


It is strongly recommended that you quit all programs before continuing with

this installation.


Respond to each prompt to proceed to the next step in the installation.  If you

want to change something on a previous step, type 'back'.


<read this carefully>


Licensing on the Mobility Services Engine is enforced with the release of

software version 6.x and greater. Please have the Product Authorization Key

(PAK) and refer to the instructions in the User Guide to enable licensing.





Installing MSE version:


Installation Check


The system appears to have a Cisco Mobility Services Engine already installed.

If you choose "Continue", all the currently installed components will be

removed permanently (Only database and license files will be preserved).


  ->1- Exit

    2- Continue





Current Role - Primary



High Availability Role is currently set to Primary from previous installation.


If need to change role to Secondary or re-configure high availability settings,

please execute after installation is completed.





MSE Startup



Would you like the Cisco Mobility Services Engine to startup automatically at

system boot up?


  ->1- Yes

    2- No






Pre-Installation Summary



Please Review the Following Before Continuing:


Product Name:

    Cisco Mobility Services Engine


Install Folder:



Link Folder:



Disk Space Information (for Installation Target):

    Required:  2,570,778,828 bytes

    Available: 497,276,530,688 bytes











Database Installation


The installer will now install the database. This may take a long time (up to

30 minutes). Do not cancel the installer.





!!!! IMPORTANT NOTE !!!! :



The system is minimally configured right now. It is strongly recommended that

you run the setup script under /opt/mse/setup/ to configure all

appliance related parameters immediately after installation is complete.


The hostname must be set correctly on the system. The Cisco MSE platform will

NOT start if it is configured incorrectly or not configured at all.


Additionally, it is strongly recommended that the Cisco MSE be configured to

use the same NTP servers as the controllers with which it will be synchronized.

This is essential to the correct operation of the Cisco Mobility Services



Both these parameters may be configured as part of the setup script.





Installation Complete



Congratulations. Cisco Mobility Services Engine has been successfully installed





Licensing on the Mobility Services Engine is enforced with the release of

software version 6.x and greater. Please have the Product Authorization Key

(PAK) and refer to the instructions in the User Guide to enable licensing.


PRESS <ENTER> TO EXIT THE INSTALLER: [root@CiscoMSE installers]#


Just a note about this:  I didn’t see the MSE come back to life.  I had to restart the service.  Command is “service msed start”


[root@CiscoMSE /]# service msed start


Starting MSE Platform


Flushing firewall rules:                                   [  OK  ]

Setting chains to policy ACCEPT: filter                    [  OK  ]

Unloading iptables modules:                                [  OK  ]

Starting Health Monitor, Waiting to check the status.

Health Monitor successfully started

Starting Admin process...

Started Admin process.

Starting database ....

Database started successfully. Starting framework and services .................

Framework and services successfully started

[root@CiscoMSE /]#


Now to check with Prime Infrastructure – which was just upgraded to 2.0 several days ago. (the reason for this upgrade)




Here’s a screenshot from this link:










Saturday, November 2, 2013

How to block Bit torrent on your WLAN

I came across an interesting feature I would like share on the 7.4 version of Cisco 5508 WLAN controller.


I was asked to block bit torrent, audio and voice streaming on the guest WLAN for obvious reasons.  The old way, doing it on a firewall or with an ACL on the WLAN controller was rather clunky at best.


If you are either on 7.4 or can jump to it, here’s all it took to turn on this nifty feature.


Here’s the flavor of code that I’m running:



Browse to Wirelessà Application Visibility And Control à AVC Profiles and select NEW.




Next come up with a name that fits your organization.  I’ll call mine “WLAN Restrictions” because there will be a list of things and not one single application.  Your mileage may vary, of course.


After you create the Profile, click on it and you will see that there are no rules associated with the profile.



Look over to the right hand side of the screen and click on “Add New Rule”…


This way is kind of clunky, but I will go ahead with explaining it.  To block Audio, you have to select “voice-and-video” as the Application Group and then select the Application Name.  In this case, I selected “audio-over-http” and then selected Drop as the action.


Now you can add another rule.  But this time we’re going to go a different way.  We want to block bit torrent, but we don’t know which Application Group it is in.  This time, browse to Wirelessà Application Visibility And Control à AVC Profiles and select AVC Applications.



This time,



Scroll down and click “bittorrent” and then use the AVC Name Drop down and select the Application Profile you created in the first step and select Ddrop as the action.  Drop is the default, so you really don’t have to do anything.



Now browse to the WLAN you want to apply the AVC Profile to.  I’m sure you know where it is, but in case you forgot, browse to WLANSà WLANsà WLAN ID (of the WLAN Profile) and then browse to the QoS tab.  Select the AVC Profile and apply.


That’s it.  You’re finished.  Don’t forget to save your config! 


Wednesday, August 14, 2013

Wall mounting vs. Ceiling mounting your access points

This post stems from the knowledge of how to properly mount your access points.  I recently went to do a validation survey for a 5 GHz WLAN, and discovered two of the three access points were mounted on the wall, perpendicular to the floor.


I decided to survey it anyway, and then remount the access points another day when I had the appropriate hardware, and re-survey.  I wanted to see what the actual coverage pattern would be – a “before and after”, if you would like to think of it that way.


Here is the coverage of the floor before making any changes.  The green and purple coverage patterns are created by two access points mounted “incorrectly”.  They’re both hanging like wall clocks, instead of being mounted on the ceiling like UFOs.  The brick colored pattern is mounted horizontally, and no change was made to this access point.



Here is the overlapping coverage in red.



I remounted the green access point horizontally about 3 feet from the telepole where it had been mounted vertically.  The “purple AP” I had to move from the hallway into the room next to the stairwell since there was no ceiling or structure to mount it to in the hallway. 



This is the “after” overlapping coverage area.



I must admit that I expected something a little more dramatic.  I used the same laptop, the same adapter, and walked the same path on both surveys.


I’m interested if anyone else has done any comparison surveys like this, what did they show?








Tuesday, April 30, 2013

Offloading your guest WLAN onto local cable/DSL/FiOS

This is the first post of several posts describing how to offload your guest WLAN internet traffic from your backbone and out a local internet provider.  Why would you want to do this?  If you have a corporate WLAN and are tunneling your guest traffic over the leased lines, your guest traffic could quite easily exceed your production traffic.


First of all, you may be tempted to use the DHCP server on the ASA5505 appliance.  Although this can be done, it would be nice if you could use your corporate DHCP services that are already in place.  Let’s start at the bottom – as if you have never administered a Windows DHCP server and go all the way to the end – with offloading your traffic.  Note – this the first of several blog posts.


First, this post explains how to install the admin pack for Windows 7 machines and start using it.  This will allow you to manage the DHCP server function that runs on the Windows 2003/2008 servers.


Administration pack tools do not come with Windows 7. You have to download it from Microsoft site and install it.  This administration tools pack allows you to do most of the Windows 2003, Windows 2008 and Windows 2008 R2 server tasks from your Window7 computer.


DHCP manager is one of the admin pack tools to manage DHCP servers and it allows you to do it right from your workstation.  Installing Admin or administrators pack on Windows 7 is slightly different than earlier versions of Windows.


Steps for installing Admin pack on Windows 7 Professional, Enterprise, or Ultimate editions.


Download the server administration pack here:


After downloading, Start the installation. Yes for Install update.



Once successfully installed, next screen shows how to install each feature of admin pack tool.  Without doing the following steps you can’t find any of the administration tools in program files or control panel. Close the screen and go to control panel. 


Go to Programs and features. Select Turn Windows features on or off then select Remote Server Administration Tools as shown below. (blue and yellow icon)




You must be in administrator group or administration tasks privilege should have been given to perform some of server tasks. In this example I select DHCP server Tools which help to manage multiple DHCP servers from my Windows 7 computer.


Press OK.


The newly added administrative pack tool feature can be found under Administrative Tools in Windows 7. (your window may look differently than mine)


Now we are going to add a DHCP server so we can add a new DHCP scope.


Click on Administrative Tools.




The  Administrative Tools window pops up:




Double click DHCP and the following window pops up:




Click on Action -à Add Server….  (sorry for the blur – it was necessary in this case)



Choose the existing DHCP server that you want to create a DHCP scope on.  In this example, I am creating a scope for the guest wireless internet users in our fictitious Redmond, WA, office.




The DHCP server has now been added so you can be an Administrator.



Now I am going to create a new DHCP scope.


Next, click on Action à New Scope… and the “Welcome to the New Scope Wizard box pops up”.





Click Next and Enter in the name of the scope you are creating.




Click Next and enter in the range of IP addresses that you want to hand out.





Click Next and enter in any IP addresses you do NOT want to hand out.  You might need this if you have some static IP addresses somewhere on the subnet.  In this example there are not exclusions.




Click Next.  I am setting up the lease time for two hours since the guest network is for transient clients.




Click Next.  You will need to set up some options, such as the DNS server and gateway you want the clients to use.




Click Next, and enter is the router’s IP address that you want the clients to use as their gateway.




Click Next.  This one is tricky.  Since the guest network is not on the production network (and tied to a DSL/Cable/FiOS circuit) you will not want to use the corporate DNS servers which are inside your network since they will not be reachable by the client devices.  In this example, I am adding, which is Google’s public DNS servers.  They are accessible from the circuit outside of the network – and most likely your home, too!




Click Next… nothing to do here.





Click Next.  Yes, you want to activate the scope now.




Click Finish.  Now you’re done.




Now you are finished.  If your network is all built and clients are waiting, you can browse to the scope you just created and look at the Address Leases folder.  In the middle pane you should see new leases being handed out.






















































Tuesday, February 19, 2013

Disabling 6 and 9 mb/s Cisco 1310 bridges

We all know the benefits of trimming off 802.11b from your 2.4 GHz network.  The task is quite easy, so here goes:
I trimmed off 802.11b entirely with the command:
interface Dot11Radio0
speed only-ofdm
I then attempted to trim off the lower two OFDM data rates.  I consulted the manual on how to do so, and here is what I found: (READ VERY CAREFULLY)
and entered in the following command:
interface Dot11Radio0
no speed basic-12.0 basic-18.0 basic-24.0 basic-36.0 basic-48.0 basic-54.0
The result was that all data rates were disabled except 6 & 9 mb/s.
Show run:
interface Dot11Radio0
 speed  basic-6.0 basic-9.0
The command entered to disable the lower two data rates actually did the opposite!
Here's the "fix" - or what worked for me.
config t
interface Dot11Radio0
speed basic-6.0 basic-9.0 basic-12.0 basic-18.0 basic-24.0 basic-36.0 basic-48.0 basic-54.0 (restored it the way it was)
no speed basic-6.0 basic-9.0 (removed the lower two data rates)
The "fix" is the way I would have done it in the first place, until I found the manual and read it.  Did I interpret the manual incorrectly?