- ripe-atlas - mailman.ripe.net

Re: [atlas] Please set your NIC handle for your RIPE Atlas anchor
by Paul Vlaar 17 Mar '15

17 Mar '15

Dear RIPE Atlas staff, I'm a little confused. I need to add a NIC handle, you say. "What is a NIC handle? A NIC handle is the unique identifier of a person. It is basically the person's unique ID and it helps to keep different people with the same name apart from each other. Whenever a person object is referenced in another object, they are referenced by their NIC handle ("nic-hdl:") and not by their name. See an example person object" How can a handle meant for a person be used for a machine? Is this correct? Thanks, Paul Vlaar Afilias On 11/3/15 12:59 PM, RIPE Atlas (no reply) wrote: > Dear Paul Vlaar, > > We noticed that you haven't added the NIC handle for your RIPE Atlas > anchor yet. Could you please add it as soon as possible? > > NIC handles are objects in the RIPE Database that contain contact > information. Having this information available for all anchors will > make it easier for other anchor hosts or members of the community to > communicate with one another by finding the appropriate technical or > administrative contacts. > > If you don't already have a NIC handle, you can learn more about what > it is and how to create one in the RIPE Database here: > http://www.ripe.net/lir-services/new-lir/first-steps-as-a-ripe-ncc-member#c… > > > Once you have a NIC handle, you can enter it on the RIPE Atlas > website under “My Atlas” > “Anchors” > "View". > > For any questions or issues with the creation of your NIC handle, > please contact ripe-dbm(a)ripe.net. > > Kind regards, > > Michela Galante RIPE Atlas Team RIPE NCC atlas(a)ripe.net > -- Paul Vlaar DNS Infrastructure Group Afilias e-mail: pvlaar(a)afilias.info phone: +1-416-673-4078

2 2

Re: [atlas] Probe #1047
by Ben Vaux 16 Mar '15

16 Mar '15

I had my Probe drop out a few times, I replaced the Apple USB Power Supply with a new one and it seem better now. Best regards, Ben Vaux From: Ben Choy <ben.choy(a)hkirc.hk> Date: Friday, 13 March 2015 06:16 To: "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> Subject: [atlas] Probe #1047 Dear RIPE, Our probe #1047 has been playing up lately eg. keep dropping out after a few hours even after power cycle. Any chance of getting a replacement if we sent it back. BTW, it is one of the “Old” v1. Cheers. Benjamin ChoyProject Manager (System & Network)Hong Kong Internet Registration Corporation Limited (HKIRC) http://www.hkirc.hk <http://www.hkirc.hk/> http://互聯網註冊.香港 <http://互聯網註冊.香港/> Hong Kong Domain Name Registration Company Limited (HKDNR) http://www.hkdnr.hk <http://www.hkdnr.hk/> http://域名註冊.香港 <http://域名註.香港/> Tel: +852 2319 1313 / Fax: +852 2319 2626 / Direct: +852 2319 3819 / Email: ben.choy(a)hkirc.hk <http://www.hkirc.hk/> The information in this email is confidential and may be legally privileged. If you are not the intended recipient, please notify the sender immediately and then delete this e-mail entirely. You must not retain, copy, distribute or use this e-mail for any other purpose not intended by this email or disclose any of its content to others. The recipient should check the email and attachment for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.PROTECT OUR ENVIRONMENT - think before printing!

1 0

Probe #1047
by Ben Choy 13 Mar '15

13 Mar '15

Dear RIPE, Our probe #1047 has been playing up lately eg. keep dropping out after a few hours even after power cycle. Any chance of getting a replacement if we sent it back. BTW, it is one of the “Old” v1. Cheers. [hkirc] Benjamin Choy Project Manager (System & Network) Hong Kong Internet Registration Corporation Limited (HKIRC) http://www.hkirc.hk<http://www.hkirc.hk/> http://互聯網註冊.香港<http://互聯網註冊.香港/> Hong Kong Domain Name Registration Company Limited (HKDNR) http://www.hkdnr.hk<http://www.hkdnr.hk/> http://域名註冊.香港<http://域名註.香港/> Tel: +852 2319 1313 / Fax: +852 2319 2626 / Direct: +852 2319 3819 / Email: ben.choy(a)hkirc.hk [cid:image002.png@01CEAE2D.C3DA7B80]<http://www.hkirc.hk/> The information in this email is confidential and may be legally privileged. If you are not the intended recipient, please notify the sender immediately and then delete this e-mail entirely. You must not retain, copy, distribute or use this e-mail for any other purpose not intended by this email or disclose any of its content to others. The recipient should check the email and attachment for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. PROTECT OUR ENVIRONMENT - think before printing!

1 0

Internet Exchange Nepal (NPIX) has joined RIPE Atlas anchors
by Michela Galante 10 Mar '15

10 Mar '15

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 np-ktm-as45170 and it is hosted by the Internet Exchange Nepal (NPIX) in Kathmandu, Nepal, and sponsored by APNIC. 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, RIPE Atlas Team atlas(a)ripe.net

1 0

Mistakenly sent "please register your probe" emails
by Robert Kisteleki 05 Mar '15

05 Mar '15

Dear RIPE Atlas users, As part of our regular development schedule, the development team rolled out a new version of the infrastructure components yesterday. As a side-effect, due to a mistake on our end, some users received emails urging them to register their probe(s), even though this has already been done. If you got such a mail although you've done your part, then please ignore this mail. Our apologies for the confusion. Regards, Robert Kisteleki

1 0

University of Twente (Enschede, The Netherlands) has joined RIPE Atlas Anchors
by Alastair Strachan 27 Feb '15

27 Feb '15

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-ens-as1133 and it is hosted by University of Twente in Enschede, The 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/ <https://atlas.ripe.net/anchors/list/> Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ <https://atlas.ripe.net/about/anchors/> Thank you for participating in RIPE Atlas! Kind Regards, RIPE Atlas Team

1 0

some probes not returning NSID
by Paul Vlaar 26 Feb '15

26 Feb '15

Hi all, it appears that some probes never return NSID, when requested, while others do, for the same query. For example: https://atlas.ripe.net/measurements/1875836/#!general As you can see NSID is set to True. These are the raw results from the two probes, for a one-off DNS UDM: results = { u'6012': [{u'lts': 230, u'proto': u'UDP', u'from': u'193.0.19.108', u'msm_id': 1875836, u'af': 4, u'timestamp': 1424384037, u'fw': 4670, u'msm_name': u'Tdig', u'prb_id': 6012, u'result': {u'abuf': u'OQGEAAABAAEAAAABA29yZwAABgABwAwABgABAAADhAAzAmEwA29yZwthZmlsaWFzLW5zdARpbmZvAANub2PAKHfjQ2sAAAcIAAADhAAJOoAAAVGAAAApEAAAAAAAACUAAwAhbnMwMDBiLmFwcDcubnJ0MS5hZmlsaWFzLW5zdC5pbmZv', u'rt': 312.971, u'NSCOUNT': 0, u'QDCOUNT': 1, u'answers': [{u'RNAME': u'noc.afilias-nst.info.', u'NAME': u'org.', u'MNAME': u'a0.org.afilias-nst.info.', u'TTL': 900, u'SERIAL': 2011382635, u'TYPE': u'SOA'}], u'ID': 14593, u'ARCOUNT': 1, u'ANCOUNT': 1, u'size': 132}, u'src_addr': u'193.0.19.108', u'group_id': 1875836, u'type': u'dns', u'dst_addr': u'199.19.56.1'}], u'10039': [{u'lts': 166, u'proto': u'UDP', u'from': u'96.237.232.254', u'msm_id': 1875836, u'af': 4, u'timestamp': 1424384040, u'fw': 4670, u'msm_name': u'Tdig', u'prb_id': 10039, u'result': {u'abuf': u'qxGAgAABAAEAAAABA29yZwAABgABwAwABgABAAAB3QAzAmEwA29yZwthZmlsaWFzLW5zdARpbmZvAANub2PAKHfjQ2UAAAcIAAADhAAJOoAAAVGAAAApD6AAAAAAAAA=', u'rt': 8.299, u'NSCOUNT': 0, u'QDCOUNT': 1, u'answers': [{u'RNAME': u'noc.afilias-nst.info.', u'NAME': u'org.', u'MNAME': u'a0.org.afilias-nst.info.', u'TTL': 477, u'SERIAL': 2011382629, u'TYPE': u'SOA'}], u'ID': 43793, u'ARCOUNT': 1, u'ANCOUNT': 1, u'size': 95}, u'src_addr': u'192.168.13.40', u'group_id': 1875836, u'type': u'dns', u'dst_addr': u'199.19.56.1'}] } Sagan tells me, for probe 6012, responses[0].abuf.raw_data is: {'HEADER': {'AA': True, 'QR': True, 'AD': False, 'NSCOUNT': 0, 'QDCOUNT': 1, 'ANCOUNT': 1, 'TC': False, 'RD': False, 'ARCOUNT': 1, 'CD': False, 'ReturnCode': 'NOERROR', 'OpCode': 'QUERY', 'RA': False, 'Z': 0, 'ID': 14593}, 'AnswerSection': [{'Retry': 900, 'Name': u'org.', 'NegativeTtl': 86400, 'Refresh': 1800, 'MasterServerName': u'a0.org.afilias-nst.info.', 'Expire': 604800, 'MaintainerName': u'noc.afilias-nst.info.', 'TTL': 900, 'Serial': 2011382635, 'Type': 'SOA', 'Class': 'IN', 'RDlength': 51}], 'QuestionSection': [{'Qclass': 'IN', 'Qtype': 'SOA', 'Qname': u'org.'}], 'EDNS0': {'ExtendedReturnCode': 0, 'Option': [{'OptionCode': 3, 'OptionName': 'NSID', 'NSID': u'ns000b.app7.nrt1.afilias-nst.info', 'OptionLength': 33}], 'UDPsize': 4096, 'Version': 0, 'Z': 0, 'Type': 'OPT', 'Name': u'.'}} NSID is present. And for 10039: {'HEADER': {'AA': False, 'QR': True, 'AD': False, 'NSCOUNT': 0, 'QDCOUNT': 1, 'ANCOUNT': 1, 'TC': False, 'RD': False, 'ARCOUNT': 1, 'CD': False, 'ReturnCode': 'NOERROR', 'OpCode': 'QUERY', 'RA': True, 'Z': 0, 'ID': 43793}, 'AnswerSection': [{'Retry': 900, 'Name': u'org.', 'NegativeTtl': 86400, 'Refresh': 1800, 'MasterServerName': u'a0.org.afilias-nst.info.', 'Expire': 604800, 'MaintainerName': u'noc.afilias-nst.info.', 'TTL': 477, 'Serial': 2011382629, 'Type': 'SOA', 'Class': 'IN', 'RDlength': 51}], 'QuestionSection': [{'Qclass': 'IN', 'Qtype': 'SOA', 'Qname': u'org.'}], 'EDNS0': {'ExtendedReturnCode': 0, 'Option': [], 'UDPsize': 4000, 'Version': 0, 'Z': 0, 'Type': 'OPT', 'Name': u'.'}} NSID is missing. Why is this? I've tried increasing the payload size, this makes no difference. I get the same when I try for SOA . @ k.root-servers.net: Compare these outcomes: https://atlas.ripe.net/measurements/1875933/ https://atlas.ripe.net/measurements/1875926/ It appears to me that probe 10039 (or its network) has a problem of sorts, causing this. It would be great if faulty probes can be weeded out, if this is really the case. BTW, I am always getting "null" on the NSID field in the web interface, regardless of whether it lives in abuf, or not. This seems to be a bug. ~paul

