Connect. Secure. Manage.
Cisco ACI Fabric Design
Design a Cisco ACI fabric around application connectivity, leaf and spine roles, failure domains and the policy model the operations team will maintain.
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 ACI fabric design joins the physical switch layout to the rules that control app traffic. We plan ports, controllers, workload links and outside access together. The design explains the effect of faults and who owns each choice. That gives the rollout team a clear plan, with fewer gaps to resolve on site.
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.
Define the fabric’s role and boundaries
We establish which workloads will enter the fabric, which networks remain outside it and what business outcome the change supports. The scope may involve a new data centre, consolidation of a current estate or a staged migration. Application dependencies, security needs and limits on live changes are recorded before selecting the topology or policy structure.
The design distinguishes current needs from future possibilities. Planned capacity, workload mobility and extra sites are assessed as scenarios with stated assumptions. This avoids overbuilding for an undefined future while still preserving sensible expansion options. Where a need depends on unavailable or unverified functionality, it is listed as a gap rather than quietly included in the acceptance criteria.
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
Design leaf, spine and controller placement
We review supported switch roles, interface capacity, optics and physical placement. The topology needs sufficient capacity in normal and degraded states, with failure domains that reflect rack, power and site dependencies. Controller network access and resilience are considered separately from the forwarding links. The design should explain how management and policy operations remain recoverable when a component is unavailable.
Hardware and software compatibility are checked for the exact feature set. A device being part of a Nexus family does not prove that it supports the intended ACI role or scale. We document platform constraints and the implications for future additions. Physical installation needs, including airflow and cabling, are included so that the logical design can be delivered in the actual facility.
A useful starting point
Not sure where to start?
Bring the requirement. We will help you define the engineering work.
Establish infrastructure and tenant policy standards
Infrastructure policies define how equipment connects to the fabric; tenant policies describe the logical services and permitted communication. We create naming and allocation standards that make both layers understandable. Interface profiles, domains and pools are aligned with the actual endpoint attachment model rather than copied from an unrelated setup.
The tenant design identifies routing contexts, bridge domains, endpoint groups and the policy governing communication. We agree how apps and admin duties map to those objects. Shared services and exceptions are made clear. A design that simply reproduces every old VLAN without considering its purpose may preserve unnecessary complexity rather than deliver a clearer operating model.
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 borders and security integration
External routing determines how the fabric reaches the rest of the organisation. We set out L3Out placement, neighbours, route-control policy and security classification with the relevant teams. The design addresses forward and return paths and avoids accidental transit between external connections. Route availability and permission to communicate are treated as separate needs.
Firewalls and other stateful services need an agreed insertion and failure model. We review the supported integration and the effect of asymmetric traffic or a device transition. The ACI policy model does not remove the need to understand those services. Their ownership, maintenance and recovery duties remain visible in the overall architecture and acceptance plan.
Plan migration, maintenance and failure tests
The design includes a practical introduction path, especially where current apps cannot move together. Coexistence, gateway ownership and temporary extensions are documented with removal criteria. We find the conditions under which rollback remains possible and where app changes could make a simple network reversal insufficient.
Maintenance scenarios are considered before rollout. Software changes, switch replacement and expansion should have a supported sequence and a clear impact assessment. Acceptance tests are derived from the important needs, covering representative app access, denied paths and safe failure cases. The document states which behaviours must be shown during rollout and which require separate app or platform testing.
Deliver a design that supports engineering decisions
The handover can include architecture diagrams, addressing and object schedules, policy principles, interface standards and a risk register. Decisions are accompanied by their rationale so that later engineers can distinguish intentional choices from historical accidents. Review sessions with the customer’s teams resolve gaps before procurement or change windows make the design expensive to alter.
MCI can continue into ACI deployment or provide independent design support for a customer-led rollout. We work with UK data-centre and enterprise teams, keeping app, security and infrastructure duties clear. An initial scope needs the workload needs, current topology and project constraints. The output is a supported, reviewable design rather than a generic diagram labelled highly available.
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.