The tag was the third octet of the network address. That reads well while every
network happens to occupy a whole octet, and stops being possible the moment one
does not, because two networks that share an octet are assigned the same tag. It
had already forced a cap on the subnet mask length one commit earlier, since a
/25 produced thirty two networks carrying only sixteen distinct tags.
The tag is now counted. StartingVlanId gives the first tagged network its tag and
defaults to 2, and VlanIdIncrement advances it for each network after that and
defaults to 1, so a sixteen network deployment carries the tags 2 through 16. The
default leaves the tag of 1 unused, because a switch commonly treats it as its
own default network and colliding with that is awkward to diagnose.
Counting removes the constraint at its source rather than fencing it off. The tag
no longer has anything to do with the address, so it stays unique however the
parent network was divided, and the cap on the subnet mask length is lifted back
to a /30. The same /25 and /26 that collided now produce thirty one and sixty
three distinct tags.
The highest tag is computed before the loop runs, so a range that would pass 4094
throws and names the range it would have produced rather than emitting invalid
tags. A run starting at 4080 across fifteen networks is accepted and ends exactly
at 4094.
The increment also makes tag ranges expressible, which a derived tag could never
have offered. An increment of ten gives 2, 12, 22 and so on, which is useful when
a tag is meant to carry meaning of its own.
What is given up is that a tag no longer tells you the address. That was a real
convenience, but it was only ever available while the addressing cooperated, and
paying for it with a cap on how the parent network could be divided was the worse
side of the trade.
The screenshot walkthrough is annotated rather than restaged. Those frames are a
real run captured while the tag was still derived, so the caption now says so and
gives the names the same deployment would produce today.
Verified end to end with the defaults, which produced the tags 2 through 16 with
matching interface descriptions and vlan devices, and with a /22 parent divided
into /26 networks at an increment of ten, which is a combination the previous
scheme could not express at all and which produced fifteen distinct tags from 2
to 142. Both exited 0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The size of each individual network was fixed at a /24 by a parameter the plan
function held privately and the main script never surfaced, so the only way to
change how the parent network was divided was to edit the function. It is now
ParentNetworkSubnetMaskLength on both, defaulting to 24, which pairs it with
ParentNetworkMaskLength and makes the relationship between the two legible: one
says how large the whole range is, the other says how large each network inside
it is, and the count is what falls out.
It applies on both paths. It describes how the parent network is divided rather
than how the parent network is chosen, so the mask length that an explicitly
supplied parent network carries has no bearing on it. Only
ParentNetworkMaskLength is bypassed when a parent network is named, and the
distinction is now stated in the help of both parameters rather than left to be
inferred.
Testing it across a range of values surfaced a constraint that had not been
considered. The virtual local area network tag is the third octet of the network
address, so a network has to occupy a whole third octet to own a tag. A network
shorter than a /24 spans several and takes the first, which stays unique, but a
network longer than a /24 occupies only part of one, so several networks share a
third octet and are assigned the same tag. Measured against a /20 parent, a /25
produced thirty two networks carrying only sixteen distinct tags, and a /26
produced sixty four carrying sixteen.
Duplicate tags on one parent interface are not a valid virtual local area
network configuration, so the range is capped at /24 rather than allowed to emit
a document the appliance would refuse. Supporting smaller networks would mean
decoupling the tag from the address, which is the property that makes the
addressing readable, so the cap is the right side of that trade rather than a
limitation to be worked around later.
Verified with mask lengths from /22 through /26 against both a specified and a
randomly selected parent network, confirming that the tags stay distinct at every
accepted value, that both rejected values are refused by the range rather than by
producing a broken plan, and that the existing guard against a subnet mask no
longer than the parent mask still fires. An end to end run with a /20 parent
divided by /22 produced four networks with tags 244, 248 and 252 and exited 0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gsadmin