Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
laf
New Contributor II

system link-monitor

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!

The most expensive and scarce resource for man is time, paradoxically, it' s infinite.

The most expensive and scarce resource for man is time, paradoxically, it' s infinite.
3 REPLIES 3
ede_pfau
Esteemed Contributor III

hi,

 

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


Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
laf
New Contributor II

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!

The most expensive and scarce resource for man is time, paradoxically, it' s infinite.

The most expensive and scarce resource for man is time, paradoxically, it' s infinite.
ede_pfau
Esteemed Contributor III

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.


Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
Labels
Top Kudoed Authors