-
Notifications
You must be signed in to change notification settings - Fork 35
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
Modify Subnet /31 or /32 #127
Comments
Just encountered this issue. Was able to create a subnet but when adding a host to the last IP in the range it complains about the broadcast IP address. I have a similar issue with a /29 ranged assigned to loopback addresses on a firewall. I could record them as /32 addresses but would prefer not to. |
I would say that on any subnet larger than a /29 you would not want to be putting any hosts at the broadcast address, thus those rules were put in place. That poor host living on the broadcast address would get a bunch of junk packets hitting it that it would never do anything with. The exception was always /31 and /32 as by definition they do not use the same gateway/broadcast paradigm. The design here is intended to be that /31 and /32 bypass the last IP address check, but everything else retains it. If there are errors adding/modifying subnets or interfaces with those small masks then that needs to be fixed. More discussion about the merits of the last IP address limitation are welcome. This is just the design things have currently been following. |
Yes I was able to create the /31 host IP address (added an interface to an existing host) but when I want to edit the entry I still get a warning that broadcast hosts can't be used. So I think there's still a few corner scenarios where the block on using the second address in a /31 is not allowed. As for using a /28 as loopback addresses, they're essentially used as routed /32 addresses, so can be recorded as such. It's just extra work, but rare in use. |
Wont work if there are interfaces in those nets.
Will probably need a similary fix as #84
The text was updated successfully, but these errors were encountered: