Re: Favorite Speed Test Systems

[Mike O'Connor]

:On 05-12-2016 16:34, Nick Ryce wrote:
:> For testing downloads, fast.com is pretty nice
:> 
:
:The problem with fast.com is that they use HTTPS for the test. The user needs
:a fast computer to decode the SSL at full speed. Even if you have a very fast
:computer the test will max out at 100-200 Mbps because the Netflix servers
:are apparently not able to encode SSL any faster. Maybe we would get better
:speed if multiple SSL connections were used.

I've run into the opposite problem -- fast.com sporadically reporting
1+ Gbps times for circuits that are only 20-40 Mbps.  There's no obvious
client-side issues -- no proxying, interesting browsers, etc.  fast.com
is glitchy just often enough to give some friends of mine silly glee
when it misreports.

-Mike

--
 Michael J. O'Connor  m...@dojo.mi.org
 =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--=
"A superhero should always speak from his diaphragm!"   -The Tick


signature.asc
Description: PGP signature

Re: Favorite Speed Test Systems

[Curtis Generous]

http://speedof.me/

Keeps history of past tests and is HTML5 based so no flash or java needed

--curtis



On 12/5/16, 9:50 AM, "NANOG on behalf of Graham Johnston" 
 wrote:

For many years we have had a local instance of the Ookla speedtest.net on 
our network, and while it is pretty good some other tests seem include more 
detailed results.

I am aware of the following speedtest systems that an operator can likely 
have a local instance of:

* Speedtest.net

* Sourceforge.net/speedtest

* Dslreports.com/speedtest

Are there others? What is your preferred one and why?

Thanks,
Graham

Re: Canadian National Railway contact

[jim deleskie]

Have a friend that used to work there, will reach out to see if he still
does.

-jim

On Tue, Dec 6, 2016 at 11:48 AM, Andy Ringsmuth  wrote:

> If there happens to be someone here from the Canadian National Railway, or
> if someone knows someone there, could you hit me up off-list?
>
> Attempting to work through an e-mail block from us to them that I’ve been
> unsuccessful remedying so far.
>
> Much appreciated!
>
> 
> Andy Ringsmuth
> a...@newslink.com
> News Link – Manager Travel, Technology & Facilities
> 2201 Winthrop Rd., Lincoln, NE 68502-4158
> (402) 475-6397(402) 304-0083 cellular
>
>

Canadian National Railway contact

[Andy Ringsmuth]

If there happens to be someone here from the Canadian National Railway, or if 
someone knows someone there, could you hit me up off-list?

Attempting to work through an e-mail block from us to them that I’ve been 
unsuccessful remedying so far.

Much appreciated!


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

Looking for a Comcast engineer

[Chris Lane]

If a Comcast engineer is available mind hitting me up offline.

I am not a customer, but a former customer of mine is still advertising my
IP /24 out to you Comcast.

the prefix belongs to our company and the former customer won't return my
calls. I'd like you to remove prefix from filters.

Much regards,

Chris
​

Re: Favorite Speed Test Systems

[Alex Moura]

There is also http://speedof.me/ tool around for a while as well as:

https://sourceforge.net/speedtest/

http://www.bandwidthplace.com/

http://testmy.net/

I've got a good result of 880Mbps[1] from fast.com from 6 hops away
(~9ms)[2]:
[1] http://pasteboard.co/6xAnRRa6F.png
[2] http://pasteboard.co/6xBIViwaM.png


2016-12-06 0:38 GMT-02:00 Roland Dobbins :

> On 5 Dec 2016, at 21:50, Graham Johnston wrote:
>
>  What is your preferred one and why?
>>
>
> 
>
> Thorough, reasonable teat methodology, allows one to store history, decent
> range of test servers worldwide.
>
> ---
> Roland Dobbins 
>

Re: Favorite Speed Test Systems

[Baldur Norddahl]

On 05-12-2016 16:34, Nick Ryce wrote:

For testing downloads, fast.com is pretty nice



The problem with fast.com is that they use HTTPS for the test. The user 
needs a fast computer to decode the SSL at full speed. Even if you have 
a very fast computer the test will max out at 100-200 Mbps because the 
Netflix servers are apparently not able to encode SSL any faster. Maybe 
we would get better speed if multiple SSL connections were used.


I just did a test on fast.com and got 150 Mbps. Click the compare on 
speedtest.net button and I got 940 Mbps at beta.speedtest.net. The 
computer is Intel i7 5820K, the OS is Ubuntu 16.04 and the internet is 1 
Gbps delivered on GPON. The test runs on IPv6.


We are directly peered with Netflix with 2x10G and there is plenty of 
capacity. It appears fast.com is on Akamai but the test itself is 
downloading data via our peering.


Regards,

Baldur

Re: Re: Favorite Speed Test Systems

[J]

I've used Visualware's My Connection Server, and the stats it gives are decent.

Haven't yet updated to the latest version, which seems to be require client 
software installation, however.


http://www.myconnectionserver.com/


Have also used Ookla's, but it seems more useful to join their speedtest 
network, than host the standalone, now.

 On Tue, 06 Dec 2016 07:28:55 -0600 Matthew Walster 
 wrote  

On 5 December 2016 at 14:50, Graham Johnston  
wrote: 
 
> Are there others? What is your preferred one and why? 
> 
 
​Generally I don't bother with speed testers unless I'm wanting a quick 
guesstimate -- I wouldn't recommend using them as a measure of how "fast" 
an internet connection is because there's always other factors in 
contention, and it only tests the path to the speedtester. 
 
Having said that, despite the obnoxious adverts on the site, speedof.me 
provides a really nice non-flash interface that is an excellent teaching 
tool for showing people how TCP congestion windows work, and lets you 
demonstrate to people the effect of buffers in a network etc. 
 
I'll be taking notes if anyone provides anything else similar that does a 
similar (if not better) job, maybe one that can be self-hosted too! 
 
M​ 

Re: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue)

[Leo Bicknell]

In a message written on Fri, Dec 02, 2016 at 08:50:40PM +0100, Job Snijders 
wrote:
> IEEE told one of my friends: "We changed our allocation methods to
> prevent vendors using unregistered mac addresses."
> 
> Does the cost of some squatters on poorly usable MAC space outweight the
> cost of the community spending countless hours tracking down where those
> dropped packets went?

That's the wrong question to ask.

The right question is, what could have been done to prevent this entire
situation?

This problem has occured in all sorts of number spaces before.
There have been squatters in almost every number space, boxes
"optimized" based on the pattern of allocation, code bugs that went
unnoticed due to part of the number space not being used.  It's
happened to MAC's, IP's, ports, even protocol numbers.

One of the answers is to better allocate numbers.  Starting at the
bottom and working up is almost never the optimal solution.  Various
sparce allocation strategies exist which insure a wider range of
addresses are used early, there is a greater chance of wacking a
squatter early, and that the number space ends up more efficiently
used in many cases.

Had the IETF allocated a MAC starting with 0 then 2, then 4 then 6
then 8 then 10 then 12 then 14 this problem would have likely been
identified early on in vendor labs when testing the pseudowire code
and would have prevented the "hack" of looking deeper in the packet
and guessing because too many 4 and 6 MACs were already deployed.

-- 
Leo Bicknell - bickn...@ufp.org
PGP keys at http://www.ufp.org/~bicknell/


pgpfoqPpxwNSM.pgp
Description: PGP signature

Re: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue)

[Saku Ytti]

On 6 December 2016 at 14:28, Job Snijders  wrote:
> Liberal translation below. The big take-away for operators is that
> service providers need to make it part of the MPLS Psuedo-wire
> troubleshooting procedure to ask the customer which MACs are involved
> and raise the red flag when a 4 or 6 is involved.

Expect also per-vendor behaviour on ethertype values, result from one
vendor: http://ytti.fi/ether_type.png

Granted these are not technically ethertypes at all, but 802.3 frame
length, still some other vendors don't care and pass each of these
transparently. Here we can observe blackholing and policing depending
on 802.3 frame length value.

The same vendor here experiences packet loss on pseudowires if
ethertype tells it's ipv4, ipv6, mpls, vlan and packet /does not/
contain said payload. Potentially because NPU time-cost increases too
much.

Vendor never really explained either behaviour.

Other behavioural differences is that some vendors don't accept bad
source addresses, like MCAST source address, some other vendors do.
Pseudowires behaviour is highly dependent on hardware and software
release in corner cases. It's easy to debate that bad MACs should be
dropped, but it's also easy to argue that perhaps you're testing
things, and you expect to get transparent pipe and you to test if your
SUT accepts bad MACs or not.



-- 
  ++ytti

Re: Favorite Speed Test Systems

[Matthew Walster]

On 5 December 2016 at 14:50, Graham Johnston 
wrote:

> Are there others? What is your preferred one and why?
>

​Generally I don't bother with speed testers unless I'm wanting a quick
guesstimate -- I wouldn't recommend using them as a measure of how "fast"
an internet connection is because there's always other factors in
contention, and it only tests the path to the speedtester.

Having said that, despite the obnoxious adverts on the site, speedof.me
provides a really nice non-flash interface that is an excellent teaching
tool for showing people how TCP congestion windows work, and lets you
demonstrate to people the effect of buffers in a network etc.

I'll be taking notes if anyone provides anything else similar that does a
similar (if not better) job, maybe one that can be self-hosted too!

M​

Re: Level3 / Cogent / NetFlix BGP Assistance

[Dave Temkin]

Hi Sam,

As you may have noticed, Netflix no longer uses Cogent as a transit
provider. You will see all of your transit traffic from us traverse Level3.

We are happy to try to work with you to find the best way to deliver your
traffic. Please reach out to peer...@netflix.com and the team will try to
help.

Regards,
-Dave

On Sun, Dec 4, 2016 at 9:14 AM, Sam Norris 
wrote:

> Hey all,
>
>
>
> In early October our traffic levels from NetFlix went from about half
> Level3 and
> half Cogent - pretty well balanced - to all on Level3.  Standard
> multihomed BGP
> setup with minimal TE if I can help it.  I am starting to run into
> problems with
> a full gigabit port on Level3 and only 100-200mbps on Cogent at that
> colo.  I
> tried padding, I even tried 65000:2906 bgp community, but it seems like if
> our
> level3 port is up NetFlix chooses it solely.  How can I load balance
> NetFlix
> traffic across my two ports so that I am not paying for overages and/or
> forced
> to up to a 10G port immediately?  I have 3 other providers at that colo and
> cannot find any mix of bgp tricks to get some of it thru our other
> providers.
>
>
>
> I notice AS2906 has a localpref of 86 - odd ...
>
>
>
> The 108.175.47.0/24 block seems to be using as 2906 so I thought a
> 65000:2906
> wouldn't announce those prefixes to them at all.  I have about 10 prefixes
> being
> announced so I could implement a no-export on some of them to load balance
> but
> that doesn't work.
>
>
>
> Thx,
>
> Sam
>
>
>
>
>
> BGP routing table entry for 108.175.47.0/24
>
>
>
> Paths: (2 available, best #1)
>
>   2906
>
>   AS-path translation: { 108.175.47.0/24 }
>
>ear3.LosAngeles1 (metric 10)
>
> Origin IGP, metric 30334, localpref 86, valid, internal, best
>
> Community: 2906:51081 North_America Lclprf_86 United_States Level3_Peer
> Los_Angeles Level3:10984
>
> Originator: ear3.LosAngeles1
>
>   2906
>
>   AS-path translation: { 108.175.47.0/24 }
>
>ear3.LosAngeles1 (metric 10)
>
> Origin IGP, metric 30334, localpref 86, valid, internal
>
> Community: 2906:51081 North_America Lclprf_86 United_States Level3_Peer
> Los_Angeles Level3:10984
>
> Originator: ear3.LosAngeles1
>
>
>
>
>
>
>
>

Re: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue)

[Mike Jones]

> MACs that didnt make it through the switch when running 4.12.3.1:
>
> 4*:**:**:**:**:**
> 6*:**:**:**:**:**
> *4:**:**:**:**:**
> *6:**:**:**:**:**
> **:**:*B:**:6*:**
> **:**:*F:**:4*:**

Can anyone explain the last 2 for me?

I was under the impression that this bug was mainly caused by some
optimistic attempt to detect raw IPv4 or IPv6 payloads by checking for
a version at the start of the frame. This does not explain why it
would be looking at the 5th octet.

I also would assume that there must be something else to the last 2
examples beyond just the B or F and 4 or 6 because otherwise it would
match way too many addresses to have not been noticed before. Perhaps
the full MAC address looks like some other protocol with a 4 byte
header?

Thanks,
Mike

Re: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue)

[Job Snijders]

On Fri, Dec 02, 2016 at 04:02:43PM +, Simon Lockhart wrote:
> On Fri Dec 02, 2016 at 10:29:56AM -0500, Christopher Morrow wrote:
> > you'd think standard testing of traffic through the asic path
> > somewhere between 'let's design an asic!' and 'here's your board ms
> > customer!' would have found this sort of thing, no? or does testing
> > only use 1 mac address ever?
> 
> Well, it's actually payload, rather than src/dst MAC used for
> forwarding, so there's quite a few more combinations to look for...
> 
> 2^(8*9216) is quite a lot of different packets to test through the
> forwarding path... But, wait, that assumes every bit combination for
> 9216 byte packets, but the packet might be shorter than that... So
> multiply that by (9216-64).
> 
> Anyone want to work out how many years that'd take to test, even at
> 100G?

Folks on NLNOG found another gem: 
http://mailman.nlnog.net/pipermail/nlnog/2016-December/002637.html

Liberal translation below. The big take-away for operators is that
service providers need to make it part of the MPLS Psuedo-wire
troubleshooting procedure to ask the customer which MACs are involved
and raise the red flag when a 4 or 6 is involved.

---
Hi,

We've observed a similar problem on the Arista 7150S-52 with EOS
4.12.3.1: issues with passing transient MPLS traffic through a layer-2
domain where the payload contains certain MACs.

Arista EOS 4.16.9M apparently contains a fix to address this problem.

MACs that didnt make it through the switch when running 4.12.3.1:

4*:**:**:**:**:**
6*:**:**:**:**:**
*4:**:**:**:**:**
*6:**:**:**:**:**
**:**:*B:**:6*:**
**:**:*F:**:4*:**

Maybe there are more combinations, but we didn't iterate through all
possibilities.

Big thank you to Richard van Looijen (Flowmailer) for finding this
issue, Edwin Kalle (2hip) for pointing us at this thread, and Job
Snijders, his email which prompted us to investigate the intermediate
switches.

Kind regards,

Robert