As @Leo Laohoo notes in his initial reply, all member links need to be the same "bandwidth", but member link distance latency isn't an issue, or is it?
I suspect, Etherchannel, if it monitors latency across its member links, may consider a huge latency delta between member links as problematic. (Possibly a sort of, if one link is so different, and worse than others, there must be something "faulty" with that link. Or, basically, only a issue because it's just an unexpected difference.)
However, the distance delta is only about 1.3 miles, so the additional latency is about 10 microseconds (if my math is correct). I would also suspect, this wouldn't be an issue, assuming member link latency is monitored.
BTW, a similar question was raised on these forums before: https://community.cisco.com/t5/switching/fibre-link-length-and-etherchannel/td-p/2472878
Also, my browser's AI summary is:
Using an Etherchannel (or LACP) with links that have significantly different latencies is generally not problematic for the core functionality of the link aggregation, as long as the links are of the same speed and duplex settings. This is because Etherchannel uses a hashing algorithm to assign individual traffic flows to specific physical links within the bundle, ensuring that all frames belonging to the same flow are sent over the same physical link. This prevents out-of-order packet delivery, which is critical for protocols like TCP.
The primary concern with differing latencies is the potential for increased latency on the longer path. However, the difference in latency due to physical length is typically minimal. For example, a 200-meter difference in fiber length adds only about 1 microsecond of additional latency. Such a small difference is negligible for most real-world applications and is unlikely to cause issues at the TCP/IP stack level, as the stack can auto-adjust to changes in latency.
While the standard load-balancing mechanism ensures that a single session uses one link consistently, the overall performance of the Etherchannel is not degraded by latency differences. The throughput of the entire channel is determined by the combined bandwidth of the links, not by the latency of individual paths. However, if one link is significantly longer and has higher attenuation (signal loss), it could potentially lead to errors or reduced performance, especially if the link is operating near its limits. In such cases, even if no errors are reported, the effective throughput might be limited by the weaker link.
It is important to note that while latency differences themselves are not a technical barrier, using Etherchannel over WAN links with different providers or paths can introduce other complications, such as difficulty in troubleshooting and potential issues with link state synchronization if one path fails. In such scenarios, using ECMP (Equal-Cost Multi-Path) routing with a dynamic routing protocol is often a more reliable and manageable alternative.
In summary, minor differences in latency due to physical length are not a concern for Etherchannel operation, but significant differences in link quality or path characteristics (such as those caused by different providers) should be carefully evaluated to avoid potential performance or management issues.
@ERTP1 wrote:
I have a question about this — I’d like to know if it’s considered good practice or good design to configure a port-channel between two buildings that are interconnected by two dark fibers. One fiber has a distance of 10.5 kilometers (~6.5 miles) and the other route has a distance of 8.5 kilometers (~5.2 miles).
Is this considered a good practice? What are the advantages and disadvantages? Our two sites operate as an extended LAN due to business necessity.
Personally, I don't see doing this as either a good or bad practice.
As to advantages and disadvantages, well they're pretty much the typical Etherchannel advantages and disadvantages. Are you well acquainted with those? (You later wrote "I have configured a point-to-point L3 connection with ECMP for traffic balancing before, but not an L2 port-channel.", so possibly you're not?)
