From robert at ripe.net Tue Jul 3 09:10:32 2012 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 03 Jul 2012 09:10:32 +0200 Subject: [atlas] Atlas infrastructure issues on Friday, 2012-06-29 Message-ID: <4FF29AE8.5060801@ripe.net> Dear Atlas users, As part of regular maintenance, last Thursday (2012-06-28) afternoon we upgraded the OS on a subset of our controlling infrastructure. During this work, some Atlas probes were told to hold back result reporting. A consequence of this was that when reconnecting, these probes sent in way more (and bigger) results than usual. Unfortunately, not all of the upgraded components ("controllers") had enough disk space to deal with the sudden increased data inflow. The combination of these events means that part of our infrastructure could not buffer results submitted from the probes, and as a result these results have been discarded. The event lasted approximately between 22h Thursday and 05h Friday (UTC), and affected about 30% of the probes. These probes will have a gap in their downloadable data sets and on their graphs. Since the event we increased the capacity of the involved infrastructure components. This will help us avoiding the same event occurring again. We apologise for the inconvenience this may cause. Regards, Robert Kisteleki RIPE NCC R&D From abarcomb at ripe.net Wed Jul 11 15:07:31 2012 From: abarcomb at ripe.net (Ann Barcomb) Date: Wed, 11 Jul 2012 15:07:31 +0200 Subject: [atlas] Firmware 4470 to be released soon Message-ID: <4FFD7A93.4060503@ripe.net> Hello, Probe firmware version 4470 will be released soon. This version includes a small data structure change from 4460 which only affects DNS measurements: the addition of the optional field 'src_addr'. We have also published a correction for version 4460, which mistakenly listed a field 'src' for DNS measurements. This field does not exist in 4460. http://weir-dev.atlas.ripe.net/doc/data_struct#v4460_dns Kind Regards, Ann -- Ann Barcomb RIPE NCC Community Builder http://www.ripe.net Measurements Community Building +31 20 535 4444 From BECHA at ripe.net Wed Jul 11 15:31:56 2012 From: BECHA at ripe.net (Vesna Manojlovic) Date: Wed, 11 Jul 2012 15:31:56 +0200 Subject: [atlas] ::correction:: Firmware 4470 to be released soon In-Reply-To: <4FFD7A93.4060503@ripe.net> References: <4FFD7A93.4060503@ripe.net> Message-ID: <4FFD804C.6040305@ripe.net> Hi all, On 7/11/12 3:07 PM, Ann Barcomb wrote: > Hello, > > Probe firmware version 4470 will be released soon. This version > includes a small data structure change from 4460 which only affects DNS > measurements: the addition of the optional field 'src_addr'. > > We have also published a correction for version 4460, which mistakenly > listed a field 'src' for DNS measurements. This field does not exist in > 4460. > > http://weir-dev.atlas.ripe.net/doc/data_struct#v4460_dns weir-dev is our development server; Ann was testing the documentation and sent you the wrong URL. The correct one is just without the development server name: https://atlas.ripe.net/doc/data_struct#v4460_dns Regards, Vesna From kix at kix.es Wed Jul 18 09:38:22 2012 From: kix at kix.es (kix) Date: Wed, 18 Jul 2012 09:38:22 +0200 Subject: [atlas] Fwd: [ipv6-wg] New on RIPE Labs: Test your IPv6 Reachability by Using RIPE Atlas (now visualised) Message-ID: <510a9307cb61e4b6976364369449f999@mail.kix.es> fyi. I think this mail was not sent to this mail list. Cheers, kix -------- Mensaje original -------- Asunto: [ipv6-wg] New on RIPE Labs: Test your IPv6 Reachability by Using RIPE Atlas (now visualised) Fecha: 17/07/2012 14:32 Remitente: Mirjam Kuehne Destinatario: ipv6-wg at ripe.net [apologies for duplicate mails] Dear colleagues, As announced in earlier, it is possible for RIPE NCC members to do IPv6-traceroutes from all RIPE Atlas probes to IPv6 destinations. In this new article on RIPE Labs we present a first experimental analysis and a prototype visualisation of the traceroute results: https://labs.ripe.net/Members/emileaben/visualise-your-ipv6-connectivity-using-ripe-atlas Kind Regards, Mirjam Kuehne RIPE NCC -- Rodolfo Garc?a Pe?as (kix) http://www.kix.es From rm at romanrm.ru Wed Jul 18 11:51:26 2012 From: rm at romanrm.ru (Roman Mamedov) Date: Wed, 18 Jul 2012 15:51:26 +0600 Subject: [atlas] Fwd: [ipv6-wg] New on RIPE Labs: Test your IPv6 Reachability by Using RIPE Atlas (now visualised) In-Reply-To: <510a9307cb61e4b6976364369449f999@mail.kix.es> References: <510a9307cb61e4b6976364369449f999@mail.kix.es> Message-ID: <20120718155126.13c3f732@natsu> On Wed, 18 Jul 2012 09:38:22 +0200 kix wrote: > In this new article on RIPE Labs we present a first experimental > analysis and a prototype visualisation of the traceroute results: > > https://labs.ripe.net/Members/emileaben/visualise-your-ipv6-connectivity-using-ripe-atlas So I was interested by this and went and created my first UDM. I have chosen "traceroute" and did not mark the "Do not visualise" checkbox. However in the Results section I now see only a table in an obscure format, and an option to "Download as JSON". How do I get some kind of visualisation of these results? Is that something only for LIRs? Well, even not asking for the pretty graphs, how do I view traceroutes as regular plaintext traceroutes shown on a web page, not a machine-readable structure? Note: please do not suggest to write my own JSON processing to merely view a traceroute. -- With respect, Roman ~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Stallman had a printer, with code he could not see. So he began to tinker, and set the software free." -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From emile.aben at ripe.net Wed Jul 18 13:28:37 2012 From: emile.aben at ripe.net (Emile Aben) Date: Wed, 18 Jul 2012 13:28:37 +0200 Subject: [atlas] Fwd: [ipv6-wg] New on RIPE Labs: Test your IPv6 Reachability by Using RIPE Atlas (now visualised) In-Reply-To: <20120718155126.13c3f732@natsu> References: <510a9307cb61e4b6976364369449f999@mail.kix.es> <20120718155126.13c3f732@natsu> Message-ID: <50069DE5.2030007@ripe.net> On 18/07/2012 11:51, Roman Mamedov wrote: > On Wed, 18 Jul 2012 09:38:22 +0200 kix wrote: > >> In this new article on RIPE Labs we present a first experimental >> analysis and a prototype visualisation of the traceroute >> results: >> >> https://labs.ripe.net/Members/emileaben/visualise-your-ipv6-connectivity-using-ripe-atlas > >> > So I was interested by this and went and created my first UDM. I > have chosen "traceroute" and did not mark the "Do not visualise" > checkbox. However in the Results section I now see only a table in > an obscure format, and an option to "Download as JSON". How do I > get some kind of visualisation of these results? > Is that something only for LIRs? Well, even not asking for the > pretty graphs, how do I view traceroutes as regular plaintext > traceroutes shown on a web page, not a machine-readable structure? > Note: please do not suggest to write my own JSON processing to > merely view a traceroute. Hi Roman, We are experimenting with how to visualize large amounts of traceroutes. In the Labs article you mention I wrote about how this is done for the IPv6 traceroutes that were done through the LIR-only interface for this at: https://atlas.ripe.net/atlas/ipv6_traces.html So that is currently only available for these measurements. An example of the visualization for ns.ripe.net can be found here: http://albatross.ripe.net/cgi-bin/demo-area/v6reach.cgi?msm_id=1002799;nonce=2bb398946c5513d966e84182027fc20eaa941e6a204812c3349b769fb55ec503;no_embed=1 For other traceroute measurements there are no other results currently other then the JSON-downloads and the table with unformatted JSON results. Having that available as something plain-text to read (for when you have small amounts of traceroute data), is a good suggestion I think. best regards, Emile Aben RIPE NCC From renne.bartsch at googlemail.com Wed Jul 18 13:48:08 2012 From: renne.bartsch at googlemail.com (Bartsch, Rene) Date: Wed, 18 Jul 2012 11:48:08 +0000 Subject: [atlas] Flood-ping to measure packet loss? Message-ID: Hi, I've just started hosting a probe and I'm new to the list, so a "Hello" to all! :) Does the probe send simple pings or does it send flood pings (e.g. ping -f -c 1000 ) for detection of packet loss? Best regards, Renne -- Sent with love from the new tine 2.0 email client ... Please visit http://tine20.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From bicknell at ufp.org Wed Jul 18 15:08:13 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 18 Jul 2012 06:08:13 -0700 Subject: [atlas] Fwd: [ipv6-wg] New on RIPE Labs: Test your IPv6 Reachability by Using RIPE Atlas (now visualised) In-Reply-To: <50069DE5.2030007@ripe.net> References: <510a9307cb61e4b6976364369449f999@mail.kix.es> <20120718155126.13c3f732@natsu> <50069DE5.2030007@ripe.net> Message-ID: <20120718130813.GA72117@ussenterprise.ufp.org> In a message written on Wed, Jul 18, 2012 at 01:28:37PM +0200, Emile Aben wrote: > An example of the visualization for ns.ripe.net can be found here: > http://albatross.ripe.net/cgi-bin/demo-area/v6reach.cgi?msm_id=1002799;nonce=2bb398946c5513d966e84182027fc20eaa941e6a204812c3349b769fb55ec503;no_embed=1 Very cool. > For other traceroute measurements there are no other results currently > other then the JSON-downloads and the table with unformatted JSON > results. Having that available as something plain-text to read (for > when you have small amounts of traceroute data), is a good suggestion > I think. I've had to deal with JSON before, but it was long ago and far away. I suspect it is not something most sysadmin/netadmin types deal with on a daily basis. It's not hard, just not familar. To that end, if RIPE could produce a template/example in a few popular languages (perl, python, ruby, php) to download the JSON and parse into the native language data structure that could get a LOT more folks using the data... -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From renne.bartsch at googlemail.com Wed Jul 18 15:44:40 2012 From: renne.bartsch at googlemail.com (Bartsch, Rene) Date: Wed, 18 Jul 2012 13:44:40 +0000 Subject: [atlas] Fwd: [ipv6-wg] New on RIPE Labs: Test your IPv6 Reachability by Using RIPE Atlas (now visualised) In-Reply-To: <20120718130813.GA72117@ussenterprise.ufp.org> References: <510a9307cb61e4b6976364369449f999@mail.kix.es> <20120718155126.13c3f732@natsu> <50069DE5.2030007@ripe.net> <20120718130813.GA72117@ussenterprise.ufp.org> Message-ID: <9f43762d3426e2e048c334950d111ab48fad7df8@googlemail.com> Am 18.07.2012 15:14:19, schrieb Leo Bicknell: > I've had to deal with JSON before, but it was long ago and far away. > I suspect it is not something most sysadmin/netadmin types deal with on > a daily basis. It's not hard, just not familar. > > To that end, if RIPE could produce a template/example in a few popular > languages (perl, python, ruby, php) to download the JSON and parse into > the native language data structure that could get a LOT more folks using > the data... Javascript: At https://www.bartschnet.de/lib/js/XMLHttpRequest.js you can find my Javascript-function which I use to directly communicate with a JSON-API via POST from a browser. url:???????? API-URL object:??? Javascript-object to be converted to JSON and sent to API ( can be "{}") if you don't want to send any data callback: Javascript-function which gets a javascript-object converted from JSON-POST-result as only parameter PHP: You can directly decode JSON to PHP-objects/arrays with: http://php.net/manual/en/function.json-decode.php or encode any PHP data type including objects and arrays to JSON with: http://php.net/manual/en/function.json-encode.php Just do not forget JSON-strings are UTF-8! Best regards, Renne -- Sent with love from the new tine 2.0 email client ... Please visit http://tine20.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From matija at serverflow.com Wed Jul 18 15:45:32 2012 From: matija at serverflow.com (Matija Grabnar) Date: Wed, 18 Jul 2012 15:45:32 +0200 Subject: [atlas] Fwd: [ipv6-wg] New on RIPE Labs: Test your IPv6 Reachability by Using RIPE Atlas (now visualised) In-Reply-To: <20120718130813.GA72117@ussenterprise.ufp.org> References: <510a9307cb61e4b6976364369449f999@mail.kix.es> <20120718155126.13c3f732@natsu> <50069DE5.2030007@ripe.net> <20120718130813.GA72117@ussenterprise.ufp.org> Message-ID: <5006BDFC.503@serverflow.com> On 07/18/2012 03:08 PM, Leo Bicknell wrote: > To that end, if RIPE could produce a template/example in a few popular > languages (perl, python, ruby, php) to download the JSON and parse into > the native language data structure that could get a LOT more folks using > the data... > You can fins a bunch of decoders in more languages than I count on http://www.json.org/ From antony at ripe.net Wed Jul 18 17:49:35 2012 From: antony at ripe.net (Antony Antony) Date: Wed, 18 Jul 2012 17:49:35 +0200 Subject: [atlas] Flood-ping to measure packet loss? In-Reply-To: References: Message-ID: <20120718154935.GA26576@dog.ripe.net> Hi Rene, it is the simple one. One packet per second. regards, -antony On Wed, Jul 18, 2012 at 11:48:08AM +0000, Bartsch, Rene wrote: > Hi, > > I've just started hosting a probe and I'm new to the list, so a "Hello" to all! :) > > Does the probe send simple pings or does it send flood pings (e.g. ping -f -c 1000 ) for detection of packet loss? > > Best regards, > > Renne > > -- > Sent with love from the new tine 2.0 email client ... > Please visit http://tine20.org From florian at net.t-labs.tu-berlin.de Wed Jul 18 18:33:47 2012 From: florian at net.t-labs.tu-berlin.de (Florian Streibelt) Date: Wed, 18 Jul 2012 18:33:47 +0200 Subject: [atlas] Flood-ping to measure packet loss? In-Reply-To: <20120718154935.GA26576@dog.ripe.net> References: <20120718154935.GA26576@dog.ripe.net> Message-ID: <20120718183347.0ac98fef@fls-nb.lan.streibelt.net> Hi, Am Mi, 18.07.12 um 17:49:35 Uhr schrieb Antony Antony : > > On Wed, Jul 18, 2012 at 11:48:08AM +0000, Bartsch, Rene wrote: > > Hi, > > > > I've just started hosting a probe and I'm new to the list, so a "Hello" to all! :) > > > > Does the probe send simple pings or does it send flood pings (e.g. ping -f -c 1000 ) for detection of packet loss? > > If you would do a flood ping it is more likely you will observe congestion in the LAN when the probe is connected to a slow uplink. More interesting for WAN measurements is the loss under 'normal' conditions. Consider the probe beeing installed at a residential DSL or cable line, where one of the probes I host ist located. If I start a huge download I will have congestion on my upstream because of the ACKs I send. A probe would now observe huge loss when doing a flood ping. Florian From renne.bartsch at googlemail.com Wed Jul 18 19:15:35 2012 From: renne.bartsch at googlemail.com (Bartsch, Rene) Date: Wed, 18 Jul 2012 17:15:35 +0000 Subject: [atlas] Flood-ping to measure packet loss? In-Reply-To: <20120718183347.0ac98fef@fls-nb.lan.streibelt.net> References: <20120718154935.GA26576@dog.ripe.net> <20120718183347.0ac98fef@fls-nb.lan.streibelt.net> Message-ID: Am 18.07.2012 18:41:11, schrieb Florian Streibelt: > Hi, > > > Am Mi, 18.07.12 um 17:49:35 Uhr > schrieb Antony Antony <> antony at ripe.net> >: > > > > > On Wed, Jul 18, 2012 at 11:48:08AM +0000, Bartsch, Rene wrote: > > > Hi, > > > > > > I've just started hosting a probe and I'm new to the list, so a "Hello" to all! :) > > > > > > Does the probe send simple pings or does it send flood pings (e.g. ping -f -c 1000 ) for detection of packet loss? > > > > > If you would do a flood ping it is more likely you will observe congestion > in the LAN when the probe is connected to a slow uplink. More interesting > for WAN measurements is the loss under 'normal' conditions. Consider the > probe beeing installed at a residential DSL or cable line, where one of > the probes I host ist located. > > If I start a huge download I will have congestion on my upstream because > of the ACKs I send. A probe would now observe huge loss when doing a flood ping. I've installed the first probe (just registered for a second) on a residential socket on today noon. It shows packet loss for c.root-servers.net (192.33.4.12) from time to time and continous packet loss of 100% for m.root-servers.net (202.12.27.3). Netalyzer-Tests show a packet loss of 8-17% for the last two weeks (problems habe been around for about half a year, getting more and more annyoing for the last three month), while connections inside Germany seem to work for the users meanwhile. The 16/1-MBit/s last mile has one or zero non-correctable errors in fifteen minutes (DSL). CPE (IAD 3222 -> IAD 3221 -> Fritzbox 7390) and wiring has been changed completely. For me, it looks like a broken or misconfigured router in the ISPs backbone, but they keep insisting everything is fine with their backbone. :( When I did simple ping tests, no packet loss was shown on the unused line, but when using a flood ping with 1000 packets I can see packet loss. As I'm no forensic scientist I'm trying to find a way to localize the problem ... -- Sent with love from the new tine 2.0 email client ... Please visit http://tine20.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From yoann.gini at gmail.com Fri Jul 20 14:39:39 2012 From: yoann.gini at gmail.com (Yoann Gini) Date: Fri, 20 Jul 2012 14:39:39 +0200 Subject: [atlas] Probe down? Message-ID: <7DD1D52C-7028-43DE-9FCC-532D41460C3C@gmail.com> Hello, My probe is down since a while now. I?ve try to unplug and replug many time, change USB and ethernet slot and it?s still down. The green led is on and the orange is slowly flashing, my swith see the probe, bit Atlas always report it as down. I?ve the Probe ID 2199. What I?m supposed to do ? Best regards, Yoann Gini. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4802 bytes Desc: not available URL: From philip.homburg at ripe.net Fri Jul 20 15:03:48 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 20 Jul 2012 15:03:48 +0200 Subject: [atlas] Probe down? In-Reply-To: <7DD1D52C-7028-43DE-9FCC-532D41460C3C@gmail.com> References: <7DD1D52C-7028-43DE-9FCC-532D41460C3C@gmail.com> Message-ID: <50095734.2070009@ripe.net> On 7/20/12 14:39 , Yoann Gini wrote: > Hello, > > My probe is down since a while now. I?ve try to unplug and replug many time, change USB and ethernet slot and it?s still down. The green led is on and the orange is slowly flashing, my swith see the probe, bit Atlas always report it as down. > > I?ve the Probe ID 2199. What I?m supposed to do ? > > Can you still ping the probe from inside your network? From jhma at mcvax.org Fri Jul 20 15:44:46 2012 From: jhma at mcvax.org (James Aldridge) Date: Fri, 20 Jul 2012 15:44:46 +0200 Subject: [atlas] Probe down? In-Reply-To: <7DD1D52C-7028-43DE-9FCC-532D41460C3C@gmail.com> References: <7DD1D52C-7028-43DE-9FCC-532D41460C3C@gmail.com> Message-ID: <500960CE.6040505@mcvax.org> On 20/07/2012 14:39, Yoann Gini wrote: > Hello, > > My probe is down since a while now. I?ve try to unplug and replug many time, change USB and ethernet slot and it?s still down. The green led is on and the orange is slowly flashing, my swith see the probe, bit Atlas always report it as down. > > I?ve the Probe ID 2199. What I?m supposed to do ? I had this problem with my Atlas probe a while ago when I was using an old Apple iPod power supply. Moving the probe to an otherwise unused, powered USB hub fixed the problem. James From pribeiro-salta at net.ipl.pt Fri Jul 20 16:34:09 2012 From: pribeiro-salta at net.ipl.pt (Pedro Ribeiro) Date: Fri, 20 Jul 2012 15:34:09 +0100 Subject: [atlas] Probe down? In-Reply-To: <7DD1D52C-7028-43DE-9FCC-532D41460C3C@gmail.com> References: <7DD1D52C-7028-43DE-9FCC-532D41460C3C@gmail.com> Message-ID: <50096C61.8010304@net.ipl.pt> Same problem here, since July 1. I've sent some debug info to the Atlas team, still waiting for answers. Replacing the power supply doesn't solved the problem. The probe seems to be stuck in an old firmware version (4310), after powerup acquires IP via DHCP, does some DNS queries, connects to some Atlas server using SSH to port 443. After some packets the connection seems to hang and the probe becomes quiet (it still answers "pings"). Side by side with another probe I'm hosting at the job and the behaviour is the same, the other probe works ok. As reference, I'm attaching a capture of the broken probe traffic after boot. Regards. On 20-07-2012 13:39, Yoann Gini wrote: > Hello, > > My probe is down since a while now. I?ve try to unplug and replug many time, change USB and ethernet slot and it?s still down. The green led is on and the orange is slowly flashing, my swith see the probe, bit Atlas always report it as down. > > I?ve the Probe ID 2199. What I?m supposed to do ? > > Best regards, > Yoann Gini. > -- Best regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Pedro Ribeiro IPLNet - Rede de dados e comunica??es Instituto Polit?cnico de Lisboa (IPL) Mail: mailto:pribeiro AT net.ipl.pt VoIP: sip:pribeiro AT net.ipl.pt =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -------------- next part -------------- A non-text attachment was scrubbed... Name: atlas-20120702.pcap Type: application/octet-stream Size: 6719 bytes Desc: not available URL: From renne.bartsch at googlemail.com Sun Jul 22 14:31:35 2012 From: renne.bartsch at googlemail.com (Bartsch, Rene) Date: Sun, 22 Jul 2012 12:31:35 +0000 Subject: [atlas] Embedd built-in measurement page into website Message-ID: Hi, is there any way to embedd the "Built-in Measurements"-JQuery-Frame of my probes into a publically accessible website? Thanx for any hint, Renne -- Sent with love from the new tine 2.0 email client ... Please visit http://tine20.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From tibor.djurica at ojdip.net Sun Jul 22 15:03:05 2012 From: tibor.djurica at ojdip.net (Tibor Djurica Potpara) Date: Sun, 22 Jul 2012 15:03:05 +0200 Subject: [atlas] High inbound traffic causing packet loss? Message-ID: <500BFA09.5080700@ojdip.net> Hello! I have just received an Atlas probe and I have been observing some weird readouts on the Atlas portal. Especially, occasional packet loss and considerable jitter, even to first and second hop destinations. I am surprised because even though I am a home user, I have a very stable connection (FTTH, 100/10 Mbps) and I've never experienced such connectivity issues. I've attached the probe directly to the ISP-provided switch that doesn't do IGMP snooping and since IP multicast is used for IPTV, high traffic (up to 50 Mbps) is occasionally flooded to all the switch ports. Taking into account that the probe is underpowered in terms of CPU, is it possible that it cannot handle such traffic and thus reports packet loss? If such is the case, I will move the probe behind a router to filter the multicast streams out. Best regards, Tibor Djurica Potpara From david.lebrun at student.uclouvain.be Mon Jul 23 08:15:38 2012 From: david.lebrun at student.uclouvain.be (David Lebrun) Date: Mon, 23 Jul 2012 15:15:38 +0900 Subject: [atlas] Concurrent traceroute issues on the probes Message-ID: <500CEC0A.8060900@student.uclouvain.be> Hi all, I was wondering whether the probes can perform multiple concurrent traceroutes toward different destinations, and if so, are they able to differentiate the replies ? I just ran into this problem with paris-traceroute, the path were completely mixed up and stderr output looking like the following messages multiple times (IP addresses redacted): [WARN](TracertImpl.cc, 368)A reply received with bad original destination address A.B.C.D, should be W.X.Y.Z [WARN](TracertImpl.cc, 326)Bad return flow id 0x4d2 from E.F.G.H [WARN](TracertImpl.cc, 331)ICMP reserved words 0 0 0 0 0 As the probes use paris-traceroute, I prefer to be sure that the results are not flawed. David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From philip.homburg at ripe.net Mon Jul 23 10:28:23 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 23 Jul 2012 10:28:23 +0200 Subject: [atlas] Concurrent traceroute issues on the probes In-Reply-To: <500CEC0A.8060900@student.uclouvain.be> References: <500CEC0A.8060900@student.uclouvain.be> Message-ID: <500D0B27.7000603@ripe.net> On 7/23/12 8:15 , David Lebrun wrote: > I was wondering whether the probes can perform multiple concurrent > traceroutes toward different destinations, and if so, are they able to > differentiate the replies ? > Yes, which instance it is, is encoded in the packet that is sent out. From david.lebrun at student.uclouvain.be Mon Jul 23 10:57:36 2012 From: david.lebrun at student.uclouvain.be (David Lebrun) Date: Mon, 23 Jul 2012 17:57:36 +0900 Subject: [atlas] Concurrent traceroute issues on the probes In-Reply-To: <500D0B27.7000603@ripe.net> References: <500CEC0A.8060900@student.uclouvain.be> <500D0B27.7000603@ripe.net> Message-ID: <500D1200.8050303@student.uclouvain.be> On 07/23/2012 05:28 PM, Philip Homburg wrote: > Yes, which instance it is, is encoded in the packet that is sent out. Ok thanks. This leads me to another question: do you use the standard paris-traceroute arguments to perform this or is it a customized version ? The actual question might be: how is the instance ID encoded in the packet ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From philip.homburg at ripe.net Mon Jul 23 14:04:45 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 23 Jul 2012 14:04:45 +0200 Subject: [atlas] Concurrent traceroute issues on the probes In-Reply-To: <500D1200.8050303@student.uclouvain.be> References: <500CEC0A.8060900@student.uclouvain.be> <500D0B27.7000603@ripe.net> <500D1200.8050303@student.uclouvain.be> Message-ID: <500D3DDD.2090305@ripe.net> On 7/23/12 10:57 , David Lebrun wrote: > On 07/23/2012 05:28 PM, Philip Homburg wrote: >> Yes, which instance it is, is encoded in the packet that is sent out. > Ok thanks. This leads me to another question: do you use the standard > paris-traceroute arguments to perform this or is it a customized version > ? The actual question might be: how is the instance ID encoded in the > packet ? > I didn't try to follow existing traceroute implementations. There are now 8 variations of traceroute: v4/v6 UDP/ICMP paris or non-paris. For v4/UDP/paris, the instance id is put in the source port. From philip.homburg at ripe.net Mon Jul 23 14:22:52 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 23 Jul 2012 14:22:52 +0200 Subject: [atlas] Probe down? In-Reply-To: <50096C61.8010304@net.ipl.pt> References: <7DD1D52C-7028-43DE-9FCC-532D41460C3C@gmail.com> <50096C61.8010304@net.ipl.pt> Message-ID: <500D421C.1050801@ripe.net> On 7/20/12 16:34 , Pedro Ribeiro wrote: > Same problem here, since July 1. > > I've sent some debug info to the Atlas team, still waiting for answers. > It is not the same problem. Your probe seems to work fine except from one (important) part. I have no explanation for your probe's behavior. Something seems to have gone wrong with your ticket. I thought I asked Alastair to organize exchanging the probe. I that didn't happen. Sorry. From robert at ripe.net Mon Jul 23 14:47:02 2012 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 23 Jul 2012 14:47:02 +0200 Subject: [atlas] High inbound traffic causing packet loss? In-Reply-To: <500BFA09.5080700@ojdip.net> References: <500BFA09.5080700@ojdip.net> Message-ID: <500D47C6.9070708@ripe.net> Hi, On 2012.07.22. 15:03, Tibor Djurica Potpara wrote: > I've attached the probe directly to the ISP-provided switch that doesn't do > IGMP snooping and since IP multicast is used for IPTV, high traffic (up to > 50 Mbps) is occasionally flooded to all the switch ports. Taking into > account that the probe is underpowered in terms of CPU, is it possible that > it cannot handle such traffic and thus reports packet loss? > > If such is the case, I will move the probe behind a router to filter the > multicast streams out. I'd think that if your network is really flooded, then a packet loss observed by your probe is not that unexpected. Most likely it happens to other devices too, you just don't notice because you're not constantly measuring? Having said this, moving the probe to behind the router will probably help. Regards, Robert From robert at ripe.net Mon Jul 23 14:56:32 2012 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 23 Jul 2012 14:56:32 +0200 Subject: [atlas] Embedd built-in measurement page into website In-Reply-To: References: Message-ID: <500D4A00.7000107@ripe.net> On 2012.07.22. 14:31, Bartsch, Rene wrote: > Hi, > > is there any way to embedd the "Built-in Measurements"-JQuery-Frame of my > probes into a publically accessible website? > > Thanx for any hint, > > Renne Hello, It is theoretically possible, one has to link to https://atlas.ripe.net/atlas/probeconn.html?prb_id=XXXX However, this page needs authentication, so simply embedding the contents into a web page will not work right away. (It does work if the visitor is logged in in RIPE NCC Access and has the right to load this page, but that's not really your intention.) We are working on a solution that can do this, by using "API keys" -- the concept that has already been introduced in the LIR portal. See https://labs.ripe.net/Members/AlexBand/lir-portal-api-keys for details. Using this approach, one will be able to share the views/data with others, including "the public". Regards, Robert From robert at ripe.net Mon Jul 23 15:03:56 2012 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 23 Jul 2012 15:03:56 +0200 Subject: [atlas] Fwd: [ipv6-wg] New on RIPE Labs: Test your IPv6 Reachability by Using RIPE Atlas (now visualised) In-Reply-To: <5006BDFC.503@serverflow.com> References: <510a9307cb61e4b6976364369449f999@mail.kix.es> <20120718155126.13c3f732@natsu> <50069DE5.2030007@ripe.net> <20120718130813.GA72117@ussenterprise.ufp.org> <5006BDFC.503@serverflow.com> Message-ID: <500D4BBC.9060309@ripe.net> On 2012.07.18. 15:45, Matija Grabnar wrote: > On 07/18/2012 03:08 PM, Leo Bicknell wrote: >> To that end, if RIPE could produce a template/example in a few popular >> languages (perl, python, ruby, php) to download the JSON and parse into >> the native language data structure that could get a LOT more folks using >> the data... >> > > You can fins a bunch of decoders in more languages than I count on > http://www.json.org/ Hi, It's really nice to see the community in action :-) It is a rather encouraging sign to us! To answer Leo's original question from a different perspective: the result data you get from Atlas is a structured piece of information. We had to choose a specific encoding, and we opted for JSON (as opposed to YAML, XML, etc.) because in many cases that can be directly used in client side applications. We *could* supply other formats too, but no matter what the encoding is, you need some kind of client library to parse it. Regards, Robert From robert at ripe.net Mon Jul 23 15:13:43 2012 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 23 Jul 2012 15:13:43 +0200 Subject: [atlas] Sharing Stats? In-Reply-To: <4FA7BA76.6030908@ripe.net> References: <20120505132358.35d8fa31@columbia> <4FA7BA76.6030908@ripe.net> Message-ID: <500D4E07.2000301@ripe.net> Dear All, To come back to this one: the introduction of "API keys" (see previous mails) is also meant to facilitate sharing of such graphs and data. Please stay tuned! Regards, Robert On 2012.05.07. 14:05, Vesna Manojlovic wrote: > Dear Dan, all, > > On 5/7/12 12:47 PM, Dan Luedtke wrote: >> What do the RIPE people think? > > Thank you for your interest & your suggestion - good idea! > > Also thanks to all the rest of you, who supported Dan's suggestion & > clariefied how would you wanted it implemented... > >> Do we have a chance to get that idea on the roadmap? > > Yes, we've heard you, and added it to the list of wanted features. > > However, it will have to wait till after 6th June (World IPv6 Launch Day), > since until then we are busy implementing specific measurements and features > that are IPv6-related. > > > Regards, > Vesna From david.lebrun at student.uclouvain.be Mon Jul 23 15:15:08 2012 From: david.lebrun at student.uclouvain.be (David Lebrun) Date: Mon, 23 Jul 2012 22:15:08 +0900 Subject: [atlas] Concurrent traceroute issues on the probes In-Reply-To: <500D3DDD.2090305@ripe.net> References: <500CEC0A.8060900@student.uclouvain.be> <500D0B27.7000603@ripe.net> <500D1200.8050303@student.uclouvain.be> <500D3DDD.2090305@ripe.net> Message-ID: <500D4E5C.1030009@student.uclouvain.be> On 07/23/2012 09:04 PM, Philip Homburg wrote: > I didn't try to follow existing traceroute implementations. > > There are now 8 variations of traceroute: v4/v6 UDP/ICMP paris or > non-paris. For v4/UDP/paris, the instance id is put in the source port. Okay, thanks for your answers ! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From renne.bartsch at googlemail.com Mon Jul 23 15:19:00 2012 From: renne.bartsch at googlemail.com (Bartsch, Rene) Date: Mon, 23 Jul 2012 13:19:00 +0000 Subject: [atlas] Fwd: [ipv6-wg] New on RIPE Labs: Test your IPv6 Reachability by Using RIPE Atlas (now visualised) In-Reply-To: <500D4BBC.9060309@ripe.net> References: <510a9307cb61e4b6976364369449f999@mail.kix.es> <20120718155126.13c3f732@natsu> <50069DE5.2030007@ripe.net> <20120718130813.GA72117@ussenterprise.ufp.org> <5006BDFC.503@serverflow.com> <500D4BBC.9060309@ripe.net> Message-ID: <23c2a7f5b87a1da2b05c7df726347c0b44447c33@googlemail.com> Am 23.07.2012 15:04:07, schrieb Robert Kisteleki: > On 2012.07.18. 15:45, Matija Grabnar wrote: > > On 07/18/2012 03:08 PM, Leo Bicknell wrote: > >> To that end, if RIPE could produce a template/example in a few popular > >> languages (perl, python, ruby, php) to download the JSON and parse into > >> the native language data structure that could get a LOT more folks using > >> the data... > >> > > > > You can fins a bunch of decoders in more languages than I count on > > > http://www.json.org/ > > Hi, > > It's really nice to see the community in action :-) It is a rather > encouraging sign to us! > > To answer Leo's original question from a different perspective: the result > data you get from Atlas is a structured piece of information. We had to > choose a specific encoding, and we opted for JSON (as opposed to YAML, XML, > etc.) because in many cases that can be directly used in client side > applications. We *could* supply other formats too, but no matter what the > encoding is, you need some kind of client library to parse it. > In my opinion, JSON is the best solution as it is strictly UTF-8 (yes, no garbled characters, anymore!) and either server-side PHP-functions or client-side Javascript-functions can decode it directly into multi-dimensional objects or arrays. And you can encode any Javascript- or PHP-datatype into JSON with one function call. Regards, Renne -- Sent with love from the new tine 2.0 email client ... Please visit http://tine20.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at wjw.co.nz Mon Jul 23 20:05:37 2012 From: bill at wjw.co.nz (Bill Walker) Date: Tue, 24 Jul 2012 06:05:37 +1200 Subject: [atlas] Probe down? In-Reply-To: <500D421C.1050801@ripe.net> References: <7DD1D52C-7028-43DE-9FCC-532D41460C3C@gmail.com> <50096C61.8010304@net.ipl.pt> <500D421C.1050801@ripe.net> Message-ID: I've just power cycled it, let's see if it comes back online Sent from my Phone On 24/07/2012, at 12:22 AM, Philip Homburg wrote: > On 7/20/12 16:34 , Pedro Ribeiro wrote: >> Same problem here, since July 1. >> >> I've sent some debug info to the Atlas team, still waiting for answers. >> > It is not the same problem. Your probe seems to work fine except from one (important) part. I have no explanation for your probe's behavior. > > Something seems to have gone wrong with your ticket. I thought I asked Alastair to organize exchanging the probe. I that didn't happen. Sorry. > From tis at foobar.fi Tue Jul 24 10:16:56 2012 From: tis at foobar.fi (Tuomo Soini) Date: Tue, 24 Jul 2012 11:16:56 +0300 Subject: [atlas] 128.0.0.1 and 128.0.24.1 measurements Message-ID: <20120724111656.7f474929@evelb.foobar.fi> Should these measurements be discontinued? These networks are no more visible. http://www.ris.ripe.net/dashboard/128.0.24.0/24 http://www.ris.ripe.net/dashboard/128.0.0.0/21 -- Tuomo Soini Foobar Linux services +358 40 5240030 Foobar Oy From robert at ripe.net Tue Jul 24 10:41:26 2012 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 24 Jul 2012 10:41:26 +0200 Subject: [atlas] 128.0.0.1 and 128.0.24.1 measurements In-Reply-To: <20120724111656.7f474929@evelb.foobar.fi> References: <20120724111656.7f474929@evelb.foobar.fi> Message-ID: <500E5FB6.5000608@ripe.net> On 2012.07.24. 10:16, Tuomo Soini wrote: > Should these measurements be discontinued? These networks are no more > visible. > > http://www.ris.ripe.net/dashboard/128.0.24.0/24 > http://www.ris.ripe.net/dashboard/128.0.0.0/21 Indeed they should, as debogonising has been stopped. In fact we stopped these measurements as of 2012-07-16, but on the UI they were not marked as such. Now we pushed out this tiny change. Regards, Robert From renne.bartsch at googlemail.com Tue Jul 24 18:27:09 2012 From: renne.bartsch at googlemail.com (Bartsch, Rene) Date: Tue, 24 Jul 2012 16:27:09 +0000 Subject: [atlas] Port blocking statistics Message-ID: Hi, when charting the internet it would be useful to have an oversight about ISPs blocking ports. Especially discussions about network neutrality should be based on hard facts instead of polemic discussions. So I suggest to check the connectivity of the protocols listed in http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt once a week as built-in measurement. Best regards, Renne -- Sent with love from the new tine 2.0 email client ... Please visit http://tine20.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From colinj at mx5.org.uk Tue Jul 24 19:24:09 2012 From: colinj at mx5.org.uk (Colin Johnston) Date: Tue, 24 Jul 2012 18:24:09 +0100 Subject: [atlas] Port blocking statistics In-Reply-To: References: Message-ID: On 24 Jul 2012, at 17:27, Bartsch, Rene wrote: > Hi, > > when charting the internet it would be useful to have an oversight about ISPs blocking ports. > > Especially discussions about network neutrality should be based on hard facts instead of polemic discussions. > > So I suggest to check the connectivity of the protocols listed in http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt once a week as built-in measurement. > Yes would be useful to map blocking via endpoints, had to use vpn from venice back to uk via google tablet since wireless hotspot blocked ssh for some unknown reason. Colin -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe at my-rz.de Wed Jul 25 13:54:36 2012 From: ripe at my-rz.de (Axel) Date: Wed, 25 Jul 2012 13:54:36 +0200 Subject: [atlas] Port blocking statistics In-Reply-To: References: Message-ID: <20120725135436.Horde.eFe8OMhos6lQD958ykZCH0A@ssl.my-rz.de> Hi, Zitat von "Bartsch, Rene" : > when charting the internet it would be useful to have an oversight > about ISPs blocking ports. This is a great idea and I would love to see this somewhere. But you always have to keep in mind that this also depends on the firewall rules that everybody has in his personal network and this does not necessarily reflect the ISP settings. Kind Regards Axel From renne.bartsch at googlemail.com Wed Jul 25 14:37:54 2012 From: renne.bartsch at googlemail.com (Bartsch, Rene) Date: Wed, 25 Jul 2012 12:37:54 +0000 Subject: [atlas] Port blocking statistics In-Reply-To: <20120725135436.Horde.eFe8OMhos6lQD958ykZCH0A@ssl.my-rz.de> References: <20120725135436.Horde.eFe8OMhos6lQD958ykZCH0A@ssl.my-rz.de> Message-ID: Am 25.07.2012 14:04:56, schrieb Axel: > Hi, > > Zitat von "Bartsch, Rene" <> renne.bartsch at googlemail.com> >: > > when charting the internet it would be useful to have an oversight > > about ISPs blocking ports. > > This is a great idea and I would love to see this somewhere. But you > always have to keep in mind that this also depends on the firewall > rules that everybody has in his personal network and this does not > necessarily reflect the ISP settings. In case of IADs the ISP sets the firewall rules => ISP-side port blocking. Outgoing connections are usually filtered by companies, but not by residentials. => You get an good intersection if there are some hundred probes per ISP in the future. Renne -- Sent with love from the new tine 2.0 email client ... Please visit http://tine20.org -------------- next part -------------- An HTML attachment was scrubbed... URL: