Re: Sites unreachable while traversing Dallas IXP

[Mel Beckman via NANOG <nanog () lists nanog org>]

Nick,

I agree that theoretically there should be no problem with different hashing implementations on each end, but as I 
noted in my original answer, I have directly experienced issues like packet reordering and dropped packets. Perhaps 
this was due to a bug of some sort in one of the implementations. I do know that changing ONLY the algorithm on one end 
solved the problem. Once I found a working configuration, I simply noted the potential issue for the future and avoided 
it. Software is too squishy to expect it to always implement every standard perfectly.

-mel

> On Sep 26, 2025, at 7:57 AM, Nick Hilliard <nick () foobar org> wrote:
>
> Mel Beckman wrote on 26/09/2025 15:32:
> > From
> > https://www.exam-labs.com/blog/configuring-lacp-between-cisco-ios-and-juniper-junos-a-step-by-step-guide
> >       *Understanding LACP Failures and Common Pitfalls*
> > Link aggregation, although a robust feature, is susceptible to various issues. To resolve these problems 
> > effectively, network administrators must first understand the potential causes of LACP failures. Here are some of 
> > the most common causes for LACP issues:
> > 1. *Mismatched Configurations:**
> >   *Often, the primary reason for LACP failure is a misalignment in
> >   configurations between the two devices. This might include
> >   differences in LACP modes (active vs. passive), inconsistent
> >   port-channel settings, or mismatched VLANs. Proper alignment of
> >   settings across both devices is crucial to the successful
> >   negotiation of LACP.
>
> Not sure what this has to do with your previous email, where you were specifically referring to hashing algos needing 
> to be the same or "compatible" on each side of the link:
>
> > Instead you configure one of the available hash-based distribution functions the two endpoints have in common.
>
> > I’ve found that sometimes with LAGs between different equipment vendors one or more of these algorithms aren’t 
> > compatible, resulting in packets out of order or even dropped.
>
> There's no such thing as the packet hashing algorithms needing to be "compatible" on each side of a LAG bundle. You 
> can use whatever hashing algo you want on either side and it doesn't make the slightest difference at the other end. 
> There's no concept of hashing algo compatibility, and hashing doesn't come into play with LACP or any other sort of 
> negotiation.
>
> With the link above, you're confusing LACP negotiation issues with packet loss. If you have an LACP negotiation 
> failure, typically the LAG interface won't come up to start with on a juniper / cisco device. Sometimes - rarely - 
> you can have failure modes where an individual bearer circuit won't be used correctly, which would cause 1/N*100% 
> packet loss, i.e. 50% if N=2.
>
> Also, as this is an IXP link, it probably means that it's a single untagged VLAN, i.e. no mismatched vlans.  Although 
> if there is a mismatched vlan, then that vlan will experience 100% packet loss.
>
> Nick
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/NIT5GRP4AEUXDR25NAA3RMPECEM5EC7M/