From mgalante at ripe.net Mon Feb 3 15:31:14 2014 From: mgalante at ripe.net (Michela Galante) Date: Mon, 3 Feb 2014 15:31:14 +0100 Subject: [atlas] =?iso-8859-1?q?Hringi=F0an_=28IS=29_has_joined_RIPE_Atlas?= =?iso-8859-1?q?_anchors?= Message-ID: Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called is-rey-as25509 and it is hosted by Hringi?an in Reykjavik, Iceland. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2626 bytes Desc: not available URL: From mgalante at ripe.net Thu Feb 6 11:13:37 2014 From: mgalante at ripe.net (Michela Galante) Date: Thu, 6 Feb 2014 11:13:37 +0100 Subject: [atlas] SIDN (NL) has joined RIPE Atlas anchors Message-ID: Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called nl-arn-as1140 and it is hosted by SIDN in Arnhem, Netherlands. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2626 bytes Desc: not available URL: From BECHA at ripe.net Fri Feb 7 14:26:03 2014 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 07 Feb 2014 14:26:03 +0100 Subject: [atlas] Easier access to bandwidth data of RIPE Atlas anchors Message-ID: <52F4DEEB.1080408@ripe.net> Dear RIPE Atlas community, we have added a small feature to the listing of RIPE Atlas anchors: https://atlas.ripe.net/anchors/list/ If you click on the hostname of the anchor (e.g. nl-ams-as3333), the link will take you to the graph of bandwidth, served by RIPEstat: https://stat.ripe.net/m/widget/atlas-probe-traffic#w.probe_id=6001&w.measurement_id=1008&w.mode=condensed This is the same graph that appears on the RIPE Atlas "probe page" of every anchor, but we decided to add a direct link to the bandwidth graph rather then to the whole probe page, since we are working on the improved version of it. The graph is zoomable, so you can see the whole year of data for older anchors; and it has other features described in this RIPE Labs article: https://labs.ripe.net/Members/becha/seismograph-and-other-new-ripe-atlas-features/#zoom-ping Hosts of RIPE Atlas anchors can access the same feature via their admin interface. Other features on this "list" page of RIPE Atlas anchors are: - sortable columns: you can sort by hostname, company name, city or country; in ascending and descending order - "clickable" links to anchoring measurement per anchor, per type We hope that this will give you more insight into the operations of RIPE Atlas anchors to date. We are still accepting applications from new hosts: https://atlas.ripe.net/get-involved/become-an-anchor-host/ Regards, Vesna From staylormuz at ripe.net Wed Feb 12 10:02:36 2014 From: staylormuz at ripe.net (Suzanne Taylor Muzzin) Date: Wed, 12 Feb 2014 10:02:36 +0100 Subject: [atlas] New on RIPE Labs: The Seismograph User Guide Message-ID: <9D7ACB0A-EDD1-4350-B31E-03308FACBFFC@ripe.net> Dear colleagues, Please find a new article on RIPE Labs that explains how you can get the most out of the Seismograph, an interactive RIPE Atlas tool that provides an overview of different RTT and packet loss trends measured by multiple probes. The Seismograph User Guide https://labs.ripe.net/Members/massimo_candela/seismograph-user-guide Kind regards, Suzanne Taylor Muzzin Measurements Community Building RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2379 bytes Desc: not available URL: From s.eravuchira at jacobs-university.de Wed Feb 12 13:46:03 2014 From: s.eravuchira at jacobs-university.de (Eravuchira, Steffie Jacob) Date: Wed, 12 Feb 2014 12:46:03 +0000 Subject: [atlas] Some of the UDM results are unavailable Message-ID: <081E9415D79F9A469A4B6C79815FC0926F2DFC@SXCHMB01.jacobs.jacobs-university.de> Dear community, I am trying to access some of the the UDMs. I find some problems in getting results for some probes in some UDM. For example, I can access the UDM [1] and get measurements from all the probes. Whereas when I try to filter the same UDM using probe ID, the result is not available for some particular probes [2]. But it is available for some others [3] in the same UDM. [1] https://atlas.ripe.net/api/v1/measurement/1037214/result/ [2] https://atlas.ripe.net/api/v1/measurement/1037214/result/?prb_id=2330 [3] https://atlas.ripe.net/api/v1/measurement/1037214/result/?prb_id=12781 Kind Regards, Steffie From robert at ripe.net Wed Feb 12 15:20:18 2014 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 12 Feb 2014 15:20:18 +0100 Subject: [atlas] Some of the UDM results are unavailable In-Reply-To: <081E9415D79F9A469A4B6C79815FC0926F2DFC@SXCHMB01.jacobs.jacobs-university.de> References: <081E9415D79F9A469A4B6C79815FC0926F2DFC@SXCHMB01.jacobs.jacobs-university.de> Message-ID: <52FB8322.4040209@ripe.net> On 2014.02.12. 13:46, Eravuchira, Steffie Jacob wrote: > > Dear community, > > I am trying to access some of the the UDMs. I find some problems in getting results for some probes in some UDM. > > For example, I can access the UDM [1] and get measurements from all the probes. > Whereas when I try to filter the same UDM using probe ID, the result is not available for some particular probes [2]. > But it is available for some others [3] in the same UDM. > > [1] https://atlas.ripe.net/api/v1/measurement/1037214/result/ > [2] https://atlas.ripe.net/api/v1/measurement/1037214/result/?prb_id=2330 > [3] https://atlas.ripe.net/api/v1/measurement/1037214/result/?prb_id=12781 > > > > Kind Regards, > Steffie Hello, Thank you for the report, we're looking into this. Regards, Robert From dquinn at ripe.net Wed Feb 12 16:02:52 2014 From: dquinn at ripe.net (Daniel Quinn) Date: Wed, 12 Feb 2014 15:02:52 +0000 Subject: [atlas] Some of the UDM results are unavailable In-Reply-To: <52FB8322.4040209@ripe.net> References: <081E9415D79F9A469A4B6C79815FC0926F2DFC@SXCHMB01.jacobs.jacobs-university.de> <52FB8322.4040209@ripe.net> Message-ID: <52FB8D1C.6000800@ripe.net> Thanks for the report! It turns out that one of the changes I made to the API for performance reasons had the opposite effect in a few cases, especially older probes with newer measurements. I've since patched it to be a little more selective in its application of said changes, and things appear to be working a lot better now. Thanks again for the report, and next time you find something like this, please post to atlas-bugs at ripe.net instead of the public list so we don't bother everyone else with these sorts of emails. From BECHA at ripe.net Wed Feb 12 16:47:01 2014 From: BECHA at ripe.net (Vesna Manojlovic) Date: Wed, 12 Feb 2014 16:47:01 +0100 Subject: [atlas] Using RIPE Atlas for monitoring: introducing "Status Checks" In-Reply-To: <52FB92BE.8030702@ripe.net> References: <52FB92BE.8030702@ripe.net> Message-ID: <52FB9775.4090302@ripe.net> Dear colleagues, After having some of you testing Status Checks, we are now introducing this new feature to all users. It allows you to integrate RIPE Atlas into any monitoring tool you currently use, such as Nagios or Icinga. Please find a new article on RIPE Labs that explains simple steps, gives an example, and points to our future plans: https://labs.ripe.net/Members/suzanne_taylor_muzzin/introducing-ripe-atlas-status-checks Direct link to Status Checks: https://atlas.ripe.net/docs/status-checks/ We are pleased to announce this feature that the operators community has been asking for, and we are looking forward to both your feedback and success stories. Kind regards, Vesna Manojlovic Measurements Community Building RIPE NCC From mgalante at ripe.net Thu Feb 13 14:08:15 2014 From: mgalante at ripe.net (Michela Galante) Date: Thu, 13 Feb 2014 14:08:15 +0100 Subject: [atlas] VIX (AT) has joined RIPE Atlas anchors Message-ID: <818B8608-85F3-4A51-B6D5-EF9316B7A2AD@ripe.net> Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called at-vie-as1120 and it is hosted by VIX in Vienna, Austria on behalf of RIPE NCC since they are one of our RIS Remote Route Collector locations. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2626 bytes Desc: not available URL: From mgalante at ripe.net Mon Feb 17 15:33:32 2014 From: mgalante at ripe.net (Michela Galante) Date: Mon, 17 Feb 2014 15:33:32 +0100 Subject: [atlas] CERN (FR) has joined RIPE Atlas anchors Message-ID: Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called fr-prm-as513 and it is hosted by CERN in Pr?vessin-Mo?ns, France on behalf of RIPE NCC since they are one of our k-root hosts and RIS Remote Route Collector locations. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2626 bytes Desc: not available URL: From sebastian at nzrs.net.nz Mon Feb 17 21:34:59 2014 From: sebastian at nzrs.net.nz (Sebastian Castro) Date: Tue, 18 Feb 2014 09:34:59 +1300 Subject: [atlas] Denial of Measurement Message-ID: <53027273.4080707@nzrs.net.nz> Hi: Trying to investigate a problem with one of our boxes, I came across the following error message: "10 UDMs are already measuring 202.46.187.130/2001:dce:7000:2:0:0:0:130. Cannot add 1 more" What I did was to add a one-off DNS UDM to ns2.dns.net.nz, to track if reachability was OK, but I can't because someone else is already doing that. None of those UDMs is mine, so effectively someone created a "Denial of Measurement" against me. Any recommendations what to do about this? Cheers, -- Sebastian Castro Technical Research Manager .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 495 2337 mobile: +64 21 400535 From robert at ripe.net Tue Feb 18 09:20:05 2014 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 18 Feb 2014 09:20:05 +0100 Subject: [atlas] Denial of Measurement In-Reply-To: <53027273.4080707@nzrs.net.nz> References: <53027273.4080707@nzrs.net.nz> Message-ID: <530317B5.70002@ripe.net> On 2014.02.17. 21:34, Sebastian Castro wrote: > Hi: > > Trying to investigate a problem with one of our boxes, I came across the > following error message: > > "10 UDMs are already measuring 202.46.187.130/2001:dce:7000:2:0:0:0:130. > Cannot add 1 more" > > What I did was to add a one-off DNS UDM to ns2.dns.net.nz, to track if > reachability was OK, but I can't because someone else is already doing > that. None of those UDMs is mine, so effectively someone created a > "Denial of Measurement" against me. > > Any recommendations what to do about this? > > > Cheers, Hi, This feature is there in order to protect the destinations from too many measurements by too many users. A related feature that we're working on is to offer you the already running measurements in such a case -- because there's a good chance that someone is already doing something similar to what you wanted, and you can just use those results. In this particular case, .nz is part of the measurement set of the upcoming new DNSMON service, which will go public soon. So all .nz DNS servers are measured already. I'll contact you off-list about the details. Regards, Robert From Woeber at CC.UniVie.ac.at Tue Feb 18 17:51:08 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Tue, 18 Feb 2014 17:51:08 +0100 Subject: [atlas] Logistics Q: probe "owner" leaving an organisation, but probe remains Message-ID: <53038F7C.7090705@CC.UniVie.ac.at> Hi folks, maybe there's already an FAQ answer somewhere or it has been discussed before, and I missed it. Please point me into the right direction :-) Background: I handed out a probe (from an ambassador batch) and the probe was connected to the 'net. Now, a rather short while later, the "owner" of that probe left the organisation, and left the probe behind. It is still connected :-) What is the procedure or advice for assigning a new "owner" from the hosting organisation? Thanks, Wilfried From alexsaroyan at gmail.com Wed Feb 19 06:08:02 2014 From: alexsaroyan at gmail.com (Alex Saroyan) Date: Wed, 19 Feb 2014 09:08:02 +0400 Subject: [atlas] Logistics Q: probe "owner" leaving an organisation, but probe remains Message-ID: Hi, Owner can transfer the probe to another host. Best Regards /Alex Saroyan Wilfried Woeber wrote: >Hi folks, maybe there's already an FAQ answer somewhere or it has been >discussed before, and I missed it. Please point me into the right direction :-) > >Background: > >I handed out a probe (from an ambassador batch) and the probe was connected to >the 'net. Now, a rather short while later, the "owner" of that probe left the >organisation, and left the probe behind. It is still connected :-) > >What is the procedure or advice for assigning a new "owner" from the hosting >organisation? > >Thanks, >Wilfried > From Woeber at CC.UniVie.ac.at Wed Feb 19 08:14:12 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Wed, 19 Feb 2014 08:14:12 +0100 Subject: [atlas] Logistics Q: probe "owner" leaving an organisation, but probe remains In-Reply-To: References: Message-ID: <530459C4.3060301@CC.UniVie.ac.at> Thanks, I'll try to get in touch with the person. Wilfried Alex Saroyan wrote: > Hi, > > Owner can transfer the probe to another host. > > Best Regards > /Alex Saroyan > > Wilfried Woeber wrote: > > >>Hi folks, maybe there's already an FAQ answer somewhere or it has been >>discussed before, and I missed it. Please point me into the right direction :-) >> >>Background: >> >>I handed out a probe (from an ambassador batch) and the probe was connected to >>the 'net. Now, a rather short while later, the "owner" of that probe left the >>organisation, and left the probe behind. It is still connected :-) >> >>What is the procedure or advice for assigning a new "owner" from the hosting >>organisation? >> >>Thanks, >>Wilfried >> From Woeber at CC.UniVie.ac.at Wed Feb 19 11:02:18 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Wed, 19 Feb 2014 11:02:18 +0100 Subject: [atlas] does a probe "know" the AS# it is living in? Message-ID: <5304812A.8000904@CC.UniVie.ac.at> Folks, a small group of people is starting to develop an idea for a new measurement and I am a memeber of that team. Now I wonder: does a probe know the AS number it is living in, or is this a piece of information that is maintained by the collectors and the various pieces of central programs and the display software? TIA, Wilfried From philip.homburg at ripe.net Wed Feb 19 11:09:12 2014 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 19 Feb 2014 11:09:12 +0100 Subject: [atlas] does a probe "know" the AS# it is living in? In-Reply-To: <5304812A.8000904@CC.UniVie.ac.at> References: <5304812A.8000904@CC.UniVie.ac.at> Message-ID: <530482C8.6090102@ripe.net> Hi Wilfried, On 2014/02/19 11:02 , Wilfried Woeber wrote: > a small group of people is starting to develop an idea for a new measurement > and I am a memeber of that team. > > Now I wonder: does a probe know the AS number it is living in, or is this > a piece of information that is maintained by the collectors and the various > pieces of central programs and the display software? Probes are not really aware of anything. They report what they find, but any policy decisions are taken on the controllers and higher up. Not that that should stop you trying to describe what you want :-) Philip From Woeber at CC.UniVie.ac.at Wed Feb 19 12:31:44 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Wed, 19 Feb 2014 12:31:44 +0100 Subject: [atlas] does a probe "know" the AS# it is living in? In-Reply-To: <530482C8.6090102@ripe.net> References: <5304812A.8000904@CC.UniVie.ac.at> <530482C8.6090102@ripe.net> Message-ID: <53049620.7070308@CC.UniVie.ac.at> Philip Homburg wrote: > Hi Wilfried, > > > On 2014/02/19 11:02 , Wilfried Woeber wrote: > >>a small group of people is starting to develop an idea for a new measurement >>and I am a memeber of that team. >> >>Now I wonder: does a probe know the AS number it is living in, or is this >>a piece of information that is maintained by the collectors and the various >>pieces of central programs and the display software? > > > Probes are not really aware of anything. They report what they find, but > any policy decisions are taken on the controllers and higher up. > > Not that that should stop you trying to describe what you want :-) Thanks Philip, :-) The background is an idea to generate some sort of unique ID (in a payload) for a measurement that includes both the Probe-ID and the AS# it is connected to/served by, plus potentially the probes IPv[46] Address. We are in the very, very early stages of brainstorming. > Philip Wilfried From f4w at echo.emu.st Wed Feb 19 16:54:29 2014 From: f4w at echo.emu.st (Mark Delany) Date: 19 Feb 2014 15:54:29 +0000 Subject: [atlas] Thoughts on allowing newer DNS RR queries? Message-ID: <20140219155429.13129.qmail@f5-external.bushwire.net> Outside of Atlas I've been doing a few tests to see how well CPE supports newer RR types. By newer I mean newer than AAAA. I'd like to do the same with the Atlas probes. Has there been discussion about being able to issue RR queries of newer types? On the query side, the Atlas device only needs to know enough to encode the type-value which could be supplied as a numeric if necessary. On the response side, a simple hex dump of the response would be good enough. I guess it's sort of a one-off test for most probes because once we know a probe and its intervening caches does or does not support a number of newer types, that situation is unlikely to require re-testing very often. So an alternative might be to make it a bootstrap sequence that the probe goes thru? Out of curiousity, how does the probe do the current DNS queries? Is it via dig or similar or is it coded into a program of some sort? Mark. From antony at ripe.net Thu Feb 20 12:46:11 2014 From: antony at ripe.net (Antony Antony) Date: Thu, 20 Feb 2014 12:46:11 +0100 Subject: [atlas] Thoughts on allowing newer DNS RR queries? In-Reply-To: <20140219155429.13129.qmail@f5-external.bushwire.net> References: <20140219155429.13129.qmail@f5-external.bushwire.net> Message-ID: <20140220114611.GA7205@kitten.ripe.net> Hi Mark, what is the specific RR query you are looking for? currently we support a bunch of them UDP or TCP. Here is a list. in class IN A, AAAA, ANY, CNAME, DS, DNSKEY, MX, NS, NSEC, NSEC3, PTR, RRSIG, SOA, SRV, NAPTR. class CHAOS hostname.bind, id.server, version.bind, version.server regards, -antony On Wed, Feb 19, 2014 at 03:54:29PM +0000, Mark Delany wrote: > Outside of Atlas I've been doing a few tests to see how well CPE > supports newer RR types. By newer I mean newer than AAAA. I'd like to > do the same with the Atlas probes. > > Has there been discussion about being able to issue RR queries of > newer types? > > On the query side, the Atlas device only needs to know enough to > encode the type-value which could be supplied as a numeric if > necessary. On the response side, a simple hex dump of the response > would be good enough. > > I guess it's sort of a one-off test for most probes because once we > know a probe and its intervening caches does or does not support a > number of newer types, that situation is unlikely to require > re-testing very often. So an alternative might be to make it a > bootstrap sequence that the probe goes thru? > > Out of curiousity, how does the probe do the current DNS queries? Is > it via dig or similar or is it coded into a program of some sort? > > > Mark. > > From Woeber at CC.UniVie.ac.at Thu Feb 20 14:18:48 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Thu, 20 Feb 2014 14:18:48 +0100 Subject: [atlas] Easier access to bandwidth data of RIPE Atlas anchors - choice of colours? In-Reply-To: <52F4DEEB.1080408@ripe.net> References: <52F4DEEB.1080408@ripe.net> Message-ID: <530600B8.8090304@CC.UniVie.ac.at> Vesna Manojlovic wrote: > Dear RIPE Atlas community, > > we have added a small feature to the listing of RIPE Atlas anchors: > https://atlas.ripe.net/anchors/list/ > > If you click on the hostname of the anchor (e.g. nl-ams-as3333), > the link will take you to the graph of bandwidth, served by RIPEstat: > https://stat.ripe.net/m/widget/atlas-probe-traffic#w.probe_id=6001&w.measurement_id=1008&w.mode=condensed I just had a look on some of these graphs. Some of them are easy to interpret, e.g. https://stat.ripe.net/m/widget/atlas-probe-traffic#w.probe_id=6001&w.measurement_id=1008&w.mode=condensed and https://stat.ripe.net/m/widget/atlas-probe-traffic#w.probe_id=6006&w.measurement_id=1008&w.mode=condensed Some others do "suffer" from overlay and the small contrast in colours used e.g. https://stat.ripe.net/m/widget/atlas-probe-traffic#w.probe_id=6042&w.measurement_id=1008&w.mode=condensed and https://stat.ripe.net/m/widget/atlas-probe-traffic#w.probe_id=6020&w.measurement_id=1008&w.mode=condensed I presume just selecting distinct clours/colour-groups for the "Bits" and the "Packets" data could improve the interpretation? (Unless there is a conscious selection of colours involved?) Thanks, Wilfried From robert at ripe.net Thu Feb 20 15:21:52 2014 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 20 Feb 2014 15:21:52 +0100 Subject: [atlas] Easier access to bandwidth data of RIPE Atlas anchors - choice of colours? In-Reply-To: <530600B8.8090304@CC.UniVie.ac.at> References: <52F4DEEB.1080408@ripe.net> <530600B8.8090304@CC.UniVie.ac.at> Message-ID: <53060F80.9020300@ripe.net> On 2014.02.20. 14:18, Wilfried Woeber wrote: > Vesna Manojlovic wrote: > >> Dear RIPE Atlas community, >> >> we have added a small feature to the listing of RIPE Atlas anchors: >> https://atlas.ripe.net/anchors/list/ >> >> If you click on the hostname of the anchor (e.g. nl-ams-as3333), >> the link will take you to the graph of bandwidth, served by RIPEstat: >> https://stat.ripe.net/m/widget/atlas-probe-traffic#w.probe_id=6001&w.measurement_id=1008&w.mode=condensed > > I just had a look on some of these graphs. Some of them are easy to interpret, > e.g. https://stat.ripe.net/m/widget/atlas-probe-traffic#w.probe_id=6001&w.measurement_id=1008&w.mode=condensed > and https://stat.ripe.net/m/widget/atlas-probe-traffic#w.probe_id=6006&w.measurement_id=1008&w.mode=condensed > > Some others do "suffer" from overlay and the small contrast in colours used > e.g. https://stat.ripe.net/m/widget/atlas-probe-traffic#w.probe_id=6042&w.measurement_id=1008&w.mode=condensed > and https://stat.ripe.net/m/widget/atlas-probe-traffic#w.probe_id=6020&w.measurement_id=1008&w.mode=condensed > > I presume just selecting distinct clours/colour-groups for the "Bits" and > the "Packets" data could improve the interpretation? > (Unless there is a conscious selection of colours involved?) > > Thanks, > Wilfried One thing that's worth noting is that you can turn lines on/off by clicking on the legend. Regards, Robert From colin at spakka.net Thu Feb 20 17:23:00 2014 From: colin at spakka.net (Colin Petrie) Date: Thu, 20 Feb 2014 17:23:00 +0100 Subject: [atlas] Thoughts on allowing newer DNS RR queries? In-Reply-To: <20140219155429.13129.qmail@f5-external.bushwire.net> References: <20140219155429.13129.qmail@f5-external.bushwire.net> Message-ID: <53062BE4.1010200@spakka.net> Hi Mark, On 2/19/14 4:54 PM, Mark Delany wrote: > Out of curiousity, how does the probe do the current DNS queries? Is > it via dig or similar or is it coded into a program of some sort? FYI, you can see the description of the commands on the probes here: https://labs.ripe.net/Members/philip_homburg/ripe-atlas-measurements-source-code And check out the latest sources and options for those here: https://atlas.ripe.net/get-involved/source-code/ Cheers Colin From f4w at echo.emu.st Thu Feb 20 19:29:50 2014 From: f4w at echo.emu.st (Mark Delany) Date: 20 Feb 2014 18:29:50 +0000 Subject: [atlas] Thoughts on allowing newer DNS RR queries? In-Reply-To: <20140220114611.GA7205@kitten.ripe.net> References: <20140219155429.13129.qmail@f5-external.bushwire.net> <20140220114611.GA7205@kitten.ripe.net> Message-ID: <20140220182950.18638.qmail@f5-external.bushwire.net> On 20Feb14, Antony Antony allegedly wrote: > Hi Mark, > what is the specific RR query you are looking for? > > currently we support a bunch of them UDP or TCP. Here is a list. > > in class IN > A, AAAA, ANY, CNAME, DS, DNSKEY, MX, NS, NSEC, NSEC3, PTR, RRSIG, SOA, SRV, NAPTR. > > class CHAOS > hostname.bind, id.server, version.bind, version.server Don't ask me why I made such a goof, but for some reason when I checked I thought I only saw a couple of types. Sorry. To answer your question, it wasn't a particular type I had in mind, it was more trying to ask the question of how well the infrastructure deals with new types. In the bad old days introducing a new type was deemed risky because a lot of middleware, such as caches and firewalls had type-specific code. I was wanting to test the claim that most modern middleware is type-oblivious and "just works" with new types. So ideally, it would be a type that doesn't exist or one that has just recently been published. Mark. From jaap at NLnetLabs.nl Thu Feb 20 19:54:48 2014 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Thu, 20 Feb 2014 19:54:48 +0100 Subject: [atlas] Thoughts on allowing newer DNS RR queries? In-Reply-To: <20140220182950.18638.qmail@f5-external.bushwire.net> References: <20140219155429.13129.qmail@f5-external.bushwire.net> <20140220114611.GA7205@kitten.ripe.net> <20140220182950.18638.qmail@f5-external.bushwire.net> Message-ID: <201402201854.s1KIsmHf035978@bela.nlnetlabs.nl> In the bad old days introducing a new type was deemed risky because a lot of middleware, such as caches and firewalls had type-specific code. I was wanting to test the claim that most modern middleware is type-oblivious and "just works" with new types. So ideally, it would be a type that doesn't exist or one that has just recently been published. The latest ones are according EUI48 and EUI64 (RFC 7043) and then there are a couple (some which are still draft not even mentioned in the list above) which are still draft or just proposed: NINFO RKEY CDS UR and TA. /** draft-reid-dnsext-zs */ LDNS_RR_TYPE_NINFO = 56, /** draft-reid-dnsext-rkey */ LDNS_RR_TYPE_RKEY = 57, /** draft-ietf-dnsop-trust-history */ LDNS_RR_TYPE_TALINK = 58, /** draft-barwood-dnsop-ds-publis */ LDNS_RR_TYPE_CDS = 59, /** DNSSEC Trust Authorities */ LDNS_RR_TYPE_TA = 32768, Enjoy! jaap From mgalante at ripe.net Fri Feb 21 10:18:07 2014 From: mgalante at ripe.net (Michela Galante) Date: Fri, 21 Feb 2014 10:18:07 +0100 Subject: [atlas] AusRegistry (AU) has joined RIPE Atlas anchors Message-ID: Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called au-mel-as38796 and it is hosted by AusRegistry in Melbourne, Australia. Congratulations to AusRegistry! This is the first anchor in Oceania and the second in the Asia and Pacific area. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-02-21 at 10.10.31.png Type: image/png Size: 159777 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2626 bytes Desc: not available URL: From atlas at liman.net Fri Feb 21 10:47:26 2014 From: atlas at liman.net (Lars-Johan Liman) Date: Fri, 21 Feb 2014 10:47:26 +0100 Subject: [atlas] Thoughts on allowing newer DNS RR queries? In-Reply-To: <20140220114611.GA7205@kitten.ripe.net> (Antony Antony's message of "Thu, 20 Feb 2014 12:46:11 +0100") References: <20140219155429.13129.qmail@f5-external.bushwire.net> <20140220114611.GA7205@kitten.ripe.net> Message-ID: <22r46wer0x.fsf@ziptop.autonomica.net> antony at ripe.net: > Hi Mark, > what is the specific RR query you are looking for? > currently we support a bunch of them UDP or TCP. Here is a list. > in class IN > A, AAAA, ANY, CNAME, DS, DNSKEY, MX, NS, NSEC, NSEC3, PTR, RRSIG, SOA, SRV, NAPTR. > class CHAOS > hostname.bind, id.server, version.bind, version.server I suggest allowing queries, not from mnemonics, but from ID-number. Any unsigned 16-bit number should be allowed, both for CLASS and for RRTYPE. The result can be presented as an ASCII-fied blob (BASE64? uuencode? Motorla S-records? ...) for parsing by interested parties. DNS infrastructure is supposed to be blackbox store-and-forward. So should Atlas be. Yes, I understand there may be design problems with this. I'm stating the desired long-term goal. And keeping mnemonics for the most common cases is of course desireable, but if there are (e.g.) space restriction in the poor little dongles, I suggest asking by number only, and have a front-end system that does necessary translations. Maybe I'm stating the obvious ... :-/ Cheers, /Liman From gsachot at oceanet-technology.com Wed Feb 26 12:15:41 2014 From: gsachot at oceanet-technology.com (Guillaume Sachot) Date: Wed, 26 Feb 2014 12:15:41 +0100 Subject: [atlas] Network configuration / Multiple VLANs Message-ID: <63FB52BD9AE2774282E44412A87377258C8D211F@OTSRV008> Hi, I have just received my Atlas probe, and I have an issue for the IPv6 part. Its definitive IPv4 public address does not share the same VLAN with the IPv6 subnet. Would it be possible to add an optional VLAN field in the network configuration? Thank you, Regards. -- Guillaume SACHOT Oceanet Technology Administrateur syst?me et r?seau Support : +332 28 07 14 88 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gsachot at oceanet-technology.com Wed Feb 26 12:28:14 2014 From: gsachot at oceanet-technology.com (Guillaume Sachot) Date: Wed, 26 Feb 2014 12:28:14 +0100 Subject: [atlas] Network configuration / Multiple VLANs In-Reply-To: References: <63FB52BD9AE2774282E44412A87377258C8D211F@OTSRV008> Message-ID: <63FB52BD9AE2774282E44412A87377258C8D2131@OTSRV008> I also thought of that, but I cannot adapt a datacenter network only for one probe :) Regards. -----Message d'origine----- De?: gsmachado at gmail.com [mailto:gsmachado at gmail.com] De la part de Guilherme Sperb Machado Envoy??: mercredi 26 f?vrier 2014 12:23 ??: Guillaume Sachot Cc?: ripe-atlas at ripe.net Objet?: Re: [atlas] Network configuration / Multiple VLANs Hello all, I faced the same issue when I configured the probes here. I solved such thing changing the network a bit, and putting both IP addresses in the same VLAN... but this is not optimum. Therefore, I agree, an additional VLAN field in the network configuration it would be great. :-) Cheers! On Wed, Feb 26, 2014 at 12:15 PM, Guillaume Sachot wrote: > Hi, > > > > I have just received my Atlas probe, and I have an issue for the IPv6 part. > > > > Its definitive IPv4 public address does not share the same VLAN with > the > IPv6 subnet. Would it be possible to add an optional VLAN field in > the network configuration? > > > > Thank you, > > Regards. > > > > > > -- > > Guillaume SACHOT > > Oceanet Technology > > Administrateur syst?me et r?seau > > Support : +332 28 07 14 88 > > -- ---------------------------------------------------- MSc. Guilherme Sperb Machado Researcher & PhD. student at UZH (Universit?t Z?rich) http://www.csg.uzh.ch/staff/machado/ ---------------------------------------------------- From machado at ifi.uzh.ch Wed Feb 26 12:23:17 2014 From: machado at ifi.uzh.ch (Guilherme Sperb Machado) Date: Wed, 26 Feb 2014 12:23:17 +0100 Subject: [atlas] Network configuration / Multiple VLANs In-Reply-To: <63FB52BD9AE2774282E44412A87377258C8D211F@OTSRV008> References: <63FB52BD9AE2774282E44412A87377258C8D211F@OTSRV008> Message-ID: Hello all, I faced the same issue when I configured the probes here. I solved such thing changing the network a bit, and putting both IP addresses in the same VLAN... but this is not optimum. Therefore, I agree, an additional VLAN field in the network configuration it would be great. :-) Cheers! On Wed, Feb 26, 2014 at 12:15 PM, Guillaume Sachot wrote: > Hi, > > > > I have just received my Atlas probe, and I have an issue for the IPv6 part. > > > > Its definitive IPv4 public address does not share the same VLAN with the > IPv6 subnet. Would it be possible to add an optional VLAN field in the > network configuration? > > > > Thank you, > > Regards. > > > > > > -- > > Guillaume SACHOT > > Oceanet Technology > > Administrateur syst?me et r?seau > > Support : +332 28 07 14 88 > > -- ---------------------------------------------------- MSc. Guilherme Sperb Machado Researcher & PhD. student at UZH (Universit?t Z?rich) http://www.csg.uzh.ch/staff/machado/ ---------------------------------------------------- From philip.homburg at ripe.net Wed Feb 26 13:49:03 2014 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 26 Feb 2014 13:49:03 +0100 Subject: [atlas] Network configuration / Multiple VLANs In-Reply-To: <63FB52BD9AE2774282E44412A87377258C8D2131@OTSRV008> References: <63FB52BD9AE2774282E44412A87377258C8D211F@OTSRV008> <63FB52BD9AE2774282E44412A87377258C8D2131@OTSRV008> Message-ID: <530DE2BF.9060302@ripe.net> Hi, On 2014/02/26 12:28 , Guillaume Sachot wrote: > I also thought of that, but I cannot adapt a datacenter network only for one probe :) An easy way out for both sides would be for you to host two probes, one of each VLAN. At the moment probes are not set up for multiple interfaces, and we have no clear idea what it would require to make that work. (And even if we did, it would probably take a while before it is released) Philip From rm at romanrm.net Wed Feb 26 14:23:59 2014 From: rm at romanrm.net (Roman Mamedov) Date: Wed, 26 Feb 2014 19:23:59 +0600 Subject: [atlas] Network configuration / Multiple VLANs In-Reply-To: <63FB52BD9AE2774282E44412A87377258C8D2131@OTSRV008> References: <63FB52BD9AE2774282E44412A87377258C8D211F@OTSRV008> <63FB52BD9AE2774282E44412A87377258C8D2131@OTSRV008> Message-ID: <20140226192359.2b37aacf@natsu> On Wed, 26 Feb 2014 12:28:14 +0100 Guillaume Sachot wrote: > I also thought of that, but I cannot adapt a datacenter network only for one probe :) You don't have a "guest" VLAN for "here any visitor can plug in their laptop, and have internet-only (no internal services whatsoever) IPv4+IPv6 access"? Just place the probe into that same VLAN, it can't be trusted as it communicates with an external server and unconditionally accepts firmware upgrades from it anyway. Also having IPv4 and IPv6 in separate VLANs seems like a sign that whoever did the v6 deployment had little idea of wtf they are even doing. I wonder if many people have such a wretched configuration that it would warrant adding the whole VLAN option to the interface. -- With respect, Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From gsachot at oceanet-technology.com Wed Feb 26 14:54:04 2014 From: gsachot at oceanet-technology.com (Guillaume Sachot) Date: Wed, 26 Feb 2014 14:54:04 +0100 Subject: [atlas] Network configuration / Multiple VLANs In-Reply-To: <20140226192359.2b37aacf@natsu> References: <63FB52BD9AE2774282E44412A87377258C8D211F@OTSRV008> <63FB52BD9AE2774282E44412A87377258C8D2131@OTSRV008> <20140226192359.2b37aacf@natsu> Message-ID: <63FB52BD9AE2774282E44412A87377258C8D2171@OTSRV008> > You don't have a "guest" VLAN for "here any visitor can plug in their laptop, and have internet-only (no internal services whatsoever) IPv4+IPv6 access"? The guest network is WiFi based. > Also having IPv4 and IPv6 in separate VLANs seems like a sign that whoever did the v6 deployment had little idea of wtf they are even doing. I wonder > if many people have such a wretched configuration that it would warrant adding the whole VLAN option to the interface. That's a bit presumptuous. Maybe the IPv6 VLAN is dedicated to this kind of external probes, and that we don't want to waste IPv4 by creating a dedicated one for the IPv4 counterpart when it can be put on an existing public range. -----Message d'origine----- De?: Roman Mamedov [mailto:rm at romanrm.net] Envoy??: mercredi 26 f?vrier 2014 14:24 ??: Guillaume Sachot Cc?: ripe-atlas at ripe.net Objet?: Re: [atlas] Network configuration / Multiple VLANs On Wed, 26 Feb 2014 12:28:14 +0100 Guillaume Sachot wrote: > I also thought of that, but I cannot adapt a datacenter network only > for one probe :) You don't have a "guest" VLAN for "here any visitor can plug in their laptop, and have internet-only (no internal services whatsoever) IPv4+IPv6 access"? Just place the probe into that same VLAN, it can't be trusted as it communicates with an external server and unconditionally accepts firmware upgrades from it anyway. Also having IPv4 and IPv6 in separate VLANs seems like a sign that whoever did the v6 deployment had little idea of wtf they are even doing. I wonder if many people have such a wretched configuration that it would warrant adding the whole VLAN option to the interface. -- With respect, Roman From alexsaroyan at gmail.com Wed Feb 26 15:04:50 2014 From: alexsaroyan at gmail.com (Alex Saroyan) Date: Wed, 26 Feb 2014 18:04:50 +0400 Subject: [atlas] Network configuration / Multiple VLANs In-Reply-To: <63FB52BD9AE2774282E44412A87377258C8D2171@OTSRV008> References: <63FB52BD9AE2774282E44412A87377258C8D211F@OTSRV008> <63FB52BD9AE2774282E44412A87377258C8D2131@OTSRV008> <20140226192359.2b37aacf@natsu> <63FB52BD9AE2774282E44412A87377258C8D2171@OTSRV008> Message-ID: <530DF482.5040908@gmail.com> Hi, You don't need to waste IPv4, just enable IPv6 in vlan where you already have IPv4 running. This is common deployment way - dual stack. And you don't waste IPv4 in this case. Regards. /Alex Saroyan On 02/26/2014 05:54 PM, Guillaume Sachot wrote: >> You don't have a "guest" VLAN for "here any visitor can plug in their laptop, and have internet-only (no internal services whatsoever) IPv4+IPv6 access"? > The guest network is WiFi based. > >> Also having IPv4 and IPv6 in separate VLANs seems like a sign that whoever did the v6 deployment had little idea of wtf they are even doing. I wonder >> if many people have such a wretched configuration that it would warrant adding the whole VLAN option to the interface. > That's a bit presumptuous. Maybe the IPv6 VLAN is dedicated to this kind of external probes, and that we don't want to waste IPv4 by creating a dedicated one for the IPv4 counterpart when it can be put on an existing public range. > > > > -----Message d'origine----- > De : Roman Mamedov [mailto:rm at romanrm.net] > Envoy? : mercredi 26 f?vrier 2014 14:24 > ? : Guillaume Sachot > Cc : ripe-atlas at ripe.net > Objet : Re: [atlas] Network configuration / Multiple VLANs > > On Wed, 26 Feb 2014 12:28:14 +0100 > Guillaume Sachot wrote: > >> I also thought of that, but I cannot adapt a datacenter network only >> for one probe :) > You don't have a "guest" VLAN for "here any visitor can plug in their laptop, and have internet-only (no internal services whatsoever) IPv4+IPv6 access"? > Just place the probe into that same VLAN, it can't be trusted as it communicates with an external server and unconditionally accepts firmware upgrades from it anyway. > > Also having IPv4 and IPv6 in separate VLANs seems like a sign that whoever did the v6 deployment had little idea of wtf they are even doing. I wonder if many people have such a wretched configuration that it would warrant adding the whole VLAN option to the interface. > > -- > With respect, > Roman > From gsachot at oceanet-technology.com Wed Feb 26 15:43:08 2014 From: gsachot at oceanet-technology.com (Guillaume Sachot) Date: Wed, 26 Feb 2014 15:43:08 +0100 Subject: [atlas] Network configuration / Multiple VLANs In-Reply-To: <530DF482.5040908@gmail.com> References: <63FB52BD9AE2774282E44412A87377258C8D211F@OTSRV008> <63FB52BD9AE2774282E44412A87377258C8D2131@OTSRV008> <20140226192359.2b37aacf@natsu> <63FB52BD9AE2774282E44412A87377258C8D2171@OTSRV008> <530DF482.5040908@gmail.com> Message-ID: <63FB52BD9AE2774282E44412A87377258C8D21B5@OTSRV008> Hi, That's was not much a debate on doing dual stack on the same VLAN (we already do that), but to be able to put the IPv6 interface on a dedicated subnet for this kind of purpose, when you won't do that in your IPv4 network. I prefer to think where would be the right place for a thing in an IPv6 network rather than planning a network only on the IPv4 constraints. We can all do our IPv6 subnetting based on what we have done in IPv4, but that would mostly be a bad idea. Regards. -----Message d'origine----- De?: ripe-atlas-bounces at ripe.net [mailto:ripe-atlas-bounces at ripe.net] De la part de Alex Saroyan Envoy??: mercredi 26 f?vrier 2014 15:05 ??: ripe-atlas at ripe.net Objet?: Re: [atlas] Network configuration / Multiple VLANs Hi, You don't need to waste IPv4, just enable IPv6 in vlan where you already have IPv4 running. This is common deployment way - dual stack. And you don't waste IPv4 in this case. Regards. /Alex Saroyan On 02/26/2014 05:54 PM, Guillaume Sachot wrote: >> You don't have a "guest" VLAN for "here any visitor can plug in their laptop, and have internet-only (no internal services whatsoever) IPv4+IPv6 access"? > The guest network is WiFi based. > >> Also having IPv4 and IPv6 in separate VLANs seems like a sign that >> whoever did the v6 deployment had little idea of wtf they are even doing. I wonder if many people have such a wretched configuration that it would warrant adding the whole VLAN option to the interface. > That's a bit presumptuous. Maybe the IPv6 VLAN is dedicated to this kind of external probes, and that we don't want to waste IPv4 by creating a dedicated one for the IPv4 counterpart when it can be put on an existing public range. > > > > -----Message d'origine----- > De : Roman Mamedov [mailto:rm at romanrm.net] Envoy? : mercredi 26 > f?vrier 2014 14:24 ? : Guillaume Sachot Cc : ripe-atlas at ripe.net Objet > : Re: [atlas] Network configuration / Multiple VLANs > > On Wed, 26 Feb 2014 12:28:14 +0100 > Guillaume Sachot wrote: > >> I also thought of that, but I cannot adapt a datacenter network only >> for one probe :) > You don't have a "guest" VLAN for "here any visitor can plug in their laptop, and have internet-only (no internal services whatsoever) IPv4+IPv6 access"? > Just place the probe into that same VLAN, it can't be trusted as it communicates with an external server and unconditionally accepts firmware upgrades from it anyway. > > Also having IPv4 and IPv6 in separate VLANs seems like a sign that whoever did the v6 deployment had little idea of wtf they are even doing. I wonder if many people have such a wretched configuration that it would warrant adding the whole VLAN option to the interface. > > -- > With respect, > Roman > From dario.ciccarone at gmail.com Wed Feb 26 16:53:39 2014 From: dario.ciccarone at gmail.com (Dario Ciccarone) Date: Wed, 26 Feb 2014 10:53:39 -0500 Subject: [atlas] Network configuration / Multiple VLANs In-Reply-To: <63FB52BD9AE2774282E44412A87377258C8D21B5@OTSRV008> References: <63FB52BD9AE2774282E44412A87377258C8D211F@OTSRV008> <63FB52BD9AE2774282E44412A87377258C8D2131@OTSRV008> <20140226192359.2b37aacf@natsu> <63FB52BD9AE2774282E44412A87377258C8D2171@OTSRV008> <530DF482.5040908@gmail.com> <63FB52BD9AE2774282E44412A87377258C8D21B5@OTSRV008> Message-ID: FWIW, my probe is sitting on its own "RIPE-ATLAS" VLAN . . . I have a lot of respect for the RIPE team - but dropping a device from a 3rd party, that you *know for a fact* it will get requests for tests from who-knows-where . . . A bit of a bad idea. Trust, but verify applies here - segment the probe into its own segment. Maybe an IPv6-only one . . . On 2/26/14 9:43 AM, "Guillaume Sachot" wrote: >Hi, > >That's was not much a debate on doing dual stack on the same VLAN (we >already do that), but to be able to put the IPv6 interface on a dedicated >subnet for this kind of purpose, when you won't do that in your IPv4 >network. > >I prefer to think where would be the right place for a thing in an IPv6 >network rather than planning a network only on the IPv4 constraints. We >can all do our IPv6 subnetting based on what we have done in IPv4, but >that would mostly be a bad idea. > >Regards. > > >-----Message d'origine----- >De : ripe-atlas-bounces at ripe.net [mailto:ripe-atlas-bounces at ripe.net] De >la part de Alex Saroyan >Envoy? : mercredi 26 f?vrier 2014 15:05 >? : ripe-atlas at ripe.net >Objet : Re: [atlas] Network configuration / Multiple VLANs > >Hi, > >You don't need to waste IPv4, just enable IPv6 in vlan where you already >have IPv4 running. >This is common deployment way - dual stack. And you don't waste IPv4 in >this case. > >Regards. >/Alex Saroyan > >On 02/26/2014 05:54 PM, Guillaume Sachot wrote: >>> You don't have a "guest" VLAN for "here any visitor can plug in their >>>laptop, and have internet-only (no internal services whatsoever) >>>IPv4+IPv6 access"? >> The guest network is WiFi based. >> >>> Also having IPv4 and IPv6 in separate VLANs seems like a sign that >>> whoever did the v6 deployment had little idea of wtf they are even >>>doing. I wonder if many people have such a wretched configuration that >>>it would warrant adding the whole VLAN option to the interface. >> That's a bit presumptuous. Maybe the IPv6 VLAN is dedicated to this >>kind of external probes, and that we don't want to waste IPv4 by >>creating a dedicated one for the IPv4 counterpart when it can be put on >>an existing public range. >> >> >> >> -----Message d'origine----- >> De : Roman Mamedov [mailto:rm at romanrm.net] Envoy? : mercredi 26 >> f?vrier 2014 14:24 ? : Guillaume Sachot Cc : ripe-atlas at ripe.net Objet >> : Re: [atlas] Network configuration / Multiple VLANs >> >> On Wed, 26 Feb 2014 12:28:14 +0100 >> Guillaume Sachot wrote: >> >>> I also thought of that, but I cannot adapt a datacenter network only >>> for one probe :) >> You don't have a "guest" VLAN for "here any visitor can plug in their >>laptop, and have internet-only (no internal services whatsoever) >>IPv4+IPv6 access"? >> Just place the probe into that same VLAN, it can't be trusted as it >>communicates with an external server and unconditionally accepts >>firmware upgrades from it anyway. >> >> Also having IPv4 and IPv6 in separate VLANs seems like a sign that >>whoever did the v6 deployment had little idea of wtf they are even >>doing. I wonder if many people have such a wretched configuration that >>it would warrant adding the whole VLAN option to the interface. >> >> -- >> With respect, >> Roman >> > > > From rm at romanrm.net Wed Feb 26 16:57:58 2014 From: rm at romanrm.net (Roman Mamedov) Date: Wed, 26 Feb 2014 21:57:58 +0600 Subject: [atlas] Network configuration / Multiple VLANs In-Reply-To: References: <63FB52BD9AE2774282E44412A87377258C8D211F@OTSRV008> <63FB52BD9AE2774282E44412A87377258C8D2131@OTSRV008> <20140226192359.2b37aacf@natsu> <63FB52BD9AE2774282E44412A87377258C8D2171@OTSRV008> <530DF482.5040908@gmail.com> <63FB52BD9AE2774282E44412A87377258C8D21B5@OTSRV008> Message-ID: <20140226215758.64e35ca5@natsu> On Wed, 26 Feb 2014 10:53:39 -0500 Dario Ciccarone wrote: > FWIW, my probe is sitting on its own "RIPE-ATLAS" VLAN . . . > > I have a lot of respect for the RIPE team - but dropping a device from a > 3rd party, that you *know for a fact* it will get requests for tests from > who-knows-where . . . A bit of a bad idea. > > Trust, but verify applies here - segment the probe into its own segment. > Maybe an IPv6-only one . . . AFAIK the probe currently does not support being on an IPv6-only network. Besides, why voluntarily make it half as useful to the world as it can be. You got the probe, got IPv4, might as well let the probe measure on IPv4... -- With respect, Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From dario.ciccarone at gmail.com Wed Feb 26 17:20:22 2014 From: dario.ciccarone at gmail.com (Dario Ciccarone) Date: Wed, 26 Feb 2014 11:20:22 -0500 Subject: [atlas] Network configuration / Multiple VLANs In-Reply-To: <20140226215758.64e35ca5@natsu> References: <63FB52BD9AE2774282E44412A87377258C8D211F@OTSRV008> <63FB52BD9AE2774282E44412A87377258C8D2131@OTSRV008> <20140226192359.2b37aacf@natsu> <63FB52BD9AE2774282E44412A87377258C8D2171@OTSRV008> <530DF482.5040908@gmail.com> <63FB52BD9AE2774282E44412A87377258C8D21B5@OTSRV008> <20140226215758.64e35ca5@natsu> Message-ID: Then it could be a /30 network, right ? Or even a /31, if both probe and L3 device support RFC-3021 . . . In any case - my suggestion was NOT to deploy the probe on a network segment where, if compromised, could compromise the rest of the network - specially if you're dropping it on a network management / infrastructure segment. On 2/26/14 10:57 AM, "Roman Mamedov" wrote: >On Wed, 26 Feb 2014 10:53:39 -0500 >Dario Ciccarone wrote: > >> FWIW, my probe is sitting on its own "RIPE-ATLAS" VLAN . . . >> >> I have a lot of respect for the RIPE team - but dropping a device from a >> 3rd party, that you *know for a fact* it will get requests for tests >>from >> who-knows-where . . . A bit of a bad idea. >> >> Trust, but verify applies here - segment the probe into its own segment. >> Maybe an IPv6-only one . . . > >AFAIK the probe currently does not support being on an IPv6-only network. >Besides, why voluntarily make it half as useful to the world as it can be. >You got the probe, got IPv4, might as well let the probe measure on >IPv4... > >-- >With respect, >Roman From rm at romanrm.net Wed Feb 26 17:32:07 2014 From: rm at romanrm.net (Roman Mamedov) Date: Wed, 26 Feb 2014 22:32:07 +0600 Subject: [atlas] Network configuration / Multiple VLANs In-Reply-To: References: <63FB52BD9AE2774282E44412A87377258C8D211F@OTSRV008> <63FB52BD9AE2774282E44412A87377258C8D2131@OTSRV008> <20140226192359.2b37aacf@natsu> <63FB52BD9AE2774282E44412A87377258C8D2171@OTSRV008> <530DF482.5040908@gmail.com> <63FB52BD9AE2774282E44412A87377258C8D21B5@OTSRV008> <20140226215758.64e35ca5@natsu> Message-ID: <20140226223207.2c6a6160@natsu> On Wed, 26 Feb 2014 11:20:22 -0500 Dario Ciccarone wrote: > Then it could be a /30 network, right ? Or even a /31, if both probe and > L3 device support RFC-3021 . . . It could, and perhaps should, be an RFC1918 /24, NATed upstream by your router into whatever publicly routable IPs your site happens to have. Of course no one suggests or requires to waste any "real" IPv4 addresses just on the probe. -- With respect, Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From dario.ciccarone at gmail.com Wed Feb 26 17:40:03 2014 From: dario.ciccarone at gmail.com (Dario Ciccarone) Date: Wed, 26 Feb 2014 11:40:03 -0500 Subject: [atlas] Network configuration / Multiple VLANs In-Reply-To: <20140226223207.2c6a6160@natsu> References: <63FB52BD9AE2774282E44412A87377258C8D211F@OTSRV008> <63FB52BD9AE2774282E44412A87377258C8D2131@OTSRV008> <20140226192359.2b37aacf@natsu> <63FB52BD9AE2774282E44412A87377258C8D2171@OTSRV008> <530DF482.5040908@gmail.com> <63FB52BD9AE2774282E44412A87377258C8D21B5@OTSRV008> <20140226215758.64e35ca5@natsu> <20140226223207.2c6a6160@natsu> Message-ID: Well, THAT is my scenario here - NAT for IPv4, and global unicast for IPv6 But in case you don't want to do NAT/can't . . . On 2/26/14 11:32 AM, "Roman Mamedov" wrote: >On Wed, 26 Feb 2014 11:20:22 -0500 >Dario Ciccarone wrote: > >> Then it could be a /30 network, right ? Or even a /31, if both probe and >> L3 device support RFC-3021 . . . > >It could, and perhaps should, be an RFC1918 /24, NATed upstream by your >router >into whatever publicly routable IPs your site happens to have. Of course >no >one suggests or requires to waste any "real" IPv4 addresses just on the >probe. > >-- >With respect, >Roman From philip.homburg at ripe.net Thu Feb 27 01:38:45 2014 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 27 Feb 2014 01:38:45 +0100 Subject: [atlas] Network configuration / Multiple VLANs In-Reply-To: <20140226215758.64e35ca5@natsu> References: <63FB52BD9AE2774282E44412A87377258C8D211F@OTSRV008> <63FB52BD9AE2774282E44412A87377258C8D2131@OTSRV008> <20140226192359.2b37aacf@natsu> <63FB52BD9AE2774282E44412A87377258C8D2171@OTSRV008> <530DF482.5040908@gmail.com> <63FB52BD9AE2774282E44412A87377258C8D21B5@OTSRV008> <20140226215758.64e35ca5@natsu> Message-ID: <530E8915.5070409@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 2014/02/26 16:57 , Roman Mamedov wrote: > AFAIK the probe currently does not support being on an IPv6-only > network. Besides, why voluntarily make it half as useful to the > world as it can be. You got the probe, got IPv4, might as well let > the probe measure on IPv4... IPv6-only operation is supported. You only need to configure the DNS resolvers statically because they are not picked automatically. Philip -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMOiRUACgkQ23LKRM64egLFWwCeLkPRlW3ZvgSmytQc0AQKApwa EpkAoJREeAK6rItj5UgV+k5qkERZ+3Fc =GVT3 -----END PGP SIGNATURE----- From daniel.karrenberg at ripe.net Thu Feb 27 10:04:22 2014 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 27 Feb 2014 10:04:22 +0100 Subject: [atlas] Some Atlas Anchor Graphs Message-ID: <13DC1DA7-72C9-4F10-8DF5-1FE76811A3DF@ripe.net> During some research I happened to visualise some random anchor calibration measurements and thought I'd share the graphs. The basis are IPv4 traceroutes from all (4500+) RIPE Atlas probes to the anchor encoded in the file name. The graphs show adjacencies that appear in more than 3% of all paths. IP addresses are aggregated by the network name as registered in the RIR registries. The darker an edge appears, tho more paths contain this adjacency; the colouring is scaled logarithmically. Enjoy Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: no-osl-as39029.png Type: image/png Size: 27564 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: nl-ams-as3333-2.png Type: image/png Size: 202914 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ch-zrh-as34288.png Type: image/png Size: 180802 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: au-mel-as38796.png Type: image/png Size: 134827 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ch-zrh-as559.png Type: image/png Size: 102333 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mir at ripe.net Fri Feb 28 10:06:39 2014 From: mir at ripe.net (Mirjam Kuehne) Date: Fri, 28 Feb 2014 10:06:39 +0100 Subject: [atlas] New on RIPE Labs: Improved RIPE Atlas Probe Pages In-Reply-To: <53105176.4070904@ripe.net> References: <53105176.4070904@ripe.net> Message-ID: <5310519F.30001@ripe.net> Dear colleagues, We've made it easier to get an overview of the history and measurements for all the public probes in the RIPE Atlas network. Read about that and other new functionality on RIPE Labs: https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-improved-probe-pages Kind regards, Mirjam Kuehne RIPE NCC From el at lisse.NA Fri Feb 28 10:20:51 2014 From: el at lisse.NA (Dr Eberhard Lisse) Date: Fri, 28 Feb 2014 11:20:51 +0200 Subject: [atlas] New on RIPE Labs: Improved RIPE Atlas Probe Pages In-Reply-To: <5310519F.30001@ripe.net> References: <53105176.4070904@ripe.net> <5310519F.30001@ripe.net> Message-ID: <531054F3.7040008@lisse.NA> Hi, I have a probe sitting on my DSL here in Windhoek and it just runs the standard measurements (as far as I am aware). I am an elderly Gynaecologist dabbling in Perl a little, but can for the life of me not figure out how to analyze any of this. The very first thing I'd like to do is getting more or less every of these standard measurements on a regular basis into a PostgreSQL database. Doesn't have to be real time, a nightly cron job would do nicely. I am reasonably sure that someone has done this already and I also think this might be of interest to others, hence I would appreciate if they contact through the list (or directly, in which I would summarize to the list eventually :-)-O) If someone has done this in another programming language that I have on OS X or I can install via Fink and is willing to share the code, I'd also appreciate it. greetings, el -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist (Saar) el at lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 \ / Bachbrecht, Namibia ;____/