The image is just wrong.   If you look at the switch image on this page: Main MS390-48 page  You'll see the correct module inserted. ... View more

You only have a few options. You could try to change the subnet you're on. You could change the subnet where the pc's and server are at. You could put yourself behind a NAT in that subnet you're on and try to build your VPN from there.  For example if you're on an AP SSID that does NAT instead of bridge mode. Finally there's another more expensive option to buy a Z3 appliance and do Site2site VPN instead. ... View more

"The subnet I'm in before I connect to VPN is 192.168.0.0/23." That's the problem:  The subnet you're in before connecting to the VPN overlaps in address space with 192.168.1.0/24. Your client will be arping for the destination on his own adapter, not the virtual adapter created by the L2TP. ... View more

My personal biggest beef is the lack of differentiated support for people in the networking field. What I mean is that as a network engineer myself I always try to give as much information as possible when opening a case by clearly formulating the problem and providing drawings and packet captures. I then always wait a few minutes before effectively calling support and expect them to first read the info I have given them instead of having to answer noob questions like 'have I tried using a factory made cable'.  My usual calm self quickly escalates to an erupting volcano if after 20 minutes on the phone I'm still answering silly questions after I explained the situation clearly enough for the third time. I do understand that I can make a mistake myself and perhaps have made a premature conclusion but in most of the cases the conclusions are correct and escalation is in order, but then some engineers just won't escalate and keep you answering noob questions and trying to find bogus reasons in the configuration why the problem exists. I think the engineer should be able to quickly gauge the skill level of the person on the other end of the line and adjust troubleshooting accordingly. ... View more

Or if you really want their email you could setup an excap. Then you need a website with php that just lets the users fill in their email and then sends the OK to the access point. ... View more

First the basics: So the LAN behind the MX is 192.168.1.0/24.  Do the PC's and server point to the LAN IP of the MX as default gateway? Second when you connect using L2TP/IPsec to the MX from a remote location do you have a full tunnel config or a split tunnel?  If you have split tunnel then you need to add a route in windows for the network 192.168.1.0/24. Thirdly also very important since you're using a very common subnet of 192.168.1.0/24 behind the MX you'll have to make sure the subnet where you're in at the remote location should not also be 192.168.1.0 or the connection will definitely fail. ... View more

Your config seems correct.  Unless some group policy is overriding that policy it should work. ... View more

I would advise against doing that. I have a Meraki customer that switched his AD based DHCP to Meraki because their admin found Windows DHCP to be too hard to manage which I find strange... But since doing that there are issues: The topology is one big MX at HQ, and multiple branch sites connected to MPLS to HQ.  The DHCP scopes all comes from the MX and there are two issues which are under investigation by Meraki engineering. First:  When the initial DHCP DORA comes from the remote client and it gets forwarded from the local router's DHCP relay agent, the lease works.  However when the client starts to ask for a lease renewal starting halfway the lease time, the client sends it directly to the DHCP server in the MX who constantly NAK's the request because it's already in use.  Then right at the end the client once more does a broadcasted DHCP request and that works again. Second: After a few weeks the MX refuses to reply to discovers for a few of the sites.  After triggering a failover it works again... So not stable at the moment. ... View more

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

If you look at the 2.4GHz graphic you’ll see that channel 6 RF output seems to be centered around channel 5 instead. Also it’s unclear if signals from the same AP are ignored or not.  Since it uses a separate radio to scan it should also see it’s own transmitted signal.   Simply put we need   Info how the scanning works exactly What It uses to project It onto the graph A much higher resolution ... 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 wish I had an Ekahau sidekick so I could also verify what dashboard is saying about interference is actually correct. The graph is surely wrong because the center channels are always wrong especially in the 2.4 GHz band. There can of course be non-WiFi interferers on your channel and if they have a high duty cycle then yes, you could have a 'jammed' warning even with no WiFi clients in that area. I've also complained to Meraki for almost two years now that they should fix the spectrum analyser page and include the damn UNII-2 bands. ... 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