Simplify IPv6 Gateway Calculation #2703
Conversation
| gatewayRule := n.netLink.NewRule() | ||
| gatewayRule.Src = &net.IPNet{IP: *gw, Mask: net.CIDRMask(128, 128)} | ||
| gatewayRule.Src = &net.IPNet{IP: GetIPv6Gateway(), Mask: net.CIDRMask(128, 128)} |
There was a problem hiding this comment.
I'm curious: Was this sufficient and necessary, during your testing?
If I remember my AWS-internal discussion with the VPC folks leading up to this FE80:EC2::1 launch, the idea was that the gateway would respond to these additional addresses, but still use the original SLAAC address for traffic initiated from the gateway (eg router advertisements). This was an important detail, to avoid changing any user-visible behaviour.
I'm not sure what "can resolve their gateway" includes exactly. I think what you've done in this PR is break router-initiated RAs, but (continue to) allow explicit host-initiated NDs. If so, I think one of the following is true:
- sgpp needs ICMPv6, and this breaks it (RAs?), and we need to fix/revert this line. 👎
- sgpp needs ICMPv6, and works with this change (NDs? dhcp6?). Best answer if true, but something feels odd that we don't need all the other variants of gateway address too ($subnet::1, original SLAAC address). 👍
- sgpp no longer needs ICMPv6 at all now that we're hardcoding fe80:ec2::1 elsewhere, and ICMPv6 to/from gateway is broken but we don't care. 😐
If it's this third case, I think we should remove this createIPv6GatewayRule() function entirely.
There was a problem hiding this comment.
Yes, this rule is required. The way that the route tables are setup for SGPP (same for IPv6 as is for IPv4), Neighbor Discovery initiated by the host needs this carve-out in order to receive the NA to its NS. We disable RA (accept_ra=0) on the VLAN interfaces and pod veth pair, so we need ND to succeed.
As for the address itself, I do see NA coming from the gateway using fe80:ec2::1. It may be safer to include the other variants, though.
What type of PR is this?
cleanup
Which issue does this PR fix:
N/A
What does this PR do / Why do we need it:
This PR takes the finding in #2700 and applies it to simplify IPv6 gateway calculation for IPv6 Security Groups for Pods support. The IPv6 gateway for a subnet can always be reached from the node via
fe80:ec2::1.If an issue # is not available please add repro steps and logs from IPAMD/CNI showing the issue:
N/A
Testing done on this change:
Manually verified that all integration tests pass against an IPv6 cluster, including the
pod-enitest suite.Will this PR introduce any new dependencies?:
No
Will this break upgrades or downgrades? Has updating a running cluster been tested?:
No, Yes
Does this change require updates to the CNI daemonset config files to work?:
No
Does this PR introduce any user-facing change?:
No
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.