New MS 17.2.2 Firmware - Many Fixes/Known Issues

[Mloraditch]

Ms12x important notes

• MS 16 introduced DAI on MS100 series platforms. If you are upgrading to a current release from MS 15 or earlier please ensure trusted ports and/or DAI-allow lists are configured prior to upgrading.

New feature highlights

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

New ms130x feature highlights

• Adaptive Policy on MS130X/R models

New ms150 feature highlights

• Static routing on all MS150 models

General fixed issues

• 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
• Fixed a bug that caused an unexpected LACP discarding state when connected to third party firewalls
• Resolved an issue that sometimes prevented communication between VLANs on switches in stack configurations
• Resolved a bug that caused the Ping tool in the Client details page to fail to display data on Dashboard for wired clients
• Resolved a bug that occasionally caused switches in stack configurations to crash and reboot

Ms120 fixed issues

• Resolved an issue that sometimes caused MS120 switches to unexpectedly reboot after upgrading to MS 17.2.1

Ms130 fixed issues

• Fixed a bug that sometimes caused switches to fail to deliver PoE, and could cause all ports to display as disconnected in Dashboard

Ms220 fixed issues

• Resolved an issue that caused MS220 switches to reboot after updating to MS 17

Ms355 fixed issues

• Fixed a bug that sometimes caused SFP ports to fail to connect after a firmware upgrade
• Resolved a bug that sometimes caused a stack member to go offline when a stacking cable was disconnected and reconnected

Ms425 fixed issues

• Resolved a bug that occasionally caused MS425 switches in stack configurations to unexpectedly reboot
• Fixed a bug that sometimes caused fail to collect reporting data on all SFP ports, or to only report data on port 1

General known issues

• Clients authenticating via 802.1X with an access policy using hybrid authentication may not correctly log their RADIUS sessions
• Clients that fail to pass RADIUS authentication and are connected to ports using access policies may get stuck in an authentication loop, possibly resulting in a switch reboot
• In rare circumstances switches may experience uplink instability when IPv6 link-local addresses are enabled. If this issue is encountered it can be resolved by enabling IPv6 RA Guard to block ICMPv6 neighbor discovery messages.
• LACP links may take an extended time to come back up when the Active Member of a stack reboots
• Some switches may encounter an error, "incompatible configuration for attributes: allowed_vlans" when attempting to aggregate ports regardless of allowed VLANs configured in Dashboard
• On MS250 and MS350 switches, MAC addresses learned via AGGR are not removed when LAG ports are disabled. Mac addresses will be removed correctly within 5 minutes of reenabling LAG ports.

Ms120 known issues

• Switches may fail to provide PoE power to legacy access points (always present)
• Cable tests may report incorrect cable lengths

Ms220 known issues

• Client devices connected to ports 24-48 on MS220-48LP switches may have their DHCP offers and ARP replies erroneously dropped

Ms225 known issues

• MS225 switches may infrequently stop forwarding client traffic until the switch is rebooted
• In rare circumstances, switches in stack configurations may experience a software crash that results in a reboot

Ms250 known issues

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

Ms350x known issues

• Switches may experience an unexpected reboot (present since MS 15)

Ms355 known issues

• In rare instances, stack ports fail to initialize after an upgrade (always present)

Ms410 known issues

• Some MS410 switches may encounter alerts for fan failures that will eventually self-resolve

Ms425 known issues

• Frequent notifications about new DHCP servers that have mismatched VLANs/subnets
• In rare circumstances MS425 switches may encounter a software crash that results in a reboot
• Powering off the active switch in a MS425 stack may result in up to 5 minutes of downtime while the stack reconverges
• Switches in stack configurations may experience high CPU utilization in multicast scenarios that may result in network instability

Other

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

[cmr]

The big question is does it support MS220s, it looks like it might...

[cmr]

Unfortunately I think it does not, they just forgot to mention it in the release notes...

[cmr]

Upgrading to 17.2.2 didn't reboot the MS220-8ps in the target network, it simply went from upgrading to not running configured version.  However rolling back did reboot them, which is different behaviour to when I tried 17.2.1 where there were no reboots...

[JacekJ]

Reliability and quality of the release notes are always hitting me.

I always read the comments from you guys and don't trust the release notes fully, things disappearing between releases without an word of explanation, wouldn't be the first time.

[jbright]

The DHCP/ARP problems with the MS220-48LP switches persist.

These are still good switches that have to remain on MS16.x firmware.

[Brash]

Still not liking these ones... 😶

Ms225 known issues

• MS225 switches may infrequently stop forwarding client traffic until the switch is rebooted
• In rare circumstances, switches in stack configurations may experience a software crash that results in a reboot

[harmankardon]

Does anyone know if this is a new issue introduced by 17.2.2 or is it a known issue that is now just being documented/published? Have some MS225 switch stacks still on MS 16.9 that I'm hesitant to upgrade because of this.

[RSU21it]

I spoke to tech support a few weeks ago and asked this exact question as I mostly have MS225 switches and was told that these known issues were not introduced by 17.2.x but existed 16.x.

Having said that, I am also hesitant to upgrade to 17.2.2 and remain on 16.9 because it has been very stable in my environment. 

I would love to hear from other MS225 users that have upgraded to 17.2.2.

[Brash]

I have 30 odd sites with MS225's now upgraded to 17.2.2 and so far, so good.

I'm guessing (and hopeful) that they are niche issues that requires some specific circumstances to hit.

[RSU21it]

Thanks for replying!  Yeah, my strong impression was that these are niche issues but wasn't given the specific conditions when I called in about it.

[Miroslav_Novak]

Previous firmware MS 17.2.1.1. reporter this known issues

 

MS150 known issues

• Client MAC addresses changing physical ports may cause a flood of unknown unicast packets to the source port on MS150-48 switches

New firmware MS 17.2.2 lost any information about this problem. Is it solved, or no?

[nlev]

Interestingly my MS320 switches seem to have been able to upgrade to 17.2.2 even though they were not able to run 17.2.1 

I assumed 17.1.4 was the last version for MS320 but it looks like 17.2.2 put some more life back in them just in time for me to replace them anyway.

[cmr]

That's interesting, I tried on MS220-8P switches and they didn't seem to upgrade...

[nlev]

Is anyone able to packet capture on MS320 or MS220 running 17.2.2?  I get the following errors but it works on MS425.

Capture failed: 500.

Unknown

Capture failed: 507.

Net::ReadTimeout with #TCPSocket:(closed)

[Crocker]

Had a few issues with a few MS120's after upgrading from MS16.9 to MS17.2.2 this past weekend. 34 networks upgraded total, 2 of them had issues (so far).

At one site, the 17.2.2 upgrade broke the downlinks between the main MS120 and a couple closet MS120's. Downlinks to the closet switches are 1gbps fiber connections on ports 49/50, using 10gtek 1gbps MMF SFP's. Worked just fine before the upgrade, broke after the upgrade. The error condition was odd - Ports 49/50 on the primary switch showed green/connected at 1gbps. No DOM info available, though. No downstream clients seen. Rebooting all 3 switches didn't help anything. Disconnecting the fibers and re-seating the SFP's on both ends didn't help. Weirdly, packet captures saw 0 packets at all even on 5 minute captures, though the switchport packet counters were incrementing (though very, very small increments). Rolled back to 16.9, all is well.

Another, smaller site (with a single MS120) had similar problems, but on the copper switchports. Seemingly random downstream devices (IP phones/workstations) had 0 network connectivity even though ports showed green/connected at 1gbps. No downstream client available on the problematic ports. Packet counters incrementing very, very slightly, but no packets captured over 5 minute packet captures (when it didn't throw a 500 error partway through the capture). Also saw DHCP failures on SSID's broadcasted by MR33's connected to the switch, but haven't dug too deep. Gonna roll this one back to MS16.9 tonight.

Contacted support for both issues, but haven't gotten anywhere yet.