This is when the firmware moved from stable release candidate to stable ... View more

Security appliance firmware versions MX 18.107.1 changelog Bug fixes Resolved an issue that could result in MX100 appliances becoming unresponsive and unable to be recovered with a factory reset after upgrading to MX 17.10.5 or MX 18.1.07 from very old, unsupported firmware versions that reflect as critically out of date from the Organization > Firmware upgrades page in Dashboard. 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. Due to an MX 17 regression, RADIUS messages that transit across AutoVPN may fail to be routed correctly. There may be an increased risk of encountering device stability and performance issues. ... View more

Wireless firmware versions MR 30.1 changelog 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) WEP deprecation (https://documentation.meraki.com/MR/Encryption_and_Authentication/WEP_Deprecation_on_MRs) 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 New feature RadSec Support on MRs (https://documentation.meraki.com/MR/Encryption_and_Authentication/RADSec_Documentation) VLAN Profiles Support on MRs (https://documentation.meraki.com/General_Administration/Cross-Platform_Content/VLAN_Profiles) HTTP CONNECT Proxy Support on MRs (https://documentation.meraki.com/MR/Deployment_Guides/HTTP_CONNECT_Proxy_Support_on_MR_Access_Points) Enhancement IPv6 Improvements: IPv6 Packet Fragmentation with WPN, Fast roaming support in IPv6-only networks, Distributed L3 roaming for IPv6-only clients (https://documentation.meraki.com/MR/Other_Topics/MR_30.X_Firmware_Release_-_Supported_IPv6_Features) WPA3 + 802.11r Support (https://documentation.meraki.com/MR/Wi-Fi_Basics_and_Best_Practices/WPA3_Encryption_and_Configuration_Guide) MR57 Uplink High Availability (https://documentation.meraki.com/MR/MR_Overview_and_Specifications/MR57_High_Availability) 6GHz Site Survey Support via the local status page (https://documentation.meraki.com/MR/Wi-Fi_Basics_and_Best_Practices/Conducting_Site_Surveys_with_MR_Access_Points) UNII-3 Support in the EU Alternate Management Interface interface ping response Bug fixes General stability and performance improvements DNS resolution over IPv6 Invalid PMKID when client roams using WPA3-SAE AP may change the gateway's MAC address when it receives a spoofed unicast ARP request AP may not send or respond to UDP tests from a Secondary MX Concentrator Known issues Sporadic packet loss & instability on Layer 3 roaming & Teleworker VPN SSID's (Wi-Fi 5 Wave 2 and Wi-Fi 6 APs) ... View more

Wireless firmware versions MR 29.6 changelog 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 Ethernet PHY optimizations (MR30H) AP may stop sending MQTT updates AP may send client balancing updates when disabled AP may stop beaconing 5GHz BSSID after multiple DFS events (Wi-Fi 6 and Wi-Fi 6E APs) AP may continue to send traffic to a client after it has roamed to a new AP AP may reply to every LLDP packet from a PSE AP may not broadcast setup SSIDs on factory firmware (Wi-Fi 6 and Wi-Fi 6E APs) AP may reboot when the “Client Balancing” feature is enabled (Wi-Fi 6 and Wi-Fi 6E APs) Numerous fixes to address MT connectivity at scale (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) ... View more

This is just the firmware being upgraded to the stable release channel ... View more

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. Due to an MX 17 regression, RADIUS messages that transit across AutoVPN may fail to be routed correctly. There may be an increased risk of encountering device stability and performance issues. OTHER Due to its limited value as a troubleshooting tool, the speed testing tool has been removed from the local status page. Made the content filtering system more aware of system state issues (such as system time not having been set through NTP yet) that would cause content filtering lookup requests to fail. This may make web traffic more responsive in certain edge-case situations. Secure Group Tags (SGT) will now be supported on Z3(C), MX64(W), MX65(W), MX67(C,W), MX68(W,CW), MX75, MX85, MX95, MX100, MX250, and MX450 appliances. ... View more

Camera firmware versions MV 5.3 changelog New Improved Image Quality for MV63(x)/MV93(x) Smartcodec Support for MV2/MV52 Advanced Presence Sensing Support for MV63(x)/MV93(x) Bug fixes Resolved an issue where MV72(x) could go offline after upgrading to MV5.1/5.2 Resolved an issue where MV63(x)/MV93(x) LED turns off during camera initialization Resolved an issue where MV63(x) low-resolution stream could become corrupted Resolved an issue where MV63(x)/MV93(x) can experience fps fluctuations ... View more

Switch firmware versions MS 15.21.1 changelog Alerts HTTP proxy is no longer supported on MS 15+. Nodes that use HTTP proxy without any other means to connect to dashboard may fail to connect. While Meraki switches have traditionally relied on UDP port 7351 for cloud communication and TCP ports 80 and 443 for backup communications, with MS 15.1+ we are beginning a 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 filtering devices that may be deployed upstream of your Meraki switches. These requirements have been updated on Nov 2022, so it’s important that you review them. Ms390 alerts Switches can only downgrade to MS 12 with an incremental step to MS 14 Upgrades from MS 15.20 or later will result in minimal impact to client traffic Ms390 features Additional client analytics added Alternate Management Interface (AMI) support Critical/failed authentication support Group policy ACL support IPv6 static routing support MAC flap detection support Meraki authentication support Multi-auth with voice VLAN bypass support Netflow and Encrypted Traffic Analytics (ETA) support STP anomaly detection Stack power is supported by default UDLD support UPoE (802.3bt) support URL redirect support New features IPv6 management interface support Bug fixes Meraki Go switches fail to provide PoE to connected Powered Devices (present since MS 15.20) Note: this does not apply to MS model switches, and only applies to Meraki Go (GS model) 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) 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) Known issues In rare instances, the port status will fail to update to dashboard until the system reboots (present since MS 14) Ms120 known issues In rare instances, switches may return empty packet captures until they are rebooted 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) Ms2xx/35x/4xx known issues Cross-stack LACP bundles experiencing a switch reboot will cause the remaining online port to experience an outage for up to 30 seconds. The same is seen again when the switch comes back online (present since MS 10) 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 Loops can be seen when rebooting a stack member containing a cross-stack lag port (always present) 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. Ms390 known issues "Port Up/Down" events will generate an event log for each stack member Adding additional ports to a port bundle will cause the entire bundle to be reconfigured causing traffic loss (always present) 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) DHCP options longer than 180 characters may fail to be configured on the device resulting in the configuration being reverted (always present) IGMP snooping enabled will send an IGMP message on every configured VLAN every 125 seconds (always present) If a link aggregate has an adaptive policy group added or removed, the link aggregate ports will be disabled and stay disabled Large stacks may experience intermittent management plane loss resulting in config fetch delays (always present) Loop detection is not supported 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) Warm spare/VRRP is not supported Ms425 known issues 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

Switch firmware versions MS 15.21 changelog Alerts HTTP proxy is no longer supported on MS 15+. Nodes that use HTTP proxy without any other means to connect to dashboard may fail to connect. While Meraki switches have traditionally relied on UDP port 7351 for cloud communication and TCP ports 80 and 443 for backup communications, with MS 15.1+ we are beginning a 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 filtering devices that may be deployed upstream of your Meraki switches. These requirements have been updated on Nov 2022, so it’s important that you review them. Ms390 alerts Switches can only downgrade to MS 12 with an incremental step to MS 14 Upgrades from MS 15.20 or later will result in minimal impact to client traffic Ms390 features Additional client analytics added Alternate Management Interface (AMI) support Critical/failed authentication support Group policy ACL support IPv6 static routing support MAC flap detection support Meraki authentication support Multi-auth with voice VLAN bypass support Netflow and Encrypted Traffic Analytics (ETA) support STP anomaly detection Stack power is supported by default UDLD support UPoE (802.3bt) support URL redirect support New features IPv6 management interface support Ms220/320 fixes PoE telemetry data is not sent to dashboard (present since MS 15.20) Ms320 fixes In rare instances, PoE may fail to be supplied to end devices (present since MS 15.20) Ms390 fixes Configurations from dashboard do not overwrite changes made from the local status page Configuring an empty custom ACL in an adaptive policy group will result in the entire adaptive policy config failing to be configured Enabling and disabling storm control can cause ports to stay disabled Packet captures may stop working after a reboot (present since MS 15) Stacks may fail to complete an upgrade past MS 15.15 and will revert back to the starting version. If this happens, splitting the stack and upgrading individually is required (present since MS 15.15) Switches are unable to directly upgrade from MS 12 to MS 15.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) 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) Ms120 known issues In rare instances, switches may return empty packet captures until they are rebooted 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) Ms2xx/35x/4xx known issues Cross-stack LACP bundles experiencing a switch reboot will cause the remaining online port to experience an outage for up to 30 seconds. The same is seen again when the switch comes back online (present since MS 10) 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 Loops can be seen when rebooting a stack member containing a cross-stack lag port (always present) 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. Ms390 known issues "Port Up/Down" events will generate an event log for each stack member Adding additional ports to a port bundle will cause the entire bundle to be reconfigured causing traffic loss (always present) 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) DHCP options longer than 180 characters may fail to be configured on the device resulting in the configuration being reverted (always present) IGMP snooping enabled will send an IGMP message on every configured VLAN every 125 seconds (always present) If a link aggregate has an adaptive policy group added or removed, the link aggregate ports will be disabled and stay disabled Large stacks may experience intermittent management plane loss resulting in config fetch delays (always present) Loop detection is not supported 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) Warm spare/VRRP is not supported Ms425 known issues 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

Cellular gateway firmware versions MG 3.100 changelog Important notice While Meraki appliances have traditionally relied on UDP port 7351 for cloud communication and TCP ports 80 and 443 for backup communications, with MG 3.0 we are beginning a 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 filtering devices that may be deployed upstream of your Meraki appliances. These requirements have been updated on Nov 2022, so it’s important that you review them. New feature highlights IPv6 support for MG21/41 IP Passthrough support for MG41 Bug fixes Improved NAT mode throughput for MG41 Improved cellular modem management and SIM detection Corrected issue where some MGs may show the wrong connection type Known issues This build is currently only expected to run on MG21/41 There is an increased risk of encountering device stability and performance issues on all platforms and across all configurations for firmware set as beta ... View more

This is 3.00 moving from beta to stable release candidate, but bizarrely the release notes are now as below:   Other MG 3.0: First beta image! 🎉 Cellular WAN Connectivity NAT and Passthrough modes supported IPv6 Support (Firmware only) Dual SIM Support - SIM slot selection via dashboard/LSP Auto SIM failover - if SIM1 is not present, auto switch to SIM2 ZTP via auto APN detection and multi-APN retry Custom APN setting via dashboard/LSP Safemode for troubleshooting Known Issues DHCP section is not disabled in passthrough mode Licensing is not enforced properly on Dashboard. Device shows up as a "wireless AP" on the licensing page Enabling/disabling SIM PIN/PUK currently unavailable Limitation If SIM1 is configured as Primary, Dashboard will not show the details of SIM2 until SIM2 is made active. If SIM2 is configured as Primary, Dashboard will likely have the details of SIM1 Changing carrier provided MTU is not available. ECO is available to change MTU only in passthrough mode ... View more

Cellular gateway firmware versions MG 3.0 changelog Important notice While Meraki appliances have traditionally relied on UDP port 7351 for cloud communication and TCP ports 80 and 443 for backup communications, with MG 3.0 we are beginning a 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 filtering devices that may be deployed upstream of your Meraki appliances. These requirements have been updated on Nov 2022, so it’s important that you review them. New product highlights MG51 support New feature highlights IPv6 support for MG21/41/51 IP Passthrough support for MG41/51 Bug fixes Improved NAT mode throughput for MG41 Improved cellular modem management and SIM detection Corrected issue where some MGs may show the wrong connection type Known issues There is an increased risk of encountering device stability and performance issues on all platforms and across all configurations for firmware set as beta ... View more

Camera firmware versions MV 5.2 changelog Other Custom MV 5.2 version Please contact support for more details. ... View more

