feat: Name the parent network instead of seeding its selection #2

Merged
gsadmin merged 1 commits from development into main 2026-08-18 01:48:21 +00:00
Owner

The seed was repeatable in the strict sense and unusable in the practical one.
Reaching a wanted network meant brute forcing seeds until one happened to land
on the right index, and the seed did not even mean the same thing twice, because
the index was taken against the candidate list that remains after the host's own
networks are excluded. On the development host, which holds a network inside
10.0.0.0/8, one candidate is removed and every index above it shifts by one, so
the seed that selects 10.130.240.0/20 there selects the adjacent network on a
host with no network in that range.

The parent network is now named directly. Supplying it takes it verbatim, so it
means the same thing on every host and needs no calculation, and leaving it out
selects one at random and reports the exact argument that reproduces the
selection. Copying one line out of the summary is now the whole of making a
build repeatable.

The network count follows from the mask lengths rather than standing beside them
as a parameter that could disagree, so a /20 divided into /24 networks is sixteen
networks and a /21 is eight. NetworkCount is therefore gone, and the count is
changed by choosing a different parent mask length.

The base network is restricted to the three ranges RFC 1918 reserves. It only
bounds a random selection, so a parent network that was named explicitly is not
required to sit inside it, nor to avoid the networks this host is attached to.
Both are reported and then honoured, because substituting a different network for
one that was named deliberately would defeat the only reason to name it. An
unaligned value is aligned to its own mask length and the substitution reported.

Naming the supernet ParentNetwork collided with the existing use of that term for
the first of the divided networks, which is the one bound directly to the adapter
rather than to a tag. That one is now the untagged network, which is what
actually distinguishes it, and the VLAN sense of parent is left alone since the
parent interface of a tagged interface is standard terminology.

One defect found while testing rather than reasoned about: the two paths read the
subnet mask from different sources, and Get-NetworkSummary spells it Mask where
Get-Subnet spells it SubnetMask, so the host route command emitted an empty mask
on the explicit path until it was corrected.

Verified across both paths, four parent mask lengths, all three base networks,
unaligned input, an out of base network, an overlapping network, and the guard
against a network mask that is not longer than the parent mask. Two consecutive
explicit runs produce identical addressing across all 48 interface, VLAN and
scope entries; the documents themselves differ only in the UUIDs, which are
regenerated by design.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com

The seed was repeatable in the strict sense and unusable in the practical one. Reaching a wanted network meant brute forcing seeds until one happened to land on the right index, and the seed did not even mean the same thing twice, because the index was taken against the candidate list that remains after the host's own networks are excluded. On the development host, which holds a network inside 10.0.0.0/8, one candidate is removed and every index above it shifts by one, so the seed that selects 10.130.240.0/20 there selects the adjacent network on a host with no network in that range. The parent network is now named directly. Supplying it takes it verbatim, so it means the same thing on every host and needs no calculation, and leaving it out selects one at random and reports the exact argument that reproduces the selection. Copying one line out of the summary is now the whole of making a build repeatable. The network count follows from the mask lengths rather than standing beside them as a parameter that could disagree, so a /20 divided into /24 networks is sixteen networks and a /21 is eight. NetworkCount is therefore gone, and the count is changed by choosing a different parent mask length. The base network is restricted to the three ranges RFC 1918 reserves. It only bounds a random selection, so a parent network that was named explicitly is not required to sit inside it, nor to avoid the networks this host is attached to. Both are reported and then honoured, because substituting a different network for one that was named deliberately would defeat the only reason to name it. An unaligned value is aligned to its own mask length and the substitution reported. Naming the supernet ParentNetwork collided with the existing use of that term for the first of the divided networks, which is the one bound directly to the adapter rather than to a tag. That one is now the untagged network, which is what actually distinguishes it, and the VLAN sense of parent is left alone since the parent interface of a tagged interface is standard terminology. One defect found while testing rather than reasoned about: the two paths read the subnet mask from different sources, and Get-NetworkSummary spells it Mask where Get-Subnet spells it SubnetMask, so the host route command emitted an empty mask on the explicit path until it was corrected. Verified across both paths, four parent mask lengths, all three base networks, unaligned input, an out of base network, an overlapping network, and the guard against a network mask that is not longer than the parent mask. Two consecutive explicit runs produce identical addressing across all 48 interface, VLAN and scope entries; the documents themselves differ only in the UUIDs, which are regenerated by design. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gsadmin added 1 commit 2026-08-18 01:48:06 +00:00
The seed was repeatable in the strict sense and unusable in the practical one.
Reaching a wanted network meant brute forcing seeds until one happened to land
on the right index, and the seed did not even mean the same thing twice, because
the index was taken against the candidate list that remains after the host's own
networks are excluded. On the development host, which holds a network inside
10.0.0.0/8, one candidate is removed and every index above it shifts by one, so
the seed that selects 10.130.240.0/20 there selects the adjacent network on a
host with no network in that range.

The parent network is now named directly. Supplying it takes it verbatim, so it
means the same thing on every host and needs no calculation, and leaving it out
selects one at random and reports the exact argument that reproduces the
selection. Copying one line out of the summary is now the whole of making a
build repeatable.

The network count follows from the mask lengths rather than standing beside them
as a parameter that could disagree, so a /20 divided into /24 networks is sixteen
networks and a /21 is eight. NetworkCount is therefore gone, and the count is
changed by choosing a different parent mask length.

The base network is restricted to the three ranges RFC 1918 reserves. It only
bounds a random selection, so a parent network that was named explicitly is not
required to sit inside it, nor to avoid the networks this host is attached to.
Both are reported and then honoured, because substituting a different network for
one that was named deliberately would defeat the only reason to name it. An
unaligned value is aligned to its own mask length and the substitution reported.

Naming the supernet ParentNetwork collided with the existing use of that term for
the first of the divided networks, which is the one bound directly to the adapter
rather than to a tag. That one is now the untagged network, which is what
actually distinguishes it, and the VLAN sense of parent is left alone since the
parent interface of a tagged interface is standard terminology.

One defect found while testing rather than reasoned about: the two paths read the
subnet mask from different sources, and Get-NetworkSummary spells it Mask where
Get-Subnet spells it SubnetMask, so the host route command emitted an empty mask
on the explicit path until it was corrected.

Verified across both paths, four parent mask lengths, all three base networks,
unaligned input, an out of base network, an overlapping network, and the guard
against a network mask that is not longer than the parent mask. Two consecutive
explicit runs produce identical addressing across all 48 interface, VLAN and
scope entries; the documents themselves differ only in the UUIDs, which are
regenerated by design.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gsadmin merged commit 5478ec31eb into main 2026-08-18 01:48:21 +00:00
Sign in to join this conversation.
No Reviewers
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Grace-Solutions/Invoke-OPNSenseVMDeployment#2