New MS 14.25 stable release candidate firmware - minor updates, nothing to see here for MS390s

cmr
Kind of a big deal
Kind of a big deal

New MS 14.25 stable release candidate firmware - minor updates, nothing to see here for MS390s

Switch firmware versions MS 14.25 changelog

Alerts

  • MS390 upgrades from MS 14.19 or later will result in minimal impact to client traffic
  • MS 14.25 is the same as 14.24 for MS390 series switches. If the switches are running 14.24 and the network is upgraded to 14.25, the MS390s will not reboot.

Branch additions

  • 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

  • A switch's AMI will source ICMP replies from the management VLAN instead of the AMI VLAN
  • A Syslog report and event log message are missing when a cable test is run
  • In rare instances switches could experience a reboot every few days
  • Multiple RADIUS timeouts can lead to the switch rebooting
  • Stackings running PIM may encounter synchronization issues which can result in some receivers being unable to receive certain streams

Known issues

  • 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)
  • 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 UI will show clients connected to MS390 access ports as being on the "native" VLAN
  • 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
  • Switchport tags cannot be removed if they are added after a port profile is attached to the switch
  • 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
Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels