Comcast XFINITY → [Connectivity] Help measure the global Internet!

I run an HE tunnel on my ASUS RT-AC66R and the probe pulled an IPv6 address right away. I don't recall doing anything special with it.

If your router is assigning IPv6 addresses to LAN clients using DHCPv6, the Atlas probe will not get an IPv6 address because it only uses SLAAC for auto assignment of IPv6 addresses. I initially connected my probe directly to a switch behind my cable modem (I have a five IP address account with Comcast), and it got an IPv4 address, but not an IPv6 address because Comcast uses DHCPv6 for IPv6 address assignments. After I placed the Atlas probe behind a router that did not use DHCPv6 for LAN clients (it uses SLAAC/RDNSS), it immediately got a SLAAC assigned IPv6 address (but I have no way of knowing if your router is capable of doing that).

Try restarting/reseting the probe.
while they seem to prefer v6 if they don't get it first they will use v4.

By default, the probe will pull a SLAAC IPv6 address (via router advertisement / router solicitation).

Do you have router advertisements enabled for the subnet containing your probe?

Not sure about the SLAAC part but did do a reboot. Didn't see it pull an IP but in the web access logs it is listed with a v6 address and the atlas probe website is registering v6 pings now.

Proposing more public RIPE Atlas data and clarifying the current situation

A follow-up message posted on the RIPE Atlas mailing list that is worth a read (imo).

---

Vesna Manojlovic BECHA at ripe.net
Thu Jan 9 16:22:48 CET 2014

Dear colleagues,

Three weeks ago, the RIPE NCC published a clarification about the
current state of RIPE Atlas public measurement data and the privacy of
probe data. We also proposed making some changes to the current situation.

There has been some lively discussion about our proposal to make the
probe and measurement data public for new and existing users starting at
a future date.

Most comments did not support this proposal. Some people are in favour
of keeping the situation as it is (i.e. making it possible to opt out of
making your measurements public), while others proposed an alternative
solution of delaying the publication of measurement data for a day (or a
week).

We'd like to hear more opinions, either for or against any of these
proposals, including your motivation or the use case you have in mind.

Please take part in the discussion on the mailing list.

We will consider your input and come up with an updated proposal in
February.

Regards,

Vesna
Measurements Community Building
RIPE NCC

---

The message thread can be read here:
»www.ripe.net/ripe/mail/a ··· 260.html

 
RIPE 2013 status update.

»labs.ripe.net/Members/mi ··· n-review

My probe has now been online for slight over 6 months
(Total Uptime: 96.51% (191d, 22h, 19m) ) for some reason it went off line for a day several times in the last month.

I notice the "drop-outs" as well.

Sometimes I suspect they are caused by occasional early morning maintenance on Comcast's part (it looks like we're getting real close to IPv6 here, and Netdog is probably working on the equipment ).

Other times, (more rare) I suspect RIPE has a head-end issue or two.

I have noticed that the RIPE Atlas Probe seems to be very picky about what it considers to be a "connection". My probe's log shows connection drops ranging from minutes to hours every few days. OTOH, the router it is behind shows no indication in its logs of a connection drop, and the two VoIP ATAs that share the same router also do not show any indication of a connection drop in their logs. Since the VoIP ATAs maintain a continuous session to their respective servers (which should make any actual connection drop quite visible in their logs), I can only conclude that the Atlas Probe connection drops being reported are either in the RIPE infrastructure, or are just brief glitches in the international routing.

I agree, AT LEAST half of all "outages" aren't at this end, often aren't actual outages or are due to shifting back and forth between v4 and v6 addresses.
however 2 complete missing days here the probe began a strange flashing sequence which lasted all day and then resolved itself.
my modem and main router have been up 27 days without problems so it's likely a ripe problem (1 other day was a known outage at their end for an upgrade) or the probe beginning to fail.

 
My webcam sends out an image every two minutes. I see connection issues in that log in the early morning hours (no other time).

The frequency of those connection issues ramped up about the time, and since the time, the management side of my cable modem switched from IPv4 to IPv6. That's what led me to think that Comcast is doing some work here.

  
They could maintain a "connectionless session". A session is at the application level, not the networking level.

For example, when you do online banking, the bank's application places a session cookie on your disk to track the session. The HTTP connection between your browser and the bank is in place only when data are actually being sent back and forth. While you are reading the web page, there is no connection to the bank by your browser, even though there is an active session in place.

 
Check out the link to the head-end issue that I posted a couple of minutes ago. RIPE did have some sustained problems.

OK, so the ATA has a "heartbeat" that tells the server it is still alive, that is the data that is being sent over the connection.

You're right, it is different than the HTTP session I cited. In the HTTP session, the "heartbeat" (requesting a new page) can be seconds to minutes between requests.

Based upon what you said, (and I had to do some reading between the lines), the heartbeat portion of the VoIP application sends data to the server every 60-70mS, therefore being able to detect a network outage of 70mS or less.

Thanks for the follow-up.

Bumping thread to hopefully keep the discussion alive. Took me a bit to find.

How are we doing on credits tshirt?

This is how I'm doing.

2,006,329.00

450.00 credits / hour

I'm the only probe in Northwestern California, and one of only a handful in NorCal north of SF and Sacramento.

Some traffic measurements for the Atlas. I have the Atlas on its own subnet (on the rl0 network interface), so the traffic is all the probe's. (Dec 2013 and (obviously) Mar 2014 are partial months)

 rl0  /  monthly

       month        rx      |     tx      |    total    |   avg. rate
    ------------------------+-------------+-------------+---------------
      2013-12    297.45 MiB |  297.24 MiB |  594.69 MiB |     0.23 KiB/s
      2014-01    479.54 MiB |  473.86 MiB |  953.40 MiB |     0.36 KiB/s
      2014-02    425.57 MiB |  442.21 MiB |  867.78 MiB |     0.37 KiB/s
      2014-03     52.57 MiB |   53.32 MiB |  105.89 MiB |     0.36 KiB/s
    ------------------------+-------------+-------------+---------------
 

 rl0  /  weekly

                      rx      |     tx      |    total    |   avg. rate
   ---------------------------+-------------+-------------+---------------
    last 7 days     99.47 MiB |  100.96 MiB |  200.43 MiB |     0.37 KiB/s
      last week    109.08 MiB |  110.72 MiB |  219.80 MiB |     0.37 KiB/s
   current week     21.84 MiB |   22.16 MiB |   44.00 MiB |     0.35 KiB/s
   ---------------------------+-------------+-------------+---------------
 

 rl0  /  daily

         day         rx      |     tx      |    total    |   avg. rate
     ------------------------+-------------+-------------+---------------
     2014-02-03    15.01 MiB |   15.09 MiB |   30.10 MiB |     0.36 KiB/s
     2014-02-04    14.76 MiB |   14.81 MiB |   29.57 MiB |     0.35 KiB/s
     2014-02-05    14.93 MiB |   16.71 MiB |   31.63 MiB |     0.37 KiB/s
     2014-02-06    14.87 MiB |   14.91 MiB |   29.78 MiB |     0.35 KiB/s
     2014-02-07    14.88 MiB |   15.02 MiB |   29.91 MiB |     0.35 KiB/s
     2014-02-08    14.78 MiB |   15.08 MiB |   29.87 MiB |     0.35 KiB/s
     2014-02-09    14.82 MiB |   15.13 MiB |   29.95 MiB |     0.35 KiB/s
     2014-02-10    14.95 MiB |   15.10 MiB |   30.05 MiB |     0.36 KiB/s
     2014-02-11    14.87 MiB |   15.46 MiB |   30.33 MiB |     0.36 KiB/s
     2014-02-12    14.84 MiB |   15.15 MiB |   29.99 MiB |     0.36 KiB/s
     2014-02-13    14.89 MiB |   15.17 MiB |   30.06 MiB |     0.36 KiB/s
     2014-02-14    14.92 MiB |   15.22 MiB |   30.14 MiB |     0.36 KiB/s
     2014-02-15    14.76 MiB |   15.10 MiB |   29.86 MiB |     0.35 KiB/s
     2014-02-16    14.92 MiB |   15.06 MiB |   29.98 MiB |     0.36 KiB/s
     2014-02-17    14.87 MiB |   15.15 MiB |   30.02 MiB |     0.36 KiB/s
     2014-02-18    15.25 MiB |   24.55 MiB |   39.79 MiB |     0.47 KiB/s
     2014-02-19    15.66 MiB |   15.90 MiB |   31.56 MiB |     0.37 KiB/s
     2014-02-20    15.84 MiB |   16.00 MiB |   31.85 MiB |     0.38 KiB/s
     2014-02-21    15.72 MiB |   15.79 MiB |   31.51 MiB |     0.37 KiB/s
     2014-02-22    15.73 MiB |   15.91 MiB |   31.64 MiB |     0.38 KiB/s
     2014-02-23    15.67 MiB |   15.88 MiB |   31.56 MiB |     0.37 KiB/s
     2014-02-24    15.74 MiB |   15.95 MiB |   31.68 MiB |     0.38 KiB/s
     2014-02-25    15.71 MiB |   15.97 MiB |   31.68 MiB |     0.38 KiB/s
     2014-02-26    15.66 MiB |   15.93 MiB |   31.59 MiB |     0.37 KiB/s
     2014-02-27    15.65 MiB |   15.87 MiB |   31.53 MiB |     0.37 KiB/s
     2014-02-28    15.63 MiB |   15.87 MiB |   31.50 MiB |     0.37 KiB/s
     2014-03-01    15.66 MiB |   15.91 MiB |   31.57 MiB |     0.37 KiB/s
     2014-03-02    15.03 MiB |   15.22 MiB |   30.25 MiB |     0.36 KiB/s
     2014-03-03    14.78 MiB |   14.98 MiB |   29.76 MiB |     0.35 KiB/s
     2014-03-04     7.09 MiB |    7.22 MiB |   14.31 MiB |     0.36 KiB/s
     ------------------------+-------------+-------------+---------------

