IPAM: broadcast-addresses should not be assignable in pools inside containers

[n0emis]

Environment

• Python version: 3.6.9
• NetBox version: 2.10.5

Steps to Reproduce

1. Create a "Container"-Prefix
2. Create smaller "Active"-Prefixes inside the Container, mark it as a pool

Expected Behavior

The reserved Addresses (e.g. broadcast) of the Container-Prefix should not be assignable.

Observed Behavior

The limitations which IPs are assignable are not propagated to the child-pool. And broadcast-addresses can be assigned

Bonus points

When creating a IP instide such a pool the netmask should be set to the size of the next parent-prefix, which is not marked as a pool.

[DanSheps]

The reserved Addresses (e.g. broadcast) of the Container-Prefix should not be assignable.

This would be expected when using a pool. Any address inside of the pool is assignable. (To be clear, we currently do not validate network/broadcast address assignment in a normal pool either)

When creating a IP inside such a pool the netmask should be set to the size of the next parent-prefix, which is not marked as a pool.

We currently do not have a direct link between parent IP and prefix. If you create the IP from within the prefix by clicking on the address, the "### IPs available" button or the "Add an IP Address" button it will pre-fill the address for you. We do not validate against this though.

[DanSheps]

Thank you for opening a bug report. It seems that the described functionality is intended behavior. If you meant to open a feature request instead, please close this issue and open a new one using the feature request template. Otherwise, please revise your post above to elaborate on why you believe the observed behavior is flawed.

[n0emis]

This would be expected when using a pool. Any address inside of the pool is assignable. (To be clear, we currently do not validate network/broadcast address assignment in a normal pool either)

Hmm, I would see this as a bug, since a pool (like a range of addresses used e.g. for DHCP) should not include network/broadcast addresses, but this may be a just a different view i have...

Would you like me to close this issue and open a FR instead?

[DanSheps]

Hmm, I would see this as a bug, since a pool (like a range of addresses used e.g. for DHCP) should not include network/broadcast addresses, but this may be a just a different view i have...

I think the issue is there are two types of "pools". A DHCP pool is really a DHCP range within a subnet. The other pool is that of a pool of addresses that can be assigned to things like VPN endpoints, these you can normally assign the network and broadcast addresses of and might not have a concept of a broadcast/network address.

Would you like me to close this issue and open a FR instead?

It might be easier so we can gather the proper information.

[jeremystretch]

I don't follow. Permitting the use of the network (first) and broadcast (last) addresses in the prefix is the entire purpose of the "is pool" boolean. Per the documentation:

The prefix model include an "is pool" flag. If enabled, NetBox will treat this prefix as a range (such as a NAT pool) wherein every IP address is valid and assignable. This logic is used when identifying available IP addresses within a prefix. If this flag is disabled, NetBox will assume that the first and last (broadcast) address within an IPv4 prefix are unusable.

If you don't want these IPs to be assignable, don't set is_pool to true.

[n0emis]

The thing is: I want the network/broadcast-addresses of the pool to be assignable, but not the network/broadcast-addresses of the larger prefix. So if the ones from the pool overlap with those of the prefix they should not be assignable.

[jeremystretch]

What is your use case here? It sounds like you're trying to use this to carve out DHCP ranges, which (to be clear) is not its intended function. As Dan mentioned above, the is_pool boolean intends to convey that a prefix is not subject to the constraints of a broadcast domain (e.g. such as a prefix used for NAT translation). This must be true regardless of any parent prefixes defined.

[n0emis]

What is your use case here? It sounds like you're trying to use this to carve out DHCP ranges

Well, yes and no.

An example use case:

• 10.0.0.0/22 is the L2-Network
  • 10.0.0.0/23 is reserved for Network-Hardware
    • 10.0.0.0/25 is for Routing/Switching
    • 10.0.0.128/25 is for Wifi-APs
    • ....
  • 10.0.2.0/23 is used for DHCP

In this example I would mark 10.0.0.0/22 not as a pool, but everything else. And since the netmask in this Network is 255.255.252.0, 10.0.0.0 and 10.0.3.255 should not be assignable.

[jeremystretch]

Right, so 10.0.0.0/22 is the "lowest" child prefix: There are no prefixes within it. What you have inside it are arbitrary ranges, which look like prefixes because of how they're carved up but are all part of the same L2 domain. For example, 10.0.0.0/25 could just as easily be 10.0.0.100-200; its designation is arbitrary.

You might be interested in #834, which proposes implementing some mechanism for tracking such ranges, however it hasn't gotten much traction as no one has yet drafted a specific implementation.

[DanSheps]

The thing is: I want the network/broadcast-addresses of the pool to be assignable, but not the network/broadcast-addresses of the larger prefix. So if the ones from the pool overlap with those of the prefix they should not be assignable.

Unfortunately this makes no sense.

Lets use real numbers here.

Larger prefix: 192.168.0.0/24
Smaller prefix: 192.168.0.0/25

Both overlap on 192.168.0.0

However, if you want 192.168.0.0/25 to be assignable, by operation, 192.168.0.0/24 is assignable as that address is the same as 192.168.0.0/25 just with a different prefix mask in netbox. In the real world, you would not have 192.168.0.0/24 and 192.168.0.0/25, you would have 192.168.0.0/25 or 192.168.0.0/24.

It does indeed sound like you want IP ranges, and I would suggest trying to come up with a specific model for implementing ranges within the current netbox model.