Today we’re announcing the General Availability (GA) of Isovalent Networking for Virtualization alongside a deeper look at one of its core connectivity capabilities: BGP EVPN/VXLAN integration with Cisco NX-OS, part of the Cisco Nexus One strategic alignment. The INV GA post covers the full platform: Isovalent Private Networks, the Network Bridge for lift-and-shift migration, and multi-AZ support. This post is focused specifically on what it means to connect Isovalent Private Networks to a Cisco Nexus One fabric using BGP EVPN, and why that integration changes what’s possible for enterprise teams running Kubernetes on Nexus One infrastructure. Kubernetes Clusters and the data center fabric Kubernetes clusters and enterprise data center fabrics operate as distinct routing domains. The cluster has its own overlay, its own IP space, its own DNS, and its own policy model. The DC fabric has VRFs, BGP policies, prefix filters, and a routing domain built around existing workloads. Connecting the two typically means choosing between static routes, NAT at the cluster edge, or a flat external network attachment. Each option introduces specific limitations. Static routes require manual updates when workloads move and do not reflect the dynamic nature of Kubernetes scheduling. NAT at the cluster edge preserves reachability but masks per-workload source addresses, reducing the fidelity of flow telemetry and complicating security policy enforcement. Flat external attachment bypasses the VRF-based segmentation model already in place on the Nexus fabric. The visibility problem compounds the connectivity problem. Cluster-internal flow data, captured by tools like Hubble, reflects workload identity and policy context but has no awareness of the network infrastructure path. Fabric-level telemetry from NX-OS reflects interface utilization and network forwarding but has no awareness of what application or tenant is generating the traffic. Operators working across both domains must correlate two separate data sets with no common reference point, making it difficult to trace an end-to-end application flow, attribute a network event to a specific workload, or verify that micro-segmentation policy inside the cluster is consistent with the forwarding behavior observed at the fabric. For enterprise workloads with compliance requirements, or for environments undergoing active VM migration to Kubernetes, none of these approaches are operationally sound at scale. Isovalent Private Networks with BGP EVPN integration address this at the architecture level, providing standards-based L3 connectivity between the cluster and the fabric without static routes, NAT, or segmentation gaps. How the Integration Works Isovalent Networking for Virtualization uses BGP EVPN L3 VNIs to give each Isovalent Private Network (IPN) native reachability in the fabric routing domain. The cluster worker nodes peer directly with Cisco Nexus leaf switches over standard BGP. Each IPN maps to a VRF on the Nexus One fabric. There are no static routes. The cluster participates in the fabric routing domain the same way any other BGP neighbor would. The route advertisements are host-specific: /32s for IPv4 workloads, /128s for IPv6. As VMs or pods come online in each IPN, their host routes are advertised into the corresponding VRF on the Nexus One fabric. As workloads are decommissioned or rescheduled to a different node, those routes are withdrawn and re-advertised from the new location automatically. The fabric maintains a current, accurate view of workload location without manual intervention. The VXLAN encapsulation is handled entirely in the Isovalent data plane on the Kubernetes side, implemented in eBPF directly in the Linux kernel. There is no additional agent, no kernel module, and no userspace forwarding path. Policy enforcement, encapsulation, and route advertisement all happen in the same data plane that handles every other Isovalent Private Network function. The integration also carries security group context alongside routing reachability. Prefixes advertised from the cluster are decorated with a BGP extended community encoding a Security Group Tag (SGT) value, using the Security Groups mechanism supported by NX-OS. This means each IPN's routes arrive at the fabric with policy context attached, not just forwarding information. The specifics of how NX-OS consumes that SGT to enforce contract-based policy are covered in the integration details below. The following video shows these capabilities in action: Multitenancy with Isovalent Private Networks and Nexus One For organizations running Kubernetes workloads that require connectivity to existing infrastructure on the Nexus One fabric, including databases, storage systems, or application tiers that remain on physical or virtualized infrastructure, the integration provides a structured, policy-aware path between the cluster and the rest of the data center. For service providers and enterprises running shared Kubernetes platforms, the VRF-per-IPN model maps directly to multi-tenant isolation requirements. Each tenant receives a Private Network with its own address space, routing policy, and VRF on the fabric. Isolation is enforced by eBPF at the node level and by VRF separation at the Nexus One edge. Cross-tenant reachability requires explicit policy at both layers. The same architecture applies to Agentic frameworks where co-locating compute from different teams or customers on shared network fabric requires enforced network boundaries at the data plane level, from the eBPF enforcement on the Kubernetes node through to the VRF boundary on the connecting leaf in Nexus One. What This Looks Like with Cisco NX-OS The BGP EVPN integration has been validated against Cisco NX-OS. Key integration characteristics: VRF-per-IPN isolation. Each Isovalent Private Network corresponds to a VRF on the Nexus fabric. Security boundaries enforced by eBPF inside the cluster are mirrored at the fabric level by VRF separation. A workload in one IPN cannot reach a workload in another IPN unless there is an explicit cross-VRF policy in place in the fabric. The segmentation model is consistent end-to-end. BGP peering from worker nodes. The peering is distributed: worker nodes establish individual BGP sessions with the upstream Top-Of-Rack leaf switches rather than routing everything through a single cluster gateway. This eliminates the single-point-of-failure that centralized routing approaches introduce and decouples east-west throughput from a gateway bottleneck. Security Group Tag integration. The integration supports SGT assignment on prefixes advertised from the cluster to the Nexus fabric. Each IPN’s routes are decorated with a BGP extended community carrying an SGT value, which NX-OS consumes to enforce contract-based policy: allowing or denying traffic to and from those prefixes based on the assigned tag. The SGT-to-IPN mapping is configured by the network administrator, giving the network team direct control over how cluster workload groups are represented in the fabric security policy model. It is also possible to map individual workloads to a specific Security Group Tag for added granularity. Observability end-to-end. Because the EVPN integration preserves real workload IP addresses through the data path, with no SNAT and no proxy, existing flow telemetry on the Nexus side continues to reflect actual source and destination addresses. Inside the cluster, Isovalent Timescape and Hubble provide per-flow visibility for every VM and pod in an IPN, including flows crossing the EVPN boundary. There are no visibility gaps at the handoff point between the cluster and the fabric. The Migration Machine The IPN EVPN integration is useful on its own as a day-one connectivity model, but it becomes particularly powerful during a VM migration to Kubernetes KubeVirt. In the early stages of a migration, workloads that have moved into Kubernetes are reachable through the Isovalent Network Bridge: an L3 construct that provides IP address continuity for migrated environments without stretching VLANs or broadcast domains across the migration boundary. The Bridge manages the coexistence period, where VMs on source environment and VMs in the Kubernetes cluster must communicate using their original IP addresses. As migration progresses, EVPN takes over. When a VM moves into an IPN, a host route for that workload is advertised directly from the cluster to the Nexus One fabric via BGP EVPN. Traffic from the rest of the DC that previously reached that VM through the source environment’s previous network path, now follows the EVPN advertisement to the Kubernetes node where it resides. The Bridge is no longer required for that address. When the last VM in a segment has been migrated, the Bridge for that segment is cleanly decommissioned. The EVPN routes for those prefixes remain in place, now rooted directly in the IPN rather than behind a Bridge node. The upstream Nexus One fabric sees a continuous, consistent routing domain throughout the migration, with no forced cutover event and no manual changes to upstream routing policy. This is what we mean when we describe the combination of INV, the Network Bridge, and EVPN as a genuine migration machine. Get involved BGP EVPN integration with Cisco Nexus One is available now as part of Isovalent Networking for Virtualization on the Isovalent Enterprise Platform. To evaluate the migration path or see the integration in a live environment, get a demo or contact your Cisco account team. More resources Isovalent Networking for Virtualization: GA Announcement Learn more about Isovalent Networking for Virtualization Isovalent Networking for Virtualization Solution Brief Isovalent Networking for Virtualization Integration with Cisco Nexus One Fabric Solution Overview