Meraki

cmr

Totally agree with @KarstenI above. You can run WPA3 on bands other than 6GHz. I would totally avoid transition mode, in my testing it was like sticking needles in your eyes, whereas pure WPA3 has some challenges, but does work and I have run it now for a few months.

cmr

If you look at the other stack members, do they have any events related to the connection to that switch? At the time the switch was down, were the devices connected to it still working?

cmr

@Jobsp to be clear, were you monitoring the switch IP and it dropped at the time the dashboard access was lost? If so, definitely raise a ticket with support ASAP!

cmr

Have any of the devices connected to it shown an issue? As you said, if it did reboot then the uptime should be updated. It might be worth having a ping monitor on it for a few days to correlate with the dashboard connectivity errors. I'd also raise a support ticket as it could indicate something failing in the switch.

cmr

Do the helicopters fly over (or near) the AP? I'd expect that's the DFS traffic.

cmr

Also the C9300-M will only support 1000 VLANs.

cmr

I'd change Nexus first, after the 30s the connection will recover. If you change Catalyst 2 first it can take down at least that part of the network.

cmr

No, it is not conflicting WiFi traffic, it is other signals. The hospital traffic may itself be generating them. Does it have a helicopter pad?

cmr

The switch didn't reboot, it simply lost connectivity to the Meraki cloud. Something between it and the cloud dropped out. What is between the switch and the internet?

cmr

This is quite normal behaviour. The AP has detected radar use in those frequenciew and changed channel to avoid the radar. Are you near an airport, port, military establishment or similar?

cmr

The main points of PVST were to spread the overhead between devices for performance and availability. These days in most networks the equipment is powerful enough to manage the spanning tree for all VLANs, so you should be fine to change it. Remember to change the core first and the other non Meraki switches as quickly as possible. You will get a ~30s outage with at least the first change.

cmr

Personally I would never run RPVST and Meraki together in production. I have done and it was a nightmare if a traditional Cisco switch was either side of the Meraki switches. As @Brash said, it can work if Meraki is only the edge with Cisco at the core, but personally I'd just change the traditional Cisco to MST and rest easy.

cmr

I had LACP configured on the C9300L I upgraded from the first beta to this version and that worked. Edit: reread post above!

cmr · Re: A new candidate wireless firmware is now available on Tue, 18 Feb 2025

As per the main forum post, originally the below was listed as a known issue, so may need validating: Sporadic packet loss & instability on Layer 3 roaming & Teleworker VPN SSID's (Wi-Fi 6, Wi-Fi 6E APs)

cmr · Re: A new candidate wireless firmware is now available on Tue, 18 Feb 2025

