New MS 15.2 beta firmware - lots of MS390 improvements

[cmr]

Switch firmware versions MS 15.2 changelog

Alerts

• HTTP proxy is no longer supported on MS 15+. Nodes that use HTTP proxy without any other means to connect to dashboard may fail to connect.
• MS210/225/250 series switches cannot initialize SFP modules less than 10Gbps
• SecureConnect fails on MS355 series switches
• MS390 ports are not disabled when configured to do so by dashboard
• Moving or re-provisioning an MS390 stack in dashboard can cause at least one member to stay offline until rebooted (this only affects control plane traffic).
• Enabling MS390 ports for UDLD alerting mode will cause those ports to go into an STP blocking state
• MS390 upgrades to this version will experience a full system reload

Branch additions

• Named VLAN support for MS120/125/210/225/250/350/355/390 series switches
• Netflow export for Adaptive Policy
• Multi-auth with voice VLAN bypass support
• IPv6 management interface support

MS390

• IPv6 static routing support for MS390 series switches
• Additional client analytics added for MS390 series switches
• Meraki authentication support for MS390 series switches
• Alternate Management Interface (AMI) support for MS390 series switches
• UDLD support for MS390 series switches
• Group policy ACL support for MS390 series switches
• URL redirect support for MS390 series switches
• UPoE (802.3bt) support for MS390 series switches
• Critical/failed authentication support for MS390 series switches
• MAC flap detection support for MS390 series switches
• Stack power is supported by default for MS390 series switches
• Netflow support for MS390 series switches

Bug fixes

• Stability enhancements for MS390 series switches in large L2 networks

Known issues

• In rare scenarios, changes made to SVIs may result in connectivity loss for one or more SVIs until reboot (predates MS 12)
• In rare instances, DAI inspection may fail to snoop DHCP transactions on stacks leading to those clients being in a blocked state
• Connecting a stacking cable to a stack that is online may result in a stack member going offline (present since MS 12)
• In rare instances, a stack member may go offline until rebooted (present since MS 12)
• 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)
• AMI IP addresses do not send gratuitous ARP packets which can lead to packet loss if the AMI address has aged out in the network
• Meraki authentication does not work with guest VLAN
• MS210/225/250 series switches cannot initialize SFP modules less than 10Gbps
• When an SFP module is inserted/removed on MS420/425 series switches, BPDUs can be delayed leading to STP transitions in the network (predates MS 12)

MS12X

• In rare instances, MS120 series switches may have empty packet captures until they are rebooted
• Links being established on an MS120 can result in neighboring ports to flap (present since MS 11)
• MS120s switch ports 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)
• Ports with an odd-numbered MTU value fail to initialize for MS120/125 series switches (predates MS 11)

MS35X

• 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. For example, MS355 switch ports will incorrectly show an amber light for 1G, 2.5G, and 5G, but will show a green light for 10G.
• Enabling Combined Power on MS350/355 switches results in events being logged once per minute (present since MS 11)
• MS350-24X and MS355 series switches do not negotiate UPoE over LLDP correctly (predates MS 10)
• SecureConnect fails on MS355 series switches

MS390

• 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.
• Packet loss is observed when pinging the MS390 management IP
• MS390 - Port Up/Down Events Shown Across All Members
• MS390 - StackPower Not Enabled by Default
• 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
• Rebooting any MS390 stack member via the UI will result in the entire stack rebooting
• Enabling MS390 ports for UDLD alerting mode will cause those ports to go into an STP blocking state
• Moving or re-provisioning an MS390 stack in dashboard can cause at least one member to stay offline until rebooted (this only affects control plane traffic).
• MS390 ports are not disabled when configured to do so by dashboard
• IPv6 SVIs added on dashboard do not get configured on MS390 stacks

[KarstenI]

• ---

  @cmr wrote:
  

  Branch additions

  • Named VLAN support for MS120/125/210/225/250/350/355/390 series switches

This will ease a lot of installations! Great addition.

[cmr]

Indeed, but beware of this one:

• MS210/225/250 series switches cannot initialize SFP modules less than 10Gbps

[KarstenI]

Yes, no problem for me, I don't use firmware version < x.5 or so ... 😉 And I assume that one will get fixed quite soon.

[Mloraditch]

So if anyone is brave enough to try this release, does named vlan support just mean that I can type VOICE in a vlan field instead of the number? Or will it be a dropdown selection? I guess this is just for ease of management? VLANs have to use numbers in the actual packets, as far as I'm aware.

I'm not seeing documentation yet that explains this.

[cmr]

@Mloraditch I think it will simply be an additional label you can add for ease of reading.  So far I have only applied this firmware to my home switch and as that is an MS220, this feature isn't supported by the release...

[WirelesslyWired]

This feature is for Named VLANs to VLAN ID mappings for RADIUS. We definitely do want to leverage this further down the road for more than just simplifying RADIUS deployments. Please use the feedback button at the bottom (that we for some reason renamed from make a wish) and let us know there if you wouldn't mind. 

[PhilipDAth]

I currently have spreadsheets for each customer to keep track of every VLAN.

Names are going to make life MUCH easier.

[KarstenI]

For me the "inline documentation" of the VLANs are only the secondary but definitely a welcomed benefit. The main benefit is that (well, at least I expect that this feature will work that way similar to Catalyst switches) I can send the VLAN name from the RADIUS server and the "right" VLAN gets applied regardless of the VLAN ID. Yes, having consistent VLAN-IDs would be better, but is not always possible.