Re: MTU

On 22/Jul/16 19:37, Grzegorz Janoszka wrote: > > > What I noticed a few years ago was that BGP convergence time was > faster with higher MTU. > Full BGP table load took twice less time on MTU 9192 than on 1500. > Of course BGP has to be allowed to use higher MTU. > > Anyone else observed

Re: IPv6 Deployment for Mobile Subscribers

On Fri, 22 Jul 2016 10:54:48 +0200, Ricardo Ferreira said: > Is there anyone here working in an ISP where IPv6 is deployed? > We are starting to plan the roll-out IPv6 to mobile subscribers (phones) I > am interesting in knowing the mask you use for the assignment; whether it > is /64 or /128. > >

Re: MTU

On 7/22/16, Phil Rosenthal wrote: > >> On Jul 22, 2016, at 1:37 PM, Grzegorz Janoszka >> wrote: >> What I noticed a few years ago was that BGP convergence time was faster >> with higher MTU. >> Full BGP table load took twice less time on MTU 9192 than on

Re: I recommend dslreports.com/speedtest these days (was Speedtest.net not accessible in Chrome due to deceptive ads)

Just a quick clarifying reply, I have had DSL test give me an A for bufferbloat and a C for Speed on a 75 Meg line. On July 22, 2016 3:23:00 PM EDT, Jim Gettys wrote: >I don't read this list continually, but do archive it; your note was >flagged for me to comment on. > >On

Re: IPv6 Deployment for Mobile Subscribers

* Baldur Norddahl > Den 22. jul. 2016 20.25 skrev "Ca By" : > > > Phones, as in 3gpp? If so, each phone alway gets a /64, there is > > no choice. > > > > https://tools.ietf.org/html/rfc6459 > > Here the cell companies are marketing their 4G LTE as an alternative > to DSL,

Re: I recommend dslreports.com/speedtest these days (was Speedtest.net not accessible in Chrome due to deceptive ads)

On Fri, Jul 22, 2016 at 4:18 PM, Baldur Norddahl wrote: > Den 22. jul. 2016 21.34 skrev "Jim Gettys" : > > > > > > So it is entirely appropriate in my view to give even "high speed" > > connections low grades; it's telling you that they suck under

Re: I recommend dslreports.com/speedtest these days (was Speedtest.net not accessible in Chrome due to deceptive ads)

Den 22. jul. 2016 21.34 skrev "Jim Gettys" : > > > So it is entirely appropriate in my view to give even "high speed" > connections low grades; it's telling you that they suck under load > ​, like when your kid is downloading a video (or uploading one for their > friends);

Re: IPv6 Deployment for Mobile Subscribers

> I would love to test it, but it will be no surprise that none of the four carriers enabled IPv6. Verizon Wireless has been dual stack for many years, before they ran out of public IPv4 addresses and switched handsets to RFC1918 space for v4. From: NANOG

Re: IPv6 Deployment for Mobile Subscribers

Den 22. jul. 2016 20.25 skrev "Ca By" : > Phones, as in 3gpp? If so, each phone alway gets a /64, there is no choice. > > https://tools.ietf.org/html/rfc6459 Here the cell companies are marketing their 4G LTE as an alternative to DSL, Coax and fiber for internet access in

Re: MTU

On 2016-07-22 20:20, Phil Rosenthal wrote: On Jul 22, 2016, at 1:37 PM, Grzegorz Janoszka wrote: What I noticed a few years ago was that BGP convergence time was faster with higher MTU. Full BGP table load took twice less time on MTU 9192 than on 1500. Of course BGP has

RE: I recommend dslreports.com/speedtest these days (was Speedtest.net not accessible in Chrome due to deceptive ads)

Jim, No problems, I just knew you were one of the project founders. I found it on the website shortly after posting. My google-fu wasn’t up to par. https://www.bufferbloat.net/projects/cerowrt/wiki/Tests_for_Bufferbloat/ I’m assuming I used the script last time for netperf, but have downloaded

Re: I recommend dslreports.com/speedtest these days (was Speedtest.net not accessible in Chrome due to deceptive ads)

I don't read this list continually, but do archive it; your note was flagged for me to comment on. On Thu, Jul 21, 2016 at 8:11 PM, Eric Tykwinski wrote: > This is probably for Jim Gettys directly, but I’m sure most others have > input. I could of sworn that that there

Re: IPv6 Deployment for Mobile Subscribers

Good day, On 22 Jul 2016, at 10:54, Ricardo Ferreira wrote: > Is there anyone here working in an ISP where IPv6 is deployed? I am not, but I can answer from the consumer's point of view: > Basically a sole device will be connecting to the internet so I am > wondering if this rule is follwed.

Re: MTU

> On 22 Jul 2016, at 19:37, Grzegorz Janoszka wrote: > >> On 2016-07-22 15:57, William Herrin wrote: >> On a link containing only routers, you can safely increase the MTU to >> any mutually agreed value with these caveats: > > What I noticed a few years ago was that BGP

Re: IPv6 Deployment for Mobile Subscribers

On Friday, July 22, 2016, Ricardo Ferreira wrote: > Is there anyone here working in an ISP where IPv6 is deployed? > We are starting to plan the roll-out IPv6 to mobile subscribers (phones) I > am interesting in knowing the mask you use for the assignment; whether it

Re: MTU

> On Jul 22, 2016, at 1:37 PM, Grzegorz Janoszka wrote: > What I noticed a few years ago was that BGP convergence time was faster with > higher MTU. > Full BGP table load took twice less time on MTU 9192 than on 1500. > Of course BGP has to be allowed to use higher MTU. >

Weekly Routing Table Report

This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, SAFNOG, PaNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to

Re: MTU

On 2016-07-22 15:57, William Herrin wrote: On a link containing only routers, you can safely increase the MTU to any mutually agreed value with these caveats: What I noticed a few years ago was that BGP convergence time was faster with higher MTU. Full BGP table load took twice less time on

Re: IPv6 Deployment for Mobile Subscribers

As far as I'm aware Android still today does not support DHCPv6. https://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems From: NANOG on behalf of james machado Sent: Friday, July 22, 2016

Re: IPv6 Deployment for Mobile Subscribers

Ricardo, I know from previous discussions on this list that Android phones are looking for DHCPD leases and not /128's or /64's. From what I remember this is due to the current requirement for multiple ipv6 subnets for various applications (vpns among others) to function correctly. As a result

Re: MTU

Worth reading this on choosing MTU on transit link. http://blog.apnic.net/2014/12/15/ip-mtu-and-tcp-mss-missmatch-an-evil-for-network-performance/ -Sad >> >> On Fri, Jul 22, 2016 at 10:01 PM, Baldur Norddahl < >> baldur.nordd...@gmail.com> wrote: >> >>> Hi >>> >>> What is best practice

Re: MTU

This topic seems to come up more lately. Much like it did often during IPSec related deployments. I simplify on 9,000 as an easy number and I don't have to split hairs (read 9,214 v 9,216) that some vendors have. My experience has been making a view phone calls and agreeing on 9,000 is simple

Re: MTU

❦ 22 juillet 2016 14:01 CEST, Baldur Norddahl  : > Until now we have used the default of 1500 bytes. I now have a project were > we peer directly with another small ISP. However we need a backup so we > figured a GRE tunnel on a common IP transit carrier would work. We

IPv6 Deployment for Mobile Subscribers

Is there anyone here working in an ISP where IPv6 is deployed? We are starting to plan the roll-out IPv6 to mobile subscribers (phones) I am interesting in knowing the mask you use for the assignment; whether it is /64 or /128. In RFC 3177, it says: 3. Address Delegation Recommendations The

Re: MTU

On Fri 2016-Jul-22 14:01:36 +0200, Baldur Norddahl wrote: Hi What is best practice regarding choosing MTU on transit links? Until now we have used the default of 1500 bytes. I now have a project were we peer directly with another small ISP. However we need a

Re: MTU

On 22/Jul/16 15:42, Chris Kane wrote: > > My experience has been making a view phone calls and agreeing on 9,000 > is simple enough. I've only experienced one situation for which the > MTU must match and that is on OSPF neighbor relationships, for which > John T. Moy's book (OSPF - Anatomy of

Re: MTU

On Fri, Jul 22, 2016 at 8:01 AM, Baldur Norddahl wrote: > What is best practice regarding choosing MTU on transit links? Hi Baldur, On a link containing only routers, you can safely increase the MTU to any mutually agreed value with these caveats: 1. Not all

Re: MTU

On 22/Jul/16 14:01, Baldur Norddahl wrote: > > Obviously I only need to increase my MTU by the size of the GRE header. But > I am thinking is there any reason not to go all in and ask every peer to go > to whatever max MTU they can support? My own equipment will do MTU of 9600 > bytes. See the

RE: Speedtest.net not accessible in Chrome due to deceptive ads

Good point, we would need a piece of websocket code to run before or after NDT that figures out MAX speed so end users we can compare with other speed tests. NDT is about the quality of a connection, not absolute maximum quantity that can be jammed on a link irrespective of errors and all.

Re: Speedtest.net not accessible in Chrome due to deceptive ads

And work on accurate measurement of higher link speeds. ;-) On 7/20/16, 11:42 PM, "NANOG on behalf of Collin Anderson" wrote: On Wed, Jul 20, 2016 at 5:00 PM, Antonio Querubin wrote: >