@SaravananShan based on your scenarios I don’t believe that the MX is going to be the best choice for you. The VPN to non-Meraki peers, although very functional, does not provide much in the way of customisation - in-line with Meraki’s ‘simple’ approach. You may well be best off putting a third party VPN head-end/firewall behind the MX to perform the functions you describe.   Here’s my thoughts on your scenarios:   Scenario 1: the encrypted traffic is defined by the addresses that you ‘include’ in the VPN, these are either locally defined subnets on a VLAN or a static route.    Scenario 2: for each Meraki network the IP addresses encrypted are as Scenario 1. Although the non-Meraki peer is defined globally only local Meraki network IP addresses are encrypted. You can defined multiple tunnels to the same destination (with different remote subnets) and ‘tag’ them so they’re only established from certain Meraki networks - remember non-Meraki VPN routes aren’t passed across the AutoVPN.   Scenario 3: there is no capability for NATing on non-Meraki VPN tunnels. ... View more

@Lock007 this isn’t something you can do with the Meraki MX. And I doubt you could do with any device, especially across two ISPs - the IP protocol was designed to return traffic to the address where it originated, so if it’s sent from WAN1, it will be returned to WAN1. ... View more

@ToryDav, in general, pretty good. A few comments I’d make are:   Physical - why keep all the uplinks and downlinks in the top and bottom members of the stack? Why not spread them out more so that a failure doesn’t take out so many links?   Layer 2 - I’d use aggregated ports (LACP) on the links between the MDF and IDF so you can utilise the bandwidth of both links. It also simplifies the STP model as you have a single logical link. The links to the MX have to rely on STP.   Laye 3 - both the MX have to be in the same VLAN as they share an IP address on the LAN side. I’d use the MS for the Layer 3 core, with the transit VLAN from the MXs. You’ll need another VLAN on the MXs though for all your management IPs to reside in (the management IP on the core switch shouldn’t be in the same VLAN as one of the Layer 3 interfaces in the stack). Make sure the MS you are using supports DHCP… 😀   Hope that’s some help. ... View more

There's nothing that I know of for this that is built into the Dashboard, or as part of the API. The best solutions I've seen in the past are either using SNMP to poll the interface, or collecting Netflow records from the MX. Then you store them for as long as you want and report on them how you want. ... View more

@carl222 I believe the default traffic shaping rules mark traffic based on the detected application, but like you I’ve never found anything to define what they do beyond that. If you’re connected to an internet connection (which it sounds like you are) marking packets alone will make no difference. The default rules only apply to the defined applications too, so unless you’re seeing those applications on your network they’re no going to achieve anything.   The uplink bandwidths that you define on the SD-WAN page definitely tries to shape traffic to those speeds but from our experience (and conversations with service providers - some who have a hard limit with no bursting) they’re a bit coarse, and so sometimes you may well hit the provider enforced limit. Although 0.5% to 1% packet loss is what you’d call ‘normal’, if you want to try and reduce it maybe knock back the uplink bandwidth to 96Mbps so that there is a little headroom between your MX and the provider enforced limit.   If you define your own traffic shaping rules then you can set different priorities (high, normal, low) which defines which egress queue the traffic ends up in if there is congestion (as per the link @Inderdeep shared), but this won’t prevent you hitting the provider limit. If there are one or two applications which drive a lot of bandwidth in your environment then you can try and shape them down with custom rules. Have a play and see what works for your environment. ... View more

@Eddy_X I'd go with the stack option. You are correct that there in only one Layer 3 gateway per VLAN, but in the event that one switch in the stack fails then the second will take over and the network will continue (there may be a tiny outage while the stack reconfigures to accommodate for the failed switch). The other benefit of the stack is that the down-links to the access switches can be configured as aggregated links (LACP) across the two switches so that you get the benefit of the full bandwidth of both links under normal operating conditions.   Since you're using MS425 the stack is created using front panel ports, commonly the 40Gbps ports (but you can use 10Gbps ports if you want). One of the benefits here is that you can use most Meraki SFP/QFP modules so you can actually extend the stack across multiple racks, or even multiple rooms (or buildings) if you have the structured fibre in place to achieve this. ... View more

Yes, your configuration for the switch port connecting to the AP could be that simple. The AP will either need a static IP address from that VLAN or it will need to get a DHCP address from that VLAN.   You’ll still need to carry the new VLAN (200) from the switch where the AP connects back to the MX. This could mean you need to add it to the existing trunks between switches (by default a trunk caries all VLANs, so nothing to do unless you’ve restricted them), and since they are Catalyst switches you’ll need to create the VLAN on the switches between the one where the AP connects and the MX. Depending on the VTP mode you’re using this means either creating the VLAN on the VTP server (in which case it should propagate to all switches), or if you’re using VTP transparent mode then creating the VLAN on each switch.   As has been said by others, why not set it up the same as all your other sites? It’s really not going to be that much harder, if at all, to adding a single wireless VLAN. ... View more