New MS 17.1.3 stable release candidate: fixes MS210 stack port LED colour and a lot more!!

cmr
Kind of a big deal
Kind of a big deal

New MS 17.1.3 stable release candidate: fixes MS210 stack port LED colour and a lot more!!

Switch firmware versions MS 17.1.3 changelog

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 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

  • DOM (Digital Optical Monitoring)
  • Intelligent Capture
  • RSPAN and VLAN Based SPAN
  • SmartPorts

New ms130x feature highlights

  • Adaptive Policy on MS130X/R models

General fixed issues

  • Fixed a bug that caused some 802.3af devices to display as 802.3at in Switch Port Details
  • Fixed a bug that caused switches to forward some RADIUS requests that included an invalid source MAC address
  • Fixed an issue that caused boot loops when attempting to upgrade to MS17 while using an externally calibrated third party SFP
  • Fixed an issue that caused clients to get stuck in an auth_pending status until the switch port the client was connected to was bounced

Stacking fixed issues

  • Fixed a cross-stack port mirroring bug that incorrectly showed CDP/LLDP traffic from the source port as being connected to other members of the stack
  • Fixed an issue that caused switch stacks to learn MAC addresses from ports in the STP blocking state, triggering MAC flap messages in the event log
  • Resolved an issue that prevented an active stack member from managing STP state on other stack members after the active member rebooted
  • Resolved an issue that sometimes prevented stack ports from being correctly reconfigured after stack link flaps

Ms130 fixed issues

  • Resolved a bug that caused some MS130s to stop reporting to Dashboard while upstream switches reported UDLD issues

Ms210 fixed issues

  • Fixed a bug that caused MS210 stack port LEDs to incorrectly indicate an orange light rather than the expected green

Ms220 fixed issues

  • Fixed an issue that caused the packet capture files generated by the Local Status Page to be empty

Ms355 fixed issues

  • Fixed a bug that occasionally caused some MS355 switches to reboot

Ms425 fixed issues

  • Fixed a bug that caused high device utilization on MS425 stacks when multicast routing was enabled
  • Resolved an issue that caused pNIC errors when forwarding some LLC packets

General known issues

  • If voice and data are configured to use the same VLAN DHCP discovery messages may not be correctly forwarded from client devices after being authenticated via 802.1x on the voice VLAN
  • LACP links may take an extended time to come back up when the Active Member of a stack reboots
  • 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
  • Some switches may encounter an error, "incompatible configuration for attributes: allowed_vlans" when attempting to aggregate ports regardless of allowed VLANs configured in Dashboard
  • 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

  • Some client devices may fail to authenticate via MAB in an access policy with hybrid authentication enabled, resulting in 802.1X authentication failures
  • 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

Ms130 known issues

  • MS130-X switches may experience slow upstream throughput when connected directly to an MX device via an mGig port

Ms250 known issues

  • Switchport with Multi-Domain Hybrid auth access policy randomly goes into a port not forwarding state

Ms350 known issues

  • Cable tests may fail to execute on mGig ports
  • 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)

Ms425 known issues

  • In rare circumstances MS425 switches may encounter a software crash that results in a reboot
  • In some circumstances ARP requests may not be correctly forwarded after connectivity is restored following an inter-DC VPLS DCI outage
  • 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)
If my answer solves your problem please click Accept as Solution so others can benefit from it.
3 Replies 3
thomasthomsen
Kind of a big deal

Fingers crossed if I can now get Smart Port Automation to configure a trunk port correctly to an AP.

Not on the bug fix list, but one can hope.

Will test later.

RaphaelL
Kind of a big deal
Kind of a big deal

General known issues

  • If voice and data are configured to use the same VLAN DHCP discovery messages may not be correctly forwarded from client devices after being authenticated via 802.1x on the voice VLAN

I don't understand this one. This was introduced in MS 15 and Meraki told us they won't fix it. Then why is it a known issue.

cmr
Kind of a big deal
Kind of a big deal

It does seem odd to introduce an issue!  Does it occur when you have a device that doesn't announce itself as a voice device (perhaps an ATA or similar), but you know it is, so you set the data VLAN on that port to be the same as the voice VLAN to ensure that it gets the correct IP address?

If my answer solves your problem please click Accept as Solution so others can benefit from it.
Get notified when there are additional replies to this discussion.