Re: [atlas] Atlas anchors as ping targets

2023-01-30 Thread Brian E Carpenter

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

--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas


Re: [atlas] Atlas anchors as ping targets

2023-01-30 Thread Robert Kisteleki

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

--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas


Re: [atlas] Atlas anchors as ping targets

2023-01-30 Thread Gert Doering
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 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature
-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas


Re: [atlas] Atlas anchors as ping targets

2023-01-30 Thread Robert Kisteleki

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

--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas


[atlas] Atlas anchors as ping targets

2023-01-27 Thread Brian E Carpenter

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%20Operations/Multi-prefix%20operation.md

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

--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas