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..74dc3a1ee6 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 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 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. ### 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..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,8 +358,19 @@ 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 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. 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. ### 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..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,8 +392,19 @@ 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 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. 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. ### 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..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,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 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 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. ### Next steps