Cilium is ten years old, and in that time it has become a go to dataplane for cloud native networking and security. Today it powers managed Kubernetes networking in major public cloud offerings, including Google Kubernetes Engine Dataplane V2 and Azure Kubernetes Service via Azure CNI powered by Cilium. Cilium 1.19 carries that momentum forward with a release focused on secure connectivity and operator clarity. In the highlights below, you will see updates across network policy improvements, Hubble signals for encrypted traffic and scaled logging, plus continued progress across routing, IPsec, IPv6, Multi Pool IPAM, Gateway API, and BGP. If you want a practical guide to go deeper, the new O’Reilly book Cilium Up and Running is now available. It covers how Cilium works and how to run it in real clusters, from networking and policy through to observability and multi cluster patterns. Highlights at a glance This latest release from the open source Cilium project includes lots of improvements across a number of areas, we’ve included quick browse links to jump to the sections you are most interested in! Connectivity BPF Host Routing with IPsec: Improve IPsec performance by using BPF host routing for faster route lookups. (more details) Gateway API v1.4 support and GRPCRoute: Use the latest Gateway API resources and route gRPC traffic natively with GRPCRoute. (more details) IPv6 support for L2 announcements: Advertise service virtual IPs over IPv6 using Neighbor Discovery, extending L2 announcements beyond IPv4. (more details) IPv6 underlay for dual stack tunneling: Run VXLAN or Geneve tunnel underlay over IPv6 in dual stack clusters. (more details) BGP updates: Advertise interface addresses, bind sessions to a stable source interface, withdraw empty service routes, and move to the v2 BGP APIs. (more details) Multi-Pool IPAM Label selectors for Pod IP pools: Allocate pod IPs based on pool selectors, with explicit precedence and safer matching behavior. (more details) Multi Pool IPAM with IPsec and direct routing: Use multiple pod IP pools while keeping pod to pod traffic encrypted with IPsec in direct routing. (more details) Masquerade controls for multi subnet and IPAM pool traffic: Tune source NAT for multi subnet node traffic and preserve pod IPs for selected pools. (more details) Security Host firewall now supports VRRP and IGMP: Match and control VRRP and IGMP traffic in host firewall rules. (more details) Friendlier IPv4 egress denies with ICMP destination unreachable: Return ICMP destination unreachable for denied egress connections to reduce silent timeouts. (more details) DNS policy wildcards for multi level subdomains: Match multi level subdomains using wildcard prefix patterns such as *. (more details) Ztunnel integration for transparent encryption: Enroll namespaces into ztunnel for transparent TCP encryption and workload authentication. (more details) Observability IP packet tracing: Trace specific packets through the datapath using IPv4 IP options and follow the trace in Hubble. (more details) Hubble flow log aggregation: Reduce exported log volume by aggregating flows before they leave the cluster. (more details) Filter Hubble flows by encryption status: Quickly see whether observed traffic is encrypted or unencrypted. (more details) Support for VRRP and IGMP traffic: Hubble flows now have additional support for VRRP and IGMP traffic. (more details) Platform Helm charts available via OCI registries: Pull Cilium Helm charts from an OCI registry such as quay.io for simpler supply chain workflows. (more details) Deprecations and upgrade notes: Review removed and deprecated fields and defaults that may impact upgrades. (more details) Connectivity BPF Host Routing with IPsec This Cilium update makes it possible to enable IPsec and BPF Host Routing at the same time. Before this change, trying to turn on both features would cause the Cilium agent to fail, forcing users to choose between encrypted node-to-node traffic or the high-performance eBPF host routing path. With this update, IPsec encryption and BPF Host Routing are now compatible and can run together without conflict. To configure, enable both bpf.hostLegacyRouting to true and also set encryption.type to use ipsec. From a networking perspective, this means traffic can stay on the optimized eBPF forwarding path while still being encrypted at Layer 3. BPF Host Routing avoids the traditional Linux routing and iptables, which significantly reduces overhead. Gateway API v1.4.0 Support Cilium 1.19 updates its Gateway API implementation to the v1.4 series, aligning with the current upstream spec and keeping you on a supported path as the ecosystem moves beyond Ingress. Alongside the version bump, Cilium supports GRPCRoute as a first class resource, so the same Gateway API model can cover both HTTPRoute and gRPC traffic, with the same operational experience you already expect from Cilium. This matters for two common adoption paths. For ingress style traffic management, you can route gRPC natively using GRPCRoute, and the Cilium docs include a working example, including the ALPN setting needed for TLS terminated HTTP 2. For service mesh style traffic management, Gateway API v1.4 made GRPCRoute a requirement for GAMMA mesh conformance, and Cilium now supports GRPCRoute in GAMMA alongside HTTPRoute, keeping conformance tests passing and giving teams one consistent API for both north to south and east to west routing patterns. If you want to see this in a real application scenario, our Ingress NGINX migration guide walks through exposing Argo CD with Gateway API, including the GRPCRoute used for gRPC traffic alongside the HTTPRoute. L2 announcement IPv6 support Cilium 1.19 extends L2 Announcements to IPv6, so services can be advertised on the local network using Neighbor Discovery, in the same way IPv4 services are advertised using ARP. This removes the earlier IPv6 limitation and lets you use the same L2 aware service model for ExternalIPs and LoadBalancer IPs in IPv6 only and dual stack environments. This is especially useful for on premises clusters where BGP based service advertising is not available or not desired. A single node is elected per service to answer ARP and NDP queries with its own MAC address, then Cilium handles service load balancing behind that virtual IP, and failover is handled by lease based election. Configuration is unchanged at a high level, you enable L2 Announcements and then scope where and what gets advertised using a CiliumL2AnnouncementPolicy. Watch Nico take you through using this enhancement. Support IPv6 underlay on dual-stack clusters Cilium 1.19 extends IPv6 underlay support to dual stack clusters when you run in tunneling mode. This lets you keep dual stack addressing for workloads, while carrying the VXLAN or Geneve encapsulation traffic between nodes over IPv6, which is useful when your physical network is IPv6 first or you want to remove IPv4 as a dependency in the underlay. Cilium uses the node IPv6 address for tunnel endpoints, and the MTU calculation accounts for the selected underlay protocol so the effective tunnel MTU is computed correctly. To enable this feature, set the underlay protocol to IPv6 in the Cilium Helm values. BGP Updates Cilium 1.19 brings a set of practical BGP improvements aimed at real world designs with multi interface nodes and resilient service advertising. Key changes in this release include: Advertise addresses from interfaces A new Interface advertisement type lets you advertise IPs assigned to a local interface, such as a loopback address. This is useful for multi homing patterns where you want the same node address advertised across multiple sessions on different interfaces. Override the BGP session source IP You can now set a sourceInterface on the BGP transport config so the session source IP comes from that interface, instead of being inferred from the egress interface. This makes it easier to bind sessions to a loopback address that is not coupled to the lifecycle of a specific physical interface. Withdraw empty service routes Cilium can optionally withdraw service VIP routes when a Service has zero endpoints, for cases where externalTrafficPolicy or internalTrafficPolicy is Cluster. This helps anycast style setups fail over cleanly to another cluster or data center that is also advertising the VIP, rather than continuing to attract traffic to a location that cannot serve it. Multi-Pool IPAM Multi Pool IPAM is now a stable capability in Cilium 1.19, and this release makes it far easier to use as a policy driven approach to pod IP allocation, not just a way to add more pod CIDRs. The updates in this section focus on three outcomes, more predictable pool selection, broader compatibility with encrypted direct routing, and better control over when Cilium should, and should not, apply masquerade. The subsections below walk through what is new, starting with label selector support and clearer allocation precedence, then moving into IPsec support for multi pool deployments, and finishing with masquerade controls that help preserve pod IPs and handle multi subnet node reachability. In this release the Multi-Pool IPAM feature moves from “beta” to “stable” feature status. Multi-Pool IPAM introduces label selector support for PodIPPools Improvements on how IP addresses are assigned when using Multi-Pool IPAM, making the selection logic more explicit, predictable, and safer. In Multi-Pool IPAM, Cilium can manage multiple IP pools and assign pod IPs based on intent rather than just availability. This change clearly defines a precedence order for how a pod gets an IP, starting with explicit annotations on the pod or namespace, followed by label selectors on the pool, and finally falling back to the default pool if nothing matches. For example, you can create a pool for all your frontend services, using a label selector: Then, you can assign a Pod to get an IP from that range by matching the label: This Pod will get an IP address from the frontend-pool range: This update also tightens correctness and safety. A pod must match exactly one pool per IP family, otherwise allocation fails, which prevents accidental overlap between address ranges. Users can now enforce strict behavior using the require-pool-match annotation, which blocks IP assignment until a non-default pool is available and matched. This is useful in environments where IP separation matters, such as isolating workloads by tenant, security zone, or network path. This update makes Cilium IPAM behave more like a policy-driven IP allocation system, which should feel familiar if you are used to structured address planning in traditional networking. Multi-Pool IPAM mode with IPSec This release adds support for Multi-Pool IPAM in environments using IPsec encryption with native or direct routing. With this update, Pods using secondary IP pools can now securely communicate using IPsec even when no overlay is present. This ensures that encrypted traffic is correctly routed between Pods in different pools without packet loss. Now administrators can define multiple IP address pools and control which Pods get which IPs, while still using IPsec for traffic confidentiality. Cilium automatically sets up the necessary encryption policies for all pools, so traffic from Pods in non-default pools is handled correctly. This makes Multi-Pool IPAM compatible with high-performance direct routing and IPsec, giving clusters both flexibility in IP assignment and security without sacrificing performance. Masquerade tuning for multi pool IPAM and remote nodes Cilium 1.19 expands control over IP masquerade so it better fits real production topologies. Two common pain points are addressed, pods reaching node addresses across different subnets when eBPF masquerade is enabled, and preserving pod source IPs for selected Multi Pool IPAM ranges that are routed in your underlay network Masquerade traffic to remote node addresses When using eBPF masquerade, traffic from pods to a remote node address can need source NAT to behave consistently across subnets. Cilium 1.19 introduces an option to enable masquerade for this specific path, covering traffic from an endpoint to a remote node address. The is configured at the Cilium Agent level; Note: This setting can reduce Cilium host firewall enforcement for pod to node traffic, so if you enable it, review the docs and consider the default deny policy posture for access to nodes. Exclude selected Multi Pool IPAM ranges from masquerade If you use Multi Pool IPAM with underlay routing, for example, announcing pod ranges through BGP, you may want to preserve the source IP for pods from specific pools so downstream systems can apply firewall, audit, or routing policy based on the real pod address. Cilium 1.19 adds two ways to do this when eBPF masquerade is enabled. Option 1, only masquerade the default pool, set at the Cilium Agent level using --only-masquerade-default-pool. Option 2, configure per pool behavior using an annotation on the pool; More details can be found in the Cilium IPAM documentation. Security Host firewall now supports VRRP and IGMP Host firewall is an advanced policy capability that lets you define and enforce security intent for traffic entering and leaving your Kubernetes nodes. It is a powerful control, but it also comes with a practical reality: not all node level infrastructure traffic looks like a TCP or UDP flow. Two common examples are VRRP and IGMP. VRRP is widely used for virtual IP failover with tools like keepalived, and IGMP is required for multicast group membership. These protocols sit below the transport layer, so there is no concept of ports to match on. Before this change, with host firewall enforcement enabled, VRRP and IGMP traffic could be treated as unknown protocol traffic and dropped. Cilium 1.19 adds host firewall policy support for VRRP and IGMP, using the same policy language you already use today. Instead of introducing a new policy section, the existing toPorts rules are extended so you can match VRRP and IGMP directly. Since these protocols do not have transport layer ports, policy validation is relaxed so a protocol only rule is valid. The below example shows the implementation of the support for VRRP. This example host firewall policy that applies to nodes labeled type: egress-worker, and it defines an egress allow list for those nodes. It permits only the outbound traffic the node needs for cluster and Cilium operations, Kubernetes API on 6443, HTTPS on 443, etcd on 2379, the Cilium health endpoint on 4240, and VXLAN on 8472. At the end it also allows VRRP as an IP protocol, which has no ports, so the rule matches on protocol only. Any other egress traffic from those nodes is denied once host firewall enforcement is in place. Configurable ICMP response behaviour With this feature, Cilium can now be configured to send explicit ICMP “Destination Unreachable” responses when egress traffic is blocked by a CiliumNetworkPolicy. By default, denied traffic is silently dropped, which can cause applications to hang until their own timeouts expire. By setting the policyDenyResponse=icmp option during installation, the Cilium agent lets the datapath immediately notify the source requester that the connection is denied. This makes it clear which traffic is blocked without waiting for a timeout. The below details the available configuration in the helm values file. When this feature is enabled, clients will now receive the following message: This improves observability and debugging in Kubernetes clusters by giving faster feedback when egress policies prevent communication. Currently, this feature applies only to IPv4 egress traffic and is considered experimental, but it provides a more predictable and transparent experience for policy enforcement. DNS-based Policy Wildcards introduces the **. Prefix A new enhancement in Cilium’s security policy language is support for the **. prefix in DNS-based network policies. This feature brings more flexibility and precision to DNS-based access controls. Previously, Cilium supported the single-segment * wildcard, which matches any sequence of characters within a single DNS label. For instance, *.cilium.io matches sub.cilium.io but not subB.subA.cilium.io or the base domain. This provided flexible matching for direct subdomains, but not for entire subdomain hierarchies, an area now addressed by the new **. prefix. Now in Cilium 1.19, by using the special **. prefix, you can efficiently match all cascaded subdomains of a given domain in a single rule. For example: The pattern **.cilium.io will match requests to both app.cilium.io and test.app.cilium.io, as well as deeper subdomains like service.test.app.cilium.io. Importantly, it will not match the parent domain itself (cilium.io), ensuring that your policies target only the intended subdomain levels. This enhancement simplifies policy management and reduces the risk of unintentionally broad access permissions. With this update, Cilium users can write more concise, expressive, and secure DNS-based policies, making it easier to enforce least-privilege network access at scale. The below is an example CiliumNetworkPolicy implementing this new feature; This policy allows pods labeled app: test-app to: Query DNS from kube-dns in the kube-system namespace (any DNS request, due to dns: - matchPattern: "*") Access any subdomain of cilium.io over egress (for example, docs.cilium.io, api.dev.cilium.io, but not cilium.io itself), thanks to the new **.cilium.io match pattern. Introducing support for Ztunnel Service mesh style identity and encryption is a common requirement, but the traditional model, a sidecar proxy per pod, adds operational overhead, consumes resources, and increases the number of moving parts that you need to troubleshoot. Ztunnel takes a different approach, initially part of Istio Ambient Mesh. It is a purpose-built per node proxy (much like Cilium’s service mesh implementation) that provides transparent Layer 4 mutual TLS (mTLS) for pod to pod traffic, without requiring application changes. Cilium 1.19 adds an initial Ztunnel integration as a new transparent encryption mode, thanks to the significant contributions from the engineers at Microsoft and Isovalent. Cilium acts as the control plane for Ztunnel, providing workload discovery and certificate issuance, then enrolling workloads per namespace and transparently redirecting traffic to the local Ztunnel instance using iptables in the pod network namespace. This is a beta feature today, and it is primarily aimed at early adopters who want to explore ambient mesh style encryption, with a clear understanding of the current gaps and tradeoffs. The following installs Cilium with Ztunnel as the encryption mode, and deploys an opinionated Ztunnel DaemonSet that is wired up to Cilium’s control plane; Before installing, you must create the cilium-ztunnel-secrets secret in the kube-system namespace; the official documentation includes a script that generates the required keys and certificates. Once Ztunnel is enabled, workloads only participate once you explicitly enroll their namespace, which can be achieved as so; Ztunnel support in Cilium is currently in Beta. Some capabilities are still evolving, so review the documentation for current limitations and configuration guidance before rolling this out in production. Observability IP Packet Tracing This feature introduces packet tracing using IP options, allowing users to tag specific packets with a trace ID and follow them through the datapath. When a packet with a valid trace ID is seen, Cilium records the ID in a lightweight eBPF map and emits trace events to Hubble. This lets you track individual packets across the cluster without enabling verbose tracing for all traffic. The feature is designed to have minimal impact on normal traffic and only parses IP option fields when packet tracing is enabled. For example, you can install Cilium with IP option 136, which is the Stream Identifier (SID) option for IPv4, by using helm value bpf.monitorTraceIPOption=136 setting. You can then trace packets using an SID: This allows users to see a packet’s exact path through the network, even when NAT or overlays change addresses. It is particularly useful for debugging multi-cluster or complex Kubernetes setups, where traditional flow-based logs may lose context. By only tracing packets that carry a trace ID, you get precise insights without overwhelming the cluster with data, making troubleshooting faster and more efficient. Support for FlowLog Aggregation This feature adds configurable Hubble flow log aggregation, allowing you to group and summarize flow logs before they are exported. Previously, Hubble exported every flow individually, which could produce massive amounts of logs in busy clusters. With this update, you can aggregate flows by fields such as source namespace, destination service, or verdict, and set an interval for aggregation, for example every 30 seconds. This lets Hubble export summarized counts instead of thousands of individual entries. You can configure this by setting in the Cilium values file under the array hubble.export.dynamic with the following command/configuration (which shows dynamic mode): You can check full configuration options for Flow Aggregation by visiting the official documentation page. You will see that flows will now be aggregate for export: Aggregated flow logs reduce storage and processing overhead while preserving key information such as verdicts and identity context. This is especially useful in clusters with many short-lived connections, frequent DNS queries, or high monitoring traffic, making analytics and dashboards easier to manage. Filter Hubble flows by encryption status Transparent encryption is only useful if you can prove it is actually happening. In a real cluster, changes like enabling encryption, doing rolling upgrades, or fixing drift can leave parts of the data path unencrypted. Hubble already records whether a flow was encrypted, but until now you could not filter your flow stream on that field. With the Cilium 1.19, filtering by encryption status is added to Hubble, so you can instantly focus on traffic that is encrypted with WireGuard or IPsec, or find traffic that is unencrypted. In earlier Cilium releases, encryption validation was a manual spot check task. We show a method of doing so in our lab “Cilium Transparent Encryption with IPSec and WireGuard” using wireshark. With this release, you can now perform this check easily and continuously; Troubleshooting, quickly confirm whether the paths you are investigating are encrypted, then focus on the outliers. Upgrades, validate mixed mode periods and find gaps early, before they become a compliance or incident review problem. Audit and posture checks, produce a clear view of unencrypted flows that should not exist. The below asciinema playback shows this new feature in action! Support for VRRP and IGMP This release now gives Hubble’s visibility a boost by adding explicit support for VRRP and IGMP traffic. Prior, Hubble mainly focused on common transport protocols like TCP and UDP. Traffic using VRRP or IGMP was either ignored or shown as generic “unknown” traffic because those protocols were not fully parsed or classified. This feature complements the earlier discussed feature where Host Firewall supports VRRP and IGMP protocols. VRRP is commonly used for high availability by allowing multiple routers to share a virtual IP address, while IGMP is used to manage multicast group membership. With this update, Hubble can now correctly identify, log, and filter these protocols, making Kubernetes networking observability closer to what you would expect from classic network monitoring tools like NetFlow, but with Kubernetes context layered on top. Platform Cilium Helm Chart now using OCI With the release of 1.19, additional usability improvements including adding support for publishing Helm charts as OCI (Open Container Interface) artifacts. Instead of relying on a traditional Helm repository, charts can now live in any OCI-compatible registry like Quay or Docker. With OCI charts, you can install directly via an OCI reference (oci://quay.io/cilium/charts/cilium) and optionally pin to a digest for reproducible deployments. It also enables signing and verification using standard OCI tools, keeping the distribution of Cilium images and charts unified in one place. Deprecations and upgrade notes Cilium 1.19 also includes a small set of deprecations and behavior changes that are worth reviewing before you upgrade. Key items to be aware of: FromRequires and ToRequires are no longer accepted These fields were previously deprecated and, in 1.19, policies are validated so they must be empty. Remove them from your Cilium policies before upgrading. Kafka network policy support is deprecated Kafka protocol matching in policy is deprecated and is planned for removal in Cilium v1.20, so plan to migrate away if you rely on it. Cluster Mesh policy selectors default to local cluster In Cluster Mesh, selectors that do not explicitly specify clusters now default to selecting endpoints in the local cluster only. You can retain the earlier behavior via the policy-default-local-cluster option, but it is better to update policies to be explicit where cross cluster communication is required. BGP configuration moves fully to cilium.io/v2 Support for the older CiliumBGPPeeringPolicy API has been removed, and BGP should now be configured using the cilium.io/v2 CRDs. Please see the Cilium documentation covering upgrade and version specific notes. Conclusion Cilium 1.19 keeps pushing in a direction platform teams care about most, secure connectivity you can reason about, and operations that stay clear as clusters grow. Between stricter encryption modes, policy updates that remove ambiguity, Multi Pool IPAM reaching stable status, and continued investment in BGP, IPv6, and Gateway API, this release helps you run modern Kubernetes networking with fewer surprises. This release is also a reflection of the community behind Cilium. It includes 2,934 new commits from a growing community of over 1,010 developers, and the project now has over 23,600 GitHub stars. If you want to see how teams are running Cilium in production, check out the latest case studies from Airbnb, Cloudera, Cybozu, ESnet, Nutanix, OVHcloud, TikTok, and University of Wisconsin–Madison. If you are more interested in the first decade of Cilium and what comes next, check out the community eCHO episode 200, “Celebrating a Decade of Cilium” If you are evaluating Cilium for production, planning an upgrade, or trying to simplify a mixed environment across cloud and on premises, Isovalent can help. Talk to our engineers and experts behind Cilium for architecture reviews, migration planning, and best practice guidance across policy, encryption, routing, and observability.