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@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@gmail.com @dCoSays www.venicesunlight.com