New MS 16.9 stable firmware: stack and RADIUS related fixes along with MS120 and MS425 fixes

[cmr]

Switch firmware versions MS 16.9 changelog

Ms12x important notes

• If DAI is enabled prior to upgrading the network to MS 16, ensure that trusted ports and/or DAI-allow lists are configured prior to upgrading to avoid potential network outages.

Ms420 important notes

• Devices configured for this version will run MS 15.22

New feature highlights

• ACL hit counter
• DHCPv6 and IPv6 RA guard
• Local Status Page Packet Capture

New ms12x feature highlights

• DAI support

General fixed issues

• Fixed an issue causing some switches in stack configurations to incorrectly report "MAC Table Full" errors
• Fixed an issue that caused multicast routing to fail on switches in stack configurations after disruptions to link aggregation
• Fixed an issue that prevented some switches in stack configurations from successfully routing multicast traffic
• Resolved an issue that caused some switches in stack configurations to use an incorrect STP bridge priority value after reboots
• Resolved an issue that occasionally caused RADIUS authentication failures when clients were authenticated immediately after a reboot
• Resolved an issue that sometimes caused clients to be incorrectly added to a configured Guest VLAN when authenticated via RADIUS immediately after a reboot

Ms12x/130 fixed issues

• Fixed an issue causing management/control plane failures

Ms425 fixed issues

• Fixed an issue that prevented the addition of multicast MAC entries in switches configured to use cross-stack LAGs

General known issues

• RADIUS communications may not recover after an initial failure when Critical Auth is enabled
• Stack port configurations may become isolated or changed upon multiple flaps or when disabled
• Switches move LACP ports to an active forwarding state if configured. This can cause loops when connecting to an MS390 or other Catalyst switches unless the bundles are configured on the MS390/Catalyst switches first. All non-catalyst ports are configured in passive LACP mode so that loops do not occur between Meraki switches (always present)

Ms120 known issues

• Switches may fail to provide PoE power to legacy access points (always present)

Ms12x known issues] ms120/125s may fail to forward link-local multicast [224.0.0.x

• traffic when 'Flood unknown multicast traffic' is disabled

Ms210 known issues

• Stack ports have an orange LED instead of green (present since MS 11)

Ms250 known issues

• Interruptions to aggregate links initiated by restarts or reconnection may produce unexpected LACP discarding states

Ms2xx/35x/4xx known issues

• 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 known issues

• Enabling Auto-stacking on MS350s may remove existing L3 SVIs

Ms35x known issues

• In rare instances, stack ports fail to initialize after an upgrade (always present)
• Incorrect SFP port mappings may disrupt SFP functionality
• Switches may experience an unexpected reboot (present since MS 15)
• 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.

Ms425 known issues

• MS425 stacks may become unresponsive under high load
• MS425s in stack configurations may periodically trigger New DHCP Server alerts that include mismatched VLANs/subnets

Ms4xx known issues

• When an SFP module is inserted/removed, BPDUs can be delayed leading to STP transitions in the network (predates MS 12)

[CoreyDavoll1]

Pushed it to a site last night that was getting hit with the management/control plane failures.  Hopefully this actually fixes it.

[Giuseppe_A]

Hi, will this issue be ever resolved?

Ms2xx/35x/4xx known issues: 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

If not, is there a workaround to resolve or at least silence this type of alert?