From marty at martystrong.co.uk Tue Dec 1 11:34:23 2015 From: marty at martystrong.co.uk (Marty Strong) Date: Tue, 1 Dec 2015 10:34:23 +0000 Subject: [atlas] Dead probes - slightly OT In-Reply-To: <56321485.7000708@cc.univie.ac.at> References: <562A03E2.2020406@ripe.net> <5630F839.1020506@cc.univie.ac.at> <20151028165059.GE70452@Space.Net> <5631D7CE.7070806@ripe.net> <56321485.7000708@cc.univie.ac.at> Message-ID: I have a dead probe that I've tried both waiting 10 minutes with the USB stick out and placing a fresh USB stick in, but it still sits on what looks like running from internal flash. Is there another method anybody knows that can bring this old probe back to life? On 29 October 2015 at 12:43, Wilfried Woeber wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Philip, > thanks for the explanation! > > Wilfried > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQIcBAEBAgAGBQJWMhRuAAoJEPMGt0I/M2zSRSQP/AzOPEcdiLN3FAXgKi0MyuSC > ASKChSMRIW3Wg1BCxdJP3mDSGAIXOxraaSOsYf5D+LozJEgm9Kj9dfqDvEZVwpmq > w/F/AaGgiTcvPVIaJ+M5czRIew40DoddNjxnGVCvFkg1YFo4tbJqInca72WvPnXi > wnJhbmeHoWwGOAjGWSNu5yi/NahluPJ7G7HO7m40jYt9qvJiAYWYqGB418aSFY6G > fUZbvgQ3TQZaXtXK7Ykw0IqTGKIQTSid2Jqpq9xBlqTDrOae/xidN41G2jDEuLKy > PIZhnUIxmy02hfbhjAWDbSs+/3I9CiRChrsdmISzXSsOuwBz6mRIzg0/dmVd60ry > xJdkYT1pgDVCAAtmrBoTyuPjOpzSoTSM+BXuzaf+ZgOintnlCvqyAzLUX8Ln0j1s > F/49+RbNrHDKvysVRm94kqLXxeGROBJ7+wYCpfkCzLyKcmlLfS8/UAFU1AzcPceb > /WUqPuK7CSiSye0MGFSUmQGhxucRm18teuZdNq/0u44l5W3M2c34xmUkc4KXcr1E > uMmtnzaVMxX0jMWnD+JPZ7M9J692gvr198I0WhYPK22FpRJ1vgimpSgDRkP8yXoP > aSFQGFT4qedokrzex5Ctb+Vpeq6Q9VxCxIDxCjMEnIGyZo3sMTimducVOLpGMsnP > dfcjtAus5F8FNZEHBXY6 > =Q4lG > -----END PGP SIGNATURE----- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.bajpai at jacobs-university.de Tue Dec 1 12:28:05 2015 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Tue, 1 Dec 2015 11:28:05 +0000 Subject: [atlas] location field in probe API Message-ID: <1BACBD1B-2D85-4163-9B6F-E4C0EA06FDF3@jacobs-university.de> Hello, TL;DR: The probe API does not expose the probe location even if I explicitly ask for it. location: A human readable location for this probe, either explicitly specified by the probe owner, or derived from the longitude and latitude. It appears the 'location' field in the probe API is hidden by default and it must be explicitly set in the request parameters to expose location field values. However, even if I do set it, I still don't get location entries. I made multiple permutations of query requests and also tried the usage example on the API documentation webpage [1]: Get the IPv4 addresses and the usually hidden human readable location string for public probes in Germany: https://atlas.ripe.net/api/v1/probe/?country_code=de&is_public=true&fields=location,address_v4 What could be wrong? -- Thanks! PS: It seems, this field is also missing in the probe archive API. [1] https://atlas.ripe.net/docs/rest/#probe Best, Vaibhav ===================================================== Vaibhav Bajpai Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com ===================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From c.estelmann at gmx.net Tue Dec 1 13:14:40 2015 From: c.estelmann at gmx.net (Estelmann, Christian) Date: Tue, 1 Dec 2015 13:14:40 +0100 Subject: [atlas] Dead probes - slightly OT In-Reply-To: References: <562A03E2.2020406@ripe.net> <5630F839.1020506@cc.univie.ac.at> <20151028165059.GE70452@Space.Net> <5631D7CE.7070806@ripe.net> <56321485.7000708@cc.univie.ac.at> Message-ID: <565D8F30.2060609@gmx.net> The capacity of the stick must be larger than ~3 GB. On the stick will be three partitions, 1 GB size each. It is simple written to the partition table that there are this partitions, it doesn't matter whether this is possible or not (e.g. the stick has only a capacity of 2 GB). This is only my experience. Last time my USB stick broke down I first tried to replace it by a stick with a capacity of 2 GB only. The probe wrote some data to the stick (the LED of the stick was blinking) but then the probe hang in a boot loop. After plugging the USB stick into my pc fdisk showed me that there are this three partitions. Am 01.12.2015 um 11:34 schrieb Marty Strong: > I have a dead probe that I've tried both waiting 10 minutes with the USB > stick out and placing a fresh USB stick in, but it still sits on what > looks like running from internal flash. > > Is there another method anybody knows that can bring this old probe back > to life? > > On 29 October 2015 at 12:43, Wilfried Woeber > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Philip, > thanks for the explanation! > > Wilfried > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQIcBAEBAgAGBQJWMhRuAAoJEPMGt0I/M2zSRSQP/AzOPEcdiLN3FAXgKi0MyuSC > ASKChSMRIW3Wg1BCxdJP3mDSGAIXOxraaSOsYf5D+LozJEgm9Kj9dfqDvEZVwpmq > w/F/AaGgiTcvPVIaJ+M5czRIew40DoddNjxnGVCvFkg1YFo4tbJqInca72WvPnXi > wnJhbmeHoWwGOAjGWSNu5yi/NahluPJ7G7HO7m40jYt9qvJiAYWYqGB418aSFY6G > fUZbvgQ3TQZaXtXK7Ykw0IqTGKIQTSid2Jqpq9xBlqTDrOae/xidN41G2jDEuLKy > PIZhnUIxmy02hfbhjAWDbSs+/3I9CiRChrsdmISzXSsOuwBz6mRIzg0/dmVd60ry > xJdkYT1pgDVCAAtmrBoTyuPjOpzSoTSM+BXuzaf+ZgOintnlCvqyAzLUX8Ln0j1s > F/49+RbNrHDKvysVRm94kqLXxeGROBJ7+wYCpfkCzLyKcmlLfS8/UAFU1AzcPceb > /WUqPuK7CSiSye0MGFSUmQGhxucRm18teuZdNq/0u44l5W3M2c34xmUkc4KXcr1E > uMmtnzaVMxX0jMWnD+JPZ7M9J692gvr198I0WhYPK22FpRJ1vgimpSgDRkP8yXoP > aSFQGFT4qedokrzex5Ctb+Vpeq6Q9VxCxIDxCjMEnIGyZo3sMTimducVOLpGMsnP > dfcjtAus5F8FNZEHBXY6 > =Q4lG > -----END PGP SIGNATURE----- > > From boesen at belwue.de Tue Dec 1 13:16:30 2015 From: boesen at belwue.de (Andreas Boesen) Date: Tue, 1 Dec 2015 13:16:30 +0100 Subject: [atlas] Dead probes - slightly OT In-Reply-To: References: <562A03E2.2020406@ripe.net> <5630F839.1020506@cc.univie.ac.at> <20151028165059.GE70452@Space.Net> <5631D7CE.7070806@ripe.net> <56321485.7000708@cc.univie.ac.at> Message-ID: <565D8F9E.7010001@belwue.de> Hi, Am 01.12.2015 um 11:34 schrieb Marty Strong: > I have a dead probe that I've tried both waiting 10 minutes with the USB > stick out and placing a fresh USB stick in, but it still sits on what > looks like running from internal flash. > > Is there another method anybody knows that can bring this old probe back > to life? https://wiki.openwrt.org/toh/tp-link/tl-mr3020#gpio_pinout I read that you can "debrick" a "home router" via the JTAG interface. But the TL-MR3020 only gives you GPIO ... maybe that works just fine, too. AFAIK RIPE does not want you to flash a probe yourself. So flashing the firmware yourself is probably not possible. But at least looking at the boot log (serial console) could maybe help you spot the problem. Best regards, Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: OpenPGP digital signature URL: From philip.homburg at ripe.net Tue Dec 1 13:25:08 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 1 Dec 2015 13:25:08 +0100 Subject: [atlas] Dead probes - slightly OT In-Reply-To: References: <562A03E2.2020406@ripe.net> <5630F839.1020506@cc.univie.ac.at> <20151028165059.GE70452@Space.Net> <5631D7CE.7070806@ripe.net> <56321485.7000708@cc.univie.ac.at> Message-ID: <565D91A4.6050308@ripe.net> On 2015/12/01 11:34 , Marty Strong wrote: > I have a dead probe that I've tried both waiting 10 minutes with the USB > stick out and placing a fresh USB stick in, but it still sits on what > looks like running from internal flash. > > Is there another method anybody knows that can bring this old probe back > to life? Hi Marty, In these cases it is best to start with a mail to atlas at ripe.net, which is our ticketing system. If the probe still works a bit, then there might be log records. Philip From marty at martystrong.co.uk Wed Dec 2 00:26:08 2015 From: marty at martystrong.co.uk (Marty Strong) Date: Tue, 1 Dec 2015 23:26:08 +0000 Subject: [atlas] Dead probes - slightly OT In-Reply-To: <565D91A4.6050308@ripe.net> References: <562A03E2.2020406@ripe.net> <5630F839.1020506@cc.univie.ac.at> <20151028165059.GE70452@Space.Net> <5631D7CE.7070806@ripe.net> <56321485.7000708@cc.univie.ac.at> <565D91A4.6050308@ripe.net> Message-ID: I couldn't see any SOS history sadly :( But mail sent nonetheless. On 1 December 2015 at 12:25, Philip Homburg wrote: > On 2015/12/01 11:34 , Marty Strong wrote: > > I have a dead probe that I've tried both waiting 10 minutes with the USB > > stick out and placing a fresh USB stick in, but it still sits on what > > looks like running from internal flash. > > > > Is there another method anybody knows that can bring this old probe back > > to life? > > Hi Marty, > > In these cases it is best to start with a mail to atlas at ripe.net, which > is our ticketing system. > > If the probe still works a bit, then there might be log records. > > Philip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From camin at ripe.net Thu Dec 3 15:27:25 2015 From: camin at ripe.net (Chris Amin) Date: Thu, 3 Dec 2015 15:27:25 +0100 Subject: [atlas] New on RIPE Labs: DomainMON in RIPE Atlas Message-ID: <5660514D.6010405@ripe.net> Dear colleagues, A few weeks ago we gave you a heads up about a new visualisation tool in RIPE Atlas called DomainMON, and we're pleased to announce that this is now available for all RIPE Atlas users with available credits. Please find more details on RIPE Labs: https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-domainmon-is-here Kind regards, Chris Amin RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From thomas.kessler at gmx.net Fri Dec 4 15:09:14 2015 From: thomas.kessler at gmx.net (Kessler, Thomas) Date: Fri, 4 Dec 2015 21:09:14 +0700 Subject: [atlas] Turris Omnia as probe Platform? Message-ID: Dear all, some of you are probably aware of the Turris Omnia project by CZ.NIC ( https://www.indiegogo.com/projects/turris-omnia-hi-performance-open-source-router/x/9304546#/story ). This might be an interesting platform for running an VM probe?! Just thought it might be worth brining it up here for discussion. Cheers Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Fri Dec 4 17:39:44 2015 From: gert at space.net (Gert Doering) Date: Fri, 4 Dec 2015 17:39:44 +0100 Subject: [atlas] Turris Omnia as probe Platform? In-Reply-To: References: Message-ID: <20151204163944.GV89490@Space.Net> Hi, On Fri, Dec 04, 2015 at 09:09:14PM +0700, Kessler, Thomas wrote: > This might be an interesting platform for running an VM probe?! I think there is no lack of "interesting platforms to host a VM", but the point of the discussion was "virtualizing measurements leads to unreliable results as you do not control the hardware well enough" - and for that reason, I'd strongly discourage *any* sort of VM solution. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From danny at danysek.cz Fri Dec 4 23:30:34 2015 From: danny at danysek.cz (Daniel Suchy) Date: Fri, 4 Dec 2015 23:30:34 +0100 Subject: [atlas] Turris Omnia as probe Platform? In-Reply-To: <20151204163944.GV89490@Space.Net> References: <20151204163944.GV89490@Space.Net> Message-ID: <5662140A.80100@danysek.cz> Hello, I don't fully agree here. There're always so many things, which may involve measurement realiability just on first from the probe. You always believe, that "hardware" probe is more reliable. Not, it isn't - current probe itself is quite cheap piece of not-so-powerfull hardware. And if someone want's to trick measurement, he can - there're so many ways. You don't have any kind of control on network behind the probe - and that's more important part in terms of reliable measurements... Many thing are going virtual around us (even on high-end routing platforms). Virtualised probe can be more reliable in terms of computing power compared to small TP-Links & so-on. Turris itself is very powerfull hardware (and it's open, both HW & SW). Some kind of integration between Atlas & Turris is good idea in my oppinion. Requirement of hardware-probe is in 'old-school' point of view. And at least with v3 of probes, it's harder to keep probe alive (dying "low-cost" USB flash is big issue...). With regards, Daniel On 4.12.2015 17:39, Gert Doering wrote: > Hi, > > On Fri, Dec 04, 2015 at 09:09:14PM +0700, Kessler, Thomas wrote: >> This might be an interesting platform for running an VM probe?! > > I think there is no lack of "interesting platforms to host a VM", but > the point of the discussion was "virtualizing measurements leads to > unreliable results as you do not control the hardware well enough" - and > for that reason, I'd strongly discourage *any* sort of VM solution. > > gert > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4233 bytes Desc: S/MIME Cryptographic Signature URL: From randy at psg.com Sat Dec 5 02:59:50 2015 From: randy at psg.com (Randy Bush) Date: Sat, 05 Dec 2015 10:59:50 +0900 Subject: [atlas] Turris Omnia as probe Platform? In-Reply-To: <20151204163944.GV89490@Space.Net> References: <20151204163944.GV89490@Space.Net> Message-ID: > I think there is no lack of "interesting platforms to host a VM", but > the point of the discussion was "virtualizing measurements leads to > unreliable results as you do not control the hardware well enough" - and > for that reason, I'd strongly discourage *any* sort of VM solution. i strongly agree that vms risk reducing the precision of results. i am less sure this makes them useless or dangerous if clearly marked, as in probe version, perhaps. heck, if i want precision below ~15ms, i would be leery of v1 and v2 probes. otoh, nlring is mostly virtual and has its uses. but probes are so small and sufficiently cheap that i question the utility of maintaining a vm-based infrastructure. ymmv. randy, a researcher who uses atlas data, sometimes for timing sometimes not From bjonglez at illyse.org Sat Dec 5 14:43:31 2015 From: bjonglez at illyse.org (Baptiste Jonglez) Date: Sat, 5 Dec 2015 14:43:31 +0100 Subject: [atlas] Map-based visualisations for Atlas data Message-ID: <20151205134331.GA15161@illyse.org> Hi, Is there a way to reuse and adapt the code for the maps available here? https://atlas.ripe.net/results/maps/ It could be interesting to have a generic map-based visualisation, where all probes matching a certain set of conditions would be displayed. Possible applications include: - monitor IPv6 deployment for an AS, by displaying all probes matching "asn_v6 = XX". It would probably be useful to also display probes matching "asn_v4 = XX", as a baseline, using a different color - monitor DNS resolver outage geographically, by matching on system tags like "resolving A doesn't work". - match on user tags, like "IXP" or "core", to monitor deployment of Atlas at specific locations/types of networks. In all those examples, the "time slider" functionality would be extremely useful, to see the evolution over time. It could be even nicer if the slider could move automatically, so as to provide nice animations. Is all this currently feasible, and if not, would it be hard to implement? Thanks, Baptiste -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From gert at space.net Sat Dec 5 17:27:44 2015 From: gert at space.net (Gert Doering) Date: Sat, 5 Dec 2015 17:27:44 +0100 Subject: [atlas] Turris Omnia as probe Platform? In-Reply-To: <5662140A.80100@danysek.cz> References: <20151204163944.GV89490@Space.Net> <5662140A.80100@danysek.cz> Message-ID: <20151205162744.GX89490@Space.Net> On Fri, Dec 04, 2015 at 11:30:34PM +0100, Daniel Suchy wrote: > I don't fully agree here. There're always so many things, which may > involve measurement realiability just on first from the probe. You > always believe, that "hardware" probe is more reliable. Not, it isn't - > current probe itself is quite cheap piece of not-so-powerfull hardware. > And if someone want's to trick measurement, he can - there're so many > ways. You don't have any kind of control on network behind the probe - > and that's more important part in terms of reliable measurements... The thing is "we perfectly well know the characteristics of the measuring device". Everything deviating from the norm will be caused by the network, not "something in the VM environment". > Many thing are going virtual around us (even on high-end routing > platforms). Virtualised probe can be more reliable in terms of computing > power compared to small TP-Links & so-on. Computing power is totally unimportant as compared to reproduceability of a given measurement on a given probe. Of course a VM is more powerful than either of these probes, but does this make it more suitable to be part of Atlas? I say no, because for a measurement platform, "raw power" is not the key issue. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5023 bytes Desc: not available URL: From joao at bondis.org Sat Dec 5 18:02:49 2015 From: joao at bondis.org (=?utf-8?Q?Jo=C3=A3o_Damas?=) Date: Sat, 5 Dec 2015 18:02:49 +0100 Subject: [atlas] Turris Omnia as probe Platform? In-Reply-To: <20151205162744.GX89490@Space.Net> References: <20151204163944.GV89490@Space.Net> <5662140A.80100@danysek.cz> <20151205162744.GX89490@Space.Net> Message-ID: What you want from the probe is predictability in the form of minimal jitter and possibly some calibration (to equate latency). IF the Turris people can run the Atlas code with some sort of real-time scheduling then it is going to be OK as a probe. Can they? If it is a process competing with whatever else the router might be doing at the time then I agree, it wouldn?t be suitable as a probe for things that involve precise time measurements, although they could still run the set of measurements for which precise timing is not necessary (routing, DNS, etc). In the Atlas probe all software is under control of one party and *I guess* doesn?t interfere with the rest of the software running on them. The criteria should be reproducibility of the experiment, not whether it is a VM or something else. Just my opinion Joao > On 05 Dec 2015, at 17:27, Gert Doering wrote: > > > On Fri, Dec 04, 2015 at 11:30:34PM +0100, Daniel Suchy wrote: >> I don't fully agree here. There're always so many things, which may >> involve measurement realiability just on first from the probe. You >> always believe, that "hardware" probe is more reliable. Not, it isn't - >> current probe itself is quite cheap piece of not-so-powerfull hardware. >> And if someone want's to trick measurement, he can - there're so many >> ways. You don't have any kind of control on network behind the probe - >> and that's more important part in terms of reliable measurements... > > The thing is "we perfectly well know the characteristics of the measuring > device". Everything deviating from the norm will be caused by the network, > not "something in the VM environment". > >> Many thing are going virtual around us (even on high-end routing >> platforms). Virtualised probe can be more reliable in terms of computing >> power compared to small TP-Links & so-on. > > Computing power is totally unimportant as compared to reproduceability > of a given measurement on a given probe. > > Of course a VM is more powerful than either of these probes, but does this > make it more suitable to be part of Atlas? I say no, because for a > measurement platform, "raw power" is not the key issue. > > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From tomas.hlavacek at nic.cz Sat Dec 5 19:29:22 2015 From: tomas.hlavacek at nic.cz (tomas.hlavacek at nic.cz) Date: Sat, 05 Dec 2015 19:29:22 +0100 Subject: [atlas] Turris Omnia as probe Platform? In-Reply-To: References: <20151204163944.GV89490@Space.Net> <5662140A.80100@danysek.cz> <20151205162744.GX89490@Space.Net> Message-ID: <1449340162.18525.17@smtp.gmail.com> Hi! On Sat, Dec 5, 2015 at 6:02 PM, Jo?o Damas wrote: > What you want from the probe is predictability in the form of minimal > jitter and possibly some calibration (to equate latency). IF the > Turris people can run the Atlas code with some sort of real-time > scheduling then it is going to be OK as a probe. Can they? It depends on what level of control you need. The board will be supported by vanilla Linux kernel (we are almost there). So you/we can compile in whatever is needed. The hardware should be more than enough for routing (=processing input IRQs from NICs and forwarding) and almost everything else can be prioritized. But I suppose we need to discuss that into more detail to address all possible interactions. Is there some documentation of kernel tuning in the current probes? And the probe could perform self-tests periodically and disable itself either temporarily or permanently if the router fails the test. > > > If it is a process competing with whatever else the router might be > doing at the time then I agree, it wouldn?t be suitable as a probe > for things that involve precise time measurements, although they > could still run the set of measurements for which precise timing is > not necessary (routing, DNS, etc). In the Atlas probe all software is > under control of one party and *I guess* doesn?t interfere with the > rest of the software running on them. I personally (though I am the Turris kernel guy) think that we can cooperate on determining interactions and tune the basic system for the probe, if needed. But I suppose that we won't be shipping the routers with the probe turned on by default anyway. From my point of view it would make sense to do more general work in this direction. It boils down to the question whether we can have the probe in form of a daemon? Of course there have to be some requirements for reliable operation, that can be enforced on the OS side and checked on the daemon side. But it does not make sense to think of them if the software probe is still deemed undesirable. Is it? Tomas From randy at psg.com Sun Dec 6 10:28:44 2015 From: randy at psg.com (Randy Bush) Date: Sun, 06 Dec 2015 18:28:44 +0900 Subject: [atlas] Turris Omnia as probe Platform? In-Reply-To: <20151205162744.GX89490@Space.Net> References: <20151204163944.GV89490@Space.Net> <5662140A.80100@danysek.cz> <20151205162744.GX89490@Space.Net> Message-ID: > Computing power is totally unimportant as compared to reproduceability > of a given measurement on a given probe. 100% with you there. but, for example, is fetching a dane tlsa or a browser cert gonna be bothered by the kinds of things which vms do to us? the problem with this path is that we fragment what measurements can be done on which probes, a major pain. randy From magicsata at gmail.com Sun Dec 6 13:22:51 2015 From: magicsata at gmail.com (Alistair Mackenzie) Date: Sun, 6 Dec 2015 12:22:51 +0000 Subject: [atlas] Probe power down. Message-ID: Hi all, I'm currently moving house and expect my probe to be offline for approximately one week, Is there any formal channels that I must notify ripe of this other than the location change once it's back online? Thanks, Alistair -------------- next part -------------- An HTML attachment was scrubbed... URL: From michabailey at gmail.com Sun Dec 6 16:39:26 2015 From: michabailey at gmail.com (Micha Bailey) Date: Sun, 6 Dec 2015 17:39:26 +0200 Subject: [atlas] Probe power down. In-Reply-To: References: Message-ID: Section 5.5 of the terms of service require best-effort uptime, and it requires notification if you want to take the probe offline indefinitely. I don't believe there's any other notification requirement. On Sunday, December 6, 2015, Alistair Mackenzie wrote: > Hi all, > > I'm currently moving house and expect my probe to be offline for > approximately one week, > > Is there any formal channels that I must notify ripe of this other than > the location change once it's back online? > > Thanks, > Alistair > -------------- next part -------------- An HTML attachment was scrubbed... URL: From budiwijaya at ipv6.or.id Sun Dec 6 23:45:04 2015 From: budiwijaya at ipv6.or.id (Budiwijaya) Date: Mon, 7 Dec 2015 05:45:04 +0700 Subject: [atlas] Probe power down. In-Reply-To: References: Message-ID: Micha, can you give me the url? On Sun, Dec 6, 2015 at 10:39 PM, Micha Bailey wrote: > Section 5.5 of the terms of service require best-effort uptime, and it > requires notification if you want to take the probe offline indefinitely. I > don't believe there's any other notification requirement. > > > On Sunday, December 6, 2015, Alistair Mackenzie wrote: >> >> Hi all, >> >> I'm currently moving house and expect my probe to be offline for >> approximately one week, >> >> Is there any formal channels that I must notify ripe of this other than >> the location change once it's back online? >> >> Thanks, >> Alistair From michabailey at gmail.com Mon Dec 7 05:06:25 2015 From: michabailey at gmail.com (Micha Bailey) Date: Mon, 7 Dec 2015 06:06:25 +0200 Subject: [atlas] Probe power down. In-Reply-To: References: Message-ID: http://bfy.tw/39cQ On Monday, December 7, 2015, Budiwijaya wrote: > Micha, can you give me the url? > > On Sun, Dec 6, 2015 at 10:39 PM, Micha Bailey > wrote: > > Section 5.5 of the terms of service require best-effort uptime, and it > > requires notification if you want to take the probe offline > indefinitely. I > > don't believe there's any other notification requirement. > > > > > > On Sunday, December 6, 2015, Alistair Mackenzie > wrote: > >> > >> Hi all, > >> > >> I'm currently moving house and expect my probe to be offline for > >> approximately one week, > >> > >> Is there any formal channels that I must notify ripe of this other than > >> the location change once it's back online? > >> > >> Thanks, > >> Alistair > -------------- next part -------------- An HTML attachment was scrubbed... URL: From camin at ripe.net Mon Dec 7 12:47:23 2015 From: camin at ripe.net (Chris Amin) Date: Mon, 7 Dec 2015 12:47:23 +0100 Subject: [atlas] New on RIPE Labs: DomainMON in RIPE Atlas) In-Reply-To: <5660514D.6010405@ripe.net> References: <5660514D.6010405@ripe.net> Message-ID: <566571CB.3000202@ripe.net> Dear RIPE Atlas users, Unfortunately there was a problem which prevented some users from adding extra name servers to domains that they had already started monitoring with DomainMON. This has now been resolved. Apologies for any inconvenience caused. Kind regards, Chris Amin RIPE NCC On 03/12/2015 15:27, Chris Amin wrote: > Dear colleagues, > > A few weeks ago we gave you a heads up about a new visualisation tool in > RIPE Atlas called DomainMON, and we're pleased to announce that this is > now available for all RIPE Atlas users with available credits. Please > find more details on RIPE Labs: > > https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-domainmon-is-here > > Kind regards, > Chris Amin > RIPE NCC > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From joao at bondis.org Mon Dec 7 13:05:14 2015 From: joao at bondis.org (=?utf-8?Q?Jo=C3=A3o_Damas?=) Date: Mon, 7 Dec 2015 13:05:14 +0100 Subject: [atlas] Turris Omnia as probe Platform? In-Reply-To: <1449340162.18525.17@smtp.gmail.com> References: <20151204163944.GV89490@Space.Net> <5662140A.80100@danysek.cz> <20151205162744.GX89490@Space.Net> <1449340162.18525.17@smtp.gmail.com> Message-ID: <1CF82EC1-45A1-4061-B066-46550603CAEE@bondis.org> > On 05 Dec 2015, at 19:29, tomas.hlavacek at nic.cz wrote: > > Hi! > > On Sat, Dec 5, 2015 at 6:02 PM, Jo?o Damas wrote: >> What you want from the probe is predictability in the form of minimal jitter and possibly some calibration (to equate latency). IF the Turris people can run the Atlas code with some sort of real-time scheduling then it is going to be OK as a probe. Can they? > > It depends on what level of control you need. The board will be supported by vanilla Linux kernel (we are almost there). So you/we can compile in whatever is needed. > Schedule determinism (some sort of real time kernel extension) : to send probe traffic in a predictable manner Accurate time-of-arrival stamping for incoming packets, so you can trust the measurement. Joao -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From robert at ripe.net Tue Dec 8 09:34:31 2015 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 8 Dec 2015 09:34:31 +0100 Subject: [atlas] Turris Omnia as probe Platform? In-Reply-To: <1449340162.18525.17@smtp.gmail.com> References: <20151204163944.GV89490@Space.Net> <5662140A.80100@danysek.cz> <20151205162744.GX89490@Space.Net> <1449340162.18525.17@smtp.gmail.com> Message-ID: <56669617.6040108@ripe.net> > I personally (though I am the Turris kernel guy) think that we can cooperate > on determining interactions and tune the basic system for the probe, if > needed. But I suppose that we won't be shipping the routers with the probe > turned on by default anyway. The probe's measurement source code is published on the website. We're not using any special kernel tweaks. Cheers, Robert From robert at ripe.net Tue Dec 8 09:50:21 2015 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 8 Dec 2015 09:50:21 +0100 Subject: [atlas] Map-based visualisations for Atlas data In-Reply-To: <20151205134331.GA15161@illyse.org> References: <20151205134331.GA15161@illyse.org> Message-ID: <566699CD.9030502@ripe.net> Hi, On 2015-12-05 14:43, Baptiste Jonglez wrote: > Hi, > > Is there a way to reuse and adapt the code for the maps available here? > > https://atlas.ripe.net/results/maps/ > > It could be interesting to have a generic map-based visualisation, where > all probes matching a certain set of conditions would be displayed. > > Possible applications include: > > - monitor IPv6 deployment for an AS, by displaying all probes matching > "asn_v6 = XX". It would probably be useful to also display probes > matching "asn_v4 = XX", as a baseline, using a different color > > - monitor DNS resolver outage geographically, by matching on system tags > like "resolving A doesn't work". > > - match on user tags, like "IXP" or "core", to monitor deployment of Atlas > at specific locations/types of networks. There's some development needed, but it'd be possible to add a generic map that is filterable by probe tags (and other filters present today). What we cannot do today is doing this historically, as that'd require keeping track of probe tag status for all probes at arbitrary points in time. > In all those examples, the "time slider" functionality would be extremely > useful, to see the evolution over time. It could be even nicer if the > slider could move automatically, so as to provide nice animations. The time travel functionality is available on all maps (unless we forgot some :-) where the measurement is/was ongoing. We tried doing animations / movies and while it's not impossible, it's extremely resource intensive both on the server and the client side (for 9K probes...). It's possible to do it as a gimmick, but we don't see it as a realistic public service. Regards, Robert > Is all this currently feasible, and if not, would it be hard to implement? > > Thanks, > Baptiste > From emile.aben at ripe.net Tue Dec 8 10:05:34 2015 From: emile.aben at ripe.net (Emile Aben) Date: Tue, 8 Dec 2015 10:05:34 +0100 Subject: [atlas] Map-based visualisations for Atlas data In-Reply-To: <566699CD.9030502@ripe.net> References: <20151205134331.GA15161@illyse.org> <566699CD.9030502@ripe.net> Message-ID: <56669D5E.2010704@ripe.net> On 08/12/15 09:50, Robert Kisteleki wrote: > Hi, > > On 2015-12-05 14:43, Baptiste Jonglez wrote: >> Hi, >> >> Is there a way to reuse and adapt the code for the maps available here? >> >> https://atlas.ripe.net/results/maps/ >> >> It could be interesting to have a generic map-based visualisation, where >> all probes matching a certain set of conditions would be displayed. >> >> Possible applications include: >> >> - monitor IPv6 deployment for an AS, by displaying all probes matching >> "asn_v6 = XX". It would probably be useful to also display probes >> matching "asn_v4 = XX", as a baseline, using a different color >> >> - monitor DNS resolver outage geographically, by matching on system tags >> like "resolving A doesn't work". >> >> - match on user tags, like "IXP" or "core", to monitor deployment of Atlas >> at specific locations/types of networks. > > There's some development needed, but it'd be possible to add a generic map > that is filterable by probe tags (and other filters present today). What we > cannot do today is doing this historically, as that'd require keeping track > of probe tag status for all probes at arbitrary points in time. > >> In all those examples, the "time slider" functionality would be extremely >> useful, to see the evolution over time. It could be even nicer if the >> slider could move automatically, so as to provide nice animations. > > The time travel functionality is available on all maps (unless we forgot > some :-) where the measurement is/was ongoing. > > We tried doing animations / movies and while it's not impossible, it's > extremely resource intensive both on the server and the client side (for 9K > probes...). It's possible to do it as a gimmick, but we don't see it as a > realistic public service. Experiments with external platforms like CartoDB do work though: https://labs.ripe.net/Members/emileaben/visualising-network-outages-with-ripe-atlas (figures 2) but just animation without other info is quite hard to follow (at least for me), so i think adding more information ( like figure 4 ) is very helpful if you want to make stuff more then a gimmick. cheers, Emile From bortzmeyer at nic.fr Tue Dec 8 16:03:12 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 8 Dec 2015 16:03:12 +0100 Subject: [atlas] DNSmon "not indicative of what happens to normal traffic" claims the root ops Message-ID: <20151208150312.GA23627@laperouse.bortzmeyer.org> http://root-servers.org/news/events-of-20151130.txt From nicolas at ncartron.org Tue Dec 8 16:16:35 2015 From: nicolas at ncartron.org (Nico CARTRON) Date: Tue, 8 Dec 2015 16:16:35 +0100 Subject: [atlas] DNSmon "not indicative of what happens to normal traffic" claims the root ops In-Reply-To: <20151208150312.GA23627@laperouse.bortzmeyer.org> References: <20151208150312.GA23627@laperouse.bortzmeyer.org> Message-ID: On 8 December 2015 at 16:07:02, Stephane Bortzmeyer (bortzmeyer at nic.fr) wrote: http://root-servers.org/news/events-of-20151130.txt? Thanks St?phane for your reactivity, as usual :) ?Such test traffic may not be indicative of what happens to normal traffic or user experience?. Not entirely sure what this means behind, or is it just them trying to minimise the impact? Cheers, --? Nico -------------- next part -------------- An HTML attachment was scrubbed... URL: From camin at ripe.net Tue Dec 8 16:34:58 2015 From: camin at ripe.net (Chris Amin) Date: Tue, 8 Dec 2015 16:34:58 +0100 Subject: [atlas] DNSmon "not indicative of what happens to normal traffic" claims the root ops In-Reply-To: References: <20151208150312.GA23627@laperouse.bortzmeyer.org> Message-ID: <5666F8A2.5030208@ripe.net> On 08/12/2015 16:16, Nico CARTRON wrote: > On 8 December 2015 at 16:07:02, Stephane Bortzmeyer (bortzmeyer at nic.fr > ) wrote: >> http://root-servers.org/news/events-of-20151130.txt > > Thanks St?phane for your reactivity, as usual :) > > ?Such test traffic may not be indicative of what happens to normal > traffic or user experience?. > > Not entirely sure what this means behind, or is it just them trying to > minimise the impact? It could be a bit of expectation management on their part. I agree with the statement that DNSMON and other similar tools do not provide direct insight into end user experience, but that is also not their goal. DNSMON at least is deliberately designed to measure from stable vantage points (RIPE Atlas anchors, formerly TTM boxes), and makes no attempt to simulate how recursive resolvers and end user operating systems may behave. In fact, it avoids such attempts, even to the point that it never retries a failed query, which most clients would do. I would argue that this is a feature of the system, providing as it does a nice clear signal that functions as a good metric for traffic between recursive resolvers and the authoritative servers. For reference, this is what DNSMON "saw" during the reported time period, which seems to correspond to the times in the report: https://atlas.ripe.net/dnsmon/?dnsmon.session.color_range_pls=0-7-7-100-100&dnsmon.session.exclude-errors=true&dnsmon.type=zone-servers&dnsmon.zone=root&dnsmon.startTime=1448798400&dnsmon.endTime=1449021600&dnsmon.ipVersion=both&dnsmon.selectedRows=198.41.0.4,2001:503:ba3e::2:30,192.228.79.201,2001:500:84::b,192.33.4.12,2001:500:2::c,199.7.91.13,2001:500:2d::d,192.203.230.10,192.5.5.241,2001:500:2f::f,192.112.36.4,128.63.2.53,2001:500:1::803f:235,192.36.148.17,2001:7fe::53,192.58.128.30,2001:503:c27::2:30,193.0.14.129,2001:7fd::1,199.7.83.42,2001:500:3::42,202.12.27.33,2001:dc3::35&dnsmon.filterProbes=true&dnsmon.session.color_range_rtt=0-60-60-250-5000&dnsmon.session.color_range_relative-rtt=0-26-26-298-1000 Regards, Chris Amin RIPE NCC Developer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From daniel.karrenberg at ripe.net Tue Dec 8 16:45:38 2015 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 8 Dec 2015 16:45:38 +0100 Subject: [atlas] DNSmon "not indicative of what happens to normal traffic" claims the root ops In-Reply-To: References: <20151208150312.GA23627@laperouse.bortzmeyer.org> Message-ID: <5666FB22.5050308@ripe.net> On 8.12.15 16:16 , Nico CARTRON wrote: > On 8 December 2015 at 16:07:02, Stephane Bortzmeyer (bortzmeyer at nic.fr > ) wrote: >> http://root-servers.org/news/events-of-20151130.txt > > Thanks St?phane for your reactivity, as usual :) > > ?Such test traffic may not be indicative of what happens to normal > traffic or user experience?. > > Not entirely sure what this means behind, or is it just them trying to > minimise the impact? Real resolvers - use caching, - retry queries, - can use all authoritative servers for a zone, - perform recursion, and (again) - use caching. The typical TTL for caching in the root zone is 48 hours. dnsmon does not do any of this. it measures the responsiveness of particular servers. This means dnsmon is a diagnostic tool for DNS root name server operators and not a diagnostic tool for the DNS service. Daniel inventor of dnsmon (the first version) co-inventor of RIPE Atlas advisor for for k.root-servers.net operations (one of "them") From nicolas at ncartron.org Tue Dec 8 16:45:57 2015 From: nicolas at ncartron.org (Nico CARTRON) Date: Tue, 8 Dec 2015 16:45:57 +0100 Subject: [atlas] DNSmon "not indicative of what happens to normal traffic" claims the root ops In-Reply-To: <5666F8A2.5030208@ripe.net> References: <20151208150312.GA23627@laperouse.bortzmeyer.org> <5666F8A2.5030208@ripe.net> Message-ID: Hi Chris, On 8 December 2015 at 16:35:29, Chris Amin (camin at ripe.net) wrote: On 08/12/2015 16:16, Nico CARTRON wrote:? > On 8 December 2015 at 16:07:02, Stephane Bortzmeyer (bortzmeyer at nic.fr? > ) wrote:? >> http://root-servers.org/news/events-of-20151130.txt? >? > Thanks St?phane for your reactivity, as usual :)? >? > ?Such test traffic may not be indicative of what happens to normal? > traffic or user experience?.? >? > Not entirely sure what this means behind, or is it just them trying to? > minimise the impact?? It could be a bit of expectation management on their part. I agree with? the statement that DNSMON and other similar tools do not provide direct? insight into end user experience, but that is also not their goal.? DNSMON at least is deliberately designed to measure from stable vantage? points (RIPE Atlas anchors, formerly TTM boxes), and makes no attempt to? simulate how recursive resolvers and end user operating systems may? behave. In fact, it avoids such attempts, even to the point that it? never retries a failed query, which most clients would do. I would argue? that this is a feature of the system, providing as it does a nice clear? signal that functions as a good metric for traffic between recursive? resolvers and the authoritative servers.? For reference, this is what DNSMON "saw" during the reported time? period, which seems to correspond to the times in the report:? [?] Fully agreed, but I still don?t see why they are downplaying the event like this. Tools such as DNSMON are useful, and of course need to be taken with a grain of salt and not blindly believed ?as it?. A lot of users/eyeballs have noticed problems, so pretending this did not happen is not really? constructive. (OK, they did not pretend this did not happen, but downplaying is kind of the same to me). Cheers, --? Nico -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.karrenberg at ripe.net Tue Dec 8 16:54:29 2015 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 8 Dec 2015 16:54:29 +0100 Subject: [atlas] DNSmon "not indicative of what happens to normal traffic" claims the root ops In-Reply-To: References: <20151208150312.GA23627@laperouse.bortzmeyer.org> <5666F8A2.5030208@ripe.net> Message-ID: <5666FD35.3060205@ripe.net> On 8.12.15 16:45 , Nico CARTRON wrote: > > Fully agreed, but I still don?t see why they are downplaying the event > like this. I would call it "putting into perspective". The DNS kept working. > > Tools such as DNSMON are useful, and of course need to be taken with a > grain of salt and not blindly believed ?as it?. Again: dnsmon is *not* a tool to measure DNS service. You know that, I know that and most people on this list know that. Most of the people reading a public statement probably *do not* know that. So it needs to be pointed out. Otherwise we will get headlines of doom for no good reason. > > A lot of users/eyeballs have noticed problems, so pretending this did > not happen is not really? constructive. Provide data please! > (OK, they did not pretend this did not happen, but downplaying is kind > of the same to me). See above. Daniel one of "them" From philip.homburg at ripe.net Tue Dec 8 16:56:56 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 8 Dec 2015 16:56:56 +0100 Subject: [atlas] DNSmon "not indicative of what happens to normal traffic" claims the root ops In-Reply-To: <5666FB22.5050308@ripe.net> References: <20151208150312.GA23627@laperouse.bortzmeyer.org> <5666FB22.5050308@ripe.net> Message-ID: <5666FDC8.4030304@ripe.net> On 2015/12/08 16:45 , Daniel Karrenberg wrote: > Real resolvers > - use caching, > - retry queries, > - can use all authoritative servers for a zone, > - perform recursion, and (again) > - use caching. > > The typical TTL for caching in the root zone is 48 hours. I wonder if in the case of local DNSSEC validating resolvers behind DNSSEC-unware resolvers in CPEs, this model is still valid. From daniel.karrenberg at ripe.net Tue Dec 8 17:08:03 2015 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 8 Dec 2015 17:08:03 +0100 Subject: [atlas] DNSmon "not indicative of what happens to normal traffic" claims the root ops In-Reply-To: <5666FDC8.4030304@ripe.net> References: <20151208150312.GA23627@laperouse.bortzmeyer.org> <5666FB22.5050308@ripe.net> <5666FDC8.4030304@ripe.net> Message-ID: <56670063.5030407@ripe.net> On 8.12.15 16:56 , Philip Homburg wrote: > On 2015/12/08 16:45 , Daniel Karrenberg wrote: >> Real resolvers >> - use caching, >> - retry queries, >> - can use all authoritative servers for a zone, >> - perform recursion, and (again) >> - use caching. >> >> The typical TTL for caching in the root zone is 48 hours. > > I wonder if in the case of local DNSSEC validating resolvers behind > DNSSEC-unware resolvers in CPEs, this model is still valid. At the risk of turning this into another DNS discussion list: Why are you wondering exactly? DNSSEC validating resolvers do cache, don't they? Daniel whose CPE runs unbound From philip.homburg at ripe.net Tue Dec 8 17:15:14 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 8 Dec 2015 17:15:14 +0100 Subject: [atlas] DNSmon "not indicative of what happens to normal traffic" claims the root ops In-Reply-To: <56670063.5030407@ripe.net> References: <20151208150312.GA23627@laperouse.bortzmeyer.org> <5666FB22.5050308@ripe.net> <5666FDC8.4030304@ripe.net> <56670063.5030407@ripe.net> Message-ID: <56670212.9060201@ripe.net> On 2015/12/08 17:08 , Daniel Karrenberg wrote: >> I wonder if in the case of local DNSSEC validating resolvers behind >> DNSSEC-unware resolvers in CPEs, this model is still valid. > > At the risk of turning this into another DNS discussion list: Why are > you wondering exactly? DNSSEC validating resolvers do cache, don't they? To give an example, the ssh client I use is linked with getdns. Getdns will try to fetch RRSIG records, etc. from the local resolver. If that fails, getdns will become a full recursive resolver. When ssh starts, the cache of getdns will be empty. And after DNS resolution whatever is cached will not be used anymore. From BECHA at ripe.net Wed Dec 9 11:50:13 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Wed, 9 Dec 2015 11:50:13 +0100 Subject: [atlas] CAIDA BGP Hackathon 6-7 Feb 2016 -- Call for Participation In-Reply-To: <63F5AAC9-1915-46B7-8BDA-6BB4CF484DA9@caida.org> References: <63F5AAC9-1915-46B7-8BDA-6BB4CF484DA9@caida.org> Message-ID: <56680765.9080307@ripe.net> Hi everyone, as a continuation of our own successful RIPE Atlas events, we are now taking part in CAIDA's BGP "live" hackahton, by providing data, measurements platform, expertise -- and you ;-) RIPE NCC's services, such as RIS & RIPE Atlas, will be "remixed" with other BGP-related data sources & tools, to create wonderful new hacks. As participants in RIPE Atlas community, you are very much invited to take part in this event. Details are below. Regards, Vesna -------- Forwarded Message -------- Subject: [mat-wg] CAIDA BGP Hackathon 6, 7 Feb 2016 -- Call for Participation Date: Tue, 8 Dec 2015 20:37:49 -0800 From: Alberto Dainotti To: mat-wg at ripe.net What: CAIDA BGP Hackathon, Call for Participation (CFP) When: Feb 6-7, 2016 Where: the San Diego Supercomputer Center (SDSC) on the University of California at San Diego (UCSD) campus. Who: Parties interested in hacking on live BGP data. Inquiries: bgp-hackathon-info at caida.org Important Deadline: Dec 22, 2015 for travel grant requests Apply to attend: http://www.caida.org/workshops/bgp-hackathon/1602/ CAIDA, in cooperation with CSU, USC, UFMG, FORTH, Route Views, RIPE NCC, will host a BGP Hackathon on the 6-7th of February 2016 at UC San Diego (La Jolla, CA, USA). The theme of the hackathon is ?live BGP measurements and monitoring?. We will provide participating teams with access to data sources and a toolbox: live streaming of BGP data, the new BGPMon interface, BGP processing tools and APIs such as the opensource BGPStream software framework, the PEERING testbed, RIPE RIS, visualization tools, and data-plane active measurement platforms such as CAIDA Ark and RIPE Atlas. Participating teams will work on "challenges" that extend, integrate and demonstrate the utility of these platforms/data for understanding or solving practical problems (e.g., detecting BGP prefix hijacking, evaluating anycast performance, effectively visualizing phenomena). The hackathon will be held in San Diego the weekend immediately preceding the NANOG conference and the AIMS academic Internet measurement workshop. The hackathon aims to: - bring together these different communities, e.g., to discuss problems operators face that academics may want to research; - advertise tools (e.g., PEERING peering.usc.edu, BGPStream bgpstream.caida.org) to the communities and get people familiar with using them, and encourage further use in the future; - get people working together on interesting/important problems, hopefully spurring further collaboration on these problems; - provide extra incentive for students to attend NANOG. ### FORMAT Each team of 2-4 people will work on a "challenge". The organization committee will propose a set of challenges to bootstrap feedback and refinement based on community input: participants can propose totally new challenges, modifications to existing ones, and express their preferences. The set of potential challenges is described in the event website at https://github.com/CAIDA/bgp-hackathon/wiki/List-of-Challenges and will continuously evolve in the days preceding the hackathon. On Saturday morning, participants will very briefly introduce their interests and ideas and teams will be officially formed. On Saturday and Sunday, participants will work together in teams to hack and develop their ideas, culminating in very short presentations to the jury on Sunday evening and a party to announce the winning teams and celebrate everyone's participation. During the event, domain-experts will provide support to the teams. Participants are free to work on drafted challenges and on their own ideas in the days preceding the hackathon. A mailing list and documentation will provide support on the platforms/tools/data used in the hackathon. However, for the teams to compete in the hackathon for prizes, they will have to demonstrate that substantial work was done during the two-day event. ### PARTICIPATION AND TRAVEL GRANTS Application to participate in the hackathon is open from December 8, 2016. Application does not guarantee participation. There is no application fee, and no participation fee. We will accept applications until one week before the hackathon, or until capacity is reached. However, the deadline to apply for a travel grant (through the hackathon application form) is 22 December 2015. Travel grants reimburse flights and hotel expenses. Food and drinks will be provided throughout the two-day event. http://www.caida.org/workshops/bgp-hackathon/1602/ From daniel.karrenberg at ripe.net Wed Dec 9 13:05:41 2015 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 9 Dec 2015 13:05:41 +0100 Subject: [atlas] DNSmon "not indicative of what happens to normal traffic" claims the root ops In-Reply-To: <56670212.9060201@ripe.net> References: <20151208150312.GA23627@laperouse.bortzmeyer.org> <5666FB22.5050308@ripe.net> <5666FDC8.4030304@ripe.net> <56670063.5030407@ripe.net> <56670212.9060201@ripe.net> Message-ID: <56681915.4040901@ripe.net> On 8.12.15 17:15 , Philip Homburg wrote: > ... > To give an example, the ssh client I use is linked with getdns. Getdns > will try to fetch RRSIG records, etc. from the local resolver. If that > fails, getdns will become a full recursive resolver. > > When ssh starts, the cache of getdns will be empty. And after DNS > resolution whatever is cached will not be used anymore. Linking full recursive resolver into each application is a poor engineering choice. A better choice is to run a caching resolver on the host system, which is quite practical and helps already. Better still is to run a caching resolver on the home router. Making the poor choices will be noticeable in the responsiveness of the application. This will provide push-back. Unfortunately the perceived cause will appear to be the choice for DNSSEC and not the poor engineering choice in implementing DNSSEC. Personally I have chosen to implement DNSSEC by running unbound on my home router. I realise that this is not for everyone at this point in time. However CPE vendors are free to make a choice like this for new equipment or upgrades of existing CPE software. Daniel From shuque at gmail.com Wed Dec 9 16:49:09 2015 From: shuque at gmail.com (Shumon Huque) Date: Wed, 9 Dec 2015 10:49:09 -0500 Subject: [atlas] Support for arbitrary DNS queries Message-ID: I'd like to request the ability to have RIPE Atlas probes be able to issue DNS queries for arbitrary record types, and have that capability exposed in the API. I'm particularly interested in newer DANE record types like TLSA, OPENPGPKEY, SMIMEA, etc but a general purpose mechanism would be useful. Is this feasible? Are others interested in this capability? Thanks! Shumon Huque -------------- next part -------------- An HTML attachment was scrubbed... URL: From bortzmeyer at nic.fr Wed Dec 9 17:01:20 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 9 Dec 2015 17:01:20 +0100 Subject: [atlas] Support for arbitrary DNS queries In-Reply-To: References: Message-ID: <20151209160120.GA22695@laperouse.bortzmeyer.org> On Wed, Dec 09, 2015 at 10:49:09AM -0500, Shumon Huque wrote a message of 26 lines which said: > I'd like to request the ability to have RIPE Atlas probes be able to issue > DNS queries for arbitrary record types, and have that capability exposed in > the API. By the way, this (real) limit does not seem to be documented in which does not indicate the possible values for query_type. > I'm particularly interested in newer DANE reacord types like TLSA, > OPENPGPKEY, SMIMEA, etc but a general purpose mechanism would be > useful. A partial workaround is to use ANY as a query_type. > Is this feasible? Are others interested in this capability? Count me in. From klaus.mailinglists at pernau.at Wed Dec 9 19:38:52 2015 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Wed, 9 Dec 2015 19:38:52 +0100 Subject: [atlas] more than 10 concurrent measurements to the same target Message-ID: <5668753C.6010505@pernau.at> Hi! When scheduling checks I often get the error: "We do not allow more than 10 concurrent measurements to the same target." Imo this is not correct. Yes, I do schedule more then 10 measurements to the same target, but they are not concurrent. They are sequential - one ofter the other. Thus, it would be great if this check could be fixed to consider start and stop times. Thanks Klaus From michabailey at gmail.com Wed Dec 9 19:51:21 2015 From: michabailey at gmail.com (Micha Bailey) Date: Wed, 9 Dec 2015 20:51:21 +0200 Subject: [atlas] Support for arbitrary DNS queries In-Reply-To: <20151209160120.GA22695@laperouse.bortzmeyer.org> References: <20151209160120.GA22695@laperouse.bortzmeyer.org> Message-ID: On Wednesday, December 9, 2015, Stephane Bortzmeyer wrote: > On Wed, Dec 09, 2015 at 10:49:09AM -0500, > Shumon Huque > wrote > a message of 26 lines which said: > > > > I'm particularly interested in newer DANE reacord types like TLSA, > > OPENPGPKEY, SMIMEA, etc but a general purpose mechanism would be > > useful. > > A partial workaround is to use ANY as a query_type. > > Not necessarily: https://tools.ietf.org/html/draft-jabley-dnsop-refuse-any-00#section-8 and http://blog.cloudflare.com/deprecating-dns-any-meta-query-type/, for example. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Wed Dec 9 19:58:31 2015 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 9 Dec 2015 13:58:31 -0500 Subject: [atlas] more than 10 concurrent measurements to the same target In-Reply-To: <5668753C.6010505@pernau.at> References: <5668753C.6010505@pernau.at> Message-ID: <35DFE73E-9BF9-49A0-850D-D408F8E1429F@puck.nether.net> > On Dec 9, 2015, at 1:38 PM, Klaus Darilion wrote: > > Hi! > > When scheduling checks I often get the error: "We do not allow more than > 10 concurrent measurements to the same target." > > Imo this is not correct. Yes, I do schedule more then 10 measurements to > the same target, but they are not concurrent. They are sequential - one > ofter the other. Thus, it would be great if this check could be fixed to > consider start and stop times. I have found a workaround for this by using DNS names in addition to the IP address. Bonus points if you create your own unique DNS name for the time period in question. - Jared From jared at puck.nether.net Wed Dec 9 20:00:18 2015 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 9 Dec 2015 14:00:18 -0500 Subject: [atlas] Scheduling a test for all probes? Message-ID: <6DA0773E-8FA8-4269-B170-84591D8B1E36@puck.nether.net> Is there a way to schedule a one-off test on all the probes to be run ?at a leisurely pace?, eg: looking up a specific DNS QNAME? (I?ll call it a lazy query/scheduling). - Jared From klaus.mailinglists at pernau.at Wed Dec 9 20:28:35 2015 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Wed, 9 Dec 2015 20:28:35 +0100 Subject: [atlas] What is the Aggregator on Map of DNS Measurements Message-ID: <566880E3.4000404@pernau.at> Hi! The MAP of DNS Measurements contains an "Aggregator" option. Unfortunately the online help (Enter a regular expression ....) does not help much. Is this feature somewhere described in detail? I do not understand it. Thanks Klaus From randy at psg.com Wed Dec 9 20:33:35 2015 From: randy at psg.com (Randy Bush) Date: Thu, 10 Dec 2015 04:33:35 +0900 Subject: [atlas] DNSmon "not indicative of what happens to normal traffic" claims the root ops In-Reply-To: References: <20151208150312.GA23627@laperouse.bortzmeyer.org> <5666F8A2.5030208@ripe.net> Message-ID: > Fully agreed, but I still don?t see why they are downplaying the event > like this. as shumon tweeted, this was the intersection of what the root ops were willing to say. given that, i am surprised they said anything at all. i guess they had to say something, and this was about as little that could be said to be 'something'; impressively content free. an interesting measurement experiment (not atlas) might be to see the smallest number of PR departments needed to remove all useful content from a post-mortem. :) randy From randy at psg.com Wed Dec 9 20:39:03 2015 From: randy at psg.com (Randy Bush) Date: Thu, 10 Dec 2015 04:39:03 +0900 Subject: [atlas] Support for arbitrary DNS queries In-Reply-To: References: Message-ID: > I'd like to request the ability to have RIPE Atlas probes be able to issue > DNS queries for arbitrary record types, and have that capability exposed in > the API. I'm particularly interested in newer DANE record types like TLSA, > OPENPGPKEY, SMIMEA, etc but a general purpose mechanism would be useful. > > Is this feasible? Are others interested in this capability? definitely! both for research and for monitoring my own services. randy From jared at puck.nether.net Wed Dec 9 20:53:42 2015 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 9 Dec 2015 14:53:42 -0500 Subject: [atlas] Support for arbitrary DNS queries In-Reply-To: References: Message-ID: <32F4CA55-7AA6-4A4C-B59D-730C90017C76@puck.nether.net> > On Dec 9, 2015, at 2:39 PM, Randy Bush wrote: > >> I'd like to request the ability to have RIPE Atlas probes be able to issue >> DNS queries for arbitrary record types, and have that capability exposed in >> the API. I'm particularly interested in newer DANE record types like TLSA, >> OPENPGPKEY, SMIMEA, etc but a general purpose mechanism would be useful. >> >> Is this feasible? Are others interested in this capability? > > definitely! both for research and for monitoring my own services. Perhaps a method to just set the RRType as integer would work in the interim? - Jared From robert at ripe.net Wed Dec 9 21:34:04 2015 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 9 Dec 2015 21:34:04 +0100 Subject: [atlas] What is the Aggregator on Map of DNS Measurements In-Reply-To: <566880E3.4000404@pernau.at> References: <566880E3.4000404@pernau.at> Message-ID: <5668903C.7050000@ripe.net> On 2015-12-09 20:28, Klaus Darilion wrote: > Hi! > > The MAP of DNS Measurements contains an "Aggregator" option. > Unfortunately the online help (Enter a regular expression ....) does not > help much. > > Is this feature somewhere described in detail? I do not understand it. > > Thanks > Klaus Hello, That feature came as a side-effect of the latest hackathon. It did not qualify for any prizes (because it was added by yours truly), but it may come handy in some cases. Its announcement was buried in a generic "Various usability fixes in measurement details, maps, ..." statement, which I'm fully to blame. As for what it's for, compare this: https://atlas.ripe.net/measurements/2255413/?filter=&diversity-picker=4&aggregator=#!map with this: https://atlas.ripe.net/measurements/2255413/?filter=&diversity-picker=4&aggregator=ns%5Cd%2B.%5C.app%5Cd%2B%5C.(...)%5Cd%5C.afilias-nst%5C.info#!map ... and the benefits will be hopefully visible. Hope this helps, Robert From robert at ripe.net Wed Dec 9 21:58:03 2015 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 9 Dec 2015 21:58:03 +0100 Subject: [atlas] Support for arbitrary DNS queries In-Reply-To: <32F4CA55-7AA6-4A4C-B59D-730C90017C76@puck.nether.net> References: <32F4CA55-7AA6-4A4C-B59D-730C90017C76@puck.nether.net> Message-ID: <566895DB.1040205@ripe.net> On 2015-12-09 20:53, Jared Mauch wrote: > >> On Dec 9, 2015, at 2:39 PM, Randy Bush wrote: >> >>> I'd like to request the ability to have RIPE Atlas probes be able to issue >>> DNS queries for arbitrary record types, and have that capability exposed in >>> the API. I'm particularly interested in newer DANE record types like TLSA, >>> OPENPGPKEY, SMIMEA, etc but a general purpose mechanism would be useful. >>> >>> Is this feasible? Are others interested in this capability? >> >> definitely! both for research and for monitoring my own services. > > Perhaps a method to just set the RRType as integer would work in the interim? > > - Jared Thank you for everyone who chimed in so far on this topic. This feature is on our radar, or short-list if you will (and I'm sure it'll appear on the public roadmap shortly ;-) Paraphrasing what we have as description / todo internally for the actual feature (Jared: bingo!): "[once implemented] simple DNS measurements can happen just like they do today: I can select a DNS query type by mnemonic. The new feature is about advanced DNS measurements: users should be able to specify a DNS type ID (numerical value, 0-65K) which is checked against a whitelist" We plan to have a whitelist [of query IDs], both because the probes just don't fully support all types, and some users expressed that they would not like us to support all query types; for example axfr/ixfr are complicated examples. Regards, Robert From klaus.mailinglists at pernau.at Wed Dec 9 22:13:57 2015 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Wed, 9 Dec 2015 22:13:57 +0100 Subject: [atlas] What is the Aggregator on Map of DNS Measurements In-Reply-To: <5668903C.7050000@ripe.net> References: <566880E3.4000404@pernau.at> <5668903C.7050000@ripe.net> Message-ID: <56689995.6070204@pernau.at> Hi Robert! On 09.12.2015 21:34, Robert Kisteleki wrote: > On 2015-12-09 20:28, Klaus Darilion wrote: >> Hi! >> >> The MAP of DNS Measurements contains an "Aggregator" option. >> Unfortunately the online help (Enter a regular expression ....) does not >> help much. >> >> Is this feature somewhere described in detail? I do not understand it. >> >> Thanks >> Klaus > > Hello, > > That feature came as a side-effect of the latest hackathon. It did not > qualify for any prizes (because it was added by yours truly), but it may > come handy in some cases. Its announcement was buried in a generic "Various > usability fixes in measurement details, maps, ..." statement, which I'm > fully to blame. > > As for what it's for, compare this: > > https://atlas.ripe.net/measurements/2255413/?filter=&diversity-picker=4&aggregator=#!map > > with this: > > https://atlas.ripe.net/measurements/2255413/?filter=&diversity-picker=4&aggregator=ns%5Cd%2B.%5C.app%5Cd%2B%5C.(...)%5Cd%5C.afilias-nst%5C.info#!map > > ... and the benefits will be hopefully visible. Indeed. I already suspected such a feature, because I was in need for such a feature, but I failed to make a proper regexp without a working example. Finally I made it: https://atlas.ripe.net/measurements/3071123/?filter=&diversity-picker=4&aggregator=tld-tirol-%28...%29\d#!map But it is difficult to find out where a probe gets routed too, as the colors are sometimes quite similar. Thus it would be great to add the NSID to the probe details (as requested some days ago). Or even better: on "mouse over" a probe display the NSID (or the serial, depending on the choosen dataset). Thanks Klaus From willem at nlnetlabs.nl Thu Dec 10 10:07:51 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 10 Dec 2015 10:07:51 +0100 Subject: [atlas] Support for arbitrary DNS queries In-Reply-To: <20151209160120.GA22695@laperouse.bortzmeyer.org> References: <20151209160120.GA22695@laperouse.bortzmeyer.org> Message-ID: <566940E7.4070504@nlnetlabs.nl> Op 09-12-15 om 17:01 schreef Stephane Bortzmeyer: > On Wed, Dec 09, 2015 at 10:49:09AM -0500, > Shumon Huque wrote > a message of 26 lines which said: >> Is this feasible? Are others interested in this capability? > > Count me in. Me too! -- Willem From willem at nlnetlabs.nl Thu Dec 10 10:11:53 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 10 Dec 2015 10:11:53 +0100 Subject: [atlas] Support for arbitrary DNS queries In-Reply-To: <566895DB.1040205@ripe.net> References: <32F4CA55-7AA6-4A4C-B59D-730C90017C76@puck.nether.net> <566895DB.1040205@ripe.net> Message-ID: <566941D9.7080409@nlnetlabs.nl> Op 09-12-15 om 21:58 schreef Robert Kisteleki: > We plan to have a whitelist [of query IDs], both because the probes just > don't fully support all types, and some users expressed that they would not > like us to support all query types; for example axfr/ixfr are complicated > examples. And sending arbitrary EDNS0 options? Have you ever considered that too? Is it on the todo list too? Thanks, -- Willem > > Regards, > Robert > From philip.homburg at ripe.net Thu Dec 10 12:21:40 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 10 Dec 2015 12:21:40 +0100 Subject: [atlas] Support for arbitrary DNS queries In-Reply-To: <566941D9.7080409@nlnetlabs.nl> References: <32F4CA55-7AA6-4A4C-B59D-730C90017C76@puck.nether.net> <566895DB.1040205@ripe.net> <566941D9.7080409@nlnetlabs.nl> Message-ID: <56696044.9070509@ripe.net> On 2015/12/10 10:11 , Willem Toorop wrote: > And sending arbitrary EDNS0 options? Have you ever considered that too? > Is it on the todo list too? Hi Willem, Just about all EDNS0 options take parameters. It is not part of the model to allow users to inject arbitrary binary data. Though if there is sufficient interest, we can add some of the options currently proposed (cookies, keepalive) Philip From jared at puck.nether.net Thu Dec 10 13:33:19 2015 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 10 Dec 2015 07:33:19 -0500 Subject: [atlas] Support for arbitrary DNS queries In-Reply-To: <56696044.9070509@ripe.net> References: <32F4CA55-7AA6-4A4C-B59D-730C90017C76@puck.nether.net> <566895DB.1040205@ripe.net> <566941D9.7080409@nlnetlabs.nl> <56696044.9070509@ripe.net> Message-ID: > On Dec 10, 2015, at 6:21 AM, Philip Homburg wrote: > > On 2015/12/10 10:11 , Willem Toorop wrote: >> And sending arbitrary EDNS0 options? Have you ever considered that too? >> Is it on the todo list too? > > Hi Willem, > > Just about all EDNS0 options take parameters. It is not part of the > model to allow users to inject arbitrary binary data. Though if there is > sufficient interest, we can add some of the options currently proposed > (cookies, keepalive) client-subnet? :) - Jared From philip.homburg at ripe.net Thu Dec 10 13:41:29 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 10 Dec 2015 13:41:29 +0100 Subject: [atlas] Support for arbitrary DNS queries In-Reply-To: References: <32F4CA55-7AA6-4A4C-B59D-730C90017C76@puck.nether.net> <566895DB.1040205@ripe.net> <566941D9.7080409@nlnetlabs.nl> <56696044.9070509@ripe.net> Message-ID: <566972F9.4000605@ripe.net> On 2015/12/10 13:33 , Jared Mauch wrote: > client-subnet? :) I can add an option to send 0/0 as the client subnet :-) From gil at magisto.com Thu Dec 10 13:43:23 2015 From: gil at magisto.com (Gil Bahat) Date: Thu, 10 Dec 2015 14:43:23 +0200 Subject: [atlas] Support for arbitrary DNS queries In-Reply-To: References: <32F4CA55-7AA6-4A4C-B59D-730C90017C76@puck.nether.net> <566895DB.1040205@ripe.net> <566941D9.7080409@nlnetlabs.nl> <56696044.9070509@ripe.net> Message-ID: On Thu, Dec 10, 2015 at 2:33 PM, Jared Mauch wrote: > > > On Dec 10, 2015, at 6:21 AM, Philip Homburg > wrote: > > > > On 2015/12/10 10:11 , Willem Toorop wrote: > >> And sending arbitrary EDNS0 options? Have you ever considered that too? > >> Is it on the todo list too? > > > > Hi Willem, > > > > Just about all EDNS0 options take parameters. It is not part of the > > model to allow users to inject arbitrary binary data. Though if there is > > sufficient interest, we can add some of the options currently proposed > > (cookies, keepalive) > > client-subnet? :) > > - Jared > Is this really useful? I mean, if a DNS server honors client-subnet, then it doesn't really matter which node is making the lookup. you might as well loop over your local machine and change the client-subnet. what could be very interesting though, is to map DNS servers supporting EDNS0 and ones not supporting it (i.e. which network operators should be bugged to support it...). it would be very good for network operators to see e.g. in-country adoption rate before relying on a CDN using EDNS0 as the core POP routing technology. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Thu Dec 10 13:54:29 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 10 Dec 2015 13:54:29 +0100 Subject: [atlas] Support for arbitrary DNS queries In-Reply-To: References: <32F4CA55-7AA6-4A4C-B59D-730C90017C76@puck.nether.net> <566895DB.1040205@ripe.net> <566941D9.7080409@nlnetlabs.nl> <56696044.9070509@ripe.net> Message-ID: <56697605.2000407@ripe.net> On 2015/12/10 13:43 , Gil Bahat wrote: > what could be very interesting though, is to map DNS servers supporting > EDNS0 and ones not supporting it (i.e. which network operators should be > bugged to support it...). it would be very good for network operators to > see e.g. in-country adoption rate before relying on a CDN using EDNS0 as > the core POP routing technology. Mapping EDNS0 support can be done today. There are the various DNSSEC related flags and udp payload size. And probes can prepend their probe ids so you can see at the dns server which probe is which. From the.lists at mgm51.com Thu Dec 10 15:34:28 2015 From: the.lists at mgm51.com (Mike) Date: Thu, 10 Dec 2015 09:34:28 -0500 Subject: [atlas] Probe Address Discovery Message-ID: <56698D74.2010907@mgm51.com> On the Network tab for my probe, there is a section named, "Probe Address Discovery". It shows the addresses on my probe, placing a green check mark next to the one(s) it thinks are the public address(es) for the probe. For my probe, the IPv4 address shown in the IP Echo Service row has a green check mark. Unfortunately, that IPv4 address was replaced about a month ago by another IPv4 address, and it can no longer be considered to be an address for my probe. Additionally, the IPv6 address for the IP Echo Service is also incorrect, but that one doesn't have a green check mark next to it. Is it a problem that these addresses are incorrect? Is there a way to refresh them, or have them refreshed, with the correct IP addresses? thanks. From dkg at fifthhorseman.net Fri Dec 11 01:07:35 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 10 Dec 2015 19:07:35 -0500 Subject: [atlas] Support for arbitrary DNS queries In-Reply-To: <566972F9.4000605@ripe.net> References: <32F4CA55-7AA6-4A4C-B59D-730C90017C76@puck.nether.net> <566895DB.1040205@ripe.net> <566941D9.7080409@nlnetlabs.nl> <56696044.9070509@ripe.net> <566972F9.4000605@ripe.net> Message-ID: <87lh91kfug.fsf@alice.fifthhorseman.net> On Thu 2015-12-10 07:41:29 -0500, Philip Homburg wrote: > On 2015/12/10 13:33 , Jared Mauch wrote: >> client-subnet? :) > > I can add an option to send 0/0 as the client subnet :-) That would be great, thanks! --dkg From nicolas at ncartron.org Fri Dec 11 10:18:50 2015 From: nicolas at ncartron.org (Nico CARTRON) Date: Fri, 11 Dec 2015 10:18:50 +0100 Subject: [atlas] DNSmon "not indicative of what happens to normal traffic" claims the root ops In-Reply-To: References: <20151208150312.GA23627@laperouse.bortzmeyer.org> <5666F8A2.5030208@ripe.net> Message-ID: Hi Randy, On 9 December 2015 at 20:33:46, Randy Bush (randy at psg.com) wrote: > Fully agreed, but I still don?t see why they are downplaying the event? > like this.? as shumon tweeted, this was the intersection of what the root ops were? willing to say. given that, i am surprised they said anything at all.? i guess they had to say something, and this was about as little that? could be said to be 'something'; impressively content free.?? an interesting measurement experiment (not atlas) might be to see the? smallest number of PR departments needed to remove all useful content? from a post-mortem. :)? well, that was the point I was trying to make: when you do a PR, people usually expect to learn something. In that case, I got the feeling that I learnt absolutely nothing, while the PR was kind of finger-pointing? to solutions such as Atlas, telling that they do not necessarily represent real life. While this is true (as pointed out by Daniel), I found it quite awkward? Cheers, --? Nico -------------- next part -------------- An HTML attachment was scrubbed... URL: From bortzmeyer at nic.fr Fri Dec 11 15:55:11 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 11 Dec 2015 15:55:11 +0100 Subject: [atlas] Support for arbitrary DNS queries In-Reply-To: <32F4CA55-7AA6-4A4C-B59D-730C90017C76@puck.nether.net> References: <32F4CA55-7AA6-4A4C-B59D-730C90017C76@puck.nether.net> Message-ID: <20151211145511.GD5328@laperouse.bortzmeyer.org> On Wed, Dec 09, 2015 at 02:53:42PM -0500, Jared Mauch wrote a message of 20 lines which said: > Perhaps a method to just set the RRType as integer would work in the > interim? +1 for me. From bortzmeyer at nic.fr Fri Dec 11 15:54:44 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 11 Dec 2015 15:54:44 +0100 Subject: [atlas] Support for arbitrary DNS queries In-Reply-To: References: <20151209160120.GA22695@laperouse.bortzmeyer.org> Message-ID: <20151211145444.GC5328@laperouse.bortzmeyer.org> On Wed, Dec 09, 2015 at 08:51:21PM +0200, Micha Bailey wrote a message of 48 lines which said: > > A partial workaround is to use ANY as a query_type. > > > > Not necessarily: > https://tools.ietf.org/html/draft-jabley-dnsop-refuse-any-00#section-8 and > http://blog.cloudflare.com/deprecating-dns-any-meta-query-type/, for > example. I know the semantics of ANY, thanks :-) That's why I called it a "partial" workaround. From bortzmeyer at nic.fr Fri Dec 11 16:11:42 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 11 Dec 2015 16:11:42 +0100 Subject: [atlas] more than 10 concurrent measurements to the same target In-Reply-To: <5668753C.6010505@pernau.at> References: <5668753C.6010505@pernau.at> Message-ID: <20151211151142.GB6278@laperouse.bortzmeyer.org> On Wed, Dec 09, 2015 at 07:38:52PM +0100, Klaus Darilion wrote a message of 12 lines which said: > When scheduling checks I often get the error: "We do not allow more than > 10 concurrent measurements to the same target." > > Imo this is not correct. I believe that the counter is global (not just your measurements). I often see this error when measuring 8.8.8.8 (a very popular target). From klaus.mailinglists at pernau.at Fri Dec 11 17:39:06 2015 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Fri, 11 Dec 2015 17:39:06 +0100 Subject: [atlas] more than 10 concurrent measurements to the same target In-Reply-To: <20151211151142.GB6278@laperouse.bortzmeyer.org> References: <5668753C.6010505@pernau.at> <20151211151142.GB6278@laperouse.bortzmeyer.org> Message-ID: <566AFC2A.2040903@pernau.at> On 11.12.2015 16:11, Stephane Bortzmeyer wrote: > On Wed, Dec 09, 2015 at 07:38:52PM +0100, > Klaus Darilion wrote > a message of 12 lines which said: > >> When scheduling checks I often get the error: "We do not allow more than >> 10 concurrent measurements to the same target." >> >> Imo this is not correct. > > I believe that the counter is global (not just your measurements). I > often see this error when measuring 8.8.8.8 (a very popular target). That's what I heard too. But I have the problem when targeting my server which for sure nobody test except me. I also have the problem even when all my measurements to this target are already stopped. It seems that this counter is not updated in real time. regards Klaus From vnaumov at ripe.net Sat Dec 12 13:15:43 2015 From: vnaumov at ripe.net (Viktor Naumov) Date: Sat, 12 Dec 2015 13:15:43 +0100 Subject: [atlas] more than 10 concurrent measurements to the same target In-Reply-To: <566AFC2A.2040903@pernau.at> References: <5668753C.6010505@pernau.at> <20151211151142.GB6278@laperouse.bortzmeyer.org> <566AFC2A.2040903@pernau.at> Message-ID: <566C0FEF.3030502@ripe.net> Hi, On 12/11/15 5:39 PM, Klaus Darilion wrote: > > On 11.12.2015 16:11, Stephane Bortzmeyer wrote: > > I believe that the counter is global (not just your measurements). I > often see this error when measuring 8.8.8.8 (a very popular target). That's absolutely right. > That's what I heard too. But I have the problem when targeting my server > which for sure nobody test except me. I also have the problem even when > all my measurements to this target are already stopped. It seems that > this counter is not updated in real time. > > regards > Klaus > It can happen when you use one-offs. RIPE Atlas infrastructure uses a timeout of ~15 minutes after starting one-off measurement before marking it as finished. You also can check what measurements are/were performed against a particular target on the RIPE Stat on "Activity" tab. Scroll down to the very last "RIPE Atlas measurement target" view. Cheers, /vty From Maciej.Andzinski at nask.pl Tue Dec 15 11:52:36 2015 From: Maciej.Andzinski at nask.pl (Maciej =?utf-8?Q?Andzi=C5=84ski?=) Date: Tue, 15 Dec 2015 11:52:36 +0100 (CET) Subject: [atlas] [request] AD bit in DNS query In-Reply-To: <421731627.14431778.1450175392255.JavaMail.zimbra@nask.pl> Message-ID: <754812229.14435867.1450176756395.JavaMail.zimbra@nask.pl> Hi, Apropos of the discussion about arbitrary QTYPE in DNS measurement, I would like to make a request for another small improvement. It would be nice if a probe had the ability to send a DNS query with AD bit set. Such query would be useful in some cases (for instance when using "Use the Probe's Resolver(s)" feature) and would reduce data volume. According to RFC6840 section 5.7: 5.7. Setting the AD Bit on Queries The semantics of the Authentic Data (AD) bit in the query were previously undefined. Section 4.6 of [RFC4035] instructed resolvers to always clear the AD bit when composing queries. This document defines setting the AD bit in a query as a signal indicating that the requester understands and is interested in the value of the AD bit in the response. This allows a requester to indicate that it understands the AD bit without also requesting DNSSEC data via the DO bit. Many greetings, Maciej Andzi?ski, NASK From bortzmeyer at nic.fr Wed Dec 16 10:31:55 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 16 Dec 2015 10:31:55 +0100 Subject: [atlas] Number of packets now ignored for ICMP tests? Message-ID: <20151216093155.GA24567@sources.org> I asked just one packet: {'definitions': [{'description': 'Ping 2001:67c:217c:6::2 from AS #3215', 'af': 6, 'packets': 1, 'type': 'ping', 'is_oneoff': True, 'target': '2001:67c:217c:6::2'}], 'probes': [{'requested': 500, 'type': 'asn', 'value': '3215', 'tags': {'include': ['system-ipv6-works']}}]} But, for the nine probes that were selected, I got 27 tests, which is the default of 3 packets per probe. Strange. Measurement #3083491 From camin at ripe.net Wed Dec 16 11:10:26 2015 From: camin at ripe.net (Chris Amin) Date: Wed, 16 Dec 2015 11:10:26 +0100 Subject: [atlas] Number of packets now ignored for ICMP tests? In-Reply-To: <20151216093155.GA24567@sources.org> References: <20151216093155.GA24567@sources.org> Message-ID: <56713892.3040600@ripe.net> On 16/12/2015 10:31, Stephane Bortzmeyer wrote: > I asked just one packet: > > {'definitions': [{'description': 'Ping 2001:67c:217c:6::2 from AS #3215', 'af': 6, 'packets': 1, 'type': 'ping', 'is_oneoff': True, 'target': '2001:67c:217c:6::2'}], 'probes': [{'requested': 500, 'type': 'asn', 'value': '3215', 'tags': {'include': ['system-ipv6-works']}}]} > > But, for the nine probes that were selected, I got 27 tests, which is > the default of 3 packets per probe. Strange. > > Measurement #3083491 Hi Stephane, Unfortunately there was a regression which was preventing this option from being honoured. We have now fixed this, so new measurements will not have this problem. Sorry for the inconvenience. Kind regards, Chris Amin RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From bortzmeyer at nic.fr Wed Dec 16 11:24:29 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 16 Dec 2015 11:24:29 +0100 Subject: [atlas] Number of packets now ignored for ICMP tests? In-Reply-To: <56713892.3040600@ripe.net> References: <20151216093155.GA24567@sources.org> <56713892.3040600@ripe.net> Message-ID: <20151216102429.GA30418@sources.org> On Wed, Dec 16, 2015 at 11:10:26AM +0100, Chris Amin wrote a message of 53 lines which said: > Unfortunately there was a regression which was preventing this > option from being honoured. When I give Atlas tutorials, I always say to the programmers "Do not assume, measure and test" I've seen code where the user looped over the results only for the number of requested packets... From Maciej.Andzinski at nask.pl Wed Dec 16 12:00:20 2015 From: Maciej.Andzinski at nask.pl (Maciej =?utf-8?Q?Andzi=C5=84ski?=) Date: Wed, 16 Dec 2015 12:00:20 +0100 (CET) Subject: [atlas] DNS measurement failed In-Reply-To: <1337083048.14557314.1450262820704.JavaMail.zimbra@nask.pl> Message-ID: <1007073621.14558737.1450263620124.JavaMail.zimbra@nask.pl> Hi, Since yesterday I've been encountering a problem, many of the DNS measurements end with "failed" status. It happens for every measurement that tries to query 8.8.8.8, 8.8.4.4 or when using "Use the Probe's Resolver(s)" feature. However, everything works fine when querying a-dns.pl (194.181.87.156) server. Sample measurements: 3082732 3083505 3083581 Do you observe any issues related to the lack of available probes / exceeded limits? Many greetings, Maciej Andzi?ski, NASK From bortzmeyer at nic.fr Wed Dec 16 12:19:05 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 16 Dec 2015 12:19:05 +0100 Subject: [atlas] DNS measurement failed In-Reply-To: <1007073621.14558737.1450263620124.JavaMail.zimbra@nask.pl> References: <1337083048.14557314.1450262820704.JavaMail.zimbra@nask.pl> <1007073621.14558737.1450263620124.JavaMail.zimbra@nask.pl> Message-ID: <20151216111905.GA5070@sources.org> On Wed, Dec 16, 2015 at 12:00:20PM +0100, Maciej Andzi?ski wrote a message of 20 lines which said: > Since yesterday I've been encountering a problem, many of the DNS > measurements end with "failed" status. Same thing for me. I thought I was the only one. See #3083496 for instance. From camin at ripe.net Wed Dec 16 12:31:08 2015 From: camin at ripe.net (Chris Amin) Date: Wed, 16 Dec 2015 12:31:08 +0100 Subject: [atlas] DNS measurement failed In-Reply-To: <20151216111905.GA5070@sources.org> References: <1337083048.14557314.1450262820704.JavaMail.zimbra@nask.pl> <1007073621.14558737.1450263620124.JavaMail.zimbra@nask.pl> <20151216111905.GA5070@sources.org> Message-ID: <56714B7C.2060007@ripe.net> On 16/12/2015 12:19, Stephane Bortzmeyer wrote: > On Wed, Dec 16, 2015 at 12:00:20PM +0100, > Maciej Andzi?ski wrote > a message of 20 lines which said: > >> Since yesterday I've been encountering a problem, many of the DNS >> measurements end with "failed" status. > > Same thing for me. I thought I was the only one. See #3083496 for > instance. Maciej, Stephane, Can you confirm whether you've seen this problem since 10:12 UTC? That was when a regression was fixed which could have caused this issue. Regards, Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From Maciej.Andzinski at nask.pl Wed Dec 16 13:15:36 2015 From: Maciej.Andzinski at nask.pl (Maciej =?utf-8?Q?Andzi=C5=84ski?=) Date: Wed, 16 Dec 2015 13:15:36 +0100 (CET) Subject: [atlas] DNS measurement failed In-Reply-To: <56714B7C.2060007@ripe.net> References: <1337083048.14557314.1450262820704.JavaMail.zimbra@nask.pl> <1007073621.14558737.1450263620124.JavaMail.zimbra@nask.pl> <20151216111905.GA5070@sources.org> <56714B7C.2060007@ripe.net> Message-ID: <93440412.14565769.1450268136395.JavaMail.zimbra@nask.pl> Hi, ----- Oryginalna wiadomo?? ----- > On 16/12/2015 12:19, Stephane Bortzmeyer wrote: > > On Wed, Dec 16, 2015 at 12:00:20PM +0100, > > Maciej Andzi?ski wrote > > a message of 20 lines which said: > > > >> Since yesterday I've been encountering a problem, many of the DNS > >> measurements end with "failed" status. > > > > Same thing for me. I thought I was the only one. See #3083496 for > > instance. > > Maciej, Stephane, > > Can you confirm whether you've seen this problem since 10:12 UTC? That > was when a regression was fixed which could have caused this issue. > I confirm, much better now :) thank you for quick response {"measurements":[3083673]} {"measurements":[3083675,3083676,3083677,3083678]} Many greetings, Maciej Andzi?ski, NASK From bortzmeyer at nic.fr Wed Dec 16 13:32:16 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 16 Dec 2015 13:32:16 +0100 Subject: [atlas] DNS measurement failed In-Reply-To: <56714B7C.2060007@ripe.net> References: <1337083048.14557314.1450262820704.JavaMail.zimbra@nask.pl> <1007073621.14558737.1450263620124.JavaMail.zimbra@nask.pl> <20151216111905.GA5070@sources.org> <56714B7C.2060007@ripe.net> Message-ID: <20151216123216.GA17663@sources.org> On Wed, Dec 16, 2015 at 12:31:08PM +0100, Chris Amin wrote a message of 49 lines which said: > Can you confirm whether you've seen this problem since 10:12 UTC? That > was when a regression was fixed which could have caused this issue. Apparently, it now works. #3083683 #3083685 #3083690 From BECHA at ripe.net Mon Dec 21 12:02:52 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Mon, 21 Dec 2015 12:02:52 +0100 Subject: [atlas] Exploring the Idea of RIPE Atlas Virtual Probes In-Reply-To: <5677DAE8.80602@ripe.net> References: <5677DAE8.80602@ripe.net> Message-ID: <5677DC5C.3000008@ripe.net> Dear colleagues, Some of you have asked about Virtual Probes on this list. Although we don't plan to make virtual probes available in 2016, we do plan to investigate this idea and develop some prototypes. Please find more details on RIPE Labs: https://labs.ripe.net/Members/suzanne_taylor_muzzin/exploring-the-idea-of-ripe-atlas-virtual-probes Kind regards, Vesna Manojlovic RIPE NCC From BECHA at ripe.net Mon Dec 21 12:05:46 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Mon, 21 Dec 2015 12:05:46 +0100 Subject: [atlas] 13 new zones added to DNSMON In-Reply-To: <5677DCAB.5060609@ripe.net> References: <5677DCAB.5060609@ripe.net> Message-ID: <5677DD0A.9090300@ripe.net> Dear colleagues, The DNS Working Group has approved documentation of the process to add new zones to the DNSMON service. This is now published as a RIPE Document on our website: https://www.ripe.net/publications/docs/ripe-661/ The following 13 zones, compliant with the new process, have now been added to DNSMON: https://atlas.ripe.net/dnsmon/group/es https://atlas.ripe.net/dnsmon/group/pt https://atlas.ripe.net/dnsmon/group/tk https://atlas.ripe.net/dnsmon/group/ml https://atlas.ripe.net/dnsmon/group/ga https://atlas.ripe.net/dnsmon/group/cf https://atlas.ripe.net/dnsmon/group/gq https://atlas.ripe.net/dnsmon/group/dk https://atlas.ripe.net/dnsmon/group/rs https://atlas.ripe.net/dnsmon/group/xn--90a3ac https://atlas.ripe.net/dnsmon/group/ao https://atlas.ripe.net/dnsmon/group/cv https://atlas.ripe.net/dnsmon/group/gw If you have any question please contact us at: . Kind regards, Vesna Manojlovic Manager of Measurements Community Building RIPE NCC From colinj at mx5.org.uk Mon Dec 21 12:33:50 2015 From: colinj at mx5.org.uk (Colin Johnston) Date: Mon, 21 Dec 2015 11:33:50 +0000 Subject: [atlas] Exploring the Idea of RIPE Atlas Virtual Probes In-Reply-To: <5677DC5C.3000008@ripe.net> References: <5677DAE8.80602@ripe.net> <5677DC5C.3000008@ripe.net> Message-ID: I fully support this idea and happy to help/develop and test. Colin Johnston > On 21 Dec 2015, at 11:02, Vesna Manojlovic wrote: > > Dear colleagues, > > Some of you have asked about Virtual Probes on this list. > > Although we don't plan to make virtual probes available in 2016, > we do plan to investigate this idea and develop some prototypes. > > Please find more details on RIPE Labs: > > https://labs.ripe.net/Members/suzanne_taylor_muzzin/exploring-the-idea-of-ripe-atlas-virtual-probes > > Kind regards, > Vesna Manojlovic > RIPE NCC > > > From klaus.mailinglists at pernau.at Tue Dec 22 06:23:25 2015 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Tue, 22 Dec 2015 06:23:25 +0100 Subject: [atlas] 13 new zones added to DNSMON In-Reply-To: <5677DD0A.9090300@ripe.net> References: <5677DCAB.5060609@ripe.net> <5677DD0A.9090300@ripe.net> Message-ID: <5678DE4D.1030300@pernau.at> Any plans to offer DNSMON also for the ngTLDs (maybe as paid service)? regards Klaus On 21.12.2015 12:05, Vesna Manojlovic wrote: > Dear colleagues, > > The DNS Working Group has approved documentation of the process > to add new zones to the DNSMON service. > > This is now published as a RIPE Document on our website: > https://www.ripe.net/publications/docs/ripe-661/ > > The following 13 zones, compliant with the new process, have now been > added to DNSMON: > > https://atlas.ripe.net/dnsmon/group/es > https://atlas.ripe.net/dnsmon/group/pt > https://atlas.ripe.net/dnsmon/group/tk > https://atlas.ripe.net/dnsmon/group/ml > https://atlas.ripe.net/dnsmon/group/ga > https://atlas.ripe.net/dnsmon/group/cf > https://atlas.ripe.net/dnsmon/group/gq > https://atlas.ripe.net/dnsmon/group/dk > https://atlas.ripe.net/dnsmon/group/rs > https://atlas.ripe.net/dnsmon/group/xn--90a3ac > https://atlas.ripe.net/dnsmon/group/ao > https://atlas.ripe.net/dnsmon/group/cv > https://atlas.ripe.net/dnsmon/group/gw > > If you have any question please contact us at: > . > > Kind regards, > Vesna Manojlovic > Manager of Measurements Community Building > RIPE NCC > > From BECHA at ripe.net Tue Dec 22 11:29:41 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Tue, 22 Dec 2015 11:29:41 +0100 Subject: [atlas] Using DomainMON instead of DSNMON In-Reply-To: <5678DE4D.1030300@pernau.at> References: <5677DCAB.5060609@ripe.net> <5677DD0A.9090300@ripe.net> <5678DE4D.1030300@pernau.at> Message-ID: <56792615.5040801@ripe.net> Hi Klaus, all, On 22-dec.-15 06:23, Klaus Darilion wrote: > Any plans to offer DNSMON also for the ngTLDs (maybe as paid service)? For all those who do not fulfill current criteria, there is another way to use features of DNSMON -- it's called DomainMON: https://atlas.ripe.net/domainmon This enables all RIPE Atlas users to specify, as a target of measurements, their own domain: second level, third level, or "ngTLD" (or "vanity domains" as I like to call them ;-) Measurements are performed from probes instead of anchors, and need to be "paid" by user's own credits. More details: https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-domainmon-is-here In order to earn more credits, users can: 0) have the credits transferred to them by another generous user 1) be an LIR/member, and claim 1.000.000 credits each month 2) host one or multiple probes 3) host one or more anchors 4) sponsor an anchor 5) become a sponsor for RIPE Atlas by "adopting" the probes, or distributing their sponsored probes themselves: https://atlas.ripe.net/sponsors Regards, Vesna ps Klaus, if you think that the "ngTLDs" should be treated differently, please re-start the discussion on DNS-WG mailing list; after that, this would have to be approved by RIPE NCC membership since DNSMON is, in a way, "subsidized" by "free credits" from the RIPE Atlas system, since ccTLDs are considered important infrastructure "for the god of the Internet". From annikaw at penguinfriends.org Tue Dec 22 14:21:59 2015 From: annikaw at penguinfriends.org (Annika Wickert) Date: Tue, 22 Dec 2015 14:21:59 +0100 Subject: [atlas] LLDP Support for RIPE Probes Message-ID: <56794E77.4020504@penguinfriends.org> Hi everybody, I would like to see LLDP support in the future on the RIPE probes. It would be a really helpful feature, to see on what Port the RIPE Probe resides at the moment. Cheers, Annika From magicsata at gmail.com Tue Dec 22 14:23:55 2015 From: magicsata at gmail.com (Alistair Mackenzie) Date: Tue, 22 Dec 2015 13:23:55 +0000 Subject: [atlas] LLDP Support for RIPE Probes In-Reply-To: <56794E77.4020504@penguinfriends.org> References: <56794E77.4020504@penguinfriends.org> Message-ID: Is this really necessary? The MAC address can be viewed from your ripe account which you can then use in conjunction with the mac address table. On 22 December 2015 at 13:21, Annika Wickert wrote: > Hi everybody, > > I would like to see LLDP support in the future on the RIPE probes. > > It would be a really helpful feature, to see on what Port the RIPE Probe > resides at the moment. > > Cheers, > Annika > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From annikaw at penguinfriends.org Tue Dec 22 14:25:30 2015 From: annikaw at penguinfriends.org (Annika Wickert) Date: Tue, 22 Dec 2015 14:25:30 +0100 Subject: [atlas] LLDP Support for RIPE Probes In-Reply-To: References: <56794E77.4020504@penguinfriends.org> Message-ID: <56794F4A.20309@penguinfriends.org> For bigger networks it is necessary because not everyone of our network team has an RIPE account or access to LIR so I cannot share the information of the probe. And it's always good for automatic documentation. On 22/12/15 14:23, Alistair Mackenzie wrote: > Is this really necessary? > > The MAC address can be viewed from your ripe account which you can > then use in conjunction with the mac address table. > > On 22 December 2015 at 13:21, Annika Wickert > > wrote: > > Hi everybody, > > I would like to see LLDP support in the future on the RIPE probes. > > It would be a really helpful feature, to see on what Port the RIPE > Probe resides at the moment. > > Cheers, > Annika > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magicsata at gmail.com Tue Dec 22 14:26:50 2015 From: magicsata at gmail.com (Alistair Mackenzie) Date: Tue, 22 Dec 2015 13:26:50 +0000 Subject: [atlas] LLDP Support for RIPE Probes In-Reply-To: <56794F4A.20309@penguinfriends.org> References: <56794E77.4020504@penguinfriends.org> <56794F4A.20309@penguinfriends.org> Message-ID: That makes a bit more sense than how I interpreted it. My bad, sorry! On 22 December 2015 at 13:25, Annika Wickert wrote: > For bigger networks it is necessary because not everyone of our network > team has an RIPE account or access to LIR so I cannot share the information > of the probe. > > And it's always good for automatic documentation. > > > On 22/12/15 14:23, Alistair Mackenzie wrote: > > Is this really necessary? > > The MAC address can be viewed from your ripe account which you can then > use in conjunction with the mac address table. > > On 22 December 2015 at 13:21, Annika Wickert > wrote: > >> Hi everybody, >> >> I would like to see LLDP support in the future on the RIPE probes. >> >> It would be a really helpful feature, to see on what Port the RIPE Probe >> resides at the moment. >> >> Cheers, >> Annika >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at inex.ie Tue Dec 22 15:08:02 2015 From: nick at inex.ie (Nick Hilliard) Date: Tue, 22 Dec 2015 14:08:02 +0000 Subject: [atlas] LLDP Support for RIPE Probes In-Reply-To: References: <56794E77.4020504@penguinfriends.org> Message-ID: <56795942.5020501@inex.ie> Alistair Mackenzie wrote: > Is this really necessary? how much do you love manually maintaining network documentation? Nick From chelliot at pobox.com Tue Dec 22 18:23:43 2015 From: chelliot at pobox.com (Chris Elliott) Date: Tue, 22 Dec 2015 12:23:43 -0500 Subject: [atlas] LLDP Support for RIPE Probes In-Reply-To: <56794E77.4020504@penguinfriends.org> References: <56794E77.4020504@penguinfriends.org> Message-ID: +1 On Tuesday, December 22, 2015, Annika Wickert wrote: > Hi everybody, > > I would like to see LLDP support in the future on the RIPE probes. > > It would be a really helpful feature, to see on what Port the RIPE Probe > resides at the moment. > > Cheers, > Annika > > -- Chris Elliott CCIE # 2013 ?You and I are mirages that perceive themselves? --Douglas Hofstadter -------------- next part -------------- An HTML attachment was scrubbed... URL: From max at gwebs.se Tue Dec 22 22:09:59 2015 From: max at gwebs.se (Max Gebert) Date: Tue, 22 Dec 2015 22:09:59 +0100 Subject: [atlas] LLDP Support for RIPE Probes In-Reply-To: References: <56794E77.4020504@penguinfriends.org> Message-ID: Hey! I could definitely see the appeal of such a function in our network. +1 from me! Best regards/ H?lsningar Max Gebert > 22 dec 2015 kl. 18:23 skrev Chris Elliott : > > +1 > >> On Tuesday, December 22, 2015, Annika Wickert wrote: >> Hi everybody, >> >> I would like to see LLDP support in the future on the RIPE probes. >> >> It would be a really helpful feature, to see on what Port the RIPE Probe resides at the moment. >> >> Cheers, >> Annika > > > -- > Chris Elliott > CCIE # 2013 > ?You and I are mirages that perceive themselves? > --Douglas Hofstadter -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard at ostman.net Tue Dec 22 22:31:28 2015 From: rickard at ostman.net (=?UTF-8?Q?Rickard_=C3=96stman?=) Date: Tue, 22 Dec 2015 22:31:28 +0100 Subject: [atlas] LLDP Support for RIPE Probes In-Reply-To: References: <56794E77.4020504@penguinfriends.org> Message-ID: awesome idea. another useful feature would be to let the probe share via the atlas portal what device and port it's connected to. To the owner alone, that is. /Rickard On Tuesday, 22 December 2015, Max Gebert wrote: > Hey! > > I could definitely see the appeal of such a function in our network. > +1 from me! > > Best regards/ H?lsningar > Max Gebert > > 22 dec 2015 kl. 18:23 skrev Chris Elliott >: > > +1 > > On Tuesday, December 22, 2015, Annika Wickert > wrote: > >> Hi everybody, >> >> I would like to see LLDP support in the future on the RIPE probes. >> >> It would be a really helpful feature, to see on what Port the RIPE Probe >> resides at the moment. >> >> Cheers, >> Annika >> >> > > -- > Chris Elliott > CCIE # 2013 > > ?You and I are mirages that perceive themselves? > --Douglas Hofstadter > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danny at danysek.cz Tue Dec 22 23:34:08 2015 From: danny at danysek.cz (Daniel Suchy) Date: Tue, 22 Dec 2015 23:34:08 +0100 Subject: [atlas] LLDP Support for RIPE Probes In-Reply-To: References: <56794E77.4020504@penguinfriends.org> Message-ID: <5679CFE0.6060506@danysek.cz> +1 On 22.12.2015 22:31, Rickard ?stman wrote: > awesome idea. > > another useful feature would be to let the probe share via the atlas > portal what device and port it's connected to. To the owner alone, that is. > > /Rickard > > On Tuesday, 22 December 2015, Max Gebert > wrote: > > Hey! > > I could definitely see the appeal of such a function in our network. > +1 from me! > > Best regards/ H?lsningar > Max Gebert > > 22 dec 2015 kl. 18:23 skrev Chris Elliott : > >> +1 >> >> On Tuesday, December 22, 2015, Annika Wickert >> wrote: >> >> Hi everybody, >> >> I would like to see LLDP support in the future on the RIPE probes. >> >> It would be a really helpful feature, to see on what Port the >> RIPE Probe resides at the moment. >> >> Cheers, >> Annika >> >> >> >> -- >> Chris Elliott >> CCIE # 2013 >> >> ?You and I are mirages that perceive themselves? >> --Douglas Hofstadter >> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4233 bytes Desc: S/MIME Cryptographic Signature URL: From nick at inex.ie Tue Dec 22 23:51:34 2015 From: nick at inex.ie (Nick Hilliard) Date: Tue, 22 Dec 2015 22:51:34 +0000 Subject: [atlas] LLDP Support for RIPE Probes In-Reply-To: <5679CFE0.6060506@danysek.cz> References: <56794E77.4020504@penguinfriends.org> <5679CFE0.6060506@danysek.cz> Message-ID: <5679D3F6.7020203@inex.ie> yes. YES! Nick Daniel Suchy wrote: > +1 > > On 22.12.2015 22:31, Rickard ?stman wrote: >> awesome idea. >> >> another useful feature would be to let the probe share via the atlas >> portal what device and port it's connected to. To the owner alone, that is. >> >> /Rickard >> >> On Tuesday, 22 December 2015, Max Gebert > > wrote: >> >> Hey! >> >> I could definitely see the appeal of such a function in our network. >> +1 from me! >> >> Best regards/ H?lsningar >> Max Gebert >> >> 22 dec 2015 kl. 18:23 skrev Chris Elliott : >> >>> +1 >>> >>> On Tuesday, December 22, 2015, Annika Wickert >>> wrote: >>> >>> Hi everybody, >>> >>> I would like to see LLDP support in the future on the RIPE probes. >>> >>> It would be a really helpful feature, to see on what Port the >>> RIPE Probe resides at the moment. >>> >>> Cheers, >>> Annika >>> >>> >>> >>> -- >>> Chris Elliott >>> CCIE # 2013 >>> >>> ?You and I are mirages that perceive themselves? >>> --Douglas Hofstadter >>> > From marco at marcoslater.com Wed Dec 23 00:10:31 2015 From: marco at marcoslater.com (Marco Slater) Date: Wed, 23 Dec 2015 00:10:31 +0100 Subject: [atlas] LLDP Support for RIPE Probes In-Reply-To: <5679D3F6.7020203@inex.ie> References: <56794E77.4020504@penguinfriends.org> <5679CFE0.6060506@danysek.cz> <5679D3F6.7020203@inex.ie> Message-ID: Agreed! +1 -Marco > On 22 Dec 2015, at 23:51, Nick Hilliard wrote: > > yes. YES! > > Nick > > Daniel Suchy wrote: >> +1 >> >>> On 22.12.2015 22:31, Rickard ?stman wrote: >>> awesome idea. >>> >>> another useful feature would be to let the probe share via the atlas >>> portal what device and port it's connected to. To the owner alone, that is. >>> >>> /Rickard >>> >>> On Tuesday, 22 December 2015, Max Gebert >> > wrote: >>> >>> Hey! >>> >>> I could definitely see the appeal of such a function in our network. >>> +1 from me! >>> >>> Best regards/ H?lsningar >>> Max Gebert >>> >>>> 22 dec 2015 kl. 18:23 skrev Chris Elliott : >>>> >>>> +1 >>>> >>>> On Tuesday, December 22, 2015, Annika Wickert >>>> wrote: >>>> >>>> Hi everybody, >>>> >>>> I would like to see LLDP support in the future on the RIPE probes. >>>> >>>> It would be a really helpful feature, to see on what Port the >>>> RIPE Probe resides at the moment. >>>> >>>> Cheers, >>>> Annika >>>> >>>> >>>> >>>> -- >>>> Chris Elliott >>>> CCIE # 2013 >>>> >>>> ?You and I are mirages that perceive themselves? >>>> --Douglas Hofstadter > > From gil at magisto.com Thu Dec 24 10:44:52 2015 From: gil at magisto.com (Gil Bahat) Date: Thu, 24 Dec 2015 11:44:52 +0200 Subject: [atlas] Support for arbitrary DNS queries In-Reply-To: <56697605.2000407@ripe.net> References: <32F4CA55-7AA6-4A4C-B59D-730C90017C76@puck.nether.net> <566895DB.1040205@ripe.net> <566941D9.7080409@nlnetlabs.nl> <56696044.9070509@ripe.net> <56697605.2000407@ripe.net> Message-ID: actually, It would be extremely useful for the DNS probe results to immediately and clearly reflect whether any response included EDNS0 bits or not, without this being a separate test. I am trying to debug some oddball CDN DNS assignments and this means trying to hunt down specific probes and tweaking specific lookups in order to get this... inconvenient to the point of almost unusable with that regards. something like this is a quick hack to achieve it: https://www.dns-oarc.net/oarc/services/replysizetest yet, it's much better to have it built-in. Regards, Gil Bahat, DevOps and Network Engineer, Magisto Ltd. On Thu, Dec 10, 2015 at 2:54 PM, Philip Homburg wrote: > On 2015/12/10 13:43 , Gil Bahat wrote: > > what could be very interesting though, is to map DNS servers supporting > > EDNS0 and ones not supporting it (i.e. which network operators should be > > bugged to support it...). it would be very good for network operators to > > see e.g. in-country adoption rate before relying on a CDN using EDNS0 as > > the core POP routing technology. > > Mapping EDNS0 support can be done today. There are the various DNSSEC > related flags and udp payload size. And probes can prepend their probe > ids so you can see at the dns server which probe is which. > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gil at magisto.com Thu Dec 24 10:59:17 2015 From: gil at magisto.com (Gil Bahat) Date: Thu, 24 Dec 2015 11:59:17 +0200 Subject: [atlas] Support for arbitrary DNS queries In-Reply-To: References: <32F4CA55-7AA6-4A4C-B59D-730C90017C76@puck.nether.net> <566895DB.1040205@ripe.net> <566941D9.7080409@nlnetlabs.nl> <56696044.9070509@ripe.net> <56697605.2000407@ripe.net> Message-ID: Unfortunately, this doesn't seem to work so well either: https://atlas.ripe.net/measurements/3115499/ Can anyone here help me figure out why almost all requests end up being null and only very few of them show up the resultant TXT record? Gil On Thu, Dec 24, 2015 at 11:44 AM, Gil Bahat wrote: > actually, It would be extremely useful for the DNS probe results to > immediately and clearly reflect whether any response included EDNS0 bits or > not, without this being a separate test. I am trying to debug some oddball > CDN DNS assignments and this means trying to hunt down specific probes and > tweaking specific lookups in order to get this... inconvenient to the point > of almost unusable with that regards. > something like this is a quick hack to achieve it: > https://www.dns-oarc.net/oarc/services/replysizetest > yet, it's much better to have it built-in. > > Regards, > > Gil Bahat, > DevOps and Network Engineer, > Magisto Ltd. > > On Thu, Dec 10, 2015 at 2:54 PM, Philip Homburg > wrote: > >> On 2015/12/10 13:43 , Gil Bahat wrote: >> > what could be very interesting though, is to map DNS servers supporting >> > EDNS0 and ones not supporting it (i.e. which network operators should be >> > bugged to support it...). it would be very good for network operators to >> > see e.g. in-country adoption rate before relying on a CDN using EDNS0 as >> > the core POP routing technology. >> >> Mapping EDNS0 support can be done today. There are the various DNSSEC >> related flags and udp payload size. And probes can prepend their probe >> ids so you can see at the dns server which probe is which. >> >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anandb at ripe.net Sat Dec 26 11:23:51 2015 From: anandb at ripe.net (Anand Buddhdev) Date: Sat, 26 Dec 2015 11:23:51 +0100 Subject: [atlas] Support for arbitrary DNS queries In-Reply-To: References: <32F4CA55-7AA6-4A4C-B59D-730C90017C76@puck.nether.net> <566895DB.1040205@ripe.net> <566941D9.7080409@nlnetlabs.nl> <56696044.9070509@ripe.net> <56697605.2000407@ripe.net> Message-ID: <567E6AB7.1060701@ripe.net> On 24/12/15 10:59, Gil Bahat wrote: Dear Gil, > Unfortunately, this doesn't seem to work so well either: > https://atlas.ripe.net/measurements/3115499/ > Can anyone here help me figure out why almost all requests end up being > null and only very few of them show up the resultant TXT record? The OARC reply-size tester works by sending a recursive resolver a series of CNAME records to follow. If the resolver has no problems, then it follows the chain quickly, and gets a result. However, if there are path MTU issues, for example, these queries time out. In this case, a resolver will take a long time to come back with the result. The RIPE Atlas DNS measurements all time out after 5 seconds, and this isn't enough time to always get results from the reply-size tester. This is most likely the reason why most of your results are empty, with a "timeout" error. Regards, Anand From gil at magisto.com Sat Dec 26 11:31:04 2015 From: gil at magisto.com (Gil Bahat) Date: Sat, 26 Dec 2015 12:31:04 +0200 Subject: [atlas] Support for arbitrary DNS queries In-Reply-To: <567E6AB7.1060701@ripe.net> References: <32F4CA55-7AA6-4A4C-B59D-730C90017C76@puck.nether.net> <566895DB.1040205@ripe.net> <566941D9.7080409@nlnetlabs.nl> <56696044.9070509@ripe.net> <56697605.2000407@ripe.net> <567E6AB7.1060701@ripe.net> Message-ID: Thank you very much, makes perfect sense. Can we increase the timeout somehow or specify it as a tunable query parameter? I find the OARC tester highly useful in conjunction with RIPE ATLAS. On Dec 26, 2015 12:24 PM, "Anand Buddhdev" wrote: > On 24/12/15 10:59, Gil Bahat wrote: > > Dear Gil, > > > Unfortunately, this doesn't seem to work so well either: > > https://atlas.ripe.net/measurements/3115499/ > > Can anyone here help me figure out why almost all requests end up being > > null and only very few of them show up the resultant TXT record? > > The OARC reply-size tester works by sending a recursive resolver a > series of CNAME records to follow. If the resolver has no problems, then > it follows the chain quickly, and gets a result. However, if there are > path MTU issues, for example, these queries time out. In this case, a > resolver will take a long time to come back with the result. > > The RIPE Atlas DNS measurements all time out after 5 seconds, and this > isn't enough time to always get results from the reply-size tester. This > is most likely the reason why most of your results are empty, with a > "timeout" error. > > Regards, > Anand > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From klaus.mailinglists at pernau.at Tue Dec 29 16:38:20 2015 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Tue, 29 Dec 2015 16:38:20 +0100 Subject: [atlas] Anchor probes with broken lat/lon Message-ID: <5682A8EC.2030604@pernau.at> https://atlas.ripe.net/api/v1/probe/6155/ "latitude": 2228.7695, "longitude": -4412.6105, https://atlas.ripe.net/api/v1/probe/6166/ "latitude": 2840.3705, "longitude": 631.8105, regards Klaus From michabailey at gmail.com Tue Dec 29 17:47:20 2015 From: michabailey at gmail.com (Micha Bailey) Date: Tue, 29 Dec 2015 18:47:20 +0200 Subject: [atlas] Ticket response times Message-ID: Hi, what's the average time for responses to atlas at ripe.net tickets? I've been waiting almost 2 months to hear back on 1193254, and was wondering if that's a typical wait time or if it fell between the cracks... -------------- next part -------------- An HTML attachment was scrubbed... URL: From marco at marcoslater.com Tue Dec 29 18:26:32 2015 From: marco at marcoslater.com (Marco Slater) Date: Tue, 29 Dec 2015 17:26:32 +0000 Subject: [atlas] Ticket response times In-Reply-To: References: Message-ID: <77781591-0F64-473F-9854-A9685BCD3935@marcoslater.com> I've gotten replies off them within a few days both times I mailed them. :) Maybe your ticket got lost in the system? Haha. - Marco > On 29 Dec 2015, at 16:47, Micha Bailey wrote: > > Hi, what's the average time for responses to atlas at ripe.net tickets? I've been waiting almost 2 months to hear back on 1193254, and was wondering if that's a typical wait time or if it fell between the cracks... -------------- next part -------------- An HTML attachment was scrubbed... URL: From woeber at cc.univie.ac.at Tue Dec 29 19:12:42 2015 From: woeber at cc.univie.ac.at (Wilfried Woeber) Date: Tue, 29 Dec 2015 19:12:42 +0100 Subject: [atlas] Exploring the Idea of RIPE Atlas Virtual Probes In-Reply-To: <5677DC5C.3000008@ripe.net> References: <5677DAE8.80602@ripe.net> <5677DC5C.3000008@ripe.net> Message-ID: <5682CD1A.70605@cc.univie.ac.at> Dear Atlas Community! On 2015-12-21 12:02, Vesna Manojlovic wrote: > Dear colleagues, > > Some of you have asked about Virtual Probes on this list. Indeed :-) > Although we don't plan to make virtual probes available in 2016, > we do plan to investigate this idea and develop some prototypes. Fair enough. > Please find more details on RIPE Labs: I'll try to put my thoughts into some well-structured words, over there. I hope to succeed, but no premature promises yet... > https://labs.ripe.net/Members/suzanne_taylor_muzzin/exploring-the-idea-of-ripe-atlas-virtual-probes > > Kind regards, > Vesna Manojlovic > RIPE NCC All the best for (2015)++ Wilfried From gil at magisto.com Tue Dec 29 20:49:28 2015 From: gil at magisto.com (Gil Bahat) Date: Tue, 29 Dec 2015 21:49:28 +0200 Subject: [atlas] Exploring the Idea of RIPE Atlas Virtual Probes In-Reply-To: <5682CD1A.70605@cc.univie.ac.at> References: <5677DAE8.80602@ripe.net> <5677DC5C.3000008@ripe.net> <5682CD1A.70605@cc.univie.ac.at> Message-ID: We also support the idea of expanding the network. If it's done in a modular fashion, users can pick their desired veracity levels to the task at hand. we'd like to see more information on mobile data as network uses shift a lot to mobile and (for various reasons) it's very hard to get current probes on such networks and ultimately having an ATLAS-like app might be the only realistic way to go about it. integration into open source platforms such as openwrt or the turris omnia would also be most welcome. Regards, Gil Bahat, DevOps and Network Engineer, Magisto Ltd. On Tue, Dec 29, 2015 at 8:12 PM, Wilfried Woeber wrote: > Dear Atlas Community! > > On 2015-12-21 12:02, Vesna Manojlovic wrote: > > Dear colleagues, > > > > Some of you have asked about Virtual Probes on this list. > > Indeed :-) > > > Although we don't plan to make virtual probes available in 2016, > > we do plan to investigate this idea and develop some prototypes. > > Fair enough. > > > Please find more details on RIPE Labs: > > I'll try to put my thoughts into some well-structured words, over there. > I hope to succeed, but no premature promises yet... > > > > https://labs.ripe.net/Members/suzanne_taylor_muzzin/exploring-the-idea-of-ripe-atlas-virtual-probes > > > > Kind regards, > > Vesna Manojlovic > > RIPE NCC > > All the best for (2015)++ > Wilfried > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From colinj at mx5.org.uk Tue Dec 29 21:15:01 2015 From: colinj at mx5.org.uk (Colin Johnston) Date: Tue, 29 Dec 2015 20:15:01 +0000 Subject: [atlas] Exploring the Idea of RIPE Atlas Virtual Probes In-Reply-To: References: <5677DAE8.80602@ripe.net> <5677DC5C.3000008@ripe.net> <5682CD1A.70605@cc.univie.ac.at> Message-ID: <9AB9BB8E-5800-4E58-B24E-3CA0F21FC97D@mx5.org.uk> iphone virtual app probe would be great as well :) Sent from my iPhone > On 29 Dec 2015, at 19:49, Gil Bahat wrote: > > We also support the idea of expanding the network. If it's done in a modular fashion, users can pick their desired veracity levels to the task at hand. we'd like to see more information on mobile data as network uses shift a lot to mobile and (for various reasons) it's very hard to get current probes on such networks and ultimately having an ATLAS-like app might be the only realistic way to go about it. > > integration into open source platforms such as openwrt or the turris omnia would also be most welcome. > > Regards, > > Gil Bahat, > DevOps and Network Engineer, > Magisto Ltd. > >> On Tue, Dec 29, 2015 at 8:12 PM, Wilfried Woeber wrote: >> Dear Atlas Community! >> >> On 2015-12-21 12:02, Vesna Manojlovic wrote: >> > Dear colleagues, >> > >> > Some of you have asked about Virtual Probes on this list. >> >> Indeed :-) >> >> > Although we don't plan to make virtual probes available in 2016, >> > we do plan to investigate this idea and develop some prototypes. >> >> Fair enough. >> >> > Please find more details on RIPE Labs: >> >> I'll try to put my thoughts into some well-structured words, over there. >> I hope to succeed, but no premature promises yet... >> >> > https://labs.ripe.net/Members/suzanne_taylor_muzzin/exploring-the-idea-of-ripe-atlas-virtual-probes >> > >> > Kind regards, >> > Vesna Manojlovic >> > RIPE NCC >> >> All the best for (2015)++ >> Wilfried > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michabailey at gmail.com Tue Dec 29 21:35:11 2015 From: michabailey at gmail.com (Micha Bailey) Date: Tue, 29 Dec 2015 22:35:11 +0200 Subject: [atlas] Exploring the Idea of RIPE Atlas Virtual Probes In-Reply-To: <9AB9BB8E-5800-4E58-B24E-3CA0F21FC97D@mx5.org.uk> References: <5677DAE8.80602@ripe.net> <5677DC5C.3000008@ripe.net> <5682CD1A.70605@cc.univie.ac.at> <9AB9BB8E-5800-4E58-B24E-3CA0F21FC97D@mx5.org.uk> Message-ID: I would imagine that having probe apps on mobile devices would be very impractical in terms of battery usage, unreliable connections, the device itself not being on/connected 24/7, etc. In addition, I believe it would not be possible on iOS. You can't really have an app like this running full-time in the background. Only certain categories of apps are allowed to do this (e.g. GPS turn-by-turn navigation and audio players), and I can't imagine anything like an Atlas Probe will make it through App Review. On Tuesday, December 29, 2015, Colin Johnston wrote: > iphone virtual app probe would be great as well :) > > > Sent from my iPhone > > On 29 Dec 2015, at 19:49, Gil Bahat > wrote: > > We also support the idea of expanding the network. If it's done in a > modular fashion, users can pick their desired veracity levels to the task > at hand. we'd like to see more information on mobile data as network uses > shift a lot to mobile and (for various reasons) it's very hard to get > current probes on such networks and ultimately having an ATLAS-like app > might be the only realistic way to go about it. > > integration into open source platforms such as openwrt or the turris omnia > would also be most welcome. > > Regards, > > Gil Bahat, > DevOps and Network Engineer, > Magisto Ltd. > > On Tue, Dec 29, 2015 at 8:12 PM, Wilfried Woeber > wrote: > >> Dear Atlas Community! >> >> On 2015-12-21 12:02, Vesna Manojlovic wrote: >> > Dear colleagues, >> > >> > Some of you have asked about Virtual Probes on this list. >> >> Indeed :-) >> >> > Although we don't plan to make virtual probes available in 2016, >> > we do plan to investigate this idea and develop some prototypes. >> >> Fair enough. >> >> > Please find more details on RIPE Labs: >> >> I'll try to put my thoughts into some well-structured words, over there. >> I hope to succeed, but no premature promises yet... >> >> > >> https://labs.ripe.net/Members/suzanne_taylor_muzzin/exploring-the-idea-of-ripe-atlas-virtual-probes >> > >> > Kind regards, >> > Vesna Manojlovic >> > RIPE NCC >> >> All the best for (2015)++ >> Wilfried >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From colinj at mx5.org.uk Tue Dec 29 21:39:18 2015 From: colinj at mx5.org.uk (Colin Johnston) Date: Tue, 29 Dec 2015 20:39:18 +0000 Subject: [atlas] Exploring the Idea of RIPE Atlas Virtual Probes In-Reply-To: References: <5677DAE8.80602@ripe.net> <5677DC5C.3000008@ripe.net> <5682CD1A.70605@cc.univie.ac.at> <9AB9BB8E-5800-4E58-B24E-3CA0F21FC97D@mx5.org.uk> Message-ID: iphones are being used as reliable routers with 4g and wireless sharing failover so having background probe app , like twitter,email auto checking would be great colin Sent from my iPhone > On 29 Dec 2015, at 20:35, Micha Bailey wrote: > > I would imagine that having probe apps on mobile devices would be very impractical in terms of battery usage, unreliable connections, the device itself not being on/connected 24/7, etc. > In addition, I believe it would not be possible on iOS. You can't really have an app like this running full-time in the background. Only certain categories of apps are allowed to do this (e.g. GPS turn-by-turn navigation and audio players), and I can't imagine anything like an Atlas Probe will make it through App Review. > >> On Tuesday, December 29, 2015, Colin Johnston wrote: >> iphone virtual app probe would be great as well :) >> >> >> Sent from my iPhone >> >>> On 29 Dec 2015, at 19:49, Gil Bahat wrote: >>> >>> We also support the idea of expanding the network. If it's done in a modular fashion, users can pick their desired veracity levels to the task at hand. we'd like to see more information on mobile data as network uses shift a lot to mobile and (for various reasons) it's very hard to get current probes on such networks and ultimately having an ATLAS-like app might be the only realistic way to go about it. >>> >>> integration into open source platforms such as openwrt or the turris omnia would also be most welcome. >>> >>> Regards, >>> >>> Gil Bahat, >>> DevOps and Network Engineer, >>> Magisto Ltd. >>> >>>> On Tue, Dec 29, 2015 at 8:12 PM, Wilfried Woeber wrote: >>>> Dear Atlas Community! >>>> >>>> On 2015-12-21 12:02, Vesna Manojlovic wrote: >>>> > Dear colleagues, >>>> > >>>> > Some of you have asked about Virtual Probes on this list. >>>> >>>> Indeed :-) >>>> >>>> > Although we don't plan to make virtual probes available in 2016, >>>> > we do plan to investigate this idea and develop some prototypes. >>>> >>>> Fair enough. >>>> >>>> > Please find more details on RIPE Labs: >>>> >>>> I'll try to put my thoughts into some well-structured words, over there. >>>> I hope to succeed, but no premature promises yet... >>>> >>>> > https://labs.ripe.net/Members/suzanne_taylor_muzzin/exploring-the-idea-of-ripe-atlas-virtual-probes >>>> > >>>> > Kind regards, >>>> > Vesna Manojlovic >>>> > RIPE NCC >>>> >>>> All the best for (2015)++ >>>> Wilfried -------------- next part -------------- An HTML attachment was scrubbed... URL: From gil at magisto.com Tue Dec 29 21:59:11 2015 From: gil at magisto.com (Gil Bahat) Date: Tue, 29 Dec 2015 22:59:11 +0200 Subject: [atlas] Exploring the Idea of RIPE Atlas Virtual Probes In-Reply-To: References: <5677DAE8.80602@ripe.net> <5677DC5C.3000008@ripe.net> <5682CD1A.70605@cc.univie.ac.at> <9AB9BB8E-5800-4E58-B24E-3CA0F21FC97D@mx5.org.uk> Message-ID: well, if you constrain yourself to workalike of physical probes, you will not get satisfactory results... yes, mobile networks and mobile phones are unreliable. this doesn't make them less interesting to researchers and professionals - on the contrary. you will simply have to deal with the limitations. a good way to deal with limitations is by having access to more such probes. in particular, since mobiles are (well...) mobile, reproducibility is next to impossible and cannot be a design goal for this class of measurements. still OK for many uses. this also means that such probes will probably be allowed by iOS to check for requested measurements and wake up only periodically, e.g. by push notification via the notification service, and thus pass app review. If there is a legitimate need and use for an app, you can usually pass app review. On Tue, Dec 29, 2015 at 10:35 PM, Micha Bailey wrote: > I would imagine that having probe apps on mobile devices would be very > impractical in terms of battery usage, unreliable connections, the device > itself not being on/connected 24/7, etc. > In addition, I believe it would not be possible on iOS. You can't really > have an app like this running full-time in the background. Only certain > categories of apps are allowed to do this (e.g. GPS turn-by-turn navigation > and audio players), and I can't imagine anything like an Atlas Probe will > make it through App Review. > > > On Tuesday, December 29, 2015, Colin Johnston wrote: > >> iphone virtual app probe would be great as well :) >> >> >> Sent from my iPhone >> >> On 29 Dec 2015, at 19:49, Gil Bahat wrote: >> >> We also support the idea of expanding the network. If it's done in a >> modular fashion, users can pick their desired veracity levels to the task >> at hand. we'd like to see more information on mobile data as network uses >> shift a lot to mobile and (for various reasons) it's very hard to get >> current probes on such networks and ultimately having an ATLAS-like app >> might be the only realistic way to go about it. >> >> integration into open source platforms such as openwrt or the turris >> omnia would also be most welcome. >> >> Regards, >> >> Gil Bahat, >> DevOps and Network Engineer, >> Magisto Ltd. >> >> On Tue, Dec 29, 2015 at 8:12 PM, Wilfried Woeber >> wrote: >> >>> Dear Atlas Community! >>> >>> On 2015-12-21 12:02, Vesna Manojlovic wrote: >>> > Dear colleagues, >>> > >>> > Some of you have asked about Virtual Probes on this list. >>> >>> Indeed :-) >>> >>> > Although we don't plan to make virtual probes available in 2016, >>> > we do plan to investigate this idea and develop some prototypes. >>> >>> Fair enough. >>> >>> > Please find more details on RIPE Labs: >>> >>> I'll try to put my thoughts into some well-structured words, over there. >>> I hope to succeed, but no premature promises yet... >>> >>> > >>> https://labs.ripe.net/Members/suzanne_taylor_muzzin/exploring-the-idea-of-ripe-atlas-virtual-probes >>> > >>> > Kind regards, >>> > Vesna Manojlovic >>> > RIPE NCC >>> >>> All the best for (2015)++ >>> Wilfried >>> >>> >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jterbeest at ripe.net Tue Dec 29 22:37:39 2015 From: jterbeest at ripe.net (Johan ter Beest) Date: Tue, 29 Dec 2015 22:37:39 +0100 Subject: [atlas] Anchor probes with broken lat/lon In-Reply-To: <5682A8EC.2030604@pernau.at> References: <5682A8EC.2030604@pernau.at> Message-ID: <5682FD23.3010608@ripe.net> Hi Klaus, On 29/12/15 16:38, Klaus Darilion wrote: > https://atlas.ripe.net/api/v1/probe/6155/ > "latitude": 2228.7695, > "longitude": -4412.6105, > > https://atlas.ripe.net/api/v1/probe/6166/ > "latitude": 2840.3705, > "longitude": 631.8105, These have been fixed, thanks for noticing and reporting :) Kind regards, Johan ter Beest > > regards > Klaus > > From mgalante at ripe.net Wed Dec 30 12:36:29 2015 From: mgalante at ripe.net (Michela Galante) Date: Wed, 30 Dec 2015 12:36:29 +0100 Subject: [atlas] Ticket response times In-Reply-To: <77781591-0F64-473F-9854-A9685BCD3935@marcoslater.com> References: <77781591-0F64-473F-9854-A9685BCD3935@marcoslater.com> Message-ID: <864FCB99-4855-4F66-A90A-AEBE93E02EFF@ripe.net> Dear Micha, I would like to explain to the list what happened in this case and what RIPE Atlas users can expect if they send an email to atlas at ripe.net. Normally our Customer Services department tries to reply to all tickets within one working day of their receipt. In cases where the ticket needs to be escalated, as was the case for your ticket, we try to reply within one week. In your specific case, after a first reply the ticket was resolved. When you added a response to the first reply the ticket was then automatically reopened, but it did not reach the engineer who was working on it so you did not get any reply. We apologise for the inconvenience. Best regards, Michela Galante Measurements Community Building RIPE NCC > On 29 Dec 2015, at 18:26, Marco Slater wrote: > > I've gotten replies off them within a few days both times I mailed them. :) > > Maybe your ticket got lost in the system? Haha. > > - Marco > > On 29 Dec 2015, at 16:47, Micha Bailey wrote: > >> Hi, what's the average time for responses to atlas at ripe.net tickets? I've been waiting almost 2 months to hear back on 1193254, and was wondering if that's a typical wait time or if it fell between the cracks... From klaus.mailinglists at pernau.at Wed Dec 30 15:39:29 2015 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Wed, 30 Dec 2015 15:39:29 +0100 Subject: [atlas] How to deal with inaccurate geocoding of probes Message-ID: <5683ECA1.5080909@pernau.at> Hi! Inspired by https://perso.telecom-paristech.fr/~drossi/index.php?n=Dataset.Anycast I wanted to detect my Anycast locations using the Atlas probes. The problem is, that my results are only as accurate as the geocoding of the Atlas probes. For example probe #19273 is reported to be somewhere in Kansas. Bit the probe is only 5ms away from my LAX server and also traceroute indicates the probe is in LAX (traceroute to 63.84.150.1). So, now I am seeking some advice how to handle such problems. Is there some tag that indicates "verified location"? Any other ideas? Thanks Klaus From jterbeest at ripe.net Wed Dec 30 19:06:26 2015 From: jterbeest at ripe.net (Johan ter Beest) Date: Wed, 30 Dec 2015 19:06:26 +0100 Subject: [atlas] How to deal with inaccurate geocoding of probes In-Reply-To: <5683ECA1.5080909@pernau.at> References: <5683ECA1.5080909@pernau.at> Message-ID: <56841D22.7090702@ripe.net> Hi Klaus, On 30/12/15 15:39, Klaus Darilion wrote: > Hi! > > Inspired by > https://perso.telecom-paristech.fr/~drossi/index.php?n=Dataset.Anycast I > wanted to detect my Anycast locations using the Atlas probes. > > The problem is, that my results are only as accurate as the geocoding of > the Atlas probes. > > For example probe #19273 is reported to be somewhere in Kansas. I guess we're not in Kansas anymore ;) > Bit the > probe is only 5ms away from my LAX server and also traceroute indicates > the probe is in LAX (traceroute to 63.84.150.1). > > So, now I am seeking some advice how to handle such problems. Is there > some tag that indicates "verified location"? Any other ideas? This particular probe has the tag: Auto GeoIP Country which means that we could not determine the location any more accurately than at country level. Originally, this probe was located somewhere in Canada but we noticed it was not there anymore so we automatically moved it closer to where we think it really is. Unfortunately, we could not be more precise than country level which is why we tagged it this way. We are constantly working on ways to improve the automatic geotagging of probes but the best way is still for probe hosts to keep the location of the probe up to date. Regards, Johan ter Beest RIPE Atlas team > > Thanks > Klaus > > > From mgalante at ripe.net Thu Dec 31 13:04:33 2015 From: mgalante at ripe.net (Michela Galante) Date: Thu, 31 Dec 2015 13:04:33 +0100 Subject: [atlas] Seven new RIPE Atlas anchors have joined the community Message-ID: <2CAA4652-0630-446E-BA74-BD3952B61026@ripe.net> Dear RIPE Atlas users, Since the previous announcement, seven new RIPE Atlas anchors have been activated bringing the total number to 164. - nc-nou-as56055, hosted by Micro Logic Systems (MLS) in Noum?a, New Caledonia. - bg-sof-as47872, hosted by Sofia Connect in Sofia, Bulgaria. - bg-sls-as198228, hosted by Silistra Telecom Solutions in Silistra, Bulgaria. - fr-ysd-as201958, hosted by Claranet in Saint-Denis, France. - de-erl-as680, hosted by Friedrich-Alexander-Universit?t Erlangen-N?rnberg in Erlangen, Germany. - cr-sjo-as263779, hosted by NIC Costa Rica in San Jos?, Costa Rica and sponsored by LACNIC. - nl-roo-as43350, hosted by NFOrce Entertainment in Roosendaal, Netherlands. The map of all anchor locations is available at: https://atlas.ripe.net/anchors/map/ You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ And here are the logos and links to hosting companies: https://atlas.ripe.net/get-involved/community/#!tab-anchor-sponsors We are still accepting new applications from organisations interested in hosting a RIPE Atlas anchor. We are particularly interested in deploying anchors in the Middle East, Western Asia, Latin America and Africa, in order to add more geographical diversity to the measurement data. There are more organisations that want to host a RIPE Atlas anchor but don?t have the necessary funding. To learn more about sponsoring an anchor, please contact us at mcb at ripe.net To apply for your own RIPE Atlas anchor: https://atlas.ripe.net/get-involved/become-an-anchor-host/ For any other questions, please contact us at atlas at ripe.net We?d like to thank all the anchor hosts and the organisations sponsoring anchors for their support in 2015. Thanks to you it was possible to expand the coverage and reach this amazing goal. Wishing all of you the best for 2016. Michela Galante on behalf of the RIPE Atlas Team RIPE NCC