Pin the MAC-first zone arm with a host-route nexthop scenario - #301
Merged
Merged
Conversation
…hop scenario Signed-off-by: arashi.li <arashi.li@bigstack.co>
arasHi87
force-pushed
the
arashi.li/host-route-nexthop
branch
from
August 18, 2026 07:05
5aa9fbf to
3d9191e
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.
Closes
Refs #302 — stays open for the live
scenariotest runon staging. The full rationale now lives there rather than in the source comment. Parent story #201.What & why
twovms-same-tenantcan't prove the hybrid lookup's MAC-first arm ever runs: its destination IP is the peer's IP, both insub-T1, so the MAC arm and the trie arm both answersame_tenantand it passes whichever executed.host-route-nexthopmakes them disagree — a host route steersvm-aatvm-nh(L2-adjacent, same tenant) toward10.0.82.0/24, a prefix absent from the topology. MAC arm sayssame_tenant; trie arm saysexternal(catchall). Assertingsame_tenant/txgrew whileexternalstayed flat pins which ran, and theexternalbound doubles as a check thatAddRouteSteptook.Deliberate omissions: an in-guest route stands in for a Neutron
host_routesentry (byte-identical frames — staging DHCP option 121 would test Neutron's DHCP agent, not the classifier); rx isn't asserted (there the trie resolvesvm-a's source IP insidesub-T1and also answerssame_tenant, so it'd prove delivery, not the arm).Test plan
task testtask test-integration(Docker, BPF caps)task bench-gate(hot-path changes only)scenariotest run <name>task testgreen,go vet ./cmd/...clean,internal/docs(chapter-citation guard) passes,scenariotest listshows it.Live validation (optional)
Not yet run — live-tier test, proves nothing until
scenariotest run host-route-nexthoppasses on dev-cmp or c36. Only real risk is ARP:vm-amust resolve.50tovm-nh's MAC. Downstream delivery is irrelevant — the assert is onvm-a's own tap and the drive is a sized-ping push tolerating no replies.Scope / deliberately not touched
No
internal/neutronunit test:neutron.Subnet(types.go:39) has noHostRoutesfield, so testing "host_routes is inert" would mean adding the field purely to assert we ignore it.Notes
Catalog-only — one scenario file plus one registry entry, no production code, no contract in
docs/architecture/contracts.mdtouched.DoD