AI-Ready Private Cloud with Cisco and VMware

An AI-ready private cloud is not simply a private cloud with GPUs added to it. What determines whether a private cloud platform can actually serve AI workloads effectively is everything built around them: how the fabric carries traffic, how the tenancy model lets teams consume capacity, and how policy and telemetry stay coherent across the virtual and physical boundary. Networking is a key component in the future of the datacenter, and it introduces new and interesting challenges.

This is where the joint work VMware and Cisco are doing across VMware Cloud Foundation (VCF) and Cisco Nexus One Fabric matters. This is work customers have been asking for, and we’re excited to deliver on this. So let’s take a look at what we’ve been doing and especially why.

AI workloads change the traffic profile in both directions

Traditional enterprise virtualization produced a reasonably stable pattern. Most traffic stayed east-west inside the cluster. North-south was the smaller, better-understood fraction, which is why concentrating it through a centralised gateway was a sound design.

AI workloads are changing the general assumptions of network traffic – they have their own patterns and they tend to go both East-West and North-South but in a more intensely saturated fashion.

• East-west becomes bandwidth-dominant and latency-sensitive during distributed training. Gradient synchronization across nodes is a collective operation, and a collective finishes when its slowest participant finishes. A single congested link does not degrade the job proportionally; it sets the pace for every GPU in the ring. This is why AI fabrics are engineered for lossless or near-lossless behaviour with RoCEv2, priority flow control, and explicit congestion notification, and why buffer behaviour on the leaf matters far more than it does for a general-purpose workload.
• North-south becomes bursty and unpredictable. Training data is pulled from object storage that frequently sits outside the cluster. Model artifacts move between development, staging, and production environments that are not colocated. Inference endpoints serve consumers across the enterprise and sometimes outside it. Retrieval-augmented pipelines make external calls on the request path, which puts north-south latency directly into user-facing response time.

You cannot size a fixed north-south chokepoint for that profile, because the profile changes every time a team ships a new model.

Distributed forwarding, and why it follows from the above

VCF 9.1 introduces the distributed Transit Gateway. North-south forwarding moves onto the ESX hosts themselves. Each host forwards for its own VMs, encapsulates in VXLAN, and hands traffic to its local leaf. The Route Controller maintains BGP EVPN peering with the fabric on behalf of the hosts, so the control plane remains centralised and operationally manageable while the data plane is not.

Some practical and noteworthy consequences:

Egress capacity scales with host count. Adding GPU nodes to a training cluster adds north-south capacity at the same time, rather than pushing an existing shared gateway closer to saturation.

The path is one hop to the fabric. A packet leaving a VM is encapsulated on its own host and lands on the leaf that host is cabled to. Latency stops depending on where a gateway appliance was placed relative to the workload.

ECMP across leaf uplinks applies to the traffic immediately. Hash distribution happens across the fabric’s full uplink set rather than across whatever the gateway’s own connectivity happens to be.

Host capacity previously dedicated to edge appliances returns to workloads. In an environment where GPU-attached hosts are the expensive resource, not spending general-purpose capacity on a forwarding tier is worth accounting for.

One encapsulation, one control plane

The integration point between VCF and a Cisco Nexus One fabric is BGP EVPN, spoken natively by both sides. Inside the workload domain, VCF Networking uses GENEVE between hosts. At the boundary, the Transit Gateway encapsulates in VXLAN and the Route Controller exchanges routes with the leaf switches over BGP EVPN. There is no gateway translating between the two models.

A single EVPN control plane means a MAC or IP that moves is a control plane event visible on both sides, which is the difference between correlating a workload move against fabric state and inferring it. It means troubleshooting a path involves one route table concept rather than two, examined from either end. And it means the fabric’s own telemetry has something to correlate against.

On the Cisco side, the Nexus One approach keeps this consistent across ACI, NX-OS, and SONiC choices and brings together on-premises and cloud-managed operating models through Nexus Dashboard and Nexus Hyperfabric respectively, sharing a VXLAN EVPN data plane, a common policy construct in Endpoint Security Groups, and common visibility, under a unified architecture. The fabric operating model your network team prefers and the VCF integration are separable decisions. The protocol interface is the same either way.

