Weave Net

Weave Net is the historically-important Container Network Interface plugin originally created by Weaveworks (founded 2014; CEO Alexis Richardson) as one of the earliest Kubernetes CNIs. Its design pre-dates Calico’s BGP-routed approach and Cilium’s eBPF era: Weave Net uses a mesh-VXLAN overlay in which every node’s weave agent forms a gossip-based mesh with all other nodes, learning peer addresses via a Weaveworks-designed gossip protocol, then programs VXLAN tunnels between node pairs. Each node receives a slice of the cluster Pod CIDR, and cross-node Pod traffic is encapsulated in VXLAN. Weave’s two distinguishing features were end-to-end encryption — using NaCl secretbox (Curve25519/XSalsa20/Poly1305) for the control plane and sleeve-mode data packets, and IPsec ESP transport mode with AES-GCM for fast-datapath packets (encryption-implementation.md, fastdp-crypto.md) — and a dual-mode forwarding plane: Fast Datapath (the optimized in-kernel VXLAN path built on Open vSwitch datapath primitives) and sleeve mode (a slower userspace fallback for connections that can’t traverse fast datapath, e.g., across NAT or with low path MTU). Weave Net supports NetworkPolicy via its own iptables-level enforcement and was widely deployed in early-Kubernetes-era production.

The original company is gone, but the project is not dead. Weaveworks the company shut down operations in February 2024 (techcrunch.com, theregister.com) — CEO Alexis Richardson announced the closure via LinkedIn after a planned merger or funding round failed despite “substantial growth in 2023.” The original weaveworks/weave GitHub repository was archived (read-only) in mid-2024 (last code push 2024-08-09; its final release was v2.8.1, January 25, 2021 — github.com/weaveworks/weave). However, maintenance has since moved to a community fork at rajch/weave, run by Raj Chaudhuri with Richardson’s public blessing in issue #3948; that fork shipped a string of releases through 2024 culminating in v2.9.0 on 2024-12-22 and was still receiving commits as of late 2025 (last push 2025-09-16, verified via the GitHub API on 2026-05-22). This note documents Weave Net for historical, maintenance, and migration purposes. For new Kubernetes clusters the mainstream choice is still Cilium, Calico, or a managed cloud CNI — but “Weave Net is dead” is now an oversimplification; it is “Weaveworks-orphaned, community-maintained.”

Mental Model

flowchart TB
    subgraph N1["Node 1 (10.0.1.10)"]
        subgraph N1POD["Pod A"]
            PA[Pod A<br/>10.32.0.5/12]
        end
        VETHA[veth]
        BR1[weave bridge<br/>10.32.0.1/12]
        VXLAN1[vxlan-6784 device<br/>fast datapath]
        SLEEVE1[sleeve mode userspace<br/>fallback for NAT'd peers]
        AGENT1[weave agent<br/>(weaver Go binary)<br/>+ gossip mesh<br/>+ IPAM allocation]
    end
    subgraph N2["Node 2 (10.0.1.11)"]
        subgraph N2POD["Pod B"]
            PB[Pod B<br/>10.32.1.7/12]
        end
        VETHB[veth]
        BR2[weave bridge<br/>10.32.1.1/12]
        VXLAN2[vxlan-6784<br/>fast datapath]
        AGENT2[weave agent]
    end
    AGENT1 -. "gossip protocol<br/>over TCP/6783<br/>peer discovery, IPAM<br/>topology graph" .- AGENT2
    PA --- VETHA --- BR1 --- VXLAN1
    PB --- VETHB --- BR2 --- VXLAN2
    VXLAN1 -- "AES-GCM encrypted<br/>VXLAN over UDP/6784<br/>(fast datapath)" --> VXLAN2
    VXLAN1 -. "NaCl secretbox<br/>over TCP/6783<br/>(sleeve fallback)" .-> SLEEVE1
    SLEEVE1 -.- AGENT2

What this diagram shows. A typical Pod-to-Pod packet path in Weave Net’s default configuration. Each node runs the weaver Go binary as a DaemonSet (the “weave agent”); each agent maintains a gossip-based mesh over TCP port 6783 with all peer agents. Gossip messages exchange peer connection state, IPAM allocations (Weave runs its own distributed IPAM that allocates Pod IPs without etcd), and topology updates so each agent has a complete topology graph of the mesh and can choose optimal forwarding paths. The data plane runs over UDP port 6784: each node creates a VXLAN device named vxlan-6784; cross-node Pod traffic is encapsulated by the kernel’s VXLAN module and authenticated/encrypted with AES-GCM when encryption is enabled. This is the fast datapath — in-kernel, line-rate, low CPU. When two nodes can’t establish fast datapath between them (most commonly when one node is behind NAT, or when their kernels lack VXLAN, or when the user disabled fast datapath), Weave falls back to sleeve mode: the kernel pulls packets up to a userspace weaver process via a pcap/raw socket interface, that userspace process encrypts the packet with NaCl secretbox (XSalsa20-Poly1305), tunnels it over the gossip channel (TCP/6783) to the peer’s userspace weaver, which decrypts and reinjects. Sleeve mode is significantly slower than fast datapath (orders of magnitude — userspace context switches, copies, encryption all hurt). The dual-mode design was Weave’s pragmatic answer to a heterogeneous-network reality: prefer fast, fall back to slow, never drop. The insight to extract: Weave Net’s architectural focus was operational portability — works on any network, encrypts by default, gossip-based so no etcd dependency — at the cost of complexity. Each agent is a full peer-to-peer gossip participant, which is conceptually elegant but practically a lot more moving parts than Flannel’s “ask the API server for my subnet.”

Mechanical Walk-through

Architecture overview

Weave Net’s per-node components (tkng.io, github.com/weaveworks/weave):

1. weaver — the main agent, Go binary. Runs as a privileged DaemonSet container. Responsibilities:
   • Maintain TCP gossip connections to peer agents (port 6783).
   • Allocate Pod IPs from the cluster CIDR (Weave’s own distributed IPAM, not the standard host-local).
   • Program the kernel: create the weave Linux bridge, create the vxlan-6784 device, install routes.
   • Sleeve-mode fallback: relay packets through userspace when fast datapath isn’t available.
   • Optionally enforce NetworkPolicy via iptables rules.
2. weave-npc (Weave Network Policy Controller) — separate binary that watches Kubernetes NetworkPolicy resources and translates them into iptables rules. Required only if you want NetworkPolicy enforcement.
3. weave-cni — the CNI plugin in /opt/cni/bin/weave-net. Invoked by the runtime per Pod ADD/DEL. Allocates an IP from the agent’s distributed IPAM, creates the veth pair, attaches one end to the weave bridge.
4. weave-utils — a sidecar container with weave CLI for operators to inspect status (weave status, weave report).

The gossip mesh

Weave’s defining design choice was using a gossip protocol instead of a central coordinator (etcd, the K8s API, BGP route reflector). Each agent on startup:

1. Reads its bootstrap peer list (from a Helm value or env var) — typically the IPs of a few “seed” nodes.
2. Opens TCP connections on port 6783 to those peers.
3. Exchanges its identity (a random “short ID” plus a public key) and its current state (allocated IP ranges, peer list).
4. Propagates updates via gossip: every state change (new peer joins, IPAM allocation changes) eventually reaches every other peer.

Peers detect collisions on the random short ID and re-negotiate via the gossip protocol. The mesh is eventually consistent, not strongly consistent — and Weave designed for this: gossiping happens continuously, IPAM uses CRDT-like allocation maps that converge, and policy enforcement is per-node.

The gossip approach gives Weave its “no external dependency” claim — no etcd, no Consul, no API server requirement. But the trade-off is operational: debugging a partitioned mesh is harder than debugging a missing etcd write, and convergence times can be measured in seconds during churn.

Distributed IPAM

Weave’s IPAM is a CRDT-based distributed allocator. Each agent claims a chunk of the cluster CIDR, gossips the claim to other agents, and rebalances when nodes leave. New Pods get IPs from the local agent’s chunk — no API round-trip per Pod, unlike Calico’s IPAM blocks model or AWS VPC CNI’s ENI-secondary-IP allocation. The downside: IP ownership is gossiped, so during partition events you can briefly see duplicate-allocation races (rare in practice but not impossible).

Fast Datapath vs Sleeve mode

The data plane has two modes (github.com/weaveworks/weave/blob/master/docs/fastdp.md):

Fast Datapath (default since Weave 1.2, automatically enabled with no flag; encrypted fast datapath arrived in Weave 1.9): in-kernel VXLAN built on the Open vSwitch datapath module. Packets traverse the kernel’s vxlan-6784 device, get encapsulated by the kernel, and leave via the physical interface as VXLAN-over-UDP/6784 packets. The userspace weaver is uninvolved in the per-packet path; it only programs the OVS datapath up front. With encryption enabled, packets are protected via IPsec ESP transport mode with AES-GCM, 32-byte key and 4-byte salt per connection direction (fastdp-crypto.md).

Sleeve mode (fallback): userspace forwarding. The kernel pulls packets up to weaver; weaver encrypts each one with NaCl secretbox (XSalsa20 stream cipher + Poly1305 authenticator) using the per-session key (see Encryption); weaver sends the encrypted blob over the gossip TCP connection (port 6783) to the peer’s weaver, which decrypts and reinjects into the kernel.

The decision per peer pair is made at connection-establishment time: if the peers can VXLAN-tunnel each other (OVS datapath present, no NAT in path, UDP/6784 reachable, path MTU adequate), they use fast datapath; otherwise they fall back to sleeve. The fastdp docs note sleeve is also preferred when path-MTU problems arise, because sleeve has “a more sophisticated dynamic mechanism for coping with low path MTUs” (fastdp.md). The choice can change over the connection’s lifetime as conditions change.

The performance gap is large. Fast datapath sustains 10+ Gbps with modest CPU; sleeve maxes out at low hundreds of Mbps before the userspace path becomes the bottleneck. Operators were strongly encouraged to ensure fast datapath worked.

Encryption

Weave was an early CNI that shipped end-to-end encryption — a feature Calico only added in BGP-routed mode via WireGuard much later, and that Flannel gets via its WireGuard backend. Encryption is enabled by supplying a password (the WEAVE_PASSWORD env var / a --password flag, typically from a Kubernetes Secret). The key handshake is not PBKDF2 (a common misstatement): per Weave’s own implementation notes (encryption-implementation.md), each pair of peers performs a Curve25519 Diffie-Hellman exchange over the control connection to derive a shared secret, appends the supplied password to that shared secret, and hashes the concatenation through SHA-256 to form the ephemeral per-session key. That session key then drives two distinct encryption regimes:

• Control plane (TCP) and sleeve-mode data plane (UDP): every message is sealed with NaCl’s secretbox.Seal — i.e. XSalsa20 stream cipher + Poly1305 authenticator — using a nonce built from a per-message sequence number plus a connection-polarity bit (encryption-implementation.md).
• Fast-datapath data plane: packets are protected with IPsec ESP in transport mode (RFC 2406), each VXLAN packet encrypted with AES-GCM (RFC 4106), 32-byte key + 4-byte salt. The per-direction in/out keys are derived with HKDF-SHA256 from the same Mesh-library session key, salted by randomly generated 32-byte nonceIn/nonceOut values exchanged over the encrypted control channel, with 64-bit extended sequence numbers (ESN) for anti-replay (fastdp-crypto.md).

For its time (~2015–2018), built-in encryption was a differentiating capability. By 2024, encrypted-overlay options had become commonplace (WireGuard in Flannel, IPsec in many CNIs, mesh-mTLS in Istio / Linkerd), eroding Weave’s unique value proposition.

NetworkPolicy

Weave Net supports Kubernetes NetworkPolicy via the weave-npc controller. Implementation: weave-npc watches the API server for NetworkPolicy objects, translates them into iptables rules in the WEAVE-NPC-* chains, and programs them on every node (tkng.io). The result is functionally equivalent to Calico’s iptables-mode policy enforcement, though with less surface area (no Calico GlobalNetworkPolicy, no NetworkSet, no service-account-based selectors).

Why Weave declined

Several forces aligned against Weave by ~2020:

1. Calico matured into the default for policy-conscious clusters and added VXLAN mode (closing Weave’s “no-BGP option” advantage).
2. Cilium arrived with eBPF and observability that Weave couldn’t match without a fundamental rewrite.
3. Cloud CNIs (AWS VPC CNI, Azure CNI, GKE Dataplane V2) became defaults on managed clouds, where most new K8s deployments live.
4. Weaveworks the company focused on its commercial products (Weave GitOps, Weave Cloud) and reduced investment in Weave Net itself. The official Weaveworks release line stopped at v2.8.1 (January 2021) — three years before the company shutdown.
5. The CNCF ecosystem moved on. Weave Net was never a CNCF-hosted project; the CNCF energy was around Calico → Cilium → Cilium-as-default.

The company’s shutdown in February 2024 (techcrunch.com) was triggered by failed funding/merger attempts despite “substantial growth in 2023,” per CEO Alexis Richardson’s LinkedIn announcement. The original weaveworks/weave repository was archived (read-only) in mid-2024. Maintenance then shifted to the community fork rajch/weave, which resumed releases (v2.8.2 → v2.8.10 through 2024, then v2.9.0 in December 2024); so while the company-led decline is real, the codebase itself did not die in 2024 the way the company did.

Configuration / API Surface

Installing Weave Net (the URL has changed)

The classic Weaveworks install command pointed at cloud.weave.works, which generated a manifest tailored to your Kubernetes version:

# DEAD — do not use. cloud.weave.works no longer serves manifests.
$ kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')&env.WEAVE_PASSWORD=<secret>"

After Weaveworks shut down, cloud.weave.works stopped serving manifests (tracked in weaveworks/weave#3960), and the weave.works domain itself now resolves to an unrelated parked/spam site (confirmed 2026-05-22). The community fork republished the manifest-generation service at reweave.azurewebsites.net (rajch.github.io/weave). The current install methods are:

# Version-pinned manifest from the community service:
$ kubectl apply -f https://reweave.azurewebsites.net/k8s/v1.29/net.yaml
 
# Or pull a release manifest directly from the fork:
$ kubectl apply -f https://github.com/rajch/weave/releases/latest/download/weave-daemonset-k8s-1.11.yaml

Operators on existing Weave-Net clusters who must reinstall should either point at the community fork’s service above or mirror a known-good manifest locally rather than depending on the dead cloud.weave.works endpoint.

The DaemonSet shape (excerpt)

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: weave-net
  namespace: kube-system
spec:
  template:
    spec:
      hostNetwork: true                          # (1) needs host network for VXLAN
      hostPID: true
      containers:
      - name: weave
        image: ghcr.io/weaveworks/launcher/weave-kube:2.8.1
        command: [ "/home/weave/launch.sh" ]
        env:
        - name: HOSTNAME
          valueFrom: { fieldRef: { fieldPath: spec.nodeName } }
        - name: WEAVE_PASSWORD                   # (2) enables encryption
          valueFrom:
            secretKeyRef: { name: weave-passwd, key: pwd }
        - name: IPALLOC_RANGE                    # (3) cluster Pod CIDR
          value: 10.32.0.0/12
      - name: weave-npc                          # (4) NetworkPolicy controller
        image: ghcr.io/weaveworks/launcher/weave-npc:2.8.1

1. weaver runs in the host’s network and PID namespaces to manage VXLAN devices.
2. WEAVE_PASSWORD enables end-to-end encryption.
3. Pod CIDR; default is 10.32.0.0/12 (a large /12 chunk).
4. weave-npc is a separate container that handles NetworkPolicy enforcement.

Verification

$ kubectl exec -n kube-system weave-net-xxxxx -- /home/weave/weave --local status
 
        Version: 2.8.1 (failed to check latest version - see logs; next check at ...)
        Service: router
        Protocol: weave 1..2
            Name: 4a:7c:de:11:22:33(node-1)
       Encryption: enabled
    PeerDiscovery: enabled
          Targets: 0
      Connections: 3 (3 established)
            Peers: 4 (with 12 established connections)
   TrustedSubnets: none

The weave status command reports mesh health: connected peers, encryption state, established connections.

Failure Modes

1. Fast datapath silently disabled. Some kernels (especially older or stripped-down ones) lack the openvswitch kernel module or the vxlan module Weave needs. Symptom: throughput is hundreds of Mbps instead of multi-Gbps. Diagnostic: weave status shows Sleeve instead of FastDP. Fix: install openvswitch kernel module; on RHEL/CentOS, ensure the openvswitch-kmod package is installed.
2. NAT in path causes sleeve fallback. Nodes behind NAT (multi-cloud, hybrid deployments) can’t establish bidirectional VXLAN UDP/6784. Symptom: only NAT-traversing pairs use sleeve mode, others use fast datapath, with hugely asymmetric performance. Fix: open UDP/6784 in NAT, or accept sleeve performance, or pick a different CNI.
3. Gossip mesh partition during rolling upgrade. During a kubelet/control-plane upgrade, multiple weave agents restart simultaneously; the gossip mesh re-converges, sometimes briefly losing IPAM consistency. Symptom: occasional Pod CreationCheck failures during upgrade windows. Fix: serialize upgrades or accept the brief window.
4. cloud.weave.works install URL dead. After Weaveworks shutdown, the canonical install URL (the one most older installation docs point at) no longer serves manifests, and weave.works now resolves to a parked/spam domain. Symptom: kubectl apply against the old URL fails or returns garbage. Fix: use the community fork’s service at reweave.azurewebsites.net, or mirror a known-good manifest locally (see Configuration section).
5. NetworkPolicy not enforced. If weave-npc failed to start (image pull, RBAC), NetworkPolicy objects appear in the API but aren’t enforced. Symptom: kubectl get networkpolicy shows the policy, but traffic flows freely. Diagnostic: kubectl get pods -n kube-system | grep weave-npc. Fix: investigate weave-npc Pod status.
6. Encryption mismatch causes total network outage. If one node’s WEAVE_PASSWORD differs from another’s (e.g., during a Secret rotation), the two can’t communicate. Symptom: cluster-wide Pod-to-Pod failure across the affected node pair. Fix: align secrets cluster-wide.
7. IP allocation collision. Rare race in the distributed IPAM during gossip-mesh partition can lead to two Pods with the same IP. Symptom: random TCP RSTs, “address in use” errors. Fix: restart weave on the affected nodes to trigger reallocation; very rare in practice.
8. CVE / maintenance risk. The original weaveworks/weave repository is archived and patches nothing. The community fork rajch/weave does cut releases (its 2024 releases were partly motivated by refreshing the Go toolchain and base images to clear CVEs), but it is a single-maintainer, best-effort project with no commercial SLA and a slow cadence. The realistic operational risk in 2026 is therefore not “zero patches forever” but “depending on a thinly-staffed community fork for security updates” — still a strong reason to plan a migration off Weave Net for anything security-sensitive at scale.

Alternatives and When to Choose Them

• Cilium — the modern eBPF replacement. CNCF-graduated, actively developed, richer feature set than Weave ever had. The first-choice migration target.
• Calico — established alternative with BGP, VXLAN-overlay, eBPF-data-plane options. Most direct functional replacement (similar feature scope: forwarding + policy + encryption-via-WireGuard).
• Flannel + Calico (Canal) — if simplicity matters more than features. Flannel handles forwarding; Calico-policy-only handles NetworkPolicy.
• AWS VPC CNI / Azure CNI / GKE Dataplane V2 — managed-cloud defaults. On managed K8s, the default is almost always a better choice than Weave.
• kindnet / kube-router — niche; minimal feature sets.

For migration from existing Weave Net clusters, the recommended path is:

1. Pick a new CNI (Cilium for green-field, Calico for direct policy-feature parity).
2. Test in staging.
3. Drain a node, change the CNI DaemonSet, reboot the node, verify, repeat per node. Pods get new IPs from the new IPAM during the transition — plan for the rolling-replace.

Production Notes

• Weaveworks shutdown story — Alexis Richardson’s LinkedIn post (February 2024): “Hi everyone, I am very sad to announce that Weaveworks is closing its doors.” Despite substantial 2023 revenue growth, the company couldn’t close a funding round or strategic merger. The CNCF project Weaveworks created (Flux) found a new home under the CNCF; Weave Net, never a CNCF project, instead landed with a volunteer community fork.
• Industry coverage — TechCrunch, The New Stack, The Register, SD Times, Codefresh all covered the shutdown. The narrative was uniform: a beloved early-CNCF company that couldn’t translate engineering excellence into a sustainable commercial model.
• Releases, official vs community — Weaveworks’ last release was v2.8.1 (January 25, 2021) — a three-year gap before the company’s Feb-2024 shutdown, reflecting that company investment had already trickled to maintenance-only. The community fork rajch/weave then resumed the line: v2.8.2 (March 2024) through v2.8.10 (October 2024), and v2.9.0 (December 22, 2024) — release tags and dates verified against the GitHub Releases API on 2026-05-22.
• Repository status — the original weaveworks/weave was archived (read-only, last code push 2024-08-09) in mid-2024; new maintenance happens in the active rajch/weave fork (last push 2025-09-16 as of this writing). Issue #3948 (“Opening up development of Weave Net”) is where Richardson (GitHub monadic) publicly endorsed the community-maintenance plan and thanked the fork maintainers.
• Historical importance — Weave Net was one of the earliest Kubernetes CNIs (alongside Flannel and Calico) to ship support for the K8s 1.x API. Its mesh-gossip and dual-mode-datapath designs influenced subsequent CNIs even though those specific patterns weren’t broadly adopted. Worth understanding for its place in the history of container networking, similar to how ReplicationController is worth understanding even though everyone uses Deployment today.
• Operational stance in 2026 — running Weave Net in production in 2026 means depending on a single-maintainer community fork for updates rather than a vendor. That is materially better than “no patches at all,” but still a thin support base; for security-sensitive or large-scale clusters, planning a migration to Cilium or Calico remains the prudent default.

See Also

• Container Network Interface — the plugin spec Weave implements
• Pod Networking — the universal mechanism Weave participates in
• Calico — most direct functional replacement (forwarding + policy + encryption)
• Cilium — modern eBPF-based migration target
• Flannel — simpler sibling; pair with Calico-policy for full Weave functional parity
• AWS VPC CNI / Azure CNI / GKE Dataplane V2 — managed-cloud alternatives
• NetworkPolicy — what Weave Net enforces via weave-npc
• Flux — Weaveworks’ other major CNCF contribution; now community-stewarded under CNCF
• Kubernetes MOC — umbrella index