Don't allow the creation of IP addresses on already allocated prefixes, from within its parent prefix

[BrunoBlanes]

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.

[empusas]

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.

[BrunoBlanes]

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.

[empusas]

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.

[BrunoBlanes]

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.

[empusas]

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.

[BrunoBlanes]

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?

[DorianXGH]

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.

[BrunoBlanes]

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.

[DorianXGH]

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.

[BrunoBlanes]

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.

[empusas]

One use case I had in a company that I worked for. They have used the same IP range for the connectivity to their customers, but that have been always different server in the backend. The reason was they did not have sufficient public IPs to assign per customer. They did not want to use the VRF feature from Netbox. Instead the used the tenant field to distinguish between them, so they still got a warning about duplicate IPs, but they did not care. A similar use case would be link local IPs(169.254. 0.0/16) for transfer segments between network devices that are used everywhere between NW devices in the same VRF. That does not mean that all those use cases are the proper way to do it, but with the lack of registered IPv4 addresses people got "creative".

I would agree that the code for the loopup between IP and prefixes I posted above is not optimal (I would add the tenant also as filter )and I think there is another request open to have as relation between IPs and prefixes, which would be the best solution I guess.

But the root cause I still see for your problem is that you setup Netbox, give everybody R/W access without given them any training on your standards how to use it. There are many features in Netbox where there is not only one way to do it. So if users don't stick to a defined standard it will lead to problem at some point. At the latest when you start developing an automation that uses Netbox as SoT you expect the data in some form.

Netbox gives you many flexibility on how to use it. For example nobody is forced yet to use the VRF feature.

[BrunoBlanes]

Your use case would not be affected at all with this change. I am not trying to make it impossible to add duplicate addresses, I only want the ability to do it to be moved to the appropriate place.

But the root cause I still see for your problem is that you setup Netbox, give everybody R/W access without given them any training on your standards how to use it.

As I've said already, people make mistakes, they have received proper training, and they need permission to assign addresses for them to be able to do their work, but as it happens sometimes you do forget to check both the "IP Address" and "Prefixes" tab.

[github-actions[bot]]

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. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

[elipsion]

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

If/when #7845 is implemented, this can be enforced via permissions and an access constraint:

[{"address__parent_prefix__status": "ACTIVE"}]

[BrunoBlanes]

It still wouldn't solve it though. We currently set all of our public /24 IPv4 prefixes to be containers given that that's the minimum mask you can advertise on the internet, it seemed suitable. However, from those we assign /32 IPs for enterprise clients, /30 prefixes for point-to-point connection with client providers, /27 prefixes for CGNAT, and so on.

The Container type is really more of an organizational characteristic than anything else. We couldn't use that to enforce a restriction on usage.

[kkthxbye-code]

@BrunoBlanes - You can prevent creation during form validation using custom validators, not sure if that is a usable workaround for you specific usecase.

[BrunoBlanes]

I haven't used this feature, could you link me to some documentation?

[kkthxbye-code]

https://docs.netbox.dev/en/stable/customization/custom-validation/

Under Custom Validation Logic you can see a small example. You would have to write a manual check in python. if I understand your issue correctly, you would have to check that the netmask matches the closest parent prefix.

[BrunoBlanes]

It sure is a workaround that I'll implement on our instance, however doing it this way means if the user makes a mistake, he will have to go back to square one and find the right prefix for the task. Doing it natively we could avoid rework by just not showing this as a free IP addresses in the front-end.

[jeremystretch]

The prescribed behavior, as far as I can tell, seems rather esoteric and would likely break competing use cases. As this FR has not found any substantial support in the community and a (potentially) viable alternative solution has been proposed, I'm going to close this for inactivity.