New MS 14.26 firmware - many MS390 fixes and a stack reboot issue quashed

[cmr]

Switch firmware versions MS 14.26 changelog

Alerts

• MS390 MS390 upgrades to this version will result in 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

Bug fixes

• In rare instances, when all stack members were rebooted at the same time, one or more stack members fail to come online and require a manual reboot
• The UI will show clients connected to MS390 access ports as being on the "native" VLAN
• MS390 ports that are blocked by STP incorrectly show as forwarding on dashboard
• MS390s do not display SFP model information
• MS390 copper ports show "SFP link" when hovering over the connectivity bar
• MS390 performance and stability enhancements
• MS390 DHCP servers exclude IPs from the DHCP pool indefinitely that were in conflict
• MS390 stack members send LLDP frames with the "System Name" being the same as the master switch
• MS390s in some instances will send DHCP requests on multiple VLANs and use DNS responses from the non-preferred VLAN
• MS390 ACLs are not removed from the switch when deconfigured from dashboard

Known issues

• Stack member click crash on 14.22
• A high amount of constant STP TCNs in a network may result in instability, and in rare instances, switch crashes
• MS390 ports are limited to the lowest link speed since boot if QoS is enabled
• In rare instances, non-MS390 switches will reboot (present since MS 12)
• Running over 1000 packet captures on a switch without a reboot may result in degraded switch performance
• MS120s may show PoE usage on the incorrect port
• In rare instances, a stack member may go offline until rebooted (present since MS 12)
• Click crashes on multiple stack members at the same time
• Packet loss is observed when pinging the MS390 management IP
• MS120s on rare occasions will reboot (present since MS 11)
• Stackpower is not enabled on MS390s by default
• 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)
• Links being established on a MS120 can result in neighboring ports to flap (present since MS 11)
• MS120s with multiple access policies enabled may reboot when port changes are made
• The traceroute live tool fails to run
• The switch status page will incorrectly report 00:00:00:00:00:00 as root for MS390s acting as root
• Enabling Combined Power on MS350/355 switches results in events being logged once per minute (present since MS 11)
• Networks containing a high number of switches may encounter issues saving changes on the Switch Settings page
• MS220 and MS320 switches may randomly reboot in large L2 domains (present since MS 11)
• In rare circumstances, the next hop VLAN is incorrectly modified for existing OSPF SVIs when a new SVI is added which will also participate in OSPF. A reboot will correct this (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. Example, MS355 switchports 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
• In rare instances, when a stack reboots, ports may come up as "LACP blocked state", even if LACP is not configured (present since MS 10)
• MS120s switchports 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 stacks on rare occasions will require a manual reboot after the upgrade has completed
• MS390 series switches do not support SM sentry
• MS390 series switches do not support Meraki authentication
• MS390 series switches do not support URL redirection
• MS390 series switches do not support MAC whitelists
• MS390 series switches do not support loop detection
• MS390 series switches do not support warm spare/VRRP
• MS390 series switches do not support UDLD
• MS390 series switches do not support MAC flap detection
• MS350-24X and MS355 series switches do not negotiate UPoE over LLDP correctly (predates MS 10)
• Rebooting any MS390 stack member via the UI will result in the entire stack rebooting

[watdee]

"MS390 series switches do not support loop detection"

This seems really important for an access switch.  Any idea when it'll be supported? 

Looks like you need to update the UDLD documentation.  It says "UDLD is supported in all Meraki switches running 10.10 and above"

Thanks

[watdee]

I feel like this should be on the known issues.  I read it on the ACL Documentation page "Note: The VLAN qualifier is not supported on the MS390. For the MS390, ACL rules with non-empty VLAN fields will be ignored."