newbits read as the target prefix
16 plus 24 is 40, so the plan fails and the error is about the extension rather than the argument
cidrsubnet("10.0.0.0/16", 24, 1) Resolve cidrsubnet, cidrhost and cidrnetmask to exact addresses, with the overlaps and the out-of-range arguments named before plan finds them.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Calculate. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
16 plus 24 is 40, so the plan fails and the error is about the extension rather than the argument
cidrsubnet("10.0.0.0/16", 24, 1)Two newbits gives four subnets, so netnum 4 does not exist
cidrsubnet("10.0.0.0/16", 2, 4)Different newbits off one prefix, so netnum means a different step in each
cidrsubnet("10.0.0.0/16", 8, 1)
cidrsubnet("10.0.0.0/16", 4, 0)These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
newbits is added to the prefix you gave. From a /16, newbits 24 asks for a /40 and the error is about the extension being too large rather than about the argument meaning.
Instead:Subtract: for a /24 out of a /16, newbits is 8.
netnum steps by a different size for each newbits value, so two calls that look unrelated produce overlapping ranges and the create fails.
Instead:Pick one newbits for the whole prefix and give each subnet a distinct netnum.
AWS reserves five addresses in every subnet regardless of size, so a /28 gives 11 usable rather than 16.
Instead:Subtract five when planning, and remember /28 is the smallest subnet AWS will create.
cidrsubnet(prefix, newbits, netnum). Almost every problem with this function comes from reading newbits as the target prefix length, and the resulting error does not say so.
Asking for a /24 out of a /16 means newbits 8, because 16 + 8 is 24. Writing newbits 24 asks for a /40, and Terraform errors about a prefix extension being too large, which is accurate and does not mention that the argument means something else.
newbits 8 gives 256 subnets, numbered 0 to 255. This fails when a list of availability zones or a count grows past what the newbits allow, so a configuration that worked for months breaks when somebody adds a region, and the error is about the netnum rather than about the list.
cidrsubnet(prefix, 8, 1) and cidrsubnet(prefix, 4, 0) both come off the same /16 and both cover 10.0.1.0. Because netnum means a differently sized step for each, two calls that look independent collide, and AWS rejects the second subnet at create time.
The network address, the VPC router, the DNS server, one reserved for future use, and the broadcast address. So a /24 has 251 usable, not 254, and a /28, which is the smallest AWS accepts, has 11. Capacity planning that assumes the RFC numbers comes out short.
10.0.5.0/16 is treated as 10.0.0.0/16, so the calculation is correct on a network that is not the one written down. Nothing errors, and the subnets come out where the /16 says rather than where the typed address suggests.
cidrhost("10.0.1.0/24", 5) is 10.0.1.5. Minus one is 10.0.1.255, which is how the broadcast address gets written. Either way it is bounded by the size of the prefix and errors rather than wrapping.