Skip to content
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

The first and last IP within a prefix are assumed to be unusable #658

Closed
NetTinkerer opened this issue Oct 31, 2016 · 2 comments
Closed
Labels
type: bug A confirmed report of unexpected behavior in the application

Comments

@NetTinkerer
Copy link

when a /27 prefix is created only 30 free IPs are mentionned. Although this is valid for Ethernet segments it is confusing when the prefix is used as a pool for nat addresses or aggregating loopbacks. It might be usefull to add a flag to a prefix if it is an ethernet segement or just a container for something else

@jeremystretch jeremystretch added type: feature Introduction of new functionality to the application type: bug A confirmed report of unexpected behavior in the application and removed type: feature Introduction of new functionality to the application labels Oct 31, 2016
@jeremystretch
Copy link
Member

It's pretty easy to modify this behavior, but we need to figure out how to indicate whether the network/broadcast IPs should be counted. It might make sense to add a new prefix type called "pool" and count otherwise unusable IPs for prefixes of this type. It might also make sense to count them for container prefixes.

@footplus
Copy link

footplus commented Nov 3, 2016

FWIW, RackTables work around this by using "reserved" addresses, that a checkbox permits to allocate easily while creating the prefix. That way, every prefix is useable as a pool or not.

@jeremystretch jeremystretch changed the title Not every prefix is used on ethernet The first and last IP within a prefix are assumed to be unusable Nov 14, 2016
lampwins pushed a commit to lampwins/netbox that referenced this issue Oct 13, 2017
@lock lock bot locked as resolved and limited conversation to collaborators Jan 19, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type: bug A confirmed report of unexpected behavior in the application
Projects
None yet
Development

No branches or pull requests

3 participants