i have a 5500 series WLC connected to a switch through a trunk port with 2 vlans. the connection works fine, but sometimes it loses connectivity. it works again rebooting the wlc.
when the problem presented, i checked the cpd neighbors on switch and it didnt show the wlc, and i checked the cdp neighbors on WLC and this shows the switch in its neighbors list. i also checked the port counters on WLC and the receiver counters keep increasing, but the transmission counters remains in the same value. then i can see that only the TX side on the controller is down, if i restart the WLC the problem disappear temporaly.
someone know if there is a misconfiguration or a wlc bug related to this behavior?
the switch is a Catalyst 3560
the WLC controller code is 22.214.171.124
Are you only using one port of the WLC to connect it to the netowrk or are you using several ports?
If using several ports make sure that they are connected to the same switch and also that the switch has been configured with a portchannel and that the load balancing method being used by the switch is SRC-DST-IP since the switches can do different loadbalancing methods and the WLC can only do SRC-DST-IP.
Using the an unsupported loadbalancing method on the switch could make the WLC lose connection to the switch, wireless clients lose connection, etc.
Check the cables, if using only one port then try to use a different port on the WLC.
If working with a trunk port on the switch make sure that you prune the vlans on the
PS: Since the WLC has code 126.96.36.199 if posible try to upgrade to a 7.0
i'm using only one port to connect to the switch. i've changed the cables several times.
the WLC was changed by RMA, assuming was a hardware failure, but the problem persist with the new one
i'll try to upgrade to a new code...
It is high likely a bug if all other factors are fine (config, cables...etc.).
Do you have LAG enabled on the wlc?
Have you tried cheching with different port on the switch?
Sent from Cisco Technical Support iPad App
Lag is not enabled.
and yes i actually had tried other ports on WLC and on the switch, the strange of the problem is that it get solved temporally if the controller is rebooted, i also think is a bug...
I opened a case on TAC and still waiting for a solution.
Julio, I would get to the controller console at the time - see if that responds, check its cdp and port state, look at the msglogs (change it to verbose) and the traplog.
See if you are able to ping the mgmt GW.
The controller has 2 connected port, one is the management port that is used also for 1 ssid, and the second port (the port with problems) carries 2 vlans more for two 2 ssid. The port 1 always works fine, so i can access to the controller via Web and CLI, the cdp in the wlc shows the switch, but the cpd on the switch doesn't show the wlc, also the RX interface counters on WLC keep increasing after the problem occurs, but the TX are the same value at the point when the port get blocked.
The WLC configuration having 2 ports, one with the vlan used for admin, and the second one used for 2 different vlans could be the cause of the problem??
Julio, these are my suggestions-
- if this is a new issue on this code, it will not be fixed since 6.0 is end of life. So, I would suggest you upgrade the controllre code to 7.0.x.0 and check if the issue persists.
- I am curious to get the interface stats "sh interface <>" on both the controller port and the switchport and see how they corelate
- Next thing to do would be get a sniffer on the switchport (for controller port 2) and ping the vlan GW from the controller and vice versa from the switch to see where the packets are getting lost.
the interface status of the switch after the port get blocked:
and in the conrtoller i cleared the counters after the port get blocked and got this:
i definetly going to upgrade to a newer code...
if i was you i would try to use to interfaces on the WLC, create a etherchannel and just for testing purposes using the three ssis on the same interfaces.
For now, and just for testing i would not use the management port.
I had a problem wiht some APs where CDP neighbors appear sometimes on one side only and sometimes do not apper in both cides while the link is still up.
The problem was disappearing temporarily when rebooting the APs and appears again later.
Eventually we found it is more a cabling problem.
as you mentioned you changed ports on switch and WLC and also used different cables, I don't think it is same issue as mine.
However, I wonder if the problem persists if you enable the LAG on the WLC and use etherchannel on the switch? I'd like to test this situation - if possible - if I was in your shoes.
Hope TAC will give you good answer to this issue so you share it with us to bulid our experience.
Best of luck.
according to Cisco TAC recommendations, i tested a different SFP for the port that present the problem, but this no changed anything, the problem persists.
I would like to try making a etherchannel for the port that presents issues, but im not sure about if i enable LAG, the WLC only can be connected to a single neighbor device, and in the topology it has 2 neighbor devices. One port goes to a 4500 switch, it never present problems, and the second one goes to a 2960 Switch (before we had a 3560 and change it for discard the switch) and this is the port with issues.
i dont' know if there is a way to make a etherchannel between the wlc and the 2960, but keeping the other connection to the 4500 switch??
i will ask to the network admin (because im a consulting service) for leave only one connection to the 4500 switch
You can't split LAG between switches. Both ports of the WLC have to go to the same switch/stack.
Please remember to rate useful posts, and mark questions as answered
I have de same problem, I have a WLC 2106 conected to Switch 3560 through trunk port, after of minutes I lose conectivity,
at reload de WLC this work again. which was your workaroud for this issue?
There was a physical layer probem. The 5508 WLC only has SFP slots and we had GLC-LH-SM modules and multimode fiber without mode conditioners.
after we changed the SFP to GLC-SX-MM, the problem was solved.