The Roaming/Teleworker bug is not listed in the fixes, but is no longer a known issue? Curious if it's actually fixed given how long it's been around.   Important note While Meraki APs have traditionally relied on UDP port 7351 for cloud communication, and TCP ports 80 and 443 for backup communications, with MR 28+ we are beginning the transition to using TCP port 443 as the primary means for cloud connectivity. In order to ensure proper connectivity to the Meraki cloud after this upgrade, please ensure that all “Meraki cloud communication” traffic specified in the "Help" > "Firewall Info" page is allowed through any firewalls or security devices that are deployed upstream of your Meraki APs. These requirements have been updated in November of 2022, so it is important that you review them. (Wi-Fi 6 and Wi-Fi 6E APs) Legacy product notice When configured for this version, MR12, MR16, MR18, MR24, MR26, MR32, MR34, MR62, MR66, and MR72 will run MR 26.8.3 Bug fixes General stability and performance improvements Known issues In high capacity wireless networks APs may experience instability when the “Client Balancing” or "Band Steering" feature are enabled ... View more

Alerts This version's IOS image is based on 17.9.3 CCO. Upgrades to this version will result in a full system reload New features 802.1X Control Direction Adaptive Policy ACL hit counter live tool MAC Allow list on access ports Named VLAN Bug fixes CDP fails to populate all port module data (always present) In rare instances, large configurations would fail to apply LLDP information for the IPv4 management VLAN is incorrect (present since CS 16) MAB authentication may intermittently fail on stacks Storm control configurations can fail to be updated on LACP groups after changes are made (present since CS 16) Traffic analytics is missing categorizing some applications (always present) General known issues DHCP options longer than 180 characters may fail to be configured on the device resulting in the configuration being reverted (always present) DHCP server information is incorrectly reported, such as the subnet mask and "Last Seen" fields (always present) Meraki native switches move LACP ports to an active forwarding state if configured. This can cause loops when connecting to an MS390 or other Catalyst switch unless the bundles are configured on the Catalyst side first. All Meraki native ports are configured in passive LACP mode so that loops do not occur between Meraki native switches (always present) Large changes made via the API for a single device may take 10+ minutes to apply ... View more

It's not appearing available to install yet, but I discovered the release notes paging through firmware versions.   Important note While Meraki APs have traditionally relied on UDP port 7351 for cloud communication, and TCP ports 80 and 443 for backup communications, with MR 28+ we are beginning the transition to using TCP port 443 as the primary means for cloud connectivity. In order to ensure proper connectivity to the Meraki cloud after this upgrade, please ensure that all “Meraki cloud communication” traffic specified in the "Help" > "Firewall Info" page is allowed through any firewalls or security devices that are deployed upstream of your Meraki APs. These requirements have been updated in November of 2022, so it is important that you review them. (Wi-Fi 6 and Wi-Fi 6E APs) Legacy product notice When configured for this version, MR12, MR16, MR18, MR24, MR26, MR32, MR34, MR62, MR66, and MR72 will run MR 26.8.3 Bug fixes General stability and performance improvements Various improvements in DFS behavior for outdoor APs APs may stop forwarding RTP traffic (Wi-Fi 6 APs) Security fixes Qualcomm wireless chipset vulnerabilities CVE-2022-33277, CVE-2022-40512, CVE-2022-33243 - https://docs.qualcomm.com/product/publicresources/securitybulletin/february-2023-bulletin.html (Wi-Fi 6 and Wi-Fi 6E APs) FTM RTT measurement turned on by default (Wi-Fi 6 and Wi-Fi 6E APs) Known issues Sporadic packet loss & instability on Layer 3 roaming & Teleworker VPN SSID's (Wi-Fi 5 Wave 2 and Wi-Fi 6 APs) In high capacity wireless networks APs may experience instability when the “Client Balancing” or "Band Steering" feature are enabled ... View more

Bug fixes Resolved an MX 17.10.4 regression that could result in the WAN 2 port being set as disabled when making changes via the device local status page. Corrected an issue that could result in an unexpected device reboot when FIPS mode was enabled. Fixed an issue that resulted in MX95 and MX105 appliances incorrectly forwarding CDP traffic. Resolved an issue that resulted in MX appliances generating syslog flow messages for internal traffic processing steps. Corrected a rare issue that could result in IBGP instability when two AutoVPN peers established their IBGP session using IPv6. Fixed an issue that could result in AutoVPN IPv6 routes not being preferred over non-Meraki VPN peer IPv6 routes. Resolved a rare issue that could result in device reboots for MX67(C,W) and MX68(W,CW) appliances. Corrected an issue that could result in configuration changes to the Layer 3 firewall rules not taking effect when the MX was configured in passthrough mode and only AnyConnect client VPN was configured. Fixed an issue that resulted in clients not receiving DHCP IP addresses if 1) clients were connected to Z4 appliances, 2) the Z4 was originally configured in NAT mode, 3) the client received an IP address from the Z4 while it was in NAT mode, and 4) the Z4 was reconfigured to operate in passthrough mode. Resolved an issue that resulted in the LED activity lights for LAN ports not functioning correctly on Z3(C) appliances. Corrected an issue that could result in IPv6 traffic received over VPN not being correctly routed to destinations reachable through other types of VPN. For example, AnyConnect client VPN to non-Meraki site-to-site VPN peers. Fixed an issue that could result in the default AnyConnect group policy not being applied consistently, depending on the username’s case/capitalization. Resolved an issue that resulted in routes learned via IBGP being reported as “external” routes on the Route table page in Dashboard. Resolved an issue that could result in traffic being incorrectly dropped when being routed across an IPv6 route learned via EBGP. Legacy products notice When configured for this version, Z1 and MX80 devices will run MX 14.56. When configured for this version, MX400 and MX600 devices will run MX 16.16.9. Known issues After making some configuration changes on MX84 appliances, a brief period of packet loss may occur. This will affect all MX84 appliances on all MX firmware versions Due to an MX 15 regression, the management port on MX84 appliances does not provide access to the local status page MX appliances will now properly validate that DBD packets conform to the appropriate MTU size. If the MX's OSPF peer has an improper MTU configured, it may cause the OSPF adjacency to fail to properly form. The updated behavior properly conforms to RFC. Please ensure these settings are properly configured on any MX's OSPF peers to avoid disruption after upgrading to MX 18.1.X. Other Updated APN mappings for the Orange and EE carriers. Content filtering URL lookups to the Talos backend will no longer follow routes configured for client traffic. These lookups should now always egress a WAN interface. Improved support for reporting when 2.5Gbps and 5Gbps link speeds were in use. Added support for automatic detection of AIF Telecom cellular connections using the “datapro” APN. ... View more

Apparently this is not possible, you have to manually claim by serial?   Is there a timeline on fixing this? Support just said it's being worked on.     ... View more

Interesting new detail on the backend IOS version Alerts This version's IOS image is based on 17.9.3 CCO. Upgrades to this version will result in a full system reload. New features 802.1X Control Direction Adaptive Policy ACL hit counter live tool MAC Allow list on access ports Named VLAN Bug fixes A stack may fully reboot if a stack member crashes (present since CS 15) Cloning a stack member results in configurations for LACP to be missing, requiring the bundles to be reconfigured or the system to be rebooted (present since MS 15.14) IPv6 information is incorrectly presented in CDP/LLDP packets (always present) Modifying storm control can result in the configuration lines not being removed (present since MS 15) Portchannel is going down upon attaching adaptive policy configs and not coming back up after removing adaptive policy configs as well. Ports that are in LACP suspended show as offline instead of errored in dashboard (present since MS 14) RADIUS message NAS IP address is incorrectly 1.1.3.1 (present since CS 15) General known issues "Port Up/Down" events will generate an event log for each stack member DHCP options longer than 180 characters may fail to be configured on the device resulting in the configuration being reverted (always present) DHCP server information is incorrectly reported, such as the subnet mask and "Last Seen" fields (always present) Non-MS390 switches move LACP ports to an active forwarding state if configured. This can cause loops when connecting to an MS390 unless the bundles are configured on the MS390 first. All Non-MS390 ports are configured in passive LACP mode so that loops do not occur between Meraki switches (always present) Rebooting a switch in a stack via the UI will result in the entire stack rebooting (always present) Receiving incorrectly flooded CDP packets may incorrectly report VLAN mismatches and SFP port information (present since MS 12) ... View more

