-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
IP ranges not visible within prefix, and not reserving IPs within the range #6934
Comments
This was not a design goal for v3.0. Per my comment on #834:
and
We should have a "ranges" tab under the prefix view, though. |
And what about prefix utilisation? ISTM that the "IPAddress" view is automatically calculating ranges - of the gaps between IP addresses (e.g. "253 IPs available" in this example). Therefore I think it would make sense to merge in the explcit "Range" objects in this view, although it's slightly complicated in that a range may also overlap with IPAddress objects (they could be indented under the "parent" range). This merge would, as a side-effect, ensure that the auto-generated ranges of 'free' addresses are correct. i.e. what I really wanted to see was "243 IPs available", and clicking on this would give me 1.1.1.11/24 But this can wait for a later iteration. |
It depends on what you try to administer with an IPrange imo. If the range is supposed to signal a delegation ('dhcp controls this range') it makes sense to mark it as utilized from a parent prefix point of view. If on the other hand an IPrange is used to dictate some sort of standardized subnet arrangement ('use this range for switch management IPs, this other range for routers') it is very natural to allow assignment within the range. Like: get-next-available-ip from a prefix, but must be within the allocation/range dedicated to 'end-user-pcs'. Do we need a 'mark-utilized' or 'assignent-delegated' flag (or logic) on the IPrange model to suit both use cases? |
I'm happy to allow assignment within a range, if you explictly choose to do so (e.g. by clicking on the range), although having a flag to disable this would be good - then you'd have to explicitly create an IP address by hand, to overlap the range. At the moment, I see the main problem is that the ranges are completely invisible in this view, and clicking on a "253 IPs available" (i.e. the range of "unused" IPs) is allocating an IP that can overlap ranges which may exist. Ideally what I'd expect to see is:
|
I believe I've addressed all of the items noted above. If there's anything anyone would like to revisit, please open a new issue for each individual proposed change. |
NetBox version
v3.0-feature (on beta-demo.netbox.dev)
Python version
3.8
Steps to Reproduce
/ipam/prefixes/<N>/ip-addresses/
)Expected Behavior
Observed Behavior
The IP address 1.1.1.1/24 is shown, and "253 IPs available".
Clicking on "253 IPs available" allocates 1.1.1.2/24 - clashing with the range
Browsing to the prefix shows utilisation as 0%
(Aside: browsing to the main IP addresses listing
/ipam/ip-addresses/
also does not show ranges mixed in, and I think it might be good if it did, but that's less important than when looking at IPs under a prefix)The text was updated successfully, but these errors were encountered: