Hi Maybe you are now connected to 2 different remote devices in MLAG/VPC or ESI, which could have MTU / routing table inconsistencies. So, as suggested in some previous mails, did you try to deactivate the new link and keep the bgp setup as it was originally? Cordialement / Best regards Pierre Le ven. 26 sept. 2025, 11 h 06 a.m., Nick Hilliard via NANOG < nanog@lists.nanog.org> a écrit :
Mel Beckman wrote on 26/09/2025 15:32:
From
https://www.exam-labs.com/blog/configuring-lacp-between-cisco-ios-and-junipe...
*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/TTWMOLCG...