Site Survey: Intravenous WiFi (Survey Pole)

Recently, I repurposed an old IV pole as a site survey rig.

Some see a collection of old carts and IV poles waiting to be thrown away as trash. As for me, I see parts for a survey rig ! This isn’t anything special and I didn’t say it was pretty. I am repurposing a few of these for local survey rigs. I plan to keep 1 at each hospital.

I mention the word “local” rig because this isn’t something that you can pack up and fly with. But if you work in healthcare it could be ideal to have one of these at each site. Or if you travel locally these travel comfortably in an suv.

IV poles come in all different shapes and sizes. I was lucky to find one that extends 12 feet in height and is very stable when fully extended with an access point attached. The casters are low profile and the battery (Terrawave) is placed at the base held into place with velcro. I have a cat5 cable running the length of the pole held in place with velcro. The access point is secured in place with a band clamp and a piece of velcro on top to stabilize the ap.

This is still a work in progress.

At the end of the day it meets my need. It is very mobile and it was FREE!

ivpole.batter

Wavelink Avalanche Cisco 79xx Wireless Phone Deployment

Over the next few weeks I’ll share my deployment strategy, challenges, design overview, testing and hands on experience while deploying one of the largest Wavelink Avalanche Cisco 79xx Wireless Phone deployments on planet earth!

I was challenged to reduce our organizations Cisco 79xx Wireless Phone deployment overhead while improving our post deployment manageability.

After clearly understanding the needs and requirements I evaluated a number of solutions and internal procedural changes to streamline a planned massive Cisco 7925 Wireless Phone deployment. It was clear an enterprise solution was needed.

Communication in Healthcare is arguably the most critical. It could mean life or death. Managing thousands of wireless phones in a healthcare system becomes a very sensitive matter while also posing a massive responsibility and an attention to detail at an extremely high level.

The consideration to demo Wavelink initially was a no brainer. The Wavelink ‘agent’ is already installed from the factory on each Cisco 79xx wireless handset. Wavelink is not new to me. Previously I was employed by a mobility company that deployed WiFi for 2 of the largest rental car companies in the US. We used Wavelink to manage thousands of Motorola hand helds across the nation.

I was surprised and concerned to learn that there wasn’t a lot of web content specific to Wavelink Avalanche and Cisco deployments. If you are considering Wavelink Avalanche I hope these post help you with your Wavelink journey.



WLC: Configuring Dynamic Anchoring for Clients with Static IP Addresses

If you have a WLAN that requires a large mobility area for roaming and your client needs to be static. This feature is something you should consider! This will allow you to break up these large subnets into much smaller sizeable subnets while still allowing static address on your mobile devices. 

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

WLC: How Cisco Virtualizes The Base Radio MAC ADDRESS On The WLC – Did you know?

This is a quick blog post on how Cisco uses the VIRTUAL MAC ADDRESS for BSSID(s).

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!

WCS: WCS HA FAIL OVER – HOW TO MANUALLY FAIL OVER!? – DID YOU KNOW?

I’ll save you a call to TAC … How to fail over your WCS server in HA mode manually..

I initially thought, shutting down the primary WCS gracefully it would failover to the secondary WCS. It didn’t.

WHAT I LEARNED …

If you shut WCS down gracefully “StopWCS” she doesn’t failover. In fact, either you have to pull the cable or hard shut down the server for the WCS to failover.

TESTING WCS HA FAIL OVER

If you want to test WCS fail over from your primary to secondary WCS server enter the following command in the primary WCS server CLI:

/WCSROOT/bin/nmsadmin.bat -switchover stop

ENJOY!



WCS: WCS Server Diagnostics Page

I always enjoy speaking to knowledgeable Cisco TAC engineers. I recently was experiencing some VERY SLOW WCS server response. The TAC engineer enlightened me to a “Server Diagnostics Page”

 “I find it most successful to have multiple windows open to WCS at the same time, one of the GUI and one of the diagnostic page.  Navigate a page in the GUI, then change windows to the diag page and click Refresh.  Use the browser's File > Save As utility to capture a copy of the diag page while WCS is in pain, and send it in for review.  We'll take a look at what the Java threads are doing, and what tables they're interacting with, and know better what actions to take to address the latency.” --TAC

 https://<WCS>/webacs/pages/admin/serverDiagnosticInfo.jsp



Cisco Security Advisory: Cisco Wireless LAN Controllers Denial of Service Vulnerability

DONT PING YOUR CISCO WLCs! LOL

Document ID: 112916

Advisory ID: cisco-sa-20110427-wlc

http://www.cisco.com/warp/public/707/cisco-sa-20110427-wlc.shtml

Revision 1.0

For Public Release 2011 April 27 1600 UTC (GMT)

---

Contents

Summary
Affected Products
Details
Vulnerability Scoring Details
Impact
Software Versions and Fixes
Workarounds
Obtaining Fixed Software
Exploitation and Public Announcements
Status of this Notice: FINAL
Distribution
Revision History
Cisco Security Procedures

---

Summary

The Cisco Wireless LAN Controller (WLC) product family is affected by a denial of service (DoS) vulnerability where an unauthenticated attacker could cause a device reload by sending a series of ICMP packets.

Cisco has released free software updates that address this vulnerability.

There are no available workarounds to mitigate this vulnerability.

This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20110427-wlc.shtml.

[Expand all sections]     [Collapse all sections]

Affected Products

Vulnerable Products

This vulnerability affects Cisco WLC software versions 6.0 and later. The following products are affected by the vulnerability described in this Security Advisory:

• Cisco 2100 Series Wireless LAN Controllers
• Cisco WLC526 Mobility Express Controller (AIR-WLC526-K9)
• Cisco NME-AIR-WLC Modules for Integrated Services Routers (ISRs)
• Cisco NM-AIR-WLC Modules for Integrated Services Routers (ISRs)

Note: The Cisco NM-AIR-WLC have reached End-of-Life and End-of-Software Maintenance. Please refer to the following document for more information:

http://www.cisco.com/en/US/prod/collateral/modules/ps2797/prod_end-of-life_notice0900aecd806aeb34.html



Cisco Wavelink (Avalanche) Bug:CSCtb45669 Code 1.3(3)

We are deploying thosands of Cisco 7925 handsets with Wavelink. After extensive testing I discovered that I could not get the phone to reboot after a profile push. I reached out to Wesley Terry (Cisco's Escalation Team) and BAM! He delivers for me ... Thanks Wesley !

792x is not reprovisioning after receiving Wavelink package

Symptom: 792x is not reprovisioning after receiving Wavelink package. If updating profile 1 or switching from profile 2, there is no provisioning trigger occurring, but the network profile config is updated. The phone stays connected with the previous network profile information even if not existing in the network profiles. Condition: Pushing a package to the 792x via Wavelink. Workaround: Power cycle the phone This is resolved in code 1.3(4)



Cisco WLC WLAN Summary Display Bug: CSCth52309 - 7.0.98.0

I was working with a colleague when I noticed the WLAN Summary Display on the WLC showed NO clients, when we knew there was indeed clients. In fact when you hit the client page there was over 100 clients on the controller.

After looking at another controller the WLAN Summary Display showed 30,000+ clients, again we knew this wasn't accurate. After speaking with a Cisco SE we discovered there is a bug in 7.0.98.0, "WLAN summary display defect causing wrong count to be displayed, defect number CSCth52309" 

This bug is fixed in 7.0.114.51 or greater.

As of this post this BUG was not in the bug tool kit. However it comes from a very reliable Cisco SE.

WCS: Limited Audit Trail in WCS

As our engineering group grows, so does the need for proper auditing measures. A user with Admin credentials to WCS has the power at his/her fingertips to make changes to your WLAN enterprise.

Currently, there is very limited accounting visibility in WCS itself. In fact, if you want detailed accounting you need to look at ACS AAA logs.

Bug / Feature Request - CSCta98733 Need TACACS accounting support on WCS

CSCta98733 Need TACACS accounting support on WCS.

The above case number can be used for bug tracking. It hasn’t been mentioned WHEN this feature will go in and I understand it was “postponed.”

LOCAL WCS AUDIT

WCS currently does offer very limited local visibility into WHO and WHEN they logged in.

Go->Administration->AAA->(User/groups/active sessions) and click on Audit Trail.

Again, very limited and pretty disappointing.



CWNP - Gestalt IT Wireless TechField Day

I would like to thank CWNP for their contribution to the Gestalt IT Wireless Tech Field Day

CWNP Provided each Wireless Tech Field Day delegate with a FREE hardcopy of their choice of either the CWAP or CWDP study guide!

I wanted to take a moment and thank both Marcus and Kevin for their continued contribution to the wireless community. It was a pleasure to meet Marcus in person. What a talented young guy with a passion and fire for WiFi.

I also wanted to show some love to Kevin Sandlin. A lot of folks may not realize the driving force and focus behind CWNP. Kevin is the guy behind the curtain keeping the CWNP momentum alive and well.  Kevin, thank you!

I also want to show love to their entire CWNP crew and authors of the recent CWDP and CWAP study guides!!

www.cwnp.com

Fluke AirCheck - Gestalt IT Wireless TechField Day

I would like to thank Fluke Networks for their participation in the Gestalt IT – Wireless Tech Field Day

Fluke Networks Presenters

Carolyn Carter
Paul Hittel

Presentation

Fluke Networks presented their Aircheck product. The presentation covered a slide deck, live demonstration and hands on session with AirCheck.

Product Focus

I was pleasantly surprised by Fluke’s AirCheck offering. I will be first to tell you, when I think of Fluke Networks, I don’t think of wireless tools (outside of AirMagnet of course). Fluke is largely known for quality wired side handheld tools.

Fluke AirCheck is a dedicated WiFi handheld analyzer. It is extremely lightweight and gives you the typical “Fluke feel”. Fluke positions the AirCheck product as an entry WiFi handheld analyzer. Fluke designed AirCheck with one thing in mind “Keep it simple”!

AirCheck:

• Dedicated, handheld 802.11 a/b/g/n wireless network tester with instant-on technology
• Rapidly perform a wireless discovery to fully assess your current wireless security settings and network availability
• See wireless network utilization by channel and quickly determine if it is 802.11 traffic or non-802.11 interference
• Robust and in-depth WLAN connection tests - from probing to DHCP request to ping
• Quickly identify and locate wireless access points whether authorized or rogue
• Fully document your troubleshooting session thus enabling fast trouble ticket resolution or problem escalation

HANDS ON

I was very impressed with Fluke’s AirCheck. Within seconds of turning it on, you’re analyzing a wireless network! I haven’t seen anything as fast as the Fluke AirCheck since Air Magnet’s (iPaq) version. AirCheck has a lot of cool features, which are all designed with the with the idea of  ‘keeping it simple’ . So simple in fact a ‘Rocky’ could use them! (Inside joke).

What you will see on the Fluke AirCheck:

List Wireless Networks

List Access Points

Channel Usage

Channel Usage Details

Access Control Settings

Locate Access Points

Access Point Details

Connect

List Probing Clients

You can quickly move through the menu options in real time with no delay.What you won't find on the Fluke AirCheck is packet analysis. Frankly, AirCheck wasn’t designed for that level of analysis.

Keeping it real

There is a price to be paid to have this technology in your bag and its not inexpensive. These babies retail for $1,999 dollars. There are of course less expensive WiFi analyzers. The value proposition for the Fluke AirCheck is six letters SIMPLE. Get an AirCheck in your hands and you can see the instant value for yourself.

With all things being said, AirCheck is a good product. If you are a network generalist, wired engineer or even a veteran wireless engineer looking to get an easy to use WiFi network analyzer you should consider Fluke Networks AirCheck.

Contact Information

www.flukenetworks.com

MetaGeek - Gestalt IT Wireless Tech Field Day

I would like to thank MetaGeek for their participation in the Gestalt IT – Wireless Tech Field Day. There product advancement was an eye opener for me ….

MetaGeek Presenters

Ryan Woodings - Chief Geek

Trent Cutler -  The "Intern"

Presentation

MetaGeek presented their Wi-Spy and Chanalyzer Pro product. The presentation covered a live demo of both products. Ryan started off with a review of their humble beginnings, which covered a bit about their financials.

Ryan is a software geek who loves to hack software. Did you know Ryan got the idea of a spectrum analyzer because he was troubleshooting a WiFi mouse interference issue?

MetaGeek is self funded, no VC injected and they are a profitable company. And if you didn’t know, they are not a Silicon Valley company. They’re actually located in good ol’ Boise, Idaho. Keeping the RF real in the land of the Potato.

In 2005, while working on some cool short-range wireless technology, our office had a single spectrum analyzer shared amongst a team of engineers. It was big, cumbersome, and expensive. I was tired of having the spectrum analyzer cart in my cubicle, so one night I starting hacking some firmware and software to create the first Wi-Spy. Sure, it wasn’t nearly as sophisticated as the Agilent spectrum analyzer I had been using, but it was a lot smaller and easier to use, which was pretty cool. I figured maybe other people would think it was cool too… and the rest, as they say, is history Today MetaGeek is a small tight-knit team of folks (mostly geeks) that strives to create easy-to-use wireless troubleshooting tools.
- Ryan

Product Focus

I was an early MetaGeek adopter. I have to admit, I hadn’t kept up with their continued product advancements. I will say, that’s my loss! I was very very impressed with their product focus during the presentation. These guys love what they do and their passion was immediately noticed within minutes into the presentation.

Their product line covers 900, 2.4 and 5 GHz spectrums. All of which, is in a USB form factor #WINNING. MetaGeek ‘s products are at a price point that allows even the network generalist and you wired guys to jump into wireless spectrum analysis without breaking your wallet!

I  was surprised to learn how much customer interaction goes on at MetaGeek. If you have an interference capture and you aren’t quite sure what it is. Zip up the capture and send it off to Trent (the guy with the Bieber haircut – Sorry Trent) and he will help analyze it with you.  Having that personal vendor attention is just another added MetaGeek bonus.

MetaGeek also presented an iPad app which is under development. Don’t get excited it currently only replays captures and doesn’t take capture readings. But still, what a great tool to demo in front of a customer or class or to analyze offline.

MetaGeek is focusing efforts on adding signatures and tightening up their duty cycle readings in future releases. They are also looking to improve their remote capture capabilities.

Conclusion

Im a fan and you should be too! These guys are like you and me (true geeks) who love what they do and have a passion doing it …

In the next few weeks I will be dedicating space to Wi-Spy and Chanalyzer Pro captures here on my80211.com. Why, because Im sold on their product and their dedication to helping the WiFi community by providing RF Spectrum products at a price point for guys like you and me!

Support these guys!

Contact Information

WebSite: metageek.net

Twitter: @metageek

Gestaly IT Links

http://gestaltit.com/field-day/2011-wireless/

Disclosure

Each Wireless Tech-Field Day delegate received a product sample of the following:

(1) Wi-Spy DBx Pro
(1) Chanalyzer Lab Software
(1) Chanalyzer Pro Software
(1) Device Finder Directional 2.4GHz antenna
(1) Offical Wi-Spy Interference Test Kit (Popcorn!)
(1) Kick ass lunch box!



CISCO ACS 5.x RADIUS EAP-PEAP MS-CHAPv2 BUG WITH A “BIG BITE”: CSCth66302

If you are using Cisco ACS 5.1 or 5.2 and you use EAP-PEAP with MSCHAP v2 you should be aware of bug CSCth66302. It’s nasty and could impact your wireless network.

If you leverage EAP-PEAP MS-CHAPv2 in your environment and you are using Cisco ACS version 5.1 or 5.2 you need to be aware of this bug!

The bug we hit was CSCth66302 and it wasn’t pretty. As wireless clients attempted to authenticate the Cisco ACS responded with client failures, thus not authenticating the clients. When you looked at the ACS logs you would immediately see “Radius Authentication Request Rejected due to critical logging error”   in nice big red letters! When you looked at the WLC the logs showed all the EAP-PEAP clients failing authentication.

Interestingly enough, the Cisco WLC NEVER moved to the back up ACS, which was configured under the WLAN. Why? Because the local ACS sever (which was failing) still responded to the client via the WLC. As far as the WLC was concerned, the ACS responded and life was good!

 The Temporary Work Around from TAC

If you still get these messages the workaround is to restart ACS runtime service from the CLI:-

# acs stop runtime
# acs start runtime

Fix Coming in Release 5.3

Cisco TAC stated a fix will be released in ACS 5.3, which is yet to be released.

BUG Information 

http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_system/5.2/release/notes/acs_52_rn.html  

CSCth66302

RADIUS authentication request rejected because of a critical logging error. Symptom: Running stress PEAP MS-CHAPV2 against primary ACS machine fails with the following error message: Radius Authentication Request Rejected due to critical logging error Conditions: This problem occurs when there is a large deployment setup with one primary connected to seven secondary machines. Workaround: None.

End-of-Sale and End-of-Life Announcement for the Cisco 3350 Mobility Services Engine

Title: End-of-Sale and End-of-Life Announcement for the Cisco 3350 Mobility Services Engine

Url: http://www.cisco.com/en/US/prod/collateral/wireless/ps9733/ps9742/end_of_life_notice_c51-643839.html

Description: Cisco announces the end-of-sale and end-of-life dates for the Cisco® 3350 Mobility Services Engine. The last day to order the affected product(s) is June 5, 2011. Customers with active service contracts will continue to receive support from the Cisco Technical Assistance Center (TAC) as shown in Table 1 of the EoL bulletin. Table 1 describes the end-of-life milestones, definitions, and dates for the affected product(s). Table 2 lists the product part numbers affected by this announcement. For customers with active and paid service and support contracts, support will be available until the termination date of the contract, even if this date exceeds the Last Date of Support shown in Table 1.
Date: 2011-03-07 09:00:00.0

WLC: Radius Statistics Command

It is always nice to get emails from twitter and blog peeps. I received an email from Bruce from Erie, PA asking:

 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



WLC: Management via Wireless – Did you know ?

In recent weeks, I fielded a number of questions on the forums about “WLC Management via Wireless”. I thought, I would follow up with a quick blog post on the subject.



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)

 

WLC: Internal Anchoring Solves VRF Challenge

Internal Anchoring -- Thinking outside of the box

Cisco’s unified guest architecture, also referenced as ‘anchoring or auto anchoring’ is a common way to provide a secured wireless guest solution in an enterprise environment. What makes this secure and unique is the native frame generated by the wireless guest never touches the network switch fabric, until it egresses the anchors outside controller port where the encapsulated frame is unwrapped. At which point, the 802.11 header is stripped and 802.3 headers are installed and the frame is placed on the wire.

You can read more about anchoring here:

http://revolutionwifi.blogspot.com/2010/10/auto-anchor-mobility-fundamentals.html

http://www.cisco.com/en/US/docs/wireless/controller/7.0/configuration/guide/c70mobil.html

Commonly, when the term ‘anchoring’ is mentioned, guest access comes to mind. However, recently I was presented with a challenge where I leveraged Cisco’s anchoring capability to solve a VRF problem. I coined it as, “internal anchoring”.

We have a very large network and deploy VRFs around our campus to segment a certain user group. We were presented with a problem where we could not access the VRF for testing purposes at our IT office, because we did not have our VRF network configured at the IT office location. 

We could have dragged the VRF to our office, which would have involved a good deal of configuration and since it was only going to be used for testing by a handful of network engineers it would have been a lot of work.

