@Inderdeep, your link seems to be broken. @hmc250000, here’s the relevant information from Inderdeep’s link… ... View more

I’m sure the documentation is there somewhere, but I’ll summarise based on knowledge and experience, as this is likely better than trying to compare statistics from data sheets.  The first point is that the MX*W and Z3 devices have a standalone wireless solution that does not interoperate with other MX*W/Z3 devices or MR devices. The upshot of this is that if a site grows and you want more coverage then you won’t be able to achieve seamless roaming or the like from the MX/Z to another MX/Z or a MR.   Second point, is AFAIK the MX/Z devices are still only Wifi5 devices, there isn’t a Wifi6 option (would love to be corrected here). Whereas most of the current MR devices are Wifi6.   Third point, if it was me I’d prefer to use MR devices everywhere so that the user experience is as similar as possible, and the management and troubleshooting is as similar as possible too. You also have many more options with the MR range to get the coverage you require, 2x2:2, 4x4:4 and so on.   If it was my choice I’d do MR devices to provide all the wireless capability, then an appropriately sized (non-W) MX (e.g MX64, MX67, MX68, MX75). The only time I’d consider a ‘W’ version of the MX is cost, or if it’s a small office/home office with no more than a few people, and absolutely no chance that it’s going to grow/expand. ... View more

Yes, if you want to tag the internal traffic then creating a new VLAN is probably the easiest solution. You can the leave he APs on the native VLAN (VLAN 20), and change the SSID for internal clients to use VLAN 30. You’ll also need to configure a new DHCP scope for VLAN 30 and, and if the DHCP server isn’t actually on VLAN 30, then configure a DHCP relay/forwarder on the Layer 3 interface for the VLAN.   There shouldn’t be any problems leaving it as it is. As has been said though, it’s recommended to keep management traffic on its own VLAN. ... View more

@MB3, what subnet mask are you using? Just be aware that if it’s a /31 (which should work with the MX), then the MX has to be higher of the two IP addresses. Not sure if this is the case, but just a heads-up in case it is. ... View more

Depends… lol. Sorry couldn’t resist. Generally I’d say it’s about 10-30MB a day per device from what I’ve seen.   Maybe others have a different view/opinion. ... View more

Not out of the box you can’t. When you enable the Client VPN it creates hidden inbound firewall rules that allow access from all IP addresses to the relevant ports on the MX. If you’re using the L2TP Client VPN then it uses UDP ports 500 and 4500, if you’re using AnyConnect then it’s TCP port 443 by default (but you can change this).   I know that support can (in certain circumstances - e.g. for no-NAT) enable manual control of the inbound firewall on the MX, which would potentially then allow you more control over the IP addresses that can access the MX. But that then comes with the overhead that you have to manage all the inbound firewall rules, e.g. ICMP, port forwards, static NATs, etc. so you really need to know what you are doing.  So you might be able to do it, but you’ll need to get support to agree to your request and enable it. ... View more

@athan1234 you shouldn’t need a static route on the MX. The MX will route between its interfaces without a static route. The MX firewall rules should allow traffic between the VLANs by default, but check those rules too - the ‘outbound’ firewall rules apply to traffic between VLANs.  Your central firewall won’t know whether the traffic is from a /24 or /25 network, so that won’t matter. You should check your devices, what OS are they running? Some have a local firewall that could be restricting traffic from the other subnet - now that the other device is in a different subnet. ... View more

Congratulations all! And great start @JustinGA  ... View more

Correct, if one fails STP will reconverge onto the remaining working links. If this is the core of your network then I would definitely change the STP priority to make one of the switches the STP root, and the other two the likely second choices. ... View more

In all honesty the MS390 switches have been really buggy, and this sounds like another one of those bugs - in fact I believe it’s listed in the release notes.  I understand the concern about running beta software in production, but personally I’d consider the whole MS390 range as ‘beta’, and you will likely get a better experience with these switches on the MS15.x ‘beta’ firmware.   Just because it’s beta, it doesn’t mean it’s unsupported or unstable (unless there are warnings to that effect in the release notes, e.g. the MX17.x firmware), all it means is it’s not widely deployed (and consequently not so thoroughly tried in the field, a bit like the MS390 in general). ... View more

Based on my experience of hotel Wifi (which I know varies from country to country - and even within a country), I wouldn’t be looking at this as an option. I’d look at providing a 4G/LTE modem (or cell phone) and get the employee to use a cellular connection while travelling. Will likely be easier to manage. In fact you could look at using the Z3C or MX67C for this purpose. Now this obviously assumes there is good cellular coverage… which may not always be the case. ... View more