Security appliance firmware versions MX 18.106 changelog Bug fixes Corrected an issue that resulted in intrusion detection rule update events not being logged to the event log. Reduced the amount of time before a URL classification request performed by the content filtering service would be considered to have failed. This may resolve latency caused by content filtering in cases when classification requests failed and needed to be retried on a consistent basis. Resolved an issue that could result in connectivity checks to Meraki cloud infrastructure that are performed prior to allowing an upgrade to be scheduled to erroneously fail. Stability improvements for MX64(W), MX65(W), MX67(C,W), and MX68(W,CW), MX75, MX84, MX85, and MX100 appliances. Corrected a rare issue that could result in Z3(C) appliances incorrectly discarding traffic. Fixed a rare issue that could result in the WAN interfaces for MX appliances incorrectly transitioning to a down state for a brief period of time. Resolved an error that resulted in the VPN status page reporting the incorrect status for VPN connections to non-Meraki VPN peers formed using an FQDN instead of an IP address. Corrected a rare issue that could result in MX84, MX100, and vMX appliances being unresponsive after rebooting. Performance improvements for VPN traffic for Z3(C), MX84, and MX100 appliances. General performance improvements. These are most likely to be noticed in environments where MX appliances are processing a high volume of packets. Fixed an issue of incorrect fragmentation handling for IPv6 packets. Resolved an issue where an MX appliance could stop responding to LAN traffic when a frame was received with a source MAC address matching the MX’s own LAN port. This issue was most likely to occur in complex switching topologies, or when there were forwarding issues within the network. Corrected an MX 18.1.X regression that could result in incorrect power LED behavior during the bootup process for MX65(W) appliances. Fixed a rare issue that could result in disruptions to DHCP in High Availability configurations. 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.6. 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 When SGT is enabled on MX84 appliances, any packet larger than 1440 bytes will be dropped. Due to this, we recommend that the SGT feature only be enabled in lab or other non-production environments on MX84 appliances. 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. Wireless clients may experience degraded performance for HTTP and HTTPS traffic when content filtering is enabled. There may be an increased risk of encountering device stability and performance issues. Other Added firmware support for reporting when the AnyConnect VPN service starts or stops in the Event Log. Minor improvements to the reporting of flow data via syslog. Slightly reduced the power usage of MX64(W) and MX65(W) appliances. Power savings range from approximately 0.5W to 1.25W. MX appliances will now use 64 as the CurHopLimit value in IPv6 Router Advertisement messages. ... View more

Switch firmware versions MS 15.20 changelog Alerts HTTP proxy is no longer supported on MS 15+. Nodes that use HTTP proxy without any other means to connect to dashboard may fail to connect. While Meraki switches have traditionally relied on UDP port 7351 for cloud communication and TCP ports 80 and 443 for backup communications, with MS 15.1+ we are beginning a 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 filtering devices that may be deployed upstream of your Meraki switches. These requirements have been updated on Nov 2022, so it’s important that you review them. Ms390 alerts MS390 series switches can only downgrade to MS 12 with an incremental step to MS 14 Stacks may fail to complete an upgrade to this version and will revert back to the starting version. If this happens, splitting the stack and upgrading individually is required (present since MS 15.15) Upgrades to this version will result in a full system reload Ms390 features Additional client analytics added Alternate Management Interface (AMI) support Critical/failed authentication support Group policy ACL support IPv6 static routing support MAC flap detection support Meraki authentication support Multi-auth with voice VLAN bypass support Netflow and Encrypted Traffic Analytics (ETA) support STP anomaly detection Stack power is supported by default UDLD support UPoE (802.3bt) support URL redirect support New features IPv6 management interface support General fixes AMI IP addresses do not send gratuitous ARP packets which can lead to packet loss if the AMI address has aged out in the network (always present) NAT detection incorrectly shows IPv4 addresses as hexadecimal instead of dotted decimal notation (present since MS 15) Ports will fail to correctly revert to the previously configured VLAN when disabling SecurePort. A reboot or port VLAN change corrects this (present since MS 15) Sporadically, SNMP walks will fail by not increasing the OID (present since MS 14.13) Ms2xx/35x/4xx fixes Clients may fail to be relearned by the MAC table after going into sleep mode and waking back up (present since MS 15.15) Stack routing tables can be incorrect after removing an SVI (present since MS 14.32) Ms390 fixes Bundling port(s) that have a voice VLAN configured results in the LACP bundle failing to be configured (present since MS 15.14) Changing the OSPF router ID will cause the system to go offline (present since MS 15.19) STP event logs are not being logged (always present) Stacks will drop DHCP relay ACK packets after modifications are made to the DHCP allowed/blocked policy (present since MS 14.32) 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) Enabling NAT detection may cause issues with TCP streams resulting in pages failing to load entirely or taking longer than usual to load (present since MS 14) 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) Ms120 known issues In rare instances, switches may return empty packet captures until they are rebooted Switches in extremely rare instances will experience reboots every few minutes (present since MS 11) Ms120/125 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) Ms125 known issues The local status page cannot be accessed from the management port (always present) Ms2xx/350/355/4xx known issues Cross-stack LACP bundles experiencing a switch reboot will cause the remaining online port to experience an outage for up to 30 seconds. The same is seen again when the switch comes back online (present since MS 10) Loops can be seen when rebooting a stack member containing a cross-stack lag port (always present) 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 Ms350/355 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. Ms355 known issues In rare instances, stack ports fail to initialize after an upgrade (always present) Ms390 known issues "Port Up/Down" events will generate an event log for each stack member Adding additional ports to a port bundle will cause the entire bundle to be reconfigured causing traffic loss (always present) Changing the OSPF router ID requires a system restart to become active (always present) 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) IGMP snooping enabled will send an IGMP message on every configured VLAN every 125 seconds (always present) In very rare instances, the management plane will restart every few minutes and requires a full reboot to self-correct (present since MS 15) Large stacks may experience intermittent management plane loss resulting in config fetch delays (always present) Loop detection is not supported Multiple CoA policies sharing the same IP but using different ports fails to be configured (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) Stacks may fail to complete an upgrade to this version and will revert back to the starting version. If this happens, splitting the stack and upgrading individually is required (present since MS 15.15) Warm spare/VRRP is not supported Ms425 known issues 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

