Connect. Secure. Manage.
SD-Access Fabric Design
Design Cisco SD-Access fabric roles and site boundaries, aligning underlay connectivity, addressing and policy with the intended campus architecture.
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 fabric design sets out how the Cisco network will meet your access needs. It covers addresses, device roles, rules and external links, as well as what happens when something fails. We turn those choices into a plan your team can review and test. The move from the current network is part of the design.
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.
Begin with a service and policy model
We confirm who and what will connect, which apps they need and which communications must remain separate. The design uses that information to define virtual networks, endpoint groups and shared-service access. A department name is not automatically a good segmentation boundary. The actual trust and app needs should determine the policy.
Capacity planning includes endpoints, routes, sites and expected growth, using the limits relevant to the chosen software and hardware. We avoid presenting a single scale figure as valid for every combination of features. For a design with several needs, assess whether the full set of features is supported together.
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
Place fabric roles deliberately
Fabric edge nodes connect endpoints, border nodes provide external network access, and control-plane functions support endpoint-location information. Roles may be combined or separated in supported designs. We choose the arrangement according to site size, resilience needs and operational complexity rather than applying one topology to every customer.
The design records the consequences of losing each device or path. Two logical roles on one chassis still share a physical failure domain. Similarly, a redundant pair can depend on common power or upstream services. These dependencies are made clear so the proposed availability can be compared with the customer’s need.
A useful starting point
Not sure where to start?
Bring the requirement. We will help you define the engineering work.
Make the underlay a stable foundation
The routed underlay needs consistent addressing, reachability and capacity for the fabric transport. We set out loopbacks, links, routing and the required MTU behaviour across the intended paths. Where Catalyst Center LAN automation is used, its prerequisites and setup ownership are included in the design rather than treated as an installation detail.
We also review cabling, uplink capacity and management access. A design should be supportable when part of the production path is unavailable. The recovery approach may include alternative access and documented local procedures, with their availability confirmed before rollout. A controller cannot compensate for an engineer being unable to reach a failed site.
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 ↗Design the boundary to retained systems
Most fabrics must connect to networks that are not being replaced. We document handoffs to firewalls, WAN services, data centres and shared infrastructure. Route exchange, virtual routing contexts and security enforcement are coordinated so that segmentation does not disappear at the first external connection.
The border design includes return paths and failure conditions. A permitted outbound route is insufficient if replies arrive through an incompatible firewall path. Shared services are considered individually, with a record of who owns their setup and testing. For detailed boundary work, see SD-Access border integration.
Include wireless and specialist traffic early
Wireless integration affects controller placement, access-point onboarding, endpoint policy and roaming. The design states whether wireless is fabric-enabled or follows another supported model. The current radio plan, client capabilities and support needs remain relevant regardless of the fabric architecture.
Multicast, building systems and apps with unusual addressing or discovery behaviour need clear assessment. We check which needs are supported directly and which need a pilot, an alternative attachment model or a design exception. The aim is to discover incompatibility before migration, not to explain it after a critical endpoint has been moved.
Define acceptance and rollback while designing
The design includes tests that show the intended outcomes. These cover endpoint admission, allowed and denied traffic, shared services, external routes and chosen failures. Test cases should name representative endpoints and apps. A generic instruction to check network access is too vague to establish whether the design has met its purpose.
Migration and rollback are developed alongside the target state. We find the temporary interfaces between old and new networks, the order of changes and the criteria for reversing a cutover. Some steps may have limited reversibility or require extra preparation; those constraints belong in the approved design, not in a late rollout note.
Deliver a usable engineering package
MCI’s design output can include high-level and low-level documents, addressing and policy matrices, role assignments, rollout dependencies and an acceptance schedule. The exact deliverables are agreed for the project. Version control and approval duties keep the rollout aligned with the reviewed design.
Our Cisco network services support both customer-led rollouts and projects delivered by MCI. An independent design review can also be useful before a major campus change. Bring the current topology, business aims and known constraints. We will use them to define a fabric that fits the setup rather than forcing the setup to fit a standard diagram.
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.