Netbox: When adding an IP address inside a prefix, the netmask must be forced to be the same as the prefix

[Keyhaku]

Environment

• Python version: 3.6.8
• NetBox version: 2.5.7

Steps to Reproduce

1. Create a Prefix with a /27 netmask
2. From this prefix, click "Add an IP Address"
3. Change the netmask of the IP automatically provided to /2 or to /29 (any other netmask size in reality)

Expected Behavior

The interface (and the API I guess) should not allowed this IP since the netmask does not belong to this subnet.

Observed Behavior

The IP is allocated inside the subnet, but the netmask associated is wrong

[DanSheps]

I can confirm this is the behaviour.

This isn't so much an adding the prefix bug as it is a display bug. It should not show that prefix as a parent, but it should allow the creation as IP addresses are not tied specifically to a prefix.

[Keyhaku]

I'm not sure I understand why this is a display bug,

On the interface I'm on the subnet tab (IPAM -> Prefixes -> <PREFIX>), If i add an IP, it should be forced to be in this subnet.
The expected behaviour is very different than if I was on the IP Address Tab that allow me to create an IP address within any subnet.

[DanSheps]

On the interface I'm on the subnet tab (IPAM -> Prefixes -> <PREFIX>), If i add an IP, it should be forced to be in this subnet.

The expected behaviour is very different than if I was on the IP Address Tab that allow me to create an IP address within any subnet.

There is no direct relationship between Prefixes and IP Addresses. It was never intended to force you into that (much like if you add a device in a Rack, it will default to the rack position you select but it won't FORCE you to keep that, you could move it into a completely diffferent site).

[DanSheps]

Question for the community: Is this something we want to fix, or should it be left and then handled with a user generated custom report to show mis-matched prefixes?

[ktims]

I would prefer this be left as is, with the subnet of the IP address representing the device's interface configuration, and the prefix itself merely representing an allocated block. Any IPs within the prefix, regardless of netmask, should be children of that prefix. Not showing them as children, despite them being allocated, would lead to accidental duplicate allocations and is at best confusing.

Not all prefixes are LAN segments, for example NAT pools, loopback address blocks, etc, where the interface will be configured as /32 despite being part of an allocated prefix.

[kdadev]

When doing network resegmentation it was better for us to expand network mask and next to edit hosts addresses instead of getting message about hosts-network prefixes incompatibility.

Also we have subnets designated for loopback interfaces. This subnet marked as /26 prefix, but each address in this subnet has /32 prefix length. So me and my colleagues don't want to change this behavior.

Maybe it's resonable to add additional flag in subnet property for point whether to check network-host prefix compatibility. But this is uneccessary by my opinion.

[DanSheps]

It seems there isn't much desire for this to change. Closing it out.