Your topology is doing exactly what RSTP and classic STP does. So switch 1 is the RB so that one will have both links in designated state and forwarding. And all other switches will have equal cost on both links towards that RB.  But since sending port 48 is numbered higher, port 47 will be the Root Port FWD and port 48 will be ALT BLK on the other switches. So to fix your problem you have to make sure switch 1 port 47 goes towards the primary MX. I myself however prefer not connecting the uplinks of access layer switches directly to an MX but going through a CORE switch stack which allows for better east west traffic.  If both MX'es are in the same room you can also connect your MX directly to your CORE stack and then only two links i total would be blocked. ... View more

Your screenshot shows interference on the 5 GHz band not 2.4 GHz. It could be another AP that is too close to this one. The side-lobe transmissions from a nearby channel are identified as non-WiFi interference. ... View more

Normally the MX is equipped with the correct downlink ports according to the maximum throughput so the need for downstream LACP is not needed. However what I do find a little problem is the following: The lack to designate 2 ports to the same WAN link. Take following scenario into account: You have two rooms where you terminate a WAN line and there is a router in each room, downstream those routers do an FHRP to have the same subnet available on both locations for redundancy.  So you need WAN1 of your MX available in both rooms, so you connect the WAN1 to a switch stack in that same room and then that switchstack uplinks to both core switches.  However if a switch in that stack fails that happens to contain your only WAN1 link from the MX, the entire device has to do a failover.  Whereas if you would have been able to have a bundle upstream you could connect to two switches in that stack and have better redundancy that way. ... View more

Sorry to bring this topic back up but... Yesterday I did a demonstration for a group of customers about SD-WAN. I had a setup with a hub and spoke WAN between 4 sites using a mixture of MX'es (250, 84, 68, 67C) All of them had a primary WAN going into a cisco router of mine each with their own little subnet (simulating an MPLS with a single breakout IP) and a second connection going to a switch going to another ISP. Before the demonstration I did some testing using iperf server on a laptop in the HQ site and another laptop in one of the sites I could send continuous heavier traffic to test policies out and found the following: Even if the HQ site had WAN2 defined as primary.  When the traffic in the branch site was being routed over WAN1, it also arrived at WAN1 on the HQ site.  I tested this with captures at first but then I could just look at the uplink stats page of HQ and see the color if the traffic downstream. We tested the other way around but the results were consistent.  So I can only conclude the MX chooses to send from WAN1 to WAN1 or WAN2 to WAN2 based on the public IP or performance metrics instead of uplink preference on the other side. The next test I did was running the test longer and then disconnecting a local uplink.  The traffic was switched to the other WAN immediately because of the layer 1 down status of the WAN link. Final test was disconnecting the receiving WAN link on HQ and there we had two results. Using UDP: the traffic stopped being received for between 20 to 25 seconds and resumed on the cross VPN link after that. Using TCP: the connection failed after the link was switched to the cross link (reset by peer), this however could be due to the behavior of iperf. So long story short:  If you have an MPLS where you overlay Meraki SD-WAN having a single breakout IP don't worry. Traffic leaving one MX onto the MPLS will be routed to the other site on that same MPLS and not crossed over to the internet unless the MPLS link on the other site is down. ... View more

In the EU you follow the ETSI rules and these are as following: For the 2.4 GHz ISM band you are allowed 20 dBm EIRP. For the 5 GHz bands it's a little more complicated: UNII-1 and UNII-2 (channels 36 through 64) are allowed 23 dBm EIRP. UNII-2e (channels 100 through 140) are allowed 30 dBm EIRP. The power levels you configure in Meraki and Cisco gear for that matter are the IR values (intentional radiator) so the antenna gain is not added to it to come to the EIRP. So in case of a MR45 which has in 2.4 GHz a gain of 5.4 dBi, you would be able to go no higher than 14 dBm Tx power. And for 5 GHz there is a gain of 6 dBi so if your channel is below 100 you would not be able to set it higher than 17 dBm TX but go up to 24 dBm if using channels 100 and above. However in a good Wi-Fi design you should keep your AP Tx power as close as possible to the Tx power most of the Wi-Fi clients have which usually varies between 12 and 14 dBm for 5 GHz clients.  And since you want 2.4 GHz to be less desirable you usually keep that one at least 5 dB lower so 8 dBm is a good value there. ... View more

No problem. It's the one thing I find annoying in my country (Belgium) where ISP's only want to use their own routers and manage the config themselves you always lose end to end visibility and having to e-mail back and forth for information and having to rely on their insights. ... View more

Hmm I don't want to throw a brick on that support guy but he's clearly unqualified to handle wireless cases then. There is no 4-way handshake on an open SSID so 802.11r can't be used. ... View more

Enterprise access points usually have a rogue AP feature. In your case you'll have access points with exactly the same SSID and on the same wired network.  This will be seen as a true malicious rogue AP because someone could impersonate the SSID to do man in the middle attacks. Because in your case you just want extra connectivity you'll have to make sure to 'whitelist' the ubiquiti AP's on the Meraki side and do the same for the Meraki AP on the ubiquiti side. Also for good roaming you won't be able to use 802.11r because of two vendors so you WPA2-Personal as security option in this case. ... View more

The Cisco Aironet AP's with WLC do support wireless mesh with ethernet bridging and VLANs. ... View more

Follow up question: If the traffic on the MR is allowed through the allow any rule, does it still fail to process the L7 rules? Or does it have to be an explicit match on a custom rule? I couldn't imagine the L7 rules ever getting hit like that if even the implicit would allow all traffic. ... View more

I think you'll need to fetch all your devices and then look at the action batches so you can add all your entries in there and POST the action batch with all the renames. Maybe some good ol' text edit edit/replace will be required. ... View more

I find it strange you can even enable this feature on non-fiber ports. Normally UDLD is a feature only used between switchlinks to avoid unidirection communication causing spanning-tree to erroneously put a discarding port into designated forwarding due to no longer receiving bpdu's. This error state usually only exists if one fiber of the pair no longer transmits due to optics error or cable error.   So if you want to enable this feature, only do it on trunks that connect two switches, since only switches support the protocol.  Never enable it between switches and hosts/AP's/Firewalls unless they specifically support the feature and have it enabled. You should also start with alert mode ( = normal mode ) before you do aggressive mode which actually blocks a link in case of a unidirectional link. ... View more

Compare clients.  Are they like clients or all sorts of clients that experience the same?   In case of like clients: check the firmwares of the clients. In case of all clients: check the wireless health, spectrum analysis of the AP's and the airtime utilization.   Also an over the air packet capture on the channel of the most troublesome channels could show who initiates the disassoc frames client or AP.  Also look for excessive retransmissions and the radiotap header if it shows deterioration of the signal. ... View more

Not only apple devices use Bonjour. Most windows clients also run the bonjour service to discover mDNS services on the local LAN.   If you're running mDNS services (like printers or video stuff) you can easily detect that by running a packet capture and look for link local multicast 224.0.0.0/24 and it would actually say mDNS. If that happens you can very easily forward those messages to the user VLANs by enabling this feature. ... View more

@Kenneth , I haven't seen the possibility to do that.  When configuring as spoke you need to define a hub of it doesn't take the config. ... View more

Can you remotely login to the AP via SSH and run a debug when this happens? That depends if SSH is allowed on the individual AP's. ... View more

Funny thing today.   I had to go out to a customer with two stacked MS225-48FP's which were the noisy ones to have them replaced under the proactive replacement program. I came into the room with the closet and said, man!  It's quiet in here compared to last time. When opening the closet I noticed the fans had already failed but the switches were still running, but hotter than usual. I could hear the fans slightly starting and directly stopping. It went from an aeroplane to an old woman groaning sound. ... View more

I'll have to make a test setup if the time and gear permits. In this situation the public IP was owned by a oneACCESS router in front of the MX pair instead of having the pub IP on the MX itself. The hairpin did not work on the oneACCESS router.  I captured the traffic and saw the outbound TCP connection but no packets back downstream.  The TCP handshake was succesful but followed by a reset short after.  So I can only assume the oneACCESS responded itself to the TCP syn. There is a DMZ host feature implemented on the oneACCESS but the ISP manages that router and they couldn't fix it.   So I had to implement my workaround by sending traffic destined to that public IP out the other WAN interface so the internet just circled it back downstream. ... View more

@Raj66, I found a problem with this behavior. What if you need to define WAN 2 as primary to have the bulk internet traffic leave that way but you want that time sensitive VPN traffic not only to leave your WAN1 MPLS and enter the other side via WAN1 MPLS but the other side also has WAN2 as primary for the same reason.   I believe downlink saturation on WAN2 on the other side may very well starve your incoming delay and loss sensitive traffic. Is there a way to escalate this in Meraki to make this behavior configurable outside of using the non-feedback make a wish button? ... View more

I understand your argument for the simplicity. But would you want car manufacturers to take away the possibility to change your own tires if you have a flat somewhere on the road and you have to wait for a technician from them to get you back on the road? That the config usually should be simple OK, that's true.  But for real troubleshooting you need an 'expert' mode.  Like when building VPN's to non-meraki peers it would be a great plus to actually see what's going on because a packet capture can't always see everytning (like the contents of the 3rd exchange in main mode IKE). Cisco itself also introduces simplicity with DNA center but they still allow console access.  Just saying... ... View more

This is exactly my main beef with Meraki that when real problems occur you only have a green led and a limited log to troubleshoot and no real control over the inner workings.  Basically you have a steering wheel and a clutch.  With Cisco “Classic” you have a cockpit with loads of buttons and switches.   I wish they would have an expert mode on dashboard or a cli/API interpreter where you input commands or code and see direct results. ... View more