- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
MS 12.29 release available
Finally fixes ARP entry timing out when still in use:
Switch firmware versions MS 12.29 changelog
Alerts
- MS210/225/250 switches cannot forward IPv6 Router Advertisement and Neighbor Solicitation packets when flood unknown multicast is disabled (has always been true)
- MS390 upgrades from MS 12.28 or later will result in minimal impact to client traffic
- MS390 client authentication may fail closed if RADIUS server passes unsupported AVPs
- Auth session state on RADIUS server may be stale following an MS390 CoA update until RADIUS Accounting is supported
Additions
- Support for MS390 Series Switches
- Loop Detection on MS210/225/250/350/355/410/420/425/450 series switches
- MAC Flap Detection on MS210/225/250/350/355/410/420/425/450 series switches
- MS390 Local Status Page identifies ports on other stack members by name instead of MAC address
- Features now supported on MS390: RADIUS Testing, RADIUS CoA
Bug fixes
- ARP entry on L3 switch can expire despite still being in use (predates MS 10.x)
- Editing properties of an existing L3 interface on MS390 switches don't take effect without a reboot
- Certain egress protocol packets missing from switch port packet captures
- Stack member switches might fail to forward multicast stream out ports with known receivers
- Changing configurations of various port settings on MS390 switches can result in the port not successfully participating in a configured LAG
- Ports configured for Access mode on MS390s can incur a 30sec delay before they forward traffic
Known issues
- Routing to a particular next-hop can fail under specific conditions for non-MS390 switch stacks
- MS390 stack members may not report client-level detail
- MS390 series switches Max MTU is limited to 9198 bytes
- MS390 series switches will not display packet details in the DHCP Servers page
- MS390 series switches do not support the 'next-server' or 'bootfile' parameters in DHCP messages
- Rebooting a single switch in an MS390 stack will reboot the entire stack
- LLDP frames from MS390 series switches will use a single system name instead of the Dashboard given name
- MS390 series switches will not display the advertising router ID for OSPF
- MS390 series switches with OSPF enabled will default to an IP MTU of 1500 bytes on every OSPF enabled interface
- MS390 series switches do not support the multicast routing livetool
- MS390 series switches do not support tagged traffic bypass for voice on ports with a Multi-Auth access policy
- Dynamic VLAN assignment from a RADIUS server on MS390 series switches must already be an allowed VLAN on the port for it to function
- MS390 series switches may not display link state on links at mGig speeds (2.5G, 5G)
- MS390 series switches do not currently support the following features: VRRP, SM Sentry, Syslog server, SNMP, Traceroute, IPv6 connectivity to dashboard, Meraki Auth, URL Redirection, MAC Whitelisting, RADIUS Accounting, QoS, Power Supply State, PoE power status/usage, Loop Detection, UDLD, MAC Flap Detection
- SM Sentry does not support Windows based clients (predates MS 10.x)
- MS425 series switches do not forward frames larger than 9416 bytes (predates MS 10.x)
- MS350-24X and MS355 series switches do not negotiate UPoE over LLDP correctly (predates MS 10.x)
Other
- Various performance and stability improvements
Solved! Go to solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Tested with 9800s & MS425... no CAPWAP drops since upgrade!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Finally:
BUG FIXES
- ARP entry on L3 switch can expire despite still being in use (predates MS 10.x
That one was knocking out a clients Wifi network on a legacy Cisco WLC cluster
https://www.linkedin.com/in/darrenoconnor/
I'm not an employee of Cisco/Meraki. My posts are based on Meraki best practice and what has worked for me in the field.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Installed on a single MS210-48P and a MS120-8P this morning, no issues so far...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Could you place a Cisco WLC on your network and let me know if it kills the wifi every 24 hours
https://www.linkedin.com/in/darrenoconnor/
I'm not an employee of Cisco/Meraki. My posts are based on Meraki best practice and what has worked for me in the field.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think the WLCs have all gone to the tip WEEE recycling agent now... 🤣
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Tested with 9800s & MS425... no CAPWAP drops since upgrade!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Fastburner was that to 12.29 or 12.30?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12.29. Haven't upgraded to 12.30. I'm sure Meraki support will upgrade to 12.29 if you phone in.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
finally !
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What issue were you hitting @sebas ?
https://www.linkedin.com/in/darrenoconnor/
I'm not an employee of Cisco/Meraki. My posts are based on Meraki best practice and what has worked for me in the field.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We use a MS250 stack with MS250 access switches.
The stack is connected to a pair of ASR routers and a HA pair of MX's.
It was a long time ago, but we had some strange issues when on a occasion switches rebooted cause of a power failure. The stack remained up due to a connected UPS but the clients could not get connectivity once the access switches finished booting,
Can't give the details anymore but i remember support pointing out to this issue.
So we've stayed at 10.45.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
and removed again... because of issues or 12.30 ?
Because when i check the release notes of 12.30 the fixes of 12.29 are not displayed ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12.29 and 12.30 are removed..
beta only shows 14 now
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@sebas in Meraki world there is always* only one stable firmware version, up to one stable release candidate and one beta. Hence with 14.5 arriving as beta and neither 12.29 not 12.30 having been popular enough to make it to stable release candidate, they both disappear.
* If there are different currently supported hardware models that do not all support the same firmware train then you may see two in one section. A current case in point is the MR firmware where 802.11ac wave 2 and newer devices use 27.x, whereas older devices use 26.x
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
tnx for the explanation.
I do find this hard to accept, i want to run stable only and 12.30 contained the fix we wanted.
New versions with features always contain bugs and now we have to wait longer until we get a stable version with the fix we want.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@sebas speak to support, they should be able to install one of those versions for you.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi all,
Does anyone know if Loop detection and MAC Flap Detection only detects (and log, does it log this events, right ?) or can also mitigate/prevent such actions ?
Thank you
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content