SECURITY FIXES Qualcomm wireless chipset vulnerability - https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwa93623 (Wi-Fi 5 Wave 2 and Wi-Fi 6 APs) ... View more

Security appliance firmware versions MX 16.16.9 changelog Important notice While Meraki appliances have traditionally relied on UDP port 7351 for cloud communication and TCP ports 80 and 443 for backup communications, with MX 16 we are beginning a 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 filtering devices that may be deployed upstream of your Meraki appliances. These requirements have been updated on Nov 2022, so it’s important that you review them. HTTP proxy, which allows default management traffic from MX appliances to be sent through a proxy, is deprecated on MX 16 and higher firmware versions. Bug fixes Fixed a rare issue that could result in disruptions to DHCP in High Availability configurations. Legacy products notice When configured for this version, Z1 and MX80 appliances will run MX 14.56. 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 MX 15 regressions, USB cellular connectivity may be less reliable on some modems 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. ... View more

Camera firmware versions MV 5.1 changelog New Initial firmware support for Audio Recording on MV63(x)/MV93(x) Initial firmware support for Sensor Crop on MV63(x) Bug fixes Fixed an issue where local video streaming can become unresponsive Fixed an issue where 2nd gen experimental model would fail to initialize Fixed an issue where Gen2 cameras do not report LLDP information General Improved connectivity performance for MT sensors Improved accuracy and performance of vehicle and person detection Improved performance of motion recap image generation General stability and performance improvements ... View more

Switch firmware versions MS 15.19 changelog Alerts HTTP proxy is no longer supported on MS 15+. Nodes that use HTTP proxy without any other means to connect to dashboard may fail to connect. While Meraki switches have traditionally relied on UDP port 7351 for cloud communication and TCP ports 80 and 443 for backup communications, with MS 15.1+ we are beginning a 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 filtering devices that may be deployed upstream of your Meraki switches. These requirements have been updated on Nov 2022, so it’s important that you review them. Ms390 alerts MS390 series switches can only downgrade to MS 12 with an incremental step to MS 14 Upgrades to this version will result in a full system reload Ms390 features Additional client analytics added Alternate Management Interface (AMI) support Critical/failed authentication support Group policy ACL support IPv6 static routing support MAC flap detection support Meraki authentication support Multi-auth with voice VLAN bypass support Netflow and Encrypted Traffic Analytics (ETA) support STP anomaly detection Stack power is supported by default UDLD support UPoE (802.3bt) support URL redirect support New features IPv6 management interface support General fixes AMI IP addresses do not send gratuitous ARP packets which can lead to packet loss if the AMI address has aged out in the network Sporadically, SNMP walks will fail by not increasing the OID (present since MS 14.13) Ms2xx/350/355/4xx fixes Stack routing tables can be incorrect after removing an SVI (present since MS 14.32) Ms390 fixes ARP live tool only shows a maximum of 63 entries Adaptive policy config fails to be configured when more than 7 ACLs are mapped to a policy (present since MS 15) DHCP fixed IP assignments are not removed until the system is rebooted Disabled LACP ports do not remain shut down after a reboot (present since MS 15.15) In very rare scenarios, the switch's VLAN database may become incompatible after an upgrade requiring a factory reset (present since MS 15.15) Management plane may lose connectivity momentarily after changes are made to the storm control percentage Management plane may restart after removing L3 interfaces (present since MS 15.17) OSPF seeing duplicate neighbor IDs will result in the system becoming unresponsive (present since MS 15) Only 255 out of 256 static routes can be configured Stack members may not reset their configuration when another member is reset Switchports with allowed VLANs character lists greater than 223 characters fail to be configured (always present) Traffic statistics may fail to show on dashboard (present since MS 15.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) Enabling NAT detection may cause issues with TCP streams resulting in pages failing to load entirely or taking longer than usual to load (present since MS 14) 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) Ms120 known issues In rare instances, switches may return empty packet captures until they are rebooted Switches in extremely rare instances will experience reboots every few minutes (present since MS 11) Ms120/125 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) Ms125 known issues The local status page cannot be accessed from the management port (always present) Ms2xx/350/355/4xx known issues Cross-stack LACP bundles experiencing a switch reboot will cause the remaining online port to experience an outage for up to 30 seconds. The same is seen again when the switch comes back online (present since MS 10) Loops can be seen when rebooting a stack member containing a cross-stack lag port (always present) 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 Ms350/355 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. Ms355 known issues In rare instances, stack ports fail to initialize after an upgrade (always present) Ms390 known issues "Port Up/Down" events will generate an event log for each stack member Adding additional ports to a port bundle will cause the entire bundle to be reconfigured causing traffic loss (always present) Fixed IP assignments are not deconfigured until the system is fully reloaded (present since MS 14.33) IGMP snooping enabled will send an IGMP message on every configured VLAN every 125 seconds (always present) In very rare instances, the management plane will restart every few minutes and requires a full reboot to self-correct (present since MS 15) Loop detection is not supported Multiple CoA policies sharing the same IP but using different ports fails to be configured (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) Warm spare/VRRP is not supported Ms425 known issues 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

Security appliance firmware versions MX 18.105 changelog New features Added support for forwarding Secure Group Tags (SGT) on traffic. This is available on Z3(C), MX64(W), MX65(W), MX67(C,W), and MX68(W,CW), MX75, MX84*, MX85, MX95, MX100, MX250, and MX450 appliances and enables full stack (MR+MS+MX) Adaptive Policy operation. * Please see the known issues for important information about SGT on MX84 appliances. Bug fixes MX appliances will now drop additional types of erroneous traffic received from AnyConnect VPN clients. Resolved a rare case that could result in non-Meraki VPN traffic being incorrectly forwarded when MX appliances were configured in passthrough mode. Performance improvements for MX250 and MX450 appliances. Corrected an issue that resulted in client traffic being will be dropped by MX65(W), MX67(C,W), and MX68(W,CW) appliances when 1) The client was connected to a LAN port with 802.1X authentication enabled and 2) The VLAN ID of the port was configured to 16, 32, 48, 64, 80, 96, 112, 128, 144, 160, 176, 192, 208, 224, or 240. Fixed several rare cases that could result in a device reboot. Fixed an issue that could result in MX appliances replying to ARP messages for an incorrect IP address when 1) The MX was configured to operate as the standby/spare device in a high availability configuration and 2) the MX appliance was configured to operate in passthrough mode. 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.6. 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 When SGT is enabled on MX84 appliances, any packet larger than 1440 bytes will be dropped. Due to this, we recommend that the SGT feature only be enabled in lab or other non-production environments on MX84 appliances. There may be an increased risk of encountering device stability and performance issues. Other If DNS is not available on the MX’s IPv6 uplink, MX appliances will now attempt to fetch a configuration using DNS over HTTPS to the Meraki cloud. ... View more

