ip-reachability behaviour

[guesstimation]

Hello,

I wanted to check what is behaviour of ip-reachability detection. Is monitoring tied to particular next-hop GW when used with static-route?

I want to monitor particular address in data center[10.1.1.1 ]from branch office with ping and failover static route from main line to backup, if monitored IP becomes unreachable on primary line.
Let's say route through GW1 fails, monitored IP becomes unreachable. Route fails over. But what happens when it starts reaching monitored IP 10.1.1.1 via functional GW2? Does it have next hop GW awareness and it understands that particular GW is no longer working? Or will it declare that monitored-ip is now reachable as it can reach it over GW2 and try to bring back route with higher priority?

Monitored IP 10.1.1.1
set static-route 10.0.0.0/8 nexthop gateway address GW01 monitored-ip 10.1.1.1 on
set static-route 10.0.0.0/8 nexthop gateway address GW01 priority 1 on

set static-route 10.0.0.0/8 nexthop gateway address GW02  on
set static-route 10.0.0.0/8 nexthop gateway address GW02 priority 5 on

[RS_Daniel]

Hello,

I've not tested that scenario, i understand the route will failover constantly because host 10.1.1.1 will become reachable/unreachble all the time.

You can try adding a specific route for host 10.1.1.1 through GW1 without monitoring, that route will make the ping to 10.1.1.1 will always use firs link as far as the physical/logical interface is up. Another option would be use two monitoring IP's adding the IP of GW1 to the route and use fail condition "Fail Any". HTH.

Regards

[emonteagudo]

Same behavior , try setting monitored-ip on reachability option to off , it work's for me 


Regards

[emonteagudo]

Update – IP Reachability issue resolved by adding /32 static routes

Hi everyone,

I wanted to share an update regarding this behavior, as we recently experienced the same issue in two different Check Point clusters (Quantum Force 3920 and 3950) running SD-WAN.

During troubleshooting, we observed that when the primary ISP became unreachable, RouteD removed the corresponding default route. However, the IP Reachability probes started reaching the monitoring targets through the secondary ISP, causing the primary route to be restored repeatedly and resulting in continuous route flapping.

We resolved the issue by adding dedicated /32 static routes for each monitoring target, forcing the probes to use only the ISP they were intended to monitor.

For example:

set static-route 1.1.1.1/32 nexthop gateway address <PRIMARY_ISP_GATEWAY> on
set static-route 9.9.9.9/32 nexthop gateway address <PRIMARY_ISP_GATEWAY> on

After implementing these routes, we successfully tested the configuration during an actual ISP outage. IP Reachability behaved correctly, the secondary ISP remained stable, and the route flapping stopped.

In parallel, we have an open support case with Check Point TAC requesting a technical explanation and RCA, particularly because we have other customer environments using SD-WAN and Smart-1 Cloud where we have never needed these dedicated /32 routes.

Interestingly, the two affected clusters are managed by a physical/on-premises Management Server, whereas our other SD-WAN deployments are managed through Smart-1 Cloud.

We are asking TAC to clarify whether this is expected RouteD/IP Reachability behavior, a configuration requirement, or potentially related to a software/version difference, since we have only encountered this issue on certain gateways.

I will share any relevant findings once we receive a technical explanation from Check Point.

Hope this helps anyone experiencing similar IP Reachability or default-route flapping issues.

Regards

[AmirArama]

Please see: https://sc1.checkpoint.com/documents/SD-WAN-with-Smart1/Content/Topics-SD-WAN-Smart-1/4_Prepare_Secu...

The behavior is expected.

think of it that way:

Let's say you have two default gateway routes with different priorities with IP reachability attached.

the route which leads to those targets are the current default route, since you don't have a specific route.

so let's say you monitor 9.9.9.9 and 1.1.1.1, the main default route is active, suddenly those targets are not reachable through the main default route, routeD removes the main default route from kernel, and then the secondary becomes the active default route, the monitored targets then become reachable again, which triggers the reactivation of the main default route which depends on reachability of these targets.

in other words , in GAIA, there is no mechanism to bind route monitoring to the specific default route / ISP, only static routes can do that.