Thursday, June 27, 2013

Check Point Gaia: What Is The "Ping" Check Box Under IPv4 Static Routes?

Well, this is an interesting 'feature'.  Actually, it caused me and another engineer a little bit of headache, but this check box in static routes for 'ping' is interesting.  We had two check point 4800s in a cluster.  One of the boxes could ping while the other box would not.  In Gaia, there is this check box under the static routes.  You select the box for a 'yes' and uncheck the box for a 'no'.  What does this do?  If you have this checked, it will ping the next hop.  IF it misses one ping, it will take the route out completely.  Here is what Im talking about:
See that 'ping' column?  On the secondary box that would not ping out to, we had the default route ping check box checked, meaning yes.  Apparently, it missed a ping (a time out) and took the default route out.  With no default route, it wouldnt ping anything on the Internet.  So, if you dont want this 'feature', make sure you turn ping off in the routing table.
With that said, I can see a really cool feature in this that is a lot like Cisco's object tracking.  With dual ISP, you can set one route a higher priority than the second ISP link.  When the first ISP link fails, causing the ping to fail, causing the route to be taken out, then the Internet traffic defaults to the second route.  This is much like object tracking, and I really like object tracking.  You dont need BGP, OSPF, etc.  Its all done with static routing, with some monitoring in place.  I like it.


  1. Hello, one question.
    In the example you gave, on multiple ISP, the thing is. if all default outbound routes go to the LAN side of the ISP's routers. It will only fail if that router fails. So if the circuit fails(WAN side of that ISP router), but the Lan side responds...the route doesn't get cleaned.

    On cisco object tracking, you can specify which IP to track(so we could for example place an ip of the hop right in front of the router for example).

    Am I reasoning correctly?


    1. Hi Joao. Yes, you are correct. Object tracking is the better option, in my opinion. You can certainly go as far as you want to monitor (as far as hops go) with object-tracking. Notice in my examples below that I typically use or You know if the ISP goes down, it will never get to those IP addresses. The only problem is that if ever really does go down (the server), then object-tracking thinks it needs to move the route. So make sure you select a target that truely will define an ISP outage instead of a server (like in the example). Generally, two or three hops away from your firewall should do just fine.

  2. This PING setting caused a lot of issue to us as we were not sure what it does, you saved the day

  3. Can you please let me know, how to remove that check i.e "YES" . We have curently configured ClusterXL format. So GUI will not work in this case. Also we have tried to unload local policy, set manual default route from expert mode but still no go. As soon we push the policy and topology it disappeared. I check on the both the gateway configuration, found that set static-route default on is the explicitely. tried to off it but still no go. In the etc/routed.conf, I found in the default section showing as default route preferences 1 ping. This is what creates the problem I believe. Can you please suggest how can I get rid off it. PLEASE.

  4. I'm not sure I know the answer right off without looking at this. Contact TAC about this issue.

