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

CCSA R82 — Check Point Certified Security Administrator Study Guide Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Introduction & Architecture

1.1 CCSA R82 Exam Facts 1.2 Standalone vs Distributed Deployment 1.3 Gaia OS, clish and expert Mode 1.4 The SmartConsole Suite 1.5 Secure Internal Communication and the ICA

2 Chapter 2: Security Policy & Access Control

2.1 Policy Packages 2.2 Access Control Policy Overview 2.3 Ordered Layers and First-Match Evaluation 2.4 Inline Layers and Nested Rule Matching 2.5 Access Rules: Fields, Actions, and Track Options 2.6 Implied Rules and Global Properties 2.7 Stealth and Cleanup Rules: Placement and Best Practice 2.8 Hit Count and Policy Install Workflow

3 Chapter 3: Network Address Translation (NAT)

3.1 NAT Overview in Check Point 3.2 Hide NAT (Many-to-One) 3.3 Static NAT (One-to-One) 3.4 Automatic vs Manual NAT and Proxy ARP

4 Chapter 4: Identity Awareness

4.1 Identity Awareness Overview 4.2 Active Directory Query 4.3 Identity Collector 4.4 Identity Agent 4.5 Captive Portal and Access Roles

5 Chapter 5: Threat Prevention

5.1 Threat Prevention Overview 5.2 Application Control 5.3 URL Filtering 5.4 Intrusion Prevention System (IPS) 5.5 Anti-Bot and Anti-Virus 5.6 Threat Emulation and Threat Extraction 5.7 TP Profiles, Best Practice, and Ordered Layers for TP 5.8 HTTPS Inspection

6 Chapter 6: ClusterXL — High Availability, Load Sharing, and Failover

6.1 ClusterXL Overview: Why Clustering, HA vs Load Sharing 6.2 High Availability Mode: Active/Standby, Primary Up vs Active Up 6.3 Load Sharing Modes: Multicast, Unicast (Pivot), and Traffic Distribution 6.4 Cluster Control Protocol (CCP) and State Synchronization 6.5 Failover, Cluster States, and Troubleshooting with cphaprob

7 Chapter 7: VPN, Logs, and Troubleshooting

7.1 Site-to-Site IPsec VPN 7.2 Remote Access VPN 7.3 Encryption Domains and VPN Communities 7.4 Mobile Access Blade 7.5 Logs, Monitor, and SmartEvent 7.6 Backups, Snapshots, and Migrate Export 7.7 fw monitor, fw ctl zdebug, and cpview 7.8 cpinfo and Common Issues

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

Key Takeaways Explain This Topic AI

ClusterXL has two Load Sharing solutions: Multicast mode and Unicast (Pivot) mode — both keep all members Active and forward traffic in parallel.

Multicast mode associates the cluster VIP with a multicast MAC; all members receive every packet and a decision function on each member decides whether to process it. It does not support IPv6 and requires multicast-capable switches.

Unicast (Pivot) mode is for switches that do not support multicast: one member (the Pivot) receives all packets and either processes them or forwards them to a non-Pivot member.

In Unicast mode the Pivot receives a smaller share of the load (e.g., 30% in a 2-member cluster, 20% in a 3-member cluster) because it also has to redistribute packets.

On Pivot failure, another non-Pivot member becomes the new Pivot and sends Gratuitous ARPs to re-associate the cluster VIP with its MAC; on non-Pivot failure, traffic is redistributed among the remaining members.

Last updated: July 2026

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:

At least one member processes every packet (nothing is dropped).

No two members process the same packet (nothing is duplicated).

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:

Total Members Pivot Share Each Non-Pivot Share
1 100% —
2 30% 70%
3 20% 40%
4 10% 30%
5 0% 25%

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

Requirement Recommended Mode
Maximum throughput, switches support multicast MAC Load Sharing Multicast
Switches do not support multicast MAC Load Sharing Unicast (Pivot)
IPv6 traffic must be load-shared Load Sharing Unicast (Pivot)
Cloud or hypervisor where multicast is filtered Load Sharing Unicast (Pivot)
Redundancy only, no throughput gain needed HA mode (not Load Sharing)
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).