Repository navigation
fix: Keep sidecar and host VRFs apart in the shared eBPF maps - #772
Conversation
The galactic-vrf sidecar writes into the same pinned maps as the host CNI, from inside its pod's network namespace. egress_route_table is keyed by VRF table ID and ifindex_vrf_table by interface index, and each namespace hands both out on its own from 1 upward. A sidecar VRF and a host tenant VRF on one edge node could therefore overwrite each other's routes, and usid_egress could route one's traffic into the other's VRF. The two writers now use disjoint ranges: - Host VRF tables 1 to 0xEFFF, skipping the kernel's reserved tables 253 to 255. The installer's sidecar return-path tables keep 0xF000 to 0xFFFF in the host namespace. - Sidecar VRF tables 0x10000 plus the uSID Argument, through vrf.AddInRange. argumentForTableID becomes an offset from that base. - Sidecar veth peers are created with the explicit index 0x40000000 plus the Argument. IfindexVRFTable.Register rejects a sidecar row with any other index and a host row at or above 0x40000000. SidecarOwnedTableIDs still reads ownership from vrf_table, so sidecar pods running the old version keep being recognised during a rollout. AddInRange rejects an existing VRF whose table is outside the caller's range, so an old pod must be replaced rather than restarted in place on the new image. Fixes #716 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A sidecar container restarted in place on the new image finds the VRF and veth peer an older version created in the same pod network namespace, outside the new ranges. Both errors now say to replace the pod rather than restart the container. vrf.AddInRange wraps a new ErrTableOutOfRange so the sidecar can recognise that case. Related to #716 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
pr-adversary merge. pr-conventions-reviewer held on two decisions: #634 merge order (whichever lands second rebases, its change does not depend on the numbering) and rollout behavior (image rollouts replace sidecar pods, no separate step), both resolved by the author. pr-rereviewer merge. pr-conventions-reviewer held on the same #634 decision plus a body warning, both resolved by the author stating rollout behavior in the body and filing #773 for stale sidecar map rows. pr-adversary ran: galactic/CLAUDE.md, commit-conventions/SKILL.md, pr-conventions/SKILL.md, clear-writing phrase table, pr details, both reviewer reports, the findings checklist. pr-conventions-reviewer ran: pr body, commit messages, test plan, findings against the gate. pr-rereviewer ran: same as first pass. All findings were applied: worktree state confirmed clean, findings in code and body applied, tests confirmed passing (root-only AddInRange test run as root by author), and test comments issue references dropped in commit 389c4fb. CI result: Build, Lint, Unit Tests, Unit Tests (root), E2E Tests all pass; all image builds pass; license/cla pass. Merge method enabled: merge (creating a merge commit), as allowed by the base branch ruleset. Auto-merge is enabled and will complete once a code owner approves, as the ruleset requires one approval after the latest push. |
2 participants
Summary
The ingress sidecar and the host CNI write the same pinned eBPF maps, but each numbers VRF tables and interfaces on its own from 1, so on an edge node with a tenant VPC attached their routes could overwrite each other.
The sidecar now takes table IDs and interface indexes from ranges the host never uses, and registering an index outside its writer's range is refused.
An image rollout replaces sidecar pods, which is all this needs, while a container restarted in place inside an old pod fails with an error naming that remedy.
Rows that deleted sidecar pods leave in the maps are tracked in #773.
Test plan
Fixes #716
🤖 Generated with Claude Code