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

Allow prefixes to be assign to device instances #11406

New Issue
Closed
opened 2025-12-29 21:44:49 +01:00 by adam · 5 comments
adam commented 2025-12-29 21:44:49 +01:00
Owner
Copy Link

Originally created by @marcusyuri on GitHub (Jul 22, 2025).

NetBox version

v4.3.4

Feature type

Data model extension

Proposed functionality

Currently netbox can natively assign a prefix to a Location, a Region, a Site or a Site Group, using the Scope fields. I am proposing to include DCIM -> Device as another option to "Scope Type".

Currently we can create a custom field on IPAM -> Prefixes relating it to a DCIM -> Device Object, but the association in 'Scope Type' will be preferred because of the native netbox feature that allows a prefix to be assigned to only one 'Scope Type' object, avoiding duplicate assigment.

Use case

The association of a prefix to a device is a very common use case in network documentation. For example, an end-user PoE access switch can have a /24 prefix assigned to it, and for example the first usable ip address will be used as end users pcs default gateway, and another address range inside this prefix, for example .10 to .200 to DHCP leases and so on.

Another example is route summarization, that can be done at a device level, so the more large IP aggregated prefix is associated with the routing device that performs the bgp or igp aggregation.

Database changes

Add IPAM->Prefix foreign key to DCIM->Device

External dependencies

None

Originally created by @marcusyuri on GitHub (Jul 22, 2025). ### NetBox version v4.3.4 ### Feature type Data model extension ### Proposed functionality Currently netbox can natively assign a prefix to a Location, a Region, a Site or a Site Group, using the Scope fields. I am proposing to include DCIM -> Device as another option to "Scope Type". Currently we can create a custom field on IPAM -> Prefixes relating it to a DCIM -> Device Object, but the association in 'Scope Type' will be preferred because of the native netbox feature that allows a prefix to be assigned to only one 'Scope Type' object, avoiding duplicate assigment. ### Use case The association of a prefix to a device is a very common use case in network documentation. For example, an end-user PoE access switch can have a /24 prefix assigned to it, and for example the first usable ip address will be used as end users pcs default gateway, and another address range inside this prefix, for example .10 to .200 to DHCP leases and so on. Another example is route summarization, that can be done at a device level, so the more large IP aggregated prefix is associated with the routing device that performs the bgp or igp aggregation. ### Database changes Add IPAM->Prefix foreign key to DCIM->Device ### External dependencies None
adam added the type: feature label 2025-12-29 21:44:49 +01:00
adam closed this issue 2025-12-29 21:44:50 +01:00
adam commented 2025-12-29 21:44:50 +01:00
Author
Owner
Copy Link

@stuntguy3000 commented on GitHub (Jul 23, 2025):

The association of a prefix to a device is a very common use case in network documentation

As a network engineer, my documentation refers to the L2/L3 VLANs and Interfaces within the device, not the device itself. From a modelling perspective, what your suggesting doesn't really make a lot of sense to me?

What you may be looking for are assignment of Prefixes to VLANs, which are then in-tern assigned to Interfaces on Devices.

Image Image Image
@stuntguy3000 commented on GitHub (Jul 23, 2025): > The association of a prefix to a device is a very common use case in network documentation As a network engineer, my documentation refers to the L2/L3 VLANs and Interfaces **within** the device, not the **device itself**. From a modelling perspective, what your suggesting doesn't really make a lot of sense to me? What you may be looking for are assignment of Prefixes to VLANs, which are then in-tern assigned to Interfaces on Devices. <img width="1920" height="937" alt="Image" src="https://github.com/user-attachments/assets/cdfd6e91-36f4-4f91-b46f-fb393e88b19d" /> <img width="772" height="337" alt="Image" src="https://github.com/user-attachments/assets/baf02f69-18c6-49fa-952a-91866bb195d3" /> <img width="1920" height="937" alt="Image" src="https://github.com/user-attachments/assets/733b6f5c-35d8-48e7-adbe-1cbf1031bce6" />
adam commented 2025-12-29 21:44:50 +01:00
Author
Owner
Copy Link

