New MS 17.1.1 beta firmware: multicast, LACP, 802.11bt and more fixes!

cmr
Kind of a big deal
Kind of a big deal

New MS 17.1.1 beta firmware: multicast, LACP, 802.11bt and more fixes!

Switch firmware versions MS 17.1.1 changelog

Ms12x important notes

  • If DAI is enabled prior to upgrading the network to MS 16, ensure that trusted ports and/or DAI-allow lists are configured prior to upgrading to avoid potential network outages.

Ms420 important notes

  • Devices configured for this version will run MS 15.22

New feature highlights

  • DOM (Digital Optical Monitoring)
  • Intelligent Capture
  • RSPAN and VLAN Based SPAN
  • SmartPorts

New ms130x feature highlights

  • Adaptive Policy on MS130X/R models

Fixed issues

  • Fixed an issue that caused multicast routing to fail on switches in stack configurations after disruptions to link aggregation
  • Fixed an issue that caused unexpected LACP discarding states after aggregate links were restarted or reconnected
  • Fixed an issue that prevented MS130R switches from setting half-duplex mode on switch ports running at 10Mbps/10Mbps HDX
  • Fixed an issue that prevented some switches in stack configurations from successfully routing multicast traffic
  • Resolved an issue that prevented successful 802.3bt LLDP negotiation on MS355
  • Resolved an issue where the option to disable client uplink sampling was only functioning for the default aggregation group (AGGR/0). This feature now works correctly across all aggregation groups.

General known issues

  • RADIUS communications may not recover after an initial failure when Critical Auth is enabled
  • Stack port configurations may become isolated or changed upon multiple flaps or when disabled
  • Switches move LACP ports to an active forwarding state if configured. This can cause loops when connecting to an MS390 or other Catalyst switches unless the bundles are configured on the MS390/Catalyst switches first. All non-catalyst ports are configured in passive LACP mode so that loops do not occur between Meraki switches (always present)

Ms120 known issues

  • Switches may fail to provide PoE power to legacy access points (always present)

Ms12x known issues

  • ms120/125s may fail to forward link-local multicast [224.0.0.x] traffic when 'Flood unknown multicast traffic' is disabled

Ms130 known issues

  • In rare circumstances MS130s may experience management plane congestion that results in UDLD alerts and STP transitions

Ms210 known issues

  • Stack ports have an orange LED instead of green (present since MS 11)

Ms250 known issues

  • Multicast traffic may not be properly forwarded between switches in stack configurations when the source and receiver are either in different VLANs or different stacks

Ms2xx/35x/4xx known issues

  • Switch stacks will learn MAC addresses from ports in the STP blocking state which can trigger a constant flood of MAC flaps in the event log

Ms35x known issues

  • Enabling Auto-stacking on MS350s may remove existing L3 SVIs
  • In rare instances, stack ports fail to initialize after an upgrade (always present)
  • Incorrect SFP port mappings may disrupt SFP functionality
  • Switches may experience an unexpected reboot (present since MS 15)
  • UPoE does not negotiate over LLDP correctly (always present)
  • 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.

Ms425 known issues

  • MS425 stacks may become unresponsive under high load
  • MS425s in stack configurations may periodically trigger New DHCP Server alerts that include mismatched VLANs/subnets

Ms4xx known issues

  • When an SFP module is inserted/removed, BPDUs can be delayed leading to STP transitions in the network (predates MS 12)
If my answer solves your problem please click Accept as Solution so others can benefit from it.
30 Replies 30
thomasthomsen
Kind of a big deal

I wish they had put links to documentation of the new features in the release notes (like they have sometime done on major MR updates).

I cant seem to find the documentation of those features anywhere.

cmr
Kind of a big deal
Kind of a big deal

Hi @thomasthomsen here is something:

 

https://documentation.meraki.com/MS/Other_Topics/Digital_Optical_Monitoring

 

RSPAN and Smart ports are in this latest video and don't seem to be documented yet...

 

https://youtu.be/iXK6H6_xc9c?feature=shared

 

 

 

 

If my answer solves your problem please click Accept as Solution so others can benefit from it.
thomasthomsen
Kind of a big deal

Thanks. - I did not see the last update vid.

But Im just old fashioned, I really like ( Enjoy almost 🙂 ) documentation on released features 🙂

thomasthomsen
Kind of a big deal

I was hoping so much to actually test the new Port Profiles (them now being org. wide, and that has been a major wish from some of my customers for a while), but alas, that feature did not appear after the upgrade.

