Same IP vs same /24 subnet

I wonder if there is any difference if two nodes sharing the same IP or just sharing the /24 subnet? Does it matter in terms if ingress/egress or not?

They’re treated the same… because in both scenarios they’re two nodes with separate Identities… in the same /24. The only difference would be if one of them was vetted and the other wasn’t or something (as they’re part of different traffic pools).

3 Likes

This sounds reasonable. But there is something that makes me curious…

I have 2 nodes behind the same IP. So far their ingress was half compared to other nodes which are alone in a subnet. This is obviously in line with your explanation.

Now one of those 2 nodes is full but ingress is still only half. My expectation was to get the full ingress for one subnet now.

Is this by design or is it another bug?

Hi, the full node is complete from hours or days? After a node becomes full you must wait at least 24/48 hours before it is reported full to the satellite and then it is considered a single node for entry into that subnet. however, consider that it will never be perfectly because in any case the full node will have cancellations and will therefore start receiving inputs again.

Even if one node is full, garbage is often generated and the reception is received again by the first node, so it seems that the second node cannot fully receive the entire reception.

You can’t predict current customer behaviour from the past.

This is not about predicting something from the past. I am just comparing nodes day by day. Right now the node in the shared subnet showing 22 GB ingress for today while other nodes have 44 GB. And I am observing this for some weeks now.

However, the nodes I call “full” never having exactly zero ingress. There is always a very small number of ingress over a 24 hour period. This might be the reason why nodes are never considered as full by satellites.

So the best way to deal with this problem as a SNO is probably moving all nodes to a single IP once they are full and using the unique IPs to create new nodes each time.

no sure, remmeber the deleting factor, the node has to refill after each week Garbage Cleaner session, might be hard to keep it full, if You put many nodes on same ip.

I think quite a few SNOs are doing that. Because unique IPs often have a cost they make sure those IPs always host the nodes that are growing. And once they’re full they switch them to use another port on an existing IP (because even shared ingress with other nodes is enough to keep them full and deal with any deletes).

Still takes a long time to fill nodes though: but that’s life!

1 Like

Why bother moving full nodes and overstress about them stopping half of the ingress?
The simplest solution is to reduce the allocated space to 1 TB for ex., for the full nodes. This will stop the ingress to them and redirect the traffic to other nodes.
After a year or 2, if they loose to much data from deletes, you can allocated again the entire space.

Is there really no other consequences of doing so? No forced deletes until the overused space is free?

“Moving” a node in this case isn’t necessarily changing the system it’s on, or even disk. It’s just reconfiguring the IP/port it uses. I see this a lot where a SNO has one node on their primary internet connection (where they usually have full control of as many inbound ports as they want)… and any extra nodes have to use a VPN to get a different IP (and only control a single port).

So when a VPN node fills up they reconfigure it back onto their primary connection on a different port. Then start a new Identity on that free single-VPN-IP/single-VPN-port. No need to change allocated space: it naturally won’t use any ingress except for topping-off deleted garbage.

This is what I had in mind.

1 Like

Satellites don’t force delete stored data just because it’s overallocated.
There’s no other consequences. I used to do this for speeding up the filewalker too. See my tests in Tuning the filewalker.