6.3 Load Sharing Modes: Multicast, Unicast (Pivot), and Traffic Distribution

Load Sharing Multicast Mode

Load Sharing Multicast is the default Load Sharing mode and the highest-throughput option. It works by associating the cluster VIP with a multicast MAC address (in the 01:00:5E:xx:yy:zz range). When the upstream router ARPs for the cluster VIP, the cluster replies with that multicast MAC, so every packet sent to the cluster VIP is delivered by the switch to every cluster member at the same time.

Once all members have a packet, each member runs the decision function — a deterministic per-packet check that guarantees three things:

1. At least one member processes every packet (nothing is dropped).
2. No two members process the same packet (nothing is duplicated).
3. Packets from the same connection are routed to the same member whenever possible, so connection state stays local and sync traffic is minimized.

When a packet lands on the "wrong" member for its connection, State Synchronization hands the connection state over so the member can process it. This is why state sync is mandatory in Load Sharing — without it, connections that span members would fail.

Multicast Mode Constraints

• Supports up to 5 cluster members; more than 4 begins to degrade performance because every member inspects every packet.
• Does not support IPv6. For IPv6 deployments, use HA or Load Sharing Unicast.
• Requires switches that accept a multicast MAC in ARP replies. Some access-layer switches refuse multicast MACs in their ARP/MAC tables, which breaks the cluster. Test before deploying.
• No ARP changes on failover. Because the cluster VIP is associated with the multicast MAC regardless of which member is Active, failover does not require GARPs or ARP changes — traffic still reaches all remaining Active members automatically. This makes multicast failover faster and cleaner than HA failover.

Load Sharing Unicast (Pivot) Mode

Load Sharing Unicast, also called Pivot mode, is designed for environments where multicast Ethernet does not work — switches that block multicast MACs, certain cloud hypervisors, or IPv6 deployments. Instead of sending every packet to every member, the cluster associates the cluster VIP with the Pivot member's unique unicast MAC. The Pivot is the only member that receives packets from the upstream router.

The Pivot then applies the decision function to every packet and either:

• Processes the packet itself, or
• Forwards it to a non-Pivot member over the cluster's internal links.

Non-Pivot members that receive a forwarded packet handle it without re-applying the decision function — they still run all the normal Firewall, NAT, IPS, and VPN processing, but they trust the Pivot's decision about ownership.

Default Load Distribution in Unicast Mode

Because the Pivot's redistribution work is time-consuming, the Pivot is assigned a smaller share of the load:

This table is a useful exam reference. The Pivot's share shrinks as the cluster grows because the redistribution overhead grows with the number of non-Pivot members.

Pivot Selection and Failover

The Pivot is always the Active member with the highest priority. If the current Pivot fails, a regular failover event occurs and another non-Pivot member assumes the Pivot role. The new Pivot sends Gratuitous ARP (GARP) requests to associate the cluster VIPs with its own unique MAC address — this is necessary because in Unicast mode the cluster VIP is bound to the Pivot's MAC, so the router must learn the new MAC.

When a non-Pivot member fails, the Pivot and remaining non-Pivots simply redistribute that member's share of traffic among themselves; no Pivot change occurs and no GARPs are sent.

When a former Pivot recovers, it retains its previous role and becomes the Pivot again, because it has the highest priority — this is similar to HA Primary Up behavior.

When to Use Each Load Sharing Mode

Exam-Critical Distinctions

A few distinctions come up repeatedly on the CCSA R82 exam:

• CCP transport mode (Auto / Unicast / Multicast / Broadcast) is not the same as the Load Sharing mode (Multicast / Unicast-Pivot). CCP transport mode controls how CCP heartbeats and sync packets are sent between members on the sync network; Load Sharing mode controls how the cluster handles data-plane traffic to the cluster VIP. They are independent settings, and on recent R82.x versions CCP always runs in unicast regardless of the Load Sharing mode.
• State sync is mandatory in both Load Sharing modes but only recommended in HA. The exam often tests this by asking what is required when you enable Load Sharing.
• Multicast mode does not support IPv6 — if a question mentions IPv6 and Load Sharing together, the answer is Unicast (Pivot).