Skip to content

Add Nexus and database support for IPv6 NAT #8758

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

bnaecker
Copy link
Collaborator

@bnaecker bnaecker commented Aug 4, 2025

@bnaecker
Copy link
Collaborator Author

bnaecker commented Aug 4, 2025

Despite the pretty big diff, this is almost entirely non-functional changes. I've basically just renamed things from ipv4_nat_foo to nat_foo, and added support for IP addresses of either family. That includes the garbage-collector background task, database models, query methods, and the DB schema.

- Renames NAT tables in the database to be IP-family agnostic
- Renames NAT-enry-related types to be IP-family agnostic
- Adds a generic `IpNet` database model type
- Adds handling of IPv6 addresses for NAT entries, for both services and
  instances
- Fixes #5090. Fixes #8749.
@@ -100,7 +100,7 @@ bgp = []
# You can configure multiple uplinks by repeating the following stanza
[[rack_network_config.ports]]
# Routes associated with this port.
routes = [{nexthop = "192.168.1.199", destination = "0.0.0.0/0"}]
routes = [{nexthop = "192.168.1.1", destination = "0.0.0.0/0"}]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes here, and below in the other non-gimlet configs, seem unintentional, right?

Copy link
Contributor

@rcgoodfellow rcgoodfellow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @bnaecker. I like the approach of making the existing machinery dual stack rather than creating parallel IPv6 machinery.

}
}

impl ToSql<sql_types::Inet, Pg> for IpNet {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the oxnet types implemented these sql traits, perhaps behind a cargo feature, could we just use the oxnet types across the board and get rid of all these variations?

@@ -808,24 +774,21 @@ mod test {

// Test our ability to return all changes interleaved in the correct order
#[tokio::test]
async fn ipv4_nat_changeset() {
let logctx = dev::test_setup_log("test_nat_version_tracking");
async fn nat_changeset() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add IPv6 aspects to this test?

IpAddr::V6(_) => {
error!(
&log,
"ipv6 addresses for service zone nat not implemented";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

woot!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Need to track IPv6 NAT entries Implement NAT for IPv6
3 participants