- ripe-atlas - mailman.ripe.net

Port blocking statistics
by Bartsch, Rene 25 Jul '12

25 Jul '12

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-po… 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

3 3

128.0.0.1 and 128.0.24.1 measurements
by Tuomo Soini 24 Jul '12

24 Jul '12

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 <tis(a)foobar.fi> Foobar Linux services +358 40 5240030 Foobar Oy <http://foobar.fi/>

2 1

Probe down?
by Yoann Gini 23 Jul '12

23 Jul '12

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.

5 5

Fwd: [ipv6-wg] New on RIPE Labs: Test your IPv6 Reachability by Using RIPE Atlas (now visualised)
by kix 23 Jul '12

23 Jul '12

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 <mir(a)ripe.net> Destinatario: ipv6-wg(a)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-us… Kind Regards, Mirjam Kuehne RIPE NCC -- Rodolfo García Peñas (kix) http://www.kix.es

7 7

Concurrent traceroute issues on the probes
by David Lebrun 23 Jul '12

23 Jul '12

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

2 4

Embedd built-in measurement page into website
by Bartsch, Rene 23 Jul '12

23 Jul '12

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

2 1

High inbound traffic causing packet loss?
by Tibor Djurica Potpara 23 Jul '12

23 Jul '12

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

2 1

Flood-ping to measure packet loss?
by Bartsch, Rene 18 Jul '12

18 Jul '12

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 <destination>) for detection of packet loss? Best regards, Renne -- Sent with love from the new tine 2.0 email client ... Please visit http://tine20.org

3 3

Firmware 4470 to be released soon
by Ann Barcomb 11 Jul '12

11 Jul '12

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

2 1

Atlas infrastructure issues on Friday, 2012-06-29
by Robert Kisteleki 03 Jul '12

03 Jul '12

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

1 0