The recommended MTU to prevent fragmentation on OTV is 1542, do you know what the maximum MTU Meraki supports on the MX devices LAN and WAN interfaces? ... View more

After speaking with other internal engineers, we have some MX250 and MX450 with C15. ... View more

Awesome, I didn't consider the C15 to be compatible with the C13 but it obviously is as the C15 just has a notch cut out.  Good spot and thanks. ... View more

Using a dummy device is an interesting one but I currently don't have the time to invest in testing it.  I've told the customer the feature isn't available and they need to reach out to their Meraki account team.  Thanks. ... View more

I originally API created a 600 site Org with only MX devices, the customer is using their original none Meraki switches and access points.  Now the customer wants to start adding Meraki switches to all sites and have asked if I can add product type switching in advance and then mass configure their switch alerting settings, switch alert settings are not visible or configurable on a network until it has product type switching. They've stated the reason for asking this as: "we will be adding the switch serials/devices to the networks on an ad-hoc basis and will not know all the serials for each site in advance, having all the switch alert settings pre-configured for the whole Org would remove a step from our provisioning process". A third party is holding all their switch stock, they request a few devices per day from stock for the roll out and that is the point at which they are given the per site serial numbers. ... View more

You asked a question regarding my request "What would be the advantage of doing this in advance?"   Then tried to shutdown a reasonable response with this "It just sounds like an extra, unnecessary step to me".   Then slopey shouldered it with this "contact your Meraki account team".   And all without waiting for my initial response.  Judge, Jury and Executioner all in one paragraph.  People might presume customer support is not your strong point. I'm sure the API code to add product type to an existing network would be simple, especially as multiple product types can be added when the network is created. ... View more

Thanks for the information.  I think they should add it as a feature to be able to add product types after the initial network creation rather than create new then combine, its a long winded way to achieve the same result.   Thanks ... View more

Hi CuongPham   I finally got a confirmed answer to your question.  In the scenario you provided your topology is correct, there isn't specific documentation for this scenario but there is documentation on hub priorities which ended up being the simple answer to this.  I queried this scenario just in case the return traffic was symmetric using some kind of 'Meraki Magic' which we keep reading about.     When spokes have different hub priorities, spoke to spoke routing is asymmetric as the spokes will route via their hub priorities. Spoke tunnels are not stateful, so they can send via one tunnel and receive via a different tunnel. The hubs are agnostic as they are in VPN concentrator mode. ... View more

Hi CuongPham   I finally got a confirmed answer to your question.  In the scenario you provided your topology is correct, there isn't specific documentation for this scenario but there is documentation on hub priorities which ended up being the simple answer to this.  I queried this scenario just in case the return traffic was symmetric using some kind of 'Meraki Magic' which we keep reading about.     When spokes have different hub priorities, spoke to spoke routing is asymmetric as the spokes will route via their hub priorities. Spoke tunnels are not stateful, so they can send via one tunnel and receive via a different tunnel. The hubs are agnostic as they are in VPN concentrator mode.   ... View more

Now I'm conflicted between your reply and the FMTeuchter reply. It makes some sense that asymmetric routing happens over the spoke tunnels and the spoke tunnels are not stateful as a reply could come via a different tunnel due to the other spoke having a different hub priority. It also could make some sense that reply traffic would go via the same tunnel the traffic was received on. The problem is without Meraki documentation, neither response can be validated. ... View more

Hi Philip   If the asymmetric routing example detailed in this post does happen, does this mean that the MX is a stateful firewall over its WAN and LAN interfaces but not over its autovpn tunnels?  The reason I'm asking is that the return traffic could be via a different tunnel.   Thanks Rick ... View more

Hi Mike   I know its a long time since your original post but I'm interested to know where you ended up with this. Is it the same prefix limit across all models and how dis you get the right result for the customer?   Thanks Rick ... View more