Connect. Secure. Manage.
SD-Access Border Integration
Connect a Cisco SD-Access fabric to external networks, defining routing handoffs, shared services and the treatment of different virtual 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.
SD-Access border integration connects a Cisco fabric to the networks and services that remain outside it. That boundary often determines whether users can reach applications, whether segmentation remains meaningful and whether failover behaves as expected. MCI Network Services designs and implements border handoffs with explicit route policy, security ownership and end-to-end testing, rather than treating the border as a simple cable connection.
Cisco-focused engineering
Design around the platform, traffic and failure behaviour you actually operate.
Change with evidence
Use pre-checks, acceptance criteria and a documented route back.
Operational handover
Keep the configuration, diagrams and responsibilities understandable after delivery.
Map every external dependency
We begin with the destinations fabric users and devices need: data-centre applications, internet services, remote offices, identity systems and specialist partner networks. Each dependency is associated with the relevant virtual network and security requirement. This prevents a broad external route from becoming an unintended connection between otherwise separated groups.
The existing external topology is reviewed as carefully as the fabric. Firewalls, WAN routers and shared-service devices may have their own routing and resilience arrangements. We identify who owns each component and which team can approve changes. A fabric deployment should not silently assume responsibility for another provider’s network.
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
Choose a supported handoff model
The appropriate border role and handoff depend on the design and Cisco release in use. We review the supported Layer 3 and, where justified, Layer 2 options against the actual requirement. Preserving an existing subnet during migration is a different problem from connecting a new routed service, and the two should not be solved with the same default arrangement.
Where a fusion function is used to connect virtual networks with shared services, its routing and policy responsibilities are documented. A fusion device does not automatically provide the same inspection as a stateful firewall. We establish which component enforces the intended security boundary and how that enforcement is tested.
A useful starting point
Not sure where to start?
Bring the requirement. We will help you define the engineering work.
Keep route exchange narrow and explainable
We define the prefixes exchanged at each handoff, including default-route behaviour and any aggregation. Virtual routing contexts and route leaking are reviewed together. An external default can be useful, but it must represent a usable service and should not inadvertently collapse separate routing domains into one unrestricted network.
BGP or other supported routing mechanisms are configured according to the approved policy. Filters, peer details and failure conditions are recorded for operations. We also examine the return path: an external application needs a route back to the correct fabric destination, and its security devices must accept the path chosen during normal operation and failover.
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 ↗Make shared services reachable without opening everything
DNS, DHCP, authentication, management and logging often sit outside the fabric. They may need access from several virtual networks without allowing unrestricted communication between those networks. We turn these needs into explicit traffic requirements and coordinate the relevant routing and security configuration.
Service owners help define acceptance. For example, successful name resolution is not the same as successful authentication, and a DHCP relay test does not establish access to an application. The test plan covers the actual workflow and identifies which team will validate it. This avoids a handover in which every network team declares its own interface healthy while users still cannot work.
Review resilience across both sides of the border
Redundant border nodes need compatible upstream paths. We assess device roles, link diversity, routing preferences and the effect of an upstream firewall or WAN failure. Two fabric borders connected to one external gateway still share that gateway’s availability limit. The design should say so plainly.
We test selected failure and restoration cases where safe. Measurements consider representative traffic and any stateful dependencies, not only neighbour transitions. If a scenario cannot be exercised in production, the acceptance record states the evidence used instead. The result is a documented resilience boundary rather than a blanket claim of uninterrupted service.
Plan changes around the existing estate
Border integration often takes place while the old campus remains active. We identify temporary routes, overlapping subnets, gateway ownership and possible asymmetry during coexistence. The migration sequence should make it clear which network owns a destination at each stage and how that ownership changes.
Rollback includes both fabric and external configuration. Reversing only one side can leave stale routes or an unreachable shared service. We retain the baseline, agree change authority across teams and define when temporary handoffs will be removed. A completed migration should leave one understandable target design.
Produce a boundary that can be supported
MCI provides the handoff specification, route-policy record, test results and escalation map agreed for the engagement. These records support later changes to applications, WAN links and security policy. This work complements SD-Access fabric design and segmentation. A border review is also useful when an existing fabric has reliable internal connectivity but inconsistent access to the rest of the business.
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.