Hi, I'm trying to add a UDM for one of our nameservers, however it appears others are already doing "too many measurements" for this server, as this is the message I get when I try to add my UDM: "10 UDMs are already measuring 199.19.54.1/2001:500:c::1. Cannot add 2 more" AFAIK I have no UDMs running for this server, so the mentioned UDMs are beyond my control to retract. Is it possible to find out who is running these UDMs so I can ask them to stop, or alter them in such a way that they match what I need in this UDM? It seems a bit odd to me that I can't do custom measurements on our server because others are already doing some. ~paul -- Paul Vlaar DNS Infrastructure Group Afilias e-mail: pvlaar@afilias.info phone: +1-416-673-4078 mobile DE: +49-1578-5742-695 mobile NL: +31-6-506-306-35 mobile USA: +1-602-410-4148
On 18/9/14, 12:07 PM, Paul Vlaar wrote:
It seems a bit odd to me that I can't do custom measurements on our server because others are already doing some.
P.S. while I understand this is probably done to protect the server in question, I would like to see a better way to deal with this than just a "hard stop" at 10 measurements. Perhaps a way to negotiate a higher amount of UDMs possible for a given server? As it is now, this feels a like a DoS that is very easy to achieve. We've been getting more probes up recently, and we even ordered a RIPE Atlas Anchor box so that we can do a decent amount of UDMs on our own servers, but with this limitation in place, I'm fearing disappointment. Thanks, ~paul -- Paul Vlaar DNS Infrastructure Group Afilias e-mail: pvlaar@afilias.info phone: +1-416-673-4078 mobile DE: +49-1578-5742-695 mobile NL: +31-6-506-306-35 mobile USA: +1-602-410-4148
On Sep 18, 2014, at 6:13 AM, Paul Vlaar <pvlaar@afilias.info> wrote:
On 18/9/14, 12:07 PM, Paul Vlaar wrote:
It seems a bit odd to me that I can't do custom measurements on our server because others are already doing some.
P.S. while I understand this is probably done to protect the server in question, I would like to see a better way to deal with this than just a "hard stop" at 10 measurements. Perhaps a way to negotiate a higher amount of UDMs possible for a given server? As it is now, this feels a like a DoS that is very easy to achieve.
We've been getting more probes up recently, and we even ordered a RIPE Atlas Anchor box so that we can do a decent amount of UDMs on our own servers, but with this limitation in place, I'm fearing disappointment.
There’s some tricks to work around this. The easiest is to have a DNS name that points at the IP, or the RIPE folk have been able to adjust the limit in the past. I have some anycasted IPs I asked them to increase the limit for. - Jared
On 2014.09.18. 14:32, Jared Mauch wrote:
On Sep 18, 2014, at 6:13 AM, Paul Vlaar <pvlaar@afilias.info> wrote:
On 18/9/14, 12:07 PM, Paul Vlaar wrote:
It seems a bit odd to me that I can't do custom measurements on our server because others are already doing some.
P.S. while I understand this is probably done to protect the server in question, I would like to see a better way to deal with this than just a "hard stop" at 10 measurements. Perhaps a way to negotiate a higher amount of UDMs possible for a given server? As it is now, this feels a like a DoS that is very easy to achieve.
We've been getting more probes up recently, and we even ordered a RIPE Atlas Anchor box so that we can do a decent amount of UDMs on our own servers, but with this limitation in place, I'm fearing disappointment.
There’s some tricks to work around this. The easiest is to have a DNS name that points at the IP, or the RIPE folk have been able to adjust the limit in the past. I have some anycasted IPs I asked them to increase the limit for.
Hi, We have a system-wide setting for "no more than X ongoing measurements against the same target", where X=10 now. One can argue that 10 should be 20 (or a 100, 1000, ...) but there has to be something there. We can make exceptions on this per user. It'd be pretty difficult to administer quotas per target. Instead, our line of thinking at the moment is: * to separate the one-offs from the ongoing measurements; ie. there should be X one-off and X ongoing slots. This would allow users to do ad-hoc measurements even if the destination is otherwise well-measured * to switch to a model where we calculate the expected load on the target, like probes*frequency/time_interval, instead of pure number of measurements (which can have 1..10..100.1000 probes). In this model one could start a new measurement against a target even if there are a 1000 running already, as long as those measurements are not too heavy Let us know what you think about these scenarios! Cheers, Robert
Hi, On Thu, Sep 18, 2014 at 02:55:01PM +0200, Robert Kisteleki wrote:
It'd be pretty difficult to administer quotas per target. Instead, our line of thinking at the moment is: * to separate the one-offs from the ongoing measurements; ie. there should be X one-off and X ongoing slots. This would allow users to do ad-hoc measurements even if the destination is otherwise well-measured * to switch to a model where we calculate the expected load on the target, like probes*frequency/time_interval, instead of pure number of measurements (which can have 1..10..100.1000 probes). In this model one could start a new measurement against a target even if there are a 1000 running already, as long as those measurements are not too heavy
I think both models are useful :-) - one-off and ongoing to have separate quotas, and changing the actual quota calculation to some (obviously arbitrary) "packets per minute" number or such. Higher ppm values for well-known targets, like "all anchors", that signal their willingness to receive packets. Gert -- 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 18/9/14, 2:55 PM, Robert Kisteleki wrote:
It'd be pretty difficult to administer quotas per target. Instead, our line of thinking at the moment is: * to separate the one-offs from the ongoing measurements; ie. there should be X one-off and X ongoing slots. This would allow users to do ad-hoc measurements even if the destination is otherwise well-measured
In this particular case, this would not suffice, since I'm trying to setup new ongoing measurements. 2 per IP, actually, for 4 IPs. It looks like they are all maxed out. This wasn't the case a month ago.
* to switch to a model where we calculate the expected load on the target, like probes*frequency/time_interval, instead of pure number of measurements (which can have 1..10..100.1000 probes). In this model one could start a new measurement against a target even if there are a 1000 running already, as long as those measurements are not too heavy
Still, this would not address the fact that some IPs will simply always receive more measurements than others as they are more "popular". It just so happens that our IPs in question are okay to be measured more than others, as they are anycasted and have many servers running this IP. So I'm not worried about "over-measuring", and would prefer to have the limit raised on these. If we can prove ownership of these IPs, then perhaps this is something that can be done. Jared seems to have had luck in getting the NCC to raise the limit for individual IPs. ~paul -- Paul Vlaar DNS Infrastructure Group Afilias e-mail: pvlaar@afilias.info phone: +1-416-673-4078 mobile DE: +49-1578-5742-695 mobile NL: +31-6-506-306-35 mobile USA: +1-602-410-4148
On 18/9/14, 2:32 PM, Jared Mauch wrote:
the RIPE folk have been able to adjust the limit in the past. I have some anycasted IPs I asked them to increase the limit for.
This would be great if it can also be done for us. We're also talking about very solidly represented anycasted IPs here and it would be fine if the limit is raised to 100. Robert, should I contact you directly about this? ~paul -- Paul Vlaar DNS Infrastructure Group Afilias e-mail: pvlaar@afilias.info phone: +1-416-673-4078 mobile DE: +49-1578-5742-695 mobile NL: +31-6-506-306-35 mobile USA: +1-602-410-4148
participants (4)
-
Gert Doering -
Jared Mauch -
Paul Vlaar -
Robert Kisteleki