netlib: resolve isolated gateway MAC inside the task netns - #5132
Merged
Merged
Conversation
The isolated platform installs a permanent ARP neighbor for the VPC gateway so the micro-VM guest (which has no L2 broadcast) can reach it. resolveHostNeighbor obtained the gateway MAC from the host root netns ARP cache. On ECS managed instances the host instance's subnet may or may not match the task's subnet; when they differ, the host has no interface on the task's subnet and its ARP cache never contains the task's gateway, so setup failed with: ResourceInitializationError: gateway MAC not in host neighbor cache: no neighbor entry for <gw> in host ARP table This affected any task whose subnet differed from the host's (both IPv4-on-dualstack and dualstack-on-IPv4 instance combinations), i.e. the case that dualstack rollout exposed. It is not IPv6-specific; only IPv6-only ENIs skip the IPv4 path. Resolve the gateway MAC from inside the task netns instead, where the task ENI carries the task's own VPC IP and has L2 reachability to the gateway regardless of the host's subnet. addGatewayNeighbor now does the resolution within ExecInNSPath: look up the interface, poll its neighbor table (nudging the kernel to ARP the gateway between polls) until a resolved entry appears or a timeout elapses, then install the permanent neighbor + /32 link-scope route as before. Tests updated for the in-netns flow and a gateway-not-resolvable case.
amogh09
approved these changes
Sep 10, 2026
willmyrs
approved these changes
Sep 10, 2026
hoshank10
reviewed
Sep 10, 2026
| return errors.Wrapf(linkErr, "failed to find device %s in task netns", eni.DeviceName) | ||
| } | ||
|
|
||
| gwMAC, err := il.resolveGatewayNeighbor(link, gwIP) |
Contributor
There was a problem hiding this comment.
gwMAC is no longer logged, are we missing out on helpful data?
Contributor
Author
There was a problem hiding this comment.
The error from the func should be good for us to troubleshooting but no harm to log it.
hoshank10
approved these changes
Sep 10, 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
5 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
The isolated platform installs a permanent ARP neighbor for the VPC gateway so the micro-VM guest (which has no L2 broadcast) can reach it. resolveHostNeighbor obtained the gateway MAC from the host root netns ARP cache. On ECS managed instances the host instance's subnet may or may not match the task's subnet; when they differ, the host has no interface on the task's subnet and its ARP cache never contains the task's gateway, so setup failed with:
This affected any task whose subnet differed from the host's (both IPv4-on-dualstack and dualstack-on-IPv4 instance combinations), i.e. the case that dualstack rollout exposed. It is not IPv6-specific; only IPv6-only ENIs skip the IPv4 path.
Resolve the gateway MAC from inside the task netns instead, where the task ENI carries the task's own VPC IP and has L2 reachability to the gateway regardless of the host's subnet. addGatewayNeighbor now does the resolution within ExecInNSPath: look up the interface, poll its neighbor table (nudging the kernel to ARP the gateway between polls) until a resolved entry appears or a timeout elapses, then install the permanent neighbor + /32 link-scope route as before.
Implementation details
Resolve the gateway MAC from inside the task netns instead, where the task ENI carries the task's own VPC IP and has L2 reachability to the gateway regardless of the host's subnet. addGatewayNeighbor now does the resolution within ExecInNSPath: look up the interface, poll its neighbor table (nudging the kernel to ARP the gateway between polls) until a resolved entry appears or a timeout elapses, then install the permanent neighbor + /32 link-scope route as before.
Testing
New tests cover the changes: Yes
Run the e2e tests locally on isolated platform on ECS MI where the IPv4 tasks can run on dualstack instances and dualstack tasks can run on IPv4 instances.
Description for the changelog
Additional Information
Does this PR include breaking model changes? If so, Have you added transformation functions?
Does this PR include the addition of new environment variables in the README?
Licensing
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.