Unhelpful 400 error when trying to add-cidr, unclear behavior

[jakintosh]

Hi all,

First—I love this project. It's rare to find something that both feels like magic and is also so simple to see exactly how and why it works. So glad to have an option like this over something like Tailscale.

Anyhow, I'm in the early stages of deploying/figuring out how I want to partition my innernet's CIDRs, and am running into an issue where I'm getting a 400 from the server when trying to add a new CIDR.

Current Network

mynetwork (:xxx)
  10.1.0.0/16 mynetwork
    10.1.0.1/32 innernet-server
    | ◉ 10.1.0.1: innernet-server (xxx…)
    10.1.8.0/24 fleet
    | ◉ 10.1.8.1: a (you, xxx…)
    | ◉ 10.1.8.2: b (xxx…)
    10.1.16.0/24 cloud
    | ◉ 10.1.16.1: c (xxx…)

Goal

What I want to do next, after I started adding machines, is to add a layer of granularity to my cloud block, one for my physical servers that I can see and touch, and another for my virtual servers that I rent from the public cloud. What I'd really like to do is add two CIDRs to 'cloud', a 'physical' 10.1.16.0/25 and a 'virtual' 10.1.16.128/25 block. However, I couldn't figure out if there was a way to "move" an existing peer (in this case 'c') into a child CIDR, even if its IP doesn't change.

Issue

When I try to run either:

sudo innernet add-cidr mynetwork --name physical --cidr '10.1.16.0/25' --parent 'cloud' --yes

or

sudo innernet add-cidr mynetwork --name virtual --cidr '10.1.16.128/25' --parent 'cloud' --yes

I get

[E] http://10.1.0.1:51820/v1/admin/cidrs: status code 400

I feel like I'm getting bitten by the immutability of the network, even though I'm not technically trying to change any IP addresses.

Is my only option to nuke my config and start over? Presumably, with a little more future planning this time.

Thanks!

[strohel]

Agreed the errors are often unhelpful: the server should propagate them better to the client (patches welcome!). Another example of unhelpful is when adding a peer with a name that already exists (even if it is disabled).

About your particular issue: I think it is how you describe it: innernet currently doesn't support moving a peer between CIDRs (not even special cases where its IP wouldn't change - AFAIK). In these situations we disable old peer and create a new peer (renaming the original to something like peername-old first to free up the name).

But, when creating a CIDR, I think innernet shows that none existing peers (including disabled ones I fear) overlap it. So I fear you're out of luck until/unless innernet supports deleting peers. Actually another option is editing the sqlite database of the server, it's pretty straightforward (but one can of course mess up).

[jakintosh]

Thanks for the reply! Sounds like my gut was correct on the issue I was having. I've been digging into the codebase, and maybe I can see if I can put together a patch on propagating the error messages :)

This may be off topic for the issue, but it leads me towards a higher level intended-use question: is the idea that, with the immutability, you're expected to go into setting up an innernet CIDR-tree with a single design pre-planned and implemented at set up time, and that it won't really be changed after initialization?

[strohel]

is the idea that, with the immutability, you're expected to go into setting up an innernet CIDR-tree with a single design pre-planned and implemented at set up time, and that it won't really be changed after initialization?

We regularly add CIDRs to our innernet network; though our basic scheme doesn't change.

Under the current design choice (impossibility to fully delete a peer) some operations are not possible: mainly converting between leaf and non-leaf CIDRs (also depends if/what peers are inside). But many changes are possible, namely adding CIDRs at any point in the hierarchy where there is an address space left for them (read: it helps if your initial design is "sparse").

[strohel]

• Cannot delete CIDR after adding peer invite #138 is very similar earlier-reported issue