The Diagram below shows a high level diagram I recently did for an International customer. All Meraki devices seen below can be deployed, configured and monitored from the Meraki Dashboard. we also have the option of doing the same with API’s, a ton of which are already created and can be found at the Github.
Hardware
MX 67c at the Branches
MX 450 x2 at the Two DC’s
MS120-48 port switches
MR 42 and MR 33 Access points at the branches
Customer Background
The customer has over a 1000’s branches in Canada along with two Data Centers. They have a mix of MPLS, broadband, and LTE as an underlay network and the sites are split as follows:
- Category A sites have MPLS and Internet
- Category B sites have one link of BID ( an internet connection with an SLA) and second as a BIS (an internet connection with an SLA)
- Category C has one BIS and one LTE connection
They all connect back to both the DC’s for full redundancy in case of link or DC failure.
DC Setup and Deployment
The first step in setting up this topology is to onboard all the devices to the Meraki Dashboard with proper licenses. All that is required to do this is to add the serial numbers of the devices and all devices can be onboarded with a single click.
Internet connectivity is a must to configure and activate the Meraki devices.
After onboarding, We first connected the DC side MX450’s to the Customer L3 switch in One-Armed Concentrator mode with High availability setup. As per meraki recommended design, an MX deployed in an one-armed concentrator is preferred datacenter design. To enable inter-VLAN routing and reachability, some static routes may need to be added to the L3 switch if not using dynamic routing (BGP or OSPF in limited capacity). As per Meraki “An MX VPN concentrator with OSPF route advertisement enabled will only advertise routes via OSPF; it will not learn OSPF routes.”
To route traffic from the DC to the internet we have to configure the NAT on the firewall. Most of the time this step is overlooked. According to Meraki ” Placing an MX appliance configured as a one-armed VPN concentrator at the perimeter of the network with a publicly routable IP address is not recommended and can present security risks. As a best practice, one-armed concentrators MX appliances should always be deployed behind an edge firewall that filters inbound connections.”
As all the devices can be managed and configured from the Meraki Dashboard, It really makes the job really easy. The Dashboard is cloud based so we have to make sure that the relevant destination ports and IP addresses are allowed through the Firewall. The ports that must be open are listed under Help>Firewall Section on the Dashboard.
Branch Setup and Deployment
First, you need to make sure that the appliance can connect to the Internet and access the Meraki Dashboard.
In the above design, the MX67c deployed at the branches are the default gateways and DHCP servers for all the Customer VLANs. The Uplink decision is made on the Custom policies configured on the MX.
After completing the configuration we created the templates for 3 types of sites. The Templates really simplify the deployment process of the new sites. Meraki is much simpler to manage as compared to Juniper/MIST because of its single pane of glass approach. With Juniper/MIST one still has to use two separate dashboards (CSO and Mist) to manage all the SD-WAN and Wi-Fi devices. Both the vendors do provide excellent API support for remote configuration changes.
For detailed configuration information please use the link below to find the relevant deployment guide
https://documentation.meraki.com/MX/Deployment_Guides
The MX appliances allow auto-provisioning of IPsec VPN tunnels between sites. VPN routes, authentication and encryption protocols are automatically negotiated by the Meraki Dashboard for all Meraki MX appliances to create hub-and-spoke or mesh VPN topologies.
References: