Connect. Secure. Manage.
Meraki MX VLAN Routing
Design VLAN interfaces and routing on Meraki MX, checking subnet ownership, DHCP dependencies and traffic paths between local and remote networks.
Devices supported
across the UK
Client locations
supported
Traffic handled
at peak time
Average
response time
Average response is not a resolution time or a contractual guarantee. Support scope and response commitments are agreed for each engagement.
Meraki MX VLAN routing defines how local networks reach one another, remote sites and the internet through the branch edge. The configuration must agree with the switches, address-allocation services and security rules around it. MCI Network Services designs and reviews these paths so that VLAN numbers, gateway addresses and VPN participation represent a coherent service. We focus on both reachability and separation, because a device obtaining an address does not prove it has the right access.
Dashboard clarity
Structure organisations, networks and permissions around real operational ownership.
Consistent sites
Use repeatable standards without ignoring the differences between locations.
Practical operations
Keep cloud management connected to physical links, users and business services.
Map the networks and their owners
We identify the purpose of each local segment, its endpoints and the applications it needs to reach. Staff devices, guests, voice systems and building equipment may require different paths and restrictions. The design records the subnet, gateway and DHCP owner for each network. It also identifies which segments should remain local and which need access through a VPN or another routed connection.
Existing addresses are checked against remote sites and partner networks. Overlap can create ambiguity once a site joins a wider estate, even when the subnet works perfectly within the branch. We resolve the addressing plan before deployment or document a separate renumbering project. A temporary translation workaround should not become the default answer to every collision without understanding the operational consequences.
Standards & partnerships
Confidence in the team behind your network.
Cisco Partner
Cisco Meraki
Cyber Essentials
Cyber Essentials PlusMCI Network Services is operated by Proxar Ltd. Certifications apply to the certified legal entity and the scope of its certificates. View accreditation information
Decide whether the MX should host every gateway
An MX can provide the appropriate routed role in many branch designs, but some sites need downstream Layer 3 switching or another specialist router. We assess capacity, security enforcement and supported features before choosing gateway placement. Moving a gateway changes the traffic path and can change which device inspects communication between local networks.
Where routing is shared, the transit connection and route ownership are made explicit. The MX needs the correct path to downstream subnets, and those subnets need a valid return route. We avoid duplicate gateway addresses or competing DHCP services introduced during a migration. Our Meraki Layer 3 Switching service can define the downstream role when a switch is part of the routed design.
A useful starting point
Not sure where to start?
Bring the requirement. We will help you define the engineering work.
Align VLAN tagging across the access layer
The edge configuration must match the switch ports that carry each network. We review trunks, allowed VLANs and untagged traffic expectations, then trace the path to representative endpoints. A VLAN created on the MX but absent from an uplink produces a different fault from a client receiving an address from the wrong scope. Clear port descriptions and a current diagram make those cases easier to distinguish.
Wireless adds another dependency. An SSID’s addressing and VLAN behaviour must agree with the edge and switching design. We document whether clients are bridged locally, handled through another supported mode or carried to a different gateway. A wireless network name does not establish its routing boundary, so the actual packet path is verified during commissioning.
Different environments. The same care.
Built around the work
your network supports.
Finance, banking and the wider private sector. We start with the systems and people that depend on your connections.
Finance & banking
Market-data paths, routing and provider coordination on clients’ behalf.
Financial-market services ↗Offices & multi-site teams
Reliable access between people, workplaces and business applications.
Office network design ↗Data centres & cloud
Network boundaries, workload connections and operational ownership.
Data centre networks ↗Define permitted communication
Routing between segments should follow the business access policy. We identify the required shared services and the restrictions for guests or untrusted devices. A separate VLAN is not an isolation guarantee once a device routes between it and the rest of the network. The relevant firewall controls and any additional enforcement points are therefore included in the design and acceptance tests.
VPN advertisements need the same care. Only the intended local networks should be made reachable to remote sites, with remote policies and return routes checked by their owners. We distinguish a tunnel being established from a particular application being permitted. This avoids a common handover gap where the network appears connected but nobody has verified DNS, authentication or the server-side path.
Migrate without confusing endpoints
Gateway or DHCP changes are planned around how clients obtain and retain their settings. Static devices, long-lived leases and cached neighbour information can complicate a cutover. We identify the affected populations, sequence the changes and define what local assistance is needed. The implementation record states when old services are removed and how to restore them if the new path fails validation.
Acceptance tests include fresh address acquisition, name resolution and application traffic from each representative segment. We also test paths that should be denied and inspect the selected route for remote services. Failover checks are included where the edge design provides alternate connectivity. The outcome is recorded at the service level rather than reduced to a list of configured VLAN interfaces.
Keep future additions controlled
The handover includes a subnet register, gateway ownership, uplink map and security-policy references. A new VLAN request should state its purpose, required destinations and operational owner before configuration is created. This prevents the estate accumulating undocumented segments whose access nobody can explain.
MCI can review an inherited branch, add a controlled segment or migrate gateway functions as part of Meraki branch networks. We support Cisco and Meraki environments across the UK and coordinate with existing IT, application and carrier teams. The agreed scope identifies which parts of the path we can change and which require another party’s approval.
Technical references
- MX addressing and VLANs — Cisco / Cisco Meraki
- Site-to-site VPN settings — Cisco / Cisco Meraki
Talk to a specialist
What does your network need next?
Tell us what you are planning, changing or trying to improve. We will help define a practical next step and the engineering scope.
+44 203 196 6566Choose option 1
sales@proxar.co.ukUK-wide service.
Most of our engineers are based in Kent, with a focus on London, Sussex, Essex and Berkshire.
Existing customers should use their agreed support and escalation channels. This form is for service enquiries, not a monitored emergency ticket.
Tell us what you need.
A short outline is enough. Please do not include passwords or sensitive network details.
Thank you. Your enquiry has been submitted.
Please check your name, email and message, then try again.
Your form session expired. Please try again.
Please wait a minute before sending another enquiry.
We could not submit your enquiry. Please call or email us instead.