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 new IP addresses with Mask - also add prefix #65

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

Originally created by @troxil on GitHub (Jun 29, 2016).

When adding a new IP address to a device or mask - add the same prefix the mask represents.

Given that this inclusive of a VRF - I suspect that maybe a default unassigned VRF first?

Originally created by @troxil on GitHub (Jun 29, 2016). When adding a new IP address to a device or mask - add the same prefix the mask represents. Given that this inclusive of a VRF - I suspect that maybe a default unassigned VRF first?
adam closed this issue 2025-12-29 15:31:16 +01:00
adam commented 2025-12-29 15:31:17 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 29, 2016):

Not sure I like the idea of automatically creating a prefix to house an IP address. There may be cases where a user needs to track individual IPs but not necessarily their parent prefixes.

@jeremystretch commented on GitHub (Jun 29, 2016): Not sure I like the idea of automatically creating a prefix to house an IP address. There may be cases where a user needs to track individual IPs but not necessarily their parent prefixes.
adam commented 2025-12-29 15:31:17 +01:00
Author
Owner
Copy Link

@afenioux commented on GitHub (Jul 8, 2016):

Not really the same question, but it's related:
Why is there a netmask in the IP object?

The IP by itself has no netmask, but need to be linked to a prefix (which has a netmask).
Having the netmask in both IP and Prefix is redundant, error prone and not needed IMHO

@afenioux commented on GitHub (Jul 8, 2016): Not really the same question, but it's related: Why is there a netmask in the IP object? The IP by itself has no netmask, but need to be linked to a prefix (which has a netmask). Having the netmask in both IP and Prefix is redundant, error prone and not needed IMHO
adam commented 2025-12-29 15:31:18 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 8, 2016):

The mask is part of the IP address. You can't configure an IP address on an interface without also specifying a mask (except for legacy systems which infer classful addressing). Since the mask is likely to be needed when reading IP info from NetBox, it makes sense to include it as part of the model. Including the mask also helps with performance and data integrity.

@jeremystretch commented on GitHub (Jul 8, 2016): The mask is part of the IP address. You can't configure an IP address on an interface without also specifying a mask (except for legacy systems which infer classful addressing). Since the mask is likely to be needed when reading IP info from NetBox, it makes sense to include it as part of the model. Including the mask also helps with performance and data integrity.
adam commented 2025-12-29 15:31:18 +01:00
Author
Owner
Copy Link

@afenioux commented on GitHub (Jul 8, 2016):

Well, looking at IP field (src or dst) in a packet do not provide the mask (which is used only for routing purpose of the prefix). But I looked at how IP are created and linked to an interface in Netbox, so your answer makes sens.

Regarding the model, I think that including mask (at least) as a separated attribute would be easier to be able to edit the mask in the "IP Address Bulk Edit" page.
An even better solution would probably be to add a relation between IPAddress and Prefix classes.

@afenioux commented on GitHub (Jul 8, 2016): Well, looking at IP field (src or dst) in a packet do not provide the mask (which is used only for routing purpose of the prefix). But I looked at how IP are created and linked to an interface in Netbox, so your answer makes sens. Regarding the model, I think that including mask (at least) as a separated attribute would be easier to be able to edit the mask in the "IP Address Bulk Edit" page. An even better solution would probably be to add a relation between IPAddress and Prefix classes.
adam commented 2025-12-29 15:31:18 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 9, 2016):

The IP address along with its mask is already related to its parent prefix by the very nature of how IP addressing works. This was done intentionally to avoid the need for an explicit relation in the database. It's entirely possible to add a method to update the max length of IP addresses in bulk, but that's far from the topic of this issue.

@jeremystretch commented on GitHub (Jul 9, 2016): The IP address along with its mask is already related to its parent prefix by the very nature of how IP addressing works. This was done intentionally to avoid the need for an explicit relation in the database. It's entirely possible to add a method to update the max length of IP addresses in bulk, but that's far from the topic of this issue.
adam commented 2025-12-29 15:31:18 +01:00
Author
Owner
Copy Link

@Marlinc commented on GitHub (Aug 12, 2016):

I don't think its a good idea to automatically create a prefix for a IP address. We for example have a few 1U rack units with single IPs. We don't own the prefix in which those IP addressen reside.

@Marlinc commented on GitHub (Aug 12, 2016): I don't think its a good idea to automatically create a prefix for a IP address. We for example have a few 1U rack units with single IPs. We don't own the prefix in which those IP addressen reside.
adam commented 2025-12-29 15:31:19 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 12, 2016):

I'm going to close this out as there doesn't seem to be much interest, and I'd rather avoid any "automagical" behavior in NetBox. Users can of course create whatever prefixes they'd like anyway.

@jeremystretch commented on GitHub (Aug 12, 2016): I'm going to close this out as there doesn't seem to be much interest, and I'd rather avoid any "automagical" behavior in NetBox. Users can of course create whatever prefixes they'd like anyway.
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#65
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?