Just going to throw my two cents worth in here too.   First, the best way I find to think of the Meraki Management interface is a virtual interface. The virtual Management port is an access port that then connects via a virtual cable to a virtual port on the switch (which is an access port), and whatever you specify as the management VLAN is the VLAN assigned to that virtual access port on the switch, not how the virtual management interface is configured. (Now I re-read that I'm not sure if it will help or not...)   Second, as @GIdenJoe states the management VLAN doesn't have to be the native VLAN. But, it makes it significantly easier if the management VLAN matches the native VLAN on the uplink. Since the virtual port behaves as an access port the traffic is never tagged. Its only when management VLAN traffic exits the switch on a trunk that it is tagged, if that VLAN isn't the native VLAN. As everyone has said, using the native VLAN is easier as when a switch with no configuration first comes up it, well, has no configuration, so the traffic from the management port will always access the switch untagged. Likewise, if you move the switch to another network if the management VLAN corresponds with the native on the uplink then it will more likely get a DHCP address (and thus retrieve its new configuration), even if the upstream port is configured as an access port, or is blocking certain VLANs.   Third, and completely unrelated to the management port. Remember that the MS390 runs a single instance MST, whereas a Catalyst switch will likely be running PVST+. This is just something to be aware of, and keep in mind if you appear to have STP issues. ... View more

I don’t believe there is a way to disable the wireless radios on the MX-W devices. The best you can do is under Security & SD-WAN -> Wireless Settings set all the SSIDs to Disabled, this means the MX won’t be advertising anything but I don’t believe it actually powers off the radios. You may want to check with support to see if they have a backend way to turn them off. ... View more

@RadyMohammed the number of clients in the sizing guide is a recommendation, not a hard limit; whereas the throughput figures are basically a hard limit (depending on your traffic mix you may or may not hit those figures).   If you think you might do SD-WAN then I’d consider a larger box at HQ there will be two tunnels from each site, which doesn’t leave much head room. But if the servers are all at HQ, then most (if not all) of the traffic is going to be initiated from the remote sites, so the traffic (and people) at the HQ itself is largely irrelevant.   I’d normally position a minimum of a MX84 at HQ in this scenario, but you may be able to get away with something smaller. Maybe try the MX67 - it still only supports 50 VPN tunnels, but it is a slightly more powerful box. ... View more

@JonasResende Are there any messages in the event log? The VPN registry connection is only required to first establish the VPN tunnels, and then when the keys are renewed. So the tunnel will stay up even if the VPN registry connection is lost.   You can sometimes lose registry connectivity if the Meraki registry server is overloaded, and you’ll likely be able to see that in the log - lots of registry connectivity losses and connections. Of course, it is just possible that there is something upstream blocking the connection - the VPN registry uses UDP ports 9350 and 9351, and you can find the IP addresses for your org., buy looking under Help -> Firewall Info. ... View more

@RadyMohammed, you can do it with or without a MX at the HQ end, but for ease of administration and configuration I’d be putting an MX at the HQ end. Essentially you’ll be following this document if you have the MX at the HQ end, https://documentation.meraki.com/MX/Deployment_Guides/MPLS_Failover_to_Meraki_Auto_VPN. If you don’t have the MX at the HQ end then you’ll manually need to configure a connection to each of the remote sites on the Fortigate. The Meraki side won’t be so hard as you can configure one set of credentials that applies to all the sites, but you’ll likely need a static IP address on each of the remote sites (so the FortiGate can confirm the device identity).   From a sizing perspective make sure the MX64 are big enough. All your traffic will pass through them onto the MPLS circuit, and if you failover to the VPN then you’ll need to be encrypting that traffic too. At the HQ end I’d be thinking you definitely need something more capable than an MX64, but that depends on the required bandwidths. Have a look here if you haven’t already, https://meraki.cisco.com/product-collateral/mx-sizing-guide/?file.  If you do implement the MX at the HQ it’s not a huge leap to go to a full SD-WAN solution, and then you can make use of the internet VPN for less latency sensitive traffic, e.g. email, so freeing up more space on those MPLS links - definitely something I’d be thinking about.   Hope this helps. ... View more

I’m still in two minds about the MS390. From a futures perspective, yes it will be the best switch. Should you deploy it now? Hmmmmm... if you just want switches doing nothing too special in small stacks (three or less), and you’re happy for the odd hiccup and to run the MS14 ‘beta’ code then I reckon they’re probably deployable.   As for SGTs, I doubt very much that the traditional Meraki switches will ever support them. The Cisco Catalysts and the MS390 that support SGTs have the UADP ASIC in them so that they can process the additional payload in the Layer 2 header - its unlikely the traditional switches will ever get this capability as their ASICs most likely can’t do it, and doing it on the CPU is impractical.   I expect, but this is pure speculation, that potentially once the MS390 has reached a certain level of maturity and stability then Meraki may bring a small number of other Catalyst hardware over to the MS range, like the Catalyst 9500 to expand/extend the MS400 series. Under the hood the Catalyst 9000 switches are all similar from my understanding, so once one is done the others should be significantly easier (and probably not such a mess as the MS390 was). ... View more

Good to hear that you use the SD-WAN method for sites where it’s applicable. With this site have you fully tested it and did it work?   I’m surprised that using a host in the destination subnet works as when the AutoVPN route takes over that host would become accessible again, and so you’d expect the route would become active and start black-holing traffic, then it would drop again, and you’d get a route flap.   If it is working, all I can assume is that the source used for the routing ‘ping’ can’t be routed into the VPN... that would be what is ‘solving the problem’ (although isn’t intuitive). ... View more

It won’t work if you do it directly on the MX firewall page, but may work if you use a Group Policy. Not something I’ve tried to do before, so will be trial and error. Would be interested to hear the outcome. ... View more

I'd try creating a Group Policy and attach it to your Mail Server. With this Group Policy you could override the outbound firewall rules so that that particular server can communicate with all countries, rather than being blocked.   (In fact if you read the last paragraph of this, https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Layer_3_and_7_Firewall_Processing_Order, you may find that if you specify the outbound ports that your mail server uses as a Layer 3 outbound rule as an 'allow' then it may work with your country blocks; that's assuming the Group Policy is processed the way it states, i.e. like a MR). ... View more

