Connect. Secure. Manage.
Meraki Campus Fabric External Routing
Plan the routing handoff between a Meraki-managed campus fabric and existing networks, checking route control and shared-service dependencies.
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 campus fabric external routing connects logical fabric services to the applications, WAN links and security systems outside the fabric. MCI Network Services designs and validates these handoffs so reachability, route ownership and policy remain clear at the boundary. We consider both directions of traffic and the effect of failures, rather than treating an established routing neighbour as proof that users can reach the right services. External integration is part of the production design, not an afterthought once the internal fabric appears healthy.
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.
Identify every service that crosses the boundary
We map internet access, data-centre applications, other offices and shared infrastructure services. Each connection has an owner and an agreed set of permitted networks. This is particularly important where the fabric and external firewall are managed by different teams: both sides need the same understanding of which prefixes are authoritative and which traffic should be inspected.
The register includes return paths and dependencies such as DNS, DHCP relay and authentication. A client may have a valid address and a healthy local gateway yet remain unable to work because an external service has no route back. Recording the complete flow helps avoid a narrow acceptance test that proves only one direction or only a test generated by a network device.
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
Select the supported handoff method
The appropriate design may use a supported BGP-based VRF-Lite handoff or static routing, depending on scale, change frequency and the capabilities of the external network. We verify the current platform and release support before specifying the arrangement. A small stable prefix set has different operational needs from a boundary that must exchange many changing routes.
We document the interfaces, routing contexts, addressing and adjacency requirements on both sides. The handoff specification should be usable by the external provider or firewall team without relying on an informal conversation. Where a feature is unavailable on the selected platform, we identify a supported alternative or a design constraint rather than assuming that generic BGP or VRF knowledge proves implementation support.
A useful starting point
Not sure where to start?
Bring the requirement. We will help you define the engineering work.
Keep route exchange explicit
Import and export policy should describe the routes the fabric may accept and advertise. Default routes, aggregates and more-specific prefixes need deliberate treatment. We examine what happens when an underlying destination disappears and whether a summary could continue attracting traffic to an unavailable service. The intended withdrawal behaviour is part of the design.
We also review any exchange with another routing protocol outside the fabric. Redistribution can introduce feedback or unexpected path selection when several boundaries exist. Our Cisco route redistribution work addresses those risks where relevant. The objective is a limited, understandable policy, not unrestricted exchange followed by ad hoc filters after an incident exposes a problem.
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 segmentation through shared infrastructure
External routing should not accidentally merge networks that the fabric separates internally. We identify which routing contexts must remain independent and where approved shared-service access occurs. If a firewall mediates communication, its policy and routing need to be reviewed together. A permitted route is not the same as an approved application flow.
Stateful services add another dependency. Forward and return traffic may need to traverse the same logical security path for sessions to work. We assess asymmetry during normal operation and failure, including the effect of multiple border connections or upstream gateways. The result should explain how the design preserves the required service rather than simply showing that more than one route exists.
Test the boundary under realistic failure conditions
Acceptance checks include expected advertisements, selected routes and representative endpoint traffic. We compare the fabric and external device views, then test the applications that motivated the connection. For a resilient design, we agree which links or peers can be withdrawn safely and observe the effect on new connections and existing sessions.
Restoration is tested as well. A preferred path returning can change traffic again, and the effect may differ from the initial failure. We record the observed behaviour and any limitations imposed by the external service. The report separates network convergence from application recovery so a quickly restored route is not presented as a guarantee that every session continued without interruption.
Hand over a boundary that both teams can support
The operating record includes peer details, prefix policy, normal paths, expected alarms and escalation contacts. It identifies which changes require coordination across the boundary, including new subnets, shared-service moves and modifications to firewall policy. This reduces the risk of one team making a locally reasonable change that breaks the service for the other.
MCI can provide external-routing design, implementation or fault investigation as part of Meraki campus fabric services. We work with customer teams and relevant providers to establish the handoff before production traffic moves. The final scope makes clear which components MCI controls, which remain with another supplier and what evidence is needed when an incident crosses those responsibilities.
Technical references
- Cloud-managed EVPN fabric technical guide — Cisco / Cisco Meraki
- Cloud fabric architecture — 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.