So, we did the next best thing…

The location (building), where the VRF user group lives also lives a number of Cisco WLCs supporting wireless connectivity for this VRF building. For sake of this post the WLCs living in this building will be called the VRF/WLC. 

An SSID was created on one of the VRF/WLC as WLAN: VRF_TEST. This WLAN was then anchored to itself, as normal anchoring procedure.

On the other end, at the IT office also lives a WLC. This WLC was providing wireless connectivity to the IT office.  For sake of this post the WLC living in the IT office will be called the IT OFFICE/WLC.  The WLAN: VRF_TEST was created on the IT OFFICE/ WLC and then anchored to the VRF/WLC.

This anchoring process will allow us to simply connect to the VRF_TEST at the IT office and have access to the VRF at the VRF building just like if we were physically there in person. This configuration effort took less than 5 minutes.

** Note: Mobility Group configuration was also required **

WLC: Predownload the Image to the Access Points from the controller CLI

Why preload the image on the access points?

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 !

GEORGE STEFANICK - CWSP JOURNEY, (CHAPTER 4 –AAA, POST#8)- 2/11/2011

I’m back !!!!! On the study horse that is...

AAA – What is it ?

“Triple A”, as it is sometimes called, is a model for access control. It really is the model and basic frame work for security. There are 3 distinctive features in AAA, which are:

Authentication

Authorization

Accounting

Authentication

Authentication is the process to determine whether someone or something (entity) is, in fact, who they say they are.  This is commonly done with user credentials (logon and password). The credentials are then presented to a “server” for verification. Other means, such as tokens and digital certificates can also be used in place of or combined with user credentials. This is called multi layer authentication. It is used to enhance the authentication process.

Authentication uses UDP port 1812, prior to IANA allocation 1645

Authorization

Once the entity is authenticated. Authorization can then take place. Authorization is the process of granting access or permissions to the entity. You are allowing the entity the privilege to do or have access to something on your network.

Accounting

Accounting is a means of keeping track of the entity, while on the network. This is often used by security to track what the entity did, how long they were on the network, what commands they may have entered, etc.

Accounting uses UDP port 1813, prior to IANA allocation 1646

Radius Server

The radius server is sometimes called the AAA server. This is because most common radius servers support all three functions. The Cisco ACS server is an example of such a device.

Other Radius Servers Include:

Juniper Steel Belted Radius

Microsoft IAS (Server 2003)

Microsoft NAP (Server 2008)

Free Radius

Configuration Notes

Speaking from experience (also noted on page 121) there are 2 common mistakes that happen often when setting up a radius server. One is using the wrong port numbers. Two is using the incorrect shared secret between the radius server and the authenticator.  If you have issues in your initial setup, this is something you should check.

RFC

Radius Authentication and Authorization is defined in:

IETF RFC 2865

http://www.ietf.org/rfc/rfc2865.txt

Radius Accounting is defined in:

IETF RFC 2866

http://www.ietf.org/rfc/rfc2866.txt