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 <[email protected]> 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/[email protected]/message/NIT5GRP4AEUXDR25NAA3RMPECEM5EC7M/
