starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

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

New Issue
Closed
opened 2025-12-29 18:38:29 +01:00 by adam · 10 comments
adam commented 2025-12-29 18:38:29 +01:00
Owner
Copy Link

Originally created by @n0emis on GitHub (Mar 8, 2021).

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.

Originally created by @n0emis on GitHub (Mar 8, 2021). <!-- NOTE: IF YOUR ISSUE DOES NOT FOLLOW THIS TEMPLATE, IT WILL BE CLOSED. This form is only for reporting reproducible bugs. If you need assistance with NetBox installation, or if you have a general question, please start a discussion instead: https://github.com/netbox-community/netbox/discussions Please describe the environment in which you are running NetBox. Be sure that you are running an unmodified instance of the latest stable release before submitting a bug report, and that any plugins have been disabled. --> ### Environment * Python version: 3.6.9 * NetBox version: 2.10.5 <!-- Describe in detail the exact steps that someone else can take to reproduce this bug using the current stable release of NetBox. Begin with the creation of any necessary database objects and call out every operation being performed explicitly. If reporting a bug in the REST API, be sure to reconstruct the raw HTTP request(s) being made: Don't rely on a client library such as pynetbox. --> ### Steps to Reproduce 1. Create a "Container"-Prefix 2. Create smaller "Active"-Prefixes inside the Container, mark it as a pool <!-- What did you expect to happen? --> ### Expected Behavior The reserved Addresses (e.g. broadcast) of the Container-Prefix should not be assignable. <!-- What happened instead? --> ### 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.
adam closed this issue 2025-12-29 18:38:29 +01:00
adam commented 2025-12-29 19:18:54 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Mar 11, 2021):

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 commented on GitHub (Mar 11, 2021): > 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.
adam commented 2025-12-29 19:18:54 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Mar 11, 2021):

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.

@DanSheps commented on GitHub (Mar 11, 2021): 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](https://github.com/netbox-community/netbox/issues/new?template=feature_request.md). Otherwise, please revise your post above to elaborate on why you believe the observed behavior is flawed.
adam commented 2025-12-29 19:18:54 +01:00
Author
Owner
Copy Link

@n0emis commented on GitHub (Mar 13, 2021):

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?

@n0emis commented on GitHub (Mar 13, 2021): > 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?
adam commented 2025-12-29 19:18:54 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Mar 15, 2021):

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.

@DanSheps commented on GitHub (Mar 15, 2021): > 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.
adam commented 2025-12-29 19:18:54 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 15, 2021):

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.

@jeremystretch commented on GitHub (Mar 15, 2021): 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.
adam commented 2025-12-29 19:18:54 +01:00
Author
Owner
Copy Link

@n0emis commented on GitHub (Mar 15, 2021):

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.

@n0emis commented on GitHub (Mar 15, 2021): 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.
adam commented 2025-12-29 19:18:54 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 15, 2021):

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.

@jeremystretch commented on GitHub (Mar 15, 2021): 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.
adam commented 2025-12-29 19:18:54 +01:00
Author
Owner
Copy Link

@n0emis commented on GitHub (Mar 15, 2021):

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.

@n0emis commented on GitHub (Mar 15, 2021): > 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.
adam commented 2025-12-29 19:18:54 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 15, 2021):

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.

@jeremystretch commented on GitHub (Mar 15, 2021): 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.
adam commented 2025-12-29 19:18:55 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Mar 16, 2021):

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.

@DanSheps commented on GitHub (Mar 16, 2021): > 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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#4631
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?