Correct what survives the switch to eBPF mode

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
 

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
 

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
 

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
 

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
 

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
 

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
 

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
 

calico/operations/ebpf/enabling-ebpf.mdx

@@ -391,8 +391,17 @@ calicoctl patch felixconfiguration default --patch='{"spec": {"bpfEnabled": true
 
 </Tabs>
 
-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
 

calico_versioned_docs/version-3.30/operations/ebpf/enabling-ebpf.mdx

@@ -358,8 +358,17 @@ calicoctl patch felixconfiguration default --patch='{"spec": {"bpfEnabled": true
 
 </Tabs>
 
-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
 

calico_versioned_docs/version-3.31/operations/ebpf/enabling-ebpf.mdx

@@ -392,8 +392,17 @@ calicoctl patch felixconfiguration default --patch='{"spec": {"bpfEnabled": true
 
 </Tabs>
 
-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
 

calico_versioned_docs/version-3.32/operations/ebpf/enabling-ebpf.mdx

@@ -391,8 +391,17 @@ calicoctl patch felixconfiguration default --patch='{"spec": {"bpfEnabled": true
 
 </Tabs>
 
-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