Link Aggregation - Load Sharing - Question

[an_technical]

Hi Team,

Good day

I am trying to understand what this statement means?

• Load Sharing (Active/Active): All interfaces are active, but handle different connections simultaneously. Traffic is balanced amongst subordinate interfaces to maximize throughput. The Load Sharing option does not support switch redundancy

What are the limitations on switch side if we configure load sharing? The switches are Arista switches.

Thanks 

[AkosBakos · Accepted solution]

Hi @an_technical 

ftom the AI:

What Does This Mean in Practice?

• No Switch Redundancy in Load Sharing:
  If you use Load Sharing mode for your bond, the system will not automatically switch over to a backup switch if the primary switch fails.

  • If a switch connected to one of the bond interfaces goes down, traffic through that interface will be affected, and the bond will not automatically reroute all traffic through a different switch.
  • This can lead to loss of connectivity for the affected paths, even though other interfaces in the bond may still be up.

[G_W_Albrecht · Accepted solution]

If you use HA, you have redundancy - if one switch port fails, the other from the Bond will take over. With Load sharing, both ports of the Bond are in use, so there is no redundancy !

[the_rock]

The guys are 100% right, thats exactly it.

Andy

[the_rock · Accepted solution]

Also, to add to all this, though its another AI answer, but see below things listed for limitrations.

Andy

**********************************

When configuring load sharing on a switch—particularly in the context of EtherChannel (link aggregation) or port-channel-based load balancing—there are several limitations you should be aware of on the switch side:

---

🔹 1. Load Balancing Algorithm Limitations

• Static algorithms: Most switches use static load balancing algorithms (e.g., based on source/destination MAC/IP/port). These do not adapt dynamically to traffic load.

• Uneven distribution: If traffic flows share the same hash result (e.g., same source/destination IP), they may all use the same physical link, leading to underutilization of other links.

• No per-packet balancing: To preserve packet order, most switches use per-flow hashing rather than per-packet, limiting fine-grained load sharing.

---

🔹 2. Hardware Constraints

• Hashing method limitations: Lower-end switches may only support a limited set of hashing options (e.g., only source MAC or IP).

• ASIC capabilities: Some switches have hardware ASICs that determine how flexible or efficient load balancing can be.

---

🔹 3. Interoperability Issues

• Mismatch with other devices: Load sharing policies (e.g., Cisco vs HP vs Juniper) can differ, leading to asymmetrical traffic or link failures if not configured compatibly.

• Inconsistent hashing: If two ends of a link aggregate use different hashing criteria, packet ordering and throughput issues can occur.

---

🔹 4. Link Speed and Duplex Mismatch

• All member links should ideally be identical in speed and duplex. Otherwise, the load-sharing may favor faster links, which may still lead to congestion if not managed properly.

---

🔹 5. Traffic Type Sensitivity

• Single-flow sessions (like large TCP transfers) can't be split across links, which limits the usefulness of load sharing in some scenarios.

• Latency-sensitive traffic may be affected if not evenly distributed.

---

🔹 6. Failover Granularity

• If a physical link fails, the switch reroutes traffic to other links. However, reconvergence isn’t always instant and may briefly disrupt traffic.