warn about IP conflict #320

Closed
opened 2025-12-29 16:20:50 +01:00 by adam · 8 comments
Owner

Originally created by @jkldgoefgkljefogeg on GitHub (Aug 3, 2016).

no warning was given when duplicated IP address in the same VRP configured on multiple devices (device edit => assign IP address)

Originally created by @jkldgoefgkljefogeg on GitHub (Aug 3, 2016). no warning was given when duplicated IP address in the same VRP configured on multiple devices (device edit => assign IP address)
adam added the type: featurestatus: needs ownerpending closure labels 2025-12-29 16:20:50 +01:00
adam closed this issue 2025-12-29 16:20:50 +01:00
Author
Owner

@jkldgoefgkljefogeg commented on GitHub (Aug 3, 2016):

The current duplicated IP check under IP addresses show only 1 IP address under conflict if the IP address was created from DCIM and then removed from interface. It's a bit of confusing. Better warn about duplicated IP at creation rather than depending on cleaning up later.

If device primary IP is added from assign IP address. When the assigned IP address gets deleted, primary IP is not cleared, leaving an orphaned IP usage.

@jkldgoefgkljefogeg commented on GitHub (Aug 3, 2016): The current duplicated IP check under IP addresses show only 1 IP address under conflict if the IP address was created from DCIM and then removed from interface. It's a bit of confusing. Better warn about duplicated IP at creation rather than depending on cleaning up later. If device primary IP is added from assign IP address. When the assigned IP address gets deleted, primary IP is not cleared, leaving an orphaned IP usage.
Author
Owner

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

We can probably add a warning on the IP creation form. It's worth noting however that you can disable duplicate IPs and prefixes entirely by enforcing unique space within the VRF (by toggling "Enforce unique space") and/or global table (using the ENFORCE_GLOBAL_UNIQUE configuration setting).

If device primary IP is added from assign IP address. When the assigned IP address gets deleted, primary IP is not cleared, leaving an orphaned IP usage.

All IPs assigned to an interface on a deleted device get deleted. You're probably seeing the duplicate IP that's left after the other IP is deleted.

@jeremystretch commented on GitHub (Aug 3, 2016): We can probably add a warning on the IP creation form. It's worth noting however that you can disable duplicate IPs and prefixes entirely by enforcing unique space within the VRF (by toggling "Enforce unique space") and/or global table (using the `ENFORCE_GLOBAL_UNIQUE` configuration setting). > If device primary IP is added from assign IP address. When the assigned IP address gets deleted, primary IP is not cleared, leaving an orphaned IP usage. All IPs assigned to an interface on a deleted device get deleted. You're probably seeing the duplicate IP that's left after the other IP is deleted.
Author
Owner

@fallenfuzz commented on GitHub (Aug 9, 2018):

Hi,

A button for overlapping check would be nice too in IP Address / IP preffix creation.

43589114-b60621da-9676-11e8-9f40-bac8a53c7c97

@fallenfuzz commented on GitHub (Aug 9, 2018): Hi, A button for overlapping check would be nice too in IP Address / IP preffix creation. ![43589114-b60621da-9676-11e8-9f40-bac8a53c7c97](https://user-images.githubusercontent.com/13089287/43920007-66ee81be-9c20-11e8-8922-59b2df41b0a1.png)
Author
Owner

@DanSheps commented on GitHub (Nov 15, 2019):

Do we want to revisit this? I don't see any value to be gained by this with both the enforce uniqueness on a per-vrf or global basis. I think it could only confuse things to if a IP address was assigned a FHRP role and was duplicated (since you want a duplicate in that instance).

I can see the logic for checking this getting unnecessarily complex.

@DanSheps commented on GitHub (Nov 15, 2019): Do we want to revisit this? I don't see any value to be gained by this with both the enforce uniqueness on a per-vrf or global basis. I think it could only confuse things to if a IP address was assigned a FHRP role and was duplicated (since you want a duplicate in that instance). I can see the logic for checking this getting unnecessarily complex.
Author
Owner

@jeremystretch commented on GitHub (Jul 24, 2020):

It doesn't look like this ever got any traction. I've tagged it as needs owner in case anyone wants to volunteer. If not, it will end up getting closed and possibly reconsidered during a future UI refresh.

@jeremystretch commented on GitHub (Jul 24, 2020): It doesn't look like this ever got any traction. I've tagged it as `needs owner` in case anyone wants to volunteer. If not, it will end up getting closed and possibly reconsidered during a future UI refresh.
Author
Owner

@Kircheneer commented on GitHub (Aug 20, 2020):

I would be willing to implement the check @fallenfuzz has proposed. I think it has value for those cases where you explicitly do not want to create a container allocation but rather allocate a new subnet. What do you guys think?

@Kircheneer commented on GitHub (Aug 20, 2020): I would be willing to implement the check @fallenfuzz has proposed. I think it has value for those cases where you explicitly do not want to create a container allocation but rather allocate a new subnet. What do you guys think?
Author
Owner

@stale[bot] commented on GitHub (Oct 4, 2020):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@stale[bot] commented on GitHub (Oct 4, 2020): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
Author
Owner

@stale[bot] commented on GitHub (Oct 19, 2020):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@stale[bot] commented on GitHub (Oct 19, 2020): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#320