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
If my answer solves your problem please click Accept as Solution so others can benefit from it.
35 Replies 35
Mloraditch
A model citizen

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 🤞

If my answer solves your problem please click Accept as Solution so others can benefit from it.
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
Mloraditch
A model citizen

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.

bigben386
Getting noticed

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

Mloraditch
A model citizen

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

scytales
Conversationalist

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 😁

bigben386
Getting noticed

Definitely if you use 802.1x!

Mloraditch
A model citizen

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.

If my answer solves your problem please click Accept as Solution so others can benefit from it.
bmarms
Getting noticed

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

 

MS250 14.32 access policy - The Meraki Community

bmarms
Getting noticed

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?

Mloraditch
A model citizen

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

bigben386
Getting noticed

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

bigben386
Getting noticed

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
bigben386
Getting noticed

Hey @KRobert ,

 

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

KRobert
Head in the Cloud

Hi @bigben386 , any update from support yet? 

CMNO, CCNA R+S
bigben386
Getting noticed

No update. I haven't really pushed it since 14.27 is working fine for us.

bmarms
Getting noticed

here's my issue after an upgrade to 14.32:

 

MS250 14.32 access policy - The Meraki Community

bmarms
Getting noticed

Meraki was able to identify that STP being disabled on ports was causing the 802.1x issue as the switch was not able to maintain an accurate mac table.  I enabled STP on all ports where it was disabled and upgraded switches to 14.32 and am having no issues.  Dev is reviewing the access policy not working on STP disabled ports in 14.32 as its no an expected behavior

bigben386
Getting noticed

We run STP on all our access ports and had issue on the voice vlan with 14.32. I would recommend anyone doing 802.1x on their voice vlan to still stay on 14.27.

KRobert
Head in the Cloud

Is there any warning "update before x date" on the firmware page for 14.27? I have my networks on 12.28.1 and 14.27 isn't an option so I'll have to work with support on that. If there is a warning status date, what is it?

CMNO, CCNA R+S
bigben386
Getting noticed

No warnings on our firmware page

bigben386_0-1638376927943.png

 

KRobert
Head in the Cloud

Hi @bigben386, Can you confirm that 14.27 is still showing "good" in the firmware status?

CMNO, CCNA R+S
mcvosi
Getting noticed

Yep.

3CB89334-7233-4F12-976D-D2EE2C581863.jpeg

bigben386
Getting noticed

I just saw 14.33 pop up in the stable rc channel. It says:

Bug fixes

  • The Voice VLAN fails to stay authenticated if it is authenticated before the Data VLAN (present since 14.28)

Going to give it a go on our beta site.

KRobert
Head in the Cloud

Hi @bigben386. How have the results been? 

CMNO, CCNA R+S
bigben386
Getting noticed

So far everything has been working fine on our PCs connected through the voip phones. We haven't had too many people in our beta office so far this week though.

bigben386
Getting noticed

We updated a larger batch of sites over the weekend. We have not had any issues with our voip phones authenticating after the update.

KRobert
Head in the Cloud

Great to hear @bigben386 ! Of course they  push this version out right after I manually call in to support and update all of my switches to 14.27 😑

CMNO, CCNA R+S
mcvosi
Getting noticed

Running into similar issue with 802.1x and voice VLANs and 14.32. Just opened a case...

 

KRobert
Head in the Cloud

I just saw this Bug Fix with 14.33. Let me know if anyone has any luck with it resolving the voice VLAN authentication issues. @bigben386 

KRobert_0-1643985497969.png

 

CMNO, CCNA R+S
Get notified when there are additional replies to this discussion.