The EX 4650 does indeed do 25G.
Chris
From: NANOG
Date: Tuesday, July 7, 2020 at 16:10
To: Jürgen Jaritsch , nanog@nanog.org
Subject: RE: L2VPN/L2transport, Cumulus Linux & hardware suggestion
Good luck with tunnelling LACP, no matter what boxes you have - LACP has (de
facto) hard ji
On 09.07.2020 02.14, Valdis Klētnieks wrote:
There's a difference between a TCP *resend*, and a *RESET*.
Triggering a resend on a re-order is reasonably sane, sending an RST isn't
You get the RESETs from people that do anycast when your broken ECMP
hashing splits the packets between mul
(re-adding Adam's text that didn't get quoted, but matters)
On Wed, 08 Jul 2020 13:49:56 +0300, Saku Ytti said:
> On Wed, 8 Jul 2020 at 13:46, Radu-Adrian Feurdean
> wrote:
> On Wed, Jul 8, 2020, at 00:09, Adam Thompson wrote:
> > > Good luck with tunnelling LACP, no matter what boxes you have -
eudowire"? I
can't even find a config example on the net :(
thanks & best regards
Jürgen
-Ursprüngliche Nachricht-
Von: Adam Thompson [mailto:athomp...@merlin.mb.ca]
Gesendet: Dienstag, 7. Juli 2020 23:09
An: Jürgen Jaritsch ; nanog@nanog.org
Betreff: RE: L2VPN/L2transpo
On Wed, 8 Jul 2020 at 14:56, Adam Thompson wrote:
> If jitter were defined anywhere vis-à-vis LACP, it would be _de jure_, not
> _de facto_ as I said.
I suspect the de-facto domain you think of has modest population. As
jitter would only matter in case where protocol measures delay and
artifici
If jitter were defined anywhere vis-à-vis LACP, it would be _de jure_, not _de
facto_ as I said.
Yes, if you have *guaranteed* that TCP sessions hash uniquely to a single link
in your network, you might be able to successfully tunnel LACP (or
EtherChannel, or any other L1 link-bonding technique
On 8/Jul/20 12:42, Radu-Adrian Feurdean wrote:
> Errr sorry, but at the latest news, TCP was supposed to handle out of
> order packets and reorder them before sending them to upper layer.
> Not to mention hashing that almost systematically makes that all packets of
> the same TCP stream wi
On Wed, 8 Jul 2020 at 13:46, Radu-Adrian Feurdean
wrote:
> Errr sorry, but at the latest news, TCP was supposed to handle out of
> order packets and reorder them before sending them to upper layer.
> Not to mention hashing that almost systematically makes that all packets of
> the same TCP
On Wed, Jul 8, 2020, at 00:09, Adam Thompson wrote:
> Good luck with tunnelling LACP, no matter what boxes you have - LACP
> has (de facto) hard jitter requirements of under 1msec, or you'll be
> getting TCP resets coming out your ears due to mis-ordered packets.
Errr sorry, but at the la
On 7/Jul/20 23:09, Adam Thompson wrote:
> Good luck with tunnelling LACP, no matter what boxes you have - LACP has (de
> facto) hard jitter requirements of under 1msec, or you'll be getting TCP
> resets coming out your ears due to mis-ordered packets.
Hmmh - this is odd.
We once provided a c
Hey Adam,
On Wed, 8 Jul 2020 at 00:11, Adam Thompson wrote:
> Good luck with tunnelling LACP, no matter what boxes you have - LACP has (de
> facto) hard jitter requirements of under 1msec, or you'll be getting TCP
> resets coming out your ears due to mis-ordered packets.
Can you elaborate on
Good luck with tunnelling LACP, no matter what boxes you have - LACP has (de
facto) hard jitter requirements of under 1msec, or you'll be getting TCP resets
coming out your ears due to mis-ordered packets.
For your requirements, although I hesitate to recommend them for
enterprise/carrier use,
12 matches
Mail list logo
