Atlas anchors as ping targets
Hi, I have a question about using Atlas anchors for a special purpose. Is the following acceptable, or would people have objections to the following idea? TL;DR: Is it OK to use Atlas anchors as random ping targets? Over in IETF-land we are (again) debating how to make IPv6 multi-provider multihoming work properly. There's a scenario description and picture at https://github.com/becarpenter/book6/blob/main/6.%20Management%20and%20Opera... One unsolved problem is that if one provider fails, many client applications may continue to use a source address belonging to that provider, instead of switching to a source address belonging to the other provider. One approach to solving this without any changes except in the host is to magically deprecate failing source addresses until they work again. One approach to that is a pure hack - a program that runs in the background pinging a remote target from various source addresses, to deprecate and undeprecate them as appropriate. There's code at https://github.com/becarpenter/misc/blob/main/deprecator.py. This is experimental software that might disturb network access. Would it be OK to choose the probe target by picking an Atlas anchor at random? (I have running code for that, but will not post it to github if there are objections.) I am quite sure that this code is only of interest to a few IPv6 geeks. It could of course be instrumented for measurement purposes, but multihomed sites of this kind are so rare that I don't think there would be much to measure. Regards Brian Carpenter
Hi, On 2023-01-28 02:24, Brian E Carpenter wrote:
TL;DR: Is it OK to use Atlas anchors as random ping targets?
RIPE Atlas anchors are known and willing targets for measurements - so I'd say yes, definitely!
Would it be OK to choose the probe target by picking an Atlas anchor at random? (I have running code for that, but will not post it to github if there are objections.)
The anchors are in a full measurement mesh - meaning they ping and trace each other. Also, all anchors are assigned some probes to measure them. You can find these measurements on the anchors' pages. This may mean you don't need to set up new measurements. If so, it's always nicer to reuse existing data :-) Regards, Robert
Hi, On Mon, Jan 30, 2023 at 01:08:25PM +0100, Robert Kisteleki wrote:
Would it be OK to choose the probe target by picking an Atlas anchor at random? (I have running code for that, but will not post it to github if there are objections.)
The anchors are in a full measurement mesh - meaning they ping and trace each other. Also, all anchors are assigned some probes to measure them. You can find these measurements on the anchors' pages.
This may mean you don't need to set up new measurements. If so, it's always nicer to reuse existing data :-)
The idea here is - I have a host in a "home network" that has 2 ISPs, with a global IPv6 address from each of them - one of the ISPs fails, but the host does not know, and keeps using the "broken" IPv6 source address - by cyclic measurements, Brian's tool will see "nah, that address stopped working" and will de-preference it on the host -> host starts using the other IPv6 source address -> connectivity restored (over the other ISP) and the test envisioned would be "ping something willing to be pinged" :-) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
The idea here is
- I have a host in a "home network" that has 2 ISPs, with a global IPv6 address from each of them
- one of the ISPs fails, but the host does not know, and keeps using the "broken" IPv6 source address
- by cyclic measurements, Brian's tool will see "nah, that address stopped working" and will de-preference it on the host -> host starts using the other IPv6 source address -> connectivity restored (over the other ISP)
and the test envisioned would be "ping something willing to be pinged" :-)
Yes that's fine, there could be $reasons to do more measurements! :) Cheers, Robert
On 31-Jan-23 01:15, Robert Kisteleki wrote:
The idea here is
- I have a host in a "home network" that has 2 ISPs, with a global IPv6 address from each of them
- one of the ISPs fails, but the host does not know, and keeps using the "broken" IPv6 source address
- by cyclic measurements, Brian's tool will see "nah, that address stopped working" and will de-preference it on the host -> host starts using the other IPv6 source address -> connectivity restored (over the other ISP)
and the test envisioned would be "ping something willing to be pinged" :-)
Yes that's fine, there could be $reasons to do more measurements! :)
Thanks. And Gert's summary is just perfect. It may be a day or two for personal reasons, but I will post my code to github after a few more tweaks. Brian Carpenter
participants (3)
-
Brian E Carpenter -
Gert Doering -
Robert Kisteleki