Tshirt. I just sent you a million, four hundred thousand credits.

sorry for the delayed response
We're fine on credits, with Wayne99021 's bump putting us back over 40 Million.

From the RIPE Atlas mailing list:
»www.ripe.net/ripe/mail/a ··· 355.html

Daniel Quinn dquinn at ripe.net
Wed Mar 5 13:45:57 CET 2014

Dear colleagues,

As Mirjam announced late last week, we've created a new interface for
probe information on RIPE Atlas. Today we've set this as the default,
so when you navigate to "My Atlas > Probes", you will get the new
interface in place of the old one.

You can read more about the new layout on RIPE Labs:

»labs.ripe.net/Members/su ··· be-pages

or just visit the pages yourself when you have some time:

»atlas.ripe.net/probes/

Ditto
»www.ripe.net/ripe/mail/a ··· 354.html

Robert Kisteleki robert at ripe.net
Wed Mar 5 10:54:19 CET 2014

On 2014.02.12. 10:02, Suzanne Taylor Muzzin wrote:
> Dear colleagues,
>
> Please find a new article on RIPE Labs that explains how you can get the most out of the Seismograph, an interactive RIPE Atlas tool that provides an overview of different RTT and packet loss trends measured by multiple probes.
>
> The Seismograph User Guide
> »labs.ripe.net/Members/ma ··· er-guide
>
> Kind regards,
>
> Suzanne Taylor Muzzin
> Measurements Community Building
> RIPE NCC

Dear colleagues,

The above article reiterated our previous communication about
decommissioning the RRD style ping visualisations:

"The Seismograph is the new way to visualise ping user-defined measurements
within RIPE Atlas, and is meant to replace the old ping visualisations
(under the RRDs tab), which we will decommission at the end of February 2014."

Based on this, we began to remove the old graphs.

Regards,
Robert

new interface is much nicer, but takes a little getting used too, compared to the old. Actually much easier to find a watch what a given probe is doing.

Encouraging RIPE Atlas users to choose for public probes and measurements

From the mailing list:
»www.ripe.net/ripe/mail/a ··· 359.html

Vesna Manojlovic BECHA at ripe.net
Tue Mar 11 11:17:35 CET 2014

Dear colleagues,

One of the main goals of RIPE Atlas is to share information about
Internet performance, which we collect via the active measurements
performed by the thousands of probes in the RIPE Atlas network.
In order to better achieve that goal, last year we suggested making even
more of the collected data public. You can read the full details of this
proposal on RIPE Labs:

»labs.ripe.net/Members/be ··· e-public

We asked for feedback about this proposal from the RIPE Atlas community
and, based on that feedback, we have decided not to go ahead with the
proposal or make any major changes to the system.

We would therefore like to revise our original proposal and suggest the
following, revised plan:

1. We will strongly encourage RIPE Atlas users to keep their RIPE Atlas
probes public and to perform public measurements as much as possible by:

- Making new probes public by default (opt-out available) whenever
someone applies for a new probe
- Checking the public option by default when using the web interface to
create user-defined measurements
- Rewarding those who make their probes and measurements public by
giving them more credits than those who don’t
- Requiring all research enabled by special credits to produce public
measurement results
- Stressing the public nature of RIPE Atlas as a measurements platform
in the RIPE NCC's publications and outreach

2. We will continue to allow users to *not* mark their probes public and
to schedule user-defined measurements that are not public.

3. We will improve the documentation in order to clarify exactly what
information is available for probes and user-defined measurements that
are marked public versus those not marked public.

Because this revised plan does not involve making any significant
changes to our procedures or interfaces, the implementation would take
place during our regular deployment cycle.

We are basing this revised plan on the reactions of the 13 RIPE Atlas
users who provided feedback after we proposed our original plan (you can
find more details about the feedback we received below).

We would like to hear from more of you, even if you just confirm that
you agree with this revised proposal.

Regards,

Vesna Manojlovic
Senior Community Builder for Measurements Tools
RIPE NCC

Summary of the feedback
(the original comments can also be found on the RIPE Atlas mailing list
archives):

Eleven people replied on the mailing list and two replied on RIPE Labs,
with some people supporting more than one option.

- Three people supported making the data more public
- Six people supported keeping things the same (i.e. against removing
the "not public" option)
- One person suggested making the data less public
- Three people suggested delaying the publication of the public results
(a new suggestion)
- One person was completely neutral

Specific comments included:

- Making the data public by default is okay, but leave the option to not
make it public
- If a delay in making the data public is introduced, one-off
measurements should be excluded
- A delay in making the data public will introduce more complexity to
the system
- A proposal to receive extra/fewer credits for making probes and
measurements public/not public, respectively

How are we doing on points? I have nearly 6 million that are just sitting there. If I could just turn them into Bitcoins! ...

I'll take them.
the 2 experiments continue to run, but I've temporarily disconnected my own probe (after 270+days/9 months) to troubleshoot, either my probe is dying or it doesn't like the new channels, still being tweaked in my area, keeps losing v6 and getting stuck offline.

Did your probe receive the new 4610 firmware upgrade? I was having problems with my probe going offline for IPv6 until it received the 4610 firmware several weeks ago.

Shown below is a snapshot I just took. I still see brief glitches in its IPv6 responses for the internal tests, but it used to go invisible for IPv6 for multiple hours (or even days) at a time prior to the 4610 firmware upgrade. During those previous IPv6 blackouts, I could not even do a ping6 to it (and it would disappear from the router's IPv6 device table), but after the 4610 firmware upgrade, it seems to be IPv6 active all the time.

Yes it did recivie the 4610 and was going fine, but at that point Comcast opened up moved me to 4 lower (25-28vs 29-32 before) channels which are still seeing occasional noise bursts and occasionally going offline. just the usual plant cleaning and tuning sequence getting better/not yet prefect.
all good but the reboots (by then or me, sometimes get a v4 first and need another boot before the probe is happy (not the probes fault, but it is the least stable device on my network right now.) I'll play with it some more next week or maybe get it replaced.

BTW those wishing to send credits can do like this
(copied from older post)
»[Connectivity] Help measure the global Internet!

Any host with spare credits wishing to transfer some credits can do so at their RIPE Atlas "my credits" page under the "transfer" tab to the email
tshirtripeprobeATcomcast.net.
AT=@

Thanks to ctgreybeard and all the others who keep sending them in.