WLC 6.0.182.0

[Darren Ramsey]

Anyone running 6.0 and/or ClientLink? Let's hear some feedback...

[gluker7388]

thank you!

[sullyjman]

Im havin a problem where all my remote access points are showing up as offline. They dont even show up in the controller as connected. However the access points on the same subnet as the controller connected just fine.

So right now I have about 70 access points showing up as offline and only 5 connecting lol!

[sullyjman]

apparently this seems to be a gateway issue on the controller? I can ping the management address on the local network just fine, however I cant not ping it from the remote networks (and yes routing is working fine) However something very interesting, if I go into the management interface and just press apply the I get a few ping request from the ip but then it times out again. If i go into the access points section I see a few of the remote access points have joined and started to download the new IOS. However they disassociate again. Anyone else having this problem with 6.0.182.0?

[Leo Laohoo]

I think I get what you are saying. Just yesterday, I was preparing for impending conversion of a significant amount of APs to LAP. So I was playing with a number of AP 1240. All the AP's booted on the RCV image, joined the WLC (almost immediately) to download the LWAP image. After the reboot, the LAPs take about 5-10 minutes before it would join the WLC. After I configured static IP Address (using the GUI) the LAPs would un-join the WLC and take another 5-10 minutes looking for the WLC. During this stage, the LAPs now with static IP Address, couldn't find the WLC. The LAP would suddenly get DHCP IP Address, join the WLC and revert back the static IP Address assigned.

VERY WEIRD!

[sullyjman]

The best way to describe is thinking about pc with a static ip address without a gateway address. Locally everything works fine, however try to go outside the network and it has no idea how too. That is what im experiencing. I rebooted the WLC again this morning while pinging the address from a remote site. I got one ping reply then it timed again. I forward this onto cisco with a picture of the pings, I haven't gotten a response all day. Talking to those on site, the wireless is working fine. But I still have many wireless access points that cant connect to the controller at all unless I go into the management interface, press apply and wait. Some will join then leave the controller. Its very odd

[Darren Ramsey]

Is your management interface's GW a virtual address like HSRP or GLBP? Are you running a single GigE connection or LAG?

[sullyjman]

The gateway that is on the cores which the controller is plugged into is running HSRP. We are running LAG on two of the four interfaces.

[Leo Laohoo]

Have to tried to "enable" the AP's using the GUI?

[sullyjman]

What do you mean enable? The remote aps never connect to the controller after the software upgrade

[sullyjman]

Ive open a TAC case with Cisco, the more I look at this, the more I think its a software issue! The lady at Cisco was telling me I needed the Option43 on my remote DHCP servers. This has been working fine without it since 4.x, plus none of the remote sites can ping the controller so even if their was an option43 in the DHCP the controller would never respond! Its difficult to explain that when both parties have a hard time understanding each other on the phone.

[Darren Ramsey]

sullyjman,

Sounds like TAC is wasting your time. If you can't ping the management address from a routed subnet, then opt43 is irrelevant. Could be some type of GW issue or LAG hash issue. Why don't you try pointing the manage GW to a physical address on one of your cores. Also try disabling each gig port independently and see what happens. There are HSRP bugs from time to time and LAG requires src-dst-ip load-balance. Also you might try "debug ip icmp" on your cores and see if that shows anything.

[sullyjman]

Thanks for the suggestions! I will be doing some testing today and see what I can come up with

[david.kelsen]

Anyone else having trouble with MAC Filtering on some WLANs since upgrading to 6.0.182.0?

I've found that our WLANs that had MAC Filtering applied to WLANs running WPA2/AES/PSK can no longer associate.

This is also true for another WLAN running WPA1/AES/PSK.

The common thread I see here is AES.. is this a known problem with the new release?

I should make it very clear that these WLANs have been running in this state without issue prior to upgrading the WLC to v6.

[sullyjman]

Im sorry I didnt update, I got it working. Two issues occurred

1. with this update, they remove the lwapp name and changed it to capwap. I had to change my DNS entry for the controller, TAC was asking me to run the old lwapp debug commands.

2. We had two of the 4 gigabit in a etherchannel, i randomly just added a third port into the etherchannel and i started getting ping responses from the controller at the remote sites. I havent taken the time to unplug to the first two ports to see if it still works. What all my remote sites are now back online!

[ericwoodin]

I just upgraded to 6.0.182.0 last weekend. I had a little trouble with the static service IP not showing up. I eventually rebooted a couple more times and they came back up. I've enabled Clientlink on all the 1142 APs and they seem to be working fine with our a/g/n radios. We are getting better SNR values on clients and seeing better throughput as well.