Isovalent Networking for Virtualization (INV) Integration with Cisco Nexus One Fabric Solution Overview
Available Languages
Bias-Free Language
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Unified cloud-native and data-center networking with VXLAN EVPN
As enterprises modernize their infrastructure, the boundary between traditional virtualization and cloud-native platforms continues to blur. Organizations are increasingly running Virtual Machines (VMs) alongside containerized workloads on Kubernetes (K8s), yet the networking and security models between these two worlds have historically been disconnected. Bridging this gap requires a fabric architecture built on open standards and a unified operational model.
Isovalent® Networking for Virtualization (INV) addresses this gap by extending cloud-native networking to virtualized workloads while integrating with the Cisco Nexus® One data center fabric. Built on the VXLAN EVPN standards that Cisco helped define at the IETF, this integration creates a unified, distributed, and identity-aware network that treats Kubernetes-hosted VMs and pods as first-class citizens of the enterprise fabric.
Enterprise data centers today run a mix of bare-metal servers, traditional VMs, and Kubernetes clusters with different networking models, security boundaries, and operational tooling. This fragmentation creates real operational challenges: separate network overlays for VMs and containers that do not share a common control plane; security policies that stop at the cluster boundary, with no identity continuity between Kubernetes and the traditional network fabric; and operational complexity from managing multiple networking stacks, each with its own provisioning, monitoring, and troubleshooting workflows.
The foundation: Isovalent Private Network (IPN)
At the heart of INV is Isovalent Private Network (IPN), the foundational construct for building the equivalent of a Virtual Private Cloud (VPC) in Kubernetes. An IPN is defined through the ClusterwidePrivateNetwork Custom Resource Definition (CRD), a Kubernetes-native construct for creating isolated network domains for virtual machines and pods.
IPN key capabilities:
● Isolation and multitenancy: IPNs deliver full network isolation, ensuring strict separation between tenant networks for secure multi-tenant environments.
● Advanced topologies: IPNs support overlapping IP ranges between tenants, hybrid IPv4/IPv6 deployments, and fully isolated network segments to address complex enterprise use cases.
● Native Kubernetes: Because IPNs are native Kubernetes resources, network segments can be managed declaratively using standard GitOps workflows and tooling.
In summary, IPNs provide isolated, multitenant networks for KubeVirt VMs and pods, directly aligned with how modern platform teams operate.
Seamless fabric integration through VXLAN EVPN
An IPN only delivers value when it can communicate with the rest of the data center. An IPN supports several integration models, with VXLAN EVPN being the center piece for Cisco NX-OS fabric integration.
In this model, every Kubernetes node peers directly with its connected Top-of-Rack (ToR) switch (or pair of switches for redundancy) using MP-BGP EVPN, and advertises Type 5 EVPN routes into the fabric. This is the same VXLAN EVPN control plane that the Cisco Nexus One fabric—running NX-OS—uses across the data center; this means that Kubernetes nodes are not bridged or proxied into the network but participate natively as EVPN speakers within the Nexus One fabric.
Native K8s Node Integration with Cisco® DC Fabrics via MP-BGP EVPN
Why this matters:
● Fully distributed model: Every Kubernetes node can participate as an EVPN speaker. Routing is distributed across the cluster without reliance on a centralized gateway appliance.
● VXLAN tunnel scale: Kubernetes nodes terminate VXLAN tunnels at their directly connected ToR switch, rather than building a full mesh of node-to-node tunnels. This dramatically reduces the total number of VXLAN tunnels in the environment and leverages the routing in and out of tunnels (RIOT) capability of Cisco NX-OS.
● Host-route advertisement: VM and pod IPs are advertised as EVPN Type 5 /32 or /128 host routes, allowing Cisco NX-OS leaf nodes to learn the location of each workload through the EVPN control plane.
● First class fabric citizenship: Kubernetes-hosted workloads communicate with any other endpoint on the fabric (bare-metal servers, traditional VMs, network services) as native participants, with no Network Address Translations (NATs), no proxies, and no hair-pinning.
● Unified visibility: Because Kubernetes nodes participate as standard EVPN peers, their routes, health, and connectivity are visible alongside every other fabric endpoint.
The security angle: identity-aware fabric integration
The integration goes beyond reachability. INV propagates Security Group Tags (SGTs) as part of the BGP control plane. When a VM or pod is advertised into the fabric, the advertisement can include identity context in addition to IP reachability.
This integration unlocks:
● Identity-aware policies: The Cisco NX-OS fabric can enforce policy based on workload identity, not just IP address or VLAN.
● End-to-end policy consistency: The same workload identity that Cilium uses to enforce policies inside Kubernetes is now visible and actionable on the physical fabric.
● Policy follows the workload: As workloads move, scale, change their IPs, or are rescheduled to different nodes, their identity and associated policy can move with them automatically.
This level of tight integration between Kubernetes-native security and the data- center network represents a fundamentally new capability for enterprise infrastructure.
| Use case |
How INV + Cisco Nexus One helps |
| VM migration |
Migrate VMs from traditional hypervisors to Kubernetes without re-architecting the network. INV advertises VM IPs into the existing VXLAN EVPN fabric, maintaining reachability with bare-metal and traditional VM endpoints. |
| Multitenant platform engineering |
Platform teams can offer Isolated Network Domains (IPNs) to internal tenants using standard Kubernetes CRDs, while the physical fabric enforces tenant boundaries through VRF mapping and SGTs. |
| Hybrid VM + container workloads |
Applications that span VMs and containers (for example, a containerized frontend with a VM-based database) communicate natively through the fabric with no NATs or proxies. |
| Zero-trust microsegmentation |
SGT propagation from Kubernetes to the Cisco Nexus One fabric extends identity-based microsegmentation from inside the cluster to the network fabric, enabling consistent zero-trust enforcement. |
| Extended visibility |
Isovalent Timescape and Nexus Dashboard provide a unified view of fabric health, workload reachability, and policy state across network fabric and Kubernetes endpoints, eliminating operational silos. |
A common framework: EVPN/VXLAN across every workload platform
The INV integration described in this brief is part of a broader Cisco strategy: establishing standards based EVPN/VXLAN as the common networking framework for every hypervisor and container platform in the data center with operational consistency through Cisco Nexus One and deliver unified visibility with an integrated platform.
Cisco has driven standards-based EVPN/VXLAN integration across multiple workload platforms, ensuring that regardless of the virtualization or container technology an enterprise chooses, the Cisco Nexus One fabric serves as the common networking substrate with consistent operations.
The initial release of INV is focused on VM connectivity use cases, supporting the advertisement of VM and Pod IPs into the fabric. IP address management (IPAM) is handled either by manual assignment or through an external DHCP server, which aligns naturally with lift-and-shift migrations from existing virtualization environments.
The integration of Isovalent Networking for Virtualization with the Cisco NX-OS VXLAN EVPN fabric delivers what enterprises have long needed: a unified, distributed, and workload-aware networking model that spans Kubernetes and traditional infrastructure. By combining the agility of cloud-native networking with the scale and reliability of VXLAN EVPN, organizations can modernize on their own terms — without compromising on security, performance, or operational consistency.