LIR Locator Tool
The RIPE NCC is working on an Local Internet Registry (LIR) Locator tool that provides the public with geographical information about LIRs and the services they offer in the RIPE NCC service region: Europe, the Middle East and parts of Central Asia.
“dear :how to use bgp rpki server?”
Sylow, can you please clarify your question. Is it related to the article above?
“Thanks for the post! Solution 1 solved the problem of my probe.”
Thanks for letting us know, Stefan. I am glad to hear your probe works again.
“How to do this ?”
Hi Lisa, can you please clarify your question. What exactly are you trying to do? Thank you.
“hello, I have found that there is a problem with class of CombinePcapInputFormat about the version on github,maybe the constructor function is wrong.The version 1.1 is right. Now I need to change some code to fit my application.So that I need the right source code.Could you help me? would you put the version 1.1 on github ?Or would you email me the source code of version 1.1?My email adress is email@example.com. Thanks a lot. Yimi”
Dear Yimi, the author informs me that the version 1.1 is here in source: https://github.com/RIPE-NCC/hadoop-pcap/releases/tag/1.1 and as binary in the repository as described here: https://github.com/RIPE-NCC/hadoop-pcap I hope this helps.
“I'm interested in addressing the issues that have come up on my V1 probe, but it's unclear how to go about doing so.”
Hi Owen, Can you please send this as a ticket to firstname.lastname@example.org so we can respond in more detail. Please also mention the 12 characters printed under the MAC address of the probe. Thank you.
“Let me suggest one other hypothesis based on experience. There appear to be two types of USB storage failures, ones that can be overcome by the unplug, remove USB stick, plug in, reinsert USB stick procedure and ones in which the USB stick itself get trashed so that it can no longer be formatted, etc. The former issue is just an annoyance, but the annoyance is cumulative: if the probe disconnects once, whomever is hosting it is likely to go to the trouble to get it back up. After several times, the motivation to bring it back up and do it quickly may diminish. The latter issue is more serious, at least for those of us who do not keep an inventory of USB sticks in the appropriate size on hand, because the process is to spend a fair amount of time determining that resetting / reloading the USB stick won't work, finding time to go to the store or order a USB stick and wait for it to arrive, and then set the probe up again. Once sure, twice maybe, but, after running through three or four USB sticks, I'd guess that the odds of a probe being reconnected go down rapidly. Suggestion: provide a way for people to record when they have applied the "corrupt file system" fix, when they have replaced a USB stick, and what size and brand they have replaced it with. Wrt the latter, the data in the article probably don't show what USB stick is in a connected probe, only what kind of stick you shipped it with.”
Hi John, Thanks for constructive thoughts and your suggestion. We keep track of failure rates for various versions of RIPE Atlas probes to a certain extend. You can see some of this anlysis in this earlier article on RIPE Labs: https://labs.ripe.net/Members/philip_homburg/further-analysis-of-ripe-atlas-version-3-probe. Ultimately the best solution might be to look at completely different hardware. This is on our roadmap but will take some time to investigate.
“Hello. I need to contact admin. Thank you.”
Please contact email@example.com.
“I had also this issue: with normal reboot didn't get a IP. without USB the probe gets again a IP but plugin the USB didn't solve the issue. The probe was still "not connected". the info in SoS were coming quickly. I had to reboot later several times with the USB. Now is OK. I hope for a long time .....”
Hi Jean-Michel, thanks for letting us know. We're working on a more long-term solution. Please also see this RIPE Labs article in that context: https://labs.ripe.net/Members/kistel/ripe-atlas-countering-hardware-issues-with-better-firmware
“Great (and a good answer to the people who would like the packets to stay inside human borders) but small typo: the IETF working group on DNS privacy is DPRIVE, not DPRIV.”
Oops. Fixed. Thanks, Stéphane.
“The link to the SURFnet website is broken :(”
Hi Sander, Thanks for pointing this out. I found it and updated the link. Mirjam
Showing 44 comment(s)