Connect. Secure. Manage.
Meraki Layer 3 Switching
Design routing on supported Meraki switches, checking interface, route and redundancy capabilities against the requirements of the wider network.
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 Layer 3 switching moves traffic between IP networks on supported switching platforms. That can improve the structure of a campus or branch, but gateway placement also determines where traffic is inspected and how failures affect users. MCI Network Services designs routed Meraki-managed switching around actual application paths, platform capabilities and operational responsibilities. We keep the distinction between switching, routing and firewall enforcement explicit, particularly when a customer is moving gateways away from an existing edge appliance.
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.
Decide where routing belongs
We map the local VLANs, servers, remote networks and internet path, then identify the device currently responsible for each gateway. The right location depends on capacity, security and resilience requirements. Moving every gateway to a switch may simplify forwarding but bypass an inspection point that previously controlled traffic between departments. That consequence must be understood before the customer approves the change.
The assessment also distinguishes a simple branch from a larger campus. A small site may need a limited set of routes and a clear transit connection to its firewall. A larger environment may require additional routing policy, scale or separation that only particular platforms support. We choose the design from the requirements rather than assume all Meraki-managed switches offer the same Layer 3 feature set.
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
Verify the supported routing capabilities
The exact model, software and management mode determine which interfaces, routing protocols and redundancy features are available. We review those details against the intended topology and record any limits that affect growth or recovery. A dashboard showing an option on one switch is not evidence that an older access model can fulfil the same role.
Management connectivity receives its own review. On classic MS platforms, management addressing and routed interfaces have specific relationships and restrictions that differ from some Catalyst cloud-managed arrangements. We follow the current documentation for the selected family rather than reuse an addressing pattern indiscriminately. The switch must retain a reliable management path while its own forwarding configuration is being introduced or changed.
A useful starting point
Not sure where to start?
Bring the requirement. We will help you define the engineering work.
Build the addressing and route plan
The design identifies each subnet, gateway address, DHCP dependency and route to upstream services. We check for overlap with VPN-connected sites, partner networks and existing infrastructure. Static routes and dynamic routing are chosen according to the supported capability and the operational need. A route that works today but cannot be withdrawn appropriately during a failure may not meet the service requirement.
Return paths are checked alongside outbound reachability. A local host can send traffic towards a remote service while the remote side lacks a route back to the new gateway. Firewalls and address translation can further complicate the result. We document the expected path in both directions and coordinate changes with whichever team owns the adjoining routing domain.
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 ↗Preserve the intended security boundary
VLAN separation is not enough when routed interfaces permit communication between those VLANs. We define which flows need restriction and where the applicable control will be enforced. Switch access lists, group-based policy and stateful firewalls have different capabilities and should not be described as interchangeable. The design states the chosen boundary and any traffic that deliberately crosses it.
For identity-aware requirements, Meraki Adaptive Policy Switching may be relevant on eligible platforms. Its assessment remains separate from basic IP routing. We do not assume that enabling a routing feature establishes end-to-end group enforcement or that a switch automatically replaces a firewall’s inspection and session-handling role.
Introduce gateways without competing ownership
A gateway migration needs a controlled sequence so old and new devices do not answer for the same address unexpectedly. We capture the existing configuration, identify affected endpoints and plan DHCP or static-address dependencies. The cutover includes upstream routes, security rules and monitoring changes where necessary. Each step has a verification point and a practical rollback method.
Testing covers representative local and remote applications, denied paths and the agreed failure scenarios. We inspect routing and forwarding state rather than relying solely on responses from a switch’s own interface address. Device control-plane responses and transit forwarding can behave differently, so the evidence should include traffic between actual endpoints.
Handover and ongoing changes
The final records include gateway ownership, route policy, management addressing and the service tests performed. Engineers should know how a new VLAN is introduced and who approves its access to other networks. Monitoring should expose a lost upstream route or degraded redundancy even when some local traffic still works.
MCI can prepare a new routed design, migrate an existing gateway arrangement or investigate an unstable deployment. Our IP Routing services cover the broader Cisco routing estate where a hybrid design is needed. The recommendation may combine Meraki-managed access with another routing or security platform when that better meets the customer’s feature and operational requirements.
Technical references
- Adaptive Policy configuration guide — Cisco / Cisco Meraki
- Cloud management with IOS XE overview — 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.