Wireless firmware versions MR 31.1.6 changelog Important note Wi-Fi 5 Wave 2 MRs support - This version and subsequent MR 31.x.x are only supported on 802.11ax (Wi-Fi 6) and newer MR models. 802.11ac Wave 2 and older products will only upgrade to the backup version (MR 30.7.1) if they are in networks configured for MR 31.x.x versions, and thus, the new features will not be available. The bug fixes listed below will also not apply to Wi-Fi 5 Wave 2 and older MRs. (https://documentation.meraki.com/MR/Other_Topics/Cisco_Meraki_MR_Firmware_Restrictions_Overview_and_FAQ) Includes support for Wi-Fi7 APs (https://documentation.meraki.com/MR/MR_Overview_and_Specifications/CW9176I_%2F%2F_CW9176D1_Datasheet, https://documentation.meraki.com/MR/MR_Overview_and_Specifications/CW9178_Datasheet) Bug fixes General stability and performance improvements MR56 ethernet port flaps occur when connected to C9300-48UN(V04) at 5Gbps speeds MR57 ethernet port flaps occur when connected to MS355 at 5Gbps speeds MR46 not responding to Probe Requests from clients Channel & power not configurable via LSP on CW9163E APs Wildcard NAS-IPv6-Address AVP sent on config change (Wi-Fi 6, Wi-Fi 6E APs) NAS-IP-Address discarded (Wi-Fi 6, Wi-Fi 6E APs) RADSec authentication failures (Wi-Fi 6, Wi-Fi 6E APs) Sporadic packet loss & instability on Layer 3 roaming & Teleworker VPN SSID's (Wi-Fi 6, Wi-Fi 6E APs) DHCP offer is not forwarded if broadcast flag is set (Wi-Fi 7 APs) mDNS traffic blocked (Wi-Fi 7 APs) SSIDs broadcast on 6Ghz despite being disabled when using WPA3 transition mode (Wi-Fi 7 APs)

cmr

Just sharing the love @Paccers 👍

cmr

Interestingly here is the console from before the upgrade: Switch 1 has been registered Booting in Meraki mode Switch Serial Migr Num PID Number Cloud ID Mac Address Stat -------------------------------------------------------------------------------- 1 C9300L-24UXG-4X FVH0000XXXF Q5XX-XXXX-XXVS c4xx:xxxx:xxxx Regi Starting Meraki app... service meraki connect is enabled. Meraki app is up and connecting to Dashboard ... And after: Switch 1 has been registered Booting in Meraki mode Switch Serial Migration Num PID Number Cloud ID Mac Address Status Mode ----------------------------------------------------------------------------------------------- 1 C9300L-24UXG-4X FVH0000XXXF Q5XX-XXXX-XXVS c4xx:xxxx:xxxx Registered C9K-M Please go to dashboard.meraki.com to manage above device(s). You can locate the device(s) on the Meraki Dashboard using the Cloud ID(s). Starting Meraki app... service meraki connect is enabled. Meraki app is up and connecting to Dashboard ... Local status page is available ... The Meraki mode table is somewhat more informative and the local status page is new...

cmr

I finally upgraded a C9300L to this version and the experience was very good. Scheduled the upgrade from the dashboard and unlike @PhilipDAth it let me go through. 14 minutes later the upgrade started being staged. 2.5 minutes later network traffic stopped traversing the switch as the MCU upgrade started. 30 seconds later the switch rebooted (soft boot, no fans going loud etc.) 3 minutes 18 seconds later the switch entered Meraki mode according to the console 30 seconds later the switch started passing traffic again. In total 4 minutes and 18 seconds of downtime for an upgrade 😎

cmr

What @PhilipDAth said is the answer.

cmr

Yes, I ran this configuration for several years at a site.

cmr

I've been running it for a while on a number of WiFi6 and 6e APs. What models are you having trouble with?

cmr

Thanks @alemabrahao I hadn't seen that before. It looks like they finally added it to the documentation after the issues I had trying to get those options working. I do believe they will be supported in a later IOS-XE native release, but don't have a specific version or timescale.

cmr

@Robthesoundguy, although stacks are supported up to 8 switches, I've experienced issues with larger stacks for many years and always try to keep stacks to a maximum of 4 switches. With CS firmware, the larger the stack, the slower it is to reboot as well. The beta IOS-XE firmware does specifically improve this a lot.

cmr

I had something similar when I changed an SSID from WPA3 to WPA2. A Windows 11 client that remembered it would then try to connect, fail, prompt for the password, connect for 10-15 seconds and fail again. As @Mloraditch said, forgetting the SSID on the Windows 11 device and finding it again fixed the problem.

cmr

I'm guessing you meant MR34s and not MR44s, as the latter are quite new and still fully supported? Moving to WiFi 6 APs will give you the possibility of faster connections, with existing settings though it is an incremental improvement and not a huge change. Going up to WiFi 6e models only makes a further improvement if you can use WPA3 encryption and I'd have to say that client support is patchy and not as stable as WPA2. Without WPA3 you cannot use the new 6GHz band. Even with it, outside of the US it only works for APs with internal antenna that are inside. WiFi 7 adds on to 6e, but retains the same requirement for WPA3.

About cmr

cmr

Community Record

Badges