system link-monitor

[laf]

Hi guys,

I am bit rusty with Fortigate 5.2 and got a bit of a trouble with this feature.

I am trying to clear up any static route that uses port8 if the next-hop becomes unavailable.

Here's the config:

FG100D3G14824892 (root) # get router info routing-table all | grep 192.168. S 192.168.1.0/24 [10/0] via 172.16.3.50, port8 S 192.168.15.0/24 [10/0] via 172.16.3.50, port8 S 192.168.16.0/24 [10/0] via 172.16.3.50, port8 S 192.168.25.0/24 [10/0] via 172.16.3.50, port8

Then I add port8 link monitoring:

config system link-monitor edit "A_Polling" set srcintf "port8" set server "172.16.3.50" set source-ip 172.16.3.49 set update-cascade-interface disable next end

and then I read about enabling fail-detect on interface itself

config system interface edit "port8" set vdom "root" set ip 172.16.3.49 255.255.255.248 set allowaccess ping set fail-detect enable set fail-detect-option detectserver link-down set type physical set netflow-sampler both set snmp-index 13 next

End of this is that I see a message on GUI : Static route is removed. Route: (172.16.3.49->172.16.3.50 ping-down) and obviously a blank CLI output:

FG100D3G14824892 (root) # get router info routing-table all | grep 192.168.

What am I missing?

Thanks in advance!

[ede_pfau]

hi,

the obivous first: how do you determine that the ping target is alive? You've been pinging from the FGT's console?

[laf]

ede_pfau wrote:

hi,

the obivous first: how do you determine that the ping target is alive? You've been pinging from the FGT's console?

Config was right, it was just the IP that I was monitoring was dropping ICMP.

Here's the story: I assumed ICMP is allowed on the destination, configured link-monitor, it cleared my static routes and while having link-monitor configured I tried ping 172.16.3.50. It didn't work and I thought it's because of link-monitor configuration rather than the real issue.

Many thanks!

[ede_pfau]

Last time this happened to me I realized how difficult it is to name a server on the 'net which will always be responsive to ping. So here comes the second hint: configure a second ping target to raise your chances exponentially! You can do this in the CLI. In this case, having 2 independent servers down (of which you assume both will be responsive) at the same time will almost certainly signal a defective WAN line.