Calico BGP Peering for Nested Clusters in KubeVirt

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, 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 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

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

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 and Design Considerations for BGP over IP Fabrics.

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.