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/TTWMOLCGU5NLRTNDMPVBCJH4G5VVJ4WX/
