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
(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 -
lin.mb.ca/>
From: NANOG on behalf of
Jürgen Jaritsch
Sent: Tuesday, July 7, 2020 5:05:03 PM
To: nanog@nanog.org
Subject: AW: L2VPN/L2transport, Cumulus Linux & hardware suggestion
Dear Adam,
yeah, forget about LACP - the bigger problem is all the LLDP and STP
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
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
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
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
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
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
.mb.ca
http://www.merlin.mb.ca
> -Original Message-
> From: NANOG <mailto:nanog-bounces+athompson=merlin.mb...@nanog.org> On
Behalf
> Of Jürgen Jaritsch
> Sent: Tuesday, July 7, 2020 3:15 PM
> To: mailto:nanog@nanog.org
> Subject: L2VPN/L2transport, Cumulus Li
NANOG On Behalf Of
> Jürgen Jaritsch
> Sent: Tuesday, July 7, 2020 3:15 PM
> To: nanog@nanog.org
> Subject: L2VPN/L2transport, Cumulus Linux & hardware suggestion
>
> Dear folks,
>
> have anyone already tried to run VXLAN/EVPN + “Bridge Layer 2 Protocol
> Tunneling”
Dear folks,
have anyone already tried to run VXLAN/EVPN + Bridge Layer 2 Protocol
Tunneling on Cumulus Linux as an replacement for classic MPLS L2VPN/VPWS
(xconnect, l2circuit, VLL) ?
I need to provide transparent Ethernet P2P virtual leased lines to my
customers and these have to support
14 matches
Mail list logo
