General Fixes and it appears some rather specific bugs fixed. 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 Disallow RF mode switching for CM64 boards Intermittent low power mode (MR53, MR56) SES-imagotag bootloop (MR30H, MR33) Honeywell printers unable to connect to hidden SSID Known issues Sporadic packet loss & instability on Layer 3 roaming & Teleworker VPN SSID's (Wi-Fi 5 Wave 2 and Wi-Fi 6 APs) No DHCP response error is seen after a client performs a successful L3 roam (Wi-Fi 5 Wave 2 and Wi-Fi 6 APs) ... View more

Per this doc: https://documentation.meraki.com/MX/Client_VPN/AnyConnect_on_the_MX_Appliance#Dashboard_API_Support   There should be an anyconnect api, but I can't find it at the referenced location or anywhere else.   Does anyone know what's up? ... View more

The below releases appear to bring 28.x and 29.x to fix parity with one exception as 28.7 still has:  AP performance may degrade over time (Wi-Fi 6 APs) Otherwise just 3 known issues   29.2 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 AP performance may degrade over time (Wi-Fi 6 APs) AP may stop broadcasting beacons on WPA2 configured SSID (MR53E) AP may lose Cloud connectivity for an interval of time (Wi-Fi 6 APs) SES-imagotag ESL status may display as gray even when ESL is functioning normally (Wi-Fi 5 Wave 2 and Wi-Fi 6 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) No DHCP response error is seen after a client performs a successful L3 roam (Wi-Fi 5 Wave 2 and Wi-Fi 6 APs) SES-imagotag ESL functionality may not work (MR30H, MR33)   28.7   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. New U-NII 1, 2, 2E channel support in Qatar regulatory domain (Wi-Fi 5 Wave 2 APs) Bug fixes General stability and performance improvements (Wi-Fi 5 Wave 2, Wi-Fi 6, and Wi-Fi 6E APs) AP may stop broadcasting beacons on WPA2 configured SSID (MR53E) AP may lose Cloud connectivity for an interval of time (Wi-Fi 6 and Wi-Fi 6E APs) Wireless timeline and wireless latency client metrics may be missing (Wi-Fi 5 Wave 2, Wi-Fi 6, and Wi-Fi 6E APs) Multicast traffic received on the wired is periodically not forwarded to clients on LAN (MR30H) Channel 100 utilizing 40 or 80 MHz channel widths may show high channel utilization with no client connected (MR53) When an Apple client enters an incorrect PSK the AP responds with a disassociation response instead of deauthentication response, resulting in multiple failed connection attempts from the client (Wi-Fi 5 Wave 2 APs) AP may stop publishing MQTT updates until rebooted (Wi-Fi 5 Wave 2 APs) AP may reboot when detecting a very high number of DFS events (Wi-Fi 6 APs) AP may not sync PMKs on WPA3 Enterprise SSIDs configured with OKC (Wi-Fi 5 Wave 2, Wi-Fi 6, and Wi-Fi 6E APs) Enabling FIPS may cause issues with RADIUS authentication (Wi-Fi 6 APs) AP intermittently stops redirecting HTTP Traffic to the Splash page prior to Splash page login (Wi-Fi 5 Wave 2 and Wi-Fi 6 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) No DHCP response error is seen after a client performs a successful L3 roam (Wi-Fi 5 Wave 2 and Wi-Fi 6 APs) AP performance may degrade over time (Wi-Fi 6 APs) SES-imagotag ESL status may display as gray even when ESL is functioning normally (Wi-Fi 5 Wave 2 and Wi-Fi 6 APs)   ... View more

This big one: Resolved an issue that resulted in MX84 and MX100 appliances having significantly reduced VPN throughput. and a few others for 17.7 and some to match 16.16.3   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, MX60, MX60W, MX80, and MX90 devices will run MX 14.56. When configured for this version, MX400 and MX600 devices will run MX 16.16.3. Bug fixes BGP stability improvements. Resolved a case that resulted in MX appliances improperly routing traffic to clients behind an IPv6 static route. Resolved several rare cases that could result in device reboots. Resolved a rare case where port speed and duplex settings applied via the local status page would not be honored if settings had previously been configured on MX 12 or earlier. Resolved a rare issue that could result in MX appliances performing content filtering lookups for an improperly derived URL when the certificate exchange used to establish an HTTPS connection was fragmented. Corrected an issue that could result in dynamic DNS certificates used for AnyConnect VPN failing to renew. Resolved an issue that could result in a disruption to traffic routing when configuration changes were made to MX appliances with a large number of AutoVPN routes. Fixed an issue that could result in Z3(C) appliances erroneously showing an orange power LED while they were connected and online. Corrected an issue that resulted in MX appliances not responding to ICMPv6 ping messages received on PPPoE WAN uplinks. Resolved an issue that resulted in MX84 and MX100 appliances having significantly reduced VPN throughput. Corrected an issue that resulted in the PoE status icons not being displayed in Dashboard for MX95 and MX105 appliances. 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. Other MX appliances now support forwarding IPv6 no next header packets when configured in passthrough mode. ... View more

Absolute Bevy of Fixes, including I believe Voice Vlan/802.1x and layer 3 changes needing a reboot. Alerts MS390 upgrades to this version will experience a full system reload Branch additions Syslog support for MS390 series switches SNMP support for MS390s RADIUS accounting support for MS390s Alternate Management Interface support for MS210/MS225/MS250/MS350/MS355/MS410/MS425/MS450 series switches QoS support for MS390s CoA support for MS390s STP anomaly detection events for non-MS390 series switches Adaptive policy support for MS390 series switches SecureConnect support for MS210/MS225/MS250/MS350/MS355/MS410/MS425/MS450 series switches NAC enhancements for MS120/125/210/225/250/350/355/425/450 series switches Critical/failed auth VLAN support for MS120/125/210/225/250/350/355/425/450 series switches Bug fixes The Voice VLAN fails to stay authenticated if it is authenticated before the Data VLAN (present since 14.28) Client MAC addresses may fail to be learned on a port right after an access policy is applied (present since 14.28) SVI changes made to stacks may result in incorrect route mappings resulting in packet loss (present since MS 14.32) MS390 management plane can experience frequent restarts (present since MS 14.27) Voice VLAN bypass configuration was not being applied correctly to MS390 series switches Clients fail to be placed into the Critical VLAN if the re-authentication timer is configured In rare instances, DAI may fail to snoop DHCP transactions on stacks leading to those clients being in a blocked state MS390 series switches do not support forced speeds of 2.5 or 5Gbps Ports that are moved into a Critical Authentication state fail to be removed once the RADIUS server becomes reachable again without a reboot Switches in an IPv6 only network will experience reboots MS120 series switches may experience instability when multiple ports are modified which are configured with access policies MS250 series switches in rare instances could experience unexpected reboots SNMP IfIndex integer for MS390 series switches would start at 9 instead of 1 ACLs are not removed on MS390s when unconfigured on dashboard MS120s on rare occasions will reboot (present since MS 11) Stack members may go offline and require a reboot to regain connectivity (present since MS 12) MS390 management plane can get stuck in a crash loop resulting in the switch staying disconnected from dashboard Known issues MS390 switches may experience a full system restart (present since MS 14.29) MS390 management plane can restart which may show as brief loss of connectivity in dashboard (present since MS 12.28) MS390 stack members may experience a full system restart (present since MS 14.29) When the management plane restarts on MS390s, LACP flapping can be encountered Stacks with a large number of LACP bundles (10+) may fail to initialize stack ports properly requiring additional reboots to regain connectivity MS390s do not respond to broadcast DHCP Offers for their management IP addresses (present since MS 14.31) MS390 stacks may send frequent DHCP requests despite having a valid static IP In rare instances, the MS390 management plane will fail to restart requiring a manual reboot (present since MS 14.26) MA-SFP-1GB-TX modules may fail to be detected after link loss (always present) CDP protobuf data reports null port module ID Stack members may go offline after a stacking cable is reconnected requiring a power cycle (present since MS 12) MS120 in rare instances will not be able to perform packet captures until rebooted (predates MS 12.28) Packet loss is observed when pinging the MS390 management IP MS210/250 series switches may fail to relearn client MACs on ports that have access policies configured (present since MS 12) Links being established on an MS120 can result in neighboring ports to flap (present since MS 11) In very rare instances, MS120 series switches will reboot every 10 min (present since MS 12) MS390 - Port Up/Down Events Shown Across All Members Enabling Combined Power on MS350/355 switches results in events being logged once per minute (present since MS 11) Networks containing a large number of switches may encounter issues saving changes on the Switch Settings page Stack members are not being marked to update their configuration when changes are made on other members 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. Example, MS355 switch ports will incorrectly show an amber light for 1G, 2.5G, and 5G, but will show a green light for 10G. The list of switches to clone from fails to load when cloning a switch in an organization with a large number of switches and networks Cable test tool returns wrong pairs for 100Mbps connections (predates MS 12) MS390 stack management plane may experience recurrent loss of dashboard connectivity (present since MS 14) Broadcast types of traffic can leak into the Guest VLAN if a port that fails authentication has a Voice VLAN configured, and dashboard has a Guest VLAN defined (present since MS 11) MS120s switch ports with MAB authentication may randomly deauthenticate clients. In order to resume client authentication on that port, a switch reboot is required (present since MS 12) MS390 series switches do not support SM sentry MS390 series switches do not support loop detection MS390 series switches do not support warm spare/VRRP MS350-24X and MS355 series switches do not negotiate UPoE over LLDP correctly (predates MS 10) Ports with an odd-numbered MTU value fail to initialize for MS120/125 series switches (predates MS 11) When an SFP module is inserted/removed on MS420/425 series switches, BPDUs can be delayed leading to STP transitions in the network (predates MS 12) ... View more

