New MS 14.31 stable release - MS 12 no longer a current release train

cmr
Kind of a big deal
Kind of a big deal

New MS 14.31 stable release - MS 12 no longer a current release train

Switch firmware versions MS 14.31 changelog

Alerts

  • MS390 upgrades from MS 14.29 or later will result in minimal impact to client traffic
  • Clients on a RADIUS authenticated port that ages out of the MAC table due to inactivity will fail to be relearned until a port bounce has occurred (present since MS 14.28)
  • Voice VLAN clients cannot pass traffic on ports that have MAC allowlists enabled (present since MS 14.28)

Branch additions

  • Syslog support for MS390 series switches
  • 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
  • NAC enhancements for MS120/125/210/225/250/350/355/425/450 series switches
  • Critical/failed auth VLAN support for MS120/125/210/225/250/350/355/425/450 series switches

Bug fixes

  • Modifying SVIs on switches could cause the next-hop VLAN to be incorrectly set; which would result in routing outages

Known issues

  • Clients on a RADIUS authenticated port that ages out of the MAC table due to inactivity will fail to be relearned until a port bounce has occurred (present since MS 14.28)
  • In rare instances, DAI inspection may fail to snoop DHCP transactions on stacks leading to those clients being in a blocked state
  • Voice VLAN clients cannot pass traffic on ports that have MAC allowlists enabled (present since MS 14.28)
  • If a combined network has Umbrella integration, changes cannot be made to the group policy page (present since MS 14.5)
  • In rare instances, a stack member may go offline until rebooted (present since MS 12)
  • In rare instances, non-390 stack members will reboot (present since 12.29+)
  • Clients connected to a trunk port on the native VLAN will show "native" for the VLAN information rather than the native VLAN ID.
  • Networks containing a large number of switches may encounter issues saving changes on the Switch Settings page
  • Stack members are not being marked to update their configuration when changes are made on other members
  • 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
  • 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)

MS120

  • MS120s may show PoE usage on the incorrect port
  • MS120s on rare occasions will reboot (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
  • 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)

MS35X

  • Enabling Combined Power on MS350/355 switches results in events being logged once per minute (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.

MS390

  • Packet loss is observed when pinging the MS390 management IP
  • Stackpower is not enabled on MS390s by default
  • MS390 ports are limited to the lowest link speed since boot if QoS is enabled
  • MS390s may experience a brief 1-2 minute control plane outage. The data plane will not experience issues during this time.
  • MS390 - Port Up/Down Events Shown Across All Members
  • 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
20 REPLIES 20
Mloraditch
Getting noticed

I like your model breakdown of the bugs. Maybe someone smart at Meraki will start doing that!! You do have the second to last MS390 bug listed wrong. Its a 355 bug.

 

This is a fun one when you are in the middle of an ISE Rollout: 

  • Clients on a RADIUS authenticated port that ages out of the MAC table due to inactivity will fail to be relearned until a port bounce has occurred (present since MS 14.28)

At least it's identified now.

cmr
Kind of a big deal
Kind of a big deal

Oops missed that one, as you say, hopefully they'll be sorted at source soon 🤞

bigben386
Getting noticed

I would definitely recommend anyone running 802.1x not upgrade to this version due to

  • Clients on a RADIUS authenticated port that ages out of the MAC table due to inactivity will fail to be relearned until a port bounce has occurred (present since MS 14.28)

That is killing us. Phones and printers are becoming unreachable due to this and it only takes a few minutes of inactivity for them to age out. Very frustrating.

KRobert
Head in the Cloud

Has anyone opened a case about this? Any update on when this will be resolved?
CMNO, CCNA R+S

I have an open case. No eta yet but I got asked for more info yesterday and told:

"we have identified some backend issues for this firmware that are likely causing this behavior."

Haven't provided the additional info yet or been able to talk to the tech.

Luckily support was able to roll us back to 14.27 and all our issues went away.

Talked to tech today, he indicated the next stable release was the goal. Didn't give a timeline.

I get the feeling i should delay my upgrade to 14.31 from 12.28.1 set for tonight... 

 

Edit: 

They really should move that bullet point up to the top. This could be very bad for those of us with decent sized ISE deployments. Thankfully,  i came here prior to following through 😁

Definitely if you use 802.1x!

It appears 14.32 is becoming available with the relevant fix. Just got a push notice for it for a client. It’s not showing up in all my orgs yet but I think that can be a propagation delay.

 

 

cmr
Kind of a big deal
Kind of a big deal

I've just pushed the upgrade to the switches where the PoE was on the wrong ports, I'll repost here once applied with the result.

14.32 doesn't fix the 802.1x problem.  here's my issue after that upgrade:

 

MS250 14.32 access policy - The Meraki Community

agreed.  I'm having this issue which isn't due to a mac age out and nothing resolves the problem.  I either have to remove the access policy or disconnect ethernet and move user's to WiFi

 

MS250 14.32 access policy - The Meraki Community

bigben386
Getting noticed

Any 802.1x users tried 14.32 yet?

We have and despite the various bug descriptions, the 802.1x bug we have with voice vlan clients is NOT fixed in 14.32

@Mloraditch We just tried it too and we are also having issues with the voice vlan. The bug mentions mac whitelist but we are not doing that. We use 802.1x for voice vlan authentication. Are you doing similar? And do you have a ticket open with them?

I have opened a ticket with meraki about this. Looks like 14.32 fixed the issue for the data vlan but our phones on the voice vlan are disappearing from the switch's mac tables just like data vlan devices did in 14.31. Rolling back to 14.27 again!

KRobert
Head in the Cloud

Thanks @bigben386. It is good to know this information, especially since the bug fix notes point out this has been resolved in 14.32. Keep us posted on your case.
CMNO, CCNA R+S

Hey @KRobert ,

 

Just got confirmation it is a known issue. Support recommended sticking to 14.27.

bmarms
Here to help

here's my issue after an upgrade to 14.32:

 

MS250 14.32 access policy - The Meraki Community

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