SRv6 with Cilium (eBPF)¶

Cilium is the eBPF-based networking layer (CNI) for Kubernetes. It can make each Kubernetes node an SRv6 endpoint: pod traffic is encapsulated into SRv6 by eBPF programs on the node, and SRv6 packets addressed to the node's SIDs are decapsulated into the right tenant. What you get depends on which Cilium you run:

Why Cilium + SRv6?¶

Router-based SRv6 implementations (IOS-XR, Junos, SR OS, FRRouting) stop at the PE. With SRv6 in the CNI, the fabric extends into the Kubernetes node: each worker node gets its own locator and SIDs and exchanges VPN routes with the PE routers over BGP, so tenant traffic leaves the node already encapsulated.

graph TB
    subgraph K8s Cluster A
        P1[Pod] --> N1["K8s Node\n(Cilium agent\n+ eBPF SRv6)"]
    end
    subgraph SRv6 Fabric
        R1[PE / Route Reflector] <-->|"BGP VPNv4/v6\nSRv6 Prefix-SID"| N1
        R1 <-->|"IS-IS"| R2[P Router]
        R2 <-->|"BGP VPNv4/v6\nSRv6 Prefix-SID"| N2
    end
    subgraph K8s Cluster B
        N2["K8s Node\n(Cilium agent\n+ eBPF SRv6)"] --> P2[Pod]
    end

The Open-Source Datapath¶

All of open-source Cilium's SRv6 code is in bpf/lib/srv6.h and the maps it reads. It implements:

There is no transit SRv6 processing (End, End.X), no multi-SID segment lists, no flavors, no L2 behaviors and no uSID in the open-source datapath. Both flags (--enable-srv6, --srv6-encap-mode) are hidden and marked beta in the agent (source). Reduced encapsulation has been the default since 1.13 (source).

eBPF maps¶

Older releases (up to 1.15) also had cilium_srv6_state_v4/_v6 maps; they were later removed.

Where it runs¶

Both directions are TC programs, not XDP: encapsulation runs on pod egress (bpf_lxc.c, tail call CILIUM_CALL_SRV6_ENCAP) and decapsulation in cil_from_netdev in bpf_host.c. The XDP program explicitly skips SRv6 handling. eBPF programs run inside the kernel; this is not kernel bypass.

Inspecting the datapath¶

# List the SRv6 maps (the agent CLI was renamed cilium-dbg in 1.15)
cilium-dbg bpf srv6 vrf
cilium-dbg bpf srv6 policy
cilium-dbg bpf srv6 sid

Hubble flows carry the trace reasons SRV6_ENCAP and SRV6_DECAP (from 1.15). There are no SRv6-specific Prometheus metrics; SRv6 drops are counted by the generic drop metrics.

Isovalent Enterprise: SRv6 L3VPN¶

Isovalent Enterprise for Cilium adds the control plane. Its documentation requires a login, so the details below come from Isovalent's Enterprise 1.13 announcement and from public Cisco lab material that runs the Enterprise product (Cisco Live LTRSPG-2212 lab); check them against your release.

• Locators and SIDs — IsovalentSRv6LocatorPool (with behaviorType: uSID or SRH, e.g. a 32/16/16 F3216 structure) and IsovalentSRv6SIDManager allocate a per-node locator and per-VRF SIDs such as uDT4.
• VRFs — IsovalentVRF classifies pods into tenants; route distinguishers and import/export route targets are set per VRF in IsovalentBGPClusterConfig.
• BGP — the BGP control plane is GoBGP (open source and Enterprise alike; FRR is not used). The lab peers over VPNv4 (afi: ipv4, safi: mpls_vpn) and advertises the locator itself as plain IPv6 unicast via IsovalentBGPAdvertisement (advertisementType: SRv6LocatorPool).

How the routes are signaled¶

The signaling follows RFC 9252, as on any SRv6 PE:

• One BGP session per peer carries the routes of every VRF; the route target extended communities place each prefix in the right VRF on the PE.
• The BGP next hop is the node's IPv6 address. The Service SID travels in the BGP Prefix-SID attribute (SRv6 L3 Service TLV), with the function bits transposed into the label field. In the Cisco lab, the IOS-XR route reflector shows a uDT4 SID (behavior 63) learned from the Cilium node this way.
• IPv4 tenant prefixes use VPNv4 (AFI 1 / SAFI 128) and IPv6 prefixes VPNv6 (AFI 2 / SAFI 128).

EVPN fabrics¶

Cilium does not speak BGP EVPN for SRv6; the open-source advertisement types are PodCIDR, CiliumPodIPPool, Service and Interface only (source). If the rest of your fabric carries tenant routes as EVPN Route Type 5 over SRv6, the PE that peers with the Kubernetes nodes must run VPNv4/VPNv6 toward them and re-originate the routes into EVPN (a gateway function). A plain route reflector cannot do this: it reflects routes within the same address family.

Comparison with Router-Based SRv6¶

See the SRv6 Support Matrix for open-source Cilium next to every other platform, behavior by behavior.

Further Reading¶

• SRv6 Support Matrix -- Cilium, Linux, FRR, VPP and vendor routers side by side
• Host-Based SRv6 -- How end-hosts participate in SRv6 without router involvement
• BGP Overlay Services -- VPNv4/VPNv6 signaling for SRv6 L3VPN
• Linux Kernel -- The kernel's own seg6 data plane, which Cilium does not use for SRv6
• FRRouting -- Open-source BGP/IS-IS for SRv6 on Linux hosts
• Cloud-Native Backbone -- SRv6 in cloud and container environments

References¶

1. Cilium source: bpf/lib/srv6.h (v1.20.0) -- The complete open-source SRv6 datapath and map definitions
2. Cilium source: hidden SRv6 agent flags (v1.20.0) -- --enable-srv6 (beta) and --srv6-encap-mode
3. Cilium 1.13 release blog -- SRv6 listed under Isovalent Cilium Enterprise; single SID only at the time
4. Isovalent Enterprise for Cilium 1.13 -- SRv6 L3VPN support, feature status Beta
5. cilium-dbg bpf srv6 command reference -- Listing the SRv6 eBPF maps
6. Cisco Live LTRSPG-2212 lab guide -- Public lab running Isovalent Enterprise SRv6 L3VPN with uSID against IOS-XR (secondary source)
7. RFC 9252 - BGP Overlay Services Based on SRv6 -- Service SIDs in the BGP Prefix-SID attribute
8. SRv6 on Cilium: an introductory demo (Isovalent) -- Video walkthrough of SRv6 L3VPN with Cilium