Add support for dual-stack external addressing#9470
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.
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.
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.
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.
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.
Thanks Ben, I think I'm happy with where things are at right now!