When planning and deploying your Auto VPN topology, there are several best practices to keep in mind to ensure optimal performance. The first and most important practice is to ensure that the model of MX deployed at each location is capable of handling the required load. As discussed in the “MX Scaling” section earlier in this chapter, different models of MX hardware have different maximum capabilities, so it’s crucial that the chosen model of device is capable of supporting the expected load not only from the number of connected tunnels and peers, but also for any additional security features that will be configured.

Properly sizing your model selection is imperative to designing a deployment that will be able to provide consistent and stable performance not only on initial deployment but also for the foreseeable future and accommodate any expected growth. For example, a deployment that currently consists of only five satellite sites with a single main hub may be able to operate the hub using a mid-tier model of hardware for the initial deployment, but if the number of satellite offices is expected to expand rapidly over the next two years, the original hub MX device may not be able to fully support the future number of required tunnels and security features without a noticeable performance impact. This, of course, depends heavily on many factors specific to the deployment, such as how many tunnels are needed, the amount of traffic passing through those tunnels, and the number and types of additional security features configured. However, proper sizing is a very important aspect to keep in mind during the initial planning phases of the deployment.

Pro Tip

Voice (VoIP) and other small packet traffic is notorious for a high performance impact compared to other types of traffic for all firewalls, not just Meraki devices. This may impact your sizing decisions depending on the type of traffic that is expected to pass over Auto VPN. Therefore, it’s important to analyze and understand the types of traffic that are passing through your networks.

To ensure proper sizing when planning your deployment, we recommend engaging the Meraki sales organization or your local VAR, who can assist in proper review of your deployment and make additional sizing recommendations based on projected future use.

Leave a Reply

Your email address will not be published. Required fields are marked *

Explore More

Network-wide Multicast Topology – Building a Scalable Foundation with Dashboard – Cisco Meraki

For networks that have multicast routing enabled, you can configure the Layer 3 Topology page to show the current multicast topology as an overlay on top of the existing Layer

L3/L7 Firewall – MX and MG Best Practices – Cisco Meraki

As previously mentioned, the MX line of security appliances is capable of L3 stateful access control in addition to more advanced inspection and filtering. Alongside the standard Layer 3 IP-based

Automated API-based Organization Status – Automating the Dashboard – Cisco Meraki

To start, you need to determine the organization IDs for the organization you want to monitor. You can do so by sending a GET request to the endpoint as shown