Fix the CIDR range calculation in case of a custom CIDR block

[Skarlso]

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:

2022-03-04 18:21:39 [✖]  AWS::EC2::Subnet/PublicSubnetUSWEST2B: CREATE_FAILED – "Template error: Template error: invalid CIDR block size 23"

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.

        "CidrBlock": {
          "Fn::Select": [
            3,
            {
              "Fn::Cidr": [
                {
                  "Fn::GetAtt": [
                    "VPC",
                    "CidrBlock"
                  ]
                },
                8,
                23
              ]
            }
          ]
        },

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:

• Add some test coverage

Checklist

• Added tests that cover your change (if possible)
• Added/modified documentation as required (such as the README.md, or the userdocs directory)
• Manually tested
• Made sure the title of the PR is a good description that can go into the release notes
• (Core team) Added labels for change area (e.g. area/nodegroup) and kind (e.g. kind/improvement)

BONUS POINTS checklist: complete for good vibes and maybe prizes?! 🤯

• Backfilled missing tests for code in same general area 🎉
• Refactored something and made the world a better place 🌟

[Skarlso]

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.

cidrBits
The number of subnet bits for the CIDR. For example, specifying a value "8" for this parameter will create a CIDR with a >mask of "/24".

Note
Subnet bits is the inverse of subnet mask. To calculate the required host bits for a given subnet bits, subtract the subnet >bits from 32 for IPv4 or 128 for IPv6.

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 198.18.160.0/23. So this works. :)

[Skarlso]

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

[Skarlso]

With custom cidr ipv6:

2022-03-04 19:18:37 [ℹ]  no recommended policies found, proceeding without any IAM
2022-03-04 19:18:37 [ℹ]  creating addon
2022-03-04 19:18:38 [ℹ]  successfully created addon
2022-03-04 19:18:39 [ℹ]  kubectl command should work with "/Users/skarlso/.kube/config", try 'kubectl get nodes'
2022-03-04 19:18:39 [✔]  EKS cluster "invalid-ipv6-cidr-5" in "us-west-2" region is ready
➜  invalid_ipv6_cidr

Without custom cidr ipv6:

2022-03-04 19:41:01 [ℹ]  no recommended policies found, proceeding without any IAM
2022-03-04 19:41:01 [ℹ]  creating addon
2022-03-04 19:41:02 [ℹ]  successfully created addon
2022-03-04 19:41:03 [ℹ]  kubectl command should work with "/Users/skarlso/.kube/config", try 'kubectl get nodes'
2022-03-04 19:41:03 [✔]  EKS cluster "invalid-ipv6-cidr-6-nocustomcidr" in "us-west-2" region is ready
➜  invalid_ipv6_cidr

Since I only altered ipv6 path, I only launch a test cluster for ipv4 to see that the original path didn't break.

[nikimanoledaki]

This is great, well done! :)