Repository navigation
Sidecar and host VRFs collide in shared maps #716
Description
Summary
The galactic-vrf sidecar writes into the same pinned eBPF maps as galactic-cni. Two of those maps are keyed by numbers each network namespace hands out on its own: the egress route map by VRF table ID, and the attachment map by interface index.
Both namespaces start from the same values, so a sidecar VRF and a host tenant VRF on the same node can overwrite each other's entries, or be mistaken for each other during cleanup. This needs a tenant VPC attached to the edge node itself, which is rare while edge nodes are tainted.
Acceptance criteria
- A sidecar VRF and a host tenant VRF with the same table ID on one node both route correctly
- The same holds for a sidecar interface and a host interface with the same index
Metadata
Metadata
Assignees
Type
Fields
Priority
None yet
Activity
privateip commentedon Oct 4, 2026
Read at main ca0e47a.
struct egress_route_keyininternal/plumbing/ebpf/prog/usid.c(line 519) carries onlytable_id, family and prefix, andifindex_vrf_table(line 758) is keyed by interface index. Both the host CNI and the sidecar allocate table IDs withfindNextAvailableVRFID(internal/plumbing/vrf/vrf.go:284), each inside its own network namespace, starting from the same minimum.egressroutemap.SidecarOwnedTableIDsthen classifies a table ID as sidecar-owned if any sidecarvrf_tablerow uses it, which would also capture a host table with the same number.A sidecar-only range for table IDs, or the writer's Block in the key, would separate the two populations.
fix: Name the remedy when an older sidecar's VRF or veth is in the way
test: Drop issue references from the #716 test comments