Connect. Secure. Manage.
Cisco EVPN Multi-Site Interconnect
Assess supported Cisco EVPN multi-site connectivity, defining border gateways, inter-site routing and fault isolation across separate fabrics.
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.
Cisco EVPN Multi-Site interconnect links supported fabrics through defined border points. We plan which tenant services cross sites and which remain local. Routing rules and failure boundaries are part of that plan. Tests check the design against your Nexus devices, software and transport links before the service is accepted.
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.
Confirm the requirement for multi-site connectivity
The customer may need chosen network extension, shared services or workload movement between separate fabrics. We find the apps and the reasons behind each need. A general request for geographic resilience does not on its own justify stretching every segment. The architecture must also account for app and storage recovery, which remain separate from network reachability.
We review the current fabrics, their management ownership and the intended scale. Supported multi-site capabilities depend on the chosen hardware and releases. We identify prerequisites and any required lifecycle changes before proposing production integration. An architecture diagram from a different setup is not enough evidence that the same border design is suitable here.
Standards & partnerships
Confidence in the team behind your network.
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
Define border-gateway and transport roles
The border design specifies how each fabric connects to the inter-site network and how the relevant control-plane information is exchanged. We document device roles, addressing and policy ownership. This separation helps engineers distinguish a local fabric problem from an inter-site transport or border issue during an incident.
The transport is assessed for reachability, MTU, bandwidth, latency and failure behaviour. It may be operated by a separate team or provider and needs its own escalation and maintenance arrangements. We do not assume that fabric-management tooling configures or checks every external dependency. The design records what must already exist before the multi-site service can be enabled.
A useful starting point
Not sure where to start?
Bring the requirement. We will help you define the engineering work.
Limit the services extended between sites
We find the tenant networks and routing functions that need to span the boundary. Local services remain local where that meets the need and reduces shared risk. Identifier and route-policy consistency are reviewed for the chosen design, with allocation standards that prevent accidental overlap or broad import of unrelated tenant information.
Layer 2 extension receives particular scrutiny because it can carry broadcast and endpoint-related effects across locations. We document the reason for each extended service and the behaviour expected during a partition. Security inspection and approved route leaking are designed separately. The ability to carry a tenant network between sites is not equivalent to permission for every cross-site app flow.
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 ↗Model path, site and border failures
The design considers loss of an inter-site link, a border device and an entire location as different events. We explain which routes remain available and which services depend on the failed component. The surviving path must have sufficient capacity for the agreed critical traffic, or the operating plan must state what will be restricted during the incident.
Application consistency and failover authority are reviewed with their owners. The network cannot safely decide every recovery action on behalf of a clustered app. We identify shared DNS, identity, security and storage dependencies that could undermine a multi-site availability claim. Those limitations remain visible in the design and acceptance documentation.
Introduce connectivity through a bounded pilot
Implementation begins with reviewed setup, prerequisites and rollback conditions. We check transport and border state before adding a limited set of tenant services. The pilot checks both local and cross-site app paths, intended separation and the evidence from the live network available for troubleshooting. A healthy control-plane session is not the sole acceptance criterion.
Authorised failure tests include restoration where practical. Returning a site or path can produce another transition, and the expected result must be understood. We record observed interruption, route changes and app outcomes, while identifying scenarios that were not exercised. The handover does not convert documented feature support into a claim that every production failure has been proven harmless.
Maintain the inter-site boundary deliberately
The operating record includes border roles, transport references, extended services, route policy and escalation contacts. Changes to either fabric are assessed for cross-site effects. Software compatibility and management workflows are reviewed together so that one site’s routine maintenance does not introduce an unsupported combination at the boundary.
MCI can build a new multi-site interconnect or review a current Cisco rollout. Related work includes EVPN architecture and data centre interconnect design. Provide the fabric inventories, tenant needs and transport details to begin. We will define a supported integration with clear ownership and a test plan tied to the business services it must carry.
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.