DOCS-2997: Point existing pages at L2 bridge networking - #2951
Open
ctauchen wants to merge 1 commit into
Open
Conversation
✅ Deploy Preview for calico-docs-preview-next ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview succeeded!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
Contributor
There was a problem hiding this comment.
Pull request overview
Updates several Calico Enterprise “next” documentation pages to reference and clarify the new L2 bridge networking feature set, including disambiguating terminology on the KubeVirt networking page and scoping a BGP-related statement to the pod-network path.
Changes:
- Add cross-references and guidance for L2 bridge networking across KubeVirt, Multus/multiple networks, and eBPF use-cases docs.
- Document per-interface forms of the
hwAddrandipAddrsannotations, including KubeVirt-specific guidance for MAC/IP identity. - Clarify that the existing “BGP without overlay” live-migration requirement applies to the pod network scenario described on the page (not to L2 bridge networks).
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| calico-enterprise/operations/ebpf/use-cases-ebpf.mdx | Adds L2 bridge networking as a consumer of the eBPF data plane and notes a feature-specific kernel minimum. |
| calico-enterprise/networking/kubevirt/kubevirt-networking.mdx | Adds a note disambiguating “bridge” terminology and scopes the BGP requirement to the pod-network path. |
| calico-enterprise/networking/ipam/use-specific-ip.mdx | Adds per-interface IP annotation guidance and L2 bridge–specific rationale for using ipAddrs. |
| calico-enterprise/networking/configuring/pod-mac-address.mdx | Adds per-interface MAC annotation guidance and notes preferred KubeVirt macAddress usage/consistency behavior. |
| calico-enterprise/networking/configuring/multiple-networks.mdx | Points Multus readers to the L2 bridge networking path and calls out the required Installation setting. |
Suppressed comments (1)
calico-enterprise/operations/ebpf/use-cases-ebpf.mdx:102
- This adds a per-feature kernel minimum (5.18) for L2 bridge networking. The eBPF installation page has a central table of "Kernel version requirements for eBPF features" (calico-enterprise/operations/ebpf/install.mdx around the Feature/Minimum kernel version table) but it doesn't currently list L2 bridge networking. To avoid kernel requirements being scattered across pages, consider adding L2 bridge networking to that table (or linking to it here).
[L2 bridge networking](../../networking/l2-bridge/about-l2-bridge.mdx) requires the eBPF
data plane. Enforcing policy on a bridged, VLAN-tagged segment is not possible with the
iptables data plane, and the eBPF data plane also raises the minimum kernel version for
that feature to 5.18.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Comment on lines
+93
to
+102
| ## Additional resources | ||
|
|
||
| To learn more and see performance metrics from our test environment, see the blog, [Introducing the eBPF data plane](https://www.projectcalico.org/introducing-the-calico-ebpf-dataplane/). | ||
|
|
||
| ## L2 bridge networking | ||
|
|
||
| [L2 bridge networking](../../networking/l2-bridge/about-l2-bridge.mdx) requires the eBPF | ||
| data plane. Enforcing policy on a bridged, VLAN-tagged segment is not possible with the | ||
| iptables data plane, and the eBPF data plane also raises the minimum kernel version for | ||
| that feature to 5.18. |
Comment on lines
+63
to
+77
| ## Additional resources | ||
|
|
||
| For help configuring $[prodname] CNI and $[prodname] IPAM, see [Configuring the $[prodname] CNI Plugins](../../reference/component-resources/configuration.mdx). | ||
|
|
||
| ## Requesting an address on another interface | ||
|
|
||
| The annotations above apply to a pod's primary interface. To request an address on an | ||
| additional interface, prefix the annotation with the interface name — for example, | ||
| `cni.projectcalico.org/vlan10.ipAddrs`. | ||
|
|
||
| For a workload on an [L2 bridge network](../l2-bridge/about-l2-bridge.mdx), use `ipAddrs` | ||
| rather than `ipAddrsNoIpam`. Bypassing IPAM leaves $[prodname] without a record of the | ||
| address, and on an L2 network that record is what lets $[prodname] tell the workload's own | ||
| traffic from spoofed traffic. See | ||
| [Bring a VM over with its IP and MAC](../l2-bridge/vm-identity.mdx). |
Update five existing pages so they account for the new L2 bridge networking set. The KubeVirt networking page uses the word bridge for KubeVirt's interface binding mode, which is a different thing from an L2 bridge network. That page now says so, and its statement that live migration requires BGP without overlay is scoped to the pod network path it describes, since it does not hold for a VM on an L2 network. The pod MAC address and specific IP address pages documented the flat form of their annotations only. Both now cover the per-interface form. The MAC page also points at KubeVirt's own field, and notes that setting both to conflicting values is rejected. The IP address page explains why an L2 workload should use ipAddrs rather than ipAddrsNoIpam. The multiple networks page points Multus readers at the L2 path and at the additional installation setting it needs. The eBPF use cases page records L2 bridge networking as a consumer of the eBPF data plane, with its higher kernel requirement. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ctauchen
force-pushed
the
DOCS-2997-9-surrounding-edits
branch
from
August 21, 2026 11:08
b24713d to
c91e292
Compare
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.
Updates five existing pages so they account for the new L2 bridge networking set. Last in the DOCS-2997 sequence. Small diffs, but two of them are correctness fixes rather than additions.
The KubeVirt networking page uses the word bridge for KubeVirt's interface binding mode, which connects a VM to its own pod interface. That is a different thing from an L2 bridge network, and the two pages now sit next to each other in the sidebar. A note disambiguates them.
The same page states that live migration requires BGP networking without overlay. That is true of the pod network path it describes, but not of a VM on an L2 network, whose address is reachable on the reader's own VLAN. The claim is now scoped, because left as it was it reads as contradicting the L2 story.
The remaining three are additions:
Reviewers may want to check the scoping of the BGP statement in particular. I am confident it does not apply to L2, but the sentence has been there a while and someone may have meant it more broadly.
Changed pages: