topic Link Aggregation - Load Sharing - Question in Firewall and Security Management

Link Aggregation - Load Sharing - Question

an_technical — Wed, 30 Apr 2025 09:47:47 GMT

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

Re: Link Aggregation - Load Sharing - Question

AkosBakos — Wed, 30 Apr 2025 11:11:58 GMT

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.

Re: Link Aggregation - Load Sharing - Question

G_W_Albrecht — Wed, 30 Apr 2025 11:16:11 GMT

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 !

Re: Link Aggregation - Load Sharing - Question

the_rock — Thu, 01 May 2025 00:43:18 GMT

The guys are 100% right, thats exactly it.

Andy

Re: Link Aggregation - Load Sharing - Question

the_rock — Thu, 01 May 2025 00:49:21 GMT

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.