IP ranges not visible within prefix, and not reserving IPs within the range

[candlerb]

NetBox version

v3.0-feature (on beta-demo.netbox.dev)

Python version

3.8

Steps to Reproduce

1. Create IP address 1.1.1.1/24
2. Create IP range 1.1.1.2/24-1.1.1.10/24
3. Create prefix 1.1.1.0/24
4. Navigate to the prefix
5. Select the "IP addresses" tab (/ipam/prefixes/<N>/ip-addresses/)

Expected Behavior

• Under the prefix, I was expecting to see both the IP and the range.
• I was also expecting by default that allocating a new IP would not pick one within the existing range (e.g. this might be a DHCP pool)
• I was expecting to see the prefix utilisation as 10/254 = 3.94% (showing as 3% or 4%)

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)

[jeremystretch]

Under the prefix, I was expecting to see both the IP and the range.

This was not a design goal for v3.0. Per my comment on #834:

Something I've been stuck on for a long time is how to integrate IP ranges with individual addresses e.g. in a prefix's child IPs list. But maybe I'm overthinking it. Just having the IP range model in place, even without any especially convenient integration with individual IPs, is pretty valuable.

and

If we accept the introduction of IPRange as a new model separate from the Prefix and IPAddress models, with its own parallel views and API endpoints, this becomes very straightforward to implement, and I'd be open to tackling it for v3.0.

We should have a "ranges" tab under the prefix view, though.

[candlerb]

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.

[sdktr]

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?

[candlerb]

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:

• 1.1.1.1
• 1.1.1.2-1.1.1.10 (i.e. range)
• 243 IPs available # i.e. unused 1.1.1.11 - 1.1.1.254

[jeremystretch]

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.