Connect. Secure. Manage.
Data Centre Interconnect Design
Design Cisco data centre interconnects around workload needs, available transport, route control and the consequences of losing a site or circuit.
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.
Data centre interconnect design sets out how two or more sites should work together. We plan the transport, routes and security before the build. The design checks capacity during recovery and what happens if a circuit or whole site fails. It also gives engineers a clear plan for running and restoring the service.
Workload-led design
Start with application, compute and storage dependencies rather than the switch model.
Clear failure domains
Understand which links, devices and sites can fail together.
Operational clarity
Make fabrics, external routing and management responsibilities supportable.
Establish the service and recovery objectives
We find the workloads that communicate across sites and the reason for that communication. Replication, distributed apps, management and user access can have different bandwidth and timing needs. The app and storage owners confirm which functions require continuous reachability and which can tolerate a planned recovery process.
The design distinguishes network recovery aims from app recovery commitments. Restoring a route does not prove that a database is consistent or that a business service is ready for users. We record the wider dependencies and the teams responsible for deciding when a failover can occur. This prevents the network topology from being used as evidence for an app guarantee it cannot provide alone.
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 where routed separation is sufficient
We assess whether sites can remain separate routed domains or whether chosen services genuinely need Layer 2 extension. Routed boundaries often simplify failure isolation and policy ownership, but app constraints may require another approach. The decision follows the actual workload needs rather than a default preference to preserve every address and VLAN during a migration.
Where a supported Cisco EVPN multi-site or similar architecture is appropriate, we define its roles and prerequisites clearly. The design separates fabric-local functions from the inter-site boundary. Hardware, software and scale are checked for the chosen combination. A feature available on one Nexus platform or release is not assumed to exist identically across the whole estate.
A useful starting point
Not sure where to start?
Bring the requirement. We will help you define the engineering work.
Specify transport characteristics and diversity
The transport schedule records handoffs, bandwidth, latency expectations, MTU and provider duties. We compare these with the needs of encapsulation, routing and app traffic. Any guarantee used in the design must come from an actual service agreement or checked evidence, not a marketing description of the circuit.
Diversity includes physical routes, building entry, carrier infrastructure, power and customer-edge equipment. We identify common dependencies and the confidence of the evidence available. The design also considers what happens when only one path remains: required traffic must fit the surviving capacity or have an agreed priority and restriction plan. Redundancy without usable degraded-state performance is not enough.
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 ↗Place gateways, borders and security services
Gateway location and route policy determine how apps use the interconnect. We set out permitted advertisements, summaries, defaults and the intended path in both directions. The design avoids accidental transit and makes clear how routes change when a site or upstream service becomes unavailable. Temporary migration routes are separated from the permanent architecture.
Security needs are reviewed independently of transport choice. Private network access does not on its own provide encryption or app filtering. We identify inspection points, stateful dependencies and the consequences of path changes. Shared services are limited to approved access, with tenant or app separation preserved where required. These controls are reflected in acceptance tests, not only in descriptive diagrams.
Design maintenance and recovery procedures
The architecture includes a workable sequence for circuit maintenance, device replacement and software changes. We identify whether the service can remain available during each task and what capacity or access limitations apply. The operations team needs alternative management access and a clear escalation route when the interconnect itself is impaired.
Recovery and restoration are modelled separately. Returning a site may require app validation before routes or gateways move back. We document those decision points and the authority needed to proceed. The network runbook should not automatically force a business service back to its original location when the data or app owners have not confirmed that it is safe.
Produce implementation and acceptance records
The design package can include topology, addressing, interface schedules, route policy, security boundaries and a test matrix. Each important need is linked to a verification method or a clearly stated limitation. Review with the participating teams resolves gaps before procurement or a cutover makes changes difficult.
MCI can deliver the design independently or carry it into rollout as part of our data centre interconnect services. We support UK organisations with local and geographically separated facilities. Share the workload needs, current fabric design and transport options to begin. The result will distinguish supported network behaviour, accepted risks and the app or supplier dependencies needed for a complete cross-site service.
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.