Clustering supports VLANs?

[jmcgrady]

Does Checkpoints clustering work with tagged dot1q vlans? I have two vlans created on a SPLAT ethernet interface - eth2.26 and 2.27. The interface trunks into a Cisco 2950 switch. All seems correct, however i cant reach the ip addresses of any machines connected to this switch. When i do a cphaprobe -a if on the firewall it doesnt list these interfaces quite as i would expect:

Required interfaces: 4
Required secured interfaces: 1

eth0 UP sync(secured), broadcast
eth1 DOWN (64355.3 secs)non sync(non secured), broadcast
eth3 DOWN (64355.3 secs)non sync(non secured), broadcast
eth4 UP non sync(non secured), broadcast
eth5 DOWN (64355.3 secs)non sync(non secured), broadcast
eth6 DOWN (64355.3 secs)non sync(non secured), broadcast
eth7 UP non sync(non secured), broadcast
eth2 UP non sync(non secured), broadcast (eth2.26 )

Virtual cluster interfaces: 5

eth0 10.1.1.50
eth4 16.17.23.1
eth7 16.17.28.1
eth2.26 16.17.45.1
eth2.27 16.17.10.1


Does ClusterXL fully support vlaned interfaces?

[avjana]

Yes this works with the latest service pack

[Izzio]

The only limit that I know is: "Cluster Sync should take place over a real (no trunked) interface".

Which version are you using?

Ciao - Maurizio

[jmcgrady]

I'm using R60 HFA3 on secureplatform. I believe it is working. However the output of cphaprob and the web tools is somewhat ambiguous.

[kaldek]

Clustering with VLANs does work - since R55 I believe. The way it works is somewhat "poorly documented", but it's actually not too bad.

The ClusterXL developers were smart enough to realise that when using VLANs, your physical interface might stay up, but it's possible for the switch to stop forwarding VLAN tagged packets. In that situation you could find that ClusterXL stayed active since the physical port was up but the firewall was effectively broken because packets could not be sent or received on a tagged VLAN interface.

What ClusterXL does to counter this is monitor the lowest-numbered VLAN attached to an interface, and send gratuitous ARP requests to all possible IP addresses in that VLAN until it gets a response. It then also tries to send an ICMP ping packet to the first host that it finds; if a response comes back the VLAN interface is considered "up".

For example, if you had a firewall with interfaces eth6.400 and eth6.401, ClusterXL will monitor interface eth6.400 (since it's the lowest numbered VLAN), and begin to send an ARP flood to the entire IP subnet of that VLAN. Once it finds someone and they respond, ClusterXL goes into "Active" state.

Note that other cluster members are good enough - their ARP requests will find each other and consider the VLAN up since Node A would see Node B and vice versa.

[jmcgrady]

I'm still getting some strangeness with it. I'm now using load sharing unicast mode. The 2nd gateway is showing as down due to only having 4 of the required 5 interfaces up. Heres an output from cphaprob:

Required interfaces: 5
Required secured interfaces: 1

eth0 UP sync(secured), broadcast
eth1 DOWN (224.2 secs)non sync(non secured), broadcast
eth3 DOWN (224.2 secs)non sync(non secured), broadcast
eth4 UP non sync(non secured), broadcast
eth5 DOWN (224.2 secs)non sync(non secured), broadcast
eth6 DOWN (224.2 secs)non sync(non secured), broadcast
eth7 UP non sync(non secured), broadcast
eth2 UP non sync(non secured), broadcast (eth2.2 )

Virtual cluster interfaces: 5

eth0 10.1.4.50
eth2 16.18.10.1
eth4 16.18.223.1
eth7 16.18.228.1
eth2.2 16.18.45.1

Notice that eth2.2 is a vlan resident on eth2. It shows up under "Virtual cluster interfaces" but theres only one instance of eth 2 under "Required interfaces". I believe that HA is considering eth2 as a single interface instead of two. Hence the "4 active 5 required" message.

[kaldek]

Originally Posted by jmcgrady

Notice that eth2.2 is a vlan resident on eth2. It shows up under "Virtual cluster interfaces" but theres only one instance of eth 2 under "Required interfaces". I believe that HA is considering eth2 as a single interface instead of two. Hence the "4 active 5 required" message.

The output looks normal (and fine) to me. From memory, what I'd say ClusterXL is doing is monitoring the link state of the physical "eth2" interface, whilst at the same time also performing the CCP (UDP 8116) checks and VLAN connectivity checks on eth2.2. Because eth2.2 is a VLAN check only, it prints them on the same line.

Note that if you had "eth2.3" and "eth2.4", etc, they would not appear in the required interfaces list, because as I mentioned in my previous post it only monitors the first VLAN (and it considers if one VLAN is working then they all must be).


Honestly I think your problem is something to do with the VLAN interface not considering itself "up". A good way to test this is to edit the /$FWDIR/conf/discntd.if file and add "eth2.2" to it. If after restarting it does not complain, then you have found your problem. Of course, having said all that I could be wrong! I'd need to bring up my VMWare Cluster test and twiddle with it to see if I can reproduce your symptoms.

[jmcgrady]

My issue turned out to be a typo in the subnet mask of one firewall's interface definition. Once corrected it came up fine.