From fenner at fenron.com Tue Jun 4 22:27:40 2013 From: fenner at fenron.com (Bill Fenner) Date: Tue, 4 Jun 2013 16:27:40 -0400 Subject: [atlas] Newly-defined traceroute measurement failing with "name resolution failed: non-recoverable failure in name resolution" Message-ID: Hi, I have two probes that seem to work just fine; their built-in measurements work, I can see their results from my "My Atlas" page, etc. I happened to notice something weird about the ping times to c.root-servers.net, so wanted to define a traceroute measurement to see if there were route changes that could explain what I saw. However, the only result that I'm getting is "error": "name resolution failed: non-recoverable failure in name resolution". I picked "Resolve on probe", and used "c.root-servers.net" as the destination. I'm pretty sure I didn't make a typo, because I've copy-n-pasted from the dst_name of the result JSON. For reference, the UDM ID is 1010361 and the probes are 4936 and 4938. Each probe has a working DNS server configured, according to the "My Probes" view. Thanks for any help, Bill (P.S. I created a new UDM using the IP address, to work around the DNS problem, but it'd still be nice to understand what I did wrong with the other one.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Tue Jun 4 23:15:47 2013 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 04 Jun 2013 23:15:47 +0200 Subject: [atlas] Newly-defined traceroute measurement failing with "name resolution failed: non-recoverable failure in name resolution" In-Reply-To: References: Message-ID: <51AE5903.9040100@ripe.net> Hi Bill, On 6/4/13 22:27 , Bill Fenner wrote: > > > I picked "Resolve on probe", and used "c.root-servers.net > " as the destination. I'm pretty sure I > didn't make a typo, because I've copy-n-pasted from the dst_name of > the result JSON. > > For reference, the UDM ID is 1010361 and the probes are 4936 and 4938. > Each probe has a working DNS server configured, according to the "My > Probes" view. > > I've no idea what is going on there. It works on other probes and your resolvers also seem to work fine. I'll try to investigate. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lee at kerfuffle.net Sat Jun 8 21:17:40 2013 From: lee at kerfuffle.net (Lee Hetherington) Date: Sat, 08 Jun 2013 20:17:40 +0100 Subject: [atlas] New Atlas Probe Message-ID: <51B38354.3090301@kerfuffle.net> Hi, I obtained an Atlas probe at NANOG last week... I've got it connected (natted) and registered, but it's not showing up under my probes as yet. How long does it usually take? I can see traffic on the port that i've connected the atlas probe too, so assume its able to get out. Cheers, Lee From fearghas at gmail.com Sat Jun 8 21:28:32 2013 From: fearghas at gmail.com (Fearghas McKay) Date: Sat, 8 Jun 2013 13:28:32 -0600 Subject: [atlas] New Atlas Probe In-Reply-To: <51B38354.3090301@kerfuffle.net> References: <51B38354.3090301@kerfuffle.net> Message-ID: <93EB6093-E57E-46FF-8870-B51D10E892C6@gmail.com> Depending on how the registration is being done for the NANOG probes it may need intervention from the NCC folks so that will be Monday. f Sent from my iPhone On Jun 8, 2013, at 1:17 PM, Lee Hetherington wrote: > Hi, > > I obtained an Atlas probe at NANOG last week... I've got it connected (natted) and registered, but it's not showing up under my probes as yet. How long does it usually take? I can see traffic on the port that i've connected the atlas probe too, so assume its able to get out. > > Cheers, > > Lee > From albyva at empire.org Sat Jun 8 21:32:07 2013 From: albyva at empire.org (AlbyVA) Date: Sat, 8 Jun 2013 15:32:07 -0400 Subject: [atlas] New Atlas Probe In-Reply-To: <93EB6093-E57E-46FF-8870-B51D10E892C6@gmail.com> References: <51B38354.3090301@kerfuffle.net> <93EB6093-E57E-46FF-8870-B51D10E892C6@gmail.com> Message-ID: I'm in the same boat. My probe is connected and registration submitted but MyProbe remains blank. -Alby On Jun 8, 2013 3:28 PM, "Fearghas McKay" wrote: > Depending on how the registration is being done for the NANOG probes it > may need intervention from the NCC folks so that will be Monday. > > f > > Sent from my iPhone > > On Jun 8, 2013, at 1:17 PM, Lee Hetherington wrote: > > > Hi, > > > > I obtained an Atlas probe at NANOG last week... I've got it connected > (natted) and registered, but it's not showing up under my probes as yet. > How long does it usually take? I can see traffic on the port that i've > connected the atlas probe too, so assume its able to get out. > > > > Cheers, > > > > Lee > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vnaumov at ripe.net Mon Jun 10 14:11:15 2013 From: vnaumov at ripe.net (Viktor Naumov) Date: Mon, 10 Jun 2013 14:11:15 +0200 Subject: [atlas] New Atlas Probe In-Reply-To: <93EB6093-E57E-46FF-8870-B51D10E892C6@gmail.com> References: <51B38354.3090301@kerfuffle.net> <93EB6093-E57E-46FF-8870-B51D10E892C6@gmail.com> Message-ID: <51B5C263.40802@ripe.net> CS is a bit behind... Lots of probes to verify. Sorry for delay Viktor On 6/8/13 9:28 PM, Fearghas McKay wrote: > Depending on how the registration is being done for the NANOG probes it may need intervention from the NCC folks so that will be Monday. > > f > > Sent from my iPhone > > On Jun 8, 2013, at 1:17 PM, Lee Hetherington wrote: > >> Hi, >> >> I obtained an Atlas probe at NANOG last week... I've got it connected (natted) and registered, but it's not showing up under my probes as yet. How long does it usually take? I can see traffic on the port that i've connected the atlas probe too, so assume its able to get out. >> >> Cheers, >> >> Lee >> From becha at ripe.net Mon Jun 10 14:41:12 2013 From: becha at ripe.net (becha at ripe.net) Date: Mon, 10 Jun 2013 14:41:12 +0200 (CEST) Subject: [atlas] New Atlas Probe - delay in registration In-Reply-To: <51B5C263.40802@ripe.net> References: <51B38354.3090301@kerfuffle.net> <93EB6093-E57E-46FF-8870-B51D10E892C6@gmail.com> <51B5C263.40802@ripe.net> Message-ID: <62831.83.161.216.205.1370868072.squirrel@webmail.ripe.net> Dear all, in the last weeks we had two big events - NANOG and ENOG - where hundreds of probes were distributed. We are now dealing with processing of all the registration information, so this is bringing the delay in seeing the probes that you have already connected as "active". Thank you for your understanding and patience. If you have additional questions, you can email "atlas at ripe.net", with your Probe-ID included. In the meantime, please enjoy the "Community" pages, where you can watch "new arrivals" and upload photos: https://atlas.ripe.net/get-involved/community/#!tab-actionshots Regards, on behalf of RIPE-Atlas team, Vesna -- Vesna Manojlovic BECHA at ripe.net Senior Community Builder @Ms_Measurements for Measurements Tools RIPE NCC http://ripe.net >> On Jun 8, 2013, at 1:17 PM, Lee Hetherington wrote: >> >>> Hi, >>> >>> I obtained an Atlas probe at NANOG last week... I've got it connected >>> (natted) and registered, but it's not showing up under my probes as >>> yet. How long does it usually take? I can see traffic on the port >>> that i've connected the atlas probe too, so assume its able to get out. >>> >>> Cheers, >>> >>> Lee >>> > > > > From bouncepioppeto at gmail.com Wed Jun 12 10:12:13 2013 From: bouncepioppeto at gmail.com (Hotel Pioppeto saronno) Date: Wed, 12 Jun 2013 08:12:13 +0000 Subject: [atlas] A New look, a tailor made hospitality - Welcom and Welcome back Message-ID: <0000013f377130f0-c9f4b53e-68c5-42ea-bc3c-a7acdd3b4f63-000000@email.amazonses.com> +39.0296248164 pioppeto at hotelpioppeto.it WWW.HOTELPIOPPETOSARONNO.IT Via Str? Madonna, 15 - 21047 Saronno (VA) - A9 Milano-Como-Chiasso motorway, Saronno exit -------------- next part -------------- An HTML attachment was scrubbed... URL: From bortzmeyer at nic.fr Wed Jun 12 16:53:32 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 12 Jun 2013 16:53:32 +0200 Subject: [atlas] Spoofing the source IP address from a probe? Message-ID: <20130612145331.GA23909@nic.fr> I read in the interesting about BCP38 (anti-spoofing): > Another possibility that was suggested is using RIPE Atlas probes to > probe network capabilities (or shall we say incapabilities?). AFAIK, Atlas probes cannot currently perform these tests, am I correct? From daniel.karrenberg at ripe.net Wed Jun 12 17:30:21 2013 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 12 Jun 2013 17:30:21 +0200 Subject: [atlas] Spoofing the source IP address from a probe? In-Reply-To: <20130612145331.GA23909@nic.fr> References: <20130612145331.GA23909@nic.fr> Message-ID: <42BF63F0-6D87-40CC-ADCC-A9E76B227ED8@ripe.net> On 12.06.2013, at 16:53 , Stephane Bortzmeyer wrote: > I read in the interesting > > about BCP38 (anti-spoofing): > >> Another possibility that was suggested is using RIPE Atlas probes to >> probe network capabilities (or shall we say incapabilities?). > > AFAIK, Atlas probes cannot currently perform these tests, am I > correct? No they cannot. It is a matter of policy first and foremost. It is too easy to loose the trust of the probe hosts and to get a bad name with providers if we have the probes do stuff that is as questionable as source address spoofing. Personally I am very much against probes spoofing source addresses. In my personal judgement the risk of loosing a significant number of probes is not at all justified by the potential benefit of doing spoofing measurements. As RIPE NCC chief scientist I am of the opinion that if the community decides to do such tests despite the risk to RIPE Atlas, then we can only do this with explicit permission from the host concerned. Daniel From randy at psg.com Wed Jun 12 17:35:54 2013 From: randy at psg.com (Randy Bush) Date: Wed, 12 Jun 2013 17:35:54 +0200 Subject: [atlas] Spoofing the source IP address from a probe? In-Reply-To: <42BF63F0-6D87-40CC-ADCC-A9E76B227ED8@ripe.net> References: <20130612145331.GA23909@nic.fr> <42BF63F0-6D87-40CC-ADCC-A9E76B227ED8@ripe.net> Message-ID: > No they cannot. It is a matter of policy first and foremost. It is too > easy to loose the trust of the probe hosts and to get a bad name with > providers if we have the probes do stuff that is as questionable as > source address spoofing. thank you randy From jzp-ripe at rsuc.gweep.net Wed Jun 12 17:44:20 2013 From: jzp-ripe at rsuc.gweep.net (Joe Provo) Date: Wed, 12 Jun 2013 11:44:20 -0400 Subject: [atlas] Spoofing the source IP address from a probe? In-Reply-To: References: <20130612145331.GA23909@nic.fr> <42BF63F0-6D87-40CC-ADCC-A9E76B227ED8@ripe.net> Message-ID: <20130612154420.GA79562@gweep.net> On Wed, Jun 12, 2013 at 05:35:54PM +0200, Randy Bush wrote: > > No they cannot. It is a matter of policy first and foremost. It is too > > easy to loose the trust of the probe hosts and to get a bad name with > > providers if we have the probes do stuff that is as questionable as > > source address spoofing. > > > > thank you To be fair, it was discussed at ripe66 and there was an open question as to wether malformed traffic testing of any type would be of value (even on an opt-in basis). Arguably, address forgery is a subtype of malformed traffic. I would encourage those in the community who wish to be performing individual spoof testing (or instruct others how to do so) to use the easy-peasey pointy-clicky CAIDA/CSAIL tool: http://spoofer.cmand.org/ (also spoofer.csail.mit.edu, spooftest.net, etc etc) -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NANOG From colinj at mx5.org.uk Wed Jun 12 18:24:31 2013 From: colinj at mx5.org.uk (Colin Johnston) Date: Wed, 12 Jun 2013 17:24:31 +0100 Subject: [atlas] Spoofing the source IP address from a probe? In-Reply-To: <42BF63F0-6D87-40CC-ADCC-A9E76B227ED8@ripe.net> References: <20130612145331.GA23909@nic.fr> <42BF63F0-6D87-40CC-ADCC-A9E76B227ED8@ripe.net> Message-ID: > > No they cannot. It is a matter of policy first and foremost. It is too easy to loose the trust of the probe hosts and to get a bad name with providers if we have the probes do stuff that is as questionable as source address spoofing. > > Personally I am very much against probes spoofing source addresses. In my personal judgement the risk of loosing a significant number of probes is not at all justified by the potential benefit of doing spoofing measurements. > > As RIPE NCC chief scientist I am of the opinion that if the community decides to do such tests despite the risk to RIPE Atlas, then we can only do this with explicit permission from the host concerned. > > Daniel This is the wrong approach above to take from a ISP sysadmin perspective. What should be done is Router(CBAC correct packet source address checking), ideally on the sysadmin leaf routers if such routers are implemented or on the core routers. You only want good traffic getting to service machines to make network traffic usage worthwhile. A good network provider will implement source address checking as they value the network usage. Customer end devices are a good point to check for packet source checking as botnet machines frequently utiliize home machines, feel free for my probe to be used as anything which can improve good network traffic usage in the age of cutbacks of money is useful. Colin Johnston From pk at DENIC.DE Wed Jun 12 18:02:15 2013 From: pk at DENIC.DE (Peter Koch) Date: Wed, 12 Jun 2013 18:02:15 +0200 Subject: [atlas] Spoofing the source IP address from a probe? In-Reply-To: <42BF63F0-6D87-40CC-ADCC-A9E76B227ED8@ripe.net> References: <20130612145331.GA23909@nic.fr> <42BF63F0-6D87-40CC-ADCC-A9E76B227ED8@ripe.net> Message-ID: <20130612160215.GD23524@x28.adm.denic.de> On Wed, Jun 12, 2013 at 05:30:21PM +0200, Daniel Karrenberg wrote: > No they cannot. It is a matter of policy first and foremost. It is too easy to loose the trust of the probe hosts and to get a bad name with providers if we have the probes do stuff that is as questionable as source address spoofing. thanks. > As RIPE NCC chief scientist I am of the opinion that if the community decides to do such tests despite the risk to RIPE Atlas, then we can only do this with explicit permission from the host concerned. as a host my understanding is that the Atlas network exists to generate a view of "the Internet" from a variety of vantage points. A spoofing test (and other tests that have been discussed) would rather explore specific aspects of the respective hosts' network. There's really a fine line. -Peter From daniel.karrenberg at ripe.net Wed Jun 12 20:37:24 2013 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 12 Jun 2013 20:37:24 +0200 Subject: [atlas] Spoofing the source IP address from a probe? In-Reply-To: <20130612154420.GA79562@gweep.net> References: <20130612145331.GA23909@nic.fr> <42BF63F0-6D87-40CC-ADCC-A9E76B227ED8@ripe.net> <20130612154420.GA79562@gweep.net> Message-ID: <942E06E5-C9AE-4752-8902-4D8AF70CC2EA@ripe.net> On 12.06.2013, at 17:44 , Joe Provo wrote: > I would encourage those in the community who wish to be > performing individual spoof testing (or instruct others how > to do so) to use the easy-peasey pointy-clicky CAIDA/CSAIL > tool: http://spoofer.cmand.org/ > (also spoofer.csail.mit.edu, spooftest.net, etc etc) Seconded. Using this something like this is a conscious decision of the user. I have personally run Robert Beverley's probes regularly for many years and I am proud to say that both my broadband providers have never allowed source address spoofing. This involves a conscious decision on my part taking into account local network etiquette, my relation to my providers and the local legal situation. It is very very different from the RIPE community deciding to use RIPE Atlas to do this from my network. Daniel From jayb at braeburn.org Thu Jun 13 16:47:10 2013 From: jayb at braeburn.org (Jay Borkenhagen) Date: Thu, 13 Jun 2013 10:47:10 -0400 Subject: [atlas] BOOTP/DHCP on a probe with static network configuration Message-ID: <20921.56174.783260.385390@oz.mt.att.com> Hi, I have two brand new RIPE Atlas probes. Both are reported as 'connected' on my My Atlas page, both run the 4520 firmware, and both correctly report and use the static network configurations I gave them per the instructions at https://atlas.ripe.net/doc/static-config However, both probes still send BOOTP/DHCP requests every 3 seconds. Are others seeing this behavior with their probes that have static network configurations? Can this behavior be changed? Thanks! Jay B. From bouncepioppeto at gmail.com Sun Jun 16 00:03:11 2013 From: bouncepioppeto at gmail.com (Hotel Pioppeto saronno) Date: Sat, 15 Jun 2013 22:03:11 +0000 Subject: [atlas] A New look, a tailor made hospitality - Welcom and Welcome back Message-ID: <0000013f49dd0edb-b26cac08-5588-4f06-a9bc-ce74c3c0138d-000000@email.amazonses.com> +39.0296248164 pioppeto at hotelpioppeto.it WWW.HOTELPIOPPETOSARONNO.IT Via Str? Madonna, 15 - 21047 Saronno (VA) - A9 Milano-Como-Chiasso motorway, Saronno exit -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayb at braeburn.org Tue Jun 18 17:17:17 2013 From: jayb at braeburn.org (Jay Borkenhagen) Date: Tue, 18 Jun 2013 11:17:17 -0400 Subject: [atlas] BOOTP/DHCP on a probe with static network configuration In-Reply-To: <20921.56174.783260.385390@oz.mt.att.com> References: <20921.56174.783260.385390@oz.mt.att.com> Message-ID: <20928.31229.944140.392637@oz.mt.att.com> On 13-June-2013, Jay Borkenhagen writes: > Hi, > > I have two brand new RIPE Atlas probes. Both are reported as > 'connected' on my My Atlas page, both run the 4520 firmware, and both > correctly report and use the static network configurations I gave them > per the instructions at https://atlas.ripe.net/doc/static-config > > However, both probes still send BOOTP/DHCP requests every 3 seconds. > > Are others seeing this behavior with their probes that have static > network configurations? Can this behavior be changed? > Hi again, Philip from the RIPE Atlas team replied to a query I sent to atlas at ripe.net: > The way it is supposed to work is that the probe verifies its > static config by pinging the configured default router. When that > works (i.e., the ping results in an ARP entry), the probe kills the > dhcp client. > I have no idea why that doesn't work in your case. I've tried making some minor configuration adjustments with the above in mind, but no change. For some admittedly silly reasons, this minor nit is something I will need to address. But before I set about doing that, I would really like to know whether anyone else is seeing the same behavior: continual DHCP requests being emitted from their RIPE Atlas probes with static network configuration. FWIW my probes are both version 3 (Architecture TP-Link) running Firmware Version 4520. Thanks. Jay B. From jared.allison at verizon.com Tue Jun 18 19:19:54 2013 From: jared.allison at verizon.com (Allison, Jared M) Date: Tue, 18 Jun 2013 13:19:54 -0400 Subject: [atlas] troubleshooting a new probe configuration Message-ID: Hello, I just got a new RIPE Atlas probe at NANOG in New Orleans, US and am trying to get it up and running. I configured a port for it on my firewall with IPv4 DHCP service and DNS. The firewall rules should permit just about all traffic. I confirmed that the port was operational by connecting a computer to it and could browse to external websites, etc. When I connect the probe to this port, I can see in the logs that it gets an IPv4 DHCP address, but doesn't seem to do anything else. The power light on the probe is solid, the second light appears to be off, and the third and fourth lights are blinking. It's been this way through several power-cycles and several days. Any idea what error condition this indicates? Thanks, -jared --- Jared Allison jared.allison at verizon.com From danny at danysek.cz Tue Jun 18 20:07:01 2013 From: danny at danysek.cz (Daniel Suchy) Date: Tue, 18 Jun 2013 20:07:01 +0200 Subject: [atlas] Atlas probe - virtual appliance? Message-ID: <51C0A1C5.6000004@danysek.cz> Hello, maybe should be interesting providing RIPE Atlas probe as an virtual appliance (VMWare, XEN, VirtualBox etc). Handling will be much easier and deployment cheaper (as no extra hardware will be required to run new probe). Virtual apliance should be still managed by RIPE NCC (like current hardware probes) in terms of upgrades and so on. I think this may be interesting to consider. With regards, Daniel From nigel.titley at easynet.com Wed Jun 19 11:47:16 2013 From: nigel.titley at easynet.com (Nigel Titley) Date: Wed, 19 Jun 2013 09:47:16 +0000 Subject: [atlas] Atlas probe - virtual appliance? In-Reply-To: <51C0A1C5.6000004@danysek.cz> References: <51C0A1C5.6000004@danysek.cz> Message-ID: But virtual appliances are generally pretty bad at network monitoring. Nigel -----Original Message----- From: ripe-atlas-bounces at ripe.net [mailto:ripe-atlas-bounces at ripe.net] On Behalf Of Daniel Suchy Sent: 18 June 2013 19:07 To: ripe-atlas at ripe.net Subject: [atlas] Atlas probe - virtual appliance? Hello, maybe should be interesting providing RIPE Atlas probe as an virtual appliance (VMWare, XEN, VirtualBox etc). Handling will be much easier and deployment cheaper (as no extra hardware will be required to run new probe). Virtual apliance should be still managed by RIPE NCC (like current hardware probes) in terms of upgrades and so on. I think this may be interesting to consider. With regards, Daniel From colinj at mx5.org.uk Wed Jun 19 11:53:02 2013 From: colinj at mx5.org.uk (Colin Johnston) Date: Wed, 19 Jun 2013 10:53:02 +0100 Subject: [atlas] Atlas probe - virtual appliance? In-Reply-To: References: <51C0A1C5.6000004@danysek.cz> Message-ID: <0DD56314-A072-4616-A8BB-3591D0D51DE5@mx5.org.uk> Virtual firewalls work great with VMware and cost effective as well, 90% cost saving Colin Sent from my iPhone On 19 Jun 2013, at 10:47, Nigel Titley wrote: > But virtual appliances are generally pretty bad at network monitoring. > > Nigel > -----Original Message----- > From: ripe-atlas-bounces at ripe.net [mailto:ripe-atlas-bounces at ripe.net] On Behalf Of Daniel Suchy > Sent: 18 June 2013 19:07 > To: ripe-atlas at ripe.net > Subject: [atlas] Atlas probe - virtual appliance? > > Hello, > maybe should be interesting providing RIPE Atlas probe as an virtual appliance (VMWare, XEN, VirtualBox etc). Handling will be much easier and deployment cheaper (as no extra hardware will be required to run new probe). > > Virtual apliance should be still managed by RIPE NCC (like current hardware probes) in terms of upgrades and so on. > > I think this may be interesting to consider. > > With regards, > Daniel > From randy at psg.com Wed Jun 19 12:01:37 2013 From: randy at psg.com (Randy Bush) Date: Wed, 19 Jun 2013 19:01:37 +0900 Subject: [atlas] Atlas probe - virtual appliance? In-Reply-To: <0DD56314-A072-4616-A8BB-3591D0D51DE5@mx5.org.uk> References: <51C0A1C5.6000004@danysek.cz> <0DD56314-A072-4616-A8BB-3591D0D51DE5@mx5.org.uk> Message-ID: > Virtual firewalls work great with VMware and cost effective as well, > 90% cost saving >> But virtual appliances are generally pretty bad at network monitoring. nigel meant time-dependent measurements From daniel.karrenberg at ripe.net Wed Jun 19 12:04:35 2013 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 19 Jun 2013 12:04:35 +0200 Subject: [atlas] Atlas probe - virtual appliance? In-Reply-To: <51C0A1C5.6000004@danysek.cz> References: <51C0A1C5.6000004@danysek.cz> Message-ID: <5A3DF324-DC49-476A-9F3E-926C99D16040@ripe.net> On 18.06.2013, at 20:07 , Daniel Suchy wrote: > Hello, > maybe should be interesting providing RIPE Atlas probe as an virtual > appliance (VMWare, XEN, VirtualBox etc). Handling will be much easier > and deployment cheaper (as no extra hardware will be required to run new > probe). > > Virtual apliance should be still managed by RIPE NCC (like current > hardware probes) in terms of upgrades and so on. > > I think this may be interesting to consider. > > With regards, > Daniel > > From https://atlas.ripe.net/about/faq/ : Why did you choose a hardware solution instead of software? With a pure software solution, distribution costs are low and the number of potential hosts is very large. However, there are several significant downsides to a pure software approach: ? Host machines may not run continuously over long periods, which affects our ability to gather round-the-clock measurements. ? Measurements can be influenced by sharing systems and network resources with other applications on the host computer. ? It is often not possible to install software like this in a corporate or computer centre environment. ? It is easier to tamper with the results. This is also why we chose not to release a software version in tandem with the hardware solution. Because of these drawbacks, we opted to develop the RIPE Atlas probe as a stand-alone piece of hardware. From nigel.titley at easynet.com Wed Jun 19 12:09:10 2013 From: nigel.titley at easynet.com (Nigel Titley) Date: Wed, 19 Jun 2013 10:09:10 +0000 Subject: [atlas] Atlas probe - virtual appliance? In-Reply-To: References: <51C0A1C5.6000004@danysek.cz> <0DD56314-A072-4616-A8BB-3591D0D51DE5@mx5.org.uk> Message-ID: -----Original Message----- From: Randy Bush [mailto:randy at psg.com] Sent: 19 June 2013 11:02 To: Colin Johnston Cc: Nigel Titley; ripe-atlas at ripe.net Subject: Re: [atlas] Atlas probe - virtual appliance? > Virtual firewalls work great with VMware and cost effective as well, > 90% cost saving >> But virtual appliances are generally pretty bad at network monitoring. > nigel meant time-dependent measurements Yes... Randy is right.. apologies for the sloppy wording From inigo at infornografia.net Wed Jun 19 13:34:31 2013 From: inigo at infornografia.net (=?ISO-8859-1?Q?I=F1igo_Ortiz_de_Urbina?=) Date: Wed, 19 Jun 2013 13:34:31 +0200 Subject: [atlas] Atlas probe - virtual appliance? In-Reply-To: References: <51C0A1C5.6000004@danysek.cz> <0DD56314-A072-4616-A8BB-3591D0D51DE5@mx5.org.uk> Message-ID: On Wed, Jun 19, 2013 at 12:01 PM, Randy Bush wrote: > > > Virtual firewalls work great with VMware and cost effective as well, > > 90% cost saving > >> But virtual appliances are generally pretty bad at network monitoring. > > nigel meant time-dependent measurements > Allow me to share some interesting links with Daniel Suchy (and the list archive) regarding the virtualization impact on CPU, disk I/O and time accuracy: o Short article published at labs.ripe.net [1] not long ago around the Atlas Anchors. o Talk by Randy himself [2][3] on probe/measurement calibration Regards, [1] https://labs.ripe.net/Members/romeo_zwart/ripe-atlas-anchor-to-ripe-ncc-service-node [2] https://ripe66.ripe.net/presentations/128-130513.tokyo-ping.pdf [3] https://ripe66.ripe.net/archives/video/12/ From philip.homburg at ripe.net Wed Jun 19 13:58:11 2013 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 19 Jun 2013 13:58:11 +0200 Subject: [atlas] Atlas probe - virtual appliance? In-Reply-To: <51C0A1C5.6000004@danysek.cz> References: <51C0A1C5.6000004@danysek.cz> Message-ID: <51C19CD3.3060607@ripe.net> On 6/18/13 20:07 , Daniel Suchy wrote: > maybe should be interesting providing RIPE Atlas probe as an virtual > appliance (VMWare, XEN, VirtualBox etc). Handling will be much easier > and deployment cheaper (as no extra hardware will be required to run new > probe). > > Virtual apliance should be still managed by RIPE NCC (like current > hardware probes) in terms of upgrades and so on. > > One thing to keep in mind is that, apart from the obvious issues with getting reliable timings out of a virtual machine, this proposal may have significant development and operational costs. These costs may be high enough to offset the benefits of not having to buy new hardware. Setting up Atlas on a VM may easily be more expensive than a probe. Developing Atlas 'firmware' for common VMs may also cost enough that in the end there aren't any savings. From bouncepioppeto at gmail.com Wed Jun 19 19:24:41 2013 From: bouncepioppeto at gmail.com (Hotel Pioppeto saronno) Date: Wed, 19 Jun 2013 17:24:41 +0000 Subject: [atlas] A New look, a tailor made hospitality - Welcome and Welcome back Message-ID: <0000013f5d778399-c16105d2-f4b5-4ce4-aa54-d9f6c6f75c5d-000000@email.amazonses.com> +39.0296248164 pioppeto at hotelpioppeto.it WWW.HOTELPIOPPETOSARONNO.IT Via Str? Madonna, 15 - 21047 Saronno (VA) - A9 Milano-Como-Chiasso motorway, Saronno exit -------------- next part -------------- An HTML attachment was scrubbed... URL: From fiansirstroi at mail.ru Wed Jun 19 22:39:21 2013 From: fiansirstroi at mail.ru (=?Windows-1251?B?UG//6/Lo?=) Date: Thu, 20 Jun 2013 00:39:21 +0400 Subject: [atlas] =?windows-1251?b?SODr7uPu4u7lIO/r4O3o8O7i4O3o5SBQT9/L0sg=?= Message-ID: <107008391.20130620200713@mail.ru> 26 ???? 2013 ?. Bce o po???? ? ???o?o??? ??a??po?????, ?a?o???? ?x??? o?????????? ?a???o? c ???o??? ??pe????????. ?p?????a pa???? c o??e??a?? ??????e????????? ?o??????????? ?. K?e?, ??. ??p??o?? (???o??????), 172 ????e?-?e??? ?????a???? C????, 8 ??, o?. 817. ?e?.: (044) 362-7625 ??K??????? ?c?????? B??????? ?????????a ? ???a??????? ?????e? ?a?????o-???????????? ?????c??? ?C???p????, ???e????? ????p?????, a??????. ????e??? ??e?o? Bc??????????? ????c??????? op????????? ???c??????? ???c?o? ??p?????, ??e ?e????p?? ???????e? ??ac??e ? ??ce?????? ?o??????? ?o ????o??? ?a?o???????????, ??????????a????? ?o?c????????? ? ?e??a??. ????e?c? ????p?? ??o?o?, ??o????c?????? ??????a??? ? ?o???????? ?e?a???????? ???????x. ??????p?? ??????a?? ? ????c??? ????a????a ?a ?p??o??? ?o??ep??????, a ?a??? ?o??????????, ??????e???? ??????????o????? IT ? ???e??e? ?????c? ? ??pa??e. ?ep????? A???a A?e?????????? - ??p??e? ?a?????o-???????????? a?e?????? "???ep???", ?a?e????? ?o?ep????? ??p????. C??????????????? ?a ?o?p???? p?????????? ??????o? ???e??e????????? ?o?c????????? ?a? ? ???a??e, ?a? ? ? ?????x c?????? ??pa, ????c?????? ?o?o?o??? ?a ??? ???e???, ?p??e????? ?p????e????? ?????a o??????? ??????e????????? c????????????. ??????c? a???p?? ????o?, ???????c?????? ??????a??? ? ?o???????? ?e?????????? ???a???x. K????? E?e?a ??????e??? - ???a??????? ??e???? ??????e???a????? ?o?c?????????, ??e? ?O? ??c???????? C??????????? O?e????, ?a?e????? ?o?ep????? ???a???. C????a?????????? ?a o?e??? ???e???????????? co?c?????????, a ?a??? o?pe??????? ??ep?? o? ?????e??? ????ec??e???? ?pa? ?a ???e??? ??????????a????? ?o???????????. ?e??op ??o?? ??????a????? ????e??????????? ??a?????a??? ??? (?o ?a??a?????? ?O????? ???e???????????? c??c??????????) ? ??c?????a ???e??e???a????? ?o?c????????? ???c???? ??????ec??? ????e??? ? ?. ??e?e. ?????a ??????? - ??o?? ??a???o?????, ????????a?? ?o ????o??? ???????p?????? ?a???????? ?a??????????????, ?a?o????? ? ??x?a??e????? o?????????, o??? ?e?????????????? ????ec?, ? o???o???? ????ece ???ee 7 ?e?, ??????a??? ? ??????x ????o???e???? ? ?p????ec??? ???????x. ?pe????e???? Ce????? ?o??????? ?? ??a????????? co????? ? ???o????????. B? ?e ?c?????e ????p?????? ?o?? ???o?? ? ????a???o? c??c??. Ka???? ???c???? c??????? ?a????c? ?p??e???? ?a?o? ??? ?a???? ? ??a?? ??o??? ?????ca. ?? ?o??a????? Ba? c ?o?????? ?a?o?o??? op?a??? ?o p???????? ??a??a? ?a???o????????? ?o????, a ?a??e c ?p???p??? ?? c?????o? ??a?????. B? ???????c? ???e???? ????o? ? o????e??? ?e?????? c o??e????? ??????????a????? c????????????, ?o??p?? ?o??? ?p??e??? ? p???o??????? c ???o?????? op?a???? ? ???e???? ?????p??????????. ?p??????? ??o? 1. ?a?o????? ?????p?????? ? ??????e ? ?a ???e?o?. O?????????? ?o??p????? ???o???? c??? ???o?? c ??p?????????? ? ??a??, ?a???e ?p??e???, ?a???p?,??????? ?????? ?a ?p?????? pe?e??? ? ?????e ?a??a???? ?a?o??, ???o? ????a??? ? ?p. Ce?p??? ?oc??????? ???a???????? ? o??o???????? ???o???x c?e? ?a?o?? ??? ??????a??????? ????e??. P??? ??oc??????? ?o?????? ? ?????c?, ??? ?e?? ?e c??????? ?????o ??pa??????? ?ec??????. ???????p????? ?????o??? ??a??p??????. ???c??? ?a?o????? ??e??????? ???pa? ? ???o??? ??a????a ???????a??? ????a? ??o? 2. B???e??? ? ???o?o??? ??a??p?????? c ?o?o??? o??e???? ???e??e????????? ???c?????????. K?? ??a??????? cx??? ????a?? ?o???? ?ep?????????, po?? ??o? cxe?? ? ???o????? ?????po?????. ?p???????????? ? ???p?????? ?e?????? ?pa? ??????e????????? co???????????. Kp????? o???p. ???e???o???? ???o?o?, ???o??????????? po???? ? ??pa???: ?a?o??e ???e???. ??o? 3. O?????? ???e???????????? ?o?c?????????: ?a?o? ???pa??, ?a? pe??c????????? ? ?a????a?? ?o???o??. ??p???????? ???e??o? ???e??????a????? ?o???????????. ?oc???????????? pe??c?????? o??????? ???e??e???a????? co???????????: ????e??? ???e??? ????????o?? o????????? ?????e??????. ?o???e???, ?????ep??????? ????a ?a ???e??? ???e???????????? co?c?????????. O?????????? ?pa?o??? o?p??? o??e??o? ???o????? ? ??e???? ?pa? ? ??p???e. ???o????????? a??o????? ? c?e???x ??a? ? ?????ce. ?pa?o??? pe????p?????? ?po?e??? ?p?o???????? ??a? ?a ????o??? ?ap?? ? ??pa??e. ?o?e? ?e?a???? o? ???o?????? ??? o??a?a ? pe??c?????? ? ?a? ?x ???e????. ?e?????p????? p???c?????? ??p????? ?ap??: ????, ?pe????e???? ? ???o?????? ?a????o ?? ???o?. ?po????e???? o?pa???, ???e??a? ?o????, ????p?????? ? ????e??e o?????? ?e??? ????, oco???????? ?e????????? ? ?p?????? ?x????, a ?a??e ?o???????, ??????p??????? ?pa?? ?a ??x. ????a ??????e????????? co?c????????? ?a ?o???p?????? ?a??e???????. ??a?o??? p?????p?????? o????e??? o??o???????? ?p???x ???e??o? ??????e???a????? co?c?????????, ? ?a???????: o?????????? ??o?????????? ?o?a??, ?o???????? ???e?pa????? ???po????, ?o?-xa?. ???????????e ???o?o??, ?????o?? ?e?e???? ?p??, a ????e ?????e ?o?o?o?? ?a o??e??? ???e???????????? c???????????? (? ?a???o???: ?a o??e??? ???op???? ? c?e???x ??a?, ?op????? ?ap??, ??o????????? o??a???, ?o?????e ?o?e??, ????pe?????): ?p???p?? ????p???????? ? c??ec??????? ???e???, ?o??p?? ??o?? ??????a?? ?p? co?????????/?????????? ?a??x ?o?o?????. ??o? 4. Ha?o??????????? ???p???? c o???????? ???e??????a????? co???????????. ?a? o??????? o??e??? ???e??e????????? ???c????????? ? ????a???????? ??e?e; ?e???? ?a??c?e??? a??p???????. H?????????????? ????e??? ?o ?o?o????? ?e?????? ??a? ?a o??e??? ??????????a????? c??c?????????. ??p???????? ?o????, ?????o????????? po???? ? ???a??e ? ???a????? ???o?, c?????????? ?o??, ?pa????a ????e?e???. Po???? ?o ??????????o?? ?o?o?o?? c ?pa?o? ???a?? c??????????, po???? ?o ?o?????? ?o???p?????? ????e???? (?p???a??????). ????a????????? ?c?????o????? ???e??a ??????????a????? ?o??????????? ? ?o???c??????? ????????o??? ???????a?? ??? ?e?e? ????a?? po????. ???o??????????? ??a?e?e? ?o???? ???e????????: H?C, ?a?pa??, ?a??? c ??xo??? ??p????????? c ?c?o????o? ?x ?po?c???????? ?? ??p????. ?po??????? ????o?? ? o???????? ??a?e??? po???? ?e??????????: ?a? ?o???ep???? ????????a?????? ?o?????e?? ?o????; ??o ?e?a??, e??? ?p??? ??e???? ?o?????? ?a ?e?p?????? ???a???? ?????a ?a?o????? c????? ? ???e??? ??c?e?? ??????c?p???????? c??a ??p???? ?o ?o?p????, ???a?????? p?????p?????? ?a?o?o????????? p?????: ?a???c????? ? pe?o???????? ?o ??????e??? ?x ?a ?p?????e. ?e?????p????? ???o?o?? o? ?????a??? ?????o?o ?????o?????????: ?????o? ?p????e???. C?pa??, c ?o?op??? ??????a ????????a ?a??? ?o??????, ? ???a??, ? ?o?o??? ??????o ??a???? ?o????. ??o? 5. Ca?? ? ?o???. ?????a ???op????? ? ?????e???a????? ?o?c????????? ????????e po???? ? ?a?o?e???? c?o??o???: ?p??????? ?o?? c?ap??? ? ?o?o?? ?????e???? ???e?c??, c?????a? ??a?????. C??? ?a? o??e?? ???e??e???a????? ?o?c?????????. ?a???? ????p?a???. ?o??? ? x?????? ?a? o?????? ??????????a????? ?o?c?????????. ?o????? o????? ??????e????????? co?c?????????. ?pe?o????? ? ?p???????? ??e??? ???e???????????? co???????????. ???op ?o?xo??? ? ?????e ???e???????????? ?o???????????. ??oc??? ??p???????? ??a??? ?o????. ???e??????? c???? ?a??a?????? ????e??. ?o??????e a??a ???o?o? ????ep???? ? ?o????????????: ?e?????? ?e??x?????? ?????e????, ?p???, ?c?o???, ?????o??? ?c???. ?c????????? ?a?o?? ??pa?????? ??e??p????? c ??p??????????: ?a?o???????????, ?a?????? ?o??po??, ????????op??? o?e????? ? ?p???? oc?????????. ??o? 6. Oco???????? p??o?? ??????c??? ?????p????? c ??p??????????: ?a?o?o?????????, ?a?????? ?o???o??, ????????o???? ??ep???? ? ?p???? o?o????????. C???? c ????a?o? po???? ??pe???????? - ec?? ?? ??a c???a?, ? ? ???o? ??e??????? ???e ???e??????? B?????? ?? p??o???? c ?e??????????? ?p? ??????e po????? ???o??????????? ??e????? c ?o????. ?????o????????? p?????p?????? ????a? p?????. Oc????????? ???o?o????????? ?o???? ? ?????x ??p????. K??p, ?e???o????????, ?a????, ?c????? ? ?p. E??? ?? ????e??????? ????c??? ?o??a????, ? ?a?a?? ?p?????e???? c??e?? ?o p????? c ?e?e?????????. ??p?????? ???c??????? ?o??????, ?o???a????? c?????, ?o???e???, ?e?????a??? ????????o? ? ?p???e ?co????????. ??????o??? ????a???. C??e?? ???o??????? ?????e??? (????c??????, ?o?????, ?o??????? ? ??p) ?o??????, ? ?a? o? ?ee ????????c? ?e??? ? ????p??? (?a?????, ?po????, ?po????) ???????e ??e?? ??? ??p?????????? ????a???. K?? ????a?? ?a??: ????e??? ???opa ????a. PE????E?? P?????????? c 9:00 ?o 9:30 ?a???? ? 9:30 ?????a???18:00 C?O??OC?? 1150.00 ?p?. ?a o??o?o ???c????a. ??? ??opo?o ? ?pe????o ??ac????? c????? ? 10% B c?o??oc?? ?xo???: ???op???????o-???????????????? o?c?????a??? ?a ce???a??, c?op??? ?a??p?????, ??????e, o?c???e??? ?o????o? ? o??e? ??e????? c ?e???po?. Ka???? ??ac???? ?o???ae? ??x?a??ep???? ?o???e?? ?????e??o?. ??????? ?????????????? ???????? ?????? ????? ?????????? ?????????? ??????? ??????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bouncepioppeto at gmail.com Sat Jun 22 06:07:51 2013 From: bouncepioppeto at gmail.com (Hotel Pioppeto saronno) Date: Sat, 22 Jun 2013 04:07:51 +0000 Subject: [atlas] A New look, a tailor made hospitality - Welcome and Welcome back Message-ID: <0000013f6a111423-5aa06e0f-aeb8-42da-96d5-c1fd33d77558-000000@email.amazonses.com> +39.0296248164 pioppeto at hotelpioppeto.it WWW.HOTELPIOPPETOSARONNO.IT Via Str? Madonna, 15 - 21047 Saronno (VA) - A9 Milano-Como-Chiasso motorway, Saronno exit -------------- next part -------------- An HTML attachment was scrubbed... URL: From sales13 at norminglights.com Mon Jun 24 04:03:21 2013 From: sales13 at norminglights.com (Jack) Date: Mon, 24 Jun 2013 10:03:21 +0800 Subject: [atlas] the one you look for. Message-ID: <51C7AC79.067CEB.29002@m97135.qiye.163.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 20132447094710410.jpg Type: image/jpeg Size: 33677 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 20132447094710514.jpg Type: image/jpeg Size: 28650 bytes Desc: not available URL: From carsten at schiefner.de Mon Jun 24 08:04:58 2013 From: carsten at schiefner.de (Carsten Schiefner) Date: Mon, 24 Jun 2013 08:04:58 +0200 Subject: [atlas] Spam on this list Message-ID: <51C7E18A.6090401@schiefner.de> Dear NCC colleagues, are the first ideas for counter-measures being already floated around internally about how to deal with the (increasing...) amount of spam mails being distributed via this list? Thanks and best: -C. From madis555 at hot.ee Mon Jun 24 09:25:54 2013 From: madis555 at hot.ee (Sulev-Madis Silber) Date: Mon, 24 Jun 2013 10:25:54 +0300 Subject: [atlas] Spam on this list In-Reply-To: <51C7E18A.6090401@schiefner.de> References: <51C7E18A.6090401@schiefner.de> Message-ID: <51C7F482.9050308@hot.ee> Is there any way we could subscribe some spammers into "premium plan" in RIPE Atlas? :) On 2013-06-24 09:04, Carsten Schiefner wrote: > Dear NCC colleagues, > > are the first ideas for counter-measures being already floated around > internally about how to deal with the (increasing...) amount of spam > mails being distributed via this list? > > Thanks and best: > > -C. > From carsten at schiefner.de Mon Jun 24 10:40:07 2013 From: carsten at schiefner.de (Carsten Schiefner) Date: Mon, 24 Jun 2013 10:40:07 +0200 Subject: [atlas] Spam on this list In-Reply-To: <51C7F482.9050308@hot.ee> References: <51C7E18A.6090401@schiefner.de> <51C7F482.9050308@hot.ee> Message-ID: +1 - they MUST host at least 2^10 probes! ;-D Am 24.06.2013 um 09:25 schrieb Sulev-Madis Silber : > Is there any way we could subscribe some spammers into "premium plan" in > RIPE Atlas? :) > > > On 2013-06-24 09:04, Carsten Schiefner wrote: >> Dear NCC colleagues, >> >> are the first ideas for counter-measures being already floated around >> internally about how to deal with the (increasing...) amount of spam >> mails being distributed via this list? >> >> Thanks and best: >> >> -C. >> From colinj at mx5.org.uk Mon Jun 24 10:43:46 2013 From: colinj at mx5.org.uk (Colin Johnston) Date: Mon, 24 Jun 2013 09:43:46 +0100 Subject: [atlas] Spam on this list In-Reply-To: References: <51C7E18A.6090401@schiefner.de> <51C7F482.9050308@hot.ee> Message-ID: <00F2099A-D219-41D8-84A9-6A702C2F4376@mx5.org.uk> Would to useful to use atlas to check for open mail relays and also denial of service route best practice checking. Colin Sent from my iPhone On 24 Jun 2013, at 09:40, Carsten Schiefner wrote: > +1 - they MUST host at least 2^10 probes! ;-D > > Am 24.06.2013 um 09:25 schrieb Sulev-Madis Silber : >> Is there any way we could subscribe some spammers into "premium plan" in >> RIPE Atlas? :) >> >> >> On 2013-06-24 09:04, Carsten Schiefner wrote: >>> Dear NCC colleagues, >>> >>> are the first ideas for counter-measures being already floated around >>> internally about how to deal with the (increasing...) amount of spam >>> mails being distributed via this list? >>> >>> Thanks and best: >>> >>> -C. > From BECHA at ripe.net Mon Jun 24 11:18:50 2013 From: BECHA at ripe.net (Vesna Manojlovic) Date: Mon, 24 Jun 2013 11:18:50 +0200 Subject: [atlas] Spam on this list In-Reply-To: <51C7E18A.6090401@schiefner.de> References: <51C7E18A.6090401@schiefner.de> Message-ID: <51C80EFA.3030509@ripe.net> Hi Carsten, all, On 6/24/13 8:04 AM, Carsten Schiefner wrote: > Dear NCC colleagues, > > are the first ideas for counter-measures being already floated around > internally about how to deal with the (increasing...) amount of spam > mails being distributed via this list? Yes, thanks for the reminder! I apologize for the spam you have been receiving, and we are investigating how did that happen, and what can we do to prevent it in the future. Regards, Vesna From bortzmeyer at nic.fr Mon Jun 24 15:35:02 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 24 Jun 2013 15:35:02 +0200 Subject: [atlas] No more a list of probes when the measurement is ongoing? Message-ID: <20130624133502.GA17879@nic.fr> I relied on a "probes" field in the data to find out the number of probes allocated to a measurement. Now, it is no longer available :-( % curl 'https://atlas.ripe.net/api/v1/measurement/1011817/?fields=' {"can_visualise": false, "creation_time": 1372080547, "description": "IPv4 base connectivity tests with 46.226.105.0", "dst_addr": "46.226.105.0", "dst_asn": null, "dst_name": "46.226.105.0", "interval": null, "is_oneoff": true, "is_public": true, "msm_id": 1011817, "packets": 3, "probe_sources": [["Area", "WW", 10]], "resolve_on_probe": false, "resolved_ips": ["46.226.105.0"], "result": "/api/v1/measurement/1011817/result/", "start_time": 1372080547, "status": {"id": 2, "name": "Ongoing"}, "stop_time": null, "type": {"id": 1, "name": "ping"}} What is its replacement? From dquinn at ripe.net Mon Jun 24 16:34:39 2013 From: dquinn at ripe.net (Daniel Quinn) Date: Mon, 24 Jun 2013 16:34:39 +0200 Subject: [atlas] No more a list of probes when the measurement is ongoing? In-Reply-To: <20130624133502.GA17879@nic.fr> References: <20130624133502.GA17879@nic.fr> Message-ID: <51C858FF.2070809@ripe.net> That's probably a bug I created when I tweaked the API to handle explicit field requests properly. I'll see what I can do to fix it today or tomorrow. *However* if you're using `fields=` and are only making use of a few fields *you are inadvertently hammering our servers for no good reason*. The `fields` modifier is there so you can request *specific fields*, not simply grab everything. If you use it in this way, your request will work as you need: https://atlas.ripe.net/api/v1/measurement/1011817/?fields=probes That'll return to you a list of all the probes used in measurement #1011817. If you want the probes and the `msm_id`, then just do this: https://atlas.ripe.net/api/v1/measurement/1011817/?fields=probes,msm_id ...repeat until you have *exactly* what you need and no more. You limit your bandwith consumption and the load on our servers. More importantly, the `fields=` trick is a hack that may not stick around for performance issues, so it's not a good idea to standardise on it. With that said though, as it was working this way before I broke it, I'll do what I can to fix it now :-) From bortzmeyer at nic.fr Mon Jun 24 16:40:54 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 24 Jun 2013 16:40:54 +0200 Subject: [atlas] No more a list of probes when the measurement is ongoing? In-Reply-To: <51C858FF.2070809@ripe.net> References: <20130624133502.GA17879@nic.fr> <51C858FF.2070809@ripe.net> Message-ID: <20130624144054.GA26679@nic.fr> On Mon, Jun 24, 2013 at 04:34:39PM +0200, Daniel Quinn wrote a message of 25 lines which said: > *However* if you're using `fields=` and are only making use of a few > fields *you are inadvertently hammering our servers for no good > reason*. I plead not guilty. This was an advice from Andreas Strikos and he uses this technique in his command-line tool :-) > https://atlas.ripe.net/api/v1/measurement/1011817/?fields=probes It works, thanks. > More importantly, the `fields=` trick is a hack that may not stick > around for performance issues, so it's not a good idea to > standardise on it. The problem for the Atlas user is that there is little documentation on creating and management measurements so it is hard to know what is stable and what is not and what are the things you can rely on. From bortzmeyer at nic.fr Thu Jun 27 10:47:01 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 27 Jun 2013 10:47:01 +0200 Subject: [atlas] [UDM creation API] Which parameters are mandatory? Message-ID: <20130627084701.GA7538@nic.fr> It seems that in (now linked from the Atlas documentation so I assume it is no longer in alpha test), there is no mention of which properties are mandatory and which are not. I have to resort to trial-and-error. For instance, for DNS measurements, the property query_class appear to be mandatory (otherwise, I get an error 400) which is suprising (it defaults to IN in all the DNS clients I know). From dquinn at ripe.net Thu Jun 27 11:31:58 2013 From: dquinn at ripe.net (Daniel Quinn) Date: Thu, 27 Jun 2013 11:31:58 +0200 Subject: [atlas] [UDM creation API] Which parameters are mandatory? In-Reply-To: <20130627084701.GA7538@nic.fr> References: <20130627084701.GA7538@nic.fr> Message-ID: <51CC068E.2020401@ripe.net> Actually, there are a lot of mentions of which fields were mandatory and which aren't, but you were right in stating that they weren't complete or were ambiguous. Thanks for that, I've gone ahead and updated the doc to reflect the required fields and default values for DNS measurements. I hope I've caught them all, but if you think I've missed one, please let us know. From bortzmeyer at nic.fr Thu Jun 27 11:45:48 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 27 Jun 2013 11:45:48 +0200 Subject: [atlas] [UDM creation API] Which parameters are mandatory? In-Reply-To: <51CC068E.2020401@ripe.net> References: <20130627084701.GA7538@nic.fr> <51CC068E.2020401@ripe.net> Message-ID: <20130627094548.GA14223@nic.fr> On Thu, Jun 27, 2013 at 11:31:58AM +0200, Daniel Quinn wrote a message of 6 lines which said: > I've gone ahead and updated the doc to reflect the required fields > and default values for DNS measurements. Perfect, thanks. I also like "Price Modifier". TCP is twice as expensive as UDP :-) From BECHA at ripe.net Thu Jun 27 13:35:44 2013 From: BECHA at ripe.net (Vesna Manojlovic) Date: Thu, 27 Jun 2013 13:35:44 +0200 Subject: [atlas] Spam on this list In-Reply-To: <51C80EFA.3030509@ripe.net> References: <51C7E18A.6090401@schiefner.de> <51C80EFA.3030509@ripe.net> Message-ID: <51CC2390.4090506@ripe.net> Hi again, On 6/24/13 11:18 AM, Vesna Manojlovic wrote: > Hi Carsten, all, > > On 6/24/13 8:04 AM, Carsten Schiefner wrote: >> Dear NCC colleagues, >> >> are the first ideas for counter-measures being already floated around >> internally about how to deal with the (increasing...) amount of spam >> mails being distributed via this list? this is what our operations people replied: > I have changed the spam filtering level from 8 to 6, so more "spam like" mail will be treated as spam. > > I have also switched on the option which will discard any posting from non-members As a moderator, I already saw one bounce due to these measures, so I hope this will reduce the number of spam. Regards, Vesna From carsten at schiefner.de Thu Jun 27 14:27:52 2013 From: carsten at schiefner.de (Carsten Schiefner) Date: Thu, 27 Jun 2013 14:27:52 +0200 Subject: [atlas] Spam on this list In-Reply-To: <51CC2390.4090506@ripe.net> References: <51C7E18A.6090401@schiefner.de> <51C80EFA.3030509@ripe.net> <51CC2390.4090506@ripe.net> Message-ID: Thanks, Vesna and whoever else has been involved in settling this. Best, -C. -- Diese Nachricht wurde von meinem aPad gesendet. -----Original Message----- From: Vesna Manojlovic To: Carsten Schiefner Cc: ripe-atlas at ripe.net Sent: Do., 27 Jun 2013 13:35 Subject: Re: [atlas] Spam on this list Hi again, On 6/24/13 11:18 AM, Vesna Manojlovic wrote: > Hi Carsten, all, > > On 6/24/13 8:04 AM, Carsten Schiefner wrote: >> Dear NCC colleagues, >> >> are the first ideas for counter-measures being already floated around >> internally about how to deal with the (increasing...) amount of spam >> mails being distributed via this list? this is what our operations people replied: > I have changed the spam filtering level from 8 to 6, so more "spam like" mail will be treated as spam. > > I have also switched on the option which will discard any posting from non-members As a moderator, I already saw one bounce due to these measures, so I hope this will reduce the number of spam. Regards, Vesna -------------- next part -------------- An HTML attachment was scrubbed... URL: