Selecting only anchors for UDM
Hello list, is there a way to run an UDM on Anchors only? I think it would be a good feature, especially for precise latency measurement. Cheers, Ondřej Caletka
On 11.06.14 12:03 , Ondřej Caletka wrote:
Hello list,
is there a way to run an UDM on Anchors only? I think it would be a good feature, especially for precise latency measurement.
Cheers, Ondřej Caletka
Yes, that would be useful. I have been programming around this using the API to fetch the whole probe list first. I suggest an API extension to select probe types that is exposed in the UI : "probes": [ { "requested": 10, "type": "area", "probetype": "anchor", "value": "WW" } ] This is nicely general. One could later add probetypes like: "hasipv6" and "hardwarev3". If that is too much an extension a la "probes": [ { "requested": 10, "type": "anchor", "value": "WW" } ] would already help. Can we put that on the road-map? Anyone else who would like this in the UI and API? Daniel
On Wed, 11 Jun 2014, Daniel Karrenberg wrote:
Can we put that on the road-map? Anyone else who would like this in the UI and API?
I would sugest to use the probe tags for this. RIPE could give the anchors a tag that can not be selected through the UI, but unfortunately, you can create your own tag as well ;-) Sometimes you would want to measure only with probes that are deployed at the core of networks, and sometimes you would only want edges, i.e. probes installed in peoples homes. The tags could be a nice selection criteria for the type of probes you'd like to use. This all depends on the accuracy of the probe owner selecting the tags though, but some tags like anchor or hasipv6 could be filled automagicaly. Antoin
On 2014.06.11. 13:16, Antoin Verschuren wrote:
On Wed, 11 Jun 2014, Daniel Karrenberg wrote:
Can we put that on the road-map? Anyone else who would like this in the UI and API?
I would sugest to use the probe tags for this. RIPE could give the anchors a tag that can not be selected through the UI, but unfortunately, you can create your own tag as well ;-) Sometimes you would want to measure only with probes that are deployed at the core of networks, and sometimes you would only want edges, i.e. probes installed in peoples homes. The tags could be a nice selection criteria for the type of probes you'd like to use. This all depends on the accuracy of the probe owner selecting the tags though, but some tags like anchor or hasipv6 could be filled automagicaly.
Indeed. We intended probe tagging to cover this and more (home probe or not, etc.) Some of this we can and already do do ourselves, some tagging is up for the hosts. The ultimate goal is to make this available as a filter when selecting probes for measurements. Stay tuned! :-) Cheers, Robert
On 11.06.14 13:16 , Antoin Verschuren wrote:
On Wed, 11 Jun 2014, Daniel Karrenberg wrote:
Can we put that on the road-map? Anyone else who would like this in the UI and API?
I would sugest to use the probe tags for this. RIPE could give the anchors a tag that can not be selected through the UI....
Good suggestion! That is even more general and would work fine for me. If we go down this road I suggest to implement tag selection also wherever it makes sense, such as in the probe list API/UI. Other automatic tags suggested: HASIPV6, HARDWAREVx, IPV6WORKS, ..... Daniel
On Wed, Jun 11, 2014 at 01:16:21PM +0200, Antoin Verschuren <ripe@antoin.nl> wrote a message of 18 lines which said:
some tags like anchor or hasipv6 could be filled automagicaly.
For "hasipv6", it is more complicated than it seems https://labs.ripe.net/Members/stephane_bortzmeyer/how-many-atlas-probes-beli...
On 11.06.14 14:54 , Stephane Bortzmeyer wrote:
On Wed, Jun 11, 2014 at 01:16:21PM +0200, Antoin Verschuren <ripe@antoin.nl> wrote a message of 18 lines which said:
some tags like anchor or hasipv6 could be filled automagicaly.
For "hasipv6", it is more complicated than it seems
Hence IPV6WORKS. ;-)
On Wed, Jun 11, 2014 at 03:44:48PM +0200, Daniel Karrenberg <daniel.karrenberg@ripe.net> wrote a message of 11 lines which said:
Hence IPV6WORKS. ;-)
Set how? Pinging a few Anchors and checking that at least N % answers?
On 11.06.14 15:56 , Stephane Bortzmeyer wrote:
On Wed, Jun 11, 2014 at 03:44:48PM +0200, Daniel Karrenberg <daniel.karrenberg@ripe.net> wrote a message of 11 lines which said:
Hence IPV6WORKS. ;-)
Set how? Pinging a few Anchors and checking that at least N % answers?
That is a very open question and we'd like input about it. My *personal* straw-man for IPV6WORKS would be "At least 3 IPv6 targets pinged successfully in the past 24 hours". IPv6 targets should be high-availability built-in measurement targets such as anchors and root name servers. The number and time interval can be discussed. The problem with this is that one wants to select probes that have a structural local problem while keeping probes that have intermittent and less local problems. In other words: if we exclude too many non-working probes we cannot easily measure real operational problems. Hence I proposed HASIPV6 which could mean that a non-link-local IPv6 address is configured or something similar. The nice thing about tags is that we can have as many we consider useful ... Daniel
Hi, On Wed, Jun 11, 2014 at 04:09:02PM +0200, Daniel Karrenberg wrote:
My *personal* straw-man for IPV6WORKS would be "At least 3 IPv6 targets pinged successfully in the past 24 hours". IPv6 targets should be high-availability built-in measurement targets such as anchors and root name servers. The number and time interval can be discussed.
"works for me". The Internet being what it is, "can reach all of <x>" will most likely never be true for a given probe, whatever <x> is. OTOH for reachability testing, probes that can *not* reach 100% of <x> but at least "some part of <x>" are a much more interesting candidate for testing - because testing when you already know "100%, good" is a bit boring. So, yes, what Daniel proposed. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On 2014.06.11. 15:56, Stephane Bortzmeyer wrote:
On Wed, Jun 11, 2014 at 03:44:48PM +0200, Daniel Karrenberg <daniel.karrenberg@ripe.net> wrote a message of 11 lines which said:
Hence IPV6WORKS. ;-)
Set how? Pinging a few Anchors and checking that at least N % answers?
Daniel is exposing some info about stuff that we're actually working on, but we did not announce it yet :-) but yes, the basic idea is that we'll look at how the probe performed in the last period, and if it had enough success, we'll consider it capable of doing ipv4/ipv4/dns/whatever. Then use this knowledge in the measurement scheduler when users want to use those features. That's a departure from "the probe claims that it can do X so we'll go with that" -- which is the main theme behind Stephane's article. We may even have a switch that controls "use probes that think they can do v6 but it doesn't really work" to check the corner cases. If there's a need for such thing. (Is that operationally useful? Or research only?) Cheers, Robert
Hi, On Wed, Jun 11, 2014 at 11:07:51PM +0200, Robert Kisteleki wrote:
We may even have a switch that controls "use probes that think they can do v6 but it doesn't really work" to check the corner cases. If there's a need for such thing. (Is that operationally useful? Or research only?)
Can you see probes that claim to have working IPv4, but haven't? AKA: is your controller infrastructure reachable over IPv6, and will the probes use it? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On 2014.06.11. 23:10, Gert Doering wrote:
Hi,
On Wed, Jun 11, 2014 at 11:07:51PM +0200, Robert Kisteleki wrote:
We may even have a switch that controls "use probes that think they can do v6 but it doesn't really work" to check the corner cases. If there's a need for such thing. (Is that operationally useful? Or research only?)
Can you see probes that claim to have working IPv4, but haven't?
With enough probes/locations, we can see many kinds of corner cases. I'm sure we have probes in this condition...
AKA: is your controller infrastructure reachable over IPv6, and will the probes use it?
Short version: yes, all of our infrastructure is fully dual stack, without exceptions. The trick that we have to apply is how to reliably know if the probe can actually use IPv6 and/or IPv4. For this, we'll use results of real life measurements. Robert
Am 11.06.2014 15:44, schrieb Daniel Karrenberg:
On 11.06.14 14:54 , Stephane Bortzmeyer wrote:
On Wed, Jun 11, 2014 at 01:16:21PM +0200, Antoin Verschuren <ripe@antoin.nl> wrote a message of 18 lines which said:
some tags like anchor or hasipv6 could be filled automagicaly. For "hasipv6", it is more complicated than it seems
Hence IPV6WORKS. ;-) Actually I never would want to make any IPv6 test from a probe which does not have the IPV6WORKS tag. Thus, probes which are known to knot work, should never be selected for measurements.
regards Klaus
Hi, On Wed, Jun 11, 2014 at 05:39:02PM +0200, Klaus Darilion wrote:
Actually I never would want to make any IPv6 test from a probe which does not have the IPV6WORKS tag. Thus, probes which are known to knot work, should never be selected for measurements.
Now what is that you want to measure? If I'm out to measure how well IPv6 works in practice, I'm actually more interested in probes that have *some* IPv6 reachability - or maybe even just "have a global IPv6 address" - than probes where I already know that they can reach everybody just fine... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On Jun 11, 2014, at 11:39 AM, Klaus Darilion <klaus.mailinglists@pernau.at> wrote:
Am 11.06.2014 15:44, schrieb Daniel Karrenberg:
On 11.06.14 14:54 , Stephane Bortzmeyer wrote:
On Wed, Jun 11, 2014 at 01:16:21PM +0200, Antoin Verschuren <ripe@antoin.nl> wrote a message of 18 lines which said:
some tags like anchor or hasipv6 could be filled automagicaly. For "hasipv6", it is more complicated than it seems
Hence IPV6WORKS. ;-) Actually I never would want to make any IPv6 test from a probe which does not have the IPV6WORKS tag. Thus, probes which are known to knot work, should never be selected for measurements.
I “generally” agree with this. “IPv6-works” is defined as can contact greater than 50% of atlas anchors. (I’m surprised at how little traffic my anchors see). - Jared
I currently have a case open where two of my probes on IPv6 networks have no IPv6 address. I was thinking I might reboot them or force an address probe but can't see an obvious way to do that remotely. Ironically, my one probe that reports IPv6 capability has only a ULA address :-/ On Wed, Jun 11, 2014 at 3:59 PM, Jared Mauch <jared@puck.nether.net> wrote:
On Jun 11, 2014, at 11:39 AM, Klaus Darilion <klaus.mailinglists@pernau.at> wrote:
Am 11.06.2014 15:44, schrieb Daniel Karrenberg:
On 11.06.14 14:54 , Stephane Bortzmeyer wrote:
On Wed, Jun 11, 2014 at 01:16:21PM +0200, Antoin Verschuren <ripe@antoin.nl> wrote a message of 18 lines which said:
some tags like anchor or hasipv6 could be filled automagicaly. For "hasipv6", it is more complicated than it seems
Hence IPV6WORKS. ;-) Actually I never would want to make any IPv6 test from a probe which does not have the IPV6WORKS tag. Thus, probes which are known to knot work, should never be selected for measurements.
I “generally” agree with this. “IPv6-works” is defined as can contact greater than 50% of atlas anchors. (I’m surprised at how little traffic my anchors see).
- Jared
(Epilogue: User error - my router stopped handing out IPv6 addresses (curse you, Linksys E4200 v1)) Thanks to Robert K. for rebooting my units. I still need to get to the other site and find out why the IPv6 is failing. On Thu, Jun 12, 2014 at 8:32 AM, Phillip Remaker <remaker@gmail.com> wrote:
I currently have a case open where two of my probes on IPv6 networks have no IPv6 address.
I was thinking I might reboot them or force an address probe but can't see an obvious way to do that remotely.
Ironically, my one probe that reports IPv6 capability has only a ULA address :-/
On Wed, Jun 11, 2014 at 3:59 PM, Jared Mauch <jared@puck.nether.net> wrote:
On Jun 11, 2014, at 11:39 AM, Klaus Darilion < klaus.mailinglists@pernau.at> wrote:
Am 11.06.2014 15:44, schrieb Daniel Karrenberg:
On 11.06.14 14:54 , Stephane Bortzmeyer wrote:
On Wed, Jun 11, 2014 at 01:16:21PM +0200, Antoin Verschuren <ripe@antoin.nl> wrote a message of 18 lines which said:
some tags like anchor or hasipv6 could be filled automagicaly. For "hasipv6", it is more complicated than it seems
Hence IPV6WORKS. ;-) Actually I never would want to make any IPv6 test from a probe which does not have the IPV6WORKS tag. Thus, probes which are known to knot work, should never be selected for measurements.
I “generally” agree with this. “IPv6-works” is defined as can contact greater than 50% of atlas anchors. (I’m surprised at how little traffic my anchors see).
- Jared
Hi Ondřej, there is already an API only flag that is similar to what you want. Its behavior is a bit different from what you want though, since it will try to fetch anchors first and if we don't have enough the rest will be covered by normal probes. Would that be sufficient for your needs? It's not stated on the docs and we use it currently only for our internal needs. It makes sense now though to give it to public as well. There is some cleaning up to be done first so it will be out with one of our next releases. Regards, Andreas On 6/11/14, 12:03 PM, Ondřej Caletka wrote:
Hello list,
is there a way to run an UDM on Anchors only? I think it would be a good feature, especially for precise latency measurement.
Cheers, Ondřej Caletka
participants (10)
-
Andreas Strikos -
Antoin Verschuren -
Daniel Karrenberg -
Gert Doering -
Jared Mauch -
Klaus Darilion -
Ondřej Caletka -
Phillip Remaker -
Robert Kisteleki -
Stephane Bortzmeyer