Wireless – Context Is Everything

CLICK HERE FOR MORE DETAILS on how to utilize Ciscocmd to monitor you entire network at a glance and keep your finger on the pulse of your global communications infrastructure.

SUBSCRIBE HERE for to receive useful updates and tips for Network Administration and Automation.

This article will discuss the issues you will face when attempting to administer your Cisco wireless network.

Massive Amounts of Data
One of the primary problems of monitoring and maintaining a large Cisco wireless implementation is handling the large amounts of information available from the various components of a Cisco Unified Wireless Network.

• WCS Alarms
• Mobility Anchor Status
• Authentication Infrastructure Status
• Roaming AP’s
• Wireless DHCP Pool monitoring
• Access Point Primary / Secondary Controller Relationships
• Access Point Availability
• Radio Monitoring

This article will cover how to monitor these components.

Cisco WCS alarms
In large Cisco wireless installations you will find that there are hundreds and sometime even thousands of alarms. These alarms will quickly overwhelm any team attempting to monitor them. A good way to monitor these alarms is to have them sent directly to your email. Create a special folder for the alarms so they do not flood your inbox. Or you can view them on the WCS directly. However, if you view the alarms in WCS directly, you will most likely just start ignoring the alarms.

I would suggest skimming the alarms in your inbox every day for anything that stands out as well as general patterns.

Mobility Anchor Status
If you work in a large corporation, it is important to be aware of your mobility anchor status. In a large company hundreds of people may connect to your guest wireless access. When the mobility anchor is down, it is likely you will receive a flood of calls stating that wireless is down, everywhere. The issue could be anything. It could be a number of issues such as authentication infrastructure failures, AP controllers failures, a network failure.

If you have the status of your mobility anchors and their connections to wireless controllers at your fingertips, you will be able to quickly identify or eliminate anchors as the root cause of the outage.

Authentication Infrastructure Status
Wireless authentication server infrastructure is a possible consolidated point of failure for the wireless infrastructure. Large enterprise implementations can often use 4 to 8 authentication servers based on geographic locations as well as overall authentication load. Most implementation have primary and secondary servers for redundancy.

The issue with authentication servers is that an administrator is often not  aware of problems on the primary of secondary servers. If a primary server stops authenticating, an admin may not be aware because users are still able to log on to the network via the secondary server. Also availability monitors  will not catch the primary server issue because it is not disconnected from the network. It has stopped responding to authentication request.

The wireless network admin will only become aware of the issue, when he or she gets a call at 3:00 am stating that the night shift cannot use the wireless network, because the one remaining authentication server has gone down. Basically, the users become the monitoring system.

To prevent this scenario, you must monitor your authentication servers by  performing actual authentication requests. In a future article, I will describe how to do this. By creating a synthetic transaction monitor and sending actual authentication requests, you will be able to immediately assess if a particular authentication server is working correctly. If the synthetic authentication request fails, the monitor can generate an email alert to the administrator.

Roaming APs
This is an emerging issue for large enterprise wireless implementations. It is important to assess if your APs are associated to either their primary or secondary controller, because some implementation can have special configurations that depend upon the associated controllers. It is possible that an AP will stop allowing network access if associated to a unspecified controller. Then users may start complaining of connecting to an AP but being unable to access the network. If all of your APs are associated to the correct controller you can skip this section. If you find your APs have roamed over time, there are a few ways to quickly assess this. In a future article or video I will address how to perform this assessment.

Wireless DHCP Pool Monitoring
The number of wireless clients on a particular network can be highly variable. One possible reason for outage is a DHCP pool that has reached capacity. Believe me, this one can sneak up on you in a large enterprise. Guest Wlan is a wlan that have a high risk for maxing out it’s alloted DHCP pool. At precisely this time, a visiting CEO  comes to your campus to speak to your entire executive comittee and cannot connect to the guest wlan!

The main technique to monitor your wireless DHCP pools is using SNMP. There are no specific simple techniques that I can illustrate because the SNMP objects are vendor specific. However, you may want to check out Cacti as an open source SNMP monitoring tool. Also Paessler’s PRTG is an affordable paid SNMP monitoring tool. It is easy to use and powerful in it’s display and reporting capabilities.

Access Point Primary / Secondary Controller Relationships
It is important to be aware of the primary and secondary controller relationships you have set up. Typically, each wireless controller has a maximum number of APs that can be associated with it. If you have several controllers with APs connecting to them all pointing to one or a few failover controllers, you could be in danger of being over capacity during a controller failover event. In future articles, I will show you how to expand the use of the ciscocmd utility to monitor your Cisco wireless controllers and their primary secondary relationships.

Access Point Availability
Monitoring the avialability of your wireless AP’s is easily done with ping. There are hundreds of ping monitors available. This is a simple way to determine if there are possible coverage holes. You can also write a simple script yourself.

Radio Frequency Spectrum Monitoring
In wireless networks, the radio frequency spectrum is the the physical layer component of the wireless LAN. The RF spectrum is a highly variable environment subject to interference for other devices that transmit over the wifi RF spectrum. These devices include, wireless headsets, microwave oven, and rogue wireless routers (usually brought in from home). Because this environment is highly variable, a user can experience excellent performance one day and have poor performance the next.

Using heat maps in the WCS is a good way to to obtain a general status of the RF environment. However this is a predictive view. It is not an actual measurment of the RF transmit power. Viewing the status of an AP on a wireless controller will give you the status of the AP’s signal-to-noise ratio measurments. It will also give you the APs received signal strength indicator, RSSI.

These methods are good if you have few APs in your network or know there is a specific AP you are concerned with. However, these methods are not that feasible with hundreds of AP’s on an enterprise network.

The WCS does have an alarm for “coverage holes” that attempts to aggregrate all APs RSSI and SNR issues. This is a good option to look for general issues in your RF  environment. In future articles, I will describe a scalable script based method for quickly monitoring thousands of individual APs RSSI and SNR scores. Using both a the WCS coverage hole alarms combined with the RF monitoring scripts, will provide you with an excellent starting point for detecting areas of poor wireless coverage.

As you can see there is alot of critical components and systems to monitor in a wireless network. It is important to attempt to monitor all of the components and systems outlined in this article. Neglecting any of these can lead to network outages.

In future articles, I will describe how to:

• Create Radius transaction monitors to monitor your wireless infrastructure.
• Create reports to monitor AP -to-Controller primary / secondary relationship reports.
• Create reports to monitor thousands of AP Signal-to-Noise Ratio and Received Signal Strength Indicator alarms.
• Create reports that provide a large contextual overview of the wireless network from the prespective of any particulary Access Point.

Thanks for taking the time to read this article. If you have any feedback about this or any of the other articles on eNetworkadmin.net please send feedback to info@eNetworkadmin.net.

CLICK HERE FOR MORE DETAILS on how to utilize Ciscocmd to monitor you entire network at a glance and keep your finger on the pulse of your global communications infrastructure.

SUBSCRIBE HERE for to receive useful updates and tips for Network Administration and Automation.