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

When adding an IP address inside a prefix, the netmask must be forced to be the same as the prefix #2411

New Issue
Closed
opened 2025-12-29 17:25:50 +01:00 by adam · 7 comments
adam commented 2025-12-29 17:25:50 +01:00
Owner
Copy Link

Originally created by @Keyhaku on GitHub (Feb 25, 2019).

Environment

  • Python version: 3.6.8
  • NetBox version: 2.5.7

Steps to Reproduce

  1. Create a Prefix with a /27 netmask
  2. From this prefix, click "Add an IP Address"
  3. Change the netmask of the IP automatically provided to /2 or to /29 (any other netmask size in reality)

Expected Behavior

The interface (and the API I guess) should not allowed this IP since the netmask does not belong to this subnet.

Observed Behavior

The IP is allocated inside the subnet, but the netmask associated is wrong

Originally created by @Keyhaku on GitHub (Feb 25, 2019). <!-- NOTE: This form is only for reproducible bugs. If you need assistance with NetBox installation, or if you have a general question, DO NOT open an issue. Instead, post to our mailing list: https://groups.google.com/forum/#!forum/netbox-discuss 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. --> ### Environment * Python version: 3.6.8 * NetBox version: 2.5.7 <!-- Describe in detail the exact steps that someone else can take to reproduce this bug using the current stable release of NetBox (or the current beta release where applicable). 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 wrapper like pynetbox. --> ### Steps to Reproduce 1. Create a Prefix with a /27 netmask 2. From this prefix, click "Add an IP Address" 3. Change the netmask of the IP automatically provided to /2 or to /29 (any other netmask size in reality) <!-- What did you expect to happen? --> ### Expected Behavior The interface (and the API I guess) should not allowed this IP since the netmask does not belong to this subnet. <!-- What happened instead? --> ### Observed Behavior The IP is allocated inside the subnet, but the netmask associated is wrong
adam closed this issue 2025-12-29 17:25:50 +01:00
adam commented 2025-12-29 17:25:51 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Feb 25, 2019):

I can confirm this is the behaviour.

This isn't so much an adding the prefix bug as it is a display bug. It should not show that prefix as a parent, but it should allow the creation as IP addresses are not tied specifically to a prefix.

@DanSheps commented on GitHub (Feb 25, 2019): I can confirm this is the behaviour. This isn't so much an adding the prefix bug as it is a display bug. It should not show that prefix as a parent, but it should allow the creation as IP addresses are not tied specifically to a prefix.
adam commented 2025-12-29 17:25:51 +01:00
Author
Owner
Copy Link

@Keyhaku commented on GitHub (Feb 25, 2019):

I'm not sure I understand why this is a display bug,

On the interface I'm on the subnet tab (IPAM -> Prefixes -> <PREFIX>), If i add an IP, it should be forced to be in this subnet.
The expected behaviour is very different than if I was on the IP Address Tab that allow me to create an IP address within any subnet.

@Keyhaku commented on GitHub (Feb 25, 2019): I'm not sure I understand why this is a display bug, On the interface I'm on the subnet tab (`IPAM -> Prefixes -> <PREFIX>`), If i add an IP, it should be forced to be in this subnet. The expected behaviour is very different than if I was on the IP Address Tab that allow me to create an IP address within any subnet.
adam commented 2025-12-29 17:25:51 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Feb 25, 2019):

On the interface I'm on the subnet tab (IPAM -> Prefixes -> <PREFIX>), If i add an IP, it should be forced to be in this subnet.

The expected behaviour is very different than if I was on the IP Address Tab that allow me to create an IP address within any subnet.

There is no direct relationship between Prefixes and IP Addresses. It was never intended to force you into that (much like if you add a device in a Rack, it will default to the rack position you select but it won't FORCE you to keep that, you could move it into a completely diffferent site).

@DanSheps commented on GitHub (Feb 25, 2019): > On the interface I'm on the subnet tab (`IPAM -> Prefixes -> <PREFIX>`), If i add an IP, it should be forced to be in this subnet. > > The expected behaviour is very different than if I was on the IP Address Tab that allow me to create an IP address within any subnet. There is no direct relationship between Prefixes and IP Addresses. It was never intended to force you into that (much like if you add a device in a Rack, it will default to the rack position you select but it won't FORCE you to keep that, you could move it into a completely diffferent site).
adam commented 2025-12-29 17:25:51 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Feb 25, 2019):

Question for the community: Is this something we want to fix, or should it be left and then handled with a user generated custom report to show mis-matched prefixes?

@DanSheps commented on GitHub (Feb 25, 2019): Question for the community: Is this something we want to fix, or should it be left and then handled with a user generated custom report to show mis-matched prefixes?
adam commented 2025-12-29 17:25:51 +01:00
Author
Owner
Copy Link

@ktims commented on GitHub (Feb 25, 2019):

I would prefer this be left as is, with the subnet of the IP address representing the device's interface configuration, and the prefix itself merely representing an allocated block. Any IPs within the prefix, regardless of netmask, should be children of that prefix. Not showing them as children, despite them being allocated, would lead to accidental duplicate allocations and is at best confusing.

Not all prefixes are LAN segments, for example NAT pools, loopback address blocks, etc, where the interface will be configured as /32 despite being part of an allocated prefix.

@ktims commented on GitHub (Feb 25, 2019): I would prefer this be left as is, with the subnet of the IP address representing the device's interface configuration, and the prefix itself merely representing an allocated block. Any IPs within the prefix, regardless of netmask, should be children of that prefix. Not showing them as children, despite them being allocated, would lead to accidental duplicate allocations and is at best confusing. Not all prefixes are LAN segments, for example NAT pools, loopback address blocks, etc, where the interface will be configured as /32 despite being part of an allocated prefix.
adam commented 2025-12-29 17:25:51 +01:00
Author
Owner
Copy Link

@kdadev commented on GitHub (Mar 20, 2019):

When doing network resegmentation it was better for us to expand network mask and next to edit hosts addresses instead of getting message about hosts-network prefixes incompatibility.

Also we have subnets designated for loopback interfaces. This subnet marked as /26 prefix, but each address in this subnet has /32 prefix length. So me and my colleagues don't want to change this behavior.

Maybe it's resonable to add additional flag in subnet property for point whether to check network-host prefix compatibility. But this is uneccessary by my opinion.

@kdadev commented on GitHub (Mar 20, 2019): When doing network resegmentation it was better for us to expand network mask and next to edit hosts addresses instead of getting message about hosts-network prefixes incompatibility. Also we have subnets designated for loopback interfaces. This subnet marked as /26 prefix, but each address in this subnet has /32 prefix length. So me and my colleagues don't want to change this behavior. Maybe it's resonable to add additional flag in subnet property for point whether to check network-host prefix compatibility. But this is uneccessary by my opinion.
adam commented 2025-12-29 17:25:51 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Mar 20, 2019):

It seems there isn't much desire for this to change. Closing it out.

@DanSheps commented on GitHub (Mar 20, 2019): It seems there isn't much desire for this to change. Closing it out.
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#2411
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?