Don&#39;t allow the creation of IP addresses on already allocated prefixes, from within its parent prefix #6599

Originally created by @BrunoBlanes on GitHub (Jun 27, 2022).

NetBox version

v3.2.4

Feature type

Change to existing functionality

Proposed functionality

When a prefix is created don't allow the creation of IP addresses for that prefix, from its parent prefix, for example:

Parent prefix: 10.0.0.0/24
Child prefix: 10.0.0.0/30

The IP addresses 10.0.0.0 - 10.0.0.4 should only be allowed to be created from within the child prefix. That way, it avoids the assignment of duplicate IP addresses beforehand.

Use case

We allocate a lot of prefixes as an ISP and eventually need to allocate 32 bit length subnet-mask IP addresses to our clients as well. Since prefixes and IP addresses don't share a common logic from within the prefix page, Netbox will allow (and suggest) to create a /32 IP address from an already assigned prefix.
This causes some headaches as we have to double check every IP assignment so that we don't assign an IP to client A when it is part of the prefix already assigned to client B.

Database changes

I don't think any is applicable.

External dependencies

None.

Originally created by @BrunoBlanes on GitHub (Jun 27, 2022). ### NetBox version v3.2.4 ### Feature type Change to existing functionality ### Proposed functionality When a prefix is created don't allow the creation of IP addresses for that prefix, from its parent prefix, for example: Parent prefix: `10.0.0.0/24` Child prefix: `10.0.0.0/30` The IP addresses `10.0.0.0 - 10.0.0.4` should only be allowed to be created from within the child prefix. That way, it avoids the assignment of duplicate IP addresses beforehand. ### Use case We allocate a lot of prefixes as an ISP and eventually need to allocate 32 bit length subnet-mask IP addresses to our clients as well. Since prefixes and IP addresses don't share a common logic from within the prefix page, Netbox will allow (and suggest) to create a `/32` IP address from an already assigned prefix. This causes some headaches as we have to double check every IP assignment so that we don't assign an IP to client `A` when it is part of the prefix already assigned to client `B`. ### Database changes I don't think any is applicable. ### External dependencies None.

adam added the type: feature pending closure labels 2025-12-29 19:42:50 +01:00

adam closed this issue

adam commented

@empusas commented on GitHub (Jul 4, 2022):

That won't really work well and put unnecessary restrictions on netbox IP management. One feature of netbox is that it can deal with duplicate IPs to some degree, which is common requirement in a provider network where every customer is using private RFC1918 IP address space and you have to deal with IP overlap and duplicates.
I suggest you mark your parent prefixes as "container", the child prefixes as "active" and tell people only to assign IPs in "active" prefixes.

@empusas commented on GitHub (Jul 4, 2022): That won't really work well and put unnecessary restrictions on netbox IP management. One feature of netbox is that it can deal with duplicate IPs to some degree, which is common requirement in a provider network where every customer is using private RFC1918 IP address space and you have to deal with IP overlap and duplicates. I suggest you mark your parent prefixes as "container", the child prefixes as "active" and tell people only to assign IPs in "active" prefixes.

adam commented

@BrunoBlanes commented on GitHub (Jul 4, 2022):

I suggest you mark your parent prefixes as "container", the child prefixes as "active" and tell people only to assign IPs in "active" prefixes.

The "tell people" part doesn't seem the ideal solution, also I don't see how this wouldn't work well. It doesn't impose unnecessary restrictions since you'd still be able to do everything you can do now; it would just be moved to safer spaces.

Netbox can really deal with duplicate IP addresses, but not when the address is not specified, which is my point, since I cannot specify where my client is using said IP, so I have to rely on the prefix itself.

@BrunoBlanes commented on GitHub (Jul 4, 2022): > I suggest you mark your parent prefixes as "container", the child prefixes as "active" and tell people only to assign IPs in "active" prefixes. The "tell people" part doesn't seem the ideal solution, also I don't see how this wouldn't work well. It doesn't impose unnecessary restrictions since you'd still be able to do everything you can do now; it would just be moved to safer spaces. Netbox can really deal with duplicate IP addresses, but not when the address is not specified, which is my point, since I cannot specify where my client is using said IP, so I have to rely on the prefix itself.

adam commented

@empusas commented on GitHub (Jul 4, 2022):

You currently have two choices to identify a prefix by adding the site or the tenant information. That does not work for you?
Not sure how you use netbox, by using the API with your own provisioning/automation it should not be a big problem to add a check if an IP is free or not in the right prefix, before one is assigned.
If users assign them, then I guess a proper work instruction and selectively given the access to do so is the right way.

I have seen tools like Netbrain completely fail in an environment where the customer always used the same private network for the HA clusters build from a build template. So same site, same tenant, always the same IP prefix. That never caused a technical problem, but then they had to spend thousands of hours to change all HW cluster network to unique ones, just to make netbrian work. This is the kind of restrictions I would not like to see in netbox.

@empusas commented on GitHub (Jul 4, 2022): You currently have two choices to identify a prefix by adding the site or the tenant information. That does not work for you? Not sure how you use netbox, by using the API with your own provisioning/automation it should not be a big problem to add a check if an IP is free or not in the right prefix, before one is assigned. If users assign them, then I guess a proper work instruction and selectively given the access to do so is the right way. I have seen tools like Netbrain completely fail in an environment where the customer always used the same private network for the HA clusters build from a build template. So same site, same tenant, always the same IP prefix. That never caused a technical problem, but then they had to spend thousands of hours to change all HW cluster network to unique ones, just to make netbrian work. This is the kind of restrictions I would not like to see in netbox.

