Fully-managed subnets (xpost from slack)

[slash31]

(cross-posted from Slack for visibility)

Is there any interest in developing a fully-managed subnet allocation system within NetBox? We have a specific use case that we’re starting to write a solution for that works around NetBox, but it seems like something that could be useful for others if it were integrated. I’ll describe the problem first:

We have automation around the dynamic configuration of subnets, specifically for Kubernetes use. Like many orgs, we have issues with IPv4 subnet/address exhaustion (k8s is a hungry animal), exacerbated by the partially-manual management and assignment of address resources. As the dependency on capacity being truly dynamic - e.g. a feature dev “checks out” a block of k8s capacity in devint, writes a service, proves that it works, “returns” that devint capacity, “checks out” capacity to deploy in prod - we’re finding that the lack of efficient, automatic allocation is a bottleneck.

Our idea for a solution is to overlay fully-managed subnets, where we grant a supernet (let’s say a /16) to a team/project/component/etc. and from that point on allocations/de-allocations can only happen via API call. Our current idea is to implement a binary buddy allocator to minimize fragmentation. In our use case, a t-shirt-sizes SKU of capacity would correspond to a specific CIDR.

As I said, we’ve starting to design this as an overlay to NetBox, and I had the idea that maybe it could be integrated into NetBox via a simple “fully-managed” flag; once enabled for a supernet, the only way to create/delete subnets within it would be via API endpoints for “allocate” and “deallocate”, and the code to do the partitioning and coalescing would all be handled within NetBox.

Note: There is another discussion post that sort-of asks about this kind of functionality from Sept 2022 that has zero responses, so it may just be something that few people care about. In this case, maybe our best course of action is to maintain a fork of NetBox that adds nothing but a "locked" flag for parent prefixes that are managed by an external API.

[candlerb]

In this case, maybe our best course of action is to maintain a fork of NetBox that adds nothing but a "locked" flag for parent prefixes that are managed by an external API.

That's almost certainly not your best course of action, as the long term maintenance of the fork will get harder and harder. You can add a custom field to Prefix without forking Netbox, and the rest of your logic can go in a plugin.

[DanSheps]

Could also create a separate model instead of a custom field that has a OnetoOne relationship to Prefix.

[slash31]

Thanks @candlerb for the link to the plugin docs, I'll pass that back to the team as an option. @DanSheps that's my initial though from reading the plugin docs, because at the very least I believe we'd need a separate data model for the list of allocated subnets for each CIDR size.

[carrascodc]

I wanted to humbly say that this feature would be very useful as I'm testing out Netbox right now