Correct what survives the switch to eBPF mode - #3009
Open
tomastigera wants to merge 1 commit into
Open
Conversation
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
✅ Deploy Preview succeeded!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for calico-docs-preview-next ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
The updated text introduces repeated terminology/consistency and grammar issues in the newly added paragraphs that should be corrected across all touched copies before merging.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
Updates the “Enable eBPF mode” documentation to accurately describe what happens to preexisting traffic when switching a running cluster from the standard data plane to the eBPF data plane, applied consistently across current and versioned product docs.
Changes:
- Replaces the blanket “should not be disrupted” statement with protocol-specific behavior (TCP vs non-TCP vs VXLAN overlay).
- Applies the same wording correction across Calico Open Source, Calico Enterprise, and Calico Cloud docs (including multiple versioned copies).
File summaries
| File | Description |
|---|---|
| calico/operations/ebpf/enabling-ebpf.mdx | Clarifies survivability of existing traffic across the switch, per protocol. |
| calico-enterprise/operations/ebpf/enabling-ebpf.mdx | Same protocol-specific clarification for Enterprise docs. |
| calico-cloud/operations/ebpf/enabling-ebpf.mdx | Same protocol-specific clarification for Cloud docs. |
| calico-enterprise_versioned_docs/version-3.24-2/operations/ebpf/enabling-ebpf.mdx | Propagates the clarification to this released Enterprise doc version. |
| calico-enterprise_versioned_docs/version-3.24-1/operations/ebpf/enabling-ebpf.mdx | Propagates the clarification to this released Enterprise doc version. |
| calico-enterprise_versioned_docs/version-3.23-2/operations/ebpf/enabling-ebpf.mdx | Propagates the clarification to this released Enterprise doc version. |
| calico-enterprise_versioned_docs/version-3.22-2/operations/ebpf/enabling-ebpf.mdx | Propagates the clarification to this released Enterprise doc version. |
| calico-enterprise_versioned_docs/version-3.21-2/operations/ebpf/enabling-ebpf.mdx | Propagates the clarification to this released Enterprise doc version. |
| calico-cloud_versioned_docs/version-23-2/operations/ebpf/enabling-ebpf.mdx | Propagates the clarification to this released Cloud doc version. |
| calico_versioned_docs/version-3.32/operations/ebpf/enabling-ebpf.mdx | Propagates the clarification to this released OSS doc version. |
| calico_versioned_docs/version-3.31/operations/ebpf/enabling-ebpf.mdx | Propagates the clarification to this released OSS doc version. |
| calico_versioned_docs/version-3.30/operations/ebpf/enabling-ebpf.mdx | Propagates the clarification to this released OSS doc version. |
Review details
Suppressed comments (12)
calico/operations/ebpf/enabling-ebpf.mdx:402
- The phrase “cannot tell a packet from an established UDP flow apart from a fresh one” mixes two idioms (“tell X from Y” vs “tell X apart from Y”) and reads ungrammatically.
- **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.
calico-enterprise/operations/ebpf/enabling-ebpf.mdx:238
- The phrase “cannot tell a packet from an established UDP flow apart from a fresh one” mixes two idioms (“tell X from Y” vs “tell X apart from Y”) and reads ungrammatically.
- **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.
calico-cloud/operations/ebpf/enabling-ebpf.mdx:251
- The phrase “cannot tell a packet from an established UDP flow apart from a fresh one” mixes two idioms (“tell X from Y” vs “tell X apart from Y”) and reads ungrammatically.
- **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.
calico-enterprise_versioned_docs/version-3.24-2/operations/ebpf/enabling-ebpf.mdx:238
- The phrase “cannot tell a packet from an established UDP flow apart from a fresh one” mixes two idioms (“tell X from Y” vs “tell X apart from Y”) and reads ungrammatically.
- **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.
calico-enterprise_versioned_docs/version-3.24-1/operations/ebpf/enabling-ebpf.mdx:238
- The phrase “cannot tell a packet from an established UDP flow apart from a fresh one” mixes two idioms (“tell X from Y” vs “tell X apart from Y”) and reads ungrammatically.
- **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.
calico-enterprise_versioned_docs/version-3.22-2/operations/ebpf/enabling-ebpf.mdx:206
- The phrase “cannot tell a packet from an established UDP flow apart from a fresh one” mixes two idioms (“tell X from Y” vs “tell X apart from Y”) and reads ungrammatically.
- **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.
calico-enterprise_versioned_docs/version-3.21-2/operations/ebpf/enabling-ebpf.mdx:206
- The phrase “cannot tell a packet from an established UDP flow apart from a fresh one” mixes two idioms (“tell X from Y” vs “tell X apart from Y”) and reads ungrammatically.
- **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.
calico-enterprise_versioned_docs/version-3.23-2/operations/ebpf/enabling-ebpf.mdx:238
- The phrase “cannot tell a packet from an established UDP flow apart from a fresh one” mixes two idioms (“tell X from Y” vs “tell X apart from Y”) and reads ungrammatically.
- **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.
calico-cloud_versioned_docs/version-23-2/operations/ebpf/enabling-ebpf.mdx:251
- The phrase “cannot tell a packet from an established UDP flow apart from a fresh one” mixes two idioms (“tell X from Y” vs “tell X apart from Y”) and reads ungrammatically.
- **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.
calico_versioned_docs/version-3.32/operations/ebpf/enabling-ebpf.mdx:403
- The phrase “cannot tell a packet from an established UDP flow apart from a fresh one” mixes two idioms (“tell X from Y” vs “tell X apart from Y”) and reads ungrammatically.
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
calico_versioned_docs/version-3.30/operations/ebpf/enabling-ebpf.mdx:369
- The phrase “cannot tell a packet from an established UDP flow apart from a fresh one” mixes two idioms (“tell X from Y” vs “tell X apart from Y”) and reads ungrammatically.
- **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.
calico_versioned_docs/version-3.31/operations/ebpf/enabling-ebpf.mdx:402
- The phrase “cannot tell a packet from an established UDP flow apart from a fresh one” mixes two idioms (“tell X from Y” vs “tell X apart from Y”) and reads ungrammatically.
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
- Files reviewed: 12/12 changed files
- Comments generated: 12
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Comment on lines
+243
to
+244
| 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: |
Comment on lines
+243
to
+244
| 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: |
Comment on lines
+230
to
+231
| 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: |
Comment on lines
+198
to
+199
| 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: |
Comment on lines
+198
to
+199
| 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: |
Comment on lines
+230
to
+231
| 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: |
Comment on lines
+394
to
+395
| 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: |
Comment on lines
+361
to
+362
| 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: |
Comment on lines
394
to
+395
|
|
||
| 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 |
Comment on lines
+395
to
+396
| eBPF mode’s advantages, and whether they survive the switch depends on the protocol: | ||
|
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The Enable eBPF mode section says preexisting connections "should not be disrupted". That holds only for TCP, so the page currently promises more than the dataplane delivers.
Replaced with what actually happens, per protocol: TCP connections survive including any address translation, because the translation lives in the Linux conntrack entry rather than in the
kube-proxyrules Calico removes; non-TCP traffic is treated as new, so a UDP flow to a service with several backends can move to a different one; and connections over a VXLAN overlay do not survive, because the device is recreated in eBPF mode and the kernel drops the conntrack state with it.Verified against the dataplane code and covered by a new functional verification test in projectcalico/calico#13778, which holds a TCP connection through a service across the switch and confirms it survives the removal of the
kube-proxyrules.Product Version(s): all — the sentence is identical and equally wrong in every version directory, so all 12 copies are corrected.
Issue: CORE-12056
Link to docs preview:
SME review:
DOCS review:
Additional information: the wording change came out of an investigation into which connections survive the iptables to eBPF switch. Written with Claude Code; I have reviewed every line and can explain the change.