Connect. Secure. Manage.
Private Cloud Tenant Isolation
Design Cisco-based network separation between private cloud tenants, documenting permitted shared services and validating isolation with agreed tests.
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.
Private cloud tenant isolation controls which workloads, users and administrators can communicate across a shared platform. Separate network labels alone are not enough: the design must address routing, shared services and the management paths that cross tenant boundaries. MCI Network Services designs and tests the Cisco networking elements of isolation alongside the customer’s platform and security teams.
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 boundary that matters
A tenant may represent a customer, a business unit, a regulated workload or a development environment. We establish what the separation is intended to protect and which communication is legitimately shared. The requirements should identify both permitted flows and examples that must be blocked, giving the design a testable purpose.
We also clarify administrative separation. Two tenants may be isolated in ordinary application traffic while sharing privileged operators or a management platform. That can be appropriate, but it must be understood and governed. The networking engagement does not silently promise separation from every administrator with access to the underlying infrastructure.
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
Map enforcement across the full path
VLANs, VRFs, overlays and firewall policy may all contribute to the design. We identify where each control operates and what traffic it can see. A boundary enforced on an external firewall may not cover communication that stays inside a virtual host or fabric, so the platform team’s controls must be included in the wider assessment.
Route leaking and external connectivity receive particular attention. A shared default gateway or broadly imported route can create reachability that the tenant design did not intend. We document the allowed prefixes and services at each crossing point rather than relying on a diagram showing different coloured networks.
A useful starting point
Not sure where to start?
Bring the requirement. We will help you define the engineering work.
Treat shared services as deliberate exceptions
Identity, DNS, monitoring, backup and management services often need access to several tenants. These are useful functions, but their connectivity can become a route around otherwise sound separation. We agree the minimum required flows and the controls protecting each shared service.
The design also considers what a compromised shared system could reach. Networking can restrict access, but the service’s own security and privileged accounts remain relevant. Where the customer’s requirements exceed the protection available from the proposed shared architecture, we identify that gap rather than implying that another VLAN will resolve it.
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 ↗Consider addressing and workload movement
Overlapping tenant address spaces may be supported in a particular design, but they complicate shared-service access and troubleshooting. We examine the routing contexts and any translation involved so operational tools can identify the correct tenant. An address without its routing or tenant context may be ambiguous.
Workload mobility must preserve the boundary. We check that destination hosts, switches and gateways provide the same intended policy after a move or recovery event. Isolation that works only while a workload remains on its original host is not a suitable basis for a flexible private cloud.
Test prohibited access as well as permitted access
Acceptance includes authorised negative tests. We select representative source and destination combinations across tenants, management networks and shared services, then verify the expected outcome. Testing needs approval and a defined scope so it does not become unrestricted scanning of customer workloads.
A failed connection is not always proof of successful enforcement; the destination may simply be unavailable. We confirm the service is reachable through its legitimate path and correlate test results with relevant policy or forwarding evidence. This makes the record more useful than a list of unsuccessful pings with no explanation.
Examine failure and change behaviour
A failover, gateway replacement or temporary migration link can change the path through which isolation is enforced. We review these conditions and include suitable tests where practical. The objective is to avoid a design that becomes permissive during the very incident in which administrators are under the most pressure.
Changes to tenant policy need ownership and approval. New shared services, emergency access and temporary exceptions should have a purpose, an expiry or review point and an audit trail. An exception that remains indefinitely can undermine a carefully tested design without appearing as an obvious configuration fault.
Provide evidence without overstating compliance
The deliverable records tenant boundaries, approved flows, tested cases, observed results and limitations. It can support the customer’s security review or assurance programme, but it is not a certification of the whole platform or a guarantee against every form of compromise. Application and identity controls remain part of the customer’s broader responsibility.
MCI can assess existing isolation or incorporate it into a private cloud network architecture. We scope the Cisco work and coordinate the evidence needed from virtualisation, storage and security owners, producing a separation model that remains understandable as the platform changes.
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.