You should be able to get it to work. I think below is the way to do it (although I haven't tried it), its not exactly as per the document, but hopefully should achieve the outcome you require.   Don't include 192.168.128.0/24 or 192.168.129.0/24 in the AutoVPN (if you do it will certainly break) Configure a static route, 192.168.0.0/16, that points to the local next MPLS hop. So in the case of the 'left' side this would be 192.168.0.0/16 is via 192.168.128.249. This should be set to always available. Obviously this is great if you can summarize all the subnets on your MPLS WAN, or you'll have to add more specific subnets. It also assumes the subnets on the MPLS networks are only used for transit, no hosts. Configure the static route, 10.0.0.0/24, on the 'left' side with the next hop of 192.168.128.249. This should be available if a host responds, and the host should be 192.168.129.1 (i.e. the MPLS connection on the MX on 'right' side). The theory is this: the 'always' static route ensures that the ping to test if the host is alive is always sent via the MPLS network. If that ping test fails then the 10.0.0.0/24 route will be removed, and traffic sent via the AutoVPN. However, when the AutoVPN is being used the 'left' side pings to the 192.168.129.1 will still be sent to the MPLS (even if it is a black-hole) and never via the AutoVPN since the 'left' side doesn't know that 192.168.129.0/24 is accessible via the AutoVPN.   I think that should get you working.   Forget that - the testing against a remote host doesn't work that way; the host has to be in the subnet specified in the static route (which won't work). Looks like you have to test against the next hop, which means you're only testing for a failure of the local link, not the path all the way through to the other side.   The alternative would be to turn this into a SD-WAN solution, but in that scenario you'd either need internet access from your MPLS cloud, or to configure one end as a VPN concentrator - which means another firewall (potentially MX) required. ... View more

@combimaster, I see what you’re stating. It does list the MA-ANT-21 under ordering information, although doesn’t actually state that it’s compatible... I would suggest you bring this up with your local Meraki AM to see if they can assist you. ... View more

