You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When you resize a subnet, if the smaller subnet being resized up puts it off the bit boundary, PHPIPAM will accept it, and present a subnet that is impossible to actually have.
An example, 10.0.4.0/22 is a valid subnet, having 10.0.4.0 -> 10.0.7.255
If you want to resize that into a larger range (in this case 10.0.0.0/21) and you attempt to resize 10.0.4.0/22, it creates 10.0.4.0/21 but thinks it has 10.0.4.0 -> 10.0.11.255 rather than automatically becoming 10.0.0.0/21, becoming an illegal subnet that crosses the boundary.
The IP calculator is aware of bit boundary and knows what the network should be if you put the old network and new CIDR mask in and it should be easy enough to put a check to put the new sized subnet through to pull the new network for it, then use that for the subnet. This would however break downsizing back, but i think thats fair enough to ensure strict subnet adherance.
The text was updated successfully, but these errors were encountered:
When you resize a subnet, if the smaller subnet being resized up puts it off the bit boundary, PHPIPAM will accept it, and present a subnet that is impossible to actually have.
An example, 10.0.4.0/22 is a valid subnet, having 10.0.4.0 -> 10.0.7.255
If you want to resize that into a larger range (in this case 10.0.0.0/21) and you attempt to resize 10.0.4.0/22, it creates 10.0.4.0/21 but thinks it has 10.0.4.0 -> 10.0.11.255 rather than automatically becoming 10.0.0.0/21, becoming an illegal subnet that crosses the boundary.
The IP calculator is aware of bit boundary and knows what the network should be if you put the old network and new CIDR mask in and it should be easy enough to put a check to put the new sized subnet through to pull the new network for it, then use that for the subnet. This would however break downsizing back, but i think thats fair enough to ensure strict subnet adherance.
The text was updated successfully, but these errors were encountered: