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

2 locations with the same prefix and IPs are not separated. #8946

New Issue
Closed
opened 2025-12-29 20:43:09 +01:00 by adam · 6 comments
adam commented 2025-12-29 20:43:09 +01:00
Owner
Copy Link

Originally created by @LHBL2003 on GitHub (Dec 11, 2023).

Deployment Type

Self-hosted

NetBox Version

v3.6.6

Python Version

3.8

Steps to Reproduce

Create 2 Idenic subnets at two locations (e.g. for guest WLAN)

image

Create an IP in the first prefix
image

Refresh the view for the second prefix
image

Expected Behavior

The IP is only available for the first prefix

Observed Behavior

The IP address is displayed in both prefixes, although this was only created for the first prefix.

Originally created by @LHBL2003 on GitHub (Dec 11, 2023). ### Deployment Type Self-hosted ### NetBox Version v3.6.6 ### Python Version 3.8 ### Steps to Reproduce Create 2 Idenic subnets at two locations (e.g. for guest WLAN) ![image](https://github.com/netbox-community/netbox/assets/46369917/475dcf7f-1473-4db5-a863-89db54002606) Create an IP in the first prefix ![image](https://github.com/netbox-community/netbox/assets/46369917/8dbc7db5-e632-42df-a8cb-1d27db136b90) Refresh the view for the second prefix ![image](https://github.com/netbox-community/netbox/assets/46369917/7835fd34-e640-49cb-a450-166e81c8c8f5) ### Expected Behavior The IP is only available for the first prefix ### Observed Behavior The IP address is displayed in both prefixes, although this was only created for the first prefix.
adam closed this issue 2025-12-29 20:43:09 +01:00
adam commented 2025-12-29 20:43:10 +01:00
Author
Owner
Copy Link

@ITJamie commented on GitHub (Dec 11, 2023):

theres no vrf assigned in this example so both prefixes are considered to be in the global vrf.

@ITJamie commented on GitHub (Dec 11, 2023): theres no vrf assigned in this example so both prefixes are considered to be in the global vrf.
adam commented 2025-12-29 20:43:11 +01:00
Author
Owner
Copy Link

@LHBL2003 commented on GitHub (Dec 11, 2023):

Oh thank you, now I understand why VRF.
I will also try the configuration parameter tomorrow: ENFORCE_GLOBAL_UNIQUE tomorrow. Because I've already had duplicate IPs a few times that I didn't want :)

Thank you, I've learnt something new

@LHBL2003 commented on GitHub (Dec 11, 2023): Oh thank you, now I understand why VRF. I will also try the configuration parameter tomorrow: ENFORCE_GLOBAL_UNIQUE tomorrow. Because I've already had duplicate IPs a few times that I didn't want :) Thank you, I've learnt something new
adam commented 2025-12-29 20:43:11 +01:00
Author
Owner
Copy Link

@LHBL2003 commented on GitHub (Dec 11, 2023):

@ITJamie

Does it make sense to create a VRF entry for each location and to set the VRF of the location in each prefix?

If I have a WiFi network at each location, which is always set up in the same way, should I set the VRF prefix to Global so that I don't have to create the same prefix x times, or would it be better to define the prefix for each location?

What is your experience with this?

@LHBL2003 commented on GitHub (Dec 11, 2023): @ITJamie Does it make sense to create a VRF entry for each location and to set the VRF of the location in each prefix? If I have a WiFi network at each location, which is always set up in the same way, should I set the VRF prefix to Global so that I don't have to create the same prefix x times, or would it be better to define the prefix for each location? What is your experience with this?
adam commented 2025-12-29 20:43:11 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Dec 11, 2023):

Unfortunately this is 100% intended, as the IP fits into both prefixes.

Our current data model does not take into account actual physical location of the prefix and only assigns a prefix to an IP based on the VRF (or lack of VRF) and prefix match.

I personally would like to see the IP address <> prefix link be made explicit (assigned and not derived) as you could allow for these unique circumstances.

@DanSheps commented on GitHub (Dec 11, 2023): Unfortunately this is 100% intended, as the IP fits into both prefixes. Our current data model does not take into account actual physical location of the prefix and only assigns a prefix to an IP based on the VRF (or lack of VRF) and prefix match. I personally would like to see the IP address <> prefix link be made explicit (assigned and not derived) as you could allow for these unique circumstances.
adam commented 2025-12-29 20:43:12 +01:00
Author
Owner
Copy Link

@LHBL2003 commented on GitHub (Dec 12, 2023):

@DanSheps

So I understand that VFR is a workaround in my case. Because VFR is actually (basic idea like VLAN) intended for the virtual separation of routers. And not to map individual firewalls (routers) in the company, where there are identical segments that are not routed.

@LHBL2003 commented on GitHub (Dec 12, 2023): @DanSheps So I understand that VFR is a workaround in my case. Because VFR is actually (basic idea like VLAN) intended for the virtual separation of routers. And not to map individual firewalls (routers) in the company, where there are identical segments that are not routed.
adam commented 2025-12-29 20:43:12 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 12, 2023):

A VRF is essentially an isolated routing domain, roughly similar in concept to a VLAN at layer two. It's not a workaround; it's how multiple L3 forwarding tables are maintained across an IP network. If you'd like to discuss your options further, please open a discussion.

As the behavior described above is expected, I'm going to close this bug report.

@jeremystretch commented on GitHub (Dec 12, 2023): A [VRF](https://en.wikipedia.org/wiki/Virtual_routing_and_forwarding) is essentially an isolated routing domain, _roughly_ similar in concept to a VLAN at layer two. It's not a workaround; it's how multiple L3 forwarding tables are maintained across an IP network. If you'd like to discuss your options further, please open a [discussion](https://github.com/netbox-community/netbox/discussions/new/choose). As the behavior described above is expected, I'm going to close this bug report.
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#8946
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?