Lossy cogent p2p experiences?

Sat Sep 9 20:29:49 UTC 2023

At a previous $dayjob at a Tier 1, we would only support LAG for a customer
L2/3 service if the ports were on the same card. The response we gave if
customers pushed back was "we don't consider LAG a form of circuit
protection, so we're not going to consider physical resiliency in the
design", which was true, because we didn't, but it was beside the point.
The real reason was that getting our switching/routing platform to actually
run traffic symmetrically across a LAG, which most end users considered
expected behavior in a LAG, required a reconfiguration of the default hash,
which effectively meant that [switching/routing vendor]'s TAC wouldn't help
when something invariably went wrong. So it wasn't that it wouldn't work
(my recollection at least is that everything ran fine in lab environments)
but we didn't trust the hardware vendor support.

On Sat, Sep 9, 2023 at 3:36 PM Mark Tinka <mark at tinka.africa> wrote:

>
>
> On 9/9/23 20:44, Randy Bush wrote:
>
> > i am going to be foolish and comment, as i have not seen this raised
> >
> > if i am running a lag, i can not resist adding a bit of resilience by
> > having it spread across line cards.
> >
> > surprise!  line cards from vendor <any> do not have uniform hashing
> > or rotating algorithms.
>
> We spread all our LAG's across multiple line cards wherever possible
> (wherever possible = chassis-based hardware).
>
> I am not intimately aware of any hashing concerns for LAG's that
> traverse multiple line cards in the same chassis.
>
> Mark.
>

-- 
- Dave Cohen
craetdave at gmail.com
@dCoSays
www.venicesunlight.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230909/bcd3f81f/attachment.html>