You are right, but then it would mean that they have, all of the sudden, so much to do, that they can't respond to pings. @AxL1971, think you need to double check your wiring, configs and maybe open a support case if it doesn't make sense, what firmware are you on?   BTW - I'm having trouble with ping responses on MS425 since upgrading to MS15.x. At full hours (like 8:00, 13:00, 19:00) the response times to pings would rise up to 1000ms for no reason, last maybe a minute and then return back to normal. Support is on it, since over a month and they don't see anything weird in the network and are unable to replicate in their lab, despite us seeing this in multiple locations. Never had this weird thing in previous versions. ... View more

Right, my bad, when the switch lost connectivity, you will have no logs in the dashboard! Your STP config looks OK so I would check the cabling, maybe swap SFPs, patchcords to see if the issue moves along with them. ... View more

If the STP root is meant to be the Cab1/Switch9 (as you stated previously) then this is set correctly. Sure, you can modify that internet uplink port towards the Cisco router to Root Guard, if it doesn't send any STP or is sitting with the priorities on default values way higher than 4096 you will be good, this should not harm.   But to be honest, I'm still not convinced this is a STP issue, because in the initial post you wrote that the issue was between switches, not the switch and the Cisco router.   Go one step back and take a look in the logs what happened on the other side of that connection at the same time, to have the whole picture. Looking at the log you showed, it wasn't STP (on that side), it says disabled which means that the connection is simply gone (in a case of a loop you would see alternate/blocking): https://documentation.meraki.com/MS/Monitoring_and_Reporting/MS_Event_Log_Entries_and_Definitions#Port_STP_Change ... View more

Exactly what I meant above 🙂 ... View more

First of all, it really sounds like a nightmare, I really feel bad for you!   You can read over here my lengthy complaint and story about the upgrade from MS14 to MS15: https://community.meraki.com/t5/Switching/Has-anyone-had-issues-with-Stacks-and-LACP-after-going-from-14/m-p/196404/highlight/true#M13683    There we also had issues with switches being unable to upgrade because the ports were blocked. But I handled that by disabling all redundant connections (which in my case was simply disabling almost all ports on one of core switches, thanks to a rather clean cable setup), then everything regained connectivity and upgraded. Your comment below got me thinking and I will keep that in my mind during next upgrades, since I have the Loop Guard set on all ports pointing towards the core switches (stp root), and maybe that was the reason for my issues. Thanks! @SwitchedAtBirth wrote: We also did some research and found that some folks were complaining about STP Loop Guard can be known to cause issues. We found this enabled on 2 uplinks, disabled and finally, all was well. ... View more

What you will hear from the support, is that as soon as you reboot the switch, they will lose all logs inside the switch, that would be of more value than what you can see on the dashboard or via syslog. If Meraki can't find any configuration issue causing this (LACP not configured properly on both sides and so on), then to be honest, I would demand a replacement of Core1 since the issue seems to be around that device. I think I saw something like this on one MS425, the CRC errors were seen by the switch connected to it, but not on the MS425 side, ended up with replacing it if I recall correctly. ... View more

How do you capture the packets? By interfaces you mean capturing via Meraki dashboard or and the end device? This is crucial, I've seen weird things in the dashboard captures sometimes, so you should capture data on the end devices to be on the safe side and I think its what @GiacomoS is suggesting. ... View more

@JohanPlukon Been scratching my head about this one recently as well 😉 I have a setup with 2 server rooms which are meant to be redundant (so 2 internet lines, 2 servers connected in HA and so on) with 4xMS425 stacked together (2 in each server room). I was thinking about splitting them so I would have one stack per server room - avoiding issues that come with Meraki stacks with 3 or more members and also staging the core stack upgrade (which handles our L3 and internet) therefore avoiding downtime. But as you said, there is a lot of things to consider. ... View more

@JohanPlukon you could also get rid of the stacks or split them in smaller ones and then be able to update the switches/smaller stacks individually. If the used switches have no dedicated stacking ports (like MS425) then you could change the QSFP ports to classic Ethernet mode and still have the 40Gig connection between the switches. But then (and also if you split them into 2 different networks) you obviously loose some cross stack LACP benefits and would need to rely on STP... This very much depends on how you connect the end devices to the switches 😉 ... View more

