Mirjam Kühne
Based in Amsterdam, The Netherlands
112
Articles
197
Likes on articles
Based in Amsterdam, The Netherlands
I wrote the articles collected here during my time as community builder of the RIPE NCC and the maintainer and editor of RIPE Labs. I have since taken on a new role serving as the Chair of the RIPE Community. You can reach my new profile via the website link below.
Introducing the RIPE NCC Roadmap
• 3 min read
We often get asked about the status of our different services and projects, and while we frequently publish updates on RIPE Labs, we now have a new tool that makes it easier to stay informed. We're happy to announce the RIPE NCC Roadmap, where you can get an overview of all the latest developments …
Mediterranean Cable Disruption as Seen in RIPEstat
• 2 min read
What RIPEstat tells us about the recent cable disruption in the Mediterranean.
SI6 IPv6 Toolkit v1.3.1 Released
• 3 min read
This IPv6 Toolkit allows you to perform security assessments and trouble-shooting of your IPv6 network. A new version has been released recently.
An Update on De-bogonising 128.0.0.0/16
• 4 min read
We continued RIPE Atlas measurements to see if we can still find cases where 128.0.0.0/16 is filtered out.
Mozilla Uses RPKI
• 3 min read
A few weeks ago, Mozilla started to use RPKI (Resource Public Key Infrastructure) and ROAs (Route Origin Authorization). Here is a quick introduction.
RIPE NCC Training Report 2012
• 5 min read
This article gives an overview of our training activities in 2012 and an outlook on our plans for 2013.
Survey on Network Attack Detection and Mitigation
• 2 min read
The Biometrics and Internet Security Research Group at the University Darmstadt is conducting a survey on network attack detection and mitigation in order to gain a deeper insight in processes, procedures and settings typically found in ISP networks.
IPv6 Darknet Experiment
• 2 min read
Similar to an experiment done for IPv4 address space, Merit is now performing a darknet experiment with the IPv6 ranges that have been allocated to the RIRs. This also includes prefixes allocated to the RIPE NCC.
Number of New LIRs and their IPv6 RIPEness
• 3 min read
We observed an increase in the number of new LIRs in the RIPE NCC service region. Many of these new LIRs show 1-star IPv6 RIPEness.
“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 yxm1348@163.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 atlas@ripe.net 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 labs@ripe.net.
“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)