All,   The MX sizing guide is the only document you should be using for scoping an MX, as we haven't traditionally updated the data sheet numbers post release as the results in the data sheet are only ever optimal single use testing data (RFC2544 using 1024 packets) which quite frankly are no use to anyone, however we as an industry only ever highlight data for such optimal use cases; FYI we as a PM org hate having to do this but if we don't someone who doesn't understand networking will point at vendor X and say the number is bigger and hence Meraki is worse :-(. If you need any context on why the numbers have changed (e.g. MX75 Sec throughput) please reach out to your aligned SE/TSA and they can both explain the situation and provide options, unfortunately I can't provide the answer here for fear of it being used out of context. Hope this clears up the situation and gives folks a path forward. Steve ... View more

I'm a little bit late to the party here but elements of the solution have already been mentioned, one thing that hasn't been mentioned is the maximum recommended tunnel count for the MX600s because officially there isn't one.  This stems from the fact when the MX400/600 were live we only published maximum tunnels as opposed to maximum recommended tunnels.     However, based on my experience you should have the same sort of max recommended tunnels for an MX600 as you do for an MX450.  The total aggregate bandwidth across all those tunnels is going to be less than the MX450 though, by about 2x.  Meaning you might be hitting scaling issues of the encrypted throughput side even if your tunnel count is <1500.  I am also presuming that you are running the MX600s in VPN Concentrator (VPNC) mode, as any dual/triple duty they need to pull in routed/NAT mode for firewall or UTM is going to have an impact too.  Hopefully, you are in VPNC mode as that was the recommend design (for AutoVPN termination) then. Outside of that, the answer is horizontal load balancing (you might hear the SEs call it horizontal scaling) across multiple active MXs for pools of spokes such that: VPNC MX1 - Primary for remote site pool A, backup for pool C VPNC MX2 - Primary for pool B, backup for pool A VPNC MX3 - Primary for C, backup for B Again ideally the typical resource utilisation from a tunnel count/encrypted throughput perspective for each of those VPNC modes MXs should be ~50% of max (i.e. 750 tunnels and 500Mbps for hte MX600), ideally less so that in the event of a hardware failure, the failover MX of the failed primary isn't overloaded.  This is because spokes create tunnels to both/all MXs they have configured as hubs and without knowing this you can easily go over your max recommended tunnel count and have a bad time.  Also, if AutoVPN is configured this is further compounded by the fact the spoke MXs build over all transport networks too, so a spoke with 2 WAN connections to 2 VPNC mode MX build 4 tunnels total, 2 to each VPNC mode MX.  If the hub mode MX is routed mode and also has 2 WAN connections this doubles again! Meaning that proper scaling does come down to where the customer is on the risk/cost spectrum!   Outside of that, I would only recommend BGP from the MXs into the 'rest of the network'.  This enables bilateral learning and does so efficiently, you are not the first person to complain that I took away everything but AS path prepending as an option but we did so because fundamentally BGP is an EGP, and EGPs need that sort of complexity.  The problem is nowadays BGP gets used effectively as an IGP, you could argue we use it as such, as both sides of the eBGP relationship you need to configure will be under the same administrative control.  As such we simplified it for the majority of customer use cases, if you can tell me a reason to expose MED or local pref that we can't already accommodate with some other aspect of design I will make sure it's in the next iteration of BGP!  Please don't confuse conscious design to help people build and support networks easily with 'fisher price networking', yeah sure you might have always built networks like this' but we also used to used Frame Relay and ATM and I for one don't want those days back!  So, maybe look at the recommendations we do have with an open mind because we didn't make it that way to annoy some folks, we did it to help the most folks. On the CVD front, more are coming so watch out on the documentation site and if you need some more bedtime reading here are a few of the kbs we have in and around this topic (if my boring post didn't put you to sleep my boring kb articles might 😉  https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/Best_Practice_Design_-_MX_Security_and_SD-WAN/Meraki_SD-WAN https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/Best_Practice_Design_-_MX_Security_and_SD-WAN/SD-WAN_Internet_Policies_(SD-Internet) https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/Best_Practice_Design_-_MX_Security_and_SD-WAN/Meraki_Auto_VPN_General_Best_Practices  https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/Best_Practice_Design_-_MX_Security_and_SD-WAN/General_MX_Best_Practices  Cheers Steve ... View more

The information I quoted in the White Paper is the only information we can/will share without an NDA in place. ... View more

You can use ISE as a RADIUS server for 802.1x/EAP-on-LAN on the small branch MXs that support 802.1x on their LAN ports.  The RADIUS for splash page, the splash pages are actually served from the dashboard shard infrastructure.  Hence the RADIUS request actually comes from the dashboard, not the MX.  ... View more

The key material used for non-Meraki VPN is used until it is manually changed if you are seeing a need to change it this I presume would be dictated by the device/org you are peering with. ... View more

It's fair to say it's a hardware thing, as the CPU in the Z1 has much less capacity than the rest of the line (Z3 and up), we have seen Z1's working with IKEv2, however we are not comfortable dedicating the amount of CPU time to the IKEv2 process that that would require.  Hence, we took the decision to exclude Z1's from IKEv2.   With respect to you 'weakest link' question, that's a good analogy, but it's also worth standardising on a homogeneous technology set across your organisation (i.e. all or nothing) for both simplicity and diagnostic reasons. ... View more

Thanks for replying Ken, I have reached out to Priyank to correct him, as I assure you that IKEv2 is supported!  However, in your case I see you have a sizeable Z1 estate.  That's important as the Z1 doesn't currently support IKEv2, so it's not something you can implement as you have Z1's in your AutoVPN domain.   Cheers Steve ... View more

IKEv2 (along with AES256-CBC) can be configured for AutoVPN, just ask either support or your friendly Meraki CSE.  Also, the information about DH and AutoVPN above isn't correct (Dave you should have attended the MX session at SKO!).  As AutoVPN doesn't need/use DH as an MX-to-MX VPN connection has a shared management plane (dashboard), this means that mutual authentication and creating a secure connection (via DH) isn't needed per se.   This is mentioned in some detail in my latest blog post on the Meraki blog - https://meraki.cisco.com/blog/2018/06/all-about-autovpn/ and to a less extend in the original AutoVPN white paper.  Just remember that AutoVPN isn't full standard IPSec, its IPSec-like VPN, as there are some elements of the standard that it doesn't really make sense to burn the CPU clock cycles on when you're cloud managed.   Finally we investigating support higher DH groups e.g. 14 & 15 for non-Meraki VPN peers are its part of the NIST and NCSC standards for public sector entities.   HTH Steve ... View more