@jnovinger commented on GitHub (Jul 24, 2025):

As noted, a prefix is not contained within a device.

@jnovinger commented on GitHub (Jul 24, 2025): As noted, a prefix is not contained within a device.
adam commented 2025-12-29 21:44:50 +01:00
Author
Owner
Copy Link

@marcusyuri commented on GitHub (Jul 24, 2025):

Hellow, Jason!

I respectfully disagree. See the following real world example (hostname and prefixes changed to publish in this public discussion):

SW1#show ip interface
VLAN 100     192.168.222.17/29
VLAN 101     192.168.222.25/29
VLAN 102     192.168.222.33/29
VLAN 103     192.168.222.41/29
VLAN 104     192.168.222.49/29
VLAN 110     192.168.222.97/27

SW1# show runnning
router ospf

 ... ommitted unrelated configs

 passive-interface 100
 passive-interface 101
 passive-interface 102
 passive-interface 103

... more configs ommited

 area 100 range 192.168.222.0/24 advertisse
...

Yes, we have addresses that are assigned to vlans interfaces on this switch, but all vlans prefixes (vlan 100 - /29, vlan 110 /27, etc) belongs to the parent 192.168.222.0/24 prefix.

As you can see in this config, all the vlans prefixes are aggregated by the SW1, and only by SW1, in the 192.168.222.0/24 parent prefix. So the 192.168.222.0/24 prefix is associated with the SW1 device. It is not associated with any site, nor any vlan, but with this specific device.

Thanks

@marcusyuri commented on GitHub (Jul 24, 2025): Hellow, Jason! I respectfully disagree. See the following real world example (hostname and prefixes changed to publish in this public discussion): ``` SW1#show ip interface VLAN 100 192.168.222.17/29 VLAN 101 192.168.222.25/29 VLAN 102 192.168.222.33/29 VLAN 103 192.168.222.41/29 VLAN 104 192.168.222.49/29 VLAN 110 192.168.222.97/27 SW1# show runnning router ospf ... ommitted unrelated configs passive-interface 100 passive-interface 101 passive-interface 102 passive-interface 103 ... more configs ommited area 100 range 192.168.222.0/24 advertisse ... ``` Yes, we have addresses that are assigned to vlans interfaces on this switch, but all vlans prefixes (vlan 100 - /29, vlan 110 /27, etc) belongs to the parent 192.168.222.0/24 prefix. As you can see in this config, all the vlans prefixes are aggregated by the SW1, and only by SW1, in the 192.168.222.0/24 parent prefix. So the 192.168.222.0/24 prefix is associated with the SW1 device. It is not associated with any site, nor any vlan, but with this specific device. Thanks
adam commented 2025-12-29 21:44:51 +01:00
Author
Owner
Copy Link

@ross-cello commented on GitHub (Jul 24, 2025):

We too associate prefixes with devices, so I would see value in a native prefix<>device relationship.
VLAN's aren't always relevant; particularly in L3VPN environments.

Though we utilise Site in the scope, so this particular approach probably wouldn't work for us regardless...

@ross-cello commented on GitHub (Jul 24, 2025): We too associate prefixes with devices, so I would see value in a native prefix<>device relationship. VLAN's aren't always relevant; particularly in L3VPN environments. Though we utilise Site in the scope, so this particular approach probably wouldn't work for us regardless...
adam commented 2025-12-29 21:44:51 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 25, 2025):

As stated above, prefixes are not assigned directly to devices. Interfaces, which belong to devices, can be assigned individual IP addresses, which belong to prefixes. There is no direct relationship between a device and a prefix, so this FR has been declined.

Of course, NetBox is open source, so you are welcome to make whatever changes you'd like in a local fork to support your use case.

@jeremystretch commented on GitHub (Jul 25, 2025): As stated above, prefixes are not assigned directly to devices. Interfaces, which belong to devices, can be assigned individual IP addresses, which belong to prefixes. There is no direct relationship between a device and a prefix, so this FR has been declined. Of course, NetBox is open source, so you are welcome to make whatever changes you'd like in a local fork to support your use case.
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 type: feature
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#11406
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?