Skip to content
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

feat: sort subnets to calculate by their netmask to efficiently use ip space + feature flag and tests #165

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

ivan-aws
Copy link

Expanding the work that Bill Beesley has done earlier by adding a feature flag that sets the old behavior as default + examples and tests.

please see the original MR for details.

bbeesley and others added 2 commits August 9, 2023 13:02
…p space

The previous implementation calculates the ipv4 subnet cidr ranges in an arbitrary order (actually
alphabetically based on the subnet type string). This means that if you have different netmasks for
different subnets you end up trying to take your vpc cidr range, then cut out some small netmasks,
then encounter a large netmask, at which point you have to skip a bunch of ips in order to get to
the next start address for that larger netmask. In practice this causes really inefficient use of ip
space. For example, with a vpc netmask of 22, 3 db subnets with a netmask of 27, 3 public subnets
with a netmask of 28, 3 private subnets with a netmask of 24, and 3 transit gateway subnets with a
netmask of 28, then the module is unable to calculate the cidr ranges, because first it creates the
db subnets with their 27 netmask, then the public with their 28 netmask, then it gets to the private
ones and has to skip a huge chunk to get to the start of a `/24` block. At this point it has skipped
so many that its unable to create the remaining subnets. The fix for this is to first calculate the
subnets where netmask is 24, then the ones where it is 27, then the ones where it is 28. If you do
this, then the subnet calculator is then able to create all the required subnets, as its no longer
skipping large chunks due to starting with small netmasks.

BREAKING CHANGE: Since the subnets calculated after sorting wont be the same as those calculated
without sorting, this change would cause a delete and recreate of existing subnets that were created
with older versions.
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.

2 participants