Meraki

AidanKamp

Sorry for the delayed reply, @Diz_William This issue would not be related in any way to unexpected reboots - if the AP unexpectedly upgraded, it would instead show 'Firmware upgrade' on the connectivity bar. I believe it would be best to continue working with our support team if you are encountering an issue like this. I hope this is helpful.

AidanKamp

Thanks for checking in @JimBean112 - I've put a response in the main thread above! The TLDR for you; there shouldn't be anything complicated for you to consider. Your APs would fall under scenario 1 as long as they are brought online and stay online. You'll then see them upgrade their firmware between 0-2 hours after coming online. If you do end up having any issues, or want any help - feel free to give support a call!

AidanKamp

Thank you everyone for your patience. Our team has put in place an intermediary workaround - this is to ensure that APs do not reboot en-masse outside of expected hours, causing business disruption. The details of the workaround are as follows: 1. If an AP has an uptime of <2 hours (e.g. recently rebooted or coming online for the first time) and is stalled in this upgrade pending state, it will complete its upgrade 0-2 hours after coming online. 2. If an AP has an upgrade scheduled from here on, the device will upgrade 0-2 hours from the scheduled upgrade time. 3. Otherwise, if an AP does not fall into the above categories (e.g. it first came online after more than 2 hours uptime) it will upgrade 1-2 hours after the network's next scheduled maintenance window. You can read more about how to configure the maintenance window here. We appreciate your patience whilst we work through this issue with care. We will be able to advise once we've fully resolved the issue soon.

AidanKamp

Hello Meraki Community, We're aware of a developing issue affecting CW9172I and CW9172H wireless access points, which are currently unable to upgrade or downgrade to any version of the MR 31 firmware train due to how images are downloaded from the backend. This issue has no other production impact, nor does it affect the access point's ability to serve clients. This includes all minor and patch versions. Upgrades to MR 32 are currently unaffected. This issue began at approximately 02:30 UTC on 9/30 and devices that upgraded before this time are unaffected. This issue also affects devices that are new out of the box and added to a network configured for any version of MR31. In these cases, the devices will not upgrade to the configured version and will continue running the factory default version. Devices that are already running the correct version of MR 31 are unaffected, and you should not observe any sudden issues in these cases. We are treating this as a high-severity problem and are working on a solution that will cause little to no disruption, as quickly as possible. In the meantime, please reach out to our support team if you need assistance with any problems resulting from this issue: https://meraki.cisco.com/meraki-support/overview/ We appreciate your patience while we work through this problem. Please stay tuned for further updates

AidanKamp · ‎Mar 11 2025

Adding to the 'doesn't happen to me' train 😅 I'm not seeing this issue on Android 16/Baklava either - app version 4.141.0, build 195147. No beta or anything running. I can quit out of the app, wait a few mins and re-enter the app without having to log in. Were you perhaps added to a new organisation recently with a very low idle timeout or something similar?

AidanKamp · ‎Mar 9 2025

Thank you, everyone and @AmyReyes! Happy to help, and learn from everyone else in the process!

AidanKamp · ‎Mar 6 2025

Or the other, perhaps more simple way is to create L3 Firewall Rules that block access from your Guest SSID VLAN to RFC1918 destinations. I personally like the Group Policy method a bit better as it separates that VLAN's rules into a different window, but both methods work fine.

AidanKamp · ‎Mar 6 2025

Yes - you can: 1. Set up a Group Policy per your needs for that Guest SSID. It sounds like you'd need outbound firewall rules that prevent access to RFC1918 ranges, which should do the job. 2. Assign the Guest SSID to a Guest VLAN, if one isn't already created 3. Assign the Group Policy to that VLAN That should do the job!

AidanKamp · ‎Mar 6 2025

If using port forwarding, yes - I would ensure you restrict the 'Allowed remote IPs' to the IP addresses of you and your team that will be accessing it. This limits ability for malicious actors to brute force the SSH login of your devices from anywhere in the world.

AidanKamp · ‎Mar 4 2025

If using port forwarding, the only way you can affect this is by only allowing certain IP addresses. The Aruba Switch likely has systems for authentication/authorisation (e.g. local users, RADIUS etc.) and it would need to be implemented there. If you were accessing the Switch via VPN through the MX instead, you could use group policies to lock down SSH access via user. Port forwarding does not have any sort of functionality for user based policy.

AidanKamp · ‎Mar 4 2025

No problem with 1:1 NAT as long as it works for what you have resource for. Could you clarify your ask about a particular user and what your goal is?

AidanKamp · ‎Mar 3 2025

Port forwarding should work fine then in that case. The public port can be anything you choose (as long as you change your SSH command to use that port), and the local port will need to match the port used by the Aruba switch (likely TCP22): If this is still not working, you can perform a packet capture on the internet interface to make sure the MX is seeing the incoming TCP traffic from your host. If that is seen, a packet capture on the LAN interface will help you check if the MX is forwarding that traffic internally. If you're still having trouble, give support a call and we'll be happy to help! https://meraki.cisco.com/meraki-support/overview/

AidanKamp · ‎Mar 3 2025

If I can propose a different solution that might be more secure for your needs; Does your MX95 have Client VPN or AnyConnect enabled? It might be better to VPN to this MX instead, and as long as your firewall rules and VPN routing configuration allows for it, you can then SSH directly to the switch instead of needing a port forwarding rule.

