I have a customer that is reporting the above issue from a single site
Wired clients at this site can RDP and SSH
Clients at other sites, supported by the same WLC, can connect via RDP & SSH via WiFi
There are no access lists on the WLC
Is this far more likely to be a LAN/WAN/FW issue
Is there any debug I can run on the WLC that might identify the issue or is this the realm of sniffing the LAN/monitoring the Firewall
the clients cannot start RDP or SSH? is the application installed on these clients?
is the connection refused? then check if the subnet used on this site is allowed at the destination.
if other do basic steps like
- ping default gateway from client
- ping remote gateway from client
- ping ssh/rrdp destination
- traceroute to destination
Interesting development, client has statically assigned himself an IP address in the second half of the /23 subnet and now he can RDP & SSH OK ie a 10.108.157.X address rather than a 10.108.156.X DHCP assigned address
is the AP involved in local mode (date delivered to lan centrally by WLC)?
or flexconnect mode (data delivered by AP to local vlan)?
in second case, then the subnet mask retrieved from the dhcp scope may not be correct, so it cannot reach the central site through the gateway
It turns out the fault description is not entirely accurate
The issue is not just for 10.108.156.xx addresses but affects the whole subnet due to a Cisco bug CSCvb78700 affecting the 4500 core switch
Image 03.09.00.E is vulnerable to the following.....
4500X unable to forward packets when they need to be unknown unicast flooded
Destination device's mac is NOT present on the switch mac table, but the ARP is resolved
There are 3 possible workarounds.
Workaround 1: Set the mac address aging timer to the same as the ARP timer. The default would be 14400 seconds for the arp timer. This forces the CPU to punt the traffic to cpu which uses software to forward the first packet to learn the mac.
Workaround 2: Set static entry for particular MAC address.
Workaround 3: This corrects the actual unicast floodset
Any event which triggers the review,
1) like adding or removing a port from the affected VLAN
2) shut/no shut of the port
3) removing and adding the affected VLAN.
4) System reload.
Further Problem Description:
"show platform software floodset vlan <>" and "show platform hardware floodset vlan <>" will be out of sync for the Unicast floodset.
The software unicast floodset will have all the required ports in specified vlan under it.
The hardware floodset may have no ports mapped or may have some ports missing.