Below are the fixes for 15.17 and 15.15 as that appears not to have been released, but the fixes are cumulative. 15.16 had no different fixes, merely differently phrased ones...
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.
- MS390 upgrades to this version will result in a full system reload
- MS390 series switches can only downgrade to MS 12 with an incremental step to MS 14
BRANCH ADDITIONS
- STP anomaly detection support for MS390 series switches
- IPv6 static routing support for MS390 series switches
- Additional client analytics added for MS390 series switches
- Meraki authentication support for MS390 series switches
- Alternate Management Interface (AMI) support for MS390 series switches
- UDLD support for MS390 series switches
- Group policy ACL support for MS390 series switches
- IPv6 management interface support
- URL redirect support for MS390 series switches
- UPoE (802.3bt) support for MS390 series switches
- Critical/failed authentication support for MS390 series switches
- Multi-auth with voice VLAN bypass support
- MAC flap detection support for MS390 series switches
- Stack power is supported by default for MS390 series switches
- Netflow and Encrypted Traffic Analytics (ETA) support for MS390s
BUG FIXES
General
- Guest VLAN and critical auth ports are not always bounced after the RADIUS server becomes reachable again (always present)
- Disabling Adaptive Policy at the network level fails to fully remove the configuration from the device (always present)
- Stacks running a DHCP server may experience a reboot (present since MS 14.32)
- Group policy ACLs that had non-valid characters in the name would fail to be applied and would cause the management plane to restart (present since MS 15)
- Ports that change STP state quickly may be shown as "XXX" (always present)
- High amounts of unknown unicast or multicast traffic could cause the management plane to lose connectivity (always present)
- In rare instances, stack ports may fail to be configured properly on boot
- RADIUS sessions are incorrectly created for clients behind a phone when the client sends an EAPoL logoff message (present since MS 11)
- Stacks in rare circumstances will crash if STP TCNs are seen at the same time as it is snooping DHCP traffic
- When clients would disconnect, event logs fail to be created until clients are re-connected
Specific Models
- MS120 ACLs fail to be applied if a host IP is used with a mask other than /32 (always present)
- MS225 switches will go offline if there is a flood of OSPF traffic (always present)
- RADIUS testing doesn't work on MS225/250/350/355/425/450 series switches (present since MS 15)
- MS120/125/355/450/390 switches may lose dashboard connectivity for a few minutes (present since MS 15.1)
MS390 only
- MS390 management plane may hang and fail to restart until the entire system reboots (present since MS 15)
- MS390s will report a stack topology change erroneously (present since MS 15)
- MS390s will intermittently track clients on the uplink with uplink sampling disabled when the uplink is flapping between ports or on initial bootup (always present)
- MS390 modules may fail to be reflected in dashboard (present since MS 15)
- Event log isn't generated if an MS390's configuration was rolled back or reverted (present since MS 15)
- MS390 IPv6 interfaces do not have RA suppression configured by default
- MS390 AMI duplicate address detection will fail (present since MS 15)
- MS390 management plane in rare instances will restart when configuring port-channels
- Removing ACLs from MS390s can silently fail when network boundaries are not correct (always present)
- MS390 management plane may experience boot loops (present since MS 15)
- MS390 ports fail to be configured with static speeds resulting in ports always staying in auto-negotiation mode
- Client authentications may fail on MS390 during periods when there's multiple authentication attempts, such as, during a reboot (present since MS 14)
- MS390 port status is not correctly reflected in dashboard (present since MS 15.14)
- MS390s will show different information on the "Switch > DHCP Servers & ARP" page depending if it's configured to act as a server or not (always present)
- MS390 Storm Control configuration is not applied correctly if multicast along with other traffic types are configured (present since MS 14)
- MS390s retain their Storm Control configurations after it's removed from dashboard (always present)
- MS390s in some circumstances will fail to populate all DHCP clients that it's serving (always present)
- MS390 switches do not learn traffic details from IPv6 traffic
- Access policies removed on dashboard may not fully remove the configuration on MS390s which could result in conflicts if a new policy is configured
- DHCP may become disabled on MS390s with very specific and unique pool configurations set (present since MS 12)
- MS390 series switches may experience rare management plane restarts due to dashboard statistics syncing (present since MS 15.14.1)
- MS390 event logs are misleading for port security violations when clients move between ports (always present)
- MS390 LLDP system name is incorrect (present since MS 15.15)
- MS390 deauthentication messages are displayed for all received MAC addresses, regardless of if they were authenticated or not (always present)
- Changes made to MS390 switches may take a long time to apply, or completely fail (present since MS 15.15)
- MS390 IPv6 QoS does not take effect (always present)
KNOWN ISSUES
General
- With some unique configurations, the next hop VLAN on L3 stacks may incorrectly become out of sync after making L3 changes (present since MS 14.33)
- 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)
- The next-hop port may be incorrect on L3 stacks and believed to be the result of client flapping between ports (present since MS 14.32)
- Connecting a stacking cable to a stack that is online may result in a stack member going offline (present since MS 12)
- 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
- 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)
- 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)
- 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
Specific Models
- MS120 series switches in extremely rare instances will experience reboots every few minutes (present since MS 11)
- In rare instances, MS120 series switches may have empty packet captures until they are rebooted
- MS120/220 series 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)
- Ports with an odd-numbered MTU value fail to initialize for MS120/125 series switches (predates MS 11)
- The local status page cannot be accessed from the management port of MS125s (always present)
- Enabling Combined Power on MS350/355 switches results in events being logged once per minute (present since MS 11)
- 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 stacks in rare instances will start dropping DHCP traffic on trusted ports while DAI is enabled until rebooted (present since MS 12)
- MS355-48X model switches may fail to provide PoE to some end devices like IoT (always present)
- MS350-24X and MS355 series switches do not negotiate UPoE over LLDP correctly (always present)
- 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)
- MS350/450 series switches in a stack configuration will lose dashboard connectivity if a "Deny Any Any" ACL is added without having higher "Allow" rules in place for dashboard connectivity (predates MS 12)
- MS210/225/350/355/425/450 series switches in large L2 networks experiencing frequent STP TCs can become fully unresponsive (present since MS 15)
MS390
- MS390s passing line rate traffic on non-uplink ports can have an impact on the management plane connectivity
- In rare instances, MS390 configurations will fail to be fully applied resulting in random behavior
- MS390s with multiple CoA policies sharing the same IP but using different ports fails to be configured (always present)
- MS390 management plane may lose connectivity after changes are made to the storm control percentage
- MS390 fixed IP assignments are not unconfigured until the system is fully reloaded (present since MS 14.33)
- In very rare instances, the management plane on MS390s will reboot every few minutes and requires a full reboot to self-correct (present since MS 15)
- MS390s authenticating over 350 dot1x clients at the same time may see its management connection flap (present since MS 15.15)
- MS390 stacks in rare instances will experience a full reboot
- MS390s will fail to configure a port if the allowed VLANs character length is greater than 223 (always present)
- Dashboard incorrectly reports the slot 2 power supply as offline for MS390s
- MS390s that receive incorrectly flooded CDP packets may incorrectly report VLAN mismatches and SFP port information (present since MS 12)
- MS390 "Port Up/Down" events will generate an event log for each stack member
- MS390s with IGMP snooping enabled will send an IGMP message on every configured VLAN every 125 seconds (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)
- TMS390s in rare instances will experience a system crash when syncing STP databases between stack members (present since MS 14.33)
- MS390 series switches do not support loop detection
- MS390 series switches do not support warm spare/VRRP
- Rebooting an MS390 switch in a stack via the UI will result in the entire stack rebooting
- Adding additional ports to an MS390 port bundle will cause the entire bundle to be reconfigured causing traffic loss (always present)
- MS390 throughput is limited to the lowest link speed since boot when QoS is enabled (present since MS 15.11)
