Hi, On Mon, Jun 02, 2025 at 11:35:24PM +0200, Piotr Strzyzewski wrote:
It is not. I actually tested it using a random /24 in the TEST database. First, I created a /24 inetnum object with the ALLOCATED PA status, and then 255 inetnum objects with the SUB-ALLOCATED PA status - ranging from 192.0.2.0 - 192.0.2.254 down to 192.0.2.0 - 192.0.2.0. As a side note, the last one doesn't make much sense, since it's not possible to create any smaller inetnum object with ASSIGNED PA status.
That is not surprising - but I was talking "depth", not "breadth".
Same here. I was talking "depth" as well.
So the maximum depth of nesting in a /24 is 8, then you hit /32, and
My observation is that it was 1 allocation having 255 sub-allocations nested one in another. Like 192.0.2.0 - 192.0.2.0 nested in 192.0.2.0 - 192.0.2.1 nested in 192.0.2.0 - 192.0.2.2 nested ... in 192.0.2.0 - 192.0.2.254 (last, most outer sub-allocation) nested in 192.0.2.0 - 192.0.2.255 (allocation). So the maximum depth of nesting in a /24 is 255.
No :-) 192.0.2.0/24 192.0.2.0/25 192.0.2.0/26 ... 192.0.2.0/32 ... this is what I called "nesting in depth", and the limit is 8. Filling each level (192.0.2.0/32, 192.0.2.1/32, 192.0.2.2/32, ... .255/32) is what I called "width" - and of course, you can add hundreds of object that way, without mentioning "SUB-ALLOCATED" at all (just tag the /32s as "ASSIGNED"). The former ("limit=8") would be capped by introducing a limit to the nexting level ob sub-allocations. The latter not so much. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279