As a word of caution, when you get no-NAT enabled it also enables manual configuration of the inbound firewall rules (or it did last time I did this, about a year ago), with the default being ‘allow any any’ - so be ready to update this immediately after getting no-NAT enabled. ... View more

As @KarstenI stated, you’ll need to use the Internet flow preferences to ensure that all traffic destined for the cellular modem’s IP address uses the correct WAN link. Also, remember that all traffic crossing the MX (e.g. LAN to WAN) is NATed, so when you access the cellular modem the source IP of the traffic will actually be the MX’s WAN IP, so you shouldn’t need a static route to your LAN-side subnets. ... View more

Technically you can’t for water damage, but give it a try. I’d also be getting in contact with you reseller/Meraki AM to see if they can help out in any way to get you back on the air. ... View more

The only way I can think of getting that to work is by sending all your internet traffic via Pak. You do that by setting Dubai with an exit hub of Pak on the AutoVPN page, but then All internet traffic will be tunnelled to Pak. ... View more

Echoing what @Ryan_Miles said. If you’ve got a few Z3 devices then I’d put a small MX (MX64 or MX67) in VPN concentrator mode behind the ASA. Will make things a lot easier to setup and manage. ... View more

I would definitely consider what @RaphaelL suggested to provide redundancy to the MX - use a second LAN port on the MX to connect to a different switch in the stack, and allow STP to put it in blocking state. I would also split all your aggregations across more than one stack, yes you can do that on Meraki switch stacks. With regards to the new stack, if you have fibre from the new cabinet back to the main cabinet then I would go directly back to it, so creating a star rather than a daisy-chain - means if the stack in the office cabinet fails, then the new stack won’t go offline. And again, if it was me I’d split all the aggregates across multiple switches in the stack. ... View more

That just looks like background noise. Anything coloured blue is very low level transmission. Off the top of my head it transmissions from blue though, yellows, red, and to white I believe. But that 5GHz spectrum looks clean. ... View more

Nope, RSTP is a standard, and rapid-pvst is a Cisco proprietary protocol based on the standard. The two generally play nice together if you have a Cisco switch as the STP root and any Meraki switches are only at the edge, and so long as you don’t go Catalyst - Meraki - Catalyst in the spanning-tree. Otherwise you’ll need to implement MSTP on the Catalyst switches, which is a standard, and should play nice/better with the Meraki switches. ... View more

Do you have logging/syslog enabled for the firewall rules? There is a check box on the firewall rules that needs to be checked to enable Syslog generation by the rule. ... View more

If the root of your network is a Cisco device running RPVST, and the Meraki devices are at the edge of the spanning-tree then there is a fair chance you'll get it working without having to implement MST, or anything else special - the Cisco switches transmit a standards based BPDU as well as the Cisco proprietary BPDUs. Any issues mainly occur if a Cisco device isn't the spanning-tree root, or if you're expecting to 'hop' across a non-Cisco device, e.g. Cisco <-> Meraki <-> Cisco.    If your Cisco switches are root then you need to drop your priority on them to closer to 0, e.g. 8192, 4096, or even 0 itself. As default the Meraki devices use a default STP priority of 32768 (which I believe is what Cisco use), so if you have your root set at 61440 then its really unlikely it will actually ever be your root. ... View more

As always with wireless, it depends.   If all your services are cloud based and you’ve, say, only got a 1Gbps internet link then you’ll see little benefit in running mGig to your access points. The bottleneck will be your internet connection.   If you’ve only got low client density, a handle of clients per access point, which are probably only running one or two spatial streams, and only 40MHz channels, then you’re unlikely to see more than a gigabit of traffic.   If on the other hand you’ve supporting a high client density for the latest and greatest Wifi 6 clients running 160Mhz channels with multiple spatial streams on a client, then you’ll push past the one gigabit - but then you really need ask if you need those speeds for your services?   In all honesty I wouldn’t worry about mGig yet. Office 365 doesn’t use much bandwidth, VOIP is tiny (about 100kbps), and even high-def video comes in at around 5Mbps these days.  ... View more

No, if traffic is initiated on the outside (WAN) then you need rules to allow that (inbound) traffic. Generally it means you’ll have a server inside your network listening on a specific port - you’ll then use a port forward on the MX and specify the inbound traffic that is allowed. ... View more