I would say no, you misunderstood @DarrenOC from what I can say. Below you will find an explanation, but first lets clear something else.   I would start with saying, that the log you showed will occur if you simply unplug any cable, you will see the STP changes on ports, which is expected. Maybe there is a issue with the connection, I've seen bad SFP or even fibers misbehaving from time to time, and even sometimes switches, which you should bear in mind.   Now the Root/Loop Guard logic: As a rule of thumb, on a root switch you set all ports facing towards any other switches to Root Guard, so he will always remain root, if anything wants to take over, then it will not allow to do that and cut it off. The port facing towards the cisco router - it depends, if it has a simple setup without any vlans, stp involved (access port), then set a BPDU Guard, if not, Root Guard will be OK. Loop Guard you set up on the other side of the downstream switches that are facing towards the root switch, so basically from one side of the link you set a Root Guard and from the other side a Loop Guard. This applies also to switches that are daisy chained, so if cabinet 0 switches are connected to cabinet 2 then: on the switch in cabinet 2, on the port connecting to the switch in cabinet 0 you set a Root Guard and on the other end (from cabinet 0 perspective) you set a Loop Guard (as per the logic in the end of point 3 above) https://documentation.meraki.com/MS/Port_and_VLAN_Configuration/Configuring_Spanning_Tree_on_Meraki_Switches_(MS)#Configuring_STP_Guard_on_a_Switch_Port ... View more

If the switch doesn't know STP (or you are not sure) then I would enable BPDU Guard on that port. Setting an BPDU Guard on access ports is a good practice. ... View more

@cmr good one 😂 ... View more

Thanks for checking this out, I was very surprised by @alemabrahao saying that this applies to all MS switches since my experience was that I need to reboot all switches individually (not having MS390). Too bad that there is no such option to reboot the entire stack though, one by one is a challenge if you want them to reboot ~at once. ... View more

From my experience this is always true if you have more than 2 switches in a stack and use cross stack LACP as the uplink. If you use only 2 switches, then its OK. ... View more

I also noticed that if a switch has higher loads, some of the traffic will be lost, the packet captures are often unreliable. ... View more

I'm using 4pcs of non Meraki 40G QSFP modules to stack MS425 switches via SM at around 200m distance. https://gbcphotonics.com/en/qsfp-plus-40g/1443-qsfp-lx4.html It's at least 2 years now without one issue and never had Meraki support complaining on them during troubleshooting sessions.   Of course according to the datasheet your only option is -> MA-QSFP-40G-LR4 I remember that back then the price was mind blowing so we went for testing the GBC's for a while and headed that way after finding them being just fine. ... View more

You don't need to apply different vlans for different passphrases, they are separated from each other already, its by design. Think about the WPN as a perfect solution for hotels where every room gets their different password. Now for example a chromecast that you would connect to the TV, or the built in smart TV would be visible for all devices that use the same password. In normal circumstances this is not possible when you use an client isolation. ... View more

https://meraki.cisco.com/product/switches/aggregation-switches/ms410-32/ 4 x SFP+ (1/10 Gbit) 32 (or 16 for MS410-16) x SFP (1 Gbit only) ... View more

Using it with MS425, 225 and 120 switches and apart of upgrade not going very well the devices seem to work just fine (no rollback done or so). DHCP relays 802.1x, SecurePort all work correctly, didn't notice any POE issues as some reported. ... View more

Fully aware of that, just wanted to point our that WPN can be used to cover a scenario which some of us might have. ... View more

I wonder if I would add a firewall rule in the group policy preventing access from the local subnet. Lets say the guest subnet is 192.168.0.0/24, I would add an DENY for the 192.168.0.0/24 and before that add an allow for the gateway. I don't see why this wouldn't work, but maybe I'm missing something obvious? ... View more

This is very weird, are you sure your dashboard is loading properly? Do you see the status of your switches? What models do you use?   For a test - try maybe to hand craft the url to that section: Go to the Monitor -> Switches part replace the end of the url (so this part /manage/switches/*) with /manage/configure/switch_settings (https://nnnn.meraki.com/xxxxxx/n/zzzzzz/manage/configure/switch_settings) ... View more

Sounds like you are not an admin for that network? ... View more