Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to change address space #15

Closed
crussell52 opened this issue Jul 16, 2024 · 11 comments
Closed

Ability to change address space #15

crussell52 opened this issue Jul 16, 2024 · 11 comments

Comments

@crussell52
Copy link

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.

@crussell52
Copy link
Author

#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.

@ckabalan
Copy link
Owner

ckabalan commented Jul 16, 2024

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.

@ckabalan
Copy link
Owner

@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
Copy link
Author

@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.

@ckabalan
Copy link
Owner

Thanks, and suggestions/issues are a great way to contribute, keep em coming.

@crussell52
Copy link
Author

crussell52 commented Jul 16, 2024

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 +/- 💪

image

Alternatively, the user could select Any segment to become the ONLY segment. But that might be harder to represent intuitively.

footnotes:

@ckabalan
Copy link
Owner

ckabalan commented Aug 16, 2024

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 be 07 (32 in base32 is 7). or the 5th /28 would be 54

@ckabalan
Copy link
Owner

ckabalan commented Oct 8, 2024

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.

@ckabalan
Copy link
Owner

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.

@ckabalan
Copy link
Owner

This is closed in v1.3.0!

@ahmgithubahm
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants