Non-/32 IP addresses take up only one IP #360

Closed
opened 2025-12-29 16:21:16 +01:00 by adam · 3 comments
Owner

Originally created by @rgstori on GitHub (Aug 12, 2016).

In the /ip-addresses view of a prefix, an IP address that isn't /32 occupies one position only.

On the other hand, replacing it with a child prefix (both "container" and "reserved") is worse, since these take up zero slots in the ip-addresses view.

Either non-/32 IP-address objects should not be allowed, or their occupation should be equal to their size. Also, child prefixes optionally occupying space in their parent's /ip-addresses view ("mark as full") would be nice.

Originally created by @rgstori on GitHub (Aug 12, 2016). In the /ip-addresses view of a prefix, an IP address that isn't /32 occupies one position only. On the other hand, replacing it with a child prefix (both "container" and "reserved") is worse, since these take up zero slots in the ip-addresses view. Either non-/32 IP-address objects should not be allowed, or their occupation should be equal to their size. Also, child prefixes optionally occupying space in their parent's /ip-addresses view ("mark as full") would be nice.
adam closed this issue 2025-12-29 16:21:16 +01:00
Author
Owner

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

You seem to be confusing prefixes and IP addresses. The two are different models in NetBox. An IP address only ever represents a single IP (with its mask), and a prefix only ever represents a network. See the docs for more info.

@jeremystretch commented on GitHub (Aug 12, 2016): You seem to be confusing prefixes and IP addresses. The two are different models in NetBox. An IP address only ever represents a single IP (with its mask), and a prefix only ever represents a network. See [the docs](http://netbox.readthedocs.io/en/latest/data-model/ipam/#prefixes) for more info.
Author
Owner

@rgstori commented on GitHub (Aug 13, 2016):

The difference between them is indeed very clear to me, I've simply defined
some prefixes as container subnets and now I'm filling them with single IP
addresses. My point is another: currently, there is no way to fill the IP
addresses space inside a prefix other than creating many single IPs.

For instance, I have created a /24 container prefix for some LB VIPs. Most
tenants only need a couple /32 vips, but one needs 30 of them: so I
reserved a /27 subnet for it, for the sake of readable routing.
In order to keep things tidy, I'm not very happy to create 30 ip address
objects, I just want to fill that /27 space inside the /24.
At first, I created a 'reserved' /27 child prefix inside the /24. But all
of the ip addresses of the /24 still showed up as available.
Then I created a /27 IP address object belonging to the /24 prefix, but
that occupied 1 IP only, not 32.
This was because I thought that the mask you write down when creating the
IP object represented the size of the object itself, not the mask of the
subnet it belongs to!

What I don't understand, then, is the purpose of the mask for the ip
address object: either it has the same meaning of the mask of its related
prefix, making it somewhat redundant, or maybe it has some other purpose?
The subnet mask of my devices is always the same across the whole L2
segment, why can I choose to assign different masks to IPs belonging to the
same subnet with the same mask? I shouldn't be given that possibility!

I know addresses and prefixes are separate objects but since netbox
correlates the two,
the mask should be a property of the prefix, not of the IP address.

Sorry for the long post, to sum it up:

  1. there should be a way to occupy more space than one IP at a time in the
    IP addresses tables, preferably with the creation of "full" prefixes.
  2. there is some redundancy between the masks of the prefix objects and the
    masks of the IP address objects.

Il ven 12 ago 2016 21:03 Jeremy Stretch notifications@github.com ha
scritto:

Closed #465 https://github.com/digitalocean/netbox/issues/465.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/digitalocean/netbox/issues/465#event-754397730, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEMcD1SQgCnblZ67SruUTWUJW8ErzWFcks5qfMN8gaJpZM4JjWZT
.

@rgstori commented on GitHub (Aug 13, 2016): The difference between them is indeed very clear to me, I've simply defined some prefixes as container subnets and now I'm filling them with single IP addresses. My point is another: currently, there is no way to fill the IP addresses space inside a prefix other than creating many single IPs. For instance, I have created a /24 container prefix for some LB VIPs. Most tenants only need a couple /32 vips, but one needs 30 of them: so I reserved a /27 subnet for it, for the sake of readable routing. In order to keep things tidy, I'm not very happy to create 30 ip address objects, I just want to fill that /27 space inside the /24. At first, I created a 'reserved' /27 child prefix inside the /24. But all of the ip addresses of the /24 still showed up as available. Then I created a /27 IP address object belonging to the /24 prefix, but that occupied 1 IP only, not 32. This was because I thought that the mask you write down when creating the IP object represented the size of the object itself, not the mask of the subnet it belongs to! What I don't understand, then, is the purpose of the mask for the ip address object: either it has the same meaning of the mask of its related prefix, making it somewhat redundant, or maybe it has some other purpose? The subnet mask of my devices is always the same across the whole L2 segment, why can I choose to assign different masks to IPs belonging to the same subnet with the same mask? I shouldn't be given that possibility! I know addresses and prefixes are separate objects but since netbox correlates the two, the mask should be a property of the prefix, not of the IP address. Sorry for the long post, to sum it up: 1) there should be a way to occupy more space than one IP at a time in the IP addresses tables, preferably with the creation of "full" prefixes. 2) there is some redundancy between the masks of the prefix objects and the masks of the IP address objects. Il ven 12 ago 2016 21:03 Jeremy Stretch notifications@github.com ha scritto: > Closed #465 https://github.com/digitalocean/netbox/issues/465. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > https://github.com/digitalocean/netbox/issues/465#event-754397730, or mute > the thread > https://github.com/notifications/unsubscribe-auth/AEMcD1SQgCnblZ67SruUTWUJW8ErzWFcks5qfMN8gaJpZM4JjWZT > .
Author
Owner

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

Each IP is an independent object. It wouldn't make sense for one object to represent multiple IPs. It's trivial to import IPs in bulk, and there's another feature request open to allow bulk creation of IPs using range expansion (similar to interfaces).

IP addresses include their prefix length because it's part of the address. You can't configure an IP on an interface without also specifying it's mask, so we make sure to track that data in NetBox as well. You also can't assume that an IP will inherit the prefix length of its parent prefix. For example, you might create a /24 container full of /32 IPs for loopback interfaces.

@jeremystretch commented on GitHub (Aug 13, 2016): Each IP is an independent object. It wouldn't make sense for one object to represent multiple IPs. It's trivial to import IPs in bulk, and there's another feature request open to allow bulk creation of IPs using range expansion (similar to interfaces). IP addresses include their prefix length because it's part of the address. You can't configure an IP on an interface without also specifying it's mask, so we make sure to track that data in NetBox as well. You also can't assume that an IP will inherit the prefix length of its parent prefix. For example, you might create a /24 container full of /32 IPs for loopback interfaces.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#360