Introducing Isovalent Networking for Virtualization (INV) If you've been tracking what we've been building at Isovalent over the last several months, Dean's recent post gave you an early look at where we were heading with VM networking and security. Today we're ready to go further: we're formally announcing the General Availability of Isovalent Networking for Virtualization (INV), a purpose-built product that brings full network segmentation, multi-tenancy, and policy enforcement to virtual machine workloads running in Kubernetes, in addition to streamlining migrations to KubeVirt. Enterprise infrastructure and platform teams are dealing with two realities: a Kubernetes platform that's expected to run both VMs and containers, and a set of security or operational requirements that make Kubernetes’ "flat networking" a non-starter. If these challenges resonate with you, the following sections detail how Isovalent Networking for Virtualization can help. We've been running Isovalent Networking for Virtualization with internal teams and external customers in production-grade POC environments since August 2025. That field time has shaped the product in concrete ways, which we will describe throughout this post. Why standard Kubernetes networking falls short When you run a VM on KubeVirt or OpenShift Virtualization, architecturally, the VM lives inside a pod. Because the network sees that VM as just another pod, it inherits the standard Kubernetes "flat" network. This setup is convenient, but it creates a few specific challenges: Open by default: In a standard cluster, every pod (and therefore every VM) can talk to every other pod. There is no built-in separation between users or departments. Basic filtering: Standard tools like NetworkPolicy can block specific traffic, but they don't create truly separate network zones, which are a requirement in most enterprise private cloud environments. Operational friction: VMs have unique needs that standard pods don't, such as keeping the same IP address, managing DHCP, and staying connected during a live migration. For basic setups, the default network works fine. However, if you are handling multiple tenants, or have to meet strict compliance rules, "wide open" isn't an option. You need a way to create hard boundaries between workloads without making the infrastructure impossible to manage. This is exactly why we built Isovalent Networking for Virtualization. It provides the network isolation and stability that enterprise VMs actually require, right out of the box. Integrating virtualization into the Isovalent Enterprise Platform Isovalent Networking for Virtualization, part of the Isovalent Enterprise Platform, is built on Cilium, the eBPF-based CNI that is now the default networking layer across every major cloud provider's managed Kubernetes service, and the most active CNCF networking project after Kubernetes itself. Cilium's enforcement model operates directly in the Linux kernel via eBPF, providing identity-based security, L3-L7 policy, and deep observability without the overhead of sidecars or kernel modules. Extended to VM workloads through OpenShift Virtualization and KubeVirt, Isovalent Networking for Virtualization aims to give VMs the same policy engine, the same observability, and the same multi-network capabilities as containers, through one unified control plane. Product components Isovalent Private Networks: The Kubernetes VPC The foundation of Isovalent Networking for Virtualization is Isovalent Private Networks (IPNs), a VPC-style networking construct built natively inside Kubernetes. The operational model will be familiar to anyone who has worked with Cloud VPCs: each IPN represents an isolated network domain with its own subnets and address spaces, routing policy, and security perimeter. Virtual machines are placed into an IPN by intent. The administrator declares what network and subnetwork a workload belongs to, and the control plane handles the VM connectivity. Within an IPN, routing and security are also expressed as intent. You define what the network is and what it's allowed to do; INV translates that into eBPF programs enforced at the kernel level on each node. Breakout and external connectivity from an IPN is handled through a set of pluggable access options that map to how your network infrastructure is built: Bridge mode through the Isovalent Network Bridge (INB): network extension of an existing VM segment (irrespective of network backing, meaning VLANs and overlay segments are supported), for cases where the VM needs to preserve the same IP after migration and the administrator does not want to undergo a costly network reconfiguration. VLAN-based breakout (L3): 802.1q tagged ingress/egress, supported directly as a distributed function across all, or some, worker nodes in a cluster. EVPN/VXLAN: standards-based L3 reachability to the fabric using BGP EVPN L3 VNIs, enabling the cluster to participate in your existing DC routing domain without static routes or NAT. Isovalent Load Balancer (ILB): native L4/L7 load balancing for North-South traffic, fully integrated with IPN routing and compatible with multi-AZ topologies (more on this below). On the roadmap: Egress Gateway (EGW) integration to give per-tenant control over outbound connections leveraging NAT, with further plans to enable Cross-Connection of IPNs (VPC Peering) for additional flexibility and federation of connectivity. More on the Isovalent Network Bridge The Network Bridge is a component of the Isovalent Networking for Virtualization platform that targets a specific scenario: lift-and-shift VM migrations where IP address preservation is required and connectivity must be maintained before, during, and after the VM is moved. IP preservation is critical in lift-and-shift migrations where workloads have hardcoded IPs in application configs, firewall rules, or DNS records that cannot be easily inventoried or updated. Reconfiguring the network to accommodate new addresses introduces change risk and operational overhead that defeats the purpose of a fast, low-touch migration. The Isovalent Network Bridge does not extend a VLAN or broadcast domain from the source environment into the Kubernetes cluster. That distinction is very important. Solutions that stretch L2 across a migration boundary carry well-known tradeoffs: MTU mismatch, traffic tromboning back to a centralized gateway, ARP flooding, fragmentation issues, and split-brain broadcast domains. The Isovalent Network Bridge is L3 throughout. It uses a combination of ARP proxy, stateless NAT, and overlay encapsulation (Geneve or VXLAN) to give migrated VMs the appearance of continuous L2 adjacency, while actually moving all traffic through a routed L3 data plane. The guest OS preserves its IP address and default gateway without stretched VLANs. No broadcast replication across the wire. The Isovalent Network Bridge data plane is implemented in eBPF, which enables high performance. We are also including support for horizontal scale-out across multiple Bridge nodes for additional East-West throughput, and to provide active-active resiliency. For enterprise deployments with existing DHCP infrastructure, static IP requirements, or applications that are sensitive to IP changes (a common pain point in KubeVirt migrations), Isovalent Networking for Virtualization handles these at the L3 boundary without requiring guest OS changes or reconfiguration of the application. Network cutover with EVPN: The migration machine While every customer's migration timeline will look different, the Bridge should always be treated as temporary. As shown below, the Bridge provides connectivity during migrations (1) for the workloads in Kubernetes (2). As workloads are progressively moved off source segments, or entire sites are cleared, the target state is to decommission the Bridge entirely and let the Kubernetes cluster handle that traffic natively. Isovalent Networking for Virtualization handles this through EVPN L3 VNI route advertisement. The IP addresses of the migrated workloads (/32s for IPv4, /128s for IPv6) are announced from the cluster to the fabric via BGP EVPN (3). This allows traffic destined for migrated VMs to be attracted toward the Kubernetes nodes progressively, without a hard cutover event and with complete autonomy over the upstream routing policy that propagates these host routes beyond the Top-Of-Rack switch. When the last VM in a segment has been migrated, the Bridge for that segment can be cleanly decommissioned. The EVPN advertisements for those prefixes remain in place, rooted now directly in the IPN rather than behind a Bridge. The upstream fabric sees a continuous, consistent routing domain throughout the migration. This makes the combination of Isovalent Networking for Virtualization, the Network Bridge, and EVPN a genuine network migration machine. Multi-NIC support for VMs Many enterprise VMs have multiple network interfaces by design, with separate interfaces for management, data, storage, or tenant isolation. When those VMs move into Kubernetes, preserving that network topology is essential. Isovalent Networking for Virtualization supports multi-NIC attachment for VMs and pods directly into Isovalent Private Networks using a Multus wrapper, so connectivity leverages standard Network Attachment Definitions (NADs). These NADs are surfaced to the user in each applicable namespace, giving the administrator additional options for enforcing multi-tenancy. A VM can be attached to multiple IPNs simultaneously, each with its own routing policy and security context. Notably, each interface gets the full INV treatment: eBPF-enforced policy, Timescape observability, and integration with the IPN's routing domain. This is architecturally different from how most other CNIs approach this problem. The dominant pattern elsewhere is to use Multus with a secondary CNI (often a Bridge or MACVLAN plugin) that operates outside the primary CNI's policy model, meaning you get a second interface but without visibility or security enforcement on that interface. In Isovalent Networking for Virtualization, all interfaces, regardless of how many there are, can be mapped independently to create arbitrary topologies, without having to apply special rules about how additional NICs must be configured. This also means that there are no blind spots in your observability. Multi-AZ private networks: Consistent networking across failure domains Isovalent Networking for Virtualization also supports multi Availability Zone deployments, covering OpenShift Virtualization and KubeVirt workloads. For organizations with active-active or active-DR topologies, this delivers consistent Private Network-based intent (network and security) policy across nodes spanning multiple availability zones, without per-AZ configuration overhead or policy duplication. Multi-site and multi-cloud support, where Private Networks span across geographically separated clusters, is on the near-term roadmap. This will leverage the strong foundation provided by Cilium Cluster Mesh, a mechanism that provides service discovery and connectivity across cluster boundaries. Isovalent Load Balancer integration Virtual machines connected in an Isovalent Private Network can serve as backends for the Isovalent Load Balancer (ILB). This enables L4/L7 load balancing via the ILB's two-tier architecture (T1/T2). The Isovalent Load Balancer also integrates natively with multi-AZ Private Networks, deployed on stretched cluster architectures available for OpenShift Virtualization and KuberVirt. What early access users are telling us As mentioned in the Introduction, we have been running Isovalent Networking for Virtualization (INV) internally and externally since August of 2025. This field engagement has been vital in refining the product, particularly for optimizing EVPN cutover workflows and ensuring static IP addresses are preserved during migrations. Early feedback from these users has been positive, with teams highlighting the stability of the control plane during complex network transitions and the ease of integrating the solution into their existing fabric architectures. We have also conducted performance and scale testing to ensure the system handles production-level demands. This included executing bulk migrations of hundreds of workloads across multiple waves to measure throughput, concurrency, and network state consistency. We also stress-tested BGP convergence times and control plane overhead during high-volume network churn and concurrent operations to ensure the system remains responsive under heavy load. The architecture delivers predictable convergence and a stable control plane, ensuring consistent performance even when subjected to the pressure of bulk migrations and high-frequency workload lifecycle operations. Use cases, summarized The full range of use cases Isovalent Networking for Virtualization supports is summarized below: Enterprise migration teams get a full network migration path: IP preservation, L3 Bridge connectivity, progressive EVPN cutover, and the ability to decommission existing VM network infrastructure segment by segment, without a big-bang cutover. Service providers running multi-tenant, multi-site Kubernetes platforms get VPC-grade tenant isolation built into the CNI, with policy enforcement that survives pod reschedules and live migrations. AI infrastructure operators get the multi-tenant security foundation required to, for example, co-locate training jobs from different teams or customers on shared physical fabric, with the same eBPF data plane that some of the largest LLM providers in the world are running in production. Get involved Isovalent Networking for Virtualization is available now. If you're evaluating a migration strategy, planning a multi-tenant Kubernetes platform, or building out AI infrastructure that needs hard tenant isolation, we want to talk. Reach out to your Cisco account team for additional information. More resources Learn more about Isovalent Networking for Virtualization Isovalent Networking for Virtualization Solution Brief Learn more about Isovalent Private Networks and Cisco Nexus One Isovalent Networking for Virtualization: migrate VMs without breaking the network