Re: Sites unreachable while traversing Dallas IXP

[Nick Hilliard via NANOG <nanog () lists nanog org>]

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