Got a few email notifications today that an MX I manage is using AMP and/or Threatgrid and I need to update. Was aware of the overall need to  update. A comment for whomever did this mail merge.... maybe just maybe include the Org and Network where this is!   I manage over 100 orgs with over 400 MXs...   I can find them, but it sure would save some time. ... View more

Seems they skipped a few versions   14.17 Fixes Bug fixes MS390s could show the incorrect root port in dashboard Fixed an issue where large configuration changes could encounter issues updating properly on MS390s Various performance and stability improvements 14.18 Fixes: Bug fixes Viewing a MS390's routing tab would result in a reboot Various performance and stability improvements 14.19 Additions and Fixes: Additions MS390s now support RADIUS accounting Bug fixes When a port's configuration is changed, all switch ports that use dynamic VLAN assignment are deauthenticated and require reauthentication MR44s and MR46s with the MAC address in the following range, 68:3A:1E:FF:F9:63 - 68:3A:1E:FF:FA:46, will not be detected by SecureConnect Fixed an issue where switches would repeatedly send out an excessive number of router solicitations Fixed an issue where under rare circumstances, MS425 fans will stop running which can cause the unit to overheat and power down MS390 dot1x events will now be logged Known issues once you get to 14.19 Known issues MS390s may show a client's VLAN as "native" instead of the correct VLAN number MS390 port traffic in the UI on occasion can show negative traffic for a client MS390 series switches Max MTU is limited to 9198 bytes MS390 series switches will not display packet details in the DHCP Servers page MS390 series switches do not support the 'next-server' or 'bootfile' parameters in DHCP messages Rebooting any MS390 stack member via the UI will result in the entire stack rebooting LLDP frames from MS390 series switches will use a single system name instead of the Dashboard given name MS390 series switches will not display the advertising router ID for OSPF MS390 series switches with OSPF enabled will default to an IP MTU of 1500 bytes on every OSPF enabled interface MS390 series switches do not support the multicast routing livetool MS390 series switches do not support tagged traffic bypass for voice on ports with a Multi-Auth access policy MS390 stacks on rare occasions will require a manual reboot after the upgrade has completed Dynamic VLAN assignment from a RADIUS server on MS390 series switches must already be an allowed VLAN on the port for it to function MS390 series switches do not currently support the following features: VRRP, SM Sentry, Syslog server, SNMP, Traceroute, IPv6 connectivity to dashboard, Meraki Auth, URL Redirection, MAC Whitelisting, Loop Detection, UDLD, MAC Flap Detection SM Sentry does not support Windows based clients (predates MS 10.x) MS425 series switches do not forward frames larger than 9416 bytes (predates MS 10.x) MS350-24X and MS355 series switches do not negotiate UPoE over LLDP correctly (predates MS 10.x) MS355 stacks upon reboot have a chance that the uplink port will go into STP blocking state (predates 12.X) Switches on 12.28+ will sporadically drop DHCP Offers when a relay is in use L3 switch stacks with multicast routing may fail to route streams through all members MS120s can experience packet loss when forwarding from a 1Gbps to 100Mbps port MS320s may experience reboots when in large L2 domains (predates 12.X) ... View more