IP filtering - is it temporary or permanent

Let’s say I have two ISPs and run a node on each ISP. If one line fails I can temporarily put both nodes on the remaining line to maintain uptime, but now they will share the IP. When the failed line comes back, I put each not on its separate IP.

The question is will the IP filtering notice that my two nodes shared an IP for a while and mark them as “one node” permanently or only as long as they share the IP?

1 Like

There is no marking at all. When the satellite selects nodes it select random one from each /24 subnet of public IPs. If your node is unvetted it will be selected in 5% of cases.

5 Likes

and it takes like 4 hours i think for the network to register it… like say if you had two nodes on your subnet and turned one off, then it will take 4 hours until the ingress will double at the second one, because the nodes are tracked on 4 hour checkin before they are considered offline… or online i guess

so the same will apply in your example.

Can you prove this with code?
I do not see such section either.

I did try that a few months ago, it always took 4 hours until a node was considered offline and the remaining nodes on the subnet got the ingress.
Not sure where in the code you can find it or whether it changed in the meantime.

2 Likes

think littleskunk explained it when kevink was testing something with putting offline some his nodes while monitoring his traffic, and the results was weird…

i remembered it because it was relevant to my plans for running multiple nodes, and thus didn’t want it to confuse me in the future.

looked for the post, can’t find it and i really don’t want to spend a ton of time trying to prove something to one storj employee that another said, but it would seem to be that there might be a lack for some sort of map like overview of the features and reactions of the system, so that people can more easily see how the system should behave in certain cases.

anyways i think it was littleskunk that explained it about the 4 hour adjustment time of the network / time before a node is considered offline and thus the data flow of the network adjusts.

but yeah i got no clue just regurgitating what i think i’ve been told by reliable sources.

The difference here is probably offline vs changed IP. I would assume that once a node checks in with the new IP it will be updated instantly.

i don’t doubt that the ip change isn’t recorded instantly… but would still follow the 4hour schedule before its registered as being online to the satellites… but that’s mostly for data allocation and uptime monitoring i believe or something like that…

so not critically relevant when one changes the ip, because loosing 4hours maybe … isn’t really a big deal… and essentially if the storagenode wasn’t offline for like 4 hours then it wouldn’t be counted as offline to begin with, and thus shouldn’t loose any time at all…

if it was offline for 4hours then it would be counted as offline and would then take an additional time of 4 hours being online “most of the time” to be counted as online…

but yeah the nitty gritty details i’m not totally informed on… but thats how i understand it’s suppose to work.

ofc not totally sure of what path the behavior would take in regard to the jumping from 2 nodes on 2 ip’s to 2 nodes on 1 ip… or the reverse…

that’s probably right since there is only one record for a storagenode id so it can either be online or offline.

there’s no such thing as “online delay”.

in theory yes, but from a data ingress perspective there is… but i suppose that’s not very relevant, unless if one is actively tracking it and wondering why the node is online, but doesn’t seem to get the same share of the data as the other nodes…

there is not. every node that is online gets the full traffic. there is no delay where the node is online but gets no or less traffic.

This is completely incorrect.

When a node restarts, it checks in with the satellites and updates it’s address as well. The only delay for getting traffic is the maximum 3 minutes it takes for the node selection cache on the satellites to update.
It’s different when a node goes offline, it doesn’t check out and the satellites only mark a node offline after 4 hours. But that’s the only place the 4 hours applies.

wasn’t aware of that it only factored in when going offline, but i suppose i should have deduced that…

@ general topic
still something to be aware of if one is playing around with multiple nodes and wonders why traffic doesn’t react in a expected timely manner.
even tho not strictly related to ip filtering and more the behavior of data ingress in general, which is sort of related. imho