Audit Mismatch on WCS for WLC Deployments

One of the items that comes up from time to time is the configuration of the Wireless Control System (WCS) and the Wireless LAN Controller's (WLC). WCS handles the synchronization of configurations and as they  become out of sync it will highlight a "mismatch" has occurred. 

For example, a change is made on the WLC for a new AP just installed. You want to change the grouping or SSID but, WCS does not know of this change it will think that there is a mismatched configuration for the system when in reality there isn't a mismatch the change made on the WLC was intentional so we have to update WCS with the most current configurations.


WCS Mismatch :
1. Login to WCS
2. Go to Monitor Tab
3. Go to Controllers




From above now we see that there is a configuration "mismatch" from WCS to WLC. The next step is to find out what kind of configuration mismatch is it. Is it just an AP ? Is it NTP? Is it......?
1. Go to 'Configure' tab
2. Click Controllers
3. Check a WLC you would like to have checked for the audit
4. Top right corner under 'Select a Command', select 'Audit Now'
5. Click Go

After you select go the configuration will do an audit for that specific WLC and give you what is exactly the discrepancies between the systems. 

Audit Result:

The audit result shows the specific AP associated with that WLC has a different grouping from the WCS value. 

Most of the time you want to re-sync the configuration from the WLC with WCS. There are rare cases where this may not be the correct path. Its best to understand your environment and the error that comes up in the configuration audit. 

For this error we are going to do a resync with WCS.

1. Go to 'Configure Tab'
2. Select the same previous controller the audit was done on
3. Top right corner select ' Refresh Config from Controller' drop down menu
4. Click GO



After clicking "Go"  you should end up on a final screen that is 'success'. After this go back to:
Configure > Controllers 

You will see that the configuration audit will come back as 'Identical' versus 'Mismatch' of the other Wireless LAN Controllers. 


*** Rule of thumb is to have the WCS on the same revision or higher than the WLC(s)

Comments

Post a Comment

Popular posts from this blog

HULC LED PROCESS - 3750 High CPU

Image
If you're looking at a switch and you see the HULC LED Process running high. The HULC LED process does some of the following tasks: 1. Check link status on every port 2. If the switch supports POE, it checks to see if there is a power device 3. Transceiver checks 4. Fan status updates 5. Set LED ports 6. Check on temperature status Overall the HULC LED Process is a monitoring process running. During looking into this I turned off all non-used ports since it checks the link status. Then I made sure the environment was good. Two Cisco Bugs: http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsi78581 http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtn42790
Read more

Cisco Tomcat High CPU Utilization 99 percent

Image
So a client was experience slow web interface usage to their calling node. As well RTMT was shooting off the alert. The alert is for Call Process CPU Node Pegging.  The culprit tomcat! Cisco Tomcat Service -  In enterprise edition this is a web server service. In the business edition (BE Servers) this uses the web server and unity utilizes the service as well. Log in to each call manager node and issue the following command: show process load cpu **OUTPUT** top - 08:55:48 up 340 days, 4:03, 1 user, load average: 4.64, 3.25, 2.98  Tasks: 142 total, 2 running, 140 sleeping, 0 stopped, 0 zombie  Cpu(s): 16.3%us, 3.4%sy, 0.0%ni, 80.1%id, 0.1%wa, 0.0%hi, 0.2%si, 0.0%st  Mem: 4016964k total, 3856400k used, 160564k free, 29904k buffers  Swap: 2064280k total, 1664k used, 2062616k free, 598124k cached  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND  8065 tomcat 25 0 2317m 1.9g 22m S 99.4 50.4 358084:37 tomcat  1 root 15 ...
Read more