-
Notifications
You must be signed in to change notification settings - Fork 63
Add support for dual-stack external addressing #9470
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
bnaecker
commented
Dec 4, 2025
- Adds enum for tracking the external IP addresses for an instance or service, which includes the three fields that were previously separate: SNAT, ephemeral, and list of floating addresses.
- Makes the previous source NAT config type IP address specific, with a "generic" variant for services. This is a bit lazy, but we can lift the IP version out of the contained IP address and into the source NAT type itself in the future if we need to.
- Add new version of the sled-agent API with these new types, plus conversions with the previous version
- Completely handle dual-stack OPTE ports, closes Enable dual-stack OPTE ports in the sled-agent #9247
- Closes Guest external IP configuration needs to be dual-stack #9318
078e09b to
0000088
Compare
| let mut seen_snat_ip = false; | ||
| let mut seen_ephemeral_ip = false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be better to put this kind of validation into the builder, e.g., add checked methods that fail if the caller tries to overwrite existing values.
- Adds enum for tracking the external IP addresses for an instance or service, which includes the three fields that were previously separate: SNAT, ephemeral, and list of floating addresses. - Makes the previous source NAT config type IP address specific, with a "generic" variant for services. This is a bit lazy, but we can lift the IP version out of the contained IP address and into the source NAT type itself in the future if we need to. - Add new version of the sled-agent API with these new types, plus conversions with the previous version - Completely handle dual-stack OPTE ports, closes #9247 - Closes #9318
0000088 to
4774e7f
Compare
FelixMcFelix
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Ben, this generally looks good to me. I'm less certain around any type changes relating to inventory etc., since that's not quite my wheelhouse.
| source_nat: Option<SourceNatConfig>, | ||
| ephemeral_ip: Option<IpAddr>, | ||
| floating_ips: &[IpAddr], | ||
| external_ips: &ExternalIpConfig, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a today-problem (since SNAT bindings are non-negotiable), but the lack of optionality here is leaving me wondering about future cases where we could remove all external IPs from a port if desired (particularly since ExternalIps<Ip> requires at least one non-empty field). I've opened oxidecomputer/opte#897 so I don't lose track of the issue on the driver side.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. I'm assuming that it's possible to have an all-private OPTE port, but I can't remember the last time we tried that. Is there any action you'd like to see here? It might be enough to link that OPTE issue, and possibly #9003?
- Use `itertools` to more succinctly partition IPv4/IPv6 addresses - Clean up note around Ephemeral probe addresses
Try to clean up the possible options for private / external IP configuriation when creating an OPTE port
|
CI hit what appears to be a transient error downloading the Rust toolchain here. I don't see any existing issues about this specifically, but I'm going to re-run the job. |
FelixMcFelix
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Ben, I think I'm happy with where things are at right now!