Different ISPs for IPv4 and IPv6

[alexey-yarmosh]

in theory a probe can have IPv4 and IPv6 from different ISPs. So:

1. Probe connects with e.g. IPv4.
2. We assing asn_001 to it.
3. Also probe reports that it supports IPv6 (it may even be a VPN, since only a ping is used to test that).
4. Now we have an asn_001 in IPv6 network (which is actually a VPN).

Possible solution:
Since we are collecting alt IPs, in the example above we can validate the incoming IPv6 alt IP.
If it is missing or blacklisted => probe doesn't support IPv6.
If it is same ASN => probe supports both versions.
If it is different ASN => we a creating a "virtual probe" with the new ASN data (so it can be filtered by user). So from UI it looks like 2 probes, which support only IPv4 and only IPv6 respectively.

[MartinKolarik]

Traditional VPNs or other stuff we're blocking shouldn't be a problem since we do a lookup on all alt IPs too, including the regular checks, so a VPN would throw an error and cause the IP to be ignored.

Also, different ASNs or network names are not a problem on their own. Most often, the IPv4 and IPv6 addresses are registered by different entities, but are still connected. For example, CacheFly owns its own IPv4 space, but uses EDGEUNO for IPv6. If someone asks, "How fast is CacheFly via IPv6?" we'll still give a correct answer, but if we separated the probes, it would seem like CacheFly has no IPv6 connectivity, which is not good.

The one problem we discussed with @jimaek at the beginning is tunneling services (most often Hurricane Electric), which are similar to VPNs. The problem there is that the packets are routed through a different location, which affects timings. Theoretically, these might be possible to detect, e.g., via traceroute, but we decided to skip that for the time being. However, most of these cases got resolved with #576 (ignoring the IP if countries don't match).

Looking at the probes now, there are a few more cases where Hurricane Electric is used (on probes in the same country). We could maybe add a rule that if IPv4 is not HE, and IPv6 is, then IPv6 is ignored. But I wouldn't do anything in other mismatch cases.

[alexey-yarmosh]

Traditional VPNs or other stuff we're blocking shouldn't be a problem since we do a lookup on all alt IPs too, including the regular checks, so a VPN would throw an error and cause the IP to be ignored.

The problem is that isIPv4Supported/isIPv6Supported depends only on a successful ping request from the probe. altIps are not affecting it and are only stored so the user can adopt by them. So adding something like isIPv6Supported = true only if "probe successfully pinged" && there is IPv6 IP or alt IP makes sense.

[MartinKolarik]

altIps are not affecting it and are only stored so the user can adopt by them. So adding something like isIPv6Supported = true only if "probe successfully pinged" && there is IPv6 IP or alt IP makes sense.

That's a good point indeed. Right now, it would affect 57 probes, though, which seems like too many. We'll have to recheck #601
first to make sure there are no problems with alt IPs handling.

[MartinKolarik]

So adding something like isIPv6Supported = true only if "probe successfully pinged" && there is IPv6 IP or alt IP makes sense.

The problem with this is that the alt IP mechanism would become a de facto second QA test (in addition to the current ping tests), but it is not built for that at the moment:

• the server may (very occasionally) drop the alt IP requests due to high load or node restarting,
• the probes only perform one retry in case of errors,
• even if we improved the previous points, the probe's secondary connection may be down temporarily (even for an hour or more) and start to work later. The QA tests run periodically and handle that, but the alt IP handling only runs once, which means we'd block probes that start to work later after connecting.

I think it still makes sense, but we'll have to rework the alt IP reporting first, otherwise this will break more probes than it fixes.

[MartinKolarik]

The problem with this is that the alt IP mechanism would become a de facto second QA test (in addition to the current ping tests), but it is not built for that at the moment:

Indeed, this seems like a good idea, since originally, the actual requirements for the probe to be available were:

• successful in making HTTP requests (to connect to the API),
• successful QA ping tests.

Now with the alt IPs, we require the ping tests, but don't test the HTTP functionality, and in some cases, it doesn't actually work. The alt IP reporting mechanism would work well as an additional test if we run it on schedule, and then it would also solve the original issue reported here.