feat: Name the parent network instead of seeding its selection #2
Reference in New Issue
Block a user
Delete Branch "development"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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