MS 17.1.2 Released and Pushed to RC

[Mloraditch]

General important notes

• MS17 introduces a change to the default login credentials for the device local status page, using "admin" as the username, and the device serial number (upper case with dashes) as the password

Ms12x important notes

• If DAI is enabled prior to upgrading the network to MS 17, 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

• DOM (Digital Optical Monitoring)
• Intelligent Capture
• SmartPorts

New ms130x feature highlights

• Adaptive Policy on MS130X/R models

General fixed issues

• Addressed an issue where Access-Reject did not immediately remove previously authenticated clients from authentication tables
• Fixed an error where Local Status Page packet captures for a duration of 5 minutes displayed an "Invalid timeout given" error message
• Fixed an issue where interruptions to aggregate links initiated by restarts or reconnection produced unexpected LACP discarding states
• Fixed an issue where port isolation was not working between aggregate groups
• Resolved an issue where multicast traffic wasn't properly forwarded between switches in stack configurations when the source and receiver were in different VLANs or different stacks

Ms130 fixed issues

• Corrected an issue where some MS130 switches experienced management plane congestion that resulted in UDLD alerts and STP transitions
• Fixed a problem where port mirroring failed to mirror traffic after a switch reboot
• Resolved an issue where disabling a switch port could incorrectly disable another peer port

Ms210 fixed issues

• Corrected a situation where Cisco RPS2300 continued to provide backup power to MS210 after the AC main power was restored

Ms355 fixed issues

• Fixed an issue that sometimes caused MS355 ports to be incorrectly set to half-duplex via the Local Status Page

General known issues

• RADIUS communications may not recover after an initial failure when Critical Auth is enabled
• Some clients may be incorrectly added to a configured Guest VLAN when authenticated via RADIUS immediately after a switch reboot
• 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 not forwarding 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)

Ms220 known issues

• Local status page packet captures may generate a blank packet capture file on MS220 switches

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

• Cable tests may fail to execute on mGig ports

Ms35x known issues

• Enabling Auto-stacking on MS350s may remove existing L3 SVIs
• 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)
• 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 does not see traffic from trunk link for certain VLAN
• MS425 switches in stack configurations may experience high device utilization when multicast routing is enabled
• 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)

[RaphaelL]

Faster than the bot ...! 

[Mloraditch]

Right screen, right time 😂

[thomasthomsen]

SmartPorts Automation with Trunk ports as the Smart port profile still does not work.

The SmartPorts Automation selects the right SmartPort profile but the trunk config of the SmartPort profile does not work.

When applied manually (the same SmartPort profile) everything works.

I gave up on the support case, but I cannot be the only one in the world with this problem.

[thomasthomsen]

Just wiped the config and tried all over.

Still the same. 

The Automation selects the right port-profile, but the trunk port-profile only allows traffic on its native vlan, all other vlans are blocked somehow.

And again, the fun thing is that the mac-address table of the switch actually tells you that there is a client in the (in this case) tagged vlan 10 on that port, but no traffic.

A packet capture on that Automated port, actually captures incomming packets tagged with the VLAN , but there is never any reply from the network.

*sigh*

[thomasthomsen]

PS: This was done on a MS130-12X, perhaps it works on other platforms ?

[PhilipDAth]

>using "admin" as the username,

All Meraki devices should strive to be the same.  I don't think it is good when just one family member does something different to all the other family members.

[sebas]

An still the "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" that has been there for ages ???