adam commented

@BrunoBlanes commented on GitHub (Jul 4, 2022):

Mate, it doesn't matter how we identify prefixes, identifying them doesn't fix the problem.

If users assign them, then I guess a proper work instruction and selectively given the access to do so is the right way.

Currently we have users assign them and you clearly haven't worked with people. They make mistakes, we're only human. I'm trying to avoid them.

@BrunoBlanes commented on GitHub (Jul 4, 2022): Mate, it doesn't matter how we identify prefixes, identifying them doesn't fix the problem. > If users assign them, then I guess a proper work instruction and selectively given the access to do so is the right way. Currently we have users assign them and you clearly haven't worked with people. They make mistakes, we're only human. I'm trying to avoid them.

adam commented

@empusas commented on GitHub (Jul 19, 2022):

I had a look at the NB data model. There is no direct relationship between the IP address and the prefix. And that would be necessary to avoid blocking the IP creating if there a duplicate IPs for a good reason(multi tenant, different VRFs etc)

The lookup between prefix and IP addresses is purely done by matching the IP to the prefix with this code:

def get_child_ips(self):
       """
       Return all IPAddresses within this Prefix and VRF. If this Prefix is a container in the global table, return
       child IPAddresses belonging to any VRF.
       """
       if self.vrf is None and self.status == PrefixStatusChoices.STATUS_CONTAINER:
           return IPAddress.objects.filter(address__net_host_contained=str(self.prefix))
       else:
           return IPAddress.objects.filter(address__net_host_contained=str(self.prefix), vrf=self.vrf)

So enforcing that no duplicate IP could be created within a prefix requires either

a) to force all prefixes and IP must be assigned to a VRF(VRF then becomes then the common denominator between IP address and prefix)
b) change the database model to have a relation between IP address and prefix.

@empusas commented on GitHub (Jul 19, 2022): I had a look at the NB data model. There is no direct relationship between the IP address and the prefix. And that would be necessary to avoid blocking the IP creating if there a duplicate IPs for a good reason(multi tenant, different VRFs etc) The lookup between prefix and IP addresses is purely done by matching the IP to the prefix with this code: ``` def get_child_ips(self): """ Return all IPAddresses within this Prefix and VRF. If this Prefix is a container in the global table, return child IPAddresses belonging to any VRF. """ if self.vrf is None and self.status == PrefixStatusChoices.STATUS_CONTAINER: return IPAddress.objects.filter(address__net_host_contained=str(self.prefix)) else: return IPAddress.objects.filter(address__net_host_contained=str(self.prefix), vrf=self.vrf) ``` So enforcing that no duplicate IP could be created within a prefix requires either a) to force all prefixes and IP must be assigned to a VRF(VRF then becomes then the common denominator between IP address and prefix) b) change the database model to have a relation between IP address and prefix.

adam commented

@BrunoBlanes commented on GitHub (Jul 21, 2022):

a) to force all prefixes and IP must be assigned to a VRF(VRF then becomes then the common denominator between IP address and prefix)

By default aren't they already assigned to the global VRF?

@BrunoBlanes commented on GitHub (Jul 21, 2022): > a) to force all prefixes and IP must be assigned to a VRF(VRF then becomes then the common denominator between IP address and prefix) By default aren't they already assigned to the `global` VRF?

adam commented

@DorianBourgeoisat commented on GitHub (Aug 14, 2022):

The problem with restricting possible entries is that it might hinder another usecase even though it makes it better for yours.
I would instead suggest making it possible to have user-defined validation rules.
Or at the very least make it a warning like the duplicate IP address warning.

@DorianBourgeoisat commented on GitHub (Aug 14, 2022): The problem with restricting possible entries is that it might hinder another usecase even though it makes it better for yours. I would instead suggest making it possible to have user-defined validation rules. Or at the very least make it a warning like the duplicate IP address warning.

adam commented

@BrunoBlanes commented on GitHub (Aug 14, 2022):

The problem with restricting possible entries is that it might hinder another usecase even though it makes it better for yours.

Could you give me an example of a use case where this might break?

Or at the very least make it a warning like the duplicate IP address warning.

I am ok with a warning, but I still think it could be fully implemented.

@BrunoBlanes commented on GitHub (Aug 14, 2022): > The problem with restricting possible entries is that it might hinder another usecase even though it makes it better for yours. Could you give me an example of a use case where this might break? > Or at the very least make it a warning like the duplicate IP address warning. I am ok with a warning, but I still think it could be fully implemented.

adam commented

@DorianBourgeoisat commented on GitHub (Aug 14, 2022):

Could you give me an example of a use case where this might break?

I cannot, but there might be one, thus my stance on prefering flexibility.

@DorianBourgeoisat commented on GitHub (Aug 14, 2022): > Could you give me an example of a use case where this might break? I cannot, but there might be one, thus my stance on prefering flexibility.

adam commented

@BrunoBlanes commented on GitHub (Aug 15, 2022):

I don't think there is one, because you are not forbidding users from doing what they already do, you are just moving it somewhere else. Sure, it might add additional clicks to get there, but at the benefit of not creating duplicate addresses.

@BrunoBlanes commented on GitHub (Aug 15, 2022): I don't think there is one, because you are not forbidding users from doing what they already do, you are just moving it somewhere else. Sure, it might add additional clicks to get there, but at the benefit of not creating duplicate addresses.

adam commented