The problem I have with split networks is that you can't click through on a client with problems from the MX to the switch or AP.  So troubleshooting becomes a thing where you're going back and forth between networks. There is however the big problem with combined networks and a L3 switch that you can have duplicate traffic types from ghost clients because in combined networks you can only use track clients by MAC address. ... View more

Then please share how you set up your test and what TCP/UDP port you explicitly allowed outbound in a group policy that didn't allow return traffic. ... View more

Are you kidding me? I hope this is not the case because that would be plain silly. Applying a group policy that has L3 rules only enforces rules at the MX or MR depending what is closest to you, and those devices do it stateful, so why do you think it would be stateless, that makes absolutely no sense and that would break alot of designs. ... View more

Oh the 9120 is fresh off the shelf then. Indeed in that datasheet there is mention of both DL AND UL-OFDMA ... View more

I do regular make a wish but it feels like a black hole button since no real feedback is given. By posting it here I just want to get fellow engineers like yourself also think about these features and also submit make a wishes so it get's noticed more 🙂 ... View more

Sorry, I'm used more to have MX84 appliances and the WAN's are numbered 1 and 2 instead of 4 and Internet (5). Just wanted to make my point that a packet capture on the dashboard always shows the correct MAC. Yes I did read the post wrong, I thought he meant the outgoing interface of the appliance, not the MAC's on the segments in front of the MX, sorry again 😉 ... View more

@NolanHerringI just checked the Cisco C9100 AP's and they also only support downlink OFDMA. So it could be that the standard is not 100% set on doing scheduled vs unscheduled UL-OFDMA transmissions or like the Meraki document states that in most use-cases, especially in high density the traffic is by far the biggest in the downstream direction. ... View more

If the LAN subnets exist in front of the MX then a one-armed concentrator is probably what you are looking for. ... View more

To quickly know of the WAN interface try sending traffic through it and at the same time execute a capture using dashboard on the internet (WAN1 or 2 depending on where you send it).  Just use the display you don't even need to use the pcap file option and you can see the mac address your mx uses.   In normal circumstances  without using VLANs on your WAN, the MAC address on WAN1 is always 1 higher than the system MAC and WAN2 is 2 higher. If using warm spare there is a virtual mac being used but the last part also related to the system mac part. ... View more

This is normally only used to get a decent blocking page out there for https traffic. However I think Umbrella is a better way to go about this.   Maybe if you go to a public IP instead of an allowed DNS could the inspection be used to check that? ... View more

That's a bug.   When you use Meraki as L3 switch you usually get a random client in the network that get's allotted most traffic coming from the L3 switch. From logical deduction (I don't have the facts like the Meraki team does) I believe the problem is as follows: - The switches/AP can only track clients using MAC - The MX can do both but is configured to use MAC because they're all in the same combined network. - But the L3 switch of course uses it's own MAC to forward frames towards the MX if you use a best practice point-to-point /30 LAN between MX and MS and all LAN traffic gets routed out that /30 towards the MX. - I also believe the traffic recognition differs on the switches than the MX'es so that means if the MX and the MS agree that this traffic is skype.. then the registration of that traffic to the dashboard will be coming from the MS with the correct client MAC address.   However if they don't agree for example the MS says it's HTTPS traffic, but the MX classifies the traffic as bittorent then you will have duplicate registration of the same traffic and of course the MX will see the traffic coming from the MAC of the MS causing one client to have major traffic towards WAN/Internet.  How it chooses the client name though is a mystery for me. I hope a Meraki technician could provide more inside clarification on this. ... View more

Have you tried determining on which link the LACP messages are sent using packet capture. Then try to power down the switch that does not send LACP messages and see if the port channel goes down and if messages are still sent on the active port. Then try the same but disabling the switch that normally has the LACP messages. That could help in determining which device is no longer sending the packets and report to the case owner. ... View more

Yep, I wish Meraki would implement MSTP so they are fully interoperable with Catalyst and other vendor switches. ... View more

Probably buggy behavior but before making a case with Meraki. Check if those users are already authorized. Under wireless-> splash logins you should see the status of that user. Login attempts also shows some info. ... View more

Hey Nedy, So just bring the switch online and add it to the dashboard network. Make sure you don't couple it to the other switch yet. Then wait until the switch has the same firmware as the other future stackmember. When that is done, power down both switches.  Cable them up (stack cables)  don't forget to cross them.  So stack port 1 on the first switch connects to stack port 2 on the second and vice versa. Then power them back up and wait a few minutes before going into the dashboard and then click in switch->switch stacks. In that menu you'll see possible stackmembers where both switches will be on one line and then just click provision and give the stack a name. Example:  first switch is SW-CORE1-01 and second switch is SW-CORE1-02 and then the stack is named SW-CORE1 ... View more

Then you'll need to buy the second MS350-24X. This one comes with a 0.5m stacking cable, so if  you would still have that one that was delivered from the existing switch you can fully stack them. Else if you've lost it you'll need to order one MA-CBL-40G-50CM.  Basically you need two in total to complete the 2switch stack. The switches need to be close to one another. If 0.5 meters is not enough you can order longer stacking cables of 1 or 3 meters. 2x MA-CBL-40G-1M or MA-CBL-40G-3M The stack config in dashboard is really straightforward but you will need to bring the new switch online without stacking it first and make sure the existing and the new switch have the same firmware. Then you'll need to power off both devices and connect the stacking cables in the back and startup the switches again. Then you'll have a potential stack which you'll just need to provision and voila. You can now start double uplinking every access switch for redundancy and extra bandwith through LACP port channels. ... View more

Yep, these switches are better stacked so from a logical standpoint you still have one switch but you do get the added availability and extra bandwidth.  However this only works if you can co-locate both switches in the same area (closet). If you need redundancy and spatial separation (in case of fire) then with these switches you'll need to do the classic failover with blocked STP links. The MS4xx range of switches have flexible stacking which also makes stacking possible over larger distances. ... View more

I found out it only happens when the output is on the screen. When capturing to pcap file it usually remains on for the duration given. I also have another issue with the packet capture tool on switches.   Since the packet capture is done from the dashboard, I suspect the capture is made after the frame has been processed by the ingress asic.  Since even with tagged or untagged VLAN assignments all captures from the dashboard have an 802.1Q tag assigned which does not always correspond to the incoming frame in a port.  So sometimes it's difficult to troubleshoot if a voice VLAN is getting the correct input from a phone or a server is tagging it's traffic as it should. ... View more

@TylerjuzWe had a severe dashboard bug where a change in one unrelated configuration caused a wipe of all L3/L4 firewall rules.  And those changes were not visible on the Organization->Changelog.  So we decided to do a daily backup of all our customers who give us API access to their org up to the last three days.  So we can always restore the firewall rules from the last 3 days.   I believe my colleague used existing python code readily available on the internet and tweaked it a bit for our purposes so I can't answer any details on this.  All I can say it's possible but make sure to get your customers approval and save those file in a secure location. The scripts you can find usually read the values and write the restore commands so the output is actually a .py file with the commands to restore that config, but for some things like firewall rules, you could output it textbased so it's more human readable and editable. ... View more

A colleague of mine already uses an API to backup firewall rules, so I guess it's possible to backup configurations of other devices. Another colleague of mine painfully found out that switch cloning only takes the port configs but does not do anything with L3 interfaces and routes so beware. ... View more

Hey @NolanHerring, the option to disable meshing is not available by default. So in that environment it's still running. Btw I found your fun 2 year old article about this which I agree with fully: https://nolanwifi.com/2017/02/06/merakis-mesh-mess/ ... View more

I have turned off the 2.4 GHz on a MR53 using RF profile where only 5 GHz band is allowed. When I look at RF spectrum from neighboring AP's I can still see the MAC address of the disabled AP broadcasting quite strong but at 802.11g mode on channel 1 but at a high data rate (I don't trust that output because it sees 802.11ac on channel 1???) So I started a packet capture on the neighboring AP and found it that it still sends some LLC frames once every 30 seconds. ... View more

- Interference is caused by other AP's or clients associated to other AP's on the same channel. They cause performance issues but that would need to be extremely severe before clients would start dropping their association. - Higher noise caused by non-wifi devices can cause the SNR to drop and clients to go below a certain PHY rate and if you've configured a minimum PHY rate they could be dropped because of that. - But it could be a driver issue on some clients since a certain update. Basically you'll need to find out if where it happens (if it's everywhere then test it anywhere) and if it's a certain device type, then test with multiple devices at that location to gather your info (PHY rates, retry rates, dropping) - If it's a driver issue then update/downgrade, if it's a noise/interference problem then you'll need to do a troubleshooting site survey at that location (spectrum analysis for noise, and passive survey for signals and interference) ... View more

Nope MarcP, I was talking about the thread starter. But indeed your log messages seem to state a reason (auth expired), nothing embarrassing about that. Mistakes do happen the first time around 😉 I meant the unknown reason disassocs from the threadstarter. ... View more