Question about ClusterXL on a "trunk" port (cphaprob -a if command output)

[Jake_Stafeyev]

When I have an ClusterXL interface with VLANs on it, the ClusterXL feature examines only the status of the first and the last VLAN.

A. Is it correct?

B. Why?

C. If I had status change for the first VLAN only (observed on SmartViewTracker), is it enough to change the entire ClusterXL untis status (Main / Secondary)?

D. If I had status change for the first VLAN only (observed on SmartViewTracker), should the last VLAN status change appear in the SmartView Tracker as well?

[Maarten_Sjouw]

A. Yes

B. Who knows, VRRP does not have this limitation, but it can also be turned on to monitor all VLAN's

C. Any interface, VLAN or physical, failing should trigger a failover. In VRRP you define the delta and the priority of each member and as soon as 1 interface goes down, VLAN or physical, it will lower the priority with it's delta, when this causes the priority to become lower than the other member it will fail over. ClusterXL will just put the member with a failing VLAN or physical interface, into a problem state, the member not being in problem state will then become active.

D. I can have someone mess up the switchport the FW is connected to and accidentally delete the VLAN from the trunk, what does the last VLAN then have to do with the first? Each and every interface, VLAN or physical, should be handled as a separate point to be checked for health of the cluster.

Specially when you're running VSX systems with big (10Gb) trunk interfaces with 20 or more VLAN's on it you really need to be sure that all those VLAN's are alive. The first 3 VLANs might be in use on VS1 the next 5 on VS2 etc. Now when the 6th VLAN fails for whatever reason, I will not be noticed unless I change the setting fwha_monitor_all_vlan=1 (fwkern.conf parameter) that all VLAN's need to be monitored.

[_Val_]

B: because CCP is noisy, and with lots on VLANs on the trunk you will have too many probing packets going in and out. Monitoring the highest and lowest VLANs is a reasonable and economical way to make sure physical trunk is okay. In case you need to do that on EVERY VLAN, there is a kernel parameter you could change. NOT recommended.