Thank you very much for your interest in the Cisco #WirelessTuesday podcast! This article is a quick recap of the January 2018 live recording event with the associated questions and panel responses.
I would like to make a public thanks Javier Contreras and Salil Prabhu, escalation engineers here at Cisco! They walked us through how to pick the best firmware versions, top TAC issues they are called to address, troubleshooting tools, and how testing is being changed to better reflect real-world conditions.
Recommended Firmware Releases
- For most deployments 18.104.22.168 (also known as 8.0 MR5)
- For deployments requiring new featrues or hardware released after 8.0, use 22.214.171.124 (also known as 8.2 MR7 interim) or 126.96.36.199
- DNA/Assurance features to be released by the end of January, 188.8.131.52 (also known as 8.5 MR2)
Check here for Cisco TAC recommended code releases (this doc is updated often).
Useful Troubleshooting Tools
Wireless Sniffer using Linksys USB600N with Omnipeek
- Wireless Sniffing using a Mac with OS X 10.6 and above
- Wireless Sniffing in Windows 7 with Netmon 3.4
Wired Packet Capture using Wireshark monitoring spanned switch ports of AP, WLC, or client side data.
Questions & Responses
Q1. CSCve39811 8540 WLC running 184.108.40.206 drops OEAP602 APs after upgrade from 220.127.116.11.
R1. Please request escalation or speak to the TAC Duty Manager.
Q2. Does this CSCvg37751 only apply during failover? I’ve had similar happen at sites running AireOS APs during normal operation. APs are behind a Meraki MX 65 or MX100.
R2. No, this bug appears to apply to AP’s connected to Meraki cloud managed switches/firewalls during the connection process to the WLC.
Q3. What did you use to see the data retries when you saw the delay? Did you see this on the AP, controller or sniffing traffic?
R3. A script ran that forces the WAN flap and AP’s to join and drop in a loop then they monitored the number of DTLS session (data & control) to see stale entries and mismatches