Confusing wording in official documentation regarding pool prefixes and IP assignment

[Azmodeszer]

This is NOT a question/complaint about assigning network IPs to interfaces. I've read issues such as #13392 and while I don't necessarily agree, I do acknowledge it.

I did however notice that https://demo.netbox.dev/static/docs/core-functionality/ipam/ says "If enabled, NetBox will treat this prefix as a range [..] wherein every IP address is valid and assignable" (emphasis mine). Isn't this a contradiction, then? Network IPs cannot be assigned to an interface, period. Right?

[markkuleinio]

I don't see a problem having a prefix of 10.1.2.0/24 and then assigning IP address 10.1.2.0/32 to my server interface. Do you?

[Azmodeszer]

That is not what I was addressing, though.

[candlerb]

Network IPs cannot be assigned to an interface, period. Right?

A pool is a bunch of individual (/32) IP addresses. Every address is a separate address, and there's no network address or broadcast address.

It's perfectly fine to assign an address ending .0 or .255 to a loopback interface. In any case, a /24 boundary has no significance; there are no class A/B/C ranges any more.

As regarding inconsistency in the documentation, the link you supplied gives a 404, so I don't know what you're quoting.

I checked the Netbox source code and I only found one instance of the word "wherein":

./docs/models/dcim/devicetype.md: This parent/child relationship is not suitable for modeling chassis-based devices, wherein child members share a common control plane. Instead, line cards and similarly non-autonomous hardware should be modeled as modules or inventory items within a device.

So I don't know what exactly the "If enabled" is referring to. If I search specifically for the phrase "If enabled" then I get more hits, but I don't see the text you quoted:

docs/configuration/miscellaneous.md:If enabled, a change log record will not be created when an object is updated without any changes to its existing field values.
docs/models/ipam/iprange.md:If enabled, the IP range will be considered 100% utilized regardless of how many IP addresses are defined within it. This is useful for documenting DHCP ranges, for example.
docs/models/extras/customfield.md:If enabled, values from this field will be automatically pre-populated when cloning existing objects.
docs/models/extras/customfieldchoiceset.md:If enabled, the choices list will be automatically ordered alphabetically. If disabled, choices will appear in the order in which they were defined.

The nearest text I can find is this:

docs/models/ipam/prefix.md:Designates whether the prefix should be treated as a pool. If selected, the first and last IP addresses within the prefix (normally reserved as the network and broadcast addresses, respectively) will be considered usable. This option is ideal for documenting NAT pools.

This is the Netbox 3.7.0 code I'm grepping (which os what demo.netbox.dev is running)

[Azmodeszer]

Sorry, I've fixed the link.

[Azmodeszer]

A pool is a bunch of individual (/32) IP addresses. Every address is a separate address, and there's no network address or broadcast address.

It's perfectly fine to assign an address ending .0 or .255 to a loopback interface. In any case, a /24 boundary has no significance; there are no class A/B/C ranges any more.

That would be news to me. When I create the prefix, say, 10.1.2.0/24, mark it as a pool and then try to create and assign the address 10.1.2.0/24 to an interface, Netbox will not allow it, saying that it "is a network ID, which may not be assigned to an interface". I can create the address, but I cannot assign it.

[candlerb]

Of course you cannot assign 10.1.2.0/24. But you should be able to assign 10.1.2.0/32. If that doesn't work, raise a bug (I haven't checked but I'm pretty sure it works).

Or are you saying you should not be able to create 10.1.2.0/24 in the first place? But you might have a reason to document the network address of a network (or its broadcast address).

[Azmodeszer]

/32 works, but the wording in the documentation implies that it should work with /24 regardless. Maybe I'm just reading it wrong.

But otherwise, what is even the point of the "is a pool" flag if I can just create a bunch of /32 addresses within a prefix anyway? What is the utility of marking a single prefix that way if I can just go around the network/broadcast limitation via "atomizing" IPs with a /32 mask? I am allowed to create these /32 addresses even if the pool flag is not checked.

EDIT: Actually, I noticed that I can create network and broadcast IPs regardless of the flag. The only thing that does seem to differ is whether it offers them for creation in the first place. "254 IPs available" vs. "256 IPs available". So now I'm even more confused as to the point of the pool attribute.

[candlerb]

I think that the data model that Netbox uses, where an IP address is both an address and a prefix (so 10.1.2.0/24 and 10.1.2.0/32 are effectively two different IP addresses with different properties) is awkward and, at best, results in much data duplication and scope for human error in data entry. However that's an argument I lost to Jeremy years ago.

I'm not going to argue about the "is pool" documentation, as I think it's pretty clear. A prefix which is not a pool is intended for use directly on an interface; a prefix which is a pool is intended to be broken up in to individual IPs.

I do think the "container" status would be better used for this. A "container" prefix isn't intended to be used directly on an interface; it can contain child prefixes, or it could contain /32 child IPs. From that point of view, I'd consider a "container" could also perform the function of a "pool".

EDIT:

So now I'm even more confused as to the point of the pool attribute.

More accurate calculation of prefix utilisation is an important reason, as well as offering free addresses in the GUI to be created.

[Azmodeszer]

Fair enough! Still wrapping my head around it all.