L2VPN/L2transport, Cumulus Linux & hardware suggestion

Wed Jul 8 11:56:16 UTC 2020

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).  The last time I attempted to do this on my network, I discovered that guarantee wasn't nearly as ironclad as I expected.  I don't remember the gory details, at this remove, sorry.  Maybe it wasn't TCP?  Maybe it wasn't the default hashing algorithm? Dunno.

-Adam

On Jul. 8, 2020 00:48, Saku Ytti <saku at ytti.fi> wrote:
Hey Adam,

On Wed, 8 Jul 2020 at 00:11, Adam Thompson <athompson at merlin.mb.ca> 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 this? Where is LACP jitter defined and for what
purpose? We push packets around the globe in sub 200us jitter on any
given day, so 1000us isn't for us a particularly hard goal.

Only reason why I could imagine someone would care about jitter here
is if protocol measures delay (LACP doesn't) and relies on delay to
remain static and then balances per-packet or per-byte or otherwise
between multiple links.
However we of course put all packets from given TCP session to always
same LACP interface, so from TCP session POV, each LACP is exactly a 1
interface. Per-packet balancing on LACP is possible via a special
configuration, but anyone who does it, doesn't care about reordering,
no matter of jitter, because even in very stable jitter, the paths may
be unequal length and cause reordering.

LACP hellos are sent every 1s when in fast mode with 3s keepalive,
which also isn't particularly tight. We do have customers running LACP
over MPLS pseudowires over great distances.

--
  ++ytti
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200708/9c05ca06/attachment.html>