Environment
NetBox version: 2.5.13
Proposed Functionality
Add Split and Merge to prefixes.
Split will split a single network into two networks.
Merge will merge two networks with similar subnet mask to a single bigger network.
Use Case
Will help dynamic organization when allocating IP ranges to new networks to directly split/merge based on size.
Database Changes
none
External Dependencies
none
Splitting seems pretty straightforward, but merging would require NetBox to make assumptions it should not be making. For instance, when merging prefix A and B, where each prefix has a different role, description, tags, etc. assigned, which should take precedence? IMO the safe option is to require the user to delete the higher prefix(es) and update the prefix length on the lower prefix.
A check can be made that the two Sub-nets merged must have the same properties and/or Subnet-mask to be able to merge. Else, it would not allow the operation.
This is very useful when managing high number of dynamically created and deleted environments with the same network properties but different network size.
Deleting the smaller prefixes and creating a new, larger one in their place is trivial and won't disrupt any related objects.
For example: if we have multiple successive free /27 ranges and we need to create a /24. The tool would do the calculation and merge ranges until we have the needed size. Doing this manually is time consuming and prone to error.
There's no need for anything more complex.
Leaving this open if someone wants to volunteer to work on it. Otherwise, it will be closed after a month of inactivity.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.
This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
Most helpful comment
There's no need for anything more complex.