Wireless firmware versions MR 29.5.1 changelog Important note Meraki APs use UDP port 7351 for cloud communication and TCP ports 80 and 443 for backup communications when running MR 27 and older firmware. When running MR 28+ firmware, Meraki APs will now use TCP port 443 as the primary means for cloud connectivity. In order to maintain connectivity to the Meraki cloud on MR 28+ ensure that TCP port 443 is allowed to communicate with 209.206.48.0/20 on firewalls that are deployed upstream of your Meraki APs. (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 Sporadic packet loss & instability on Layer 3 roaming & Teleworker VPN SSID's (Wi-Fi 5 Wave 2 and Wi-Fi 6 APs) ... View more

Security appliance firmware versions MX 16.16.8 changelog Important notice While Meraki appliances have traditionally relied on UDP port 7351 for cloud communication and TCP ports 80 and 443 for backup communications, with MX 16 we are beginning a 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 traffic using TCP port 443 between 209.206.48.0/20 is allowed through any firewalls that may be deployed upstream of your Meraki appliances. HTTP proxy, which allows default management traffic from MX appliances to be sent through a proxy, is deprecated on MX 16 and higher firmware versions. Legacy products notice When configured for this version, Z1 and MX80 appliances will run MX 14.56. Bug fixes Resolved an issue that could cause small, periodic packet loss on MX100 appliances. Fixed an issue that caused packet loss between client devices communicating within the same VLAN when both client devices were connected to ports configured for 802.1X port authentication. Resolved a case where the device local status page could still be accessed, even after it had been disabled via the Meraki Dashboard. 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 MX 15 regressions, USB cellular connectivity may be less reliable on some modems 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. ... View more

Security appliance firmware versions MX 18.104 changelog Important notice While Meraki appliances have traditionally relied on UDP port 7351 for cloud communication and TCP ports 80 and 443 for backup communications, with MX 16 we are beginning a 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 traffic using TCP port 443 between 209.206.48.0/20 is allowed through any firewalls that may be deployed upstream of your Meraki appliances. HTTP proxy, which allows default management traffic from MX appliances to be sent through a proxy, is deprecated on MX 16 and higher firmware versions. The transition to Cisco Talos intelligence for our content filtering services means that some URL categories have changed names, some categories are no longer available, and multiple new categories are now available. Please review your configuration after upgrading to ensure content filtering is effectively tailored to your needs and deployment environment. 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.6. Bug fixes Fixed a rare issue that could result in AutoVPN tunnels failing to form. MX appliances will no longer attempt to perform content filtering on URLs with some invalid characters. Resolved a rare issue that could result in MX devices being unresponsive to Dashboard live tools, despite appearing to be online. Fixed an MX 18.1.03 regression that resulted in MX95 and MX105 reporting incorrect port numbers in NetFlow messages. Corrected a rare case that could result in flows not respecting bandwidth limits under low bandwidth conditions. Resolved an issue that caused Z3(C) devices to be described as “Security Appliance” as opposed to “Teleworker Gateway” on the device local status page. Corrected an issue that resulted in the device local status page incorrectly showing a configuration to convert the WAN1 port to operate as a LAN port. Fixed a rare issue that could result in a device reboot when AutoVPN was enabled. Fixed an issue that caused packet loss between client devices communicating within the same VLAN when both client devices were connected to ports configured for 802.1X port authentication. Corrected an issue that could result in an inconsistent connection to the Cisco Umbrella service when Umbrella Protection was configured. Resolved a case where the device local status page could still be accessed, even after it had been disabled via the Meraki Dashboard. MX appliances will now always connect to Active Directory servers using DCOM version 5.7. This should help resolve errors when communicating with Active Directory servers using more recent versions of software. Corrected an issue that could result in the Dashboard reporting of the Active Directory server status always showing a failed connection. Corrected an additional issue that could result in AutoVPN connectivity failing to form when cellular active uplink was configured. Resolved a rare issue that could prevent Z3(C) appliances from upgrading to MX 18.1.XX firmware versions when AutoVPN was enabled. Performance improvements for basic traffic routing and AutoVPN. 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

This is the promotion of 5.00 to stable release.  I can confirm from our experience that it has worked well so far. ... View more