From florian at narrans.de Wed Dec 1 12:48:57 2010 From: florian at narrans.de (Florian Obser) Date: Wed, 01 Dec 2010 12:48:57 +0100 Subject: [atlas]atlas win! Message-ID: <4CF63629.5030602@narrans.de> Hi, we are running two probes. One behind my private dsl line at home, one in our data centre. I noticed that the IPv6 ping times to m.root-servers.net are more then twice as bad from our data centre compared to the dsl probe. As it turns out at home I'm talking to the m-root instance in Paris while in the data centre we were talking to the instance in Tokyo(?) It looks like this: http://eafc8bd05a0435ef14d31bbff29687dd7b71c3ca.de/m.root-servers.net.v6.png Not _that_ important in the great scheme of things but non the less quite nice ;) Thanks! Best regards, Florian From Woeber at CC.UniVie.ac.at Wed Dec 1 13:15:22 2010 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 01 Dec 2010 12:15:22 +0000 Subject: [atlas]atlas win! In-Reply-To: <4CF63629.5030602@narrans.de> References: <4CF63629.5030602@narrans.de> Message-ID: <4CF63C5A.5070305@CC.UniVie.ac.at> Florian Obser wrote: > Hi, > > we are running two probes. One behind my private dsl line at home, one > in our data centre. > > I noticed that the IPv6 ping times to m.root-servers.net are more then > twice as bad from our data centre compared to the dsl probe. > > As it turns out at home I'm talking to the m-root instance in Paris > while in the data centre we were talking to the instance in Tokyo(?) Some of the fun of anycasting :-) I was pondering this issue already here in Vienna, too, but for the moment with IPv4 only, because I don't have v6 on the DSL wire (yet), but our subnet at the university does v6 :-) > It looks like this: > > http://eafc8bd05a0435ef14d31bbff29687dd7b71c3ca.de/m.root-servers.net.v6.png > > Not _that_ important in the great scheme of things but non the less > quite nice ;) > > Thanks! > > Best regards, > > Florian Wilfried. From rbarnes at bbn.com Thu Dec 2 04:36:51 2010 From: rbarnes at bbn.com (Richard L. Barnes) Date: Wed, 1 Dec 2010 22:36:51 -0500 Subject: [atlas]Inaccurate uptime tracking? Message-ID: Hey guys, I'm seeing an inconsistency between the reported uptime and the actual measurements from probe #394. On the one hand, the probe info page reports only a little over an hour of uptime: Total Uptime: 0d, 1h, 1m Connect at: Disconnect at: 2010-12-02 02:38:06 UTC (still connected) 2010-12-01 04:22:43 UTC 2010-12-01 04:28:42 UTC But the graphs for the last 8 hours show only a brief down-time; roughly: Disconnect: 2010-12-02 02:27:00 UTC Reconnect: 2010-12-02 02:35:00 UTC This wouldn't bother me much if uptime weren't tied to chances to win an iPad :) --Richard From astrikos at ripe.net Thu Dec 2 09:45:31 2010 From: astrikos at ripe.net (Andreas Strikos) Date: Thu, 2 Dec 2010 09:45:31 +0100 Subject: [atlas]Inaccurate uptime tracking? In-Reply-To: References: Message-ID: <5CB7FC1A-D5F3-42C5-B067-C908289B0B36@ripe.net> Hi Richard, The reason you saw this inconsistency is because the history stats are updated every 3 hours or so. So if you see your history table now there is one more line there that makes the total uptime consistent. Anyhow, if you see anything else that seems inconsistent just let us know. /Andreas On Dec 2, 2010, at 4:36 AM, Richard L. Barnes wrote: > Hey guys, > > I'm seeing an inconsistency between the reported uptime and the actual measurements from probe #394. On the one hand, the probe info page reports only a little over an hour of uptime: > > Total Uptime: 0d, 1h, 1m > Connect at: Disconnect at: > 2010-12-02 02:38:06 UTC (still connected) > 2010-12-01 04:22:43 UTC 2010-12-01 04:28:42 UTC > > But the graphs for the last 8 hours show only a brief down-time; roughly: > Disconnect: 2010-12-02 02:27:00 UTC > Reconnect: 2010-12-02 02:35:00 UTC > > This wouldn't bother me much if uptime weren't tied to chances to win an iPad :) > > --Richard > From tore.anderson at redpill-linpro.com Thu Dec 2 11:17:13 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Thu, 02 Dec 2010 11:17:13 +0100 Subject: [atlas]DNS records for the probes' internet address Message-ID: <4CF77229.6060101@redpill-linpro.com> Hi list, I've got a probe connected to my home broadband connection, which might change its WAN address whenever my ISP feels like it should. I just thought it would be a nice feature if the probes had an A record in DNS that were automatically updated to match the current external address. Like probe-121.atlas.ripe.net or something. That way I would have a hostname I would be sure that points to the WAN address of my CPE whenever I want to log on to my home network from somewhere else. I would think such a feature would be a small incentive for home broadband users to become probe hosts. On an unrelated note, the graphs for the probe in question (#121) doesn't work, they're all gray, even though the probe is up. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com Tel: +47 21 54 41 27 From emile.aben at ripe.net Thu Dec 2 11:56:21 2010 From: emile.aben at ripe.net (Emile Aben) Date: Thu, 02 Dec 2010 11:56:21 +0100 Subject: [atlas]DNS records for the probes' internet address In-Reply-To: <4CF77229.6060101@redpill-linpro.com> References: <4CF77229.6060101@redpill-linpro.com> Message-ID: <4CF77B55.5040509@ripe.net> On 02/12/2010 11:17, Tore Anderson wrote: > Hi list, > > I've got a probe connected to my home broadband connection, which might > change its WAN address whenever my ISP feels like it should. I just > thought it would be a nice feature if the probes had an A record in DNS > that were automatically updated to match the current external address. > Like probe-121.atlas.ripe.net or something. That way I would have a > hostname I would be sure that points to the WAN address of my CPE > whenever I want to log on to my home network from somewhere else. We can see if there is broader interest for this feature and make it an opt-in (checkbox in the GUI). One thing to be careful about here is that having all probes in easy to guess hostnames, will make it easy to DoS part of the infrastructure. Doing it as an opt-in, will make sure that only the people that want/need this feature will enable it, and if that is a sufficiently low fraction of total, it makes it unlikely as a DoS target. > I would think such a feature would be a small incentive for home > broadband users to become probe hosts. > > On an unrelated note, the graphs for the probe in question (#121) > doesn't work, they're all gray, even though the probe is up. As we speak, probes are upgrading to firmware version 3900, which solves this problem (see http://atlas.ripe.net/dynamic/stats/stats.probe_versions.png for overall status). In case people still see this problem by the end of the day with firmware version < 3900 and want to force firmware version 3900 onto their probes: You can force the upgrade by rebooting (unplugging and replugging) your probe. Emile From tore.anderson at redpill-linpro.com Thu Dec 2 12:41:20 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Thu, 02 Dec 2010 12:41:20 +0100 Subject: [atlas]DNS records for the probes' internet address In-Reply-To: <4CF77B55.5040509@ripe.net> References: <4CF77229.6060101@redpill-linpro.com> <4CF77B55.5040509@ripe.net> Message-ID: <4CF785E0.9040602@redpill-linpro.com> * Emile Aben > We can see if there is broader interest for this feature and make it > an opt-in (checkbox in the GUI). One thing to be careful about here > is that having all probes in easy to guess hostnames, will make it > easy to DoS part of the infrastructure. Doing it as an opt-in, will > make sure that only the people that want/need this feature will > enable it, and if that is a sufficiently low fraction of total, it > makes it unlikely as a DoS target. You could also of course make the hostname harder to guess, generating some random UID that's part of the FQDN and that each host have to look up in the Atlas dashboard manually, and set up easier-to-remember CNAMEs perhaps. By the way - when it comes to secrecy for privacy reasons, I'd personally very much like to make my probes as public as possible (doesn't necessarily have to include listing the IP address if you're concerned about DoS attacks). Because one way I can imagine the Atlas projects being immensely useful to network operators world-wide is if it can be used as a kind of massive public looking glass. Someone could then go to the dashboard and query for a listing of probes dependent on various parameters, such as in autonomous system #N or in country/city/continent Foo, select the probes he wants, and then request an arbitrary traceroute or ping to be run from those probes. Heck, I'd even give it a BGP feed people could query like that too, but I assume it doesn't have the horsepower to deal with that... I know I would certainly allow the probes I host to be used like that and hope that as many others as possible did so too. I have no idea of how of I have tried to debug a connectivity problem from some random source network and have unsuccessfully searched for a looking glass that could help me with it, but it's _a lot_ of times. I'm sure I'm not alone about that, and if people see that Atlas provides such an awesomely useful service I'm sure that would in turn make them more interested in participating by hosting or sponsoring probes of their own. > You can force the upgrade by rebooting (unplugging and replugging) > your probe. HA! Trying to cheat me out of my iPad, are you? That's low, Emile, low...your diabolical tricks won't work on me! =D Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From robert at ripe.net Thu Dec 2 12:59:03 2010 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 02 Dec 2010 12:59:03 +0100 Subject: [atlas]DNS records for the probes' internet address In-Reply-To: <4CF785E0.9040602@redpill-linpro.com> References: <4CF77229.6060101@redpill-linpro.com> <4CF77B55.5040509@ripe.net> <4CF785E0.9040602@redpill-linpro.com> Message-ID: <4CF78A07.8070001@ripe.net> Hi, On 2010.12.02. 12:41, Tore Anderson wrote: > * Emile Aben > >> We can see if there is broader interest for this feature and make it >> an opt-in (checkbox in the GUI). One thing to be careful about here >> is that having all probes in easy to guess hostnames, will make it >> easy to DoS part of the infrastructure. Doing it as an opt-in, will >> make sure that only the people that want/need this feature will >> enable it, and if that is a sufficiently low fraction of total, it >> makes it unlikely as a DoS target. > > You could also of course make the hostname harder to guess, generating > some random UID that's part of the FQDN and that each host have to look > up in the Atlas dashboard manually, and set up easier-to-remember CNAMEs > perhaps. We could do that too. Or make it an option for the users, like "probe DNS registration: none, obfuscated, simple". > By the way - when it comes to secrecy for privacy reasons, I'd > personally very much like to make my probes as public as possible > (doesn't necessarily have to include listing the IP address if you're > concerned about DoS attacks). Because one way I can imagine the Atlas > projects being immensely useful to network operators world-wide is if it > can be used as a kind of massive public looking glass. Someone could > then go to the dashboard and query for a listing of probes dependent on > various parameters, such as in autonomous system #N or in > country/city/continent Foo, select the probes he wants, and then request > an arbitrary traceroute or ping to be run from those probes. Heck, I'd > even give it a BGP feed people could query like that too, but I assume > it doesn't have the horsepower to deal with that... Some of these are in our mid-term plans already. For example: * We will allow hosts to make some or all their measurement activities and results public. We have a couple of probes in our office, and I don't think we mind opening their measurements up to the public. (Home users might not want to do this.) * (Ssssh, don't tell anyone yet, but...) we started collecting IPv4/6 prefixes and ASNs of hosts. We plan to make this available, probably even searchable ("how many probes do you have in AS x?"). It'd be nice if one could refine this with the above, as "... and how many made their measurements available?" * At a later stage, once you can specify your own measurements, we want to allow you to say "use these sources for my measurement", so you could do on-demand stuff to/from anywhere to some extent. I think we're pretty much aligned on these features, and I'm confident we can deal with the privacy implications, if any. > I know I would certainly allow the probes I host to be used like that > and hope that as many others as possible did so too. I have no idea of > how of I have tried to debug a connectivity problem from some random > source network and have unsuccessfully searched for a looking glass that > could help me with it, but it's _a lot_ of times. I'm sure I'm not > alone about that, and if people see that Atlas provides such an > awesomely useful service I'm sure that would in turn make them more > interested in participating by hosting or sponsoring probes of their own. Exactly. We're building something with great potential, so this kind of feedback is very much welcome! Cheers, Robert From probe at garf.de Thu Dec 2 13:08:14 2010 From: probe at garf.de (Wolfgang Tremmel) Date: Thu, 2 Dec 2010 13:08:14 +0100 Subject: [atlas]DNS records for the probes' internet address In-Reply-To: <4CF78A07.8070001@ripe.net> References: <4CF77229.6060101@redpill-linpro.com> <4CF77B55.5040509@ripe.net> <4CF785E0.9040602@redpill-linpro.com> <4CF78A07.8070001@ripe.net> Message-ID: Hello, On 02.12.2010, at 12:59, Robert Kisteleki wrote: > > Some of these are in our mid-term plans already. For example: > * We will allow hosts to make some or all their measurement activities and > results public. We have a couple of probes in our office, and I don't think > we mind opening their measurements up to the public. (Home users might not > want to do this.) in addition to that (as an option for home users) an "ACL" option would be nice ("I allow you to see my probe, please allow me to see yours") best regards, Wolfgang --- Wolfgang Tremmel, WT5-RIPE tremmel at garf.de From rbarnes at bbn.com Thu Dec 2 14:45:00 2010 From: rbarnes at bbn.com (Richard L. Barnes) Date: Thu, 2 Dec 2010 08:45:00 -0500 Subject: [atlas]Inaccurate uptime tracking? In-Reply-To: <5CB7FC1A-D5F3-42C5-B067-C908289B0B36@ripe.net> References: <5CB7FC1A-D5F3-42C5-B067-C908289B0B36@ripe.net> Message-ID: I see, looks good now. Thanks! --Richard On Dec 2, 2010, at 3:45 AM, Andreas Strikos wrote: > Hi Richard, > > The reason you saw this inconsistency is because the history stats are updated every 3 hours or so. > So if you see your history table now there is one more line there that makes the total uptime consistent. > Anyhow, if you see anything else that seems inconsistent just let us know. > > /Andreas > > On Dec 2, 2010, at 4:36 AM, Richard L. Barnes wrote: > >> Hey guys, >> >> I'm seeing an inconsistency between the reported uptime and the actual measurements from probe #394. On the one hand, the probe info page reports only a little over an hour of uptime: >> >> Total Uptime: 0d, 1h, 1m >> Connect at: Disconnect at: >> 2010-12-02 02:38:06 UTC (still connected) >> 2010-12-01 04:22:43 UTC 2010-12-01 04:28:42 UTC >> >> But the graphs for the last 8 hours show only a brief down-time; roughly: >> Disconnect: 2010-12-02 02:27:00 UTC >> Reconnect: 2010-12-02 02:35:00 UTC >> >> This wouldn't bother me much if uptime weren't tied to chances to win an iPad :) >> >> --Richard >> > From Woeber at CC.UniVie.ac.at Thu Dec 2 15:10:54 2010 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 02 Dec 2010 14:10:54 +0000 Subject: [atlas]DNS records for the probes' internet address In-Reply-To: <4CF77229.6060101@redpill-linpro.com> References: <4CF77229.6060101@redpill-linpro.com> Message-ID: <4CF7A8EE.4090009@CC.UniVie.ac.at> Hi Tore, yes, manufacturing a DNS name for my/our probe/s was one of the first actions during installation :-) Tore Anderson wrote: > Hi list, > > I've got a probe connected to my home broadband connection, which might > change its WAN address whenever my ISP feels like it should. What would be your suggested mechanism to keep this in synch with the DNS zone data? > I just > thought it would be a nice feature if the probes had an A record in DNS > that were automatically updated to match the current external address. > Like probe-121.atlas.ripe.net or something. That way I would have a > hostname I would be sure that points to the WAN address of my CPE > whenever I want to log on to my home network from somewhere else. > > I would think such a feature would be a small incentive for home > broadband users to become probe hosts. > > On an unrelated note, the graphs for the probe in question (#121) > doesn't work, they're all gray, even though the probe is up. > > Best regards, Cheers, Wilfried From joao at bondis.org Thu Dec 2 15:20:54 2010 From: joao at bondis.org (=?iso-8859-1?Q?Jo=E3o_Damas?=) Date: Thu, 2 Dec 2010 15:20:54 +0100 Subject: [atlas]DNS records for the probes' internet address In-Reply-To: <4CF7A8EE.4090009@CC.UniVie.ac.at> References: <4CF77229.6060101@redpill-linpro.com> <4CF7A8EE.4090009@CC.UniVie.ac.at> Message-ID: <5A3689D0-E875-47D2-B29F-C8DDE9768DC4@bondis.org> On 2 Dec 2010, at 15:10, Wilfried Woeber, UniVie/ACOnet wrote: > Hi Tore, > > yes, manufacturing a DNS name for my/our probe/s was one of the first > actions during installation :-) > > Tore Anderson wrote: > >> Hi list, >> >> I've got a probe connected to my home broadband connection, which might >> change its WAN address whenever my ISP feels like it should. > > What would be your suggested mechanism to keep this in synch with the > DNS zone data? dynamic updates, I guess. If the probe can't handle that in its firmware then the receiving side, at the NCC, could update a local zone (what Tore was suggesting). This is a request for a service like what dyndns and others do, which has support in quite a few DSL routers these days, but without having to subscribe to these services. > >> I just >> thought it would be a nice feature if the probes had an A record in DNS >> that were automatically updated to match the current external address. >> Like probe-121.atlas.ripe.net or something. That way I would have a >> hostname I would be sure that points to the WAN address of my CPE >> whenever I want to log on to my home network from somewhere else. >> >> I would think such a feature would be a small incentive for home >> broadband users to become probe hosts. >> >> On an unrelated note, the graphs for the probe in question (#121) >> doesn't work, they're all gray, even though the probe is up. >> >> Best regards, > > Cheers, > Wilfried > From antony at ripe.net Thu Dec 2 17:27:05 2010 From: antony at ripe.net (Antony Antony) Date: Thu, 2 Dec 2010 17:27:05 +0100 Subject: [atlas]DNS records for the probes' internet address In-Reply-To: <4CF77229.6060101@redpill-linpro.com> References: <4CF77229.6060101@redpill-linpro.com> Message-ID: <20101202162705.GA14647@dog.ripe.net> talking as an individual. Isn't it the same as probe ID? just another namespace. I wonder how forward dns would scale for large sensor networks. I have my doubts on usability and maintaining operational constancy of forward dns records when probes change ip addresses. For example, German DSL networks might change probe's public IP-address every day. May be as Jo?o suggested dyndns could work in theory. Once there are 1000s of probes what good are forward names. Then we will need hierarchies. one hierarchuy based on geography, one based network prefixes, asns .. Currently these probes just send out measurements and don't respond to anything but ping. On the other hand if the probes become more static say something like an rpsl-reachable-test [1] there is definitely value for forward dns. Then you actually want a name to IP address mapping. regards, -antony [1] http://tools.ietf.org/html/draft-haberman-rpsl-reachable-test-04 On Thu, Dec 02, 2010 at 11:17:13AM +0100, Tore Anderson wrote: > Hi list, > > I've got a probe connected to my home broadband connection, which might > change its WAN address whenever my ISP feels like it should. I just > thought it would be a nice feature if the probes had an A record in DNS > that were automatically updated to match the current external address. > Like probe-121.atlas.ripe.net or something. That way I would have a > hostname I would be sure that points to the WAN address of my CPE > whenever I want to log on to my home network from somewhere else. > > I would think such a feature would be a small incentive for home > broadband users to become probe hosts. > > On an unrelated note, the graphs for the probe in question (#121) > doesn't work, they're all gray, even though the probe is up. > > Best regards, > -- > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com > Tel: +47 21 54 41 27 > > From joao at bondis.org Thu Dec 2 18:45:05 2010 From: joao at bondis.org (=?iso-8859-1?Q?Jo=E3o_Damas?=) Date: Thu, 2 Dec 2010 18:45:05 +0100 Subject: [atlas]DNS records for the probes' internet address In-Reply-To: <20101202162705.GA14647@dog.ripe.net> References: <4CF77229.6060101@redpill-linpro.com> <20101202162705.GA14647@dog.ripe.net> Message-ID: <75D320E6-0B40-46CC-9201-AA0D91D099B2@bondis.org> Antony, the "good" is for the users. It would provide them with a stable name to address the variable external IP they get from the ISP, enabling access to home machines from the outside using the name, independently of what IP the DSL modem/cable modem happens to have at any given time Joao On 2 Dec 2010, at 17:27, Antony Antony wrote: > talking as an individual. > > Isn't it the same as probe ID? just another namespace. > I wonder how forward dns would scale for large sensor networks. > > I have my doubts on usability and maintaining operational constancy of forward dns records when probes change ip addresses. For example, German DSL networks might change probe's public IP-address every day. May be as Jo?o suggested dyndns could work in theory. Once there are 1000s of probes what good are forward names. Then we will need hierarchies. > one hierarchuy based on geography, one based network prefixes, asns .. > > Currently these probes just send out measurements and don't respond to anything but ping. > > On the other hand if the probes become more static say something like an > rpsl-reachable-test [1] there is definitely value for forward dns. Then you actually want a name to IP address mapping. > > regards, > -antony > > [1] http://tools.ietf.org/html/draft-haberman-rpsl-reachable-test-04 > > > > > > On Thu, Dec 02, 2010 at 11:17:13AM +0100, Tore Anderson wrote: >> Hi list, >> >> I've got a probe connected to my home broadband connection, which might >> change its WAN address whenever my ISP feels like it should. I just >> thought it would be a nice feature if the probes had an A record in DNS >> that were automatically updated to match the current external address. >> Like probe-121.atlas.ripe.net or something. That way I would have a >> hostname I would be sure that points to the WAN address of my CPE >> whenever I want to log on to my home network from somewhere else. >> >> I would think such a feature would be a small incentive for home >> broadband users to become probe hosts. >> >> On an unrelated note, the graphs for the probe in question (#121) >> doesn't work, they're all gray, even though the probe is up. >> >> Best regards, >> -- >> Tore Anderson >> Redpill Linpro AS - http://www.redpill-linpro.com >> Tel: +47 21 54 41 27 >> >> > From Woeber at CC.UniVie.ac.at Thu Dec 2 21:30:41 2010 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 02 Dec 2010 20:30:41 +0000 Subject: [atlas]DNS records for the probes' internet address In-Reply-To: <75D320E6-0B40-46CC-9201-AA0D91D099B2@bondis.org> References: <4CF77229.6060101@redpill-linpro.com> <20101202162705.GA14647@dog.ripe.net> <75D320E6-0B40-46CC-9201-AA0D91D099B2@bondis.org> Message-ID: <4CF801F1.5050500@CC.UniVie.ac.at> Jo?o Damas wrote: > Antony, > the "good" is for the users. It would provide them with a stable name > to address the variable external IP they get from the ISP, enabling access > to home machines from the outside using the name, independently of what > IP the DSL modem/cable modem happens to have at any given time Actually, I can see the beauty of name-to-dynamic-IP-tracking, but I doubt that it is a reasonable investment to teach the small things to do dynamic DNS *centrally*. To be able to get a grip on that one, I think we'd need to better understand when and how the probe detects an change of address? My feeling is that tracking of IP to name mapping is a local issue. Wilfried > Joao > > On 2 Dec 2010, at 17:27, Antony Antony wrote: > > >>talking as an individual. >> >>Isn't it the same as probe ID? just another namespace. >>I wonder how forward dns would scale for large sensor networks. >> >>I have my doubts on usability and maintaining operational constancy of forward dns records when probes change ip addresses. For example, German DSL networks might change probe's public IP-address every day. May be as Jo?o suggested dyndns could work in theory. Once there are 1000s of probes what good are forward names. Then we will need hierarchies. >>one hierarchuy based on geography, one based network prefixes, asns .. >> >>Currently these probes just send out measurements and don't respond to anything but ping. >> >>On the other hand if the probes become more static say something like an >>rpsl-reachable-test [1] there is definitely value for forward dns. Then you actually want a name to IP address mapping. >> >>regards, >>-antony >> >>[1] http://tools.ietf.org/html/draft-haberman-rpsl-reachable-test-04 >> >> >> >> >> >>On Thu, Dec 02, 2010 at 11:17:13AM +0100, Tore Anderson wrote: >> >>>Hi list, >>> >>>I've got a probe connected to my home broadband connection, which might >>>change its WAN address whenever my ISP feels like it should. I just >>>thought it would be a nice feature if the probes had an A record in DNS >>>that were automatically updated to match the current external address. >>>Like probe-121.atlas.ripe.net or something. That way I would have a >>>hostname I would be sure that points to the WAN address of my CPE >>>whenever I want to log on to my home network from somewhere else. >>> >>>I would think such a feature would be a small incentive for home >>>broadband users to become probe hosts. >>> >>>On an unrelated note, the graphs for the probe in question (#121) >>>doesn't work, they're all gray, even though the probe is up. >>> >>>Best regards, >>>-- >>>Tore Anderson >>>Redpill Linpro AS - http://www.redpill-linpro.com >>>Tel: +47 21 54 41 27 >>> >>> >> > > From joao at bondis.org Thu Dec 2 22:57:26 2010 From: joao at bondis.org (=?iso-8859-1?Q?Jo=E3o_Damas?=) Date: Thu, 2 Dec 2010 22:57:26 +0100 Subject: [atlas]DNS records for the probes' internet address In-Reply-To: <4CF801F1.5050500@CC.UniVie.ac.at> References: <4CF77229.6060101@redpill-linpro.com> <20101202162705.GA14647@dog.ripe.net> <75D320E6-0B40-46CC-9201-AA0D91D099B2@bondis.org> <4CF801F1.5050500@CC.UniVie.ac.at> Message-ID: <8CCD9EC4-8408-4AE8-804F-B939166FAB3D@bondis.org> On 2 Dec 2010, at 21:30, Wilfried Woeber, UniVie/ACOnet wrote: > Jo?o Damas wrote: >> Antony, >> the "good" is for the users. It would provide them with a stable name >> to address the variable external IP they get from the ISP, enabling access >> to home machines from the outside using the name, independently of what >> IP the DSL modem/cable modem happens to have at any given time > > Actually, I can see the beauty of name-to-dynamic-IP-tracking, but I > doubt that it is a reasonable investment to teach the small things to do > dynamic DNS *centrally*. > I think Tore's original proposal was that the probe do nothing special, rather the central servers at the NCC would be doing all the work (detecting the new IP and feeding it into the forward DNS zone). I use dyndns as an example of why this is useful, not as an example of a technical solution to be applied here (and in any case I am not the one working on the probes or the servers, so I have nothing to say about how it is done. I am just showing why it is useful and supporting the request) Joao From Woeber at CC.UniVie.ac.at Thu Dec 2 23:01:09 2010 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 02 Dec 2010 22:01:09 +0000 Subject: [atlas]DNS records for the probes' internet address In-Reply-To: <8CCD9EC4-8408-4AE8-804F-B939166FAB3D@bondis.org> References: <4CF77229.6060101@redpill-linpro.com> <20101202162705.GA14647@dog.ripe.net> <75D320E6-0B40-46CC-9201-AA0D91D099B2@bondis.org> <4CF801F1.5050500@CC.UniVie.ac.at> <8CCD9EC4-8408-4AE8-804F-B939166FAB3D@bondis.org> Message-ID: <4CF81725.3010005@CC.UniVie.ac.at> Jo?o, good point! I was barking at the wrong tree, by assuming a particular implementation ;-/ Jo?o Damas wrote: > On 2 Dec 2010, at 21:30, Wilfried Woeber, UniVie/ACOnet wrote: > > >>Jo?o Damas wrote: >> >>>Antony, >>>the "good" is for the users. It would provide them with a stable name >>>to address the variable external IP they get from the ISP, enabling access >>>to home machines from the outside using the name, independently of what >>>IP the DSL modem/cable modem happens to have at any given time >> >>Actually, I can see the beauty of name-to-dynamic-IP-tracking, but I >>doubt that it is a reasonable investment to teach the small things to do >>dynamic DNS *centrally*. >> > > > I think Tore's original proposal was that the probe do nothing special, rather the central servers at the NCC would be doing all the work (detecting the new IP and feeding it into the forward DNS zone). I use dyndns as an example of why this is useful, not as an example of a technical solution to be applied here (and in any case I am not the one working on the probes or the servers, so I have nothing to say about how it is done. I am just showing why it is useful and supporting the request) > > Joao Wilfried. PS: thanks to the Team for shipping 3900 and showing the IPv6 address. Well done! From Tjebbe at kanariepiet.com Thu Dec 2 23:28:13 2010 From: Tjebbe at kanariepiet.com (Jelte Jansen) Date: Thu, 02 Dec 2010 23:28:13 +0100 Subject: [atlas]FYI probe problems after power failure Message-ID: <4CF81D7D.9090806@kanariepiet.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Today I had a power failure, and luckily everything came back up when I fixed it. However, a while later, I wondered if the probe had too, and it had not. The status page said it was up, but it hadn't reported data for about 6 hours (grey graphs). I assume I hit one of the problems in the FAQ: - --- Technical background: the probe tries to get current time indication using NTP upon booting, which sometimes fails. This causes the probe to think the curent date is November 1999, which confuses it a lot; it doesn't register properly or it sends measurement data for the twentieth century which is immediately discarded by the system. We plan to convince the probe to insist on vaild NTP or acquire some other time indication. The fix will be deployed in a firmware update. - --- Since the probe boots a lot faster than my gateway, I guess it never retried NTP. Powercycle fixed it indeed. So the lesson here is (at least until there is an update that retries ntpdate, or something), if the machine that provides your Internet connection takes a while to boot up, and they are both powered on at the same time, you may need to powercycle your probe. Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkz4HX0ACgkQ4nZCKsdOncVlXgCfZe+3FbLdTWTxCvXYZFrmaXjd TsEAn3vqmfjbUmWfueVcziCi2a3Hs6jF =zqNQ -----END PGP SIGNATURE----- From tore.anderson at redpill-linpro.com Fri Dec 3 09:15:08 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Fri, 03 Dec 2010 09:15:08 +0100 Subject: [atlas]DNS records for the probes' internet address In-Reply-To: <4CF801F1.5050500@CC.UniVie.ac.at> References: <4CF77229.6060101@redpill-linpro.com> <20101202162705.GA14647@dog.ripe.net> <75D320E6-0B40-46CC-9201-AA0D91D099B2@bondis.org> <4CF801F1.5050500@CC.UniVie.ac.at> Message-ID: <4CF8A70C.5040903@redpill-linpro.com> Good morning, * Wilfried Woeber, UniVie/ACOnet > Actually, I can see the beauty of name-to-dynamic-IP-tracking, but I > doubt that it is a reasonable investment to teach the small things to do > dynamic DNS *centrally*. Clearly it would be a waste of the probe's constrained resources to make it do such DNS updates itself. I didn't mean to suggest that the probe should change in any way. The central Atlas system, *already* knows all the necessary information. If you check your probe details on the web page, you will see a field called ?Internet Address?, which will differ from ?Local Address? if the probe is behind the NAT. So my idea was simply to set up a DNS server with a custom zone backend that looked up this information directly from the central database it's stored in. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com Tel: +47 21 54 41 27 From florian at narrans.de Fri Dec 3 09:31:38 2010 From: florian at narrans.de (Florian Obser) Date: Fri, 03 Dec 2010 09:31:38 +0100 Subject: [atlas]FYI probe problems after power failure In-Reply-To: <4CF81D7D.9090806@kanariepiet.com> References: <4CF81D7D.9090806@kanariepiet.com> Message-ID: <4CF8AAEA.5020309@narrans.de> On 12/02/2010 11:28 PM, Jelte Jansen wrote: > Since the probe boots a lot faster than my gateway, I guess it never > retried NTP. Powercycle fixed it indeed. > > So the lesson here is (at least until there is an update that retries > ntpdate, or something), if the machine that provides your Internet > connection takes a while to boot up, and they are both powered on at the > same time, you may need to powercycle your probe. FWIW, we deployed our probe in our datacenter on a friday and due to a typo in the firewall config the probe didn't receive any responses from the internet. We fixed the firewall and the probe started doing it's thing (pinging, connecting to ripe's infrastructure etc.). So we did not powercycle the probe as it appeared to be working. Later we noticed the grey bars and were told by Antony that we hit the ntp problem. We didn't want to send someone to the datacentre on the weekend and planed to powercycle the probe the next monday. Just before we unplugged the probe we had another look at the graphs and they were fine. It appears the probe will eventually do another ntp request, maybe every 24 hours? It looks like if it's really really a PITA to get to the probe you can just wait a day or so and it will fix itself. (Btw. the probe still has the "original" 3830 firmware so I don't think it has a fix for the ntp problem) > > Jelte regards, florian -- I remember yesterday, but the memory is in my head now. Was yesterday real? Or is it only the memory that is real? From robert at ripe.net Fri Dec 3 10:32:24 2010 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 03 Dec 2010 10:32:24 +0100 Subject: [atlas]DNS records for the probes' internet address In-Reply-To: <4CF8A70C.5040903@redpill-linpro.com> References: <4CF77229.6060101@redpill-linpro.com> <20101202162705.GA14647@dog.ripe.net> <75D320E6-0B40-46CC-9201-AA0D91D099B2@bondis.org> <4CF801F1.5050500@CC.UniVie.ac.at> <4CF8A70C.5040903@redpill-linpro.com> Message-ID: <4CF8B928.4020901@ripe.net> > The central Atlas system, *already* knows all the necessary information. > If you check your probe details on the web page, you will see a field > called ?Internet Address?, which will differ from ?Local Address? if the > probe is behind the NAT. So my idea was simply to set up a DNS server > with a custom zone backend that looked up this information directly from > the central database it's stored in. As you already concluded, we have the data to make this happen. It also seems that some of you probe hosts would find it useful -- but for completely different reasons, not for Atlas functionality as such. I have to admit this was not in our planning, but we're willing to listen to what you need :) So one thing we could do is to allow hosts to opt in to some form of probe DNS registration: simple or obfuscated. We could put this on our todo list if there's enough demand. Please let us know if you'd like to use such a feature. Regards, Robert From tore.anderson at redpill-linpro.com Fri Dec 3 11:05:02 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Fri, 03 Dec 2010 11:05:02 +0100 Subject: [atlas]DNS records for the probes' internet address In-Reply-To: <4CF8B928.4020901@ripe.net> References: <4CF77229.6060101@redpill-linpro.com> <20101202162705.GA14647@dog.ripe.net> <75D320E6-0B40-46CC-9201-AA0D91D099B2@bondis.org> <4CF801F1.5050500@CC.UniVie.ac.at> <4CF8A70C.5040903@redpill-linpro.com> <4CF8B928.4020901@ripe.net> Message-ID: <4CF8C0CE.2010902@redpill-linpro.com> * Robert Kisteleki > As you already concluded, we have the data to make this happen. It also > seems that some of you probe hosts would find it useful -- but for > completely different reasons, not for Atlas functionality as such. I have to > admit this was not in our planning, but we're willing to listen to what you > need :) > > So one thing we could do is to allow hosts to opt in to some form of probe > DNS registration: simple or obfuscated. We could put this on our todo list > if there's enough demand. Please let us know if you'd like to use such a > feature. As you can probably guess, I would. However, I don't feel it's a very important feature. If it requires diverting significant amounts of development resources away from more important features (such as implementing a massive public looking glass functionality, hint hint ;-) - don't bother! But if can be implemented quickly with little effort, it would be cool feature adding value to volunteering as a probe host. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com Tel: +47 21 54 41 27 From joao at bondis.org Fri Dec 3 11:07:02 2010 From: joao at bondis.org (=?iso-8859-1?Q?Jo=E3o_Damas?=) Date: Fri, 3 Dec 2010 11:07:02 +0100 Subject: [atlas]DNS records for the probes' internet address In-Reply-To: <4CF8C0CE.2010902@redpill-linpro.com> References: <4CF77229.6060101@redpill-linpro.com> <20101202162705.GA14647@dog.ripe.net> <75D320E6-0B40-46CC-9201-AA0D91D099B2@bondis.org> <4CF801F1.5050500@CC.UniVie.ac.at> <4CF8A70C.5040903@redpill-linpro.com> <4CF8B928.4020901@ripe.net> <4CF8C0CE.2010902@redpill-linpro.com> Message-ID: +1 On 3 Dec 2010, at 11:05, Tore Anderson wrote: > * Robert Kisteleki > >> As you already concluded, we have the data to make this happen. It also >> seems that some of you probe hosts would find it useful -- but for >> completely different reasons, not for Atlas functionality as such. I have to >> admit this was not in our planning, but we're willing to listen to what you >> need :) >> >> So one thing we could do is to allow hosts to opt in to some form of probe >> DNS registration: simple or obfuscated. We could put this on our todo list >> if there's enough demand. Please let us know if you'd like to use such a >> feature. > > As you can probably guess, I would. > > However, I don't feel it's a very important feature. If it requires > diverting significant amounts of development resources away from more > important features (such as implementing a massive public looking glass > functionality, hint hint ;-) - don't bother! > > But if can be implemented quickly with little effort, it would be cool > feature adding value to volunteering as a probe host. > > Best regards, > -- > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com > Tel: +47 21 54 41 27 > From daniel.karrenberg at ripe.net Fri Dec 3 11:12:34 2010 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 3 Dec 2010 11:12:34 +0100 Subject: [atlas]DNS records for the probes' internet address In-Reply-To: References: <4CF77229.6060101@redpill-linpro.com> <20101202162705.GA14647@dog.ripe.net> <75D320E6-0B40-46CC-9201-AA0D91D099B2@bondis.org> <4CF801F1.5050500@CC.UniVie.ac.at> <4CF8A70C.5040903@redpill-linpro.com> <4CF8B928.4020901@ripe.net> <4CF8C0CE.2010902@redpill-linpro.com> Message-ID: <20101203101234.GI15420@reifripenet.local> +100 ;-) On 03.12 11:07, Jo?o Damas wrote: > +1 > > On 3 Dec 2010, at 11:05, Tore Anderson wrote: > > > * Robert Kisteleki > > > >> As you already concluded, we have the data to make this happen. It also > >> seems that some of you probe hosts would find it useful -- but for > >> completely different reasons, not for Atlas functionality as such. I have to > >> admit this was not in our planning, but we're willing to listen to what you > >> need :) > >> > >> So one thing we could do is to allow hosts to opt in to some form of probe > >> DNS registration: simple or obfuscated. We could put this on our todo list > >> if there's enough demand. Please let us know if you'd like to use such a > >> feature. > > > > As you can probably guess, I would. > > > > However, I don't feel it's a very important feature. If it requires > > diverting significant amounts of development resources away from more > > important features (such as implementing a massive public looking glass > > functionality, hint hint ;-) - don't bother! > > > > But if can be implemented quickly with little effort, it would be cool > > feature adding value to volunteering as a probe host. > > > > Best regards, > > -- > > Tore Anderson > > Redpill Linpro AS - http://www.redpill-linpro.com > > Tel: +47 21 54 41 27 > > > From florian at narrans.de Sun Dec 5 20:28:05 2010 From: florian at narrans.de (Florian Obser) Date: Sun, 05 Dec 2010 20:28:05 +0100 Subject: [atlas]probe locations Message-ID: <4CFBE7C5.8030800@narrans.de> Hi, so, I had a look at the probe locations at https://atlas.ripe.net/ looks like there is a probe on every continent... except Antarctica! How cool would that be! Maybe there is someone on this list who knows someone who knows someone... ;) While discussing this with a friend we both noticed that the coolness could only be topped by a probe on ISS. Looking at the registration page this seems easy enough, "Method of delivery*: Other, please specify: Soyus or Ariane 5" "Hosting Location" on the other hand will probably be a pain in the ass. Regards, Florian -- I remember yesterday, but the memory is in my head now. Was yesterday real? Or is it only the memory that is real? From wilhelm at ripe.net Sun Dec 5 22:22:00 2010 From: wilhelm at ripe.net (Rene Wilhelm) Date: Sun, 05 Dec 2010 22:22:00 +0100 Subject: [atlas]probe locations In-Reply-To: <4CFBE7C5.8030800@narrans.de> References: <4CFBE7C5.8030800@narrans.de> Message-ID: <4CFC0278.2030301@ripe.net> On 12/5/10 8:28 PM, Florian Obser wrote: > Hi, > so, I had a look at the probe locations at https://atlas.ripe.net/ looks > like there is a probe on every continent... except Antarctica! How cool > would that be! Maybe there is someone on this list who knows someone who > knows someone... ;) The south pole (Scott-Amundsen base) would be the place to go! It'd be real cool to have an Atlas probe there, given the challenges in connectivity. >From http://www.computerworld.com/s/article/9049898/The_Big_Chill_Ch_Ch_Chatting_with_the_IT_manager_at_the_South_Pole?taxonomyId=10&pageNumber=2 "*What technical challenges do you face?* Our biggest challenge is bandwidth. We only have it only 12 hours a day at anywhere from T-1 (1.54 Mbit/sec) to 3 Mbit/sec speeds. We also have a transponder that we can use to send 60 Mbit/sec unidirectional from the pole to the real world. We use that to upload scientific data. Our record was 94Gbytes out in one day. We have three different satellites we use to provide our Internet. All of those are pretty ancient. We have a weather satellite, an old maritime communications satellite and an old NASA satellite, the first one that was launched back in 1981. The others were launched in 1976 or 1977. Basically we're scavenging whatever we can find and we can only see each satellite for 3 to 4 hours a day. [...] In the past year we put up a really cool system where we're using the Iridium satellite network. We have 12 modems mulitiplexed together and have a total of 28.8K connectivity 24 x 7." That was December 2007. Don't think much has changed, at this moment the webcam at http://www.usap.gov/videoclipsandmaps/spwebcam.cfm reports " Status: waiting for visibility" ... ;) > While discussing this with a friend we both noticed that the coolness > could only be topped by a probe on ISS. Looking at the registration page > this seems easy enough, "Method of delivery*: Other, please specify: > Soyus or Ariane 5" > "Hosting Location" on the other hand will probably be a pain in the ass. > South pole would already be tricky. Which longitude to use for the probe? Anything between 180W and 180E is valid! And by the looks of it, it would fall off of the google map :-) -- Rene -------------- next part -------------- An HTML attachment was scrubbed... URL: From Woeber at CC.UniVie.ac.at Mon Dec 6 04:40:27 2010 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Mon, 06 Dec 2010 03:40:27 +0000 Subject: [atlas]probe locations In-Reply-To: <4CFC0278.2030301@ripe.net> References: <4CFBE7C5.8030800@narrans.de> <4CFC0278.2030301@ripe.net> Message-ID: <4CFC5B2B.2090801@CC.UniVie.ac.at> Rene Wilhelm wrote: [...] > South pole would already be tricky. Which longitude to use for the probe? > Anything between 180W and 180E is valid! And by the looks of it, it would > fall off of the google map :-) > > -- Rene NTP would possibly be even more tricky. On my way to Cartagena, CO, on he plane, occasionally, I had a look at the map of Antarctica, the research stations and the timezones used "over there" :-) It turns out that there are 3 different approaches in use: - same as "at home" - something close to the timezone based on location (= other than the pole) - same as the port of departure from <$whereever> to the station on A. :-) but UTC may help in all of these cases.... Wilfried. PS: I was even considering to take our 3rd one with me to ICANN @ Cartagena, would have been fun, as I've got 24x7 network access in the hotel, for about a week :-) From rbarnes at bbn.com Mon Dec 6 05:18:04 2010 From: rbarnes at bbn.com (Richard L. Barnes) Date: Sun, 5 Dec 2010 23:18:04 -0500 Subject: [atlas]probe locations In-Reply-To: <4CFC5B2B.2090801@CC.UniVie.ac.at> References: <4CFBE7C5.8030800@narrans.de> <4CFC0278.2030301@ripe.net> <4CFC5B2B.2090801@CC.UniVie.ac.at> Message-ID: <7976C88A-8C38-4401-8378-67956A311DB8@bbn.com> FWIW, I've left email and voicemail on this topic with the US National Science Foundation Division of Antarctic Infrastructure and Logistics -- the guys that run infrastructural things (like networks) down there. We'll see if they reply... --Richard On Dec 5, 2010, at 10:40 PM, Wilfried Woeber, UniVie/ACOnet wrote: > Rene Wilhelm wrote: > > [...] >> South pole would already be tricky. Which longitude to use for the probe? >> Anything between 180W and 180E is valid! And by the looks of it, it would >> fall off of the google map :-) >> >> -- Rene > > NTP would possibly be even more tricky. > > On my way to Cartagena, CO, on he plane, occasionally, I had a look at the > map of Antarctica, the research stations and the timezones used "over there" :-) > > It turns out that there are 3 different approaches in use: > > - same as "at home" > - something close to the timezone based on location (= other than the pole) > - same as the port of departure from <$whereever> to the station on A. > > :-) but UTC may help in all of these cases.... > > Wilfried. > > PS: I was even considering to take our 3rd one with me to ICANN @ Cartagena, > would have been fun, as I've got 24x7 network access in the hotel, for > about a week :-) > From harald.karlsen at thelan.no Mon Dec 6 08:42:15 2010 From: harald.karlsen at thelan.no (Harald Firing Karlsen) Date: Mon, 06 Dec 2010 08:42:15 +0100 Subject: [atlas]Atlas probe showing up as Never seen Message-ID: <4CFC93D7.6020809@thelan.no> Hi, I installed my RIPE Atlas-probe yesterday and it still shows up as "Never seen" on the Atlas website. Everything looks good networking-wise (it have received DHCP-offer, etc), but it still shows up as "Never seen" on the Ripe Atlas website. The MAC-address is 00204AC8243A and the IP-address is 91.209.30.2. I hope you can solve this. -- Kind regards Harald Firing Karlsen From henk at ripe.net Mon Dec 6 14:23:17 2010 From: henk at ripe.net (Henk Uijterwaal) Date: Mon, 06 Dec 2010 14:23:17 +0100 Subject: [atlas]While debugging my dad's network at home... In-Reply-To: <4CEBFF96.6030209@CC.UniVie.ac.at> References: <4CEBFF96.6030209@CC.UniVie.ac.at> Message-ID: <4CFCE3C5.3080609@ripe.net> Hi all, This is a feature request. I was debugging my dad's home network (well, network, 1 PC with a modem) after he complained that he could not send email anymore. It turned out that he somehow managed to disable the ethernet card on his PC. This was a clear user error. He did call the helpdesk of his ISP. The helpdesk started with the configuration of the mail client... Imagine the confusion that created. Anyway, what I think would be really cool for probe hosts is if the probe could give a little bit more information about the network where it is in and present that in a way understandable to the user. For example: * Probe has local address Yes/No * Probe sees local gateway " * Probe has Internet access * Pings to XX works * DNS query works * IMAP server responds * SMTP server responds * Popular website responds * SIP server responds * ... with the list pre-configured for the ISP of the user (or some way to configure that yourself). On the probe, run a webserver such that http://10.0.0.139 points you to the list showing you a list of "yes"/"no"'s. Advantages: * For the end user: if all items are yes, then that shows that there is nothing wrong on the user side and no action has to be taken. * For the helpdesk when debugging the problem: the answer to a number of routine questions is there, without having to explain how to check things. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ I confirm today what I denied yesterday. Anonymous Politician. From robert at ripe.net Tue Dec 7 12:21:19 2010 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 07 Dec 2010 12:21:19 +0100 Subject: [atlas]While debugging my dad's network at home... In-Reply-To: <4CFCE3C5.3080609@ripe.net> References: <4CEBFF96.6030209@CC.UniVie.ac.at> <4CFCE3C5.3080609@ripe.net> Message-ID: <4CFE18AF.7060009@ripe.net> Hi, > Anyway, what I think would be really cool for probe hosts is if the probe > could give a little bit more information about the network where it is in > and present that in a way understandable to the user. For example: > > * Probe has local address Yes/No > * Probe sees local gateway " > * Probe has Internet access > * Pings to XX works > * DNS query works > * IMAP server responds > * SMTP server responds > * Popular website responds > * SIP server responds > * ... Note: there are a bunch of inputs here that would have to be pre-defined by the user. I'm not convinced that a casual user, for whom this would be useful, would ever define these in advance. > with the list pre-configured for the ISP of the user (or some way to > configure that yourself). > > On the probe, run a webserver such that http://10.0.0.139 points you > to the list showing you a list of "yes"/"no"'s. This would mean that the probe offers some externally accessible services. That doesn't sound too scary for firewalled/NATed ones, but generally enabling this would mean handling permissions, ACLs and such. And a whole lot of probe capacity taken away for something that may never be used. One could drive this through the website, execute the tests on demand, but that wouldn't work while a genuine network problem is happening. > Advantages: > > * For the end user: if all items are yes, then that shows that there > is nothing wrong on the user side and no action has to be taken. > > * For the helpdesk when debugging the problem: the answer to a number > of routine questions is there, without having to explain how to > check things. I agree with these advantages. Still, we'll have to see if they outweigh the disadvantages. Cheers, Robert > Henk > > From henk at uijterwaal.nl Tue Dec 7 12:55:40 2010 From: henk at uijterwaal.nl (Henk Uijterwaal) Date: Tue, 07 Dec 2010 12:55:40 +0100 Subject: [atlas]While debugging my dad's network at home... In-Reply-To: <4CFE18AF.7060009@ripe.net> References: <4CEBFF96.6030209@CC.UniVie.ac.at> <4CFCE3C5.3080609@ripe.net> <4CFE18AF.7060009@ripe.net> Message-ID: <4CFE20BC.8020101@uijterwaal.nl> Hi, >> Anyway, what I think would be really cool for probe hosts is if the probe >> could give a little bit more information about the network where it is in >> and present that in a way understandable to the user. For example: >> >> * Probe has local address Yes/No >> * Probe sees local gateway " >> * Probe has Internet access >> * Pings to XX works >> * DNS query works >> * IMAP server responds >> * SMTP server responds >> * Popular website responds >> * SIP server responds >> * ... > > Note: there are a bunch of inputs here that would have to be pre-defined by > the user. I'm not convinced that a casual user, for whom this would be > useful, would ever define these in advance. The probe data is known for each ISP, so a probe can be pre-configured by an ISP. Lots of ISPs send modems to their users, the probe can be included in this shipment. Also, this particular ISP sends an engineer (for a fee) to the user to configure his connection. In that case, the probe can be configured on the spot. >> On the probe, run a webserver such that http://10.0.0.139 points you >> to the list showing you a list of "yes"/"no"'s. > > This would mean that the probe offers some externally accessible services. That is true. > One could drive this through the website, execute the tests on demand, but > that wouldn't work while a genuine network problem is happening. Well, yes, in this case you limit the test suite, though I still think that the remaining tests would be useful. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ I confirm today what I denied yesterday. Anonymous Politician. From marco.davids at sidn.nl Tue Dec 7 12:41:31 2010 From: marco.davids at sidn.nl (Marco Davids (SIDN)) Date: Tue, 7 Dec 2010 12:41:31 +0100 Subject: [atlas]option ntp-servers ? Message-ID: <4CFE1D6B.5030205@sidn.nl> Hi, Question: does the Atlas-probe obey to the 'option ntp-servers' DHCP option? If not, mine could be into trouble, since I don't allow outbound NTP-requests. (Sorry if this has been asked before, I am new to this list and haven't found the archive just yet) Regards, -- Marco From robert at ripe.net Wed Dec 8 09:05:07 2010 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 08 Dec 2010 09:05:07 +0100 Subject: [atlas]Upgrades today Message-ID: <4CFF3C33.5070605@ripe.net> Hi, Today we'll upgrade some of the central components of the system, including the UI. Please don't be surprised about service interruptions. Regards, Robert From robert at ripe.net Wed Dec 8 11:46:59 2010 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 08 Dec 2010 11:46:59 +0100 Subject: [atlas]Upgrades today In-Reply-To: <4CFF3C33.5070605@ripe.net> References: <4CFF3C33.5070605@ripe.net> Message-ID: <4CFF6223.3090604@ripe.net> On 2010.12.08. 9:05, Robert Kisteleki wrote: > Hi, > > Today we'll upgrade some of the central components of the system, including > the UI. Please don't be surprised about service interruptions. > > Regards, > Robert The upgrade is now finished. Some of the new features are listed below. Internal stuff: * most of the NTP problems have been solved by the new firmware version 3900 * probes can use IPv6 to connect to the central infrastructure, provided that their assigned controller also supports it. We'll be deploying IPv6 on more controllers in the near future. UI stuff: * We replaced the geo mapping backend, which solves most (if not all) of the "my town is not found" issues * One can now enlarge the probe registration and re-geolocate dialogs so it's easier to pick your exact spot on the map * The "probe status" page now loads the sections separately, and it loads a bit faster. You can reload each section separately using the small button on the right hand side of the section header. * We added an uptime graph to visualise the probe's uptime. Small connectivity gaps (disconnect periods) don't really show up on this, as they are are much shorter than the connected periods, but one can see bigger downtimes (if they happen). * We have better IPv4/IPv6 reporting in the top section We also added some internal enhancements so that we can have more/better reporting in the future. These changes are not (yet) visible to the users. Regards, Robert From joao at bondis.org Wed Dec 8 14:51:30 2010 From: joao at bondis.org (Joao Damas) Date: Wed, 8 Dec 2010 08:51:30 -0500 Subject: [atlas]Upgrades today In-Reply-To: <4CFF6223.3090604@ripe.net> References: <4CFF3C33.5070605@ripe.net> <4CFF6223.3090604@ripe.net> Message-ID: On 8 Dec 2010, at 05:46, Robert Kisteleki wrote: > On 2010.12.08. 9:05, Robert Kisteleki wrote: >> Hi, >> >> Today we'll upgrade some of the central components of the system, including >> the UI. Please don't be surprised about service interruptions. >> >> Regards, >> Robert > > The upgrade is now finished. Some of the new features are listed below. > > Internal stuff: > * most of the NTP problems have been solved by the new firmware version 3900 > * probes can use IPv6 to connect to the central infrastructure, provided > that their assigned controller also supports it. We'll be deploying IPv6 on > more controllers in the near future. that's nice! Will it do both IPv4 and IPv6 when available? From where my probe is, the IPv4 and the IPv6 path to amsterdam (or anywhere else) are quite different and so will the measurements be Joao From daniel.karrenberg at ripe.net Wed Dec 8 15:20:27 2010 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 8 Dec 2010 15:20:27 +0100 Subject: [atlas]Upgrades today In-Reply-To: References: <4CFF3C33.5070605@ripe.net> <4CFF6223.3090604@ripe.net> Message-ID: <20101208142027.GH404@reif.karrenberg.net> On 08.12 08:51, Joao Damas wrote: > > that's nice! Will it do both IPv4 and IPv6 when available? From where my probe is, the IPv4 and the IPv6 path to amsterdam (or anywhere else) are quite different and so will the measurements be The probes have always measured IPv6 when available. The new feature is that they can now talk to the RIPE Atlas infrastructure and report their results using IPv6. The rsults will be the same whether reported via IPv4 or IPv6, I would hope. ;-) :-) ;-) The funny thing is that it took much less effort than anticipated to make this happen. Hence it happened earlier than planned. Daniel From joao at bondis.org Wed Dec 8 15:22:24 2010 From: joao at bondis.org (Joao Damas) Date: Wed, 8 Dec 2010 09:22:24 -0500 Subject: [atlas]Upgrades today In-Reply-To: <20101208142027.GH404@reif.karrenberg.net> References: <4CFF3C33.5070605@ripe.net> <4CFF6223.3090604@ripe.net> <20101208142027.GH404@reif.karrenberg.net> Message-ID: <076A9994-D52D-4154-86D5-7E90174ECFB3@bondis.org> ah, OK, read it differently. Thanks for the clarification On 8 Dec 2010, at 09:20, Daniel Karrenberg wrote: > On 08.12 08:51, Joao Damas wrote: >> >> that's nice! Will it do both IPv4 and IPv6 when available? From where my probe is, the IPv4 and the IPv6 path to amsterdam (or anywhere else) are quite different and so will the measurements be > > The probes have always measured IPv6 when available. > The new feature is that they can now talk to the RIPE Atlas > infrastructure and report their results using IPv6. > The rsults will be the same whether reported via IPv4 > or IPv6, I would hope. ;-) :-) ;-) > > The funny thing is that it took much less effort than anticipated > to make this happen. Hence it happened earlier than planned. > > Daniel From marco.davids at sidn.nl Wed Dec 8 16:54:51 2010 From: marco.davids at sidn.nl (Marco Davids (SIDN)) Date: Wed, 8 Dec 2010 16:54:51 +0100 Subject: [atlas]Upgrades today In-Reply-To: <4CFF6223.3090604@ripe.net> References: <4CFF3C33.5070605@ripe.net> <4CFF6223.3090604@ripe.net> Message-ID: <4CFFAA4B.90603@sidn.nl> On 12/08/10 11:46, Robert Kisteleki wrote: > The upgrade is now finished. Some of the new features are listed below. Is it just me, or doesn't the new UI work well with Google Chrome? I can make it to the 'My probes' page, but when I click on one, nothing happens. Works well with Firefox though. -- Marco From robert at ripe.net Wed Dec 8 17:13:59 2010 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 08 Dec 2010 17:13:59 +0100 Subject: [atlas]Upgrades today In-Reply-To: <4CFFAA4B.90603@sidn.nl> References: <4CFF3C33.5070605@ripe.net> <4CFF6223.3090604@ripe.net> <4CFFAA4B.90603@sidn.nl> Message-ID: <4CFFAEC7.9020505@ripe.net> On 2010.12.08. 16:54, Marco Davids (SIDN) wrote: > On 12/08/10 11:46, Robert Kisteleki wrote: > >> The upgrade is now finished. Some of the new features are listed below. > > Is it just me, or doesn't the new UI work well with Google Chrome? > > I can make it to the 'My probes' page, but when I click on one, nothing > happens. > > Works well with Firefox though. > > -- > Marco We rolled out some changes today which also touched the JavaScript libraries behind the pages. The problem should be solved if you reload the page with the browser's reload button. I think it works in FF because you opened up the Atlas page in FF just now, therefore "reloaded" the page. HTH, Robert From antony at ripe.net Thu Dec 9 08:37:23 2010 From: antony at ripe.net (Antony Antony) Date: Thu, 9 Dec 2010 08:37:23 +0100 Subject: [atlas]option ntp-servers ? In-Reply-To: <4CFE1D6B.5030205@sidn.nl> References: <4CFE1D6B.5030205@sidn.nl> Message-ID: <20101209073723.GA20182@dog.ripe.net> Hi Marco, currently the probes use a static ntp server configuration; tt01.ripe.net. It don't use that dchp option. However, the option ntp-servers is an interesting one to try. Thanks for the tip. The probes also receive a time indications from the ncc servers. So if the ntp fails it will use these indications. The latest firmware should be able to keep a decent time O(1) even if the ntp fails. And it seems to work so far. If your probe still has a large time skew please drop a mail to atlas at ripe.net; I am curious to hear. regards, -antony On Tue, Dec 07, 2010 at 12:41:31PM +0100, Marco Davids (SIDN) wrote: > Hi, > > Question: does the Atlas-probe obey to the 'option ntp-servers' DHCP > option? If not, mine could be into trouble, since I don't allow outbound > NTP-requests. > > (Sorry if this has been asked before, I am new to this list and haven't > found the archive just yet) > > Regards, > > -- > Marco > > > > > From bengan at bag.org Thu Dec 9 10:54:49 2010 From: bengan at bag.org (Bengt =?iso-8859-1?q?G=F6rd=E9n?=) Date: Thu, 9 Dec 2010 10:54:49 +0100 Subject: [atlas]Upgrades today In-Reply-To: <4CFFAEC7.9020505@ripe.net> References: <4CFF3C33.5070605@ripe.net> <4CFFAA4B.90603@sidn.nl> <4CFFAEC7.9020505@ripe.net> Message-ID: <201012091054.50106.bengan@bag.org> onsdag 08 december 2010 17:13:59 skrev Robert Kisteleki: > On 2010.12.08. 16:54, Marco Davids (SIDN) wrote: > > On 12/08/10 11:46, Robert Kisteleki wrote: > >> The upgrade is now finished. Some of the new features are listed below. > > > > Is it just me, or doesn't the new UI work well with Google Chrome? > > > > I can make it to the 'My probes' page, but when I click on one, nothing > > happens. > > > > Works well with Firefox though. > > > > -- > > Marco > > We rolled out some changes today which also touched the JavaScript > libraries behind the pages. The problem should be solved if you reload the > page with the browser's reload button. > > I think it works in FF because you opened up the Atlas page in FF just now, > therefore "reloaded" the page. For me it didn't work with google chrome (7.0.517.8 dev) until I actively logged out and logged in again. /bengan From bengan at bag.org Thu Dec 9 11:27:16 2010 From: bengan at bag.org (Bengt =?iso-8859-1?q?G=F6rd=E9n?=) Date: Thu, 9 Dec 2010 11:27:16 +0100 Subject: [atlas]Feature request: tag downtime Message-ID: <201012091127.17014.bengan@bag.org> Hi, Would it be possible to make some tagging functionality on the web page due to reasons as downtime etc.? For me it would be nice due to maintenance or similar. It would also be a courtesy to the upstream network in the future event that the statistics would be public (or at least semi public). /bengan From mbehring at cisco.com Thu Dec 9 15:05:37 2010 From: mbehring at cisco.com (Michael H. Behringer) Date: Thu, 09 Dec 2010 15:05:37 +0100 Subject: [atlas]Feature request: tag downtime In-Reply-To: <201012091127.17014.bengan@bag.org> Message-ID: +1 This would make a lot of sense - and the resulting data much more useful. For example, can we distinguish a power outage from a local network outage? Michael On 09/12/2010 11:27, "Bengt G?rd?n" wrote: > Hi, > > Would it be possible to make some tagging functionality on the web page due to > reasons as downtime etc.? For me it would be nice due to maintenance or > similar. It would also be a courtesy to the upstream network in the future > event that the statistics would be public (or at least semi public). > > > /bengan > From florian at narrans.de Fri Dec 10 17:57:56 2010 From: florian at narrans.de (Florian Obser) Date: Fri, 10 Dec 2010 17:57:56 +0100 Subject: [atlas]Upgrades today In-Reply-To: <4CFF6223.3090604@ripe.net> References: <4CFF3C33.5070605@ripe.net> <4CFF6223.3090604@ripe.net> Message-ID: <4D025C14.7050407@narrans.de> Hi, On 12/08/2010 11:46 AM, Robert Kisteleki wrote: > On 2010.12.08. 9:05, Robert Kisteleki wrote: > * We have better IPv4/IPv6 reporting in the top section the two probes on which I have access (156, currently don't know the other id) say for IPv6: Gateway: Undetermined/Unknown DNS Resolver: Undetermined/Unknown The probes have IPv6 connectivity so it should know it's gateway. Because a third probe of a colleague also shows undetermined/unknown I'm guessing this isn't yet implemented, right? (If this should work and you need the other probe ids to check something I can provide them next week) Second question: Can the probe get IPv6 resolvers over dhcpv6? If this should work I'm going to look at deploying dhcpv6 just for the probes. ;) > > Regards, > Robert > Thanks, Florian From daniel.karrenberg at ripe.net Sat Dec 11 14:06:32 2010 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Sat, 11 Dec 2010 14:06:32 +0100 Subject: [atlas]Upgrades today In-Reply-To: <4D025C14.7050407@narrans.de> References: <4CFF3C33.5070605@ripe.net> <4CFF6223.3090604@ripe.net> <4D025C14.7050407@narrans.de> Message-ID: <20101211130632.GC404@reif.karrenberg.net> On 10.12 17:57, Florian Obser wrote: > ... > > Gateway: Undetermined/Unknown > DNS Resolver: Undetermined/Unknown > > The probes have IPv6 connectivity so it should know it's gateway. Indeed it does. > Because a third probe of a colleague also shows undetermined/unknown I'm > guessing this isn't yet implemented, right? (If this should work and you > need the other probe ids to check something I can provide them next week) You are right, we intended 'undetermined' to mean that we do not have it implemented. It is on our list but not regarded as high priority. That whole section is intended to help debugging connectivity problems. Since there do not appear to be many of those it moved to a lower priority. > Second question: Can the probe get IPv6 resolvers over dhcpv6? If this > should work I'm going to look at deploying dhcpv6 just for the probes. ;) We have not implemented dhcpv6. Remember we are running uCLinux on a box with 8MB RAM and no MMU. How important is this? Daniel From florian at narrans.de Sat Dec 11 17:43:37 2010 From: florian at narrans.de (Florian Obser) Date: Sat, 11 Dec 2010 17:43:37 +0100 Subject: [atlas]Upgrades today In-Reply-To: <20101211130632.GC404@reif.karrenberg.net> References: <4CFF3C33.5070605@ripe.net> <4CFF6223.3090604@ripe.net> <4D025C14.7050407@narrans.de> <20101211130632.GC404@reif.karrenberg.net> Message-ID: <4D03AA39.3020204@narrans.de> On 12/11/2010 02:06 PM, Daniel Karrenberg wrote: > On 10.12 17:57, Florian Obser wrote: [...] >> Second question: Can the probe get IPv6 resolvers over dhcpv6? If this >> should work I'm going to look at deploying dhcpv6 just for the probes. ;) > > We have not implemented dhcpv6. Remember we are running uCLinux on a box with > 8MB RAM and no MMU. How important is this? Yes, I understand that. As to "important" I don't know, probably not. My motivation is something like: "ripe gave me two pieces of equipment it's my job to keep it running and provide it the best environment I can." The web interface indicated that the probe might be able to resolve over IPv6 so I started looking into how to provide the resolver. Teh googles seems to indicate that dhcpv6 is the way to go. Apparently one can also transport resolver information in router advertisements. I'm a static address configuration server guy so I have no idea what I'm talking about here ;) Anyway, before spending an hour or so to get dhcphv6 to work I asked first to find out if this has even a chance to work. On the other hand I'm personally very interested in running a v6 only network. It turns out it's a bit more complicated then just publishing AAAA records ;) That's why I'm always looking if some new piece of equipment or software can work in my v6 only network. However it's probably more useful to not artificially cut the probe of from the v4 internet. > > Daniel > Thanks, Florian -- I remember yesterday, but the memory is in my head now. Was yesterday real? Or is it only the memory that is real? From rbarnes at bbn.com Mon Dec 13 05:27:44 2010 From: rbarnes at bbn.com (Richard L. Barnes) Date: Sun, 12 Dec 2010 23:27:44 -0500 Subject: [atlas]Moving a probe Message-ID: Hey guys, I have had a probe move from Columbia, Maryland, USA to Cambridge, Massachusetts, USA. How do I update the registered location? --Richard From bengan at bag.org Mon Dec 13 08:42:04 2010 From: bengan at bag.org (Bengt =?iso-8859-1?q?G=F6rd=E9n?=) Date: Mon, 13 Dec 2010 08:42:04 +0100 Subject: [atlas]Moving a probe In-Reply-To: References: Message-ID: <201012130842.04692.bengan@bag.org> m?ndag 13 december 2010 05:27:44 skrev Richard L. Barnes: > Hey guys, > > I have had a probe move from Columbia, Maryland, USA to Cambridge, > Massachusetts, USA. How do I update the registered location? If it's just the location information there is an icon at the far right side on the myprobe-pages, same row as the MAC-address. http://atlas.ripe.net/atlas/myprobes.html /bengan From marco.davids at sidn.nl Mon Dec 13 09:53:06 2010 From: marco.davids at sidn.nl (Marco Davids (SIDN)) Date: Mon, 13 Dec 2010 09:53:06 +0100 Subject: [atlas]RFC5006 Message-ID: <4D05DEF2.9010706@sidn.nl> Question: Do the Atlas probes support RFC5006 (RDNSS option)? If not, would that be an idea to implement? Regards, -- Marco From robert at ripe.net Mon Dec 13 13:13:44 2010 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 13 Dec 2010 13:13:44 +0100 Subject: [atlas]RFC5006 In-Reply-To: <4D05DEF2.9010706@sidn.nl> References: <4D05DEF2.9010706@sidn.nl> Message-ID: <4D060DF8.7060801@ripe.net> On 2010.12.13. 9:53, Marco Davids (SIDN) wrote: > Question: > > Do the Atlas probes support RFC5006 (RDNSS option)? > > If not, would that be an idea to implement? > > Regards, > I don't think there's a good chance for this in the close future :) Robert From joerg at dorchain.net Mon Dec 13 13:49:26 2010 From: joerg at dorchain.net (Joerg Dorchain) Date: Mon, 13 Dec 2010 13:49:26 +0100 Subject: [atlas]RFC5006 In-Reply-To: <4D060DF8.7060801@ripe.net> References: <4D05DEF2.9010706@sidn.nl> <4D060DF8.7060801@ripe.net> Message-ID: <20101213124926.GJ5739@Redstar.dorchain.net> On Mon, Dec 13, 2010 at 01:13:44PM +0100, Robert Kisteleki wrote: > On 2010.12.13. 9:53, Marco Davids (SIDN) wrote: > > Question: > > > > Do the Atlas probes support RFC5006 (RDNSS option)? > > > > If not, would that be an idea to implement? > > > > Regards, > > > > I don't think there's a good chance for this in the close future :) The daemon is there http://rdnssd.linkfanel.net/, so it is all a matter of priorities how many daemons fit the small box. Joerg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: Digital signature URL: From harald.karlsen at thelan.no Thu Dec 16 09:26:35 2010 From: harald.karlsen at thelan.no (Harald Firing Karlsen) Date: Thu, 16 Dec 2010 09:26:35 +0100 Subject: [atlas]Probe flapping Message-ID: <4D09CD3B.3080502@thelan.no> Hi, My RIPE Atlas probe (MAC: 00204AC8243A) started flapping last night and is continuing to flap. It have flapped about 90 times since midnight, do you have any known problems at the moment? -- Kind regards Harald Firing Karlsen From robert at ripe.net Thu Dec 16 10:05:53 2010 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 16 Dec 2010 10:05:53 +0100 Subject: [atlas]Probe flapping In-Reply-To: <4D09CD3B.3080502@thelan.no> References: <4D09CD3B.3080502@thelan.no> Message-ID: <4D09D671.3040608@ripe.net> On 2010.12.16. 9:26, Harald Firing Karlsen wrote: > Hi, > > My RIPE Atlas probe (MAC: 00204AC8243A) started flapping last night and is > continuing to flap. It have flapped about 90 times since midnight, do you > have any known problems at the moment? Hi, It seems that your probe is not the only one. We're looking into the details and will get back with an update. Cheers, Robert From marco.davids at sidn.nl Thu Dec 16 10:34:45 2010 From: marco.davids at sidn.nl (Marco Davids (SIDN)) Date: Thu, 16 Dec 2010 10:34:45 +0100 Subject: [atlas]Probe flapping In-Reply-To: <4D09D671.3040608@ripe.net> References: <4D09CD3B.3080502@thelan.no> <4D09D671.3040608@ripe.net> Message-ID: <4D09DD35.2050606@sidn.nl> Op 16-12-10 10:05, Robert Kisteleki schreef: > On 2010.12.16. 9:26, Harald Firing Karlsen wrote: >> >> My RIPE Atlas probe (MAC: 00204AC8243A) started flapping last night and is >> continuing to flap. It have flapped about 90 times since midnight, do you >> have any known problems at the moment? > > It seems that your probe is not the only one. We're looking into the details > and will get back with an update. UPC had maintenance last night, at least where I am (Arnhem - NL). Maybe that has something to do with it? My 'home-probe' (00:20:4A:BF:FD:C5) did not show any interruptions though. I run two probes, one at work, one at home. The one at work has been flapping since the start (00:20:4A:C8:22:A4). Don't know exactly why yet, so I am interested in the outcome of this. Regards, -- Marco From mbehring at cisco.com Thu Dec 16 11:05:28 2010 From: mbehring at cisco.com (Michael H. Behringer) Date: Thu, 16 Dec 2010 11:05:28 +0100 Subject: [atlas]Probe flapping In-Reply-To: <4D09D671.3040608@ripe.net> Message-ID: BTW, simple suggestion: in your "last 25 connections" it would be really nice to add two columns (marked with *): Connect at | Connected for* | Disconnect at: | Disconnected for* To display for what duration the probe was on/off. Would probably be done in a few mins, and would make this table much easier to read! Michael On 16/12/2010 10:05, "Robert Kisteleki" wrote: > On 2010.12.16. 9:26, Harald Firing Karlsen wrote: >> Hi, >> >> My RIPE Atlas probe (MAC: 00204AC8243A) started flapping last night and is >> continuing to flap. It have flapped about 90 times since midnight, do you >> have any known problems at the moment? > > Hi, > > It seems that your probe is not the only one. We're looking into the details > and will get back with an update. > > Cheers, > Robert > From robert at ripe.net Thu Dec 16 11:21:40 2010 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 16 Dec 2010 11:21:40 +0100 Subject: [atlas]Probe flapping In-Reply-To: References: Message-ID: <4D09E834.1020709@ripe.net> On 2010.12.16. 11:05, Michael H. Behringer wrote: > BTW, simple suggestion: in your "last 25 connections" it would be really > nice to add two columns (marked with *): > > Connect at | Connected for* | Disconnect at: | Disconnected for* > > To display for what duration the probe was on/off. > > Would probably be done in a few mins, and would make this table much easier > to read! > > Michael Yes, this seems to be a good idea. Robert From daniel.karrenberg at ripe.net Thu Dec 16 14:57:46 2010 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 16 Dec 2010 14:57:46 +0100 Subject: [atlas]Probe flapping In-Reply-To: <4D09D671.3040608@ripe.net> References: <4D09CD3B.3080502@thelan.no> <4D09D671.3040608@ripe.net> Message-ID: <20101216135746.GR377@reif.karrenberg.net> Intermediate update to keep those interested informed. I am writing this to keep the engineers free to work the problem. I do not know nitty gritty details, so this is a general overview. No conclusions yet. Architecture: After registering with the RIPE Atlas network the probes are connected to "controllers" that handle requests to/from the probes. The architecture allows probes to use any controller in the system. Probes are distributed among controllers according to geographic and load balancing heuristics at the moment. We have four controllers at the moment: 1 in Germany on a dedicated server: jonin 1 in the US on a dedicated server: carson 2 in NL on RIPE NCC VMs: caldwell and zelenka You can see the number of probes associated with each controller and some other details on https://atlas.ripe.net/statistics This page is updated hourly. What happened: This morning zelenka was in standby and ronin started disassociating probes in a massive way. We do not know the root cause of this. The most likely cause so far is a connectivity problem but we are investigating with an open mind. The system reacted as designed and the probes dropped by ronin started to register with caldwell. Unfortunately caldwell became overloaded by this both because of its physical limitations and because of an unfortunate database configuration error. Probes associated to carson were not affected. What we are doing: We brought up Zelenka but as Murphy dictates the RIPE NCC firewall prevented probes from reaching it. This has been fixed and zelenka is now picking up probes. We working hard to fix a lot of minor problems uncovered by this and to get all probes re-connected and their data backlog processed. What we have learned so far: We need a larger safety margin in the capacity of the controllers vs the number of deployed probes. We will start moving caldwell and zelenka onto physical machines outside of firewalls and other complications. We also need to exercise moving probes among controllers and verify that the safety margin exists in reality. Personally I regard all this as normal teehting problems in a distributed computing deployment. So far the architecture is holding up well. Just the implementation has some flaws. Plwase bear with us. If anyone has suggestions for high quality hosting of controllers in the RIPE region, please drop me and Robert a private mail. Daniel From rbarnes at bbn.com Fri Dec 17 01:39:33 2010 From: rbarnes at bbn.com (Richard L. Barnes) Date: Thu, 16 Dec 2010 19:39:33 -0500 Subject: [atlas]Probe flapping In-Reply-To: <4D09CD3B.3080502@thelan.no> References: <4D09CD3B.3080502@thelan.no> Message-ID: <3D5C7141-6097-44CF-B4EE-E3FBF63AA72B@bbn.com> My home probe had been flapping a lot since I first installed it. But on Tuesday, I swapped out the router it's connected to * and it's been fine ever since **. I think it's the fact that the new router supports IPv6 :) --Richard * Before: Linksys WRT54GL running DD-WRT. After: Lenovo x61 running Ubuntu 10.10. ** Except for a single, isolated 30-minute down time On Dec 16, 2010, at 3:26 AM, Harald Firing Karlsen wrote: > Hi, > > My RIPE Atlas probe (MAC: 00204AC8243A) started flapping last night and is continuing to flap. It have flapped about 90 times since midnight, do you have any known problems at the moment? > > -- > Kind regards > Harald Firing Karlsen > > From robert at ripe.net Fri Dec 17 09:54:07 2010 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 17 Dec 2010 09:54:07 +0100 Subject: [atlas]Probe flapping In-Reply-To: <3D5C7141-6097-44CF-B4EE-E3FBF63AA72B@bbn.com> References: <4D09CD3B.3080502@thelan.no> <3D5C7141-6097-44CF-B4EE-E3FBF63AA72B@bbn.com> Message-ID: <4D0B252F.6020106@ripe.net> Thanks Richard for sharing this. What we have observed so far is that in some installations (a few percent of them) the probe does indeed flap in a 5-15m, sometimes up to 45m cycle. In most of these cases the probe doesn't succeed with the common traceroute at all. In one case, we could verify that this was not specific to the probe, a normal laptop showed the same behavior. Maybe we could ask the hosts of these probes to tell us what kind of home router they have, to see if there are common ones. Cheers, Robert On 2010.12.17. 1:39, Richard L. Barnes wrote: > My home probe had been flapping a lot since I first installed it. But on Tuesday, I swapped out the router it's connected to * and it's been fine ever since **. I think it's the fact that the new router supports IPv6 :) > > --Richard > > * Before: Linksys WRT54GL running DD-WRT. After: Lenovo x61 running Ubuntu 10.10. > ** Except for a single, isolated 30-minute down time > > > > On Dec 16, 2010, at 3:26 AM, Harald Firing Karlsen wrote: > >> Hi, >> >> My RIPE Atlas probe (MAC: 00204AC8243A) started flapping last night and is continuing to flap. It have flapped about 90 times since midnight, do you have any known problems at the moment? >> >> -- >> Kind regards >> Harald Firing Karlsen >> >> > From mark at dranse.com Fri Dec 17 10:23:01 2010 From: mark at dranse.com (Mark Dranse) Date: Fri, 17 Dec 2010 10:23:01 +0100 Subject: [atlas]Probe flapping In-Reply-To: <4D0B252F.6020106@ripe.net> References: <4D09CD3B.3080502@thelan.no> <3D5C7141-6097-44CF-B4EE-E3FBF63AA72B@bbn.com> <4D0B252F.6020106@ripe.net> Message-ID: On Fri, Dec 17, 2010 at 9:54 AM, Robert Kisteleki wrote: > Maybe we could ask the hosts of these probes to tell us what kind of home > router they have, to see if there are common ones. Perhaps this could be a standard question in the probe setup / account admin page? -- Mark Dranse mark at dranse.com From robert at ripe.net Fri Dec 17 10:34:39 2010 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 17 Dec 2010 10:34:39 +0100 Subject: [atlas]Probe flapping In-Reply-To: References: <4D09CD3B.3080502@thelan.no> <3D5C7141-6097-44CF-B4EE-E3FBF63AA72B@bbn.com> <4D0B252F.6020106@ripe.net> Message-ID: <4D0B2EAF.7080702@ripe.net> On 2010.12.17. 10:23, Mark Dranse wrote: > On Fri, Dec 17, 2010 at 9:54 AM, Robert Kisteleki wrote: >> Maybe we could ask the hosts of these probes to tell us what kind of home >> router they have, to see if there are common ones. > > Perhaps this could be a standard question in the probe setup / account > admin page? > That's too smart, I couldn't have thought of that :-) Robert From robert at ripe.net Fri Dec 17 12:09:19 2010 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 17 Dec 2010 12:09:19 +0100 Subject: [atlas]Probe flapping In-Reply-To: <20101216135746.GR377@reif.karrenberg.net> References: <4D09CD3B.3080502@thelan.no> <4D09D671.3040608@ripe.net> <20101216135746.GR377@reif.karrenberg.net> Message-ID: <4D0B44DF.10904@ripe.net> Dear All, Here's an update to Daniel's message from yesterday. As Daniel mentioned, on Wednesday evening our system started to migrate the probes away from a particular controller (ronin, in DE). We have a strong suspicion on why this happened, but it's not confirmed so I'm not going to publicly speculate :-) In any case, since we don't yet have enough spare capacity to handle this situation, another controller was overloaded. We needed to fix the internal databases on these controllers, which took some time. We were able to bring the system back to a stable state by the afternoon. This morning we revived some probes (25 or so) which were in a limbo -- they were not properly connected. We forced them to re-connect, so they are fine now. There are still some of them, like 10 or so, which are not connected (down) so we can't really help those from here. If your probe was working properly before Wednesday, but now is down, then please power cycle it (using the USB power) and it will very likely come back fine. Probes in the US (and Asia, very likely) were not affected, as they have a local controller on the west coast, which was not involved. That's because the system really doesn't like to send European probes to it, it's too far. Let us know if there's anything else not working properly, so that we can look into it. Regards, Robert On 2010.12.16. 14:57, Daniel Karrenberg wrote: > > Intermediate update to keep those interested informed. > I am writing this to keep the engineers free to work > the problem. I do not know nitty gritty details, so > this is a general overview. [...] From marco.davids at sidn.nl Fri Dec 17 12:38:17 2010 From: marco.davids at sidn.nl (Marco Davids (SIDN)) Date: Fri, 17 Dec 2010 12:38:17 +0100 Subject: [atlas]Question about security? Message-ID: <4D0B4BA9.2010107@sidn.nl> Hi, So how does security on the Atlas portal work? Reason for asking is that I changed the password from home yesterday, but when i logged in from work this morning, i was not asked for the new password. Maybe some kind of sessionid cookie with a long expiry time? Is that safe enough? Regards, -- Marco From robert at ripe.net Fri Dec 17 15:00:45 2010 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 17 Dec 2010 15:00:45 +0100 Subject: [atlas]Question about security? In-Reply-To: <4D0B4BA9.2010107@sidn.nl> References: <4D0B4BA9.2010107@sidn.nl> Message-ID: <4D0B6D0D.80309@ripe.net> On 2010.12.17. 12:38, Marco Davids (SIDN) wrote: > Hi, > > So how does security on the Atlas portal work? > > Reason for asking is that I changed the password from home yesterday, > but when i logged in from work this morning, i was not asked for the new > password. "logged in" or "kept on using the existing session"? I could see the later one but the former one would be a surprise. > Maybe some kind of sessionid cookie with a long expiry time? That'd be my answer; see above. > Is that safe enough? I guess it's a tradeoff between usability and security, as always. I don't know from the top of my head how long current sessions live, but I'm sure we could decrease the value until it becomes an annoyance :-) Cheers, Robert > Regards, From rbarnes at bbn.com Fri Dec 17 16:29:00 2010 From: rbarnes at bbn.com (Richard L. Barnes) Date: Fri, 17 Dec 2010 10:29:00 -0500 Subject: [atlas]Probe flapping In-Reply-To: <4D0B44DF.10904@ripe.net> References: <4D09CD3B.3080502@thelan.no> <4D09D671.3040608@ripe.net> <20101216135746.GR377@reif.karrenberg.net> <4D0B44DF.10904@ripe.net> Message-ID: Also interesting: This event is pretty clearly visible in the "probe up count" graph: On Dec 17, 2010, at 6:09 AM, Robert Kisteleki wrote: > Dear All, > > Here's an update to Daniel's message from yesterday. > > As Daniel mentioned, on Wednesday evening our system started to migrate the > probes away from a particular controller (ronin, in DE). We have a strong > suspicion on why this happened, but it's not confirmed so I'm not going to > publicly speculate :-) In any case, since we don't yet have enough spare > capacity to handle this situation, another controller was overloaded. > > We needed to fix the internal databases on these controllers, which took > some time. We were able to bring the system back to a stable state by the > afternoon. > > This morning we revived some probes (25 or so) which were in a limbo -- they > were not properly connected. We forced them to re-connect, so they are fine > now. There are still some of them, like 10 or so, which are not connected > (down) so we can't really help those from here. If your probe was working > properly before Wednesday, but now is down, then please power cycle it > (using the USB power) and it will very likely come back fine. > > Probes in the US (and Asia, very likely) were not affected, as they have a > local controller on the west coast, which was not involved. That's because > the system really doesn't like to send European probes to it, it's too far. > > Let us know if there's anything else not working properly, so that we can > look into it. > > Regards, > Robert > > > On 2010.12.16. 14:57, Daniel Karrenberg wrote: >> >> Intermediate update to keep those interested informed. >> I am writing this to keep the engineers free to work >> the problem. I do not know nitty gritty details, so >> this is a general overview. > > [...] > From Woeber at CC.UniVie.ac.at Fri Dec 17 17:09:14 2010 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 17 Dec 2010 16:09:14 +0000 Subject: [atlas]Probe flapping In-Reply-To: <4D0B44DF.10904@ripe.net> References: <4D09CD3B.3080502@thelan.no> <4D09D671.3040608@ripe.net> <20101216135746.GR377@reif.karrenberg.net> <4D0B44DF.10904@ripe.net> Message-ID: <4D0B8B2A.2060708@CC.UniVie.ac.at> Robert Kisteleki wrote: > This morning we revived some probes (25 or so) which were in a limbo -- they > were not properly connected. We forced them to re-connect, so they are fine > now. It looks like both of my babies were affected, living in completely different networks (IDs 414 and 466). Both of them seem to got turned away at 2010-12-16 08:14:01 UTC and 2010-12-16 08:14:02 UTC. They came back at 2010-12-17 07:55:23 UTC and 2010-12-17 07:53:59 UTC respectively (without any intervention on my end). Just fyi, Wilfried From robert at ripe.net Fri Dec 17 18:17:35 2010 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 17 Dec 2010 18:17:35 +0100 Subject: [atlas]Probe flapping In-Reply-To: References: <4D09CD3B.3080502@thelan.no> <4D09D671.3040608@ripe.net> <20101216135746.GR377@reif.karrenberg.net> <4D0B44DF.10904@ripe.net> Message-ID: <4D0B9B2F.7020502@ripe.net> On 2010.12.17. 16:29, Richard L. Barnes wrote: > Also interesting: This event is pretty clearly visible in the "probe up count" graph: > Indeed. There's also a more detailed statistics page, which gives interesting hints for those who are interested in more details: https://atlas.ripe.net/statistics We don't plan to apply cosmetics to the graphs :) so you can see the event in its full extent. Robert From aftabs at cyber.net.pk Sun Dec 19 09:16:33 2010 From: aftabs at cyber.net.pk (Aftab A. Siddiqui) Date: Sun, 19 Dec 2010 13:16:33 +0500 Subject: [atlas]Probe flapping In-Reply-To: <4D0B44DF.10904@ripe.net> References: <4D09CD3B.3080502@thelan.no> <4D09D671.3040608@ripe.net> <20101216135746.GR377@reif.karrenberg.net> <4D0B44DF.10904@ripe.net> Message-ID: <010901cb9f55$0ea65750$2bf305f0$@net.pk> Hi Robert, It seems like a probe (ID: 303) in Asia is still having disconnection problem. Connect at: Disconnect at: 2010-12-19 06:07:29 UTC (still connected) 2010-12-18 17:32:11 UTC 2010-12-19 06:06:49 UTC 2010-12-18 17:15:28 UTC 2010-12-18 17:30:54 UTC 2010-12-18 10:26:52 UTC 2010-12-18 17:13:24 UTC Or is this suppose to be normal? But every disconnect - connect session has 1-2min gap. Best Wishes, Aftab A. Siddiqui -----Original Message----- From: ripe-atlas-admin at ripe.net [mailto:ripe-atlas-admin at ripe.net] On Behalf Of Robert Kisteleki Sent: Friday, December 17, 2010 4:09 PM To: ripe-atlas at ripe.net Subject: Re: [atlas]Probe flapping Dear All, Here's an update to Daniel's message from yesterday. As Daniel mentioned, on Wednesday evening our system started to migrate the probes away from a particular controller (ronin, in DE). We have a strong suspicion on why this happened, but it's not confirmed so I'm not going to publicly speculate :-) In any case, since we don't yet have enough spare capacity to handle this situation, another controller was overloaded. We needed to fix the internal databases on these controllers, which took some time. We were able to bring the system back to a stable state by the afternoon. This morning we revived some probes (25 or so) which were in a limbo -- they were not properly connected. We forced them to re-connect, so they are fine now. There are still some of them, like 10 or so, which are not connected (down) so we can't really help those from here. If your probe was working properly before Wednesday, but now is down, then please power cycle it (using the USB power) and it will very likely come back fine. Probes in the US (and Asia, very likely) were not affected, as they have a local controller on the west coast, which was not involved. That's because the system really doesn't like to send European probes to it, it's too far. Let us know if there's anything else not working properly, so that we can look into it. Regards, Robert On 2010.12.16. 14:57, Daniel Karrenberg wrote: > > Intermediate update to keep those interested informed. > I am writing this to keep the engineers free to work > the problem. I do not know nitty gritty details, so > this is a general overview. [...] From astrikos at ripe.net Mon Dec 20 17:21:00 2010 From: astrikos at ripe.net (Andreas Strikos) Date: Mon, 20 Dec 2010 17:21:00 +0100 Subject: [atlas]Probe flapping In-Reply-To: <010901cb9f55$0ea65750$2bf305f0$@net.pk> References: <4D09CD3B.3080502@thelan.no> <4D09D671.3040608@ripe.net> <20101216135746.GR377@reif.karrenberg.net> <4D0B44DF.10904@ripe.net> <010901cb9f55$0ea65750$2bf305f0$@net.pk> Message-ID: Hi Aftab, Although your probe is located in Asia, it is still connected to one of our controller in Europe because this part of Asia is closer to Germany than west coast of US :) Since Friday our system is fully functional, so I think it's your network that makes your probe flapping. The small gap is normal since after the probe disconnects it takes some time to re-connect. From what i can see from our history your probe was disconnected quit often from the beginning :) Regards, Andreas Strikos On Dec 19, 2010, at 9:16 AM, Aftab A. Siddiqui wrote: > Hi Robert, > > It seems like a probe (ID: 303) in Asia is still having disconnection > problem. > > Connect at: Disconnect at: > 2010-12-19 06:07:29 UTC (still connected) > 2010-12-18 17:32:11 UTC 2010-12-19 06:06:49 UTC > 2010-12-18 17:15:28 UTC 2010-12-18 17:30:54 UTC > 2010-12-18 10:26:52 UTC 2010-12-18 17:13:24 UTC > > Or is this suppose to be normal? But every disconnect - connect session has > 1-2min gap. > > Best Wishes, > > Aftab A. Siddiqui > > -----Original Message----- > From: ripe-atlas-admin at ripe.net [mailto:ripe-atlas-admin at ripe.net] On Behalf > Of Robert Kisteleki > Sent: Friday, December 17, 2010 4:09 PM > To: ripe-atlas at ripe.net > Subject: Re: [atlas]Probe flapping > > Dear All, > > Here's an update to Daniel's message from yesterday. > > As Daniel mentioned, on Wednesday evening our system started to migrate the > probes away from a particular controller (ronin, in DE). We have a strong > suspicion on why this happened, but it's not confirmed so I'm not going to > publicly speculate :-) In any case, since we don't yet have enough spare > capacity to handle this situation, another controller was overloaded. > > We needed to fix the internal databases on these controllers, which took > some time. We were able to bring the system back to a stable state by the > afternoon. > > This morning we revived some probes (25 or so) which were in a limbo -- they > were not properly connected. We forced them to re-connect, so they are fine > now. There are still some of them, like 10 or so, which are not connected > (down) so we can't really help those from here. If your probe was working > properly before Wednesday, but now is down, then please power cycle it > (using the USB power) and it will very likely come back fine. > > Probes in the US (and Asia, very likely) were not affected, as they have a > local controller on the west coast, which was not involved. That's because > the system really doesn't like to send European probes to it, it's too far. > > Let us know if there's anything else not working properly, so that we can > look into it. > > Regards, > Robert > > > On 2010.12.16. 14:57, Daniel Karrenberg wrote: >> >> Intermediate update to keep those interested informed. >> I am writing this to keep the engineers free to work >> the problem. I do not know nitty gritty details, so >> this is a general overview. > > [...] > From aftabs at cyber.net.pk Mon Dec 20 18:26:22 2010 From: aftabs at cyber.net.pk (Aftab A. Siddiqui) Date: Mon, 20 Dec 2010 22:26:22 +0500 Subject: [atlas]Probe flapping In-Reply-To: References: <4D09CD3B.3080502@thelan.no> <4D09D671.3040608@ripe.net> <20101216135746.GR377@reif.karrenberg.net> <4D0B44DF.10904@ripe.net> <010901cb9f55$0ea65750$2bf305f0$@net.pk> Message-ID: Hi Andreas, I thought connecting it directly on the distribution network will make it The stable one :( well if everything is fine at your end than I'll try to change the upstream for this subnet. Is it possible to change the controller my probe is connected to and can you share the controller IPs? If it's not against the policy. Best Wishes, Aftab A. Siddiqui ------ Sent from my iPhone *G On Dec 20, 2010, at 9:21 PM, Andreas Strikos wrote: > Hi Aftab, > > Although your probe is located in Asia, it is still connected to one > of our controller in Europe because this part of Asia is closer to > Germany than west coast of US :) > Since Friday our system is fully functional, so I think it's your > network that makes your probe flapping. The small gap is normal > since after the probe disconnects it takes some time to re-connect. > From what i can see from our history your probe was disconnected > quit often from the beginning :) > > > Regards, > Andreas Strikos > > On Dec 19, 2010, at 9:16 AM, Aftab A. Siddiqui wrote: > >> Hi Robert, >> >> It seems like a probe (ID: 303) in Asia is still having disconnection >> problem. >> >> Connect at: Disconnect at: >> 2010-12-19 06:07:29 UTC (still connected) >> 2010-12-18 17:32:11 UTC 2010-12-19 06:06:49 UTC >> 2010-12-18 17:15:28 UTC 2010-12-18 17:30:54 UTC >> 2010-12-18 10:26:52 UTC 2010-12-18 17:13:24 UTC >> >> Or is this suppose to be normal? But every disconnect - connect >> session has >> 1-2min gap. >> >> Best Wishes, >> >> Aftab A. Siddiqui >> >> -----Original Message----- >> From: ripe-atlas-admin at ripe.net [mailto:ripe-atlas-admin at ripe.net] >> On Behalf >> Of Robert Kisteleki >> Sent: Friday, December 17, 2010 4:09 PM >> To: ripe-atlas at ripe.net >> Subject: Re: [atlas]Probe flapping >> >> Dear All, >> >> Here's an update to Daniel's message from yesterday. >> >> As Daniel mentioned, on Wednesday evening our system started to >> migrate the >> probes away from a particular controller (ronin, in DE). We have a >> strong >> suspicion on why this happened, but it's not confirmed so I'm not >> going to >> publicly speculate :-) In any case, since we don't yet have enough >> spare >> capacity to handle this situation, another controller was overloaded. >> >> We needed to fix the internal databases on these controllers, which >> took >> some time. We were able to bring the system back to a stable state >> by the >> afternoon. >> >> This morning we revived some probes (25 or so) which were in a >> limbo -- they >> were not properly connected. We forced them to re-connect, so they >> are fine >> now. There are still some of them, like 10 or so, which are not >> connected >> (down) so we can't really help those from here. If your probe was >> working >> properly before Wednesday, but now is down, then please power cycle >> it >> (using the USB power) and it will very likely come back fine. >> >> Probes in the US (and Asia, very likely) were not affected, as they >> have a >> local controller on the west coast, which was not involved. That's >> because >> the system really doesn't like to send European probes to it, it's >> too far. >> >> Let us know if there's anything else not working properly, so that >> we can >> look into it. >> >> Regards, >> Robert >> >> >> On 2010.12.16. 14:57, Daniel Karrenberg wrote: >>> >>> Intermediate update to keep those interested informed. >>> I am writing this to keep the engineers free to work >>> the problem. I do not know nitty gritty details, so >>> this is a general overview. >> >> [...] >> > From astrikos at ripe.net Tue Dec 21 09:33:05 2010 From: astrikos at ripe.net (Andreas Strikos) Date: Tue, 21 Dec 2010 09:33:05 +0100 Subject: [atlas]Probe flapping In-Reply-To: References: <4D09CD3B.3080502@thelan.no> <4D09D671.3040608@ripe.net> <20101216135746.GR377@reif.karrenberg.net> <4D0B44DF.10904@ripe.net> <010901cb9f55$0ea65750$2bf305f0$@net.pk> Message-ID: Hi Aftab, No it's not possible to change the controller your probe is connected to. The system is choosing the best controller for your probe based on the geolocation and some additional criteria. I guess you can see the ip of the controller your probe is connected to. It's not a secret :) Regards, Andreas On Dec 20, 2010, at 6:26 PM, Aftab A. Siddiqui wrote: > Hi Andreas, > I thought connecting it directly on the distribution network will make it The stable one :( well if everything is fine at your end than I'll try to change the upstream for this subnet. > > Is it possible to change the controller my probe is connected to and can you share the controller IPs? If it's not against the policy. > > Best Wishes, > Aftab A. Siddiqui > > ------ > Sent from my iPhone *G > > On Dec 20, 2010, at 9:21 PM, Andreas Strikos wrote: > >> Hi Aftab, >> >> Although your probe is located in Asia, it is still connected to one of our controller in Europe because this part of Asia is closer to Germany than west coast of US :) >> Since Friday our system is fully functional, so I think it's your network that makes your probe flapping. The small gap is normal since after the probe disconnects it takes some time to re-connect. >> From what i can see from our history your probe was disconnected quit often from the beginning :) >> >> >> Regards, >> Andreas Strikos >> >> On Dec 19, 2010, at 9:16 AM, Aftab A. Siddiqui wrote: >> >>> Hi Robert, >>> >>> It seems like a probe (ID: 303) in Asia is still having disconnection >>> problem. >>> >>> Connect at: Disconnect at: >>> 2010-12-19 06:07:29 UTC (still connected) >>> 2010-12-18 17:32:11 UTC 2010-12-19 06:06:49 UTC >>> 2010-12-18 17:15:28 UTC 2010-12-18 17:30:54 UTC >>> 2010-12-18 10:26:52 UTC 2010-12-18 17:13:24 UTC >>> >>> Or is this suppose to be normal? But every disconnect - connect session has >>> 1-2min gap. >>> >>> Best Wishes, >>> >>> Aftab A. Siddiqui >>> >>> -----Original Message----- >>> From: ripe-atlas-admin at ripe.net [mailto:ripe-atlas-admin at ripe.net] On Behalf >>> Of Robert Kisteleki >>> Sent: Friday, December 17, 2010 4:09 PM >>> To: ripe-atlas at ripe.net >>> Subject: Re: [atlas]Probe flapping >>> >>> Dear All, >>> >>> Here's an update to Daniel's message from yesterday. >>> >>> As Daniel mentioned, on Wednesday evening our system started to migrate the >>> probes away from a particular controller (ronin, in DE). We have a strong >>> suspicion on why this happened, but it's not confirmed so I'm not going to >>> publicly speculate :-) In any case, since we don't yet have enough spare >>> capacity to handle this situation, another controller was overloaded. >>> >>> We needed to fix the internal databases on these controllers, which took >>> some time. We were able to bring the system back to a stable state by the >>> afternoon. >>> >>> This morning we revived some probes (25 or so) which were in a limbo -- they >>> were not properly connected. We forced them to re-connect, so they are fine >>> now. There are still some of them, like 10 or so, which are not connected >>> (down) so we can't really help those from here. If your probe was working >>> properly before Wednesday, but now is down, then please power cycle it >>> (using the USB power) and it will very likely come back fine. >>> >>> Probes in the US (and Asia, very likely) were not affected, as they have a >>> local controller on the west coast, which was not involved. That's because >>> the system really doesn't like to send European probes to it, it's too far. >>> >>> Let us know if there's anything else not working properly, so that we can >>> look into it. >>> >>> Regards, >>> Robert >>> >>> >>> On 2010.12.16. 14:57, Daniel Karrenberg wrote: >>>> >>>> Intermediate update to keep those interested informed. >>>> I am writing this to keep the engineers free to work >>>> the problem. I do not know nitty gritty details, so >>>> this is a general overview. >>> >>> [...] >>> >> > From Woeber at CC.UniVie.ac.at Tue Dec 21 18:23:25 2010 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 21 Dec 2010 17:23:25 +0000 Subject: [atlas]trying to collect basic info about the architecture Message-ID: <4D10E28D.5060708@CC.UniVie.ac.at> Dear ATLAS-Team, I am aware of the fact that my poking and attempt to collect information may be premature, as the whole thing is still very much in development... Still, I think it would be useful for many of us to have some sort of "snapshot" regarding the behaviour of the probes and the framework they live in. The initial basic questions on my end would be: What does the term "connect", to one of the controllers, really mean in terms of TCP/IP Lingo? Like: does the thing open a TCP hose to the controller? Is communication based on UDP and/or on TCP? Is the probe capable of bufffering data for a while if connectivity to the Net is still there, but not to the controller(s)? Is there any means to (locally, on the same subnet, or even remotely) trigger or "reboot" a probe, other than disconnecting power (which means physical access required)? I am also wondering how much of this stuff is available already and where to collect it - the 'labs pool may be more appropriate than this list? Thanks to everyone who was and is involved in this fascinating project, with season's greatings and a happy (2010)++ to everyone, Wilfried. PS: for a future version of the probes or as an optional gadget: how about making the thing capable of feeding it off 2 different power plugs, e.g. a primary and a UPS? :-) From Woeber at CC.UniVie.ac.at Tue Dec 21 18:30:29 2010 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 21 Dec 2010 17:30:29 +0000 Subject: [atlas]how big is the limitation imposed by the req. for DHCPv4? Message-ID: <4D10E435.8080407@CC.UniVie.ac.at> Folks, I'd like to collect input from those interested in principle to deploy groups of probes within their operational environment(s), regarding the requirement to have DHCPv4 available in order to configure the probe (for IPv4). I already came up with a coupe of locations and environments, where such a cute thing would be nice to have, but in most (if not all) of these places, there is no DHCP available (and for good reasons). As an aside to the developers, would it be feasable to connect the probe in network A, configure it for the destination network and then move it over to network B for its happy life? Cheers, Wilfried. From emile.aben at ripe.net Wed Dec 22 12:09:28 2010 From: emile.aben at ripe.net (Emile Aben) Date: Wed, 22 Dec 2010 12:09:28 +0100 Subject: [atlas]trying to collect basic info about the architecture In-Reply-To: <4D10E28D.5060708@CC.UniVie.ac.at> References: <4D10E28D.5060708@CC.UniVie.ac.at> Message-ID: <4D11DC68.8070906@ripe.net> On 21/12/2010 18:23, Wilfried Woeber, UniVie/ACOnet wrote: > Dear ATLAS-Team, > > I am aware of the fact that my poking and attempt to collect information > may be premature, as the whole thing is still very much in development... > > Still, I think it would be useful for many of us to have some sort of > "snapshot" regarding the behaviour of the probes and the framework they > live in. > > The initial basic questions on my end would be: > > What does the term "connect", to one of the controllers, really mean in > terms of TCP/IP Lingo? Like: does the thing open a TCP hose to the controller? > Is communication based on UDP and/or on TCP? It's a single SSH connection on TCP/443. > Is the probe capable of bufffering data for a while if connectivity to the > Net is still there, but not to the controller(s)? Yes, the probes have a limited capability to do so. I think it's currently capable of storing a couple of minutes worth of data. > Is there any means to (locally, on the same subnet, or even remotely) > trigger or "reboot" a probe, other than disconnecting power (which means > physical access required)? Currently there is no way for users to reboot a probe other then disconnecting power. If this is a capability that people would like to have, we could look into ways we could make that happen. > I am also wondering how much of this stuff is available already and where > to collect it - the 'labs pool may be more appropriate than this list? The presentation at RIPE61 and the RIPE Labs articles are what we have this far. If there is a need for more documentation at this point, we'll listen of course, but that would also take resources away from developments. > Thanks to everyone who was and is involved in this fascinating project, > with season's greatings and a happy (2010)++ to everyone, > Wilfried. Best wishes from a snowy Amsterdam, on behalf of the whole team! Emile Aben RIPE NCC > PS: for a future version of the probes or as an optional gadget: > how about making the thing capable of feeding it off 2 different > power plugs, e.g. a primary and a UPS? :-) The power-input is USB, so if you can make whatever feeds power to the USB redundant you effectively accomplish what I think you want. From emile.aben at ripe.net Wed Dec 22 12:12:22 2010 From: emile.aben at ripe.net (Emile Aben) Date: Wed, 22 Dec 2010 12:12:22 +0100 Subject: [atlas]how big is the limitation imposed by the req. for DHCPv4? In-Reply-To: <4D10E435.8080407@CC.UniVie.ac.at> References: <4D10E435.8080407@CC.UniVie.ac.at> Message-ID: <4D11DD16.9040005@ripe.net> On 21/12/2010 18:30, Wilfried Woeber, UniVie/ACOnet wrote: > Folks, > > I'd like to collect input from those interested in principle to deploy > groups of probes within their operational environment(s), regarding the > requirement to have DHCPv4 available in order to configure the probe (for > IPv4). > > I already came up with a coupe of locations and environments, where such > a cute thing would be nice to have, but in most (if not all) of these places, > there is no DHCP available (and for good reasons). > > As an aside to the developers, would it be feasable to connect the probe > in network A, configure it for the destination network and then move it > over to network B for its happy life? Yes, this is something that was requested by more people, so it is on our list. Our current thinking is along the same lines as what you suggest above. best regards, Emile Aben RIPE NCC From Woeber at CC.UniVie.ac.at Wed Dec 22 12:28:17 2010 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 22 Dec 2010 11:28:17 +0000 Subject: [atlas]DHCP behaviour of the probe on startup Message-ID: <4D11E0D1.5020801@CC.UniVie.ac.at> Hi folks, while debugging some non-probe-related issues here at my ADSL'd net @home, I was told by the provider's techie, that the probe tries to grab *two* addresses at startup. He was monitoring the ARP table in the router, saw a DHCP request and the address assigned by the DHCP Server, and immediately asfterwards, the probe sent a request for an additional address, which was granted by the server. Trying to verify that, I later found out that I can ping the probe only on the second address. [1] Has anyone seen such a behaviour? Unfortunately, I don't have access to the router (cisco 800 series) as it is fully managed by the ISP, and for my other probe we had the IP-Address hard-wired into the DHCP server for the MAC address. Thanks, Wilfried. [1] this is particularly nasty for home networks with a very small number of addresses available (a bock of 8 in may case) and a long timeout... From joerg at dorchain.net Wed Dec 22 12:36:07 2010 From: joerg at dorchain.net (Joerg Dorchain) Date: Wed, 22 Dec 2010 12:36:07 +0100 Subject: [atlas]DHCP behaviour of the probe on startup In-Reply-To: <4D11E0D1.5020801@CC.UniVie.ac.at> References: <4D11E0D1.5020801@CC.UniVie.ac.at> Message-ID: <20101222113607.GB5979@Redstar.dorchain.net> On Wed, Dec 22, 2010 at 11:28:17AM +0000, Wilfried Woeber, UniVie/ACOnet wrote: > Hi folks, > > while debugging some non-probe-related issues here at my ADSL'd net @home, > I was told by the provider's techie, that the probe tries to grab *two* > addresses at startup. I noticed the probe does a BOOTP-request on startup, and later a DHCP-request. Any decent DHCP-server should handle both, and see that is is a repeated request from the same mac-address. Real world implementation may be different, though. Would puzzles me wrt to bootup-behaviour is that I see the initial bootp on both the vlan assigned to the probe and the native lan, i.e. both tagged and untagged. This might however be more related to flaky network equipment. Bye, Joerg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: Digital signature URL: From glaser at cgi.br Wed Dec 29 19:20:07 2010 From: glaser at cgi.br (Hartmut Richard Glaser) Date: Wed, 29 Dec 2010 16:20:07 -0200 Subject: [atlas]Geo-location Message-ID: <4D1B7BD7.1080304@cgi.br> After the registration of the probes, how can I correct the geo-location? Thanks Hartmut -------------- next part -------------- An HTML attachment was scrubbed... URL: From Woeber at CC.UniVie.ac.at Wed Dec 29 21:32:39 2010 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 29 Dec 2010 20:32:39 +0000 Subject: [atlas]Geo-location In-Reply-To: <4D1B7BD7.1080304@cgi.br> References: <4D1B7BD7.1080304@cgi.br> Message-ID: <4D1B9AE7.3040705@CC.UniVie.ac.at> Hartmut Richard Glaser wrote: > > After the registration of the probes, how can I correct the geo-location? Go to "my probes", select/click the one you want to "move". In the new window, at the top-right corner there is a small icon with a circle (or a globe?). Click on this icon and you will see a pop-up with the mechanism to change the geo-loc- > Thanks > > Hartmut Gerne, liebe Gruesse, sch?nes (2010)++, Wilfried. (herder of 414 and 466) :-) From vnaumov at ripe.net Wed Dec 29 20:36:40 2010 From: vnaumov at ripe.net (Viktor Naoumov) Date: Wed, 29 Dec 2010 20:36:40 +0100 Subject: [atlas]Geo-location In-Reply-To: <4D1B7BD7.1080304@cgi.br> References: <4D1B7BD7.1080304@cgi.br> Message-ID: <4D1B8DC8.2080602@ripe.net> Hi Hartmut, Surely you can! 1. Click on the probe in the grid 2. In the opened tab click on the gear icon at the top-right corner. 3. Change Best regards, /vty On 12/29/2010 07:20 PM, Hartmut Richard Glaser wrote: > > After the registration of the probes, how can I correct the geo-location? > > Thanks > > Hartmut > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbarnes at bbn.com Thu Dec 30 20:00:41 2010 From: rbarnes at bbn.com (Richard L. Barnes) Date: Thu, 30 Dec 2010 14:00:41 -0500 Subject: [atlas]Probe actually down? Message-ID: <936CFCAC-F864-4FD4-AA99-2619D51A04C5@bbn.com> Probe #394 is reported as being down in the web GUI, but I can ping6 to it without a problem. I'm not near the probe right now, so I can't look at it or its traffic. Are there known cases where probes are alive but not reporting to their controllers? --Richard From glaser at nic.br Wed Dec 29 18:25:42 2010 From: glaser at nic.br (Hartmut Richard Glaser) Date: Wed, 29 Dec 2010 15:25:42 -0200 Subject: [atlas]Geo-location Message-ID: <4D1B6F16.4020203@nic.br> After the registration of the probes, how can I correct the geo-location? Thanks Hartmut -------------- next part -------------- An HTML attachment was scrubbed... URL: From axel.pawlik at ripe.net Wed Dec 29 20:18:18 2010 From: axel.pawlik at ripe.net (Axel Pawlik) Date: Wed, 29 Dec 2010 20:18:18 +0100 Subject: [atlas]Geo-location In-Reply-To: <4D1B7BD7.1080304@cgi.br> References: <4D1B7BD7.1080304@cgi.br> Message-ID: <4D1B897A.3050701@ripe.net> On 29/12/2010 19:20, Hartmut Richard Glaser wrote: > > After the registration of the probes, how can I correct the geo-location? > > Thanks > > Hartmut > hi Hartmut, on the per probe info page, the bar with the particular probe's name in it, has a small round icon on the right hand side. If you click on it, it let's you change the probe's geo-location info. cheers, Axel