You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Most of our internal/private stacks nodes have outbound neighbors reachable on a public IP range, and maybe only one or two in a private IP range.
So most of our stacks nodes are trying to communicate with nodes external to our cluster, rather than a balanced mix between public nodes and private nodes.
From the perspective of a public node, this may be problematic when a myriad of stacks nodes behind a NAT with a single IP are trying to stay connected to it, even if each node has a unique local peer seed/public key.
I’m guessing if this happens, then the private stacks nodes may lose their external neighbors and can fall behind.
This is exactly what I'm seeing happen for many private nodes from time to time.
Ideally there would be a way to configure this behavior. Node operators might want their node to favor different neighbor strategies depending on their infra setup.
For example, node operators might prefer to configure their private stacks nodes to favor private IP ranges while publicly accessible nodes like seeds favor external IP ranges.
The default strategy (favoring public IPs) could be how neighbors are selected today, while new strategies could be supported, such as balanced (closer to 50% public/ 50% private), favor_private, only_private, and only_public.
The text was updated successfully, but these errors were encountered:
Most of our internal/private stacks nodes have outbound neighbors reachable on a public IP range, and maybe only one or two in a private IP range.
So most of our stacks nodes are trying to communicate with nodes external to our cluster, rather than a balanced mix between public nodes and private nodes.
From the perspective of a public node, this may be problematic when a myriad of stacks nodes behind a NAT with a single IP are trying to stay connected to it, even if each node has a unique local peer seed/public key.
I’m guessing if this happens, then the private stacks nodes may lose their external neighbors and can fall behind.
This is exactly what I'm seeing happen for many private nodes from time to time.
Ideally there would be a way to configure this behavior. Node operators might want their node to favor different neighbor strategies depending on their infra setup.
For example, node operators might prefer to configure their private stacks nodes to favor private IP ranges while publicly accessible nodes like seeds favor external IP ranges.
The default strategy (favoring public IPs) could be how neighbors are selected today, while new strategies could be supported, such as balanced (closer to 50% public/ 50% private), favor_private, only_private, and only_public.
The text was updated successfully, but these errors were encountered: