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

HA Port Monitoring

Hi all, We are running a ha active/active cluster. Port monitoring is enabled for the WAN links and internal links. How does it monitor, I assume it only monitors the link state ? What is the best way to monitor the protocol state ? (ping test to a device out each interface ?, if so whats is the best way to set this up) thanks greg
7 REPLIES 7
ggntt
Contributor

Just wondering if anyone out there has any ideas on how best to do this ?

norouzi
Contributor

Port monitor just look at "link state" . If link goes down, the master device will be replace with the slave one.

There are some cli commands that can help you .Please look at cli refrence.

 

config system ha

   set pingserver-failover-threshold <threshold_integer>    set pingserver-flip-timeout <timeout_integer>    set pingserver-monitor-interface <interface_names>

end

 

and ping server is here:

 

config router gwdetect     edit <interface_name>          set server <servername1_string>          set source-ip <ipv4_addr>          set protocol {ping |tcp-echo | udp-echo}          set interval <seconds_int>          set failtime <attempts_int>          set ha-priority <priority_int> end

You can change ha-priority.

 

ede_pfau
SuperUser
SuperUser

Not really - if you can configure a ping server then the FGT does NOT act on link status alone but on ping replies (host alive) as well! Link status is just that the interface reports that a device is connected (the LED is lit).

HA port monitoring is not as sophisticated as link health monitoring in load balancing but IMHO it doesn't need to. Either the HA backup unit is present and running or not. Which protocol would you like to test anyways, I mean, against a HA unit?

Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
Carl_Wallmark
Valued Contributor

In 5.2 dead gateway detection is replaced with "Link-monitor":

 

config system link-monitor

FCNSA, FCNSP
---
FortiGate 200A/B, 224B, 110C, 100A/D, 80C/CM/Voice, 60B/C/CX/D, 50B, 40C, 30B
FortiAnalyzer 100B, 100C
FortiMail 100,100C
FortiManager VM
FortiAuthenticator VM
FortiToken
FortiAP 220B/221B, 11C

FCNSA, FCNSP---FortiGate 200A/B, 224B, 110C, 100A/D, 80C/CM/Voice, 60B/C/CX/D, 50B, 40C, 30BFortiAnalyzer 100B, 100CFortiMail 100,100CFortiManager VMFortiAuthenticator VMFortiTokenFortiAP 220B/221B, 11C
Fahad
New Contributor III

if you are looking to depend on ping then you wont depend on interface state its more over link availability, while Port monitoring is for the port state (up/down)

 

..

FCSNP 5, JNCIS-FW,JNCIA-SSL ,MCSE, ITIL.

FCSNP 5, JNCIS-FW,JNCIA-SSL ,MCSE, ITIL.
ggntt
Contributor

Hi all

 

We have a couple of internal networks (subnets) on the HA cluster. (internal ports configured on each of the FG's)

Each will have their own connection to a switch.

Naturally the connections on the slave FG will be in standby.

But should the upstream connection to the switch that connects one of the internal networks on the master fail, the FG cluster will not know about it.

As far as its concerned the switch / link state is up and there is no need to failover.

But comms would be lost unless we can configure each port on the FW to monitor something upstream. (e.g ping a server)

 

What do you think ?

 

g

ede_pfau
SuperUser
SuperUser

Just go ahead and do it: configure a ping server for the WAN side, one ping server for the internal side and link monitoring (using these ping servers!) for the HA.

 

The inter-HA link should be a direct connection by all means! Do not run that across a switch. Use a redundant HA link if possible, with the second connection along a different path. I even use colored cables for the HA link so that they won't get pulled inadvertedly. Reason: if the HA link fails both members recon they are solitary and both assume the master role - with the same IP and MAC addresses on the same LAN ('cluster split'). This will cause a lot of trouble.

Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors