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 < [email protected]> a écrit : > 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/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/7JYP7MCJRI3CQPHZPWFAOJDF6VBDROID/