So Im guessing not everything is made public yet.

thomasthomsen
Kind of a big deal

*Sigh* the other features ( Adaptive policy on MS130X/R, Intelligent Capture and Traffic Mirroring ) are now all on the early access-page. But smartports is still strangely missing. The "most important" (*citation needed*) feature. Bugger.

PS: the "new features" page of the forums with MS17 announcements documentation to smartports points to the "old" (Jan 2024) page about Port profiles.

Did someone miss a memo ? 🙂

thomasthomsen
Kind of a big deal

Weeee ... SmartPorts are now ready in early access 🙂

A few things, just to be aware off, nothing I think is serious, or "bad", but just something you should know.

Smartports are now "org wide" 🙂 and that's fantastic.

 

It has two parts "Port-Profiles" and Automations.

 

It copies your current port-profiles here, so for example, if you have an AP portprofile on 3 networks, you will get 3 AP portprofiles in the list. You can see what network they are connected to when opening them. So, we will need a little bit of cleanup if you use port-profiles already - But that is fairly easy to do.

 

You can only use newly created Port-Profiles for automation.

And I really like the new "target" of Automation, of course if you have MANY switches in your org, it might be a little overwhelming. 

 

(PS: Uh oh ... ran into a problem. Created a automation, applied it to a couple of switchports, and those switchports says they run automation. When I returned to the Smartports Automation page, the Automation I created was gone 😕 so I can not edit it, and the switch still says those ports run automation. Good thing this was my lab 🙂 ).

(PPS - Edit. It was ME who made a mistake.

Creating the Automation, I "forgot" to press save / update in the "correct order.

I was just too excited 🙂 )

thomasthomsen
Kind of a big deal

Do anyone know if the API has been updated, so you can create Port-portfiles on the org. level ?

thomasthomsen
Kind of a big deal

And another important question.

What is the scale ? aka. How many Automations can I create, and how many "trigger actions" can we have pr. Automation.

Do anyone know ?

thomasthomsen
Kind of a big deal

I now "already" have a "wish" ....  for a "convert to org. wide" for a network specific port-profile when enabling this feature. 🙂

 

 

 

thomasthomsen
Kind of a big deal

And equally important ... the documentation is also ready : https://documentation.meraki.com/MS/Port_and_VLAN_Configuration/SmartPorts

thomasthomsen
Kind of a big deal

Hmmmm perhaps the wording here could be changed a bit.

From documentation : 


"An automation is a sequence of rules, each of which is a collection of one or more match conditions. Match conditions in a rule operate as a logical AND. That is, all conditions in rule should match for the rule to be considered a match. For this reason, a match type can be used only once per rule. For example, multiple match conditions for LLDP system description cannot be added in a single rule. If multiple LLDP system description values, they should be entered as comma-separated values in the match criteria instead. Values provided in the match criteria operate as a logical OR, which means that any one of them being matched will be sufficient for the condition to be considered a match"

 

In the UI it is called "Match Type" and "Match criteria".

So ... would these two Automations do the same thing ? Or would one of these not work ? (see attached picture).

(Simply trying to apply a port-profile to an MR or CW AP)

 

thomasthomsen_0-1721898734437.pngthomasthomsen_1-1721898753029.png

 

thomasthomsen
Kind of a big deal

My answer is yes, they will do "the same thing". But the wording of the documentation should perhaps be changed from "Match conditions" to "Match criteria" in order to reflect the UI. (or the other way around).

 

And "single rule" to "single criteria" ? ehh ... ??

thomasthomsen
Kind of a big deal

Hmmmm ... I have now tested a Automation based on  LLDP criteria for APs, and a Automation based on MAC criteria for some IP cameras.

Neither of them works 😕

The port has been configured with the correct SmartPort Automation , but the "Port-Profile" (I guess we now have to call these SmartPort profile) is never applied.

thomasthomsen
Kind of a big deal

Have anyone gotten it to work ?

Or is this just me being too early, and/or too hyped and excited for this feature before anyone else ? 🙂 

 

PS: I also tried to reboot my switch, it did not change anything. Ports are not being applied a profile

thomasthomsen
Kind of a big deal

Interesting.

Whenever i set SmartPort Automation on a port (change the SmartPort Automation profile, or enable it) it actually bounces the port.

But it does still not work for me. The port stays at its original configuration.

thomasthomsen
Kind of a big deal

Hmmm perhaps it actually works....... (after making some real dummy ports as default, I think I have verified this).

