--- title: "How to Connect Nested KubeVirt Clusters with Calico and BGP Peering" source: "https://www.tigera.io/blog/how-to-connect-nested-kubevirt-clusters-with-calico-and-bgp-peering/" description: "Learn how to configure Calico BGP peering to seamlessly integrate nested Kubernetes clusters running in KubeVirt into your physical network, ensuring consistent, high-performance connectivity." --- [Technical Blog](https://www.tigera.io/category/technical-blog/) # How to Connect Nested KubeVirt Clusters with Calico and BGP Peering By [Leon Barron](https://www.tigera.io/blog/author/leon-barron/) on Oct 03, 2025 • 7 min read Running Kubernetes inside Kubernetes isn’t just a fun experiment anymore – it’s becoming a key pattern for delivering multi-environment platforms at scale. With [KubeVirt](https://www.tigera.io/learn/guides/kubernetes-networking/openshift-kubevirt/#KubeVirt_Architecture_Overview), a virtualization add-on for Kubernetes that uses QEMU (an open-source machine emulator and virtualizer), you can run full-featured Kubernetes clusters as virtual machines (VMs) inside a parent Kubernetes cluster. This nested architecture makes it possible to unify containerized and virtualized workloads, and opens the door to new platform engineering use cases. **But here’s the challenge:** how can you ensure that these nested clusters, and the workloads within, can reach, and be reached by, your physical network and are treated the same way as any other cluster? That’s where [Calico’s Advanced BGP (Border Gateway Protocol) peering with workloads](https://docs.tigera.io/calico/latest/networking/configuring/bgp-to-workload#configure-bgp-peering-with-workloads) comes into play. By enabling BGP route exchange between the parent cluster and nested KubeVirt VMs, Calico extends dynamic routing directly to virtualized workloads. This allows nested clusters to participate in the broader network topology and advertise their pod and service IPs just like any other node. Thus eliminating the need for tunnels or overlays to achieve true layer 3 connectivity. In this blog, we’ll walk through the big picture, prerequisites, and step-by-step configuration for setting up BGP peering between parent clusters and nested clusters running inside KubeVirt. ## Why BGP Peering for Nested Clusters? Platform engineering teams today face a common challenge: delivering a platform that meets performance, security, and cost requirements—without forcing developers to decide where their applications should run. Whether the underlying platform is on-premises, in the cloud, or virtualized with KubeVirt, those choices should be taken care of automatically, without developer involvement. Developers should simply request a resource to run their applications, while the platform team ensures the correct resources are delivered on available platforms. Enabling BGP peering on nested KubeVirt clusters means they can be treated just like any other cluster, with no ‘special’ or snowflake-style configurations required simply because they are virtualized. They integrate cleanly into your network fabric, giving you a consistent operational model across all your environments. ## Key Challenges When Peering With Nested Clusters While Calico can peer with traditional network infrastructure like ToR switches or border routers, peering with KubeVirt worker nodes introduces unique complexities: - Dynamic IPs vs static IPs - Efficient route advertisement ### Dynamic IPs vs. Static IPs ![Dynamic IPs vs. Static IPs](https://www.tigera.io/app/uploads/2025/10/Dynamic-IPs-vs-Static-IPs.png) ToR switches and networking equipment typically have static IPs, whereas KubeVirt VMs are treated like pods and may be assigned dynamic IPs. As a result, we need a more Kubernetes-friendly, flexible approach to peer with the KubeVirt worker nodes. ### Efficient Route Advertisement ![Efficient Route Advertisement](https://www.tigera.io/app/uploads/2025/10/Dynamic-IPs-vs-Static-IPs-02.png) If all physical nodes peer with all KubeVirt VMs that share a label, the same routes get re-advertised by multiple physical nodes to the ToR. This leads to unnecessarily large routing tables and inefficient routing paths. Instead, the goal is for each KubeVirt worker VM to peer only with its **local physical node**. This ensures that route advertisements are accurate, minimal, and follow the most efficient path. Did You Know? Calico’s advanced BGP capabilities make it possible to integrate Kubernetes workloads — including nested virtual clusters — directly into your physical network fabric. If you’re new to Calico BGP or want to understand the broader networking topologies it supports (e.g., full mesh, route reflectors, ToR peering), check out [Calico’s BGP Peering Documentation](https://docs.tigera.io/calico/latest/networking/configuring/bgp) and [Design Considerations for BGP over IP Fabrics](https://docs.tigera.io/calico/latest/reference/architecture/design/l3-interconnect-fabric#bgp-network-design-considerations). ## Step-by-Step: Peering Nested KubeVirt Clusters with Calico ### Step 1: Configure Global BGP Settings To simplify configuration, Calico provisions a single virtual IP on each parent cluster node. Nested workloads use this VIP to establish BGP peering, instead of peering with node-specific IPs. For IPv4, use a free link-local IP—excluding reserved addresses such as `169.254.0.1`,`169.254.0.2`, or cloud metadata IPs like `169.254.169.254.` **An example:** ``` `apiVersion: projectcalico.org/v3 kind: BGPConfiguration metadata: name: default spec: localWorkloadPeeringIPV4: "169.254.0.179" localWorkloadPeeringIPV6: "fdc9:9723:09bc::1"` ``` ### Step 2: Create BGP Filters At this point, we can create BGP peers. However, if we do this now, it will result in inefficient and overly complex routing due to multiple physical nodes re-advertising the same routes. To prevent this, we create BGP filters. These filters control which routes are allowed to flow between peers. We recommend having three filters: **1. No Export – Prevent sending routes to nested workloads.** Since the nested workload is going to be using the local parent node as the default gateway for all destinations, there is no need to advertise specific remote networks **An example:** ``` `apiVersion: projectcalico.org/v3 kind: BGPFilter metadata: name: no-export spec: exportV4: - action: Reject exportV6: - action: Reject` ``` **2. Accept Nested Cluster IPs – Only accept routes from your nested cluster’s IP pools** This is a security best practice to control what advertised networks are accepted from child clusters (which may be tenant-controlled) rather than blindly accepting all routes. ``` `apiVersion: projectcalico.org/v3 kind: BGPFilter metadata: name: accept-nested-ip-pools spec: importV4: - action: Accept matchOperator: In cidr: 10.123.0.0/16 importV6: - action: Accept matchOperator: In cidr: ca11:c0::/48` ``` **3. Export to ToR – Re-advertise nested cluster routes to your top-of-rack (ToR) router** When parent nodes re-advertise learned routes to their ToR router, it’s important to only advertise the specific nested pod networks. This minimizes unnecessary route propagation and helps maintain efficient, manageable routing tables. ``` `apiVersion: projectcalico.org/v3 kind: BGPFilter metadata: name: export-to-tor spec: exportV4: - action: Accept matchOperator: In cidr: 10.123.0.0/16 source: RemotePeers exportV6: - action: Accept matchOperator: In cidr: ca11:c0::/48 source: RemotePeers` ``` ### Step 3: Configure Parent Cluster BGP Topology Once the BGP Filters are in place, the next step is to configure the necessary BGP peerings on the parent cluster. #### **Parent to ToR** On the parent cluster we want to: - Peer with your ToR router(s) using eBGP - Attach the export-to-tor filter to control which routes are advertised: ``` `apiVersion: projectcalico.org/v3 kind: BGPPeer metadata: name: node-tor-peer spec: peerIP: asNumber: filters: - export-to-tor` ``` #### Parent to Child Next, create a BGPPeer in the parent cluster for peering with nested workloads (child clusters). This ensures proper route exchange while applying the relevant filters for security and efficiency: ``` `apiVersion: projectcalico.org/v3 kind: BGPPeer metadata: name: peer-to-workloads spec: localWorkloadSelector: color == 'red' asNumber: filters: - no-export - accept-nested-ip-pools` ``` ### Step 4: Configure the Nested (Child) Cluster Inside the nested cluster: #### 1 Disable node-to-node mesh and assign a unique AS number: ``` `apiVersion: projectcalico.org/v3 kind: BGPConfiguration metadata: name: default spec: nodeToNodeMeshEnabled: false asNumber:` ``` #### 2. Peer with the parent cluster’s virtual IP(s) This ensures that the nested cluster peers only with its local parent node. ``` `apiVersion: projectcalico.org/v3 kind: BGPPeer metadata: name: peer-to-parent-cluster spec: peerIP: 169.254.0.179 asNumber: --- apiVersion: projectcalico.org/v3 kind: BGPPeer metadata: name: peer-to-parent-cluster-v6 spec: peerIP: "fdc9:9723:09bc::1" asNumber:` ``` ### Step 5: Scale Out with Multiple Nested Clusters Once your first nested cluster is successfully peered, you can confidently expand the architecture by applying the same principles. If you need to deploy more than one nested cluster, follow these guidelines - Use unique non-overlapping IP pools per cluster - Create per-cluster import filters - Reuse the `no-export` filter - Update the `export-to-tor` filter to include all nested cluster CIDRs - Have each nested cluster peer with the same parent VIP(s) ## Wrapping Up This setup enables: - Nested clusters that integrate seamlessly into your network - Direct L3 reachability without overlays - Consistency across physical, cloud, and virtualized clusters While the configuration requires careful planning, it empowers platform teams to deploy secure, scalable, and high-performance nested Kubernetes clusters in KubeVirt — all without creating operational special cases. Want to learn more about Calico’s BGP capabilities? [Watch it in action now.](https://www.youtube.com/live/PefluN8YM9o?si=UAr2m6nPKkpUI2jj) [Best Practices](https://www.tigera.io/tags/best-practices/)[Project Calico](https://www.tigera.io/tags/project-calico/) ## Related posts [![The Safest Place to Run an AI Agent Is On a Cluster That Doesn’t Trust It](https://www.tigera.io/app/uploads/2026/08/The-Safest-Place-to-Run-an-AI-Agent-Is-On-a-Cluster-That-Doesnt-Trust-It.png)](https://www.tigera.io/blog/the-safest-place-to-run-an-ai-agent-is-on-a-cluster-that-doesnt-trust-it/) #### [The Safest Place to Run an AI Agent Is On a Cluster That Doesn’t Trust It](https://www.tigera.io/blog/the-safest-place-to-run-an-ai-agent-is-on-a-cluster-that-doesnt-trust-it/) By [Alister Baroi](https://www.tigera.io/blog/author/alister-baroi/) on Aug 27, 2026 Every organization running AI agents has already made a hosting decision. Most made it by accident. The sales team switched on the agent built into their CRM. Engineering is piloting a coding agent in a... [Read more](https://www.tigera.io/blog/the-safest-place-to-run-an-ai-agent-is-on-a-cluster-that-doesnt-trust-it/) [![AI Red Team Agents Automate Attacks on your AI Agents. Runtime Policies Automate their Defense.](https://www.tigera.io/app/uploads/2026/08/AI-Red-Team-Agents-Automate-Attacks-on-your-AI-Agents.-Runtime-Policies-Automate-their-Defense.png)](https://www.tigera.io/blog/ai-red-team-agents-automate-attacks-on-your-ai-agents-runtime-policies-automate-their-defense/) #### [AI Red Team Agents Automate Attacks on your AI Agents. Runtime Policies Automate their Defense.](https://www.tigera.io/blog/ai-red-team-agents-automate-attacks-on-your-ai-agents-runtime-policies-automate-their-defense/) By [Alister Baroi](https://www.tigera.io/blog/author/alister-baroi/) on Aug 24, 2026 The AI red teaming market grew up fast this year. OpenAI bought Promptfoo, Cisco and Microsoft shipped automated attack suites, and a seed-stage startup publicly compromised 50 of 55 live customer service bots. These platforms... [Read more](https://www.tigera.io/blog/ai-red-team-agents-automate-attacks-on-your-ai-agents-runtime-policies-automate-their-defense/) [![VM Migration – What Happens to Your NSX Segments in Kubernetes?](https://www.tigera.io/app/uploads/2026/08/VM-Migration-What-Happens-to-Your-NSX-Segments-in-Kubernetes.png)](https://www.tigera.io/blog/vm-migration-what-happens-to-your-nsx-segments-in-kubernetes/) #### [VM Migration – What Happens to Your NSX Segments in Kubernetes?](https://www.tigera.io/blog/vm-migration-what-happens-to-your-nsx-segments-in-kubernetes/) By [Veronika Smolik](https://www.tigera.io/blog/author/veronika-smolik/) on Aug 5, 2026 Planning a migration off NSX usually starts with a networking conversation. Segments, VLANs, routing topology and BGP peering are not things that map cleanly to Kubernetes-native constructs the way the NSX distributed firewall maps to... [Read more](https://www.tigera.io/blog/vm-migration-what-happens-to-your-nsx-segments-in-kubernetes/)