Create a Post
Cyprien_Leseurr
Participant

Can we avoid the promiscuous mode for vSEC clustering ?

I work since few weeks on the virtualization of checkpoint security gateways. And to allow HA protocol (CCP) in order to create a clusterXL, I had to enabled the promiscuous mode on vmware.
So I was wondering if there was not another solution.
If not, is there some best pratices to avoid route causes on datacenters (packet loss for example) ?

0 Kudos
23 Replies
PhoneBoy
Admin
Admin

I'm not sure what you mean by "route causes."

In general, the CCP packets (which are Multicast by default) are there to determine reachability/availability of the cluster members on interfaces.

You can potentially switch ClusterXL mode to Broadcast mode: How to set ClusterXL Control Protocol (CCP) in Broadcast / Multicast mode in ClusterXL 

0 Kudos
Cyprien_Leseurr
Participant

Actually it may not be the right term. 

In order "to determine reachability/availability of the cluster members on interfaces", we must authorize the promiscuous mode on the vSwitch in VMware (both Broadcast and Multicast) 

And I have some packet loss in my datacenter due to this mode , so I search some best practices to avoid this mode or reduice its impact.

But I didn't find yet informations about this (in forum or in CP docs).

For information, we use vSphere 5.5.

Maybe you have another idea ?

0 Kudos
PhoneBoy
Admin
Admin

Unfortunately, ClusterXL in its various forms requires multicast or broadcast packets, so this mode is required.

Its use is commensurate with the amount of traffic being passed by the cluster. 

Perhaps you can limit it's impact by reducing the number of devices directly connected to the same vSwitches as the vSEC instances.

As this sounds like a VMware issue, have you engaged with them at all?

Cyprien_Leseurr
Participant

You have perfectly right. It's indeed a VMware issue and it would seem that we must upgrade our vSphere plateform to version 6. 

With v6 we could use multicast without promiscuous mode but I would have liked to have Checkpoint confirmation that this is the best practice.

By the way thanks for your response. 

0 Kudos
Vladimir
Champion
Champion

The packet loss you are referring to may be due to the broadcast control configured on physical switches your ESXi servers are connected to.

Please verify if there are any settings limiting broadcast set on the ports corresponding to NICs that have port groups and vSwitches assigned to the ClusterXL members. 

Cyprien_Leseurr
Participant

Thank you, I will check this lead with the virtualization infrastructure team.

0 Kudos
Pablo_Barriga
Advisor

Hello , Is there any way to avoid promiscuous mode with R80.20 or R80.30?

 

0 Kudos
Zach_S
Employee
Employee

Why do you need promiscuous mode? Do you have VMAC enabled?

Also, CCP supports unicast mode of operation as of R80.30 (need to configure it).

0 Kudos
Pablo_Barriga
Advisor

Hello I tried with R80.20, I configured unicast mode, but the sync lync still showing down, I read that promiscuos mode still mandatory to syncronize the cluster, if you have any material or configuration manuals will be great.

0 Kudos
Pablo_Barriga
Advisor

Hello two gw with dvswitch , its configured as unicast, the sync interface remains down. This lab is with version r80.20 

cluster.jpg

 

Each interface has its own portgroup. 

0 Kudos
Vladimir
Champion
Champion

@Pablo_Barriga , each interface or each pair of interfaces?

0 Kudos
Pablo_Barriga
Advisor

Each network adapter has its own portgroup. 

interfaces.jpg

0 Kudos
Vladimir
Champion
Champion

@Pablo_Barriga , what i am trying to determine if your Sync interfaces of both cluster member are sharing the same portgroup. They should.

0 Kudos
Pablo_Barriga
Advisor

Yes each gw share the same portgroup with their segments, we have IP connectivity with all the IP address of each interface connected, but the sync still down. I haven´t try VMAC enabled yet
0 Kudos
Vladimir
Champion
Champion

Are the vSECs on the same host or on two different hosts?

0 Kudos
Pablo_Barriga
Advisor

Different hosts
0 Kudos
Vladimir
Champion
Champion

I suggest v-motioning the vSECs to the same, verifying that it works and if it does, moving them back to separate hosts and looking at the portgroup/dvswitch/physical switch to see where its getting lost.

0 Kudos
Pablo_Barriga
Advisor

Hello both gws are on the same host, but the cluster remains down, VMAC enabled.

chk-cluster2.png

0 Kudos
G_W_Albrecht
Legend
Legend

I would involve TAC to resolve this...

0 Kudos
Pablo_Barriga
Advisor

Hello, they told me to activated promiscuous mode, thats quite complicated because its a vcloud infraestructure. I'm going to try to replicate the problem with other versions.

 

0 Kudos
Maarten_Sjouw
Champion
Champion

I think you also need to check the port security settings, this has many times been the culprit for us.
Regards, Maarten
0 Kudos
Pablo_Barriga
Advisor

So far everything is quite secure, looks like I'll have to use an ADC for load balacing

security-port.jpg

0 Kudos
dphonovation
Explorer

For anything visiting here and in VMWare:

I am on my 3rd lab. The first was done with open source OPNSense (based on PFSense) with its own CARP/VRRP implementation. Network design remained the same throughout all 3 labs and so did the VMWare kit it was hosted on.

I dealt with the promiscious thing in OPNSense, where the implementation is far more finicky. It appears it used the "virtual mac" option and therefore required me to create separate vSwitches just for the router MGMT interface for each network I wanted it to participate in (= double the networks).

I tested this for several hours and while I stopped short of enabling VirtualMac on the CP Cluster in my labs (for the dbl network reason and sticking whole switches in promisc mode isn't my idea of fun) - I CAN 100% CONFIRM Cluster VIPs WORK IN vSwitches that are not in promiscious mode. I had both broadcast and unicast succeeding. (The cluster picked broadcast mode when the dedicated sync interface had no IPs assigned and unicast when they got a /30 in between themselves). I'm on ESX 6.7 but I doubt that matters. It's a under-the-hood VxLan bridging/networking thingie, not inherently a VMWare problem.

0 Kudos