From 17bbf7a364f108abde5e98c41a3b2d484eaeb538 Mon Sep 17 00:00:00 2001 From: Tomas Hruby Date: Thu, 3 Sep 2026 19:39:19 -0700 Subject: [PATCH 1/2] Correct what survives the switch to eBPF mode The page said preexisting connections "should not be disrupted", which is true only for TCP. Say what happens per protocol: TCP survives including its address translation, non-TCP is re-evaluated and can move to a different service backend, and flows over a VXLAN overlay do not survive the device being recreated. CORE-12056 --- calico-cloud/operations/ebpf/enabling-ebpf.mdx | 13 +++++++++++-- .../version-23-2/operations/ebpf/enabling-ebpf.mdx | 13 +++++++++++-- calico-enterprise/operations/ebpf/enabling-ebpf.mdx | 13 +++++++++++-- .../operations/ebpf/enabling-ebpf.mdx | 13 +++++++++++-- .../operations/ebpf/enabling-ebpf.mdx | 13 +++++++++++-- .../operations/ebpf/enabling-ebpf.mdx | 13 +++++++++++-- .../operations/ebpf/enabling-ebpf.mdx | 13 +++++++++++-- .../operations/ebpf/enabling-ebpf.mdx | 13 +++++++++++-- calico/operations/ebpf/enabling-ebpf.mdx | 13 +++++++++++-- .../version-3.30/operations/ebpf/enabling-ebpf.mdx | 13 +++++++++++-- .../version-3.31/operations/ebpf/enabling-ebpf.mdx | 13 +++++++++++-- .../version-3.32/operations/ebpf/enabling-ebpf.mdx | 13 +++++++++++-- 12 files changed, 132 insertions(+), 24 deletions(-) diff --git a/calico-cloud/operations/ebpf/enabling-ebpf.mdx b/calico-cloud/operations/ebpf/enabling-ebpf.mdx index 988ca64eed..cf260876aa 100644 --- a/calico-cloud/operations/ebpf/enabling-ebpf.mdx +++ b/calico-cloud/operations/ebpf/enabling-ebpf.mdx @@ -240,8 +240,17 @@ resource to `"BPF"`. kubectl patch installation.operator.tigera.io default --type merge -p '{"spec":{"calicoNetwork":{"linuxDataplane":"BPF"}}}' ``` -When enabling eBPF mode, preexisting connections continue to use the non-BPF datapath; such connections should -not be disrupted, but they do not benefit from eBPF mode’s advantages. +When enabling eBPF mode, preexisting connections keep using the non-eBPF datapath. They do not benefit from +eBPF mode’s advantages, and whether they survive the switch depends on the protocol: + +- **TCP connections continue to work**, including any address translation applied to them. The translation + lives in the Linux conntrack entry rather than in the `kube-proxy` rules that $[prodname] removes, so a + connection through a service keeps reaching the backend it was already using. +- **Traffic that is not TCP is treated as new.** eBPF mode cannot tell a packet from an established UDP flow + apart from a fresh one, so it applies policy and picks a service backend again. A UDP flow to a service + with several backends can move to a different backend. +- **Connections over a VXLAN overlay do not survive.** $[prodname] recreates the VXLAN device when it + switches to eBPF mode, and the kernel drops the conntrack state for the flows through it. :::note diff --git a/calico-cloud_versioned_docs/version-23-2/operations/ebpf/enabling-ebpf.mdx b/calico-cloud_versioned_docs/version-23-2/operations/ebpf/enabling-ebpf.mdx index 485288e922..42afa52d1f 100644 --- a/calico-cloud_versioned_docs/version-23-2/operations/ebpf/enabling-ebpf.mdx +++ b/calico-cloud_versioned_docs/version-23-2/operations/ebpf/enabling-ebpf.mdx @@ -240,8 +240,17 @@ resource to `"BPF"`. kubectl patch installation.operator.tigera.io default --type merge -p '{"spec":{"calicoNetwork":{"linuxDataplane":"BPF"}}}' ``` -When enabling eBPF mode, preexisting connections continue to use the non-BPF datapath; such connections should -not be disrupted, but they do not benefit from eBPF mode’s advantages. +When enabling eBPF mode, preexisting connections keep using the non-eBPF datapath. They do not benefit from +eBPF mode’s advantages, and whether they survive the switch depends on the protocol: + +- **TCP connections continue to work**, including any address translation applied to them. The translation + lives in the Linux conntrack entry rather than in the `kube-proxy` rules that $[prodname] removes, so a + connection through a service keeps reaching the backend it was already using. +- **Traffic that is not TCP is treated as new.** eBPF mode cannot tell a packet from an established UDP flow + apart from a fresh one, so it applies policy and picks a service backend again. A UDP flow to a service + with several backends can move to a different backend. +- **Connections over a VXLAN overlay do not survive.** $[prodname] recreates the VXLAN device when it + switches to eBPF mode, and the kernel drops the conntrack state for the flows through it. :::note diff --git a/calico-enterprise/operations/ebpf/enabling-ebpf.mdx b/calico-enterprise/operations/ebpf/enabling-ebpf.mdx index 8ee98946e0..c676ee2d95 100644 --- a/calico-enterprise/operations/ebpf/enabling-ebpf.mdx +++ b/calico-enterprise/operations/ebpf/enabling-ebpf.mdx @@ -227,8 +227,17 @@ resource to `"BPF"`. kubectl patch installation.operator.tigera.io default --type merge -p '{"spec":{"calicoNetwork":{"linuxDataplane":"BPF"}}}' ``` -When enabling eBPF mode, preexisting connections continue to use the non-BPF datapath; such connections should -not be disrupted, but they do not benefit from eBPF mode’s advantages. +When enabling eBPF mode, preexisting connections keep using the non-eBPF datapath. They do not benefit from +eBPF mode’s advantages, and whether they survive the switch depends on the protocol: + +- **TCP connections continue to work**, including any address translation applied to them. The translation + lives in the Linux conntrack entry rather than in the `kube-proxy` rules that $[prodname] removes, so a + connection through a service keeps reaching the backend it was already using. +- **Traffic that is not TCP is treated as new.** eBPF mode cannot tell a packet from an established UDP flow + apart from a fresh one, so it applies policy and picks a service backend again. A UDP flow to a service + with several backends can move to a different backend. +- **Connections over a VXLAN overlay do not survive.** $[prodname] recreates the VXLAN device when it + switches to eBPF mode, and the kernel drops the conntrack state for the flows through it. :::note diff --git a/calico-enterprise_versioned_docs/version-3.21-2/operations/ebpf/enabling-ebpf.mdx b/calico-enterprise_versioned_docs/version-3.21-2/operations/ebpf/enabling-ebpf.mdx index 53375aca0c..43ad36380f 100644 --- a/calico-enterprise_versioned_docs/version-3.21-2/operations/ebpf/enabling-ebpf.mdx +++ b/calico-enterprise_versioned_docs/version-3.21-2/operations/ebpf/enabling-ebpf.mdx @@ -195,8 +195,17 @@ resource to `"BPF"`. kubectl patch installation.operator.tigera.io default --type merge -p '{"spec":{"calicoNetwork":{"linuxDataplane":"BPF"}}}' ``` -When enabling eBPF mode, preexisting connections continue to use the non-BPF datapath; such connections should -not be disrupted, but they do not benefit from eBPF mode’s advantages. +When enabling eBPF mode, preexisting connections keep using the non-eBPF datapath. They do not benefit from +eBPF mode’s advantages, and whether they survive the switch depends on the protocol: + +- **TCP connections continue to work**, including any address translation applied to them. The translation + lives in the Linux conntrack entry rather than in the `kube-proxy` rules that $[prodname] removes, so a + connection through a service keeps reaching the backend it was already using. +- **Traffic that is not TCP is treated as new.** eBPF mode cannot tell a packet from an established UDP flow + apart from a fresh one, so it applies policy and picks a service backend again. A UDP flow to a service + with several backends can move to a different backend. +- **Connections over a VXLAN overlay do not survive.** $[prodname] recreates the VXLAN device when it + switches to eBPF mode, and the kernel drops the conntrack state for the flows through it. :::note diff --git a/calico-enterprise_versioned_docs/version-3.22-2/operations/ebpf/enabling-ebpf.mdx b/calico-enterprise_versioned_docs/version-3.22-2/operations/ebpf/enabling-ebpf.mdx index 20501b9e8a..7f10fdbcff 100644 --- a/calico-enterprise_versioned_docs/version-3.22-2/operations/ebpf/enabling-ebpf.mdx +++ b/calico-enterprise_versioned_docs/version-3.22-2/operations/ebpf/enabling-ebpf.mdx @@ -195,8 +195,17 @@ resource to `"BPF"`. kubectl patch installation.operator.tigera.io default --type merge -p '{"spec":{"calicoNetwork":{"linuxDataplane":"BPF"}}}' ``` -When enabling eBPF mode, preexisting connections continue to use the non-BPF datapath; such connections should -not be disrupted, but they do not benefit from eBPF mode’s advantages. +When enabling eBPF mode, preexisting connections keep using the non-eBPF datapath. They do not benefit from +eBPF mode’s advantages, and whether they survive the switch depends on the protocol: + +- **TCP connections continue to work**, including any address translation applied to them. The translation + lives in the Linux conntrack entry rather than in the `kube-proxy` rules that $[prodname] removes, so a + connection through a service keeps reaching the backend it was already using. +- **Traffic that is not TCP is treated as new.** eBPF mode cannot tell a packet from an established UDP flow + apart from a fresh one, so it applies policy and picks a service backend again. A UDP flow to a service + with several backends can move to a different backend. +- **Connections over a VXLAN overlay do not survive.** $[prodname] recreates the VXLAN device when it + switches to eBPF mode, and the kernel drops the conntrack state for the flows through it. :::note diff --git a/calico-enterprise_versioned_docs/version-3.23-2/operations/ebpf/enabling-ebpf.mdx b/calico-enterprise_versioned_docs/version-3.23-2/operations/ebpf/enabling-ebpf.mdx index ed8d781ad4..85927738a7 100644 --- a/calico-enterprise_versioned_docs/version-3.23-2/operations/ebpf/enabling-ebpf.mdx +++ b/calico-enterprise_versioned_docs/version-3.23-2/operations/ebpf/enabling-ebpf.mdx @@ -227,8 +227,17 @@ resource to `"BPF"`. kubectl patch installation.operator.tigera.io default --type merge -p '{"spec":{"calicoNetwork":{"linuxDataplane":"BPF"}}}' ``` -When enabling eBPF mode, preexisting connections continue to use the non-BPF datapath; such connections should -not be disrupted, but they do not benefit from eBPF mode’s advantages. +When enabling eBPF mode, preexisting connections keep using the non-eBPF datapath. They do not benefit from +eBPF mode’s advantages, and whether they survive the switch depends on the protocol: + +- **TCP connections continue to work**, including any address translation applied to them. The translation + lives in the Linux conntrack entry rather than in the `kube-proxy` rules that $[prodname] removes, so a + connection through a service keeps reaching the backend it was already using. +- **Traffic that is not TCP is treated as new.** eBPF mode cannot tell a packet from an established UDP flow + apart from a fresh one, so it applies policy and picks a service backend again. A UDP flow to a service + with several backends can move to a different backend. +- **Connections over a VXLAN overlay do not survive.** $[prodname] recreates the VXLAN device when it + switches to eBPF mode, and the kernel drops the conntrack state for the flows through it. :::note diff --git a/calico-enterprise_versioned_docs/version-3.24-1/operations/ebpf/enabling-ebpf.mdx b/calico-enterprise_versioned_docs/version-3.24-1/operations/ebpf/enabling-ebpf.mdx index 620de84325..fd26b27f91 100644 --- a/calico-enterprise_versioned_docs/version-3.24-1/operations/ebpf/enabling-ebpf.mdx +++ b/calico-enterprise_versioned_docs/version-3.24-1/operations/ebpf/enabling-ebpf.mdx @@ -227,8 +227,17 @@ resource to `"BPF"`. kubectl patch installation.operator.tigera.io default --type merge -p '{"spec":{"calicoNetwork":{"linuxDataplane":"BPF"}}}' ``` -When enabling eBPF mode, preexisting connections continue to use the non-BPF datapath; such connections should -not be disrupted, but they do not benefit from eBPF mode’s advantages. +When enabling eBPF mode, preexisting connections keep using the non-eBPF datapath. They do not benefit from +eBPF mode’s advantages, and whether they survive the switch depends on the protocol: + +- **TCP connections continue to work**, including any address translation applied to them. The translation + lives in the Linux conntrack entry rather than in the `kube-proxy` rules that $[prodname] removes, so a + connection through a service keeps reaching the backend it was already using. +- **Traffic that is not TCP is treated as new.** eBPF mode cannot tell a packet from an established UDP flow + apart from a fresh one, so it applies policy and picks a service backend again. A UDP flow to a service + with several backends can move to a different backend. +- **Connections over a VXLAN overlay do not survive.** $[prodname] recreates the VXLAN device when it + switches to eBPF mode, and the kernel drops the conntrack state for the flows through it. :::note diff --git a/calico-enterprise_versioned_docs/version-3.24-2/operations/ebpf/enabling-ebpf.mdx b/calico-enterprise_versioned_docs/version-3.24-2/operations/ebpf/enabling-ebpf.mdx index 2eb828ce69..645753bbb4 100644 --- a/calico-enterprise_versioned_docs/version-3.24-2/operations/ebpf/enabling-ebpf.mdx +++ b/calico-enterprise_versioned_docs/version-3.24-2/operations/ebpf/enabling-ebpf.mdx @@ -227,8 +227,17 @@ resource to `"BPF"`. kubectl patch installation.operator.tigera.io default --type merge -p '{"spec":{"calicoNetwork":{"linuxDataplane":"BPF"}}}' ``` -When enabling eBPF mode, preexisting connections continue to use the non-BPF datapath; such connections should -not be disrupted, but they do not benefit from eBPF mode’s advantages. +When enabling eBPF mode, preexisting connections keep using the non-eBPF datapath. They do not benefit from +eBPF mode’s advantages, and whether they survive the switch depends on the protocol: + +- **TCP connections continue to work**, including any address translation applied to them. The translation + lives in the Linux conntrack entry rather than in the `kube-proxy` rules that $[prodname] removes, so a + connection through a service keeps reaching the backend it was already using. +- **Traffic that is not TCP is treated as new.** eBPF mode cannot tell a packet from an established UDP flow + apart from a fresh one, so it applies policy and picks a service backend again. A UDP flow to a service + with several backends can move to a different backend. +- **Connections over a VXLAN overlay do not survive.** $[prodname] recreates the VXLAN device when it + switches to eBPF mode, and the kernel drops the conntrack state for the flows through it. :::note diff --git a/calico/operations/ebpf/enabling-ebpf.mdx b/calico/operations/ebpf/enabling-ebpf.mdx index e85b359ad6..688ec89b8b 100644 --- a/calico/operations/ebpf/enabling-ebpf.mdx +++ b/calico/operations/ebpf/enabling-ebpf.mdx @@ -391,8 +391,17 @@ calicoctl patch felixconfiguration default --patch='{"spec": {"bpfEnabled": true -When enabling eBPF mode, preexisting connections continue to use the non-BPF datapath; such connections should -not be disrupted, but they do not benefit from eBPF mode’s advantages. +When enabling eBPF mode, preexisting connections keep using the non-eBPF datapath. They do not benefit from +eBPF mode’s advantages, and whether they survive the switch depends on the protocol: + +- **TCP connections continue to work**, including any address translation applied to them. The translation + lives in the Linux conntrack entry rather than in the `kube-proxy` rules that $[prodname] removes, so a + connection through a service keeps reaching the backend it was already using. +- **Traffic that is not TCP is treated as new.** eBPF mode cannot tell a packet from an established UDP flow + apart from a fresh one, so it applies policy and picks a service backend again. A UDP flow to a service + with several backends can move to a different backend. +- **Connections over a VXLAN overlay do not survive.** $[prodname] recreates the VXLAN device when it + switches to eBPF mode, and the kernel drops the conntrack state for the flows through it. ### Next steps diff --git a/calico_versioned_docs/version-3.30/operations/ebpf/enabling-ebpf.mdx b/calico_versioned_docs/version-3.30/operations/ebpf/enabling-ebpf.mdx index 8be583337d..cada31df43 100644 --- a/calico_versioned_docs/version-3.30/operations/ebpf/enabling-ebpf.mdx +++ b/calico_versioned_docs/version-3.30/operations/ebpf/enabling-ebpf.mdx @@ -358,8 +358,17 @@ calicoctl patch felixconfiguration default --patch='{"spec": {"bpfEnabled": true -When enabling eBPF mode, preexisting connections continue to use the non-BPF datapath; such connections should -not be disrupted, but they do not benefit from eBPF mode’s advantages. +When enabling eBPF mode, preexisting connections keep using the non-eBPF datapath. They do not benefit from +eBPF mode’s advantages, and whether they survive the switch depends on the protocol: + +- **TCP connections continue to work**, including any address translation applied to them. The translation + lives in the Linux conntrack entry rather than in the `kube-proxy` rules that $[prodname] removes, so a + connection through a service keeps reaching the backend it was already using. +- **Traffic that is not TCP is treated as new.** eBPF mode cannot tell a packet from an established UDP flow + apart from a fresh one, so it applies policy and picks a service backend again. A UDP flow to a service + with several backends can move to a different backend. +- **Connections over a VXLAN overlay do not survive.** $[prodname] recreates the VXLAN device when it + switches to eBPF mode, and the kernel drops the conntrack state for the flows through it. ### Try out direct server return mode diff --git a/calico_versioned_docs/version-3.31/operations/ebpf/enabling-ebpf.mdx b/calico_versioned_docs/version-3.31/operations/ebpf/enabling-ebpf.mdx index ebfb163081..031a82a43c 100644 --- a/calico_versioned_docs/version-3.31/operations/ebpf/enabling-ebpf.mdx +++ b/calico_versioned_docs/version-3.31/operations/ebpf/enabling-ebpf.mdx @@ -392,8 +392,17 @@ calicoctl patch felixconfiguration default --patch='{"spec": {"bpfEnabled": true -When enabling eBPF mode, preexisting connections continue to use the non-BPF datapath; such connections should -not be disrupted, but they do not benefit from eBPF mode’s advantages. +When enabling eBPF mode, preexisting connections keep using the non-eBPF datapath. They do not benefit from +eBPF mode’s advantages, and whether they survive the switch depends on the protocol: + +- **TCP connections continue to work**, including any address translation applied to them. The translation + lives in the Linux conntrack entry rather than in the `kube-proxy` rules that $[prodname] removes, so a + connection through a service keeps reaching the backend it was already using. +- **Traffic that is not TCP is treated as new.** eBPF mode cannot tell a packet from an established UDP flow + apart from a fresh one, so it applies policy and picks a service backend again. A UDP flow to a service + with several backends can move to a different backend. +- **Connections over a VXLAN overlay do not survive.** $[prodname] recreates the VXLAN device when it + switches to eBPF mode, and the kernel drops the conntrack state for the flows through it. ### Next steps diff --git a/calico_versioned_docs/version-3.32/operations/ebpf/enabling-ebpf.mdx b/calico_versioned_docs/version-3.32/operations/ebpf/enabling-ebpf.mdx index 7070ae3290..b8b8e0082c 100644 --- a/calico_versioned_docs/version-3.32/operations/ebpf/enabling-ebpf.mdx +++ b/calico_versioned_docs/version-3.32/operations/ebpf/enabling-ebpf.mdx @@ -391,8 +391,17 @@ calicoctl patch felixconfiguration default --patch='{"spec": {"bpfEnabled": true -When enabling eBPF mode, preexisting connections continue to use the non-BPF datapath; such connections should -not be disrupted, but they do not benefit from eBPF mode’s advantages. +When enabling eBPF mode, preexisting connections keep using the non-eBPF datapath. They do not benefit from +eBPF mode’s advantages, and whether they survive the switch depends on the protocol: + +- **TCP connections continue to work**, including any address translation applied to them. The translation + lives in the Linux conntrack entry rather than in the `kube-proxy` rules that $[prodname] removes, so a + connection through a service keeps reaching the backend it was already using. +- **Traffic that is not TCP is treated as new.** eBPF mode cannot tell a packet from an established UDP flow + apart from a fresh one, so it applies policy and picks a service backend again. A UDP flow to a service + with several backends can move to a different backend. +- **Connections over a VXLAN overlay do not survive.** $[prodname] recreates the VXLAN device when it + switches to eBPF mode, and the kernel drops the conntrack state for the flows through it. ### Next steps From c2849dc70934d921b98add168d0ba084dfda6bd2 Mon Sep 17 00:00:00 2001 From: Tomas Hruby Date: Fri, 11 Sep 2026 15:17:20 -0700 Subject: [PATCH 2/2] Use the page's own terminology and note the node port exception Match 'standard data plane' and the straight apostrophe used elsewhere on the page, and reword the UDP bullet. On 3.30 and 3.31 a pre-existing connection to a node port with a remote backend is still lost where the filter FORWARD policy is DROP, so those two copies carry that exception. --- calico/operations/ebpf/enabling-ebpf.mdx | 10 +++++----- .../version-3.30/operations/ebpf/enabling-ebpf.mdx | 14 ++++++++------ .../version-3.31/operations/ebpf/enabling-ebpf.mdx | 14 ++++++++------ .../version-3.32/operations/ebpf/enabling-ebpf.mdx | 10 +++++----- 4 files changed, 26 insertions(+), 22 deletions(-) diff --git a/calico/operations/ebpf/enabling-ebpf.mdx b/calico/operations/ebpf/enabling-ebpf.mdx index 688ec89b8b..74dc3a1ee6 100644 --- a/calico/operations/ebpf/enabling-ebpf.mdx +++ b/calico/operations/ebpf/enabling-ebpf.mdx @@ -391,15 +391,15 @@ calicoctl patch felixconfiguration default --patch='{"spec": {"bpfEnabled": true -When enabling eBPF mode, preexisting connections keep using the non-eBPF datapath. They do not benefit from -eBPF mode’s advantages, and whether they survive the switch depends on the protocol: +When enabling eBPF mode, preexisting connections keep using the standard data plane. They do not benefit from +eBPF mode's advantages, and whether they survive the switch depends on the protocol: - **TCP connections continue to work**, including any address translation applied to them. The translation lives in the Linux conntrack entry rather than in the `kube-proxy` rules that $[prodname] removes, so a connection through a service keeps reaching the backend it was already using. -- **Traffic that is not TCP is treated as new.** eBPF mode cannot tell a packet from an established UDP flow - apart from a fresh one, so it applies policy and picks a service backend again. A UDP flow to a service - with several backends can move to a different backend. +- **Traffic that is not TCP is treated as new.** eBPF mode has no record of an established UDP + flow, so it applies policy and picks a service backend again. A UDP flow to a service with several + backends can move to a different backend. - **Connections over a VXLAN overlay do not survive.** $[prodname] recreates the VXLAN device when it switches to eBPF mode, and the kernel drops the conntrack state for the flows through it. diff --git a/calico_versioned_docs/version-3.30/operations/ebpf/enabling-ebpf.mdx b/calico_versioned_docs/version-3.30/operations/ebpf/enabling-ebpf.mdx index cada31df43..4650a141d7 100644 --- a/calico_versioned_docs/version-3.30/operations/ebpf/enabling-ebpf.mdx +++ b/calico_versioned_docs/version-3.30/operations/ebpf/enabling-ebpf.mdx @@ -358,15 +358,17 @@ calicoctl patch felixconfiguration default --patch='{"spec": {"bpfEnabled": true -When enabling eBPF mode, preexisting connections keep using the non-eBPF datapath. They do not benefit from -eBPF mode’s advantages, and whether they survive the switch depends on the protocol: +When enabling eBPF mode, preexisting connections keep using the standard data plane. They do not benefit from +eBPF mode's advantages, and whether they survive the switch depends on the protocol: - **TCP connections continue to work**, including any address translation applied to them. The translation lives in the Linux conntrack entry rather than in the `kube-proxy` rules that $[prodname] removes, so a - connection through a service keeps reaching the backend it was already using. -- **Traffic that is not TCP is treated as new.** eBPF mode cannot tell a packet from an established UDP flow - apart from a fresh one, so it applies policy and picks a service backend again. A UDP flow to a service - with several backends can move to a different backend. + connection through a service keeps reaching the backend it was already using. A connection to a node port + with a backend on another node is an exception: on a node whose `FORWARD` policy in the `filter` table is + DROP, it is lost. +- **Traffic that is not TCP is treated as new.** eBPF mode has no record of an established UDP + flow, so it applies policy and picks a service backend again. A UDP flow to a service with several + backends can move to a different backend. - **Connections over a VXLAN overlay do not survive.** $[prodname] recreates the VXLAN device when it switches to eBPF mode, and the kernel drops the conntrack state for the flows through it. diff --git a/calico_versioned_docs/version-3.31/operations/ebpf/enabling-ebpf.mdx b/calico_versioned_docs/version-3.31/operations/ebpf/enabling-ebpf.mdx index 031a82a43c..b321094cec 100644 --- a/calico_versioned_docs/version-3.31/operations/ebpf/enabling-ebpf.mdx +++ b/calico_versioned_docs/version-3.31/operations/ebpf/enabling-ebpf.mdx @@ -392,15 +392,17 @@ calicoctl patch felixconfiguration default --patch='{"spec": {"bpfEnabled": true -When enabling eBPF mode, preexisting connections keep using the non-eBPF datapath. They do not benefit from -eBPF mode’s advantages, and whether they survive the switch depends on the protocol: +When enabling eBPF mode, preexisting connections keep using the standard data plane. They do not benefit from +eBPF mode's advantages, and whether they survive the switch depends on the protocol: - **TCP connections continue to work**, including any address translation applied to them. The translation lives in the Linux conntrack entry rather than in the `kube-proxy` rules that $[prodname] removes, so a - connection through a service keeps reaching the backend it was already using. -- **Traffic that is not TCP is treated as new.** eBPF mode cannot tell a packet from an established UDP flow - apart from a fresh one, so it applies policy and picks a service backend again. A UDP flow to a service - with several backends can move to a different backend. + connection through a service keeps reaching the backend it was already using. A connection to a node port + with a backend on another node is an exception: on a node whose `FORWARD` policy in the `filter` table is + DROP, it is lost. +- **Traffic that is not TCP is treated as new.** eBPF mode has no record of an established UDP + flow, so it applies policy and picks a service backend again. A UDP flow to a service with several + backends can move to a different backend. - **Connections over a VXLAN overlay do not survive.** $[prodname] recreates the VXLAN device when it switches to eBPF mode, and the kernel drops the conntrack state for the flows through it. diff --git a/calico_versioned_docs/version-3.32/operations/ebpf/enabling-ebpf.mdx b/calico_versioned_docs/version-3.32/operations/ebpf/enabling-ebpf.mdx index b8b8e0082c..9bdf72ddea 100644 --- a/calico_versioned_docs/version-3.32/operations/ebpf/enabling-ebpf.mdx +++ b/calico_versioned_docs/version-3.32/operations/ebpf/enabling-ebpf.mdx @@ -391,15 +391,15 @@ calicoctl patch felixconfiguration default --patch='{"spec": {"bpfEnabled": true -When enabling eBPF mode, preexisting connections keep using the non-eBPF datapath. They do not benefit from -eBPF mode’s advantages, and whether they survive the switch depends on the protocol: +When enabling eBPF mode, preexisting connections keep using the standard data plane. They do not benefit from +eBPF mode's advantages, and whether they survive the switch depends on the protocol: - **TCP connections continue to work**, including any address translation applied to them. The translation lives in the Linux conntrack entry rather than in the `kube-proxy` rules that $[prodname] removes, so a connection through a service keeps reaching the backend it was already using. -- **Traffic that is not TCP is treated as new.** eBPF mode cannot tell a packet from an established UDP flow - apart from a fresh one, so it applies policy and picks a service backend again. A UDP flow to a service - with several backends can move to a different backend. +- **Traffic that is not TCP is treated as new.** eBPF mode has no record of an established UDP + flow, so it applies policy and picks a service backend again. A UDP flow to a service with several + backends can move to a different backend. - **Connections over a VXLAN overlay do not survive.** $[prodname] recreates the VXLAN device when it switches to eBPF mode, and the kernel drops the conntrack state for the flows through it.