eBPF Maps

All BPF maps are created with upper capacity limits. Insertion beyond the limit will fail and thus limits the scalability of the datapath. The following table shows the default values of the maps. Each limit can be bumped in the source code. Configuration options will be added on request if demand arises.

Map NameScopeDefault LimitScale Implications
Connection Trackingnode or endpoint1M TCP/256k UDPMax 1M concurrent TCP connections, max 256k expected UDP answers
NATnode512kMax 512k NAT entries
Neighbor Tablenode512kMax 512k neighbor entries
Endpointsnode64kMax 64k local endpoints + host IPs per node
IP cachenode512kMax 256k endpoints (IPv4+IPv6), max 512k endpoints (IPv4 or IPv6) across all clusters
Load Balancernode64kMax 64k cumulative backends across all services across all clusters
Policyendpoint16kMax 16k allowed identity + port + protocol pairs for specific endpoint
Proxy Mapnode512kMax 512k concurrent redirected TCP connections to proxy
Tunnelnode64kMax 32k nodes (IPv4+IPv6) or 64k nodes (IPv4 or IPv6) across all clusters
IPv4 Fragmentationnode8kMax 8k fragmented datagrams in flight simultaneously on the node
Session Affinitynode64kMax 64k affinities from different clients
IP Masqnode16kMax 16k IPv4 cidrs used by BPF-based ip-masq-agent
Service Source Rangesnode64kMax 64k cumulative LB source ranges across all services
Egress Policyendpoint16kMax 16k endpoints across all destination CIDRs across all clusters

For some BPF maps, the upper capacity limit can be overridden using command line options for cilium-agent. A given capacity can be set using --bpf-ct-global-tcp-max, --bpf-ct-global-any-max, --bpf-nat-global-max, --bpf-neigh-global-max, --bpf-policy-map-max, --bpf-fragments-map-max and --bpf-lb-map-max.

Note

In case the --bpf-ct-global-tcp-max and/or --bpf-ct-global-any-max are specified, the NAT table size (--bpf-nat-global-max) must not exceed 2/3 of the combined CT table size (TCP + UDP). This will automatically be set if either --bpf-nat-global-max is not explicitly set or if dynamic BPF map sizing is used (see below).

Using the --bpf-map-dynamic-size-ratio flag, the upper capacity limits of several large BPF maps are determined at agent startup based on the given ratio of the total system memory. For example, a given ratio of 0.0025 leads to 0.25% of the total system memory to be used for these maps.

This flag affects the following BPF maps that consume most memory in the system: cilium_ct_{4,6}_global, cilium_ct_{4,6}_any, cilium_nodeport_neigh{4,6}, cilium_snat_v{4,6}_external and cilium_lb{4,6}_reverse_sk.

kube-proxy sets as the maximum number entries in the linux’s connection tracking table based on the number of cores the machine has. kube-proxy has a default of 32768 maximum entries per core with a minimum of 131072 entries regardless of the number of cores the machine has.

Cilium has its own connection tracking tables as BPF Maps and the number of entries of such maps is calculated based on the amount of total memory in the node with a minimum of 131072 entries regardless the amount of memory the machine has.

The following table presents the value that kube-proxy and Cilium sets for their own connection tracking tables when Cilium is configured with --bpf-map-dynamic-size-ratio: 0.0025.

vCPUMemory (GiB)Kube-proxy CT entriesCilium CT entries
13.75131072131072
27.5131072131072
415131072131072
830262144284560
1660524288569120
3212010485761138240
6424020971522276480
9636031457284552960