From listclient at sokolov.eu.org Wed Nov 2 06:42:53 2011 From: listclient at sokolov.eu.org (Daniel AJ Sokolov (lists)) Date: Wed, 02 Nov 2011 02:42:53 -0300 Subject: [atlas] 3d downtime reported - why? Message-ID: <4EB0D85D.8030906@sokolov.eu.org> Hello, I have noticed that my probe data on the atlas.ripe.net-website reports at downtime of over 3 days: 2011-10-25 04:17:20 UTC to 2011-10-28 08:04:53 UTC. In fact, my connection was not down - maybe a few minutes (that seems to happen regularly), but everythin longer we would have noticed. We use this internet connection most of the day. My probe ID is not unter 500 but over 1000. Is this an error in the database, a problem with the reporting system or any other known bug? Did anyone else experience something like this? Or is there some issue I can resolve locally? Thank you Daniel AJ -- My twitter feed: @newstik http://twitter.com/newstik From tis at foobar.fi Wed Nov 2 07:46:14 2011 From: tis at foobar.fi (Tuomo Soini) Date: Wed, 2 Nov 2011 08:46:14 +0200 Subject: [atlas] 3d downtime reported - why? In-Reply-To: <4EB0D85D.8030906@sokolov.eu.org> References: <4EB0D85D.8030906@sokolov.eu.org> Message-ID: <20111102084614.7ad6157f@evelb.foobar.fi> On Wed, 02 Nov 2011 02:42:53 -0300 "Daniel AJ Sokolov (lists)" wrote: > In fact, my connection was not down - maybe a few minutes (that seems > to happen regularly), but everythin longer we would have noticed. We > use this internet connection most of the day. I saw similar issue previously. We had network problems some weeks ago and probe didn't get it's status up again before I gave it power-reset. I'm quite sure there is a problem in probe software. -- Tuomo Soini Foobar Linux services +358 40 5240030 Foobar Oy From michael at procter.org.uk Wed Nov 2 09:15:08 2011 From: michael at procter.org.uk (Michael Procter) Date: Wed, 2 Nov 2011 08:15:08 -0000 (UTC) Subject: [atlas] 3d downtime reported - why? In-Reply-To: <20111102084614.7ad6157f@evelb.foobar.fi> References: <4EB0D85D.8030906@sokolov.eu.org> <20111102084614.7ad6157f@evelb.foobar.fi> Message-ID: <51109.192.168.73.47.1320221708.squirrel@webmail.procter.org.uk> On Wed, November 2, 2011 6:46 am, Tuomo Soini wrote: > On Wed, 02 Nov 2011 02:42:53 -0300 > "Daniel AJ Sokolov (lists)" wrote: > >> In fact, my connection was not down - maybe a few minutes (that seems >> to happen regularly), but everythin longer we would have noticed. We >> use this internet connection most of the day. > > I'm quite sure there is a problem in probe software. On that note, it would be really useful if the reason for the disconnect was shown. Probe restart/software upgrade disconnects are not as worrying (for me at least) as connectivity-related disconnects. If the probe sent a connection count since boot when making a connection, then I would be able to see which disconnects I can ignore and which need investigation. Michael From philip.homburg at ripe.net Wed Nov 2 10:33:25 2011 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 02 Nov 2011 10:33:25 +0100 Subject: [atlas] 3d downtime reported - why? In-Reply-To: <51109.192.168.73.47.1320221708.squirrel@webmail.procter.org.uk> References: <4EB0D85D.8030906@sokolov.eu.org> <20111102084614.7ad6157f@evelb.foobar.fi> <51109.192.168.73.47.1320221708.squirrel@webmail.procter.org.uk> Message-ID: <4EB10E65.6040400@ripe.net> On 11/2/11 9:15 , Michael Procter wrote: > If the probe sent a connection count since boot when making a > connection, then I would be able to see which disconnects I can ignore > and which need investigation. Michael With the current firmware, probes report their uptime on a regular basis. However that information is currently not processed by the back-end system. Probes also continue doing measurements if there is no network connectivity. However that doesn't show up in the graphs. It should however show up in the logs. If you see missing packets in the log files then there was probably some kind of network problem otherwise, it is probably a probe problem. Philip Homburg From philip.homburg at ripe.net Wed Nov 2 14:05:55 2011 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 02 Nov 2011 14:05:55 +0100 Subject: [atlas] 3d downtime reported - why? In-Reply-To: <4EB0D85D.8030906@sokolov.eu.org> References: <4EB0D85D.8030906@sokolov.eu.org> Message-ID: <4EB14033.1000100@ripe.net> On 11/2/11 6:42 , Daniel AJ Sokolov (lists) wrote: > > I have noticed that my probe data on the atlas.ripe.net-website > reports at downtime of over 3 days: 2011-10-25 04:17:20 UTC to > 2011-10-28 08:04:53 UTC. > > In fact, my connection was not down - maybe a few minutes (that seems > to happen regularly), but everythin longer we would have noticed. We > use this internet connection most of the day. > > My probe ID is not unter 500 but over 1000. > > Is this an error in the database, a problem with the reporting system > or any other known bug? > > We found that within the back-end, an update message got lost. When the connection to the controller came up, the fact that this happened was not recorded in the database. So the system reports the probe as being down during that connection. As far as I can tell, no data was lost. Philip Homburg From Woeber at CC.UniVie.ac.at Wed Nov 2 17:19:16 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 02 Nov 2011 16:19:16 +0000 Subject: [atlas] packet loss seen by probes to labs.ripe.net? Message-ID: <4EB16D84.10507@CC.UniVie.ac.at> Dear Atlas Team, it looks like many (or even most/all?) of the probes seem to "seen" an increasing rate of packet loss to destination labs.ripe.net (on IPv4). The problem(?) seems to have started around Week 41 and gets worse since. Could the Atlas Team have a look at that? Thanks, Wilfried. From robert at ripe.net Wed Nov 2 18:35:40 2011 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 02 Nov 2011 18:35:40 +0100 Subject: [atlas] packet loss seen by probes to labs.ripe.net? In-Reply-To: <4EB16D84.10507@CC.UniVie.ac.at> References: <4EB16D84.10507@CC.UniVie.ac.at> Message-ID: <4EB17F6C.2010903@ripe.net> On 2011.11.02. 17:19, Wilfried Woeber, UniVie/ACOnet wrote: > Dear Atlas Team, > > it looks like many (or even most/all?) of the probes seem to "seen" an > increasing rate of packet loss to destination labs.ripe.net (on IPv4). > > The problem(?) seems to have started around Week 41 and gets worse since. > > Could the Atlas Team have a look at that? > > Thanks, > Wilfried. Hi, The preliminary answer is that there is ICMP rate limiting close to the Labs servers. The more probes execute ping measurements, the more often they trigger the limiting. Since the network grew continuously in the past weeks (and before), rising failure rates per probe can be expected. I'll try to confirm this with people who know more about the Labs architecture. But if I'm right (I think I am), then Atlas is measuring precisely what it should... and as a by-product, also its own growth :-) Regards, Robert From Woeber at CC.UniVie.ac.at Wed Nov 2 19:34:13 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 02 Nov 2011 18:34:13 +0000 Subject: [atlas] follow-up on private discussion regarding management of access to probe measurement data Message-ID: <4EB18D25.6010307@CC.UniVie.ac.at> Hi Vesna, Team, here is my reminder regarding the suggested "better" granularity to manage the access to measurement data per probe. As I see it right now (please feel free to correct me!): - right now there is an "individual" guardianship per probe(s), this guardianship includes configuration access. - regarding access to the measurement data, the guardian only has two option to manage the access privileges - private and public, or simply put: white or black. Now, given that different persons are managing different probes, if I want to grant access for them, or apply for access to the data of probes under their control, the only way to accommodate this is to declare the probe(s) involved "public". That is not necessarily what we want. Thus I am asking for a sort of "intermediate" or "group" access category. I can see a couple of ways to help with this, for example by providing a way to add other user identities to be authorized for (non-config, i.e. read-only) access. An alternate approach could be to allow creation of Groups, into which some probes could be put and which user identities could be added to for access to the probes in the group. Of course any other approach would be equally fine with me, I just tried to come up with a least one idea instead of only asking for added functionality :-) Btw, my feeling is that such a facility would be even more useful in support for the upcoming UDM stuff! Thanks for reading as far, Wilfried. From listclient at sokolov.eu.org Thu Nov 3 05:03:39 2011 From: listclient at sokolov.eu.org (Daniel AJ Sokolov (lists)) Date: Thu, 03 Nov 2011 01:03:39 -0300 Subject: [atlas] packet loss seen by probes to labs.ripe.net? In-Reply-To: <4EB17F6C.2010903@ripe.net> References: <4EB16D84.10507@CC.UniVie.ac.at> <4EB17F6C.2010903@ripe.net> Message-ID: <4EB2129B.7060708@sokolov.eu.org> On 02.11.2011 14:35 wrote Robert Kisteleki: > The preliminary answer is that there is ICMP rate limiting close to the Labs > servers. The more probes execute ping measurements, the more often they > trigger the limiting. Since the network grew continuously in the past weeks > (and before), rising failure rates per probe can be expected. > > I'll try to confirm this with people who know more about the Labs > architecture. But if I'm right (I think I am), then Atlas is measuring > precisely what it should... and as a by-product, also its own growth :-) So, in other words: The Atlas probes themselves are turning into a DDOS botnet? BR Daniel AJ From Marco.Davids at sidn.nl Thu Nov 3 10:59:05 2011 From: Marco.Davids at sidn.nl (Marco Davids) Date: Thu, 3 Nov 2011 09:59:05 +0000 Subject: [atlas] j.root-servers.net ICMP? Message-ID: Hi, Can anyone elaborate on why my Atlas probe is still trying to ping j.root-servers.net, while this seems futile since a few weeks? -------------- next part -------------- A non-text attachment was scrubbed... Name: rrd.png Type: image/png Size: 20686 bytes Desc: rrd.png URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001.txt URL: From rumen at telecoms.bg Thu Nov 3 11:34:55 2011 From: rumen at telecoms.bg (Rumen Svobodnikov) Date: Thu, 3 Nov 2011 12:34:55 +0200 (EET) Subject: [atlas] j.root-servers.net ICMP? In-Reply-To: References: Message-ID: Seems like it is anycasted. The closest instance to me pings just fine. PING j.root-servers.net (192.58.128.30) 56(84) bytes of data. 64 bytes from j.root-servers.net (192.58.128.30): icmp_seq=1 ttl=57 time=7.52 ms On Thu, 3 Nov 2011, Marco Davids wrote: > Hi, > > Can anyone elaborate on why my Atlas probe is still trying to ping j.root-servers.net, while this seems futile since a few weeks? > > > From Marco.Davids at sidn.nl Thu Nov 3 11:42:01 2011 From: Marco.Davids at sidn.nl (Marco Davids) Date: Thu, 3 Nov 2011 10:42:01 +0000 Subject: [atlas] j.root-servers.net ICMP? In-Reply-To: References: Message-ID: On Nov 3, 2011, at 11:34 AM, Rumen Svobodnikov wrote: > > Seems like it is anycasted. The closest instance to me pings just fine. Yep, I noticed (by looking at some of the public probes). Quite interesting. I wonder what the rationale might be. -- Marco > PING j.root-servers.net (192.58.128.30) 56(84) bytes of data. > 64 bytes from j.root-servers.net (192.58.128.30): icmp_seq=1 ttl=57 time=7.52 ms > > On Thu, 3 Nov 2011, Marco Davids wrote: > >> Hi, >> >> Can anyone elaborate on why my Atlas probe is still trying to ping j.root-servers.net, while this seems futile since a few weeks? >> >> >> From rbarnes at bbn.com Thu Nov 3 12:02:50 2011 From: rbarnes at bbn.com (Richard Barnes) Date: Thu, 3 Nov 2011 12:02:50 +0100 Subject: [atlas] j.root-servers.net ICMP? In-Reply-To: References: Message-ID: <80BE58CC-5028-427E-9135-7E6D59D101AE@bbn.com> Probably because the probe isn't trying to get an answer, it's trying to observe whether the node is up and what the latency is. So a failed ping is just as valuable as a successful ping. --Richard On Nov 3, 2011, at 10:59 AM, Marco Davids wrote: > Hi, > > Can anyone elaborate on why my Atlas probe is still trying to ping j.root-servers.net, while this seems futile since a few weeks? > > > > > -- > Marco Davids > Technical Advisor > > SIDN | Utrechtseweg 310 | 6812 AR | Postbus 5022 | 6802 EA | ARNHEM > T +31 (0)26 352 55 83 | M +31 (0)6 52 37 34 35 | F +31 (0)26 352 55 05 > marco.davids at sidn.nl | www.sidn.nl | enum:+31652373435 | sip:583 at sidn.nl > From robert at ripe.net Thu Nov 3 12:22:09 2011 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 03 Nov 2011 12:22:09 +0100 Subject: [atlas] j.root-servers.net ICMP? In-Reply-To: <80BE58CC-5028-427E-9135-7E6D59D101AE@bbn.com> References: <80BE58CC-5028-427E-9135-7E6D59D101AE@bbn.com> Message-ID: <4EB27961.90302@ripe.net> We actually have real-time maps showing what the full networks sees in terms of ping RTTs. Specifically for j-root: https://atlas.ripe.net/atlas/rtt_maps.html?msm_id=1016 We'll also have anycast maps soon -- see https://labs.ripe.net/Members/kistel/new-ripe-atlas-features-in-the-making Regards, Robert On 2011.11.03. 12:02, Richard Barnes wrote: > Probably because the probe isn't trying to get an answer, it's trying to observe whether the node is up and what the latency is. So a failed ping is just as valuable as a successful ping. > > --Richard > > > > On Nov 3, 2011, at 10:59 AM, Marco Davids wrote: > >> Hi, >> >> Can anyone elaborate on why my Atlas probe is still trying to ping j.root-servers.net, while this seems futile since a few weeks? >> >> >> >> >> -- >> Marco Davids >> Technical Advisor >> >> SIDN | Utrechtseweg 310 | 6812 AR | Postbus 5022 | 6802 EA | ARNHEM >> T +31 (0)26 352 55 83 | M +31 (0)6 52 37 34 35 | F +31 (0)26 352 55 05 >> marco.davids at sidn.nl | www.sidn.nl | enum:+31652373435 | sip:583 at sidn.nl >> > > From Woeber at CC.UniVie.ac.at Thu Nov 3 11:19:26 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 03 Nov 2011 10:19:26 +0000 Subject: [atlas] packet loss seen by probes to labs.ripe.net? In-Reply-To: <4EB17F6C.2010903@ripe.net> References: <4EB16D84.10507@CC.UniVie.ac.at> <4EB17F6C.2010903@ripe.net> Message-ID: <4EB26AAE.9060007@CC.UniVie.ac.at> Robert Kisteleki wrote: [...] > I'll try to confirm this with people who know more about the Labs > architecture. But if I'm right (I think I am), then Atlas is measuring > precisely what it should... and as a by-product, also its own growth :-) Hi Robert, nice line of thought :-) Actually, from a purely technical point of view, I agree with your interpretation. >From a probe-herder's point of view, this behaviour sent me on a bounty hunt on our end, to find out why there is packet loss between our office network and the labs site :-) > Regards, > Robert I think both ends did learn a little by this :-) Wilfried. PS: please do not take away the Labs (or another dedicated for ATLAS) target "at the NCC", I consider that a nice reference point for connectivity From philip.homburg at ripe.net Thu Nov 3 12:55:30 2011 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 03 Nov 2011 12:55:30 +0100 Subject: [atlas] packet loss seen by probes to labs.ripe.net? In-Reply-To: <4EB26AAE.9060007@CC.UniVie.ac.at> References: <4EB16D84.10507@CC.UniVie.ac.at> <4EB17F6C.2010903@ripe.net> <4EB26AAE.9060007@CC.UniVie.ac.at> Message-ID: <4EB28132.9080206@ripe.net> On 11/3/11 11:19 , Wilfried Woeber, UniVie/ACOnet wrote: > Robert Kisteleki wrote: > [...] >> I'll try to confirm this with people who know more about the Labs >> architecture. But if I'm right (I think I am), then Atlas is measuring >> precisely what it should... and as a by-product, also its own growth :-) > Hi Robert, nice line of thought :-) > > Actually, from a purely technical point of view, I agree with your > interpretation. > > > From a probe-herder's point of view, this behaviour sent me on a bounty > hunt on our end, to find out why there is packet loss between our office > network and the labs site :-) > > I checked only one probe (the one I have at home) but the traceroute for labs is quite telling. Though I'm surprised that it is RIPE border router that is dropping the packets. From bengan at bag.org Thu Nov 3 18:01:01 2011 From: bengan at bag.org (Bengt =?iso-8859-1?q?G=F6rd=E9n?=) Date: Thu, 3 Nov 2011 18:01:01 +0100 Subject: [atlas] Feature request: tag downtime In-Reply-To: <201012091127.17014.bengan@bag.org> References: <201012091127.17014.bengan@bag.org> Message-ID: <201111031801.01867.bengan@bag.org> This was about the tagging possibility I asked about during todays session in MAT. Just bumping it :) > 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). regards, /bengan From daniel.karrenberg at ripe.net Thu Nov 3 18:39:43 2011 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 3 Nov 2011 18:39:43 +0100 Subject: [atlas] Feature request: tag downtime In-Reply-To: <201111031801.01867.bengan@bag.org> References: <201012091127.17014.bengan@bag.org> <201111031801.01867.bengan@bag.org> Message-ID: <20111103173943.GM2818@dhcp-27-231.ripemtg.ripe.net> On 03.11 18:01, Bengt G?rd?n wrote: > > This was about the tagging possibility I asked about during todays session in > MAT. Just bumping it :) > > > 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). We keep forgetting that. We shouldn't. It needs to be much more general as for probes. Thank you Bengt, I would like to be able to have notes.tags on addresses themselves, whether they are probe addresses, destinations, networks, ...... and beyond the context of Atlas. Daniel From robert at ripe.net Fri Nov 4 12:05:12 2011 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 04 Nov 2011 12:05:12 +0100 Subject: [atlas] packet loss seen by probes to labs.ripe.net? In-Reply-To: <4EB2129B.7060708@sokolov.eu.org> References: <4EB16D84.10507@CC.UniVie.ac.at> <4EB17F6C.2010903@ripe.net> <4EB2129B.7060708@sokolov.eu.org> Message-ID: <4EB3C6E8.8040004@ripe.net> > So, in other words: The Atlas probes themselves are turning into a DDOS botnet? Daniel, We are very conscious that we need to prevent RIPE Atlas from being used in a malicious way, including it being used for DDOS attacks. There are a number of features in the design that prevent that from happening: - probes are low power compared to real bots - the control infrastructure is reasonably secure against the expected threats - user defined measurements can/will be rate limited per destination The "built-in" measurements we are executing currently are rate limited by the rate of deployment: all probes do exactly the same measurements. However, if this becomes a problem, we can change the amount and distribution of these measurements. Regards, Robert From robert at ripe.net Fri Nov 4 12:08:14 2011 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 04 Nov 2011 12:08:14 +0100 Subject: [atlas] packet loss seen by probes to labs.ripe.net? In-Reply-To: <4EB17F6C.2010903@ripe.net> References: <4EB16D84.10507@CC.UniVie.ac.at> <4EB17F6C.2010903@ripe.net> Message-ID: <4EB3C79E.3080508@ripe.net> > The preliminary answer is that there is ICMP rate limiting close to the Labs > servers. The more probes execute ping measurements, the more often they > trigger the limiting. Since the network grew continuously in the past weeks > (and before), rising failure rates per probe can be expected. This has been confirmed by our IT team in the meantime. Regards, Robert From listclient at sokolov.eu.org Sat Nov 5 21:38:21 2011 From: listclient at sokolov.eu.org (Daniel AJ Sokolov (lists)) Date: Sat, 05 Nov 2011 17:38:21 -0300 Subject: [atlas] Sudden increase in RTT to a.root-servers.net In-Reply-To: <4EB17F6C.2010903@ripe.net> References: <4EB16D84.10507@CC.UniVie.ac.at> <4EB17F6C.2010903@ripe.net> Message-ID: <4EB59EBD.80102@sokolov.eu.org> Hi, This is not urgent and probably not important. I have noticed that with the turn of the month (31st-> 1st) the RTT from my probe (#1118) to a.root-servers.net has gone up a lot. It went from ~32ms to ~115 ms (with a max of 494 ms). I checked the statistics of a few other public probes ("randomly" picked) and could not find that pattern repeated there. So what does this tell me? Has my ISP downgraded one of their uplinks? There is only three other probes here in Canada and they are not public, so I can't check their numbers. Maybe one of you has a few moments to enlighten me. I try to understand and learn from my probe's stats. :-) TNX Daniel AJ From paul at xelerance.com Sat Nov 5 23:09:31 2011 From: paul at xelerance.com (Paul Wouters) Date: Sat, 5 Nov 2011 18:09:31 -0400 (EDT) Subject: [atlas] Sudden increase in RTT to a.root-servers.net In-Reply-To: <4EB59EBD.80102@sokolov.eu.org> References: <4EB16D84.10507@CC.UniVie.ac.at> <4EB17F6C.2010903@ripe.net> <4EB59EBD.80102@sokolov.eu.org> Message-ID: On Sat, 5 Nov 2011, Daniel AJ Sokolov (lists) wrote: > This is not urgent and probably not important. > > I have noticed that with the turn of the month (31st-> 1st) the RTT from my > probe (#1118) to a.root-servers.net has gone up a lot. It went from ~32ms to > ~115 ms (with a max of 494 ms). > > I checked the statistics of a few other public probes ("randomly" picked) and > could not find that pattern repeated there. > > So what does this tell me? Has my ISP downgraded one of their uplinks? > > There is only three other probes here in Canada and they are not public, so I > can't check their numbers. Mine should be public? probe ID 223 in downtown Toronto. a.root-servers.net 198.41.0.4 86.274 ms / 86.633 ms / 87.010 ms 2011-11-05 21:59:19 UTC http://zpm00.atlas.ripe.net/atlas/rrd.png?prb_id=223&msm_id=1009&graph=tiny_rtt&type=hourly&end=last I'm using DSL with Teksavvy, and getting a-root from: $ dig +short +norec @a.root-servers.net hostname.bind chaos txt "ans13-lax2" Paul From listclient at sokolov.eu.org Sat Nov 5 23:19:12 2011 From: listclient at sokolov.eu.org (Daniel AJ Sokolov (lists)) Date: Sat, 05 Nov 2011 19:19:12 -0300 Subject: [atlas] Sudden increase in RTT to a.root-servers.net In-Reply-To: References: <4EB16D84.10507@CC.UniVie.ac.at> <4EB17F6C.2010903@ripe.net> <4EB59EBD.80102@sokolov.eu.org> Message-ID: <4EB5B660.1060805@sokolov.eu.org> On 05.11.2011 19:09 wrote Paul Wouters: >> There is only three other probes here in Canada and they are not >> public, so I can't check their numbers. > > Mine should be public? probe ID 223 in downtown Toronto. Ah, so there are four other probes in Canada. On the map you are so close to #1180 that I didn't see your's. :-) > a.root-servers.net > 198.41.0.4 86.274 ms / 86.633 ms / 87.010 ms 2011-11-05 21:59:19 UTC > > http://zpm00.atlas.ripe.net/atlas/rrd.png?prb_id=223&msm_id=1009&graph=tiny_rtt&type=hourly&end=last You are showing an increase of RRT for a.root-servers.net since the turn of the month as well, though it is probably not as strong as mine. As you had some really high spikes it is harder to see on your graphs. But the increase is there, from ~35 to ~77 ms. > I'm using DSL with Teksavvy, and getting a-root from: > > $ dig +short +norec @a.root-servers.net hostname.bind chaos txt > "ans13-lax2" "ansXX-lax2" for me as well - the XX is a two digit number that changes with every dig. BR Daniel AJ From wilhelm at ripe.net Sun Nov 6 17:49:07 2011 From: wilhelm at ripe.net (Rene Wilhelm) Date: Sun, 06 Nov 2011 17:49:07 +0100 Subject: [atlas] Sudden increase in RTT to a.root-servers.net In-Reply-To: <4EB59EBD.80102@sokolov.eu.org> References: <4EB16D84.10507@CC.UniVie.ac.at> <4EB17F6C.2010903@ripe.net> <4EB59EBD.80102@sokolov.eu.org> Message-ID: <4EB6BA83.6090609@ripe.net> On 11/5/11 9:38 PM, Daniel AJ Sokolov (lists) wrote: > Hi, > > This is not urgent and probably not important. > > I have noticed that with the turn of the month (31st-> 1st) the RTT > from my probe (#1118) to a.root-servers.net has gone up a lot. It went > from ~32ms to ~115 ms (with a max of 494 ms). > > I checked the statistics of a few other public probes ("randomly" > picked) and could not find that pattern repeated there. > > So what does this tell me?Has my ISP downgraded one of their uplinks? Such sudden steps in RTT are usually an indication of a probe reaching a different, more distant instance of an anycasted server. The Atlas RTT map (https://atlas.ripe.net/atlas/rtt_maps.html . selected measurement 'IPv4: a.root-servers.net') shows all probes in the North Eastern US & Canada now have rather high round trip times to a.root-servers.net, 75ms is the lowest found. This is unusual; with global instances of the a root server in Ashburn, Virginia and New York[*] you would expect to see much lower RTTs on at least a good majority of these probes. The public probe #338 (Culpeper, Virginia) sees ping times going up to 78ms at the same time yours increased to 115ms. [**] So it's not your ISP downgrading the service. More likely something related to routing, somehow hosts in the east of the US now end up in the west of the US when talking to a.root-servers.net. -- Rene [*] http://www.root-servers.org/ lists six global sites for a.root-servers.net: two in the east, two in the west of the US, one in Germany and one in Hongkong [**] http://zpm00.atlas.ripe.net/atlas/rrd.png?prb_id=338&msm_id=1009&type=weekly&end=last ** > > There is only three other probes here in Canada and they are not > public, so I can't check their numbers. > > Maybe one of you has a few moments to enlighten me. I try to > understand and learn from my probe's stats. :-) > > TNX > Daniel AJ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Fri Nov 11 18:07:36 2011 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 11 Nov 2011 18:07:36 +0100 Subject: [atlas] Outage on one UI server Message-ID: <4EBD5658.8040303@ripe.net> Dear All, One of our UI servers is down at the moment. We've been trying hard to restore it for some hours now, but there's a chance that we'll not succeed before next week. The result is that for a subset of the probes we're currently not generating RRD graphs. The affected probes are ID<=500 and ID>=2000. We do not expect data loss, as all results are stored on intermediary nodes, however you'll not see these results until the issue is fixed. Please accept our apologies for the inconvenience this may cause. Regards, Robert Kisteleki From robert at ripe.net Tue Nov 22 16:48:14 2011 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 22 Nov 2011 16:48:14 +0100 Subject: [atlas] More maps available Message-ID: <4ECBC43E.3060305@ripe.net> Dear Atlas Users, Today we've enabled the "DNS root anycast instance map" that was announced at the RIPE meeting and in the RIPE Labs article here: https://labs.ripe.net/Members/kistel/new-ripe-atlas-features-in-the-making Clicking on the "Maps" link in the menu bar (top right) leads you to a page that lists all maps we have available at the moment, including the anycast map. As a small enhancement we also begun to link AS and prefix information to RIPEstat, to facilitate looking up more information about these resources. This is visible on the "my probes" page as well as on various maps (when clicking on individual probes). Regards, Robert (for the whole team) From Woeber at CC.UniVie.ac.at Thu Nov 24 19:33:55 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 24 Nov 2011 18:33:55 +0000 Subject: [atlas] problems with (links to) stat.ripe.net Message-ID: <4ECE8E13.2090609@CC.UniVie.ac.at> Just wanted to double-check... Are you aware of problems - or do others see similar effects - with the display of pages that are linked to from the Atlas panels? IE7 (on XP) complains with "error on page" and Iceweasel on Debian does not complain, but doesn't display any useful information either. As an aside, with Iceweasel the "Result Boxes" rectangle seems to be pinned to a fixed place on the screen and obstructs the information when the page is scrolled underneath. Just wanted to raise a small flag before doing screenshots and other investigations. Thanks for listening, Wilfried. From Woeber at CC.UniVie.ac.at Thu Nov 24 19:37:10 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 24 Nov 2011 18:37:10 +0000 Subject: [atlas] no gateway for IPv6 Message-ID: <4ECE8ED6.2040400@CC.UniVie.ac.at> Hi folks, just noticed that for an IPv6-capable probe no gateway info/address is given. Curiousity - is there an "good reason" for that behaviour or is it just not implemented yet? Lowest prio, of course :-) Wilfried. From antony at ripe.net Thu Nov 24 20:24:56 2011 From: antony at ripe.net (Antony Antony) Date: Thu, 24 Nov 2011 20:24:56 +0100 Subject: [atlas] no gateway for IPv6 In-Reply-To: <4ECE8ED6.2040400@CC.UniVie.ac.at> References: <4ECE8ED6.2040400@CC.UniVie.ac.at> Message-ID: <20111124192455.GA26127@dog.ripe.net> Wilfried, it is yet to be implemented. That is a simple answer. a bit more detail: it is half done. The probe send it and we haven't propagated it to the UI. a more complicated answer:) to kill your curiosity. IPv4 setup is rather simple. One gateway from dhcp or static configuration. V6 could be more than address and gateway. Initial version only red one IPv6 global address. Soon we ran into multiple v6 Global addresses and gateways. New versions send all addresses and routing table to the controllers. Also the gateways are often IPv6 link local address... here is an example. Actually this probe has 3 differnt prefixes/addresses. Destination Next HopF Flags Metric Ref Use Iface ::/0 fe80::1a0:c7ff:fe9f:11be UGDA 1024 39677 0 eth0 ::/0 fe80::1a1:c8ff:fe9f:15a9 UGDA 1024 0 0 eth0 also there are more complicated routing tables out there to parse. I guess eventually we will add it. However, decided UDM is more important! regards, -antony On Thu, Nov 24, 2011 at 06:37:10PM +0000, Wilfried Woeber, UniVie/ACOnet wrote: > Hi folks, > > just noticed that for an IPv6-capable probe no gateway info/address is > given. > > Curiousity - is there an "good reason" for that behaviour or is it just > not implemented yet? > > Lowest prio, of course :-) > Wilfried. > > From robert at ripe.net Mon Nov 28 12:44:27 2011 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 28 Nov 2011 12:44:27 +0100 Subject: [atlas] problems with (links to) stat.ripe.net In-Reply-To: <4ECE8E13.2090609@CC.UniVie.ac.at> References: <4ECE8E13.2090609@CC.UniVie.ac.at> Message-ID: <4ED3741B.3000406@ripe.net> Hi Wilfried, I think we should move this to RIPEstat development are instead. I'll let the right people know. Regards, Robert On 2011.11.24. 19:33, Wilfried Woeber, UniVie/ACOnet wrote: > Just wanted to double-check... > > Are you aware of problems - or do others see similar effects - > with the display of pages that are linked to from the Atlas panels? > > IE7 (on XP) complains with "error on page" and Iceweasel on Debian > does not complain, but doesn't display any useful information either. > > As an aside, with Iceweasel the "Result Boxes" rectangle seems to be pinned > to a fixed place on the screen and obstructs the information when the page > is scrolled underneath. > > Just wanted to raise a small flag before doing screenshots and other > investigations. > > Thanks for listening, > Wilfried. >