CPUG: The Check Point User Group

Resources for the Check Point Community, by the Check Point Community.


First, I hope you're all well and staying safe.
Second, I want to give a "heads up" that you should see more activity here shortly, and maybe a few cosmetic changes.
I'll post more details to the "Announcements" forum soon, so be on the lookout. -E

 

Results 1 to 5 of 5

Thread: ClusterXL issues on Gaia

  1. #1
    Join Date
    2006-03-14
    Posts
    391
    Rep Power
    15

    Default ClusterXL issues on Gaia

    Has anyone setup working CPHA clusterXL on Gaia R75.40?

    I am setting up a CPHA clusterXL in a lab using brand new 4407 appliances using Smart appliance. I am familiar with cluster setup with previous versions, but this time with new setup it doesn't seem to work. When both gateways are up, cphaprob state output looks fine. But when I remove one interface from active gw, it remains active with attentions message. Please find the various case scenarios output in the attached file. I do not have any end devices on any of the vlans except for smart appliance.


    My vendor say's I should always test cphaprob with some PC's in each segment. This advice seems to be working. However this requirement difficult to enforce since I can not afford to keep the PC's (end device) in transit segment. Can someone confirm this for me.
    Last edited by avilT; 2013-04-16 at 02:35.

  2. #2
    Join Date
    2006-03-14
    Posts
    391
    Rep Power
    15

    Default Re: ClusterXL issues on Gaia

    Please find attached the various case scenarios, with PC in each segment, the clusterXL seems to be fine.
    Attached Files Attached Files
    Last edited by avilT; 2013-04-16 at 02:35.

  3. #3
    Join Date
    2007-06-04
    Posts
    3,314
    Rep Power
    18

    Default Re: ClusterXL issues on Gaia

    Came across this before myself when didn't get a failover that expected, and saw similar behaviour to what you see.

    The ClusterXL will attempt to ping other IP addresses in it's local subnet before marking as Active.

    If all you have in the Subnet is the two devices then when the other unit's interface is taken away then the Standby Unit has no response from anything on it's network. As such the ClusterXL will mark the interface as Down, even though is physically up.

    As such the Standby Unit see's itself has having the down interface, and the Active Unit see's itslef as having 1 interface down so both units have 1 interface down according to cpha output. Therefore the Active Unit won't drop into Standby as in no worse shape then the Standby Unit thus no point in failing over.

    Even in a transit segment there should be some devices in the same subnet as the Firewall, even if only another Firewall/Router/L3 Switch Interface. Just make sure that the devices in the network are pingable by the Cluster members.

  4. #4
    Join Date
    2006-03-14
    Posts
    391
    Rep Power
    15

    Default Re: ClusterXL issues on Gaia

    Thank You very much. So that means I should have at least one device in each segment which can respond to ping requests from the cluster members. This requirement is a bit strange specially if I am going for new segments, initially my segments will not have server's in that vlan.

    Is this behaviour specific to version R75.40? I have not faced this issue in R71.30? Is there anyway to disable this behaviour?

    In Nokia VRRP, the firewall could monitor the interface status thru non failed interfaces to make the accurate decisions.
    Last edited by avilT; 2013-04-16 at 03:47.

  5. #5
    Join Date
    2007-06-04
    Posts
    3,314
    Rep Power
    18

    Default Re: ClusterXL issues on Gaia

    Quote Originally Posted by avilT View Post
    Thank You very much. So that means I should have at least one device in each segment which can respond to ping requests from the cluster members. This requirement is a bit strange specially if I am going for new segments, initially my segments will not have server's in that vlan.

    Is this behaviour specific to version R75.40? I have not faced this issue in R71.30? Is there anyway to disable this behaviour?

    In Nokia VRRP, the firewall could monitor the interface status thru non failed interfaces to make the accurate decisions.
    As I understand it then isn't specific to R75.40 at all, simply how ClusterXL works! Found out when had an issue with a distributed cluster at two locations and the link between the two locations failed thus some segments couldn't see anything else so didn't come up. Was an R75.10 cluster. Don't know of anyway to disable other then say go Gaia and use VRRP, so not using Cluster XL to determine the Active/Standby Status of the units. ( Read carefully other threads about Gaia and VRRP before doing so )

    Nokia VRRP would send VRRP updates out of the Interfaces that were up relating to that interface, and then if it recieved a VRRP update from another unit that had a higher priority then itself then it would mark the interface as down, but only that interface.

    If it did not get a VRRP update from another unit then it would presume that it had the highest priority and thus become active, however only again for that interface.

    Monitored Circuit would simply look at the box it was configured on and say that if an interface that was being monitored failed then to change the VRRP priority by the priority delta configured on the interface on the box that was monitoring it.

    Take two Nokia VRRP boxes.

    4 interfaces, External, Internal, DMZ and Synch, with VRRP on External, Internal and DMZ. Use a difference of 5 between the VRRP prioroty and a Delta of 10 on the Monitored Circuit.

    Each Nokia is connected to Seperate Switches and the Switches connected together, so there are two External Switches, Nokia connected to 1 each and then the switches connected together.

    Under normal circumstances then will all be good and VRRP updates sent and recieved.

    Then take the cable from between the two external switches.

    The Internal, DMZ, Interfaces will continue to see each others VRRP updates. However the External Interfaces will both be sending out VRRP updates but not recieving any updates. Both boxes will therefore become Active in VRRP on the External Interface. The other interfaces won't become Active and failover as the interfaces on the unit do not drop, so the VRRP Priority Delta change does not occur as the Monitor Circuit configuration doesn't see an interface drop.

    Replace the Cable between the two External Switches and the VRRP updates are recieved and you get the correct Active/Standby occur.


    If the cable is pulled from the Nokia's External Interface then no VRRP updates go out on the Interface and so the VRRP on the Standby unit becomes Active as it has the highest priority.
    As the Interface drops then the Monitored Circuit changes the VRRP priority on the other interfaces on the box so that the VRRP updates now have a lower priority then the Standby Units vrrp updates. The Standby Unit then becomes active on it's other interfaces as the VRRP priority is now higher on it then the unit with the failed interface.

    When you put the cable back in then the VRRP priority on the box is changed by the Monitor Circuit configuration and so the priority is raised on the other interfaces. The second unit then becomes standby as it starts to get VRRP updates from the first unit on the External Interface, and it again has a lower priority on all interfaces then the first unit.

    VRRP however doesn't have anything to do with the Firewall Package status, hence why on VRRP boxes then the cphaprob stat comes back as Active / Active and the ClusterXL boxes come back as Active / Standby. VRRP is OS level, whereas the ClusterXL is dong at an Application level for the failover, as it was explained to me then the connectivity test is to try and get around going Active / Active on the box where the link between the two boxes fails as opposed to an interface.

    Going back to Cluster XL

    If there is nothing in the network at all other then the two units then it doesn't matter if the interface failure doesn't cause a failover as no real traffic on the network anyway. Once you have servers or desktop users or other routers etc then there is another device can reach so isn't an issue once you get real traffic through there.

Similar Threads

  1. CPHA Cluster Issues with R75.40 Gaia
    By avilT in forum Installing And Upgrading
    Replies: 9
    Last Post: 2013-11-25, 16:16
  2. Gaia - BGP configuration on unnumbered VTI with ClusterXL
    By vermaelen in forum R75.40 (GAiA)
    Replies: 0
    Last Post: 2012-07-30, 04:14
  3. OSPF R75.40 Gaia and ClusterXL active/passive and anti-spoofing
    By nolan.rumble in forum Dynamic Routing
    Replies: 0
    Last Post: 2012-07-02, 07:04
  4. GAiA: ClusterXL magic mac settings - no changes
    By varera in forum R75.40 (GAiA)
    Replies: 0
    Last Post: 2012-05-10, 04:47
  5. Desktop Security/Policy Server logon failure issues issues
    By Clon32 in forum SecureClient/SecuRemote
    Replies: 3
    Last Post: 2006-10-25, 06:32

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •