- Products
- Learn
- Local User Groups
- Partners
- More
Check Point Jump-Start Online Training
Now Available on CheckMates for Beginners!
Why do Hackers Love IoT Devices so Much?
Join our TechTalk on Aug 17, at 5PM CET | 11AM EST
Welcome to Maestro Masters!
Talk to Masters, Engage with Masters, Be a Maestro Master!
ZTNA Buyer’s Guide
Zero Trust essentials for your most valuable assets
The SMB Cyber Master
Boost your knowledge on Quantum Spark SMB gateways!
As YOU DESERVE THE BEST SECURITY
Upgrade to our latest GA Jumbo
CheckFlix!
All Videos In One Space
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?
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.
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.
About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY