VSNext on ElasticXL (R82+) with Shared External/Campus vSwitches and Internal Transit vSwitch

[yeruel]

Hello Check Point Team / TAC,

We are designing a high-capacity multi-tenant datacenter security architecture using VSNext on an ElasticXL cluster (R82+) deployed on Quantum Force 29200 Plus appliances.

The upstream/downstream fabric consists of active-active Arista MLAG switches using LACP, VARP, and OSPF.

We would appreciate architectural validation and best-practice guidance regarding shared vSwitch behavior, inter-VG traffic flow, and ElasticXL session handling.

1. ARCHITECTURE OVERVIEW
   
   

Physical Connectivity (VS0):

• Bond1 (LACP active-active)
  → External / Internet Arista MLAG pair

• Bond2 (LACP active-active)
  → Server Farm Arista MLAG pair

• Bond3 (LACP active-active)
  → Campus/Core Arista MLAG pair

Virtual Gateways (Tenants):

• VG1_PRODUCTION

• VG2_TEST

• VG3_THIRDPARTY

Software Virtual Switching Layout:

A. External Shared Space

• Six external vSwitches (vSwitch4002–vSwitch4007)

• All mapped to Bond1

• All three VGs attach virtual interfaces into these shared external vSwitches

• Shared external subnets are used with unique tenant IP addressing

B. Campus Shared Space

• Single shared vSwitch_Campus_4008

• Mapped to Bond3 (VLAN 4008)

• All three VGs attach interfaces into this shared campus segment

• OSPF/BFD adjacency established toward Arista core switches

C. Server Farm Space

• VLAN subinterfaces directly trunked over Bond2

• Each VG owns its own server VLANs

Examples:

• VG1 → VLANs 100–215

• VG2 → VLANs 204–216

• etc.

D. Inter-Tenant Transit Space

• Internal-only virtual switch:
  vSwitch_Transit

• Transit subnet:
  10.254.254.0/24

• Used for VG-to-VG routing via static routes

Traffic path example:
VG1 → vSwitch_Transit → VG2/VG3

Example traffic path:

1. Campus user traffic arrives from Arista Core switches.

2. LACP hashing forwards the packet through Bond3 onto ElasticXL Node 2.

3. vSwitch_Campus_4008 receives the tagged VLAN traffic.

4. Traffic is forwarded to VG1_PRODUCTION.

5. VG1 enforces Security Policy Package (Pkg_VG1).

6. Routing decision forwards traffic toward VG2_TEST via:
   next-hop 10.254.254.2 over vSwitch_Transit.

7. Packet traverses kernel backplane memory through the internal vSwitch.

8. VG2_TEST receives the packet and performs its own policy inspection.

9. Traffic exits through Bond2 toward the Server Farm switches with VLAN 204 tagging.

Question 1:
Shared External & Campus vSwitch Design Validation

Is it fully supported under VSNext + ElasticXL (R82+) to:

• Bind a physical aggregate link (Bond1/Bond3) to multiple shared external vSwitches

• Attach virtual interfaces from multiple VGs simultaneously into those same shared vSwitches

• Share the same external/campus subnets across multiple tenants

within an active-active ElasticXL architecture?

Question 2:
VMAC / ARP / MAC Learning Behavior

With multiple VGs attached to the same shared vSwitches:

• How does VSNext generate and manage virtual MAC addresses?

• How are ARP domains isolated?

• Is there any known risk of MAC flapping on upstream Arista MLAG switches?

• Are there recommended ARP or gratuitous ARP tuning parameters?

Question 3:
Inter-VG Transit Processing

When traffic traverses:

VG1 → vSwitch_Transit → VG2

does the packet undergo:

• Independent stateful inspection in both VGs?

• Separate SecureXL/FWXL processing stages?

• Full connection table creation in both routing domains?

Additionally:

If ElasticXL Node 2 owns the session for VG1 while Node 1 owns the session for VG2:

• Does ElasticXL perform internal session ownership correction/path synchronization?

• Are there known performance penalties for inter-VG transit traffic?

Question 4:
OSPF Multicast Isolation

Since vSwitch_Campus_4008 acts as a shared L2 broadcast domain:

• Will OSPF multicast packets (224.0.0.5 / 224.0.0.6) be cleanly isolated per VG routing instance?

• Can all VGs independently form OSPF adjacencies with the same Arista core peers?

• Are there any known multicast scaling considerations for shared vSwitch deployments?

Question 5:
Internal Transit vSwitch & sk183336

We intend to use an internal-only vSwitch (vSwitch_Transit) for inter-tenant routing.

We found SK:
sk183336

which references traffic drops between Virtual Gateways connected through internal virtual switches.

Questions:

• Is this topology now fully supported in active-active ElasticXL mode?

• Which exact Jumbo Hotfix Take completely resolves this issue?

• Are there recommended limitations or design caveats regarding internal-only transit vSwitches?

Question 6:
Licensing & Performance

Do additional vSwitches consume:

• Extra VS licenses?

• Additional worker resources?

• Additional SecureXL acceleration contexts?

Or are vSwitches treated purely as internal VS0 infrastructure objects?

We would greatly appreciate guidance on:

• Recommended Gaia tuning parameters

• Shared vSwitch optimization

• Any scaling limitations or unsupported patterns

• Recommended design alternatives if applicable

Environment:

• Quantum Force 29200 Plus

• R82+ VSNext

• ElasticXL Active-Active

• Arista MLAG fabric

Thank you in advance for your support and architectural validation.

[emmap]

Given the in depth queries here I would recommend engaging your local Check Point office for a proper Q&A session, but here's a couple of pointers:

Q1: Yes, VSwitches are deployed to share VLANs between multiple Virtual Systems. 

Q2: The VSID is included in the MAC address on VS interfaces, ensuring that each VS has unique MAC addresses on the network. No tuning is required here.

Q3: Your 'transit' VSwitch requires a VLAN connected on one of your trunks. This VLAN will be used if packets traverse VSs and have to 'change' SGMs. As such you could eliminate this dedicated transit VSw from your design and use one of the existing ones if you prefer. Some SXL acceleration can occur when packets traverse two VSs this way to skip parts of the FW Chain where security will not be compromised. This will reduce performance penalties. You can further reduce performance penalties by skipping inspection blades on one of the VSs for this transitting traffic. 

Q4: VSs will operate OSPF independently from each other. If you configure it on both VSs sharing a VSwitch they'll end up forming an adjacency with each other, pretty sure. You'll need to account for this in your configuration.

Q5: See Q3. Your transit VSwitch must have a VLAN or interface out to the switching layer. This is by design and will not be changed by any patches. 

[Bob_Zimmerman]

It sounds like your "Campus Shared Space" and "Inter-Tenant Transit Space" provide two paths between the VSs. I would probably pick one or the other.

In your traffic flow, "LACP hashing forwards the packet through Bond3 onto ElasticXL Node 2." isn't quite how it works. All traffic goes to ElasticXL member s01-01 by default (another pivot member gets selected if s01-01 is down). That member handles some traffic, then it sends other traffic back out the same interface with the destination vMAC of one of the other members. This means a lot of traffic will hit the links to the pivot member in both directions and will hit a third link direction (switch to s01-01, s01-01 to switch for s01-02, switch to s01-02).

• Question 2 - VMAC / ARP / MAC Learning Behavior

Not sure, but here are the MACs my VSNext cluster is using for the warps to VS500:

Member VSID  Iface         Member MAC
------ ----- -----  -----------------
s01-01 0      wrp0  00:12:c1:10:00:fc
s01-01 1     wrp64  00:12:c1:10:08:fc
s01-02 0      wrp0  00:12:c1:20:00:fc
s01-02 1     wrp64  00:12:c1:20:08:fc

With both members up:
? (10.0.1.252) at 00:12:c1:10:00:fc [ether] on eth1
? (10.0.1.250) at 00:12:c1:10:08:fc [ether] on eth1

After cpstoping member s01-01:
? (10.0.1.252) at 00:12:c1:20:00:fc [ether] on eth1
? (10.0.1.250) at 00:12:c1:20:08:fc [ether] on eth1

I don't have a second "site" to see how that affects the MACs, but I would expect those members to change only the first nibble of byte 4.

ARP domains are router-style. Every VLAN on every interface is separate within a VS. Switch VSs are bridges between the warps and optionally a physical interface:

[Expert@DallasticXL-s01-01:500]# ifconfig | grep -Po "^[^ ]+"
Mgmt
br500
lo
magg1
wrpj0
wrpj64

[Expert@DallasticXL-s01-01:500]# grep "Slave Interface" /proc/net/bonding/magg1
Slave Interface: Mgmt

[Expert@DallasticXL-s01-01:500]# bridge link
15: wrpj0 state UNKNOWN : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br500 state forwarding priority 32 cost 100 
6: magg1 state UP : <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 master br500 state forwarding priority 32 cost 4 
13: wrpj64 state UNKNOWN : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br500 state forwarding priority 32 cost 100 

Mgmt is a member of magg1. magg1, wrpj0, and wrpj64 are all members of br500.

• Question 6 -  Do additional vSwitches consume extra VS licenses?

No, switches don't need licenses.

• Question 6 - Do additional vSwitches consume additional worker resources?

They're each an additional namespace, but that's a trivial amount of extra memory to track.

• Question 6 - Do additional vSwitches consume additional SecureXL acceleration contexts?

[Expert@DallasticXL-s01-01:500]# fwaccel stat
fwaccel: this command can only be used on an enforcement module.

• Question 6 - Or are vSwitches treated purely as internal VS0 infrastructure objects?

Switch VSs are their own VSs, and all VSs are separate network namespaces. Each VS can be layer 2 or layer 3, and each VS can just handle traffic or can apply firewall rules/features. Layer 2 without firewalling is a switch. Layer 2 with firewalling is a bridge-mode VS. Layer 3 without firewalling is a virtual router. Layer 3 with firewalling is a normal VS. All VSs except switches consume license slots.