swapping a v1 for a v3
a sweet old v1 probe, 2285, in a hard to access (due to covid) place died 19 months ago. i want to swap in a v3, 25898, this weekend. i know i could create a new entry, but how do i delete the old; or better yet, move the data from old to new? stop laughing. :) randy
Randy, keep this v1 probe in a safe place. One day they will open Museum of Internet Measurements so the probe will be a perfect item for exposition. They should, right? Regards, Grzegorz From: Randy Bush <randy@psg.com> Date: Friday 2021-12-10 at 01:37 To: RIPE Atlas <ripe-atlas@ripe.net> Subject: [atlas] swapping a v1 for a v3 a sweet old v1 probe, 2285, in a hard to access (due to covid) place died 19 months ago. i want to swap in a v3, 25898, this weekend. i know i could create a new entry, but how do i delete the old; or better yet, move the data from old to new? stop laughing. :) randy
Randy, keep this v1 probe in a safe place. One day they will open Museum of Internet Measurements so the probe will be a perfect item for exposition.
sad to say, i only have two working v1s deployed. others have not survived. and some of the dead have yet to be accessible. we returned the first olives (and i think a martini) to juniper. so point taken. randy
The probe in my garage (literally) has been running since 2015. I haven’t spent much time thinking or working with it, so forgive this potentially dumb question. I looked it up on the atlas.ripe.net <http://atlas.ripe.net/> site. Besides the being a note about lacking a USB stick (wasn’t aware of that), I see that the host had a IPv6 address until July and since then a series of IPv4 addresses. I can’t recall a major network event around then (the probe was offline 18 1/2 hours. Is there a reason I don’t have a v6 address now? Should I have one (as in, is something wrong to make it fail back to v4)? I did have a network overhaul in September (off line for 15h 20m). I had to “fix” IPv6 in the house then but got it working with the new CPE device. Checking, when I go to ripe.net’s webpage, it shows me coming over IPv6. FWIW, my house is a simple cable-company-as-ISP home set up, consumer-grade v4 and v6. (I try to leave work at work, if you know what I mean.) …meanwhile, I’m going to see if there is a USB stick in the house. (Maybe it’s near the book of postage stamps, DVD’s, and cassette tapes.) Ed
On 10 Dec 2021, at 0:37, Randy Bush wrote:
a sweet old v1 probe, 2285, in a hard to access (due to covid) place died 19 months ago. i want to swap in a v3, 25898, this weekend. i know i could create a new entry, but how do i delete the old; or better yet, move the data from old to new? stop laughing. :)
I’m not laughing! 8-) I know that the kind of administrative trick you suggest is possible, at least for software probes. I discovered this when, during a Turris OS upgrade, I “lost” such a probe. The solution suggested by the Atlas team was simply to register the new instance with the ID number I had been using before. This worked. IIUC, each hardware probe is pre-registered. This may be an obstacle; I don’t know. /Niall
The solution suggested by the Atlas team was simply to register the new instance with the ID number I had been using before. This worked.
IIUC, each hardware probe is pre-registered. This may be an obstacle; I don’t know.
i suspect the probe or actually the back end would have an identity crisis. randy
On 2021-12-10 18:31, Randy Bush wrote:
The solution suggested by the Atlas team was simply to register the new instance with the ID number I had been using before. This worked.
IIUC, each hardware probe is pre-registered. This may be an obstacle; I don’t know.
i suspect the probe or actually the back end would have an identity crisis.
randy
Indeed! For hardware probes, where the probe's key is virtually unchangeable, we don't do such ID/key juggling. For software probes the host can update (re-register) the probe's key meaning the ID remains the same; this is intended to solve the problem Niall faced. Hope this helps, Robert
The solution suggested by the Atlas team was simply to register the new instance with the ID number I had been using before. This worked.
IIUC, each hardware probe is pre-registered. This may be an obstacle; I don’t know.
i suspect the probe or actually the back end would have an identity crisis.
Indeed! For hardware probes, where the probe's key is virtually unchangeable, we don't do such ID/key juggling. For software probes the host can update (re-register) the probe's key meaning the ID remains the same; this is intended to solve the problem Niall faced.
so what is the convention for marking the removed v1 as deceased? randy
so what is the convention for marking the removed v1 as deceased?
Disconnected probes will automatically be marked as "abandoned" after 90 days and as such they are filtered out from various places like maps. If you want to, you ask (*) for it to be explicitly marked as "written off" which is a slightly stronger signal but otherwise it doesn't influence behaviour. Both flags are automatically reversed if the probe connects again. Cheers, Robert (*) via a mail to atlas@ripe.net. We could make this self-service but demand is/was not very high for it
On 2021/12/10 1:37 , Randy Bush wrote:
a sweet old v1 probe, 2285, in a hard to access (due to covid) place died 19 months ago. i want to swap in a v3, 25898, this weekend. i know i could create a new entry, but how do i delete the old; or better yet, move the data from old to new? stop laughing. :)
For measurements, you can add the new probe and remove the old one. The API is called 'participation-requests'. Data is firmly associated with a probe ID. And hardware probes all have their own unique IDs. Philip
Data is firmly associated with a probe ID. And hardware probes all have their own unique IDs.
So… How do we get someone to do "UPDATE data SET probe_id=25898 WHERE probe_id=2285 ;) Cheers, Sander
On 2021/12/10 15:46 , Sander Steffann wrote:
Data is firmly associated with a probe ID. And hardware probes all have their own unique IDs.
So… How do we get someone to do "UPDATE data SET probe_id=25898 WHERE probe_id=2285 ;)
Simple, download the data dumps, import them into Google Bigtable, run the update and convince the RIPE NCC to drop the hadoop cluster. :-)
participants (7)
-
Edward Lewis -
Niall O'Reilly -
Philip Homburg -
Ponikierski, Grzegorz -
Randy Bush -
Robert Kisteleki -
Sander Steffann