They'll need to purchase a license with the new hardware. You'd have to contact the Meraki AM to see if they can swap licenses, but its unlikely (unless they're a recent purchase, in which case they may agree to it for a credit).   Unless they customer has moved to the Per Device Licensing model, they will be on the Co-termination licensing model. In the Co-termination model if they purchase a 1-year license for the new hardware then licenses will 'flow back' from the SM licenses to the point where its equal (think of the licenses as a bucket of tokens spread across all devices).   The renewal date will no longer be 5 years away, and depending on the product(s) purchased it may only be a year or two out from the date of the new hardware purchase, but it effectively pulls the licenses from the SM to the new hardware. Have a look at this tool to see if it can help you calculate the impact it may have, https://documentation.meraki.com/General_Administration/Licensing/Using_the_License_Calculator.  ... View more

I think you're going to have to resort to some scripting and using an API call to grab that sort of information. It appears everything you need is available in these two endpoints:   /organizations/ {organizationId} /appliance/vpn/statuses (https://developer.cisco.com/meraki/api-v1/#!get-organization-appliance-vpn-statuses) /organizations/{organizationId}/appliance/vpn/stats (https://developer.cisco.com/meraki/api-v1/#!get-organization-appliance-vpn-stats)   It'll just need some work to see what changes when a peer goes down (and what doesn't), so you can find and report the issue. My gut feel is that you're going to have to look at the stats for a small timespan to asses with a particular peer is up or down. Although you may get lucky and be able to assess the 'merakiVpnPeers' in the Statuses, depends whether its purely 'reachable' or 'non-reachable', or whether there is an intermediate step, 'impaired'. ... View more

Well done all, and especially to @AutomationDude and @rwiesmann.  ... View more

The MR86 antenna ports, the two on the top and two on the bottom of the unit, are all dual-band connectors. That is they have both the 2.4GHz and 5GHz antennas connect by a single connector, with the four connectors providing the 4x4 MIMO that the MR86 offers.   As such the MA-ANT-21 isn’t supported - since it’s only a single band antenna - and so you can’t select it.You’ll need 2x MA-ANT-27 for the MR86, these are the dual-band sector antennas, one connects to the top two antenna ports, the other to the bottom two ports. ... View more

@Neteng-ttcoDo you have any local networks configured on the hub? If so, what are their subnets and masks (e.g. 10.1.0.0/16). When you use BGP subnets advertised to the spokes they are either learnt via the eBGP connection to the DC core, or from manual configuration on the Site-to site VPN page. Is it possible the backup hub is learning the route with a longer mask (I.e. it’s a more specific route).   If you’re sure all the subnets have the same mask length, and everything else is working correctly, then I’d open a case with support as they may be able to see from the backend why the backup hub is being preferenced. ... View more

The loss rates you are seeing are based on a ‘ping’ to the IP address listed just above the graphs on that page. The loss could be at any point between you and the server, or the host you are pinging not responding to the ping in a timely manner. As Brandon said, 8.8.8.8 (which is the default), may not be optimal. As everyone knows, it’s Google’s DNS server, and it’s any anycast address, so depending on the state of Google’s network it could be routed almost anywhere. I’ve seen the latency to 8.8.8.8 jump between 5ms and 25ms depending on the host that is responding.   You can configure additional hosts to ping under the SD-WAN configuration. Whichever hosts you do pick make sure they’re reliable. My own experience has shown that your service provider’s DNS servers aren’t always a good choice as often they’ll happily drop ‘ping’ traffic in preference to serving a DNS request (which is great for DNS requests, not so great if you’re using them to measure link quality/performance). If you’re able to identify a reliable gateway device then that may be the best bet. ... View more

Depends... (I hate answers like that). I’ll elaborate. Can users transition seamlessly between floors, maintaining their wireless connection? In my experience generally they can’t, they have to either use a stairwell or a lift where there is no wireless connectivity, and so the device will disassociate and have to re-associate anyway, so no need for roaming. Occasionally you may get an office where it is possible for clients to move between floors, and then I may just have a single subnet for those floors, but that’s the exception rather than the rule - generally I find it’s one subnet per floor, no need for roaming between them. If they can move between floors without disconnecting, they do, and they have an application that requires seemless roaming (e.g. VoIP), then at six floors I’d probably consider Layer 3 roaming rather than a large subnet. But, again, that depends on how many devices I’d expect on the subnet.   From a subnet sizing point of view remember you may have a subnet for corporate devices, one for BYOD, one for guests, so I’d say a /23 is the largest you should ever need - beyond this the broadcast domain gets too big in my opinion. ... View more

You say you’re using BGP to the DC core? Are the routes originated on the DC core, or being learnt by the cores? If they’re learnt then check the AS PATH for the routes that are being sent to the Meraki concentrator. It may be that the path length on the routes is making the MX450 more preferable. I don’t believe there is a way to do this on the Meraki side (although support can probably see it), so you may have to look at the DC cores, or do a packet capture of the BGP advertisements. ... View more