fix: Recover sidecar routes after galactic-cni reloads the eBPF datapath - #610
Merged
Merged
Conversation
vpc-vrf-sidecar wrote kernel state only on EndpointSlice changes and ensured a VRF's datapath only when first creating it. When galactic-cni reloaded the shared eBPF datapath (re-pinning usid_egress on every load, and recreating the maps empty on a schema change), the sidecar's veths kept the old program and its orphaned maps, and new route writes landed in maps nothing on those veths read. A miss falls through to the VRF default route and loops, and nothing recovered it short of a sidecar restart. Each sweep now reads the kernel IDs of the pinned usid_egress program and egress_route_table map. When either differs from the one the sidecar's writes went into, it re-runs EnsureVRF and EnsureRoute for every live VRF and route, re-registering map entries and re-attaching the current program. Routes in their teardown grace period are left alone, a partial failure retries on the next sweep, and an unreadable generation (datapath not loaded) is a no-op. SetDesired reads the generation before its first write so a reload between seed and first sweep is still caught. Adds a reapply_total counter and reapply_vrf/reapply_route error kinds. A root-gated integration test confirms a compatible reload changes the program ID while keeping the map ID. Fixes #609 Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
scotwells
approved these changes
Sep 25, 2026
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
2 participants
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.
Summary
When galactic-cni reloaded the shared eBPF datapath, vpc-vrf-sidecar kept its veths on the old program and never rewrote its routes, so affected traffic looped until the sidecar restarted. The sidecar now notices a reload within one sweep interval (5s by default) and reapplies every live VRF and route. Detection compares the kernel IDs of the pinned program and route map, so it only writes when something actually changed.
Test plan
Fixes #609
🤖 Generated with Claude Code