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 somet
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.
>
>
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 1500.
>> Of course BGP has to be allowed t
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 Thu, Jul 21, 2016 at 8
* 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, Coax and fiber for in
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 load
> > , like when your kid is downloading a v
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); your performance (e.g. we
> 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 on be
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 your home with a 4G wifi
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 to be allowed to use hig
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
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 was some test made to det
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.
T
> 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 convergence time was fas
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
> is /64 or /128.
>
> In RFC
> 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.
>
> Anyone else observed
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 bgp-st...@lists
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 M
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 12:57:58 PM
To: Ricardo Ferreira
Cc: NANOG
Subject
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 G
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 regardi
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 enou
❦ 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 want to
> avoid the trouble
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 IE
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 backup so we
figured a GRE tunne
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 an
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 equipment behaves well with large pa
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
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.
>---
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:
> Feedback: needs IPv6 connectivity and support.
>
Point well taken. The vast ma
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 backup so we
figured a GRE tunnel on a common IP transit carrier would work. We want to
avoid th
31 matches
Mail list logo
