Connect. Secure. Manage.
Cisco Nexus Network Design
Design Cisco Nexus networks around workload connectivity, failure domains, bandwidth and the operating model required by the data centre team.
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 Nexus network design should explain how workloads connect, how traffic crosses the data centre and what happens when part of that path fails. A diagram containing two switches and several redundant links does not answer those questions on its own. MCI Network Services develops Nexus designs around the customer’s applications, physical environment and operational model, with enough detail to support implementation, acceptance and future change.
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.
Build a requirements picture before selecting topology
We collect the server, virtualisation, storage and external-connectivity requirements with the teams responsible for them. This includes expected traffic patterns, addressing, security boundaries and practical constraints such as rack space or cabling routes. The requirement should distinguish current demand from planned growth and identify which assumptions still need measurement or confirmation.
Availability is expressed through specific failure cases. We ask which workloads must survive a switch, uplink, rack or site failure and which application mechanisms provide additional protection. This prevents the network design from silently inheriting responsibilities that belong to compute or storage. It also makes clear where a simpler topology is sufficient and where more independent failure domains are justified.
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
Compare suitable architectural approaches
A smaller environment may need a straightforward Nexus pair with routed uplinks, while a larger estate may benefit from a leaf-spine fabric and VXLAN EVPN. We compare approaches against scale, workload mobility, segmentation and operational complexity. ACI is assessed separately where its policy model is appropriate. We do not add a fabric simply to make the design appear more advanced.
The chosen architecture defines where gateways, routing and inspection sit. It also explains how external networks connect and which services remain outside the fabric. These decisions influence fault isolation and future migration. A design that cannot explain its border behaviour is incomplete even if every internal link has been sized correctly.
A useful starting point
Not sure where to start?
Bring the requirement. We will help you define the engineering work.
Specify hardware, links and resource assumptions
We validate the selected Nexus platforms against required features, supported software and expected scale. Port speeds, breakout arrangements, optics, power and airflow are checked against the physical deployment. Logical capacity needs the same care: forwarding resources, routing scale and feature combinations can constrain a system before its physical ports are fully used.
Bandwidth planning includes oversubscription and degraded operation. The loss of one uplink or switch should not leave the surviving path incapable of carrying the agreed critical traffic. We document the calculations and any accepted limitations. The customer can then assess future additions against a clear design envelope rather than assuming unused ports always represent unused system capacity.
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 ↗Define server attachment and segmentation
The design specifies how hosts connect, including link aggregation or independent uplinks, VLAN presentation and MTU requirements. These choices are reviewed with the server or virtualisation team. A network-side configuration cannot guarantee host resilience if the operating system uses an incompatible bonding mode or places both physical links through the same dependency.
Tenant and application boundaries are documented separately from connectivity. We define permitted shared services, route exchange and security enforcement points. Management traffic is given an explicit path and access model. Where overlapping addresses or multiple routing contexts are involved, the design shows how engineers will distinguish them in monitoring and troubleshooting as well as in configuration.
Make failure behaviour part of the deliverable
For each important failure case, the design describes detection, forwarding changes and the expected application effect. vPC peer-link failures, loss of a routed uplink and an unavailable gateway are not treated as equivalent events. We identify which behaviours depend on specific platform support and which require validation during deployment.
Maintenance is considered alongside unplanned failure. Software upgrades, switch replacement and capacity expansion should have a workable sequence. A topology that survives one fault but cannot be maintained without a broad outage may not meet the customer’s operating requirements. We document the necessary maintenance assumptions and avoid promising non-disruptive upgrades without checking the exact release and feature combination.
Produce an implementation-ready handover
The design package can include high-level architecture, detailed interface and addressing schedules, configuration standards and acceptance criteria. It records dependencies, decisions and the reasons alternatives were rejected. Review with the customer’s technical owners allows unresolved requirements to be addressed before procurement or a production change commits the organisation to the design.
MCI can provide design-only consultancy or take the approved plan into Nexus deployment. We work with UK data-centre teams and multi-site organisations, keeping scope and ownership explicit. For an initial discussion, provide the workload requirements, current topology and constraints. The result will be a Cisco Nexus design that can be implemented and operated with a shared understanding of its capabilities and limits.
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.