AidanKamp · ‎Mar 3 2025

Thanks Raphael - my bad for missing that screenshot in the index. It seems this endpoint is missing the keys nested inside eventData in the index as you've pointed out. Unsure if this is purposeful but I'll pass it on. If I check a different endpoint as an example, e.g. getNetworkApplianceConnectivityMonitoringDestinations, the nested keys inside 'destinations' show in the response parameters: Thanks for pointing that out.

AidanKamp · ‎Mar 3 2025

Where was this screenshot taken, @RaphaelL? The bottom of this link has an example body that the API will return, as well as a schema: https://developer.cisco.com/meraki/api-v1/get-network-wireless-client-connectivity-events/

AidanKamp · ‎Mar 3 2025

Perhaps this endpoint? https://developer.cisco.com/meraki/api-v1/get-network-wireless-client-connectivity-events/ I checked out an earlier roam in the UI: This has a corresponding 'connection' type event with roam details, serial and MACs omitted: { "deviceSerial": "Q2XX-XXXX-XXXX", "band": "5", "ssidNumber": 4, "type": "connection", "subtype": "success", "occurredAt": "2025-03-03T20:13:38.345999Z", "severity": "good", "durationMs": 60, "channel": 48, "rssi": 36, "eventData": { "state": "11", "connAttempts": "3", "totalConnTime": "0.590", "reassoc": "1", "roamAp": "xx:xx:xx:xx:xx:xx", "roamApMac": "xx:xx:xx:xx:xx:xx" }, "captureId": null } roamAP corresponds with the BSSID of the source AP, roamApMac corresponds with the device MAC of the source AP, and deviceSerial corresponds to the target AP I roamed to.

AidanKamp · ‎Mar 3 2025

Providing you used the 'rollback' button on a single network as below, you're correct in that this should have only rolled back that single network in the batch: As for it displaying the fact that this is rolling back all networks in that batch, this is unfortunately a known UI-only issue on our side 😟. The dialog will state that all networks are rolling back, but the action will only roll back the selected network. Hopefully helpful!

AidanKamp · ‎Mar 3 2025

@RWelch would you be happy to privately message me your case number and I can take a look? There was a mild amount of clean up that this incident required, but this should have been completed before your comment time. If the issue is reproducible, I'd be very interested in taking a look.

AidanKamp · ‎Mar 2 2025

Thanks for your patience! Our team has confirmed that this issue should now be mitigated - if any further issues are seen please reach out to Meraki Support and we'll be happy to help. 💚 https://meraki.cisco.com/meraki-support/overview/

AidanKamp · ‎Mar 2 2025

And to elaborate, the MAC flapping will likely be unrelated. As already mentioned, devices roaming between APs can generate MAC flap events as they roam. As long as your network is continuing to function, there should be no reason to worry about your internal network. The issues seen with our shards will affect dashboard page load times, from our perspective. This might result in some data being unavailable (e.g. clients seen as offline, when they aren't) or some pages failing to load after 30 or 60 seconds.

AidanKamp · ‎Mar 2 2025

Thanks for bringing this to our attention, @Wade_Carroll. I can confirm that we are noticing issues on our side with some shards - as @RWelch has noted, your shard will be the nX.meraki.com portion of the URL in your browser address bar. This is currently being worked on as a high-severity issue by our engineering team. I'll check in once again once I have further updates. Thank you for your patience in the meantime.

Meraki

Community

About AidanKamp

AidanKamp

Aidan van Kampen

Community Record

Badges

Re: Issue Affecting CW9172I and CW9172H Access Point Upgrades to MR 31 Vers...

Re: Issue Affecting CW9172I and CW9172H Access Point Upgrades to MR 31 Vers...

Re: Issue Affecting CW9172I and CW9172H Access Point Upgrades to MR 31 Vers...

Issue Affecting CW9172I and CW9172H Access Point Upgrades to MR 31 Versions

Re: Horrible App authentication experience

Re: Recognizing the February 2025 Members of the Month

Re: Anyway to set firewall rules for specific SSIDs?

Re: Anyway to set firewall rules for specific SSIDs?

Re: SSH Access Via Meraki MX to Aruba switch

Re: SSH Access Via Meraki MX to Aruba switch

Re: SSH Access Via Meraki MX to Aruba switch

Re: SSH Access Via Meraki MX to Aruba switch

Re: SSH Access Via Meraki MX to Aruba switch

Re: API for Client Roaming Event Logs

Re: API for Client Roaming Event Logs

Re: API for Client Roaming Event Logs

Re: Rolling back firmware individually

Re: Multiple issues - offline clients, unresponsive dashboard, spanning tre...

Re: Multiple issues - offline clients, unresponsive dashboard, spanning tre...

Re: Multiple issues - offline clients, unresponsive dashboard, spanning tre...

Re: Multiple issues - offline clients, unresponsive dashboard, spanning tre...

Re: SSH Access Via Meraki MX to Aruba switch

Re: API for Client Roaming Event Logs

Re: Rolling back firmware individually

Re: Multiple issues - offline clients, unresponsive dashboard, spanning tre...

Issue Affecting CW9172I and CW9172H Access Point Upgrades to MR 31 Versions

Re: Anyway to set firewall rules for specific SSIDs?

Re: Anyway to set firewall rules for specific SSIDs?

Re: Rolling back firmware individually

Re: SSH Access Via Meraki MX to Aruba switch