IP Address availability when child subnets are defined

[eptiliom]

Im sure this has been asked before but I cant find it.

When I setup /30 child prefixes under a /24, the address list of the /24 shows the network and broadcast addresses as available. I tried setting the pool and utilization flags and that made no difference.

Is there some way I am missing to filter those addresses out for child prefixes on the parent or is that the way it is?

[mtinberg]

Am I misunderstanding, if the /24 is a container, say 192.0.2.0/24 and contains a prefix 192.0.2.0/30, 192.0.2.4/30, etc. are you saying that it's still showing 192.0.2.0/32 as being a network address for 192.0.2.0/24 instead of allocated to 192.0.2.0/30? — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: eptiliom ***@***.***> Sent: Wednesday, December 1, 2021 2:01 PM To: netbox-community/netbox ***@***.***> Cc: Subscribed ***@***.***> Subject: [netbox-community/netbox] IP Address availability when child subnets are defined (Discussion #7959) Im sure this has been asked before but I cant find it. When I setup /30 child prefixes under a /24, the address list of the /24 shows the network and broadcast addresses as available. I tried setting the pool and utilization flags and that made no difference. Is there some way I am missing to filter those addresses out for child prefixes on the parent or is that the way it is? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#7959>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM5LQUCA7JNNDLBZSX3UOZ5JHANCNFSM5JFLHVQA>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[eptiliom]

I suspect I would have to turn on the pool flag on the /30s and then fill out the network and broadcast addresses manually. #3247 kind of points me in that direction but it isnt quite the same.

[candlerb]

I think there's a good argument that the "child IP addresses" view under a Prefix should block out all IP addresses within a child prefix - or show only a placeholder for a child prefix.

But I guess some people will find it useful to see all addresses linearly under a container prefix. In that case, I think you're right that the network and broadcast addresses of a non-pool child prefix should not be shown as "available".

[eptiliom]

This may not be a great example but for whatever reason this /24 was used for both /30 point to point networks and /32 loopbacks. So there is a smattering of each in it and is a little unclear as to what is going on.

They shouldn't have been mixed but it would be a lot of work to undo it now.

[DanSheps]

So here is the issue you are running into...

When you are looking at child ips under a parent container (10.0.1.0/24), you are seeing the child IP's from the prespective of that container.

So, while you might have a child prefix at 10.0.1.88/30, that has a network address of 10.0.1.88 and a broadcast of 10.0.1.91, from the prepective of the 10.0.1.0/24 those are available IP addresses.

I suppose an argument should be made that those are labelled as network and broadcast, however keep this in mind:

In order to determine if those IPs should be shown as a network and broadcast address, a query would need to be made to each child prefix to get the network and broadcast address.

Then you also have the added complexity of this design:

• 10.0.1.0/24
  • 10.0.1.0/29
    • 10.0.1.0/31
    • 10.0.1.2/31
    • 10.0.1.4/31
    • 10.0.1.6/31

With that, the "network" and "broadcast" of the /29 are actually perfectly usable if you are using it to denote a container that contains the /31 and within the /31 both 10.0.1.0/31 as a IP and 10.0.1.7/31 as an IP are both valid.

In short, the logic gets messy and complex and I don't think it is something we want to mess with right now.

[eptiliom]

Fair enough and that is what I figured. I can solve it by just making them pools anyway if I find that it is completely necessary. Thank you for the feedback.