# CubeVS eBPF Virtual Switch vs Traditional Container Networking: Architecture and Performance Differences

> Explore CubeVS eBPF virtual switch vs traditional container networking. Discover how eBPF offers O(1) lookups, per-sandbox isolation, and lower latency for superior performance.

- Repository: [Tencent Cloud/CubeSandbox](https://github.com/TencentCloud/CubeSandbox)
- Tags: architecture
- Published: 2026-07-15

---

**CubeVS replaces the multi-layer Linux bridge, iptables, and netfilter stack with a lightweight eBPF datapath that processes packets entirely in kernel space, delivering O(1) policy lookups, per-sandbox isolation via dedicated TAP devices, and significantly lower latency compared to traditional container networking.**

CubeVS is the network virtualization layer powering TencentCloud's CubeSandbox project. Unlike traditional container networking that relies on Linux bridges, Open vSwitch, or iptables-based NAT, CubeVS implements a complete virtual switch using eBPF programs attached directly to network interfaces. This architecture eliminates the context switches and subsystem traversals that plague conventional approaches.

## Core Architectural Differences

### In-Kernel Data-Plane Implementation

Traditional container networking traverses multiple kernel subsystems including netfilter, iptables chains, and bridge drivers. CubeVS replaces this complexity with three lightweight eBPF programs—`from_cube`, `from_world`, and `from_envoy`—that run entirely in kernel space. According to the source documentation in [`docs/zh/architecture/network.md`](https://github.com/TencentCloud/CubeSandbox/blob/main/docs/zh/architecture/network.md), these programs attach to TAP devices and the host NIC via TC hooks, processing packets before they ever reach the standard network stack.

### TAP-Based Isolation Model

In traditional setups, containers share a Linux bridge or OVS instance, exposing them to broadcast traffic and ARP tables common to all pods. CubeVS assigns each sandbox a dedicated TAP device that is not bridged to any others. This design ensures that inter-sandbox communication must explicitly pass through eBPF-controlled paths, eliminating lateral visibility and broadcast leakage by default.

## Forwarding, NAT, and Policy Enforcement

### eBPF-Based NAT and Session Tracking

Instead of iptables rules that must be parsed per-packet, CubeVS handles SNAT, DNAT, session-tracking, and port-mapping inside eBPF programs using BPF maps. The maps `egress_sessions`, `ingress_sessions`, and `remote_port_mapping` store connection state in [`cubevs/bpf/mvmtap.bpf.c`](https://github.com/TencentCloud/CubeSandbox/blob/main/cubevs/bpf/mvmtap.bpf.c) and related files, allowing the datapath to modify packet headers without invoking the netfilter subsystem.

### O(1) Policy Enforcement with LPM-Trie Maps

Security policies leverage LPM-Trie (Longest Prefix Match) maps named `allow_out_v2` and `deny_out`. These maps enable O(1) lookups for per-sandbox L3/L4 allow/deny lists evaluated directly in the kernel. Traditional approaches rely on iptables chains that incur linear-time checks as rules grow, plus potential lock contention across sandboxes when updating shared rule sets.

## Advanced Networking Features

### In-Kernel DNS-Based Filtering

CubeVS intercepts DNS queries at the eBPF level, learns resolved IP addresses, and writes them into `allow_out_v2` with configurable TTL values. This enables domain-level egress control completely within the kernel datapath, as implemented in the `from_cube` program. Traditional solutions typically perform DNS filtering in userspace via CoreDNS or use expensive iptables string matching that cannot directly influence kernel NAT tables.

## Performance and Scalability Characteristics

### Per-Sandbox Scalability

Policy updates in CubeVS are scoped to individual TAP devices. When you modify a sandbox's network policy, only that sandbox's map entries change—no global locks or map traversals are required. This contrasts sharply with traditional networking where iptables or bridge rule updates touch the entire host rule set, causing latency spikes as tenant density increases.

### Eliminating Context Switches

Benchmarks referenced in the CubeSandbox documentation demonstrate that CubeVS achieves orders-of-magnitude lower per-packet latency than iptables/bridge solutions. By keeping packet processing (policy checks, NAT, session creation, ARP replies) entirely within the kernel eBPF subsystem, CubeVS avoids the context switches and userspace transitions common in traditional stacks that rely on L7 proxies.

## Control Plane Implementation

The CubeVS control plane resides in the `cubevs/` Go package, which loads BPF objects, manages TAP lifecycle, and updates maps via APIs like `AddTAPDevice`, `SetSNATIPs`, and `AddPortMapping`. This programmatic approach replaces the brittle shell-script management typical of iptables-based CNI plugins.

```go
// Example: Adding a TAP device and an allow-out CIDR rule via the CubeVS Go API
import "github.com/tencentcloud/cubesandbox/cubevs"

func provisionSandbox(ifIdx int) error {
    // Register the TAP device (creates BPF maps entries)
    if err := cubevs.AddTAPDevice(ifIdx, "169.254.68.6"); err != nil {
        return err
    }

    // Allow outbound traffic to 10.0.0.0/8 for this sandbox
    rule := cubevs.CIDRRule{
        CIDR:    "10.0.0.0/8",
        Expire:  0,               // 0 = never expires
        Action:  cubevs.Allow,
    }
    return cubevs.UpdateAllowOut(ifIdx, rule)
}

```

You can also inspect eBPF map entries using the CubeSandbox CLI:

```bash

# List current allow-out rules using CubeCLI

cubesandbox network-agent list-maps --map allow_out_v2

```

## Key Source Files

Understanding CubeVS requires examining these specific components:

- **[`cubevs/bpf/mvmtap.bpf.c`](https://github.com/TencentCloud/CubeSandbox/blob/main/cubevs/bpf/mvmtap.bpf.c)**: The `from_cube` eBPF program attached to TAP ingress, handling SNAT, policy enforcement, and DNS interception.

- **[`cubevs/bpf/nodenic.bpf.c`](https://github.com/TencentCloud/CubeSandbox/blob/main/cubevs/bpf/nodenic.bpf.c)**: The `from_world` program processing host-NIC ingress, managing reverse NAT and port-mapping for incoming traffic.

- **[`cubevs/bpf/localgw.bpf.c`](https://github.com/TencentCloud/CubeSandbox/blob/main/cubevs/bpf/localgw.bpf.c)**: The `from_envoy` program handling host-to-sandbox egress, implementing DNAT and proxy routing logic.

- **[`network-agent/internal/service/local_service.go`](https://github.com/TencentCloud/CubeSandbox/blob/main/network-agent/internal/service/local_service.go)**: Orchestrates policy extraction and eBPF map updates for each sandbox instance.

## Summary

- **CubeVS** implements a complete virtual switch using eBPF programs attached to TAP devices, replacing Linux bridges and iptables entirely.
- **Traditional networking** traverses multiple kernel subsystems (netfilter, bridge, iptables) with linear rule processing and shared broadcast domains.
- **Performance**: eBPF delivers O(1) policy lookups and in-kernel NAT without context switches, achieving significantly lower latency than traditional approaches.
- **Isolation**: Dedicated TAP devices per sandbox provide natural network segmentation without bridge-based broadcast leakage.
- **DNS control**: In-kernel DNS interception enables domain-based egress filtering without userspace proxies.

## Frequently Asked Questions

### What makes CubeVS faster than traditional iptables-based container networking?

CubeVS processes packets entirely within the kernel eBPF subsystem using BPF maps for state tracking, eliminating the subsystem traversal and rule-parsing overhead of iptables. Traditional container networking requires each packet to traverse netfilter chains, bridge forwarding tables, and potentially userspace proxies, introducing latency at each layer.

### How does CubeVS handle network isolation between sandboxes?

Each CubeSandbox instance receives a dedicated TAP device that is not attached to any Linux bridge or virtual switch shared with other tenants. Inter-sandbox traffic must flow through eBPF-controlled paths, preventing ARP table pollution and broadcast leakage common in traditional bridge-based networking.

### Can CubeVS perform DNS-based egress filtering?

Yes. CubeVS eBPF programs intercept DNS resolution requests and learn the resulting IP addresses, writing them dynamically into `allow_out_v2` LPM-Trie maps with optional TTL values. This enables fine-grained, domain-level egress control without requiring external DNS servers or iptables string matching rules.

### Where are the eBPF programs in the CubeSandbox repository?

The three primary eBPF programs are located in [`cubevs/bpf/mvmtap.bpf.c`](https://github.com/TencentCloud/CubeSandbox/blob/main/cubevs/bpf/mvmtap.bpf.c) (sandbox egress/TAP ingress), [`cubevs/bpf/nodenic.bpf.c`](https://github.com/TencentCloud/CubeSandbox/blob/main/cubevs/bpf/nodenic.bpf.c) (host NIC ingress), and [`cubevs/bpf/localgw.bpf.c`](https://github.com/TencentCloud/CubeSandbox/blob/main/cubevs/bpf/localgw.bpf.c) (host-to-sandbox/proxy traffic). The Go control plane that loads these programs resides in the `cubevs/` package.