Wireless LAN Maintenance and Troubleshooting Part 2
If you an admin of a wireless network, being able to fix problems that arise is equally as important as being able to troubleshoot the problems in the first place.
In part 1 of this series, we went over different troubleshooting techniques, maintenance practices and some common issues that can arise. In the following article, we will now go over some useful wireless network tools that are at your disposal for actually fixing wireless network problems after you identify them.
(Instructional video below provides a walkthrough of the steps contained in this article.)
CLI Debug/Show Commands
The CLI may not be the most appealing interface to interact with, but it certainly is the most powerful. For instance, there are lots of information you can get from debug commands that are simply not available in any of the graphical interfaces.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
You usually have three options when you set out to use a command line interface. They are serial, telnet, and ssh. Regardless which of these three you prefer, there are two sets of CLI commands that you’ll be frequently using. These are the Debug and Show commands.
The relevant show commands include the following:
- show running-config: Displays WLC configuration (see screenshot below)
- show ap summary: Displays access points currently registered with the WLC and is useful for troubleshooting association issues and registration issues.
- show wlan summary: Displays what WLANs are currently configured and what their current status are.
- show client summary: Tells you what client devices are currently associated with an AP, what protocols are in use, and so on.
- show sysinfo: Displays a lot of status information regarding the health of the WLC.
- show tech-support: Returns highly detailed information on multiple configuration and status elements on the WLC.
- show ?: shows all show commands
The relevant Debug commands include the following:
- debug ap <ap-name>: Sends remote commands to a specific AP.
- dot11 enable: Enables WLC messages related to 802.11 operations (all, load-balancing, state, rogue ap’s, probes, etc.)
- capwap: Enables WLC messages related to CAPWAP message exchanges between the AP/WLC.
- aaa: Enables WLC messages related to authentication, etc.
Wireless LAN Controller Tools
Although it’s in the CLI where you can find a greater amount of information, you’ll probably be spending more of your time on the graphical user interface. In the WLC Tools, you can find relevant information in the Tech Support Menu, under the Management tab. In this menu you’ll find system resource information, controller crash logs, core dump, and AP crash log.
For relevant information regarding access points, navigate to the Access Point Menu under the Monitor tab. This menu will show you the AP status and AP statistics.
To get information regarding rogue AP’s, rogue clients, and ad-hoc rogues, go to the Rogue menu under the Monitor tab. In that menu, you can also designate which ones are actually ‘friendly’ access points.
The Client Menu under the Monitor tab, on the other hand, shows client information like the Client MAC address, Associated AP, WLAN SSID, and Status. You can perform drill-downs to get more details.
Wireless Control System Tools
If you want more granularity in terms of monitoring, troubleshooting and wireless network tools, then this is where you should go.
At the top of the WCS pages, you’ll see a tab named Monitor. There, you’ll be able to get WLAN status information, DHCP information, security status information, and AP status and information. It also comes with a Client Menu featuring associated clients, 24-hour history, 2.4/5.0 GHz clients, and a specialized troubleshooting tool.
The WCS Tools has a feature that’s specifically designed for Controller-related issues. It’s called TAC Case Attachment and is located under the Tools tab. Using this feature, you can send, from the controller itself, the name of the WLAN controller, network information, and crash logs, straight to Cisco TAC.
In addition, you can also send attachments to already open cases as well as notes for advising the technical support engineer assigned to the case. You may also view status information from there.
Cisco Technical Assistance Center (TAC)
Before ending this post, we’d like to talk about the global help desk system which Cisco has put in place to handle customer issues, troubleshooting, and problem resolution. It’s known as the Technical Assistance Center or TAC.
This extensive help resource is part of Cisco’s SMARTnet warranty and is available 24x7x365. Its primary sites are in San Jose, CA; Sydney, Australia; Raleigh, NC; and Brussels, Belgium. In this section, you’ll learn how to properly interface with this resource and acquire the information you need in an effective and efficient manner.
Using TAC, you can:
- Make attachments to open cases
- Open new cases. To do this, you would need the right ‘entitlement’. This means, you need to have a valid SMARTnet service contract, which would require serial numbers, contract numbers, etc.
When you open a TAC case, you have to indicate what Cisco calls Severity Levels. There are four (4) of these levels:
- Severity 1 (S1) – This is what you indicate when your network is totally “down” or there is a critical impact to your business operations. When a case is labeled Severity 1, it is expected that both you and Cisco will commit all necessary resources around the clock to resolve the situation.You must note, however, that you should exercise extreme caution before designating a situation as S1. Make sure that an S2 or S3 (which we’ll define later) is really not enough to resolve the situation.
- Severity 2 (S2) – In this severity level, the operation of your network or environment is understood to be severely degraded, or significant aspects of your business operation are negatively affected by inadequate performance of Cisco products. In such cases, you and Cisco will commit fulltime resources during normal business hours to resolve the situation.
- Severity 3 (S3) – Here, it is understood that the operation performance of your network is impaired while most business operations remain functional. In such cases, you and Cisco are expected to commit resources during normal business hours to restore service to satisfactory levels.
- Severity 4 (S4) – This is the least critical of all four severity levels. An S4 indicates that you simply require information or assistance with Cisco product capabilities, installation, or configuration, and that the situation has little or no effect on your business operations.
Actually, you can also open a TAC case by calling the numbers listed below. However, in our experience, we found this method the least helpful.
- Asia Pacific: +61 2 8446 7411
- Australia: 1 800 805 227
- New Zealand: 0800 44 6237
- Europe: +32 2 704 5555
- US/Canada: 1 800 553 2447
Regardless which method of communication you use, make sure you have the following data on hand:
- SMARTnet service contract number,
- Product/chassis serial number,
- Product Model number/HW config,
- Physical location of the product, and
- Severity Level of the issue
It will help significantly if you also have:
- an accurate description of the issue, highlighted by a succinct case title;
- the history of the problem;
- the network topology and a brief explanation as to how it is set up;
- the output from the “show tech” command and all other relevant output, whenever applicable;
- software versions and types of equipment; and
- relevant syslog/tacac logs before the issue occurred.
To work a case actively, send updates and information as requested. Basically, maintain regular communication. Then once the issue is resolved, make it a point to close it.
You can make a positive contribution to the resolution of a case by practicing TAC Case etiquette such as treating the support engineer with courtesy and respect. Yelling will not help them solve your problem faster.
Also, you must realize that TAC is not a substitute for on-site staff. While it offers a certain level of help, you will still need people in your organization who have the technical expertise to do things that need to be done at your end.
Unless there is a clear link between issues, each specific issue should correspond to a separate TAC case. For instance, an issue with a switch and an issue with a WLAN Controller should be assigned to separate cases.
Again, although you have complete control over assigning severity levels, use them with caution. If things aren’t where you expect them to be at a certain point, request to be escalated to the TAC duty manager. Then when a case is finally completed and resolved, don’t forget to pass along compliments to the support engineer’s supervisor. That way, you can establish linkages which can surely come in handy in future situations.
This brings us to the end of our series on Wireless Maintenance and Troubleshooting. In part 1 of this series, we went over basic trouble shooting and maintenance techniques and procedures. In this second and final installment, we discussed a variety of wireless network tools that you can deploy to help solve the issues that you have discovered in your troubleshooting. A wireless network adds a substantial amount of flexibility to your users but it is only useful as long as it is online, hopefully these two articles help you keep your wireless network up and running.