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!