Quick Start Guide  Getting Started  FAQ    tl;dr - Migration is built into latest versions of IOS-XE vs the process that previously existed and there is a dedicated team to help plan/validate that your system will work   Still no public ETAs on other C9X00 models. ... View more

This was just announced at Cisco Live. The details aren't fully online yet but it should be in public beta for SD-WAN Plus customers very soon.   Announcement Blog    I've pulled together some of the Cisco Live Presentations:   The Journey to Hosting Containers on Meraki with ThousandEyes - BRKAPP-2727  - Really Cool Info on internals Making Meraki SD-WAN "ThousandEyes" Aware - PSOAPP-1618  Learn How Meraki and ThousandEyes Together Are Solving Your Application Performance Issues With Simplicity - BRKMER-2007 (The actual preso is not posted yet but URL should work by Thursday morning) I've seen some demos and it's pretty cool.     ... View more

Non C9300 Models Only, see here for detail on this: New separate CS and MS release trains - no more MS390 issues in MS release notes!  They've attacked some very old bugs!   General features ACL hit counter DHCPv6 and IPv6 RA guard Local Status Page Packet Capture Loop detection event log enhancements Ms12x features DAI support General fixes A client's port may fail to reauthenticate after a RADIUS server becomes available due to the port not bouncing (present since MS 11) A trunk port receiving IPv6 ND packets tagged for a VLAN not allowed on the trunk port are not dropped but sent out another trunk port (present since MS 14) IPv6 LLA does not work correctly even when there is no Global Unicast Address assigned (always present) LACP links to MS390s or non-MS devices can take a long time to recover after a stack failure event (always present) Loops can be seen when rebooting a stack member containing a cross-stack LACP port (always present) PIM packets that are processed can incorrectly be placed back onto the wire resulting in duplicate packets (present since MS 14.15) Stack members rebooting while being a part of a cross-stack LACP group will cause the remaining online port(s) to experience an outage for up to 30 seconds. The same behavior is seen again when the switch comes back online (present since MS 10) Traffic floods can result in DNS packets in segmented VLANs to be dropped (always present) Ms210/225/250/35x/425/450 fixes Optimizations were made for devices to prioritize management traffic until a valid uplink is provided Ms4xx fixes In rare instances, switches may remain offline if it receives frequent STP TCn packets (present since MS 15) General known issues Connecting a stacking cable to a stack that is online may result in a stack member going offline (present since MS 12) In rare instances, the port status will fail to update to dashboard until the system reboots (present since MS 14) Switches move LACP ports to an active forwarding state if configured. This can cause loops when connecting to an MS390 or other Catalyst switches unless the bundles are configured on the MS390/Catalyst switches first. All non-catalyst ports are configured in passive LACP mode so that loops do not occur between Meraki switches (always present) Ms120 known issues DHCP relay fails to relay packets (present since MS 15.14) Switches in extremely rare instances will experience reboots every few minutes (present since MS 11) Ms125 known issues The local status page cannot be accessed from the management port (always present) Ms12x known issues Ports with an odd-numbered MTU value fail to initialize (predates MS 11) Switches will never move a RADIUS server's connectivity status to available if it was ever lost resulting in all authentications being placed into the critical auth VLAN (present since MS 14.32) Ms210 known issues Stack ports have an orange LED instead of green (present since MS 11) Ms2xx/35x/4xx known issues Cross-stack LACP groups may fail to fully initialize, resulting in one or more ports staying offline (present since MS 16.1) End devices connected at 100Mbps may fail to re-establish a link after the cable test has been run on the port (present since MS 14) If the same MAC address is associated with multiple IPs, adding or removing an SVI may lead to an incorrect VLAN ID mapping leading to packet loss on one or more SVIs Switch stacks will learn MAC addresses from ports in the STP blocking state which can trigger a constant flood of MAC flaps in the event log Ms355 known issues In rare instances, stack ports fail to initialize after an upgrade (always present) Ms35x known issues Enabling Combined Power results in events being logged once per minute (present since MS 11) UPoE does not negotiate over LLDP correctly (always present) mGig switches will have an amber light for all physical ports that do not negotiate to the highest supported speed. Dashboard will continue showing a light green status for all ports above 100Mbps. For example, MS355 switch ports will incorrectly show an amber light for 1G, 2.5G, and 5G, but will show a green light for 10G. Ms425 known issues Large number of SNMP walks to switches in H.A. may destabilize the VRRP connection resulting in flapping (present since MS 15) Stacks in rare instances will start dropping DHCP traffic on trusted ports while DAI is enabled until rebooted (present since MS 12) Ms4xx known issues When an SFP module is inserted/removed, BPDUs can be delayed leading to STP transitions in the network (predates MS 12) ... View more

If you deploy vMXs you should probably read this: https://documentation.meraki.com/MX/Other_Topics/vMX_NAT_Mode_Use_Cases_and_FAQ   I stumbled upon it checking out the MX new features info. Not sure I like this being the default as it can make troubleshooting more difficult. This is listed as being only in 18.103 and later in the feature guide, but the more detailed article above doesn't make that distinction. ... View more

New features Added support for configuring VPN exclusion rules for non-Meraki VPN peers. Bug fixes Resolved an issue that could result in drops of cellular connectivity when IPv6 was in use with some cellular networks. Added firmware support for LLDP on LAN ports of MX95, MX105, MX250, and MX450 appliances Performance improvements for MX250 and MX450 appliances Corrected an issue that could result in EBGP peering instability when 1) a large number of AutoVPN routes were being advertised via EBGP and 2) the MX appliance had a reduced WAN MTU. Resolved an issue that resulted in IPv6 traffic being dropped when sent over an IPv4 tunnel formed with a non-Meraki VPN peer. Fixed an MX 18.1XX performance regression on MX64(W) and MX65(W) appliances. Corrected an issue that could result in traffic to non-Meraki VPN peers being incorrectly NAT’ed when the peer was configured using an FQDN as opposed to an IP address. Resolved several rare issues for MX67C, MX68CW, and Z3C appliances that could result in the integrated cellular modem being unable to properly initialize after an upgrade from MX 16 was performed. Fixed an MX 18.1XX regression that could result in MX appliances configured in HA or passthrough mode to lose WAN connectivity. Corrected an issue that could result in a device reboot of MX appliances. Corrected an issue that could result in the global IPv6 address being unreachable to some LAN clients when the IP address was obtained via SLAAC on a cellular uplink. Resolved a rare issue that could result in traffic being misclassified by NBAR. Stability improvements for VMX-L appliances deployed in the Umbrella Cloud. Known issues After making some configuration changes on MX84 appliances, a brief period of packet loss may occur. This will affect all MX84 appliances on all MX firmware versions Due to an MX 15 regression, the management port on MX84 appliances does not provide access to the local status page Client traffic will be dropped by MX65(W), MX67(C,W), and MX68(W,CW) appliances if 1) The client is connected to a LAN port with 802.1X authentication enabled and 2) The VLAN ID of the port is configured to 16, 32, 48, 64, 80, 96, 112, 128, 144, 160, 176, 192, 208, 224, or 240. There is an increased risk of encountering device stability and performance issues on all platforms and across all configurations. ... View more