Yep it's a dashboard alert. Fair enough. Given the link successfully loads a page which just has no information, I figured it's either an issue with the dashboard linking to the wrong article or the article itself is incomplete/broken. I'll open a support ticket. ... View more

Thanks for the responses. This probably made sense for everyone else immediately but took a little for me to work through the differences in where what can be applied. Below are some clarifications for myself or anyone else confused to reference.   When performing traffic shaping, there are 3 places in which it can be applied:  - MR (per SSID) - Apply CoS and DSCP tags  - Group Policy - Apply CoS and DSCP tags  - MX - Apply DSCP tags or 'Priority' (referenced in docs as Packet Prioritization)   CoS tags are applicable within an L2 network. DSCP tags are applicable when crossing L3 boundaries.   This makes sense, but what confused me was 'priority' on the MX. This is applicable only to uplink bandwidth and when enabled, portions out the uplink bandwidth accordingly (see link below). Using Packet Prioritization on a Traffic Shaping Rule - Cisco Meraki It's only effective if the WAN bandwidth in the Uplink Configuration is accurately configured:   For my use case therefore, a combination of each of these is applicable.   ... View more

Congratulations @AmyReyes! Super exciting and a wonderful Christmas/New Years gift 🙂 I hope it's a smooth and enjoyable transition. ... View more

That section is only applicable if you're adding a warm spare MX. If you only have a standalone MX and you're migrating to another standalone MX, you can ignore this section. ... View more

Above posts are spot on. Only thing I'll add is that if you're configuring lots of switches, it's far easier to use the API. If the new switch has the same number of ports, using the API you can simply pull the config of the old switch and apply it to the new switch. If the new switch has a different number of ports (or you're changing the port mapping), you will need to create a new csv/json file and apply it using the API. I wrote up a script a while ago to take a csv file of basic port config and push it to a given switch. Not the best coding but it works well enough - Brash92/Meraki (github.com) If you have the skills, you can do something similar to push the required config to the new switches. There's plenty of other (probably better) resources/references out there to speed up this kind of work with the API. ... View more

This is expected behaviour. Have a look at the following doc. It has some good explanations and examples around switch port isolation. https://documentation.meraki.com/MS/Port_and_VLAN_Configuration/Restricting_Traffic_with_Isolated_Switch_Ports ... View more

In addition to @Ryan_Miles comment, also confirm that the switch you're pulling power on isn't the only switch with an uplink to the rest of the network. ... View more

As stated above, best to open a support case. The only other thing that comes to mind is if your Telco has restrictions on the SIM. Your SIM could be locked to the previous LTE device (especially if it was Telco provided). Otherwise, I've heard of some Telco's blocking connections from certain devices (such as Meraki) as they only allow enterprise devices on a certain APN.  Never encountered it myself though. ... View more

It kind of depends how you had port security set up previously. Meraki supports both explicit MAC address whitelisting and sticky MAC address whitelisting. https://documentation.meraki.com/MS/Port_and_VLAN_Configuration/Switch_Ports#Port_configuration   It doesn't however support a MAC address maximum where (for example) you enforce only 1 MAC address to be allowed on the port at any one time, but that MAC address can change. The equivalent of Switch(config-if)#switchport port-security maximum 1   ... View more

This is an interesting tidbit I never knew... So the MX uses 6.0.0.0/8 internally within the tunnel(s) in order to route traffic across S2S VPN? ... View more

From a bandwidth switching perspective, you're right a bigger switch would probably be overkill, but you still need to look at switches which fit the requirements of your design - which it seems here the Meraki switches don't meet.   I'd go with @cmr 's idea of breaking the VMware hosts and SAN into separate switches not reliant on the core stack. ... View more

If the client vlan isn't trunked up to your mx250, there's no way for their clients to route into your network (other than the mx64 WAN port which you already mentioned will have firewall rules).   That said, if you're concerned about it, you can add the rules for the client vlan in your MX250 anyway, it's not going to hurt anything. ... View more

If I'm not mistaken you'd been looking for something like this (site-to-site vpn translation) https://documentation.meraki.com/MX/Site-to-site_VPN/Using_Site-to-site_VPN_Translation#1-to-many_(1:M)_VPN_NAT   And yes, in a split tunnel scenario internet destined traffic goes out the Internet link while site to site vpn traffic traverses the tunnel https://documentation.meraki.com/MX/Site-to-site_VPN/Site-to-Site_VPN_Settings#Tunneling ... View more

I agree with you that the stack upgrade limitation sucks. That said, I'd also say that an MS250 isn't exactly a datacenter switch for connecting VMware hosts to a SAN. It's unfortunately one of those things that you need to assess if it meets your requirements.   It's primarily for this reason (along with a few others) that I typically don't put Meraki in the core of any datacenter or large enterprise networks, especially now that Meraki monitored/managed Catalysts exist. ... View more

This one is a little bit funny. "Cable length is reported as double the actual length during cable tests in some scenarios" ... View more

That's a very weird setup but like @RaphaelL said, it will work although the MX's need to be in different networks. As for your questions:   Would their client devices be able to use our MRs if we plugged their MX64 LAN port into one of our MS ports? I assume we would set the only allowed VLAN on that trunk port to whatever VLAN they decided to setup on their MX64 for clients. Yes, separate SSID with separate VLAN that trunks only to the MX64 Do I need to create the same VLAN on our MX250 to make firewall rules? They will be creating the VLAN on their MX64 to handle DHCP for their clients, but I can't seem to make a rule referencing a VLAN not present on our device. No, your MX250 doesn't need to be 'aware' of the VLAN. Just configure it to the MX64. You will however need to make firewall rules that prevent the network traffic coming from their MX64 WAN port into the MX250 LAN port going to your network. Will they be able to set up their own site-to-site VPN on their MX64? I don't see why not, but I could see Meraki not liking that. I've never tried it but I don't see why not. Other threads I've seen in the community and reddit seem to indicate people have tried this and it's worked.   ... View more

So good! Thanks @DrDray ! ... View more

Intel Wifi drivers being an issue?  No, never! 😉   Agreed though, love the new roaming page. ... View more

Assuming the dashboard lets you configure it (I've never tried), it's not a good idea. There's no reason I can think of that you would purposely want to introduce duplicate IP addresses into your environment - It's just asking for trouble. ... View more

This warning is pretty typical in Meraki world if you're not running the latest patch release on a given firmware train. It's not a big deal to worry about.  Meraki will never 'delete' your firmware off your device, however they might automatically schedule an upgrade in your dashboard. You will get emails advising you of this and you can cancel it from the dashboard if you don't want to upgrade yet. ... View more

Meraki AP's store the latest configured configuration locally (so it can continue to operate if it loses connection to the cloud). The following doc outlines the behaviour of different devices in that scenario Behavior during Connection Loss to Cisco Meraki Cloud - Cisco Meraki ... View more