We have two school sites on the same WAN, but managed seperately by WLC 4404 Contollers, ver. 184.108.40.206 software. APs are 1232 and 1252 with the majority being 1252. One site has 98 APs the other 78.
After a period of time, some clients will associate, get the correct IP address range, but are not able to get to certain network resources. Sometimes it is the local SAN, the intranet website, or local application servers. They usually can get to the internet, and most web sites. They always see the local domain controller, and Exchange Server.
Usually, a reboot of the controller fixes it. Periodic reboots have not prevented the situation from happening. The loss of client service is not tied to any specific AP. Some clients on an AP will work fine, but one sitting next to them on the same AP has limited service.
Has anyone else experienced this? How are you dealing with it?
It sounds like you are having a routing or ACL problem dealing with your vlans. Make sure that all clients are getting the IP addresses you are expecting and that all vlans, routes, and acls are properly applied to the the dynamic interfaces. Make sure the WLAN you are using is then applied to the right interface. Finally, make sure that all necessary trunking is enabled.
All the above steps have been taken and verified by TAC. Clients are receiving correct IP addresses, and able to get to some resources.
Is multicast an issue? I would check all my ACLs again too just to make sure. What about active directory permissions and policies?
So the wlc's are not backup for the other... correct. The WLC are on it's own mobility and rf group? If your configuration is correct, then like Dennis mentioned, it sure sounds like a routing issue or filter. Post your show run-config fro both wlc's so we can see if the wlc is setup right.
This has always felt like a routing issue. However, on the last incident, we sent packet traces on the wireless side and on the switch side of the WLC, and it was determined that packets were not making it through the WLC. We have been told there is a bug issue and Cisco is working on it.
Are we the only ones experiencing this bug in the field?
For fun, I am attaching the controler configs.
Have you traced the traffic actually going into the sfp port on the 4400? If so, I have seen bad gbics giving similar issues before. I would check that and the patch cable. Either fiber or copper. If the gbic is bad you would see similar issues and I would about bet you that TAC didn't suggest you switch them out. They assume all is well on the hardware side.
I am having a very similar issue with a client of mine who is on the same exact hardware and code version. The only difference is, the wireless clients get an IP address but are unable to access ANY network resources. The only caveat is I am not sure to what extent the client has tested getting to different network resources.
I am figuring that we will be opening a TAC case up. You mentioned you had or have one opened already. Could you pass it along? I can refer our TAC rep to it for background when we open up our case. If we are able to find the cause, I'll be sure to post a message to this thread.
If you end up getting any info out of TAC I'd be interested to know. Having on and off issues like this at a recently deployed site. Client associates, sometimes gets a DHCP, and when they do, they sometimes can't access network resources. Running the latest release code on a 4402 and with 1252 AP's.
If you are having problems on the 1252s. And in your case it sounds more 1252 related than anything else. Call TAC and ask for 220.127.116.11 This is a special version of code that resolves several 1252 traffic issues and bugs. It is NOT available on the website. You must have it published for you by a TAC engineer. I would be interested in finding out if this coorects your issue.
Tha TAC SR# is 609411479. The request is on hold, waiting for us to capture more traffic information. Have not had an incident for two weeks now, so no data colleted.
You symptons do look the same as some of our clients.
We ended getting an RMA on this controller. The replacement unit should go into production today or tomorrow. If anything interesting pops up, I'll be sure to post it here.