Ability to change address space
Currently, if I'm planning a segment and I find out it is "too small", there is no way to expand it. Ideally, there would be a way to add space without redoing all of the existing segments. For example, changing from an overall /21 space to /20
Although I have not encountered it, shrinking the overall address space may also be useful, with the understanding that notes on a removed section would be lost.
Finally, the ability to "shift" address space without losing everything may be useful. (e.g. 10.0.0.0/22 -> 10.0.4.0/22). I've had one occurrence where a typo in the initial address space forced me to redo my layout from start.
#7 could (perhaps) lesson this need as these changes would be possible through manual JSON edits. Depending on JSON layout, that may be easy or hard, though.
The current JSON layout is full subnet CIDRs as JSON keys. Converting from 10.0.0.0/16 to 10.1.0.0/16 is easy, but it's less easy going from 10.35.0.128/25 to 10.36.0.0/25 when doing text manipulation.
My next iteration of the save format is probably going to switch from a bunch of CIDRs in the JSON to one top level CIDR and then every other key is an offset+size combination from that top level CIDR. This would make your request to move the range but keep the same size trivial. Expanding would also be trivial. Shrinking would be harder since you have to determine which networks to drop. It would also have the added benefit of saves being smaller. So I may need to switch to three modes of storing the data: human readable JSON, import/export JSON, and compressed-then-URL-encoded JSON.
But it's a good request and probably will be part of my next major phase of work on this tool.
@crussell52 - By the way, did you find this site through a recent newsletter or blog or something? I've seen in the web logs a large uptick in traffic in the past week. A bunch of request URLs indicate the traffic is driven by emails from via some WordPress plugin that sends out newsletters. But I can't figure out who sent it out.
@crussell52 - By the way, did you find this site through a recent newsletter or blog or something? I've seen in the web logs a large uptick in traffic in the past week. A bunch of request URLs indicate the traffic is driven by emails from via some WordPress plugin that sends out newsletters. But I can't figure out who sent it out.
No... I actually had a need and googled some keywords having thought I saw mention of a visual tool several months ago. No idea if this was the one mentioned or not. I think this was the 3rd tool that I clicked through to, and stopped looking after that 👏
I'm exceptionally time-strapped at the moment, but I could imagine contributing to this project in some way beyond tickets in the future. I hope the new publicity (wherever it is coming from) brings you some contributors as well as users.
Thanks, and suggestions/issues are a great way to contribute, keep em coming.
Regarding the feature... I think the more you can do visually, the better... especially if it saves you from having to manage additional formats in the code. UI/UX is far from my strongsuit, but I imagine expansion as a visual widening. Like a (+) to the right side of the table.
With contraction, I think you are limited to either removing the top half or the bottom half of the range. So given the following random layout, I'd have to select one of ~~those two~~ the two /17 segments to drop.
See attached screen of random layout with crudely drawn +/- 💪
Alternatively, the user could select Any segment to become the ONLY segment. But that might be harder to represent intuitively.
footnotes:
- my least favorite part of contraction through click is that it creates a 3rd click context as opposed to just split/join.
- In the context of #7 (e.g, storing JSON in Git) a "human readable" format is better than offsets because diffs would be more useful.
I did some brainstorming today and I can't think of a more efficient way than this. I'll work on a prototype soon, but here are my notes... Effectively storing 10.0.0.0/8 and then just the value 54 instead of 10.0.0.64/28.
I'm thinking about a coordinate system. Let's say you have a base network of 10.0.0.0/8 and you want to as concisely as possible represent 10.166.64.0/20. We could represent this as the nth /20 within the /8 and just store N-20, and probably shorten that even more with the last digit always being base32 for the mask.
If I'm doing my math right you can say a /20 has 4096 addresses.
10.0.0.0 = 167772160 10.166.64.0 = 178667520 178667520 - 167772160 = 10895360 10895360 / 4096 = 2660 Which means 10.166.64.0 is the 2,660th /20 within the /8. You could store this as 2660x20 (inefficient)
You can reverse this 2660x20 from 10.0.0.0/8 by doing the following: a /21 has 4096 addresses, times the 2660th network is 10895360. Add that to the base network address to get the network
10.0.0.0 = 167772160 167772160 + 10895360 = 178667520 178667520 = 10.166.64.0 then you can tack back on the /20
This has the advantage overall that you're unlikely to store wildly different subnet sizes in the same page. Your "N" in the "Nth" subnet is likely to be very small. You're more likely to store the Nth /24 in a /20 than you are a /20 in an /8. So the numbers will mostly be 1-2 digits, rarely 3 digits, and almost never 4 digits as depicted above.
I then for efficienty I could use this format:
[Nth Network as Integer][Network Size as Base32]So lets say you're wanting to represent the 0th /24 in a /20 you would represent it as
00, always knowing the last digit is the network size. Or the 0th /32 would be07(32 in base32 is 7). or the 5th /28 would be54
I've got the more efficient save methodology working on the feature/efficient-saves branch. This is 90% of the way to implementing the "change address range" functionality. Basically I should be able to just switch the base network and as long as the the network size stays the same (and is valid) all of the other values are calculated off of that base network value. Hope to have this out by the end of the week.
This feature set is complete, I just want to do some more in-depth testing this evening and will release first thing in the morning.
With the unexpected number of community contributions (awesome community engagement!) I think I need a UI-based testing strategy.
This is closed in v1.3.0!
Interested to know how to use this. Also, I know the tool is pretty much self-explanatory, but are there general usage docs anywhere? Thanks