Support dual-stack NICs in the public API#9508
Merged
Conversation
bnaecker
force-pushed
the
external-api-for-dual-stack-instances
branch
8 times, most recently
from
cd0803a to
b276b93
Compare
Collaborator
Author
|
I'm working on the NIC-update APIs, but need to get #9542 to make that work. That'll let us update a NIC's transit IPs on a per-stack basis, rather than some RMW with the DB. |
bnaecker
force-pushed
the
external-api-for-dual-stack-instances
branch
from
b276b93 to
bc3f12c
Compare
bnaecker
force-pushed
the
external-api-for-dual-stack-instances
branch
3 times, most recently
from
2df5da9 to
a54fdb0
Compare
- Move IP traits and config types to common modules so they can be used in the public API - Add private IP stack types to external API, used when fetching NICs - Add new `IpConfig` type to the parameters for creating NICs. This gives a more flexible scheme for selecting an IP address automatically or explicitly, and independently for each IP stack. - Add a new version of the external API for the new types, and implement conversions from the previous - Ensure external IPs are allocated for NICs with a corresponding private IP stack, checking at both IP creation and attachment. - Check that candidate secondary NICs have an IP stack for every external IP when setting them to a new primary
bnaecker
force-pushed
the
external-api-for-dual-stack-instances
branch
from
a54fdb0 to
342aee5
Compare
Collaborator
Author
|
There are a few tests that will fail until I rebase on @zeeshanlakhani's changes in #9452 once that merges. This is ready for a review now though. |
bnaecker
requested review from
FelixMcFelix,
rcgoodfellow and
zeeshanlakhani
Collaborator
Author
Contributor
rcgoodfellow
left a comment
rcgoodfellow
left a comment
There was a problem hiding this comment.
Thanks for pulling all this together @bnaecker! Lots of details to line up and some hairy database work.
I've been rebasing my ipv6/all-the-things onto this branch and things are working e2e for IPv6 comms with probes.
A few minor comments/questions follow.
Collaborator
Author
|
Alright, I've integrated this with the updated handling of default pools, and have now gotten all the tests to pass and my own TODOs addressed. @rcgoodfellow thanks for your feedback, I'd love another pass when you get a minute. |
Collaborator
Author
|
Still need to resolve another conflict with main. |
rcgoodfellow
approved these changes
Jan 3, 2026
Contributor
rcgoodfellow
left a comment
rcgoodfellow
left a comment
There was a problem hiding this comment.
LGTM. All my comments have been addressed.
Collaborator
Author
|
The multicast failure looks like a flake. There's a timeout we're exceeding, but it passes locally quite quickly. I'll fixup the API check test now. |
internet-diglett
added a commit
that referenced
this pull request
Feb 14, 2026
This PR pulls in various IPv6 work. The biggest code changes revolve around integrating new Maghemite APIs around IPv6 peers and unnumbered peers. This has meant changing data structures in the rack initialize API. Before this PR, the rack initialize API was in the client-side versioned bootstrap API. This makes it impossible to change. However, it was observed that the only client of the rack initialize API is wicketd, essentially making the three API endpoints under `rack-initailize` lockstep. With that in mind, the rack initialize endpoints have been factored out as a lockstep API, and a new version of the bootstrap client side API has been created that deprecates use of rack-initialize. Another tricky aspect of changing these data structures is that they are in the boot store. In particular we are changing the BGP peer member from an `Ipv4Addr` to an `IpAddr`. This `should` be a bootstore backwards compatible change, but testing is required to ensure it is. Remaining work items: - [x] External API updates for IPv6 BGP peers - [x] External API updates for unnumbered BPG peers - [x] Wicket updates for IPv6 BGP peers - [x] Wicket updates for unnumbered BGP peers Functional milestones: - [x] Passing CI - [x] Bring up a4x2 with BGP unnumbered peering confirming - [x] session establishment - [x] ipv4 prefix exchange - [x] ipv6 prefix exchange - [x] working ipv4 probes - [x] working ipv6 probes - [x] Bring in asilomar racklette environment - [x] session establishment - [x] ipv4 prefix exchange - [x] ipv6 prefix exchange - [x] working ipv4 instance comms - [x] working ipv6 instance comms Depends on - oxidecomputer/opte#902 - oxidecomputer/opte#905 - oxidecomputer/dendrite#175 - oxidecomputer/maghemite#585 - #9508 - oxidecomputer/maghemite#584 - oxidecomputer/maghemite#598 - oxidecomputer/dendrite#216 --------- Co-authored-by: Levon Tarver <levon@oxide.computer> Co-authored-by: John Gallagher <john@oxidecomputer.com>
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
2 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.
IpConfigtype to the parameters for creating NICs. This gives a more flexible scheme for selecting an IP address automatically or explicitly, and independently for each IP stack.