-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Fix the CIDR range calculation in case of a custom CIDR block #4904
Conversation
Oh dang, I think I figured it out... I can't read, again... :D They are already subtracting the bit from 32. We don't have to do that. We specify the number they calculate a cidr bit from it.
THE NOTE IS MISLEADING! It makes you think that you have to subtract it from 32. BUT YOU DON'T! refSubnetSlices := gfnt.MakeFnCIDR(gfnt.MakeFnGetAttString("VPC", "CidrBlock"), gfnt.NewInteger(cidrPartitions), gfnt.NewInteger(32-desiredMask)) This was wrong. Should be. refSubnetSlices := gfnt.MakeFnCIDR(gfnt.MakeFnGetAttString("VPC", "CidrBlock"), gfnt.NewInteger(cidrPartitions), gfnt.NewInteger(desiredMask)) Created a subnet with block |
Works for the original path now as well. Creates the correct range subnet IP: subnet-0f99d72c80225f9ef | Available | vpc-0151de9fef3f12b30 | eksctl-invalid-ipv6-cidr-6-nocustomcidr-cluster/VPC | 192.168.32.0/19 |
With custom cidr ipv6:
Without custom cidr ipv6:
Since I only altered ipv6 path, I only launch a test cluster for ipv4 to see that the original path didn't break. |
580a752
to
50ffe71
Compare
50ffe71
to
0c46acc
Compare
0c46acc
to
1ca13a2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great, well done! :)
Description
Closes #4838
TODO
This is still failing even though I'm calculating the CIDR size correctly. Maybe I'm not taking into account that AWS also reserves some ips...
I'm calculating 23 correctly and yet:
Our IPV4 calculations with the same custom cidr also calculate 23 as cidr and that works. I suspect we mess something up with the CF template maybe?
Will have to take a look at that.
As an exercise.... Our hardcoded values add up as well.
/16
bit -> 65535 -> /8 -> 8192 -> log2(8192) -> 13. And indeed that is a working cidr block size. So why is 23 not a valid block size? 🤔DONE!
TODO:
Checklist
README.md
, or theuserdocs
directory)area/nodegroup
) and kind (e.g.kind/improvement
)BONUS POINTS checklist: complete for good vibes and maybe prizes?! 🤯