search

slackhq / nebula

A scalable overlay networking tool with a focus on performance, simplicity and security
MIT License
14.44k stars 975 forks source link

[Feature Request] Auto-switch destination IP of tunnel based on dynamic latency detection #132

Closed KazamaSion closed 4 years ago

KazamaSion commented 4 years ago

This feature is referring to here. Scenario: A host has 3 IPs: one is fast in the morning, one is fast in the afternoon, one is fast at night.

At present, once the tunnel established, the destination IP won't change except that the connection is unavailable(or there's no data transmission for a long time?).

I tried to configure like below before:

static_host_map:
  "192.168.83.2": ["ip1:port", "ip2:port", "ip3:port"]
lighthouse:
  am_lighthouse: true

Then I did these:

  1. Nebula secured the tunnel via ip3: I tried to block connection to ip3 by the firewall, and after some time, the connection reestablished by one of the other IPs.
  2. At this moment, I reset the firewall's config, and the connection can be recovered. Nebula didn't choose to re-establish the connection via ip3.
  3. I reconfigured the Nebula config by changing the IPs to local IPs while using port forwarding to designate 3 local ports(like 127.0.0.1:port) to 3 IP's respectively. After Nebula choose 1 port to establish the connection, I exchanged that one's destination IP with another one's. And, obviously, Nebula still connected to the same port as the one it chose before.

After did those, I considered this was the feature for now: no dynamic latency detection, no auto-switch.

rawdigits commented 4 years ago

Nebula can prefer certain network routes based on local_range, and will periodically try to reestablish a connection via local_range as traffic passes. There is no functionality to detect the "quality" of various connections at present, and it would require quite a lot of work to do so. It is also fraught with edge cases in something like an overlay network, where multiple hosts making independent decisions may stampede to a different link, only to saturate that link and stampede back to the other one, ad infinitum.

We may explore this if there is additional demand for such a feature, but for now we don't have any plans to support dynamic path decisions (aside from failover, which does exist) directly within nebula.

KazamaSion commented 4 years ago

I see, thx for your interest and reply. Close the issue if you want.

rawdigits commented 4 years ago

Closing for now, but I am certainly personally interested in this feature. Just no time at the moment.