Cisco 3502 AP & Wireless Problems with Cisco 2960-X POE switch
I am having a strange problem with a new Cisco 2960-X switch and my Cisco 3502 AP's....
We have several departments in our office complex. Our typical deployment is 2 Cisco 2960-s POE switches with a LAG back to the core. The Cisco 2960-s switch is where the AP will be plugged in and also the Workstation. We have a Cisco 5508 controller where all of the AP register and we configure the all of the SSID's.
So far everything has worked out great. Clients can connect and move between depratments without losing connection. Recently we changed the model of switch from the 2960-s to the 2960-X thinking this would position us for 10gig upgrade in the future. Since we atarted using the 2960-X i have started to have odd wireless connection problems.
I deployed the the 2960-X like we have done the the 2960-S but we can no longer connect with the SSID's... We can see the SSID's being broadcast and we can even attempt to connect. That as far as we get.... After that nothing... not even an IP address. If I power down the 2960-X and replace with a stack of 2960-S everything runs like normal... Has anyone else had trouble with wireless when using the 2960-X?
I presume the configuration between the 2960S and 2960X are the same? The only thing different from them are the IOS levels. Can you specify what IOS you are running on the 2960S (don't worry about the IOS for 2960X).
What debugs have you picked up?
The 2960-S switches are being deployed with the 12.2 IOS. The configuration is the same. I have had the opportunity to gather one debug so far with the AP connected to a 2960-X. The debug I performed was from the 5508 controller. I debuged the client MAC address. I had the client turn off their wireless and then turn it back on again. The client will send the inform paacket (because they already have a valid DHCP address) but the response from the DHCP server is never received and eventually the connection attempt times out. When the AP is plugged into a 2960-S on the same subnet. The connection is instant. The inform packet goes out and the acknowlegement from the DHCP server is received.
It looks like we have this issue resolved. This was not an issue with the 2960-X switch.
I was performing some double checks on the equipment deployment for this department and also debugging some AP traffic from when the AP was first powered on thru the joining with the WLC. While doing this with the two AP's for this department I noticed a flood of inpersonation log messages showing on the WLC just after the AP joined. The inpersonation target MAC was one of the AP's I was working with but the offending AP MAC was one that I did not have recorded as being deployed.
I performed a quick survey with our wireless survey tools and discovered that an AP was hung in an equipment closet while this space was being built out for the department and not inventoried. I took a deeper look at this AP and while it was showing normal operation the AP was misbehaving. When I searched the WLC for the MAC of this AP it was showing 21 connections but the time was 7:15 pm and the office had been closed for approx 2 hours. I compared the misbehaving AP configuration with one of the other AP's in that area and thats when I discovered the second problem. The 2 AP's that were deployed with the build out for this department were running on image 7.6.100 and the misbehaving AP was running on image 7.0.230... I also verified the WLC was running on 7.6.100. A quick conversation with the other team members revealed that there was an unscheduled maintenance performed where the WLC image was upgraded a few nights before. I defaulted the misbehaving AP using the clear LWAPP private-config and plugged it back in. The AP did go through the download process and properly registered with the WLC. I rehung that AP and walked through the area the next morning. Everyone was able to successfully connect to our SSIDS. The inpersonation errors I was noticing in the WLC log file have also stopped.
We believe at this time that following the image upgrade this AP did not gracefully reboot or download the new image correctly and as a result failed causeing the issue for the other AP's and client connections.
Transferring Crash file from standby: Login to the Active WLC in HA.
From CLI: (Cisco Controller) >transfer upload datatype crash (Cisco
Controller) >transfer upload filename (Cisco
Controller) >transfer upload mode tftp (Cisco Controller) >transfer
This is the start of a display filter cross reference between Wireshark
and OmniPeek. The 1st installment is a table of advanced filters. More
filters will be added as time allows. It is a living doc, so check back
for changes every so often Please feel f...