9 15

[ietf-secretariat@ietf.org: New Non-WG Mailing List: hops -- Measuring deployability of new transport protocols]
by Stephane Bortzmeyer 26 Feb '15

26 Feb '15

It could be interesting to use Atlas probes for such measurements, no?

2 1

Re: [atlas] Fwd: Re: Proble locations (Changed because of Geo-IP)
by Chris Amin 25 Feb '15

25 Feb '15

Dear Martin, I'm sorry for this, we recently made a change which keeps the location of those probes which are geolocated (i.e. *without* a manually set address) up to date. Previously such probes were geolocated once, and never again. It was never the intention to overwrite manually given locations. Unfortunately, it seems that a number of probes were erroneously marked as being automatically geolocated when in fact their owners had carefully provided a location. We are now looking at our logs to see how many probes might have been affected by this, and whether we can automatically revert the location in those cases. As for your point about not being able to enter the location, there is a text box above the map popup which should allow you to enter a textual address. If this isn't working for you, please let me know. Apologies once again. Kind regards, Chris Amin RIPE NCC On Wed, 25 Feb 2015 01:10:30 -0800 (PST), Martin Winter wrote: > I have actually the address in it. > The earlier webpage had a way to enter Lat/Lon for probes (which I can't > find anymore). > > I think a simple Geo-Lokup based on addresses in description would have > done a much better job. > But a field to enter lat/lon in it and take this as a preference (if > entered) without going to overwrite it would be a good start. > > I mainly worry on whatever happend there in this process may have > misplaced a lot of probes to the wrong location. > Anyone else noticed that their probe moved to a new (wrong) location? > > - Martin > > > On Wed, 25 Feb 2015, Grewal, Jas wrote: > >> Agreed, how about including this critical information in the >> description field to get around this, perhaps? >> >> -----Original Message----- >> From: ripe-atlas [mailto:ripe-atlas-bounces@ripe.net] On Behalf Of >> Martin Winter >> Sent: 25 February 2015 07:29 >> To: ripe-atlas(a)ripe.net >> Subject: [atlas] Proble locations (Changed because of Geo-IP) >> >> So I've noticed that (at least some) probes got the location >> automatically updated based on Geo IP. >> However, this is frequently fundamentially broken. One of my probe >> moved from San Jose, CA to somewhere in the middle of Texas. (Broken >> Geo-IP location for AT&T DSL users). >> (The example I talk about is proble #10770) >> >> Kind of sad... not sure how many had this happening. Specially as I >> took care to put the exact lat/lon in the User interface in the past. >> Now I can only reposition it by dragging on a map - and that seems to >> be broken as well (at least it fails to save when I try to correct >> this probes location on Chrome) >> >> I wonder how many and why there was a decision to change the location. >> I think the location were much better before they got force-changed. >> >> - Martin Winter >> >> >> >> > > > > >

2 1

FastVPS Eesti OU (Jõhvi, Estonia) has joined RIPE Atlas Anchors
by Alastair Strachan 25 Feb '15

25 Feb '15

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 ee-jvi-as198068 and it is hosted by FastVPS Eesti OU in Jõhvi, Estonia. 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/ <https://atlas.ripe.net/anchors/list/> Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ <https://atlas.ripe.net/about/anchors/> Thank you for participating in RIPE Atlas! Kind Regards, RIPE Atlas Team

1 0