Telemetry and observability across platforms

For AI workloads the interesting failures are not link-down events. They are the ones where a training job takes 40% longer this week than last week and nothing is obviously broken. Diagnosing that requires seeing microburst behavior, buffer occupancy, and ECN marking rates on the fabric, and correlating those against workload placement and VM-level counters on the platform.

What makes that correlation possible is the route exchange itself. The Route Controller advertises endpoint MAC and IP addresses and subnet prefixes into the fabric as EVPN routes, and the leaf installs them in its own table. In the data plane, the source VTEP is the originating ESX host. Previously the Tier-0 summarised everything behind a few edge node interfaces, so the fabric saw traffic but not who was sending it.

ASIC-assisted telemetry on the Nexus One side provides the fabric half at a granularity that polling cannot reach. Because both sides share EVPN state, workload identity is common between them. Buffer occupancy on a port resolves to a named host, and a vMotion arrives as a control plane update rather than being inferred after traffic shifts.

Consumption: building the public cloud model on premises

Infrastructure that requires a ticket for every subnet will be routed around. It’s happened before and it will absolutely happen again. 

The VPC model addresses this by fixing the boundary in advance. The provider, typically the network team, configures physical fabric access and pre-allocates network resources to tenants with quotas and limits. A tenant admin selects from the connectivity options the provider published and creates VPCs within that quota. A VPC admin creates subnets and attaches workloads.

Each layer operates independently inside limits set by the layer above. The network team is not approving subnets one at a time, and the AI team is not waiting on them. Isolation between tenants is enforced structurally, which matters when several teams share GPU infrastructure and their data cannot mix.

The compute side of the same picture

VCF delivers this against three consumption models on one control plane: VKS for Kubernetes-managed containers, KubeVM for declaratively managed VMs, and Containers as a Service for containers in vSphere Pods without Kubernetes scaffolding. A typical AI application uses more than one, with inference serving in containers and a vector or relational database in a VM, sharing namespace, RBAC, and quota.

Underneath, GPU vMotion with DRS and GPU reservations make accelerators schedulable resources rather than statically pinned hardware, and high-speed adapters and DPUs keep distributed training and multi-node inference off the CPU for data movement.

VMware’s support for Cilium as an alternative CNI add-on for VKS 3.6 and later adds another important dimension. It gives VKS customers a supported path to an eBPF-based data plane, and Kubernetes and Cilium network policy. Separately, Cisco’s supported Nexus One–Isovalent integration shows how Cilium-based workloads can participate natively in an EVPN-VXLAN fabric. 

These are complementary developments. The strategic value is that each layer can do its job while aligning around open interfaces: VCF provides the private cloud and VPC consumption model; VKS provides Kubernetes lifecycle and platform operations; Cilium provides cloud-native networking, security, and observability; and Nexus One provides the network fabric and consistent network operating model that connects those domains to the rest of the enterprise.

Designing for the AI-ready datacenter

Measure current north-south utilisation before sizing anything; most teams have never had a reason to and the shape is usually not what they expect. Treat buffer and congestion behaviour on the leaf as a first-class design input. Decide the provider and tenant boundary before the first VPC exists. And plan capacity as a growth curve tied to host count, which is the property distributed forwarding gives you.

The result is a platform where adding AI workloads is a capacity decision, not an architecture project.

Conclusions and where this goes

None of this requires starting over – it’s exactly the opposite. It’s taking advantage of what you already have. The Nexus One fabric already speaks EVPN, and so does VCF. What changed is that the two halves now exchange state directly rather than meeting at an appliance that summarized away most of what each side needed from the other. The hardware is the hardware you bought, and the people who read BGP tables and the people who size workload domains are the ones who will operate it. 

The reason this matters is because the usual answer for AI infrastructure is a separate stack: its own fabric, its own operational model, its own team. That gets the first cluster running and becomes a problem at the second. Keeping these workloads on the same platform and the same fabric means capacity added for one purpose stays available for others, and the next class of workload is a capacity decision.