Re: Proving Gig Speed

[Michael Thomas]

Thanks, Jason.

While I might have idle curiosity of how well my link performs when I 
first get it, beyond that the only time I care is when I or somebody 
else in the house starts screaming "THE INTERTOOBZ R SLOWZ!@!".


I just had this happen to me the other night as I trying to watch 
possibly the worst movie ever on Amazon Prime. Maybe because I've been 
around a long time, my first suspicion is that something at home was 
slagging the ISP hop. This is often the case, but it is *maddeningly* 
slow to diagnose -- my popcorn was getting stale. Naively, I may have 
thought to hook up to one of the speed testers, but it would only show 
what was obvious from ping times, etc: lots of drops.


So where was the problem? I had to manually go around and start 
disconnecting things. Even after I thought I had found the perp several 
times, my popcorn's freshness suffered. And in the end, I never did 
triangulate out where the problem was... and by morning it had magically 
fixed itself. My popcorn, on the other hand, gave its all.


As we get more and more stuff on our home networks, the probability for 
crappy software, infected devices, piggy updates, etc multiplies. I'm 
sure this isn't news to $CORPRO network managers, but at home we quite 
literally have nothing to help us figure out and remedy these kinds of 
problems. Or if it turns out to *not* be our problem, that we have some 
reassurance when we decide to call the support desk and be put through 
IVR maze hell only to find out it was a local problem after all.


cheers, Mike


On 7/16/18 1:27 PM, Livingood, Jason wrote:

I recently talked at the IRTF on this subject and followed up with a blog post 
at 
https://blog.apnic.net/2018/06/21/measurement-challenges-in-the-gigabit-era/. 
There's also an open source speed test project you may want to consider at 
https://github.com/Comcast/Speed-testJS.

Jason

On 7/16/18, 2:00 PM, "NANOG on behalf of Chris Gross"  wrote:

 I'm curious what people here have found as a good standard for providing 
solid speedtest results to customers. All our techs have Dell laptops of 
various models, but we always hit 100% CPU when doing a Ookla speedtest for a 
server we have on site. So then if you have a customer paying for 600M or 1000M 
symmetric, they get mad and demand you prove it's full speed. At that point we 
have to roll out different people with JDSU's to test and prove it's functional 
where a Ookla result would substitute fine if we didn't have crummy laptops 
possibly. Even though from what I can see on some google results, we exceed the 
standards several providers call for.
 
 Most of these complaints come from the typical "power" internet user of course that never actually uses more than 50M sustained paying for a residential connection, so running a circuit test on each turn up is uncalled for.
 
 Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop that can actually do symmetric gig, a rugged small inexpensive device we can roll with instead to prove, or any other weird solution involving ritual sacrifice that isn't too offensive to the eyes?
 

Re: Proving Gig Speed

[James R Cutler]

> On Jul 16, 2018, at 4:31 PM, Carlos Alcantar  wrote:
> 
> It's a complete rabbit hole different hardware with different browsers give 
> different readings, even not having your laptop plugged into power can cause 
> a change in results due to dropping cpu to power save.  The only reliable 
> solution we found for field techs was the exfo ex1.Still talks to the 
> ookla speedtest server etc.  Obvious this is a well known issue and exfo has 
> a solution.
> 
> 
> 
> https://www.exfo.com/en/products/field-network-testing/network-protocol-testing/ethernet-testing/ex1/
> 
> 
> 


This is an interesting device. But the manufactures pages promote it like 
“Speedtest for Dummies”.

Why don’t the User Manual or Spec Sheet mention IPv6 (or even (IPv4)?

I should think technicians would want technical answers.

Cutler


> 
> 
> Carlos Alcantar
> 
> Race Communications / Race Team Member
> 
> Phone: +1 415 376 3314 / car...@race.com / 
> http://www.race.com
> 
> 
> 
> 
> From: NANOG  on behalf of Chris Gross 
> 
> Sent: Monday, July 16, 2018 12:39 PM
> To: Matt Erculiani
> Cc: North American Network Operators' Group
> Subject: RE: Proving Gig Speed
> 
> Winner winner chicken dinner. I forgot to pull "Antivirus is at fault" card 
> from my deck. 250/675 with it installed, 920/920 when removed so now I get to 
> pass the the issue onwards.
> 
> Thanks everyone for your replies and the responses for the 
> adolfintel/speedtest github, I'll definitely look at it as a replacement for 
> later.
> 
> -Original Message-
> From: Matt Erculiani 
> Sent: Monday, July 16, 2018 2:17 PM
> To: Chris Gross 
> Cc: North American Network Operators' Group 
> Subject: Re: Proving Gig Speed
> 
> We use Iperf3 for customers that complain about throughput, it's relatively 
> low overhead compared to the Ookla HTML5 client. Same scenario as you, we 
> have the tech hook up their laptop to the customer's drop and perform 
> testing. I suspect your antivirus may be attempting to perform real-time 
> inspection on the http(s) traffic, which would crush the little laptop CPU 
> for sure.
> 
> Message me off-list and I'll send you a private Iperf3 server IP to test with.
> 
> -Matt
> 
> On Mon, Jul 16, 2018 at 12:58 PM, Chris Gross  
> wrote:
>> I'm curious what people here have found as a good standard for providing 
>> solid speedtest results to customers. All our techs have Dell laptops of 
>> various models, but we always hit 100% CPU when doing a Ookla speedtest for 
>> a server we have on site. So then if you have a customer paying for 600M or 
>> 1000M symmetric, they get mad and demand you prove it's full speed. At that 
>> point we have to roll out different people with JDSU's to test and prove 
>> it's functional where a Ookla result would substitute fine if we didn't have 
>> crummy laptops possibly. Even though from what I can see on some google 
>> results, we exceed the standards several providers call for.
>> 
>> Most of these complaints come from the typical "power" internet user of 
>> course that never actually uses more than 50M sustained paying for a 
>> residential connection, so running a circuit test on each turn up is 
>> uncalled for.
>> 
>> Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop 
>> that can actually do symmetric gig, a rugged small inexpensive device we can 
>> roll with instead to prove, or any other weird solution involving ritual 
>> sacrifice that isn't too offensive to the eyes?

Re: Proving Gig Speed

[Jon Meek]

On Mon, Jul 16, 2018 at 2:00 PM Chris Gross 
wrote:

> I'm curious what people here have found as a good standard for providing
> solid speedtest results to customers. All our techs have Dell laptops of
> various models, but we always hit 100% CPU when doing a Ookla speedtest for
> a server we have on site. So then if you have a customer paying for 600M or
> 1000M symmetric, they get mad and demand you prove it's full speed. At that
> point we have to roll out different people with JDSU's to test and prove
> it's functional where a Ookla result would substitute fine if we didn't
> have crummy laptops possibly. Even though from what I can see on some
> google results, we exceed the standards several providers call for.
>
> Most of these complaints come from the typical "power" internet user of
> course that never actually uses more than 50M sustained paying for a
> residential connection, so running a circuit test on each turn up is
> uncalled for.
>
> Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop
> that can actually do symmetric gig, a rugged small inexpensive device we
> can roll with instead to prove, or any other weird solution involving
> ritual sacrifice that isn't too offensive to the eyes?
>

My practice is to use iperf with packet capture on both sides. The packet
capture can then be analyzed for accurate per-second, or less, throughput,
re-transmit rates, etc. This was implemented in a corporate network in
several ways including dedicated servers (that also did other monitoring),
and bootable CDs or USB sticks that a user in a small office could run on a
standard desktop. Many interesting issues were discovered with this
technique, and a fair number of perceived issues were debunked.

Here is a wrapper to run iperf + tcpdump on each side of a connection (it
could use some automation):

 https://github.com/meekj/perl-packet-tools/blob/master/run_iperf

I originally did the analysis in Perl, but that can be fairly slow when
processing 30 seconds of packets on a saturated GigE link. If anyone is
interested there is now a C++ version along with analysis code in R at:

 https://github.com/meekj/iperfsum

That version currently has only one second resolution. I have a R interface
to libpcap files that could be used for analysis at any time resolution:

 https://github.com/meekj/libpcapR

I have a plan to implement the complete test environment in a Docker
container at some point. I also have a collection of small, mostly
low-cost, computers that I plan to benchmark for network throughput and
data analysis time. Some of the tiny computers can saturate a GigE link but
are very slow processing the data.

Jon

Re: Proving Gig Speed

[Carlos Alcantar]

It's a complete rabbit hole different hardware with different browsers give 
different readings, even not having your laptop plugged into power can cause a 
change in results due to dropping cpu to power save.  The only reliable 
solution we found for field techs was the exfo ex1.Still talks to the ookla 
speedtest server etc.  Obvious this is a well known issue and exfo has a 
solution.



https://www.exfo.com/en/products/field-network-testing/network-protocol-testing/ethernet-testing/ex1/





Carlos Alcantar

Race Communications / Race Team Member

Phone: +1 415 376 3314 / car...@race.com / 
http://www.race.com




From: NANOG  on behalf of Chris Gross 

Sent: Monday, July 16, 2018 12:39 PM
To: Matt Erculiani
Cc: North American Network Operators' Group
Subject: RE: Proving Gig Speed

Winner winner chicken dinner. I forgot to pull "Antivirus is at fault" card 
from my deck. 250/675 with it installed, 920/920 when removed so now I get to 
pass the the issue onwards.

Thanks everyone for your replies and the responses for the adolfintel/speedtest 
github, I'll definitely look at it as a replacement for later.

-Original Message-
From: Matt Erculiani 
Sent: Monday, July 16, 2018 2:17 PM
To: Chris Gross 
Cc: North American Network Operators' Group 
Subject: Re: Proving Gig Speed

We use Iperf3 for customers that complain about throughput, it's relatively low 
overhead compared to the Ookla HTML5 client. Same scenario as you, we have the 
tech hook up their laptop to the customer's drop and perform testing. I suspect 
your antivirus may be attempting to perform real-time inspection on the http(s) 
traffic, which would crush the little laptop CPU for sure.

Message me off-list and I'll send you a private Iperf3 server IP to test with.

-Matt

On Mon, Jul 16, 2018 at 12:58 PM, Chris Gross  
wrote:
> I'm curious what people here have found as a good standard for providing 
> solid speedtest results to customers. All our techs have Dell laptops of 
> various models, but we always hit 100% CPU when doing a Ookla speedtest for a 
> server we have on site. So then if you have a customer paying for 600M or 
> 1000M symmetric, they get mad and demand you prove it's full speed. At that 
> point we have to roll out different people with JDSU's to test and prove it's 
> functional where a Ookla result would substitute fine if we didn't have 
> crummy laptops possibly. Even though from what I can see on some google 
> results, we exceed the standards several providers call for.
>
> Most of these complaints come from the typical "power" internet user of 
> course that never actually uses more than 50M sustained paying for a 
> residential connection, so running a circuit test on each turn up is uncalled 
> for.
>
> Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop 
> that can actually do symmetric gig, a rugged small inexpensive device we can 
> roll with instead to prove, or any other weird solution involving ritual 
> sacrifice that isn't too offensive to the eyes?

Re: Proving Gig Speed

[Livingood, Jason]

I recently talked at the IRTF on this subject and followed up with a blog post 
at 
https://blog.apnic.net/2018/06/21/measurement-challenges-in-the-gigabit-era/. 
There's also an open source speed test project you may want to consider at 
https://github.com/Comcast/Speed-testJS. 

Jason

On 7/16/18, 2:00 PM, "NANOG on behalf of Chris Gross"  wrote:

I'm curious what people here have found as a good standard for providing 
solid speedtest results to customers. All our techs have Dell laptops of 
various models, but we always hit 100% CPU when doing a Ookla speedtest for a 
server we have on site. So then if you have a customer paying for 600M or 1000M 
symmetric, they get mad and demand you prove it's full speed. At that point we 
have to roll out different people with JDSU's to test and prove it's functional 
where a Ookla result would substitute fine if we didn't have crummy laptops 
possibly. Even though from what I can see on some google results, we exceed the 
standards several providers call for.

Most of these complaints come from the typical "power" internet user of 
course that never actually uses more than 50M sustained paying for a 
residential connection, so running a circuit test on each turn up is uncalled 
for.

Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop 
that can actually do symmetric gig, a rugged small inexpensive device we can 
roll with instead to prove, or any other weird solution involving ritual 
sacrifice that isn't too offensive to the eyes?

RE: Proving Gig Speed

[Chris Gross]

Winner winner chicken dinner. I forgot to pull "Antivirus is at fault" card 
from my deck. 250/675 with it installed, 920/920 when removed so now I get to 
pass the the issue onwards.

Thanks everyone for your replies and the responses for the adolfintel/speedtest 
github, I'll definitely look at it as a replacement for later.

-Original Message-
From: Matt Erculiani  
Sent: Monday, July 16, 2018 2:17 PM
To: Chris Gross 
Cc: North American Network Operators' Group 
Subject: Re: Proving Gig Speed

We use Iperf3 for customers that complain about throughput, it's relatively low 
overhead compared to the Ookla HTML5 client. Same scenario as you, we have the 
tech hook up their laptop to the customer's drop and perform testing. I suspect 
your antivirus may be attempting to perform real-time inspection on the http(s) 
traffic, which would crush the little laptop CPU for sure.

Message me off-list and I'll send you a private Iperf3 server IP to test with.

-Matt

On Mon, Jul 16, 2018 at 12:58 PM, Chris Gross  
wrote:
> I'm curious what people here have found as a good standard for providing 
> solid speedtest results to customers. All our techs have Dell laptops of 
> various models, but we always hit 100% CPU when doing a Ookla speedtest for a 
> server we have on site. So then if you have a customer paying for 600M or 
> 1000M symmetric, they get mad and demand you prove it's full speed. At that 
> point we have to roll out different people with JDSU's to test and prove it's 
> functional where a Ookla result would substitute fine if we didn't have 
> crummy laptops possibly. Even though from what I can see on some google 
> results, we exceed the standards several providers call for.
>
> Most of these complaints come from the typical "power" internet user of 
> course that never actually uses more than 50M sustained paying for a 
> residential connection, so running a circuit test on each turn up is uncalled 
> for.
>
> Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop 
> that can actually do symmetric gig, a rugged small inexpensive device we can 
> roll with instead to prove, or any other weird solution involving ritual 
> sacrifice that isn't too offensive to the eyes?

Re: Proving Gig Speed

[Ben Cannon]

Second the recommendation for the downloadable ookla speedtest  desktop app.

-Ben

> On Jul 16, 2018, at 11:30 AM, Mike Hammett  wrote:
> 
> Ookla does have a client that you can install in various OSes to remove 
> browser issues. 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
> 
> Midwest-IX 
> http://www.midwest-ix.com 
> 
> - Original Message -
> 
> From: "Chris Gross"  
> To: "North American Network Operators' Group"  
> Sent: Monday, July 16, 2018 12:58:20 PM 
> Subject: Proving Gig Speed 
> 
> I'm curious what people here have found as a good standard for providing 
> solid speedtest results to customers. All our techs have Dell laptops of 
> various models, but we always hit 100% CPU when doing a Ookla speedtest for a 
> server we have on site. So then if you have a customer paying for 600M or 
> 1000M symmetric, they get mad and demand you prove it's full speed. At that 
> point we have to roll out different people with JDSU's to test and prove it's 
> functional where a Ookla result would substitute fine if we didn't have 
> crummy laptops possibly. Even though from what I can see on some google 
> results, we exceed the standards several providers call for. 
> 
> Most of these complaints come from the typical "power" internet user of 
> course that never actually uses more than 50M sustained paying for a 
> residential connection, so running a circuit test on each turn up is uncalled 
> for. 
> 
> Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop 
> that can actually do symmetric gig, a rugged small inexpensive device we can 
> roll with instead to prove, or any other weird solution involving ritual 
> sacrifice that isn't too offensive to the eyes? 
> 

Re: Proving Gig Speed

[Mike Hammett]

Ookla does have a client that you can install in various OSes to remove browser 
issues. 



- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Chris Gross"  
To: "North American Network Operators' Group"  
Sent: Monday, July 16, 2018 12:58:20 PM 
Subject: Proving Gig Speed 

I'm curious what people here have found as a good standard for providing solid 
speedtest results to customers. All our techs have Dell laptops of various 
models, but we always hit 100% CPU when doing a Ookla speedtest for a server we 
have on site. So then if you have a customer paying for 600M or 1000M 
symmetric, they get mad and demand you prove it's full speed. At that point we 
have to roll out different people with JDSU's to test and prove it's functional 
where a Ookla result would substitute fine if we didn't have crummy laptops 
possibly. Even though from what I can see on some google results, we exceed the 
standards several providers call for. 

Most of these complaints come from the typical "power" internet user of course 
that never actually uses more than 50M sustained paying for a residential 
connection, so running a circuit test on each turn up is uncalled for. 

Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop that 
can actually do symmetric gig, a rugged small inexpensive device we can roll 
with instead to prove, or any other weird solution involving ritual sacrifice 
that isn't too offensive to the eyes? 

Re: Proving Gig Speed

[Max Tulyev]

Hi!

Here I have http://www.speedtest.net/result/7475546550 from my notebook
right now. It is i5-2540M CPU.

First of all, NIC is much more important than CPU. Intel NIC can give
1Gbps easy, while Realtek or Broadcom probably never gives you more than
~300mbps.

Linux times faster than Windows in the same hardware config. Speedtest
very dependent on the browser, so try different and find better with
your configuration as well.

Sometimes you will need to tune TCP stack options to have >100mbps in
one TCP session.

Speedtest usually shows good results on download, but somewhy shows slow
upload speed. Nowdays it is better, but several years ago I can't get
more than 100mbps upload in same configuration of notebook and network I
have now. Real uploads was on gig speeds.

But the best is to use IPERF to do meansurements. It is really accurate.

16.07.18 20:58, Chris Gross пише:
> I'm curious what people here have found as a good standard for providing 
> solid speedtest results to customers. All our techs have Dell laptops of 
> various models, but we always hit 100% CPU when doing a Ookla speedtest for a 
> server we have on site. So then if you have a customer paying for 600M or 
> 1000M symmetric, they get mad and demand you prove it's full speed. At that 
> point we have to roll out different people with JDSU's to test and prove it's 
> functional where a Ookla result would substitute fine if we didn't have 
> crummy laptops possibly. Even though from what I can see on some google 
> results, we exceed the standards several providers call for.
> 
> Most of these complaints come from the typical "power" internet user of 
> course that never actually uses more than 50M sustained paying for a 
> residential connection, so running a circuit test on each turn up is uncalled 
> for.
> 
> Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop 
> that can actually do symmetric gig, a rugged small inexpensive device we can 
> roll with instead to prove, or any other weird solution involving ritual 
> sacrifice that isn't too offensive to the eyes?
> 

RE: Proving Gig Speed

[Tyler Applebaum]

I have this deployed for our customers, it works well. I have yet to hear any 
complaints of not being able to max out a connection.

https://github.com/adolfintel/speedtest

-Original Message-
From: NANOG  On Behalf Of Matt Erculiani
Sent: Monday, July 16, 2018 11:17 AM
To: Chris Gross 
Cc: North American Network Operators' Group 
Subject: Re: Proving Gig Speed

We use Iperf3 for customers that complain about throughput, it's relatively low 
overhead compared to the Ookla HTML5 client. Same scenario as you, we have the 
tech hook up their laptop to the customer's drop and perform testing. I suspect 
your antivirus may be attempting to perform real-time inspection on the http(s) 
traffic, which would crush the little laptop CPU for sure.

Message me off-list and I'll send you a private Iperf3 server IP to test with.

-Matt

On Mon, Jul 16, 2018 at 12:58 PM, Chris Gross  
wrote:
> I'm curious what people here have found as a good standard for providing 
> solid speedtest results to customers. All our techs have Dell laptops of 
> various models, but we always hit 100% CPU when doing a Ookla speedtest for a 
> server we have on site. So then if you have a customer paying for 600M or 
> 1000M symmetric, they get mad and demand you prove it's full speed. At that 
> point we have to roll out different people with JDSU's to test and prove it's 
> functional where a Ookla result would substitute fine if we didn't have 
> crummy laptops possibly. Even though from what I can see on some google 
> results, we exceed the standards several providers call for.
>
> Most of these complaints come from the typical "power" internet user of 
> course that never actually uses more than 50M sustained paying for a 
> residential connection, so running a circuit test on each turn up is uncalled 
> for.
>
> Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop 
> that can actually do symmetric gig, a rugged small inexpensive device we can 
> roll with instead to prove, or any other weird solution involving ritual 
> sacrifice that isn't too offensive to the eyes?
Attention: Information contained in this message and or attachments is intended 
only for the recipient(s) named above and may contain confidential and or 
privileged material that is protected under State or Federal law. If you are 
not the intended recipient, any disclosure, copying, distribution or action 
taken on it is prohibited. If you believe you have received this email in 
error, please contact the sender with a copy to complia...@ochin.org, delete 
this email and destroy all copies.

Re: Proving Gig Speed

[Matt Erculiani]

We use Iperf3 for customers that complain about throughput, it's
relatively low overhead compared to the Ookla HTML5 client. Same
scenario as you, we have the tech hook up their laptop to the
customer's drop and perform testing. I suspect your antivirus may be
attempting to perform real-time inspection on the http(s) traffic,
which would crush the little laptop CPU for sure.

Message me off-list and I'll send you a private Iperf3 server IP to test with.

-Matt

On Mon, Jul 16, 2018 at 12:58 PM, Chris Gross
 wrote:
> I'm curious what people here have found as a good standard for providing 
> solid speedtest results to customers. All our techs have Dell laptops of 
> various models, but we always hit 100% CPU when doing a Ookla speedtest for a 
> server we have on site. So then if you have a customer paying for 600M or 
> 1000M symmetric, they get mad and demand you prove it's full speed. At that 
> point we have to roll out different people with JDSU's to test and prove it's 
> functional where a Ookla result would substitute fine if we didn't have 
> crummy laptops possibly. Even though from what I can see on some google 
> results, we exceed the standards several providers call for.
>
> Most of these complaints come from the typical "power" internet user of 
> course that never actually uses more than 50M sustained paying for a 
> residential connection, so running a circuit test on each turn up is uncalled 
> for.
>
> Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop 
> that can actually do symmetric gig, a rugged small inexpensive device we can 
> roll with instead to prove, or any other weird solution involving ritual 
> sacrifice that isn't too offensive to the eyes?

Re: Proving Gig Speed

[Jared Mauch]

On Mon, Jul 16, 2018 at 01:02:28PM -0500, Dan White wrote:
> We've found that running windows in safe mode produces better results with
> Ookla. And MACs usually do better as well. We've gotten >900mb/s with those
> two approaches.

I've seen engineers even forget to account for differing behaviors
of vendors, eg: Juniper doesn't display the layer-2 header counters

This means a 920Mb/s link may actually be 100% once you add back in
ethernet framing.  Remind folks that they are seeing the TCP/UDP throughput
and there is ethernet + IP headers involved.

- Jared

Re: Proving Gig Speed

[Matthew Crocker]

I'm on a Mac and launch 40 speedtests at the same time and monitor interface 
bandwidth

#!/bin/bash

for i in `./speedtest-cli --list | cut -f1 -d')' | head -n 40`; do 
./speedtest-cli --server $i & done


I've been able to saturate 10G links with this method

-Matt 
 
-- 
Matthew Crocker
Crocker Communications, Inc.
President

On 7/16/18, 1:59 PM, "NANOG on behalf of Chris Gross"  wrote:

I'm curious what people here have found as a good standard for providing 
solid speedtest results to customers. All our techs have Dell laptops of 
various models, but we always hit 100% CPU when doing a Ookla speedtest for a 
server we have on site. So then if you have a customer paying for 600M or 1000M 
symmetric, they get mad and demand you prove it's full speed. At that point we 
have to roll out different people with JDSU's to test and prove it's functional 
where a Ookla result would substitute fine if we didn't have crummy laptops 
possibly. Even though from what I can see on some google results, we exceed the 
standards several providers call for.

Most of these complaints come from the typical "power" internet user of 
course that never actually uses more than 50M sustained paying for a 
residential connection, so running a circuit test on each turn up is uncalled 
for.

Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop 
that can actually do symmetric gig, a rugged small inexpensive device we can 
roll with instead to prove, or any other weird solution involving ritual 
sacrifice that isn't too offensive to the eyes?

Re: Proving Gig Speed

[Dan White]

We've found that running windows in safe mode produces better results with
Ookla. And MACs usually do better as well. We've gotten >900mb/s with those
two approaches.

On 07/16/18 17:58 +, Chris Gross wrote:

I'm curious what people here have found as a good standard for providing solid 
speedtest results to customers. All our techs have Dell laptops of various 
models, but we always hit 100% CPU when doing a Ookla speedtest for a server we 
have on site. So then if you have a customer paying for 600M or 1000M 
symmetric, they get mad and demand you prove it's full speed. At that point we 
have to roll out different people with JDSU's to test and prove it's functional 
where a Ookla result would substitute fine if we didn't have crummy laptops 
possibly. Even though from what I can see on some google results, we exceed the 
standards several providers call for.

Most of these complaints come from the typical "power" internet user of course 
that never actually uses more than 50M sustained paying for a residential connection, so 
running a circuit test on each turn up is uncalled for.

Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop that 
can actually do symmetric gig, a rugged small inexpensive device we can roll 
with instead to prove, or any other weird solution involving ritual sacrifice 
that isn't too offensive to the eyes?

Proving Gig Speed

[Chris Gross]

I'm curious what people here have found as a good standard for providing solid 
speedtest results to customers. All our techs have Dell laptops of various 
models, but we always hit 100% CPU when doing a Ookla speedtest for a server we 
have on site. So then if you have a customer paying for 600M or 1000M 
symmetric, they get mad and demand you prove it's full speed. At that point we 
have to roll out different people with JDSU's to test and prove it's functional 
where a Ookla result would substitute fine if we didn't have crummy laptops 
possibly. Even though from what I can see on some google results, we exceed the 
standards several providers call for.

Most of these complaints come from the typical "power" internet user of course 
that never actually uses more than 50M sustained paying for a residential 
connection, so running a circuit test on each turn up is uncalled for.

Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop that 
can actually do symmetric gig, a rugged small inexpensive device we can roll 
with instead to prove, or any other weird solution involving ritual sacrifice 
that isn't too offensive to the eyes?

Re: (perhaps off topic, but) Microwave Towers

[Michael Crapse]

Microwave radios are the things that break the mold of the incorrect
assumption that just because it doesn't make sense to put up more wires to
a house you can't have more than one provider. Considering that we've
deployed a few wireless systems with less latency, jitter, and downtime
than the local incumbent DOCSIS provider. In fact the greatest benefit to
wireless microwave systems is the fact that they do not need to follow the
right of way. Where wireline and fiberoptics must go through more hubs to
get from side of town to the other, wireless is a point to point system
with latencies+jitter sub 400 microseconds.

No matter how great the incumbent fiber/dsl/coaxial network becomes, there
will always be new microwave links going up. For their biggest strengths
there's no replacement.
Now, their weaknesses may be many, and may be apparent, their stengths just
outweigh those.

On 16 July 2018 at 10:01, Mike Hammett  wrote:

> No idea where you were at, but lots of big companies have done microwave
> and lots of new companies do microwave.
>
> https://en.wikipedia.org/wiki/MCI_Communications
>
> MCI was founded as Microwave Communications, Inc. on October 3, 1963 with
> John D. Goeken being named the company's first president. The initial
> business plan was for the company to build a series of microwave relay
> stations between Chicago, Illinois and St. Louis, Missouri. The relay
> stations would then be used to interface with limited-range two-way radios
> used by truckers along U.S. Route 66 or by barges on the Illinois Waterway.
>
>
> https://en.wikipedia.org/wiki/Sprint_Corporation
>
> Southern Pacific maintained an extensive microwave communications system
> along its rights-of-way that the railroad used for internal communications.
>
>
> AT had a bunch and I think a couple sites are still active:
> http://long-lines.net/
>
> Western Union had a microwave network as well.
>
>
>
>
> Lots of companies build microwave for internal communications. Rail and
> utility companies are big here.
>
> All of the cell companies do some microwave in their more rural areas.
>
> Lots of independent ISPs use microwave to build their entire network.
>
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> - Original Message -
>
> From: "Miles Fidelman" 
> To: nanog@nanog.org
> Sent: Saturday, July 14, 2018 9:54:25 AM
> Subject: (perhaps off topic, but) Microwave Towers
>
> Hi Folks,
>
> I find myself driving down Route 66. On our way through Arizona, I was
> surprised by what look like a lot of old-style microwave links. They
> pretty much follow the East-West rail line - where I'd expect there's a
> lot of fiber buried.
>
> Struck me as somewhat interesting.
>
> It also struck me that folks here might have some comments.
>
> Miles Fidelman
>
> --
> In theory, there is no difference between theory and practice.
> In practice, there is.  Yogi Berra
>
>
>

Re: (perhaps off topic, but) Microwave Towers

[Mike Hammett]

No idea where you were at, but lots of big companies have done microwave and 
lots of new companies do microwave. 

https://en.wikipedia.org/wiki/MCI_Communications 

MCI was founded as Microwave Communications, Inc. on October 3, 1963 with John 
D. Goeken being named the company's first president. The initial business plan 
was for the company to build a series of microwave relay stations between 
Chicago, Illinois and St. Louis, Missouri. The relay stations would then be 
used to interface with limited-range two-way radios used by truckers along U.S. 
Route 66 or by barges on the Illinois Waterway. 


https://en.wikipedia.org/wiki/Sprint_Corporation 

Southern Pacific maintained an extensive microwave communications system along 
its rights-of-way that the railroad used for internal communications. 


AT had a bunch and I think a couple sites are still active: 
http://long-lines.net/ 

Western Union had a microwave network as well. 




Lots of companies build microwave for internal communications. Rail and utility 
companies are big here. 

All of the cell companies do some microwave in their more rural areas. 

Lots of independent ISPs use microwave to build their entire network. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Miles Fidelman"  
To: nanog@nanog.org 
Sent: Saturday, July 14, 2018 9:54:25 AM 
Subject: (perhaps off topic, but) Microwave Towers 

Hi Folks, 

I find myself driving down Route 66. On our way through Arizona, I was 
surprised by what look like a lot of old-style microwave links. They 
pretty much follow the East-West rail line - where I'd expect there's a 
lot of fiber buried. 

Struck me as somewhat interesting. 

It also struck me that folks here might have some comments. 

Miles Fidelman 

-- 
In theory, there is no difference between theory and practice. 
In practice, there is.  Yogi Berra 

Re: deploying RPKI based Origin Validation

[Job Snijders]

On Sat, Jul 14, 2018 at 11:03:16AM +0200, Mark Tinka wrote:
> On 14/Jul/18 09:11, Baldur Norddahl wrote:
> > In the RIPE part of the world there is no excuse for not getting
> > RPKI correct because RIPE made it so easy. Perhaps the industry
> > could agree on enabling RPKI validation on all european circuits for
> > a start?
> 
> I think the first step (and what I'd consider to be a quick win) is if
> we determined all the prefixes that are being designated Invalid, and
> nail down how many of those are Invalid due to the fact that they are
> more-specifics announced without a ROA, vs. the parent aggregate which
> is ROA'd.

I calculated this here few days ago
http://instituut.net/~job/rpki-report-2018.07.12.txt

Markus Weber from KPN is generating a daily report here and drew similar
conclusions: https://as286.net/data/ana-invalids.txt Markus scrapes all
routes from the AS 286 PEs and marks the routes for which no valid or
unknown alternative exists as "altpfx=NONE".

> We would then ask the operators of those prefixes to either withdraw
> them (easier, but unlikely) or sign them in the RPKI and create ROA's
> for them (more work, but more likely). Going for the latter.

Or delete the incorrect RPKI ROA. Either way is fine.

> Once that is fixed, and even though the entire BGP world is not
> running RPKI, those that are and are dropping Invalids would be 100%
> certain that those Invalids are either leaks or hijacks.
> 
> I think that will get us 50% of the way there, with the other 50%
> would now just be growing community participation in RPKI.
> 
> Thankfully, I believe all (or most) of the RIR's support a simple
> "click of a button" to say "All prefixes up to a /24 or a /48 of the
> aggregate should automatically be ROA'd if the aggregate, itself, is
> ROA'd". So it shouldn't be a lot of work to get what is currently
> broken fixed. And the beauty, we don't need everyone to participate in
> the RPKI today for those that want the benefit right now to enjoy it
> so.

Perhaps the RIRs should start an outreach program to proactively inform
the owners of those 2,200 invalid route announcements to get them to
either fix or delete the RPKI ROA.

Kind regards,

Job

Re: Bogon prefix c0f:f618::/32 announced via Cogent

[Stephane Bortzmeyer]

On Sat, Jul 14, 2018 at 08:18:25AM +0800,
 Siyuan Miao  wrote 
 a message of 27 lines which said:

> c0f:f618::/32 originated from AS327814 is announcing via Cogent for several
> weeks.

Apparently withdrawn 2018-07-14 around 16:00:00 UTC. Your mail to NANOG was
effective :-)

Re: Akamai contact

[Jared Mauch]

Replied offlist. 

Jared Mauch

> On Jul 15, 2018, at 3:34 PM, Eric Germann  wrote:
> 
> Now that I’ve learned Delta is an airline, runs hotels, and makes faucets, 
> amongst other things, if there is an Akamai [Company that deploys CDN’s and 
> other things] contact who could contact me off list re: continuing to 
> troubleshoot a Delta Airlines [amongst other sites] issue that would be most 
> appreciated.
> 
> Thank you
> 
> EKG
> 

Re: Linux BNG

[Stefan Bethke]

Am 14.07.2018 um 14:13 schrieb Baldur Norddahl :
> 
> I am considering writing a small program or kernel module. This would create 
> two TAP devices (tap0 and tap1). Traffic received on tap0 with VLAN tagging, 
> will be stripped of VLAN tagging and delivered on tap1. Traffic received on 
> tap1 without VLAN tagging, will be tagged according to a lookup table using 
> the destination IP address and then delivered on tap0. ARP and DHCP would 
> need some special handling.

As a proof of concept, a userland implementation using tap is likely the 
easiest to implement. But it won’t give you the throughput you’re looking for.

I’d look at https://www.dpdk.org if you want to stay in userland.

If FreeBSD ist an option, netgraph(4) is designed to allow packet filtering, 
manipulation and distribution in a set of small processing modules.

In either case, Ethernet frames would be processed outside the regular network 
stack, but could be handed over to the kernel for further processing, i.e. DHCP 
or SLAAC.


Stefan

-- 
Stefan BethkeFon +49 151 14070811

Re: (perhaps off topic, but) Microwave Towers

[Robert DeVita]

We had a ton of point to point wireless customers at 120E Van Buren out to 
South Mountain. About 10 years ago there was a significant shortage of fiber 
outside of Phoenix. You choices were SRP and Cox for the most part and SRP at 
that time had a very limited fiber network. They were actually the only company 
that offered dark Fiber out to Chandler when that campus first got built.

Robert DeVita
Managing Director
Mejeticks
c. 469-441-8864
e. radev...@mejeticks.com


From: 32432146260n behalf of
Sent: Saturday, July 14, 2018 10:44 AM
To: North American Network Operators' Group
Subject: Re: (perhaps off topic, but) Microwave Towers



> On Jul 14, 2018, at 10:19 AM, Brian Kantor  wrote:
>
>>> I find myself driving down Route 66. On our way through Arizona, I was 
>>> surprised by what look like a lot of old-style microwave links. They pretty 
>>> much follow the East-West rail line - where I'd expect there's a lot of 
>>> fiber buried.
>
> Could they be a legacy of the Southern Pacific Railroad Internal Network 
> Telecommunications,
> now known under the acronym SPRINT?
> - Brian
>

Not along Route 66 in Arizona. That generally parallels BNSF Railway, formerly 
the Santa Fe down there. Southern Pacific followed Interstate 10 much further 
south.



Andy Ringsmuth
a...@newslink.com
News Link – Manager Technology, Travel & Facilities
2201 Winthrop Rd., Lincoln, NE 68502-4158
(402) 475-6397 (402) 304-0083 cellular

Akamai contact

[Eric Germann]

Now that I’ve learned Delta is an airline, runs hotels, and makes faucets, 
amongst other things, if there is an Akamai [Company that deploys CDN’s and 
other things] contact who could contact me off list re: continuing to 
troubleshoot a Delta Airlines [amongst other sites] issue that would be most 
appreciated.

Thank you

EKG



signature.asc
Description: Message signed with OpenPGP

Gmail admin

[Brian]

Is there a gmail admin that can contact me offlist?
Thanks much.

Bogon prefix c0f:f618::/32 announced via Cogent

[Siyuan Miao]

Hi,

c0f:f618::/32 originated from AS327814 is announcing via Cogent for several
weeks.

I've tried to contact Cogent and AS327814 but didn't receive any reply.

Tue Jul 10 17:52:48.602 UTC
BGP routing table entry for c0f:f618::/32
Versions:
  Process   bRIB/RIB  SendTblVer
  Speaker   7640326976403269
Local Label: 61339
Last Modified: Jul  3 13:31:40.815 for 1w0d
Paths: (1 available, best #1)
  Advertised to peers (in unique update groups):
38.5.0.99
  Path #1: Received by speaker 0
  Advertised to peers (in unique update groups):
38.5.0.99
  327814
2001:550:0:1000::261c:166 (metric 119060) from
2001:550:0:1000::261c:153 (38.28.1.102)
  Origin incomplete, localpref 130, valid, internal, best, group-best
  Received Path ID 0, Local Path ID 0, version 76403269
  Community: 174:11100 174:20999 174:21101 174:22012
  Originator: 38.28.1.102, Cluster list: 38.28.1.83, 38.28.1.67, 38.28.1.92

Re: Linux BNG

[Mark Tinka]

On 14/Jul/18 20:29, t...@wicks.co.nz wrote:

> My biggest issue with the vendor offerings is that they are not making their 
> virtual offerings (VMX, VSR) attractive enough pricing wise at the small 
> scale, we have successful virtual Juniper and Nokia BNG's in production but 
> pricing wise it generally ends up with the service provider thinking that 
> hardware was probably a better choice in the long run.

vBNG's are fraught with imperceptible license fees. But yes, if you had
do deploy a BNG on an x86 box, a vBNG from a well-known vendor will
likely be less problematic to setup and scale than a BNG based on Linux.
Then again, I last researched this in 2016, so things could have changed
a tad.

Mark.

Re: NTT engineer in the wings?

[Randy Bush]

> The IP NOC is unable to locate anyone because it’s Sunday

you can't be talking about ntt noc.  ntt noc is aggressively responsive.

randy

Re: NTT engineer in the wings?

[Saku Ytti]

Hey Jason,

Can you provide me ticket number (VNOC), time you called and who you spoke with?

We have 24/7 NOC, and 24/7 escalation. Sunday is like every other day,
this is highly atypical and I apologise for it.

You can contact me off-list.

Thanks!
On Mon, 16 Jul 2018 at 01:16, JASON BOTHE via NANOG  wrote:
>
>
> If there is someone listening from NTT engineering, would you kindly write 
> back?
>
> The IP NOC is unable to locate anyone because it’s Sunday so I thought I 
> might try here.
>
> Thanks!
>
> J~
>


-- 
  ++ytti