But it never displays that the port has been reconfigured, aka. what SmartPort Profile has been applied.

 

thomasthomsen
Kind of a big deal

It seems to work on my accessports. - But the UI does not tell you anything.

Now testing trunk ports.

thomasthomsen
Kind of a big deal

Hmmmm trunk ports behave strangely.

I created a SmartPort Profile for an AP, native vlan 1 for the AP mgmt traffic, and vlan 10 and 30 for different clients / ssids, and a SmartPort Automation with LLDP for Meraki APs.

The default config of the switch port is a dummy vlan 999 that does not exists.

 

The AP becomes active in VLAN 1, and I can ping it, and it is online.

That would mean that the SmartPort Automation did "something(tm)".

I have no other "automations" that use a SmartPort profile for VLAN1.

So Im guessing that it has selected the right SmartPort profile.

 

BUT ... all other traffic is dropped somewhere.

The real kicker, is that the mac-address table of the switch says clients are in their correct VLANs, AND (and now it gets really funny) a packetcapture on the switchport, for that AP, can actually see packets from clients ?!?!?!?

But the clients never get a reply.

When pinging a client from the firewall, I can actually see the ICMP packet from the firewall on the port as well. But no reply from the client ?!?!?!
Changing the port to a static SmartPort profile (the same one from the automation), then everything works.

huh !??!?!

 

thomasthomsen
Kind of a big deal

So ... SmartPort Profiles Org. wide seems to work just fine. Trunk and Access.

But Automation, using the same profiles, not so much, something very strange is happening here.

thomasthomsen
Kind of a big deal

Here is a pcap on that, perhaps, automated port described above.

Filtered for the client, while i try to ping it, and the client tries to reach umbrella dns.

thomasthomsen_0-1721908851373.png

All packets are there, but no reply in either direction.

As mentioned the default port config here is access vlan 999 that does not exists.

So since the MAC address i clearly in the switches table, and the AP is online in its proper vlan (and works), the port has been changed. But the switch seems to throw away the packets at the edge for the other vlans on that trunk ?!?!?!

thomasthomsen
Kind of a big deal

I give up, this is too strange.

I know its "unfair" but I created a case.

thomasthomsen
Kind of a big deal

And I just realised that you cannot create a SmartPort Profile that uses dot1x 😕

So long for global org wide dot1x Port-Profiles - I guess its a question about the Access-policy being network specific at this point in time. The org. wide SmartPort Profile does of course not "know" all the Access-policies configured on each network.

I guess org. wide Access-policy is next ? I mean, we have org. wide Radius servers, why not org. wide access-policy.

 

.

.

.

A few seconds later, after thinking about this. So .. when converting to SmartPort Profiles, and not being able to create a new Port-Profile on a network anymore, you loose the ability to create a network Port-Profile with an access-policy period. ... uh oh ....

thomasthomsen
Kind of a big deal

Hmmm there is a workaround, but I dont know if its intentional.

So by chance, I switched networks while on the global SmartPort page, it then displayed the SmartPort Profiles for that network (network and org. wide).

When I then press create I get a "network" field on the SmartPort Profile creation pop-up thats locked to the network Im on, and there I can select the access-policy.

But ... how did I get there ? The url, when switching networks while on the org wide page switches to .... node/networkname-wireless/something/manage/switch_port_profiles ... now Im scarred.

thomasthomsen
Kind of a big deal

"Is .. is that Thomas guy ok ? - he seems to speak, write, and hum .... all to himself .... a lot" 🙂

DanielWahlsten
Getting noticed

Hope this fix whatever issues 16.9 had. Nothing visible but everything worked terrible at least. Apple HomeKit to

mention one of the things. The firmware that has been the worst ever on my count 

DanielWahlsten
Getting noticed

It seems like it did 🥳🥳

Brash
Kind of a big deal
Kind of a big deal

I'm liking these features.

I'd argue DOM should have been implemented way earlier than now but it's exciting  nonetheless.

redsector
Head in the Cloud

Still UDLD errors when connected to other switches (Meraki or Catalyst) with spanning tree and or aggregat. Helpdesk doesn´t know anything but today I had an phone call with an Cisco Meraki engineer and they know about this issue and working for an solution. How long it takes? I don´t know. 😒

thomasthomsen
Kind of a big deal

Is this a known error on 17.x or was it also there previously ? , I think I just encountered it today 😕

redsector
Head in the Cloud

No kudo for all this known issues!

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