New Member

Solved

Fortigate HA CLI Configuration parameters question.

Forum|Forum|11 years ago
May 7, 2015
6 replies
13257 views

We have Active/Passive with Virtual Clusters setup. With default HA configuration, the "link-failed-signal" is disabled. From some doc, it says the option is to enable/disable signaling to internal hosts when failover happens for fast switchover. So it sounds good but why it is disabled by default? Should I manually enable it?

Please advise.

Best answer by Christopher_McMullan

I don't think you can have them operate in tandem; they are meant to replace each other. See below. This is from two sections in our FortiOS Handbook for OS 5.2:

[page 1217]

Disabling gratuitous ARP packets after a failover

You can use the following command to turn off sending gratuitous ARP packets after a failover:

config system ha set gratuitous-arps disable end

Sending gratuitous ARP packets is turned on by default.

In most cases you would want to send gratuitous ARP packets because its a reliable way for the cluster to notify the network to send traffic to the new primary unit. However, in some cases, sending gratuitous ARP packets may be less optimal. For example, if you have a cluster of FortiGate units in Transparent mode, after a failover the new primary unit will send gratuitous ARP packets to all of the addresses in its Forwarding Database (FDB). If the FDB has a large number of addresses it may take extra time to send all the packets and the sudden burst of traffic could disrupt the network.

If you choose to disable sending gratuitous ARP packets you must first enable the link-failed-signal setting. The cluster must have some way of informing attached network devices that a failover has occurred.

For more information about the link-failed-signal setting, see 'Updating MAC forwarding tables when a link failover occurs' on page 1238.

[page 1238]

Updating MAC forwarding tables when a link failover occurs

When a FortiGate HA cluster is operating and a monitored interface fails on the primary unit, the primary unit usually becomes a subordinate unit and another cluster unit becomes the primary unit. After a link failover, the new primary unit sends gratuitous ARP packets to refresh the MAC forwarding tables (also called arp tables) of the switches connected to the cluster. This is normal link failover operation.

Even when gratuitous ARP packets are sent, some switches may not be able to detect that the primary unit has become a subordinate unit and will keep sending packets to the former primary unit. This can occur if the switch does not detect the failure and does not clear its MAC forwarding table.

You have another option available to make sure the switch detects the failover and clears its MAC forwarding tables. You can use the following command to cause a cluster unit with a monitored interface link failure to briefly shut down all of its interfaces (except the heartbeat interfaces) after the failover occurs:

config system ha set link-failed-signal enable end

Usually this means each interface of the former primary unit is shut down for about a second. When this happens the switch should be able to detect this failure and clear its MAC forwarding tables of the MAC addresses of the former primary unit and pickup the MAC addresses of the new primary unit. Each interface will shut down for a second but the entire process usually takes a few seconds. The more interfaces the FortiGate unit has, the longer it will take.

Normally, the new primary unit also sends gratuitous ARP packets that also help the switch update its MAC forwarding tables to connect to the new primary unit. If link-failed-signal is enabled, sending gratuitous ARP packets is optional and can be disabled if you don‘t need it or if its causing problems. See 'Disabling gratuitous ARP packets after a failover' on page 1217.

syuAuthor

New Member

Anyone has more detailed manual for this?

emnoc

New Member

i never used that that feature, my understanding is if you can't use gartuitous arps or the hosts don't like it, than you disable it and enable this feature.

And yes it's disable by default.

set arps 5 set arps-interval 8 set session-pickup enable set session-pickup-delay disable set link-failed-signal disable

syuAuthor

New Member

Okey. Thanks. That is kinda make sense. However will there be any simple way I know if my internal devices/hosts have issue with G-ARP?

Christopher_McMullan

Staff

In the event of an HA failover, the G-ARP message should primarily update the bridge tables on the switches facing the cluster, so that, for instance, the virtual MAC for port1 would be associated with the switchport facing the slave instead of the master's port1. The switch would want to have to do something else with the message in order for it to be adversely impacted, just speaking anecdotally.

Actual endpoint nodes shouldn't notice any impact, AFAIK. From their perspective, the access port facing them has not changed. The G-ARP did not change the MAC address itself. There would be nothing to change from the endpoint's perspective.

syuAuthor

New Member

Christopher McMullan_FTNT wrote:
In the event of an HA failover, the G-ARP message should primarily update the bridge tables on the switches facing the cluster, so that, for instance, the virtual MAC for port1 would be associated with the switchport facing the slave instead of the master's port1. The switch would want to have to do something else with the message in order for it to be adversely impacted, just speaking anecdotally.

Actual endpoint nodes shouldn't notice any impact, AFAIK. From their perspective, the access port facing them has not changed. The G-ARP did not change the MAC address itself. There would be nothing to change from the endpoint's perspective.

Agreed. But there are times hosts/servers are directly connected to the FG pair. I guess for that scenario, have that option turned on? Can I have both the G-ARP and link-failed-signal enabled at the same time?

Christopher_McMullanAnswer

Staff

I don't think you can have them operate in tandem; they are meant to replace each other. See below. This is from two sections in our FortiOS Handbook for OS 5.2:

[page 1217]

Disabling gratuitous ARP packets after a failover

You can use the following command to turn off sending gratuitous ARP packets after a failover:

config system ha set gratuitous-arps disable end

Sending gratuitous ARP packets is turned on by default.

In most cases you would want to send gratuitous ARP packets because its a reliable way for the cluster to notify the network to send traffic to the new primary unit. However, in some cases, sending gratuitous ARP packets may be less optimal. For example, if you have a cluster of FortiGate units in Transparent mode, after a failover the new primary unit will send gratuitous ARP packets to all of the addresses in its Forwarding Database (FDB). If the FDB has a large number of addresses it may take extra time to send all the packets and the sudden burst of traffic could disrupt the network.

If you choose to disable sending gratuitous ARP packets you must first enable the link-failed-signal setting. The cluster must have some way of informing attached network devices that a failover has occurred.

For more information about the link-failed-signal setting, see 'Updating MAC forwarding tables when a link failover occurs' on page 1238.

[page 1238]

Updating MAC forwarding tables when a link failover occurs

When a FortiGate HA cluster is operating and a monitored interface fails on the primary unit, the primary unit usually becomes a subordinate unit and another cluster unit becomes the primary unit. After a link failover, the new primary unit sends gratuitous ARP packets to refresh the MAC forwarding tables (also called arp tables) of the switches connected to the cluster. This is normal link failover operation.

Even when gratuitous ARP packets are sent, some switches may not be able to detect that the primary unit has become a subordinate unit and will keep sending packets to the former primary unit. This can occur if the switch does not detect the failure and does not clear its MAC forwarding table.

You have another option available to make sure the switch detects the failover and clears its MAC forwarding tables. You can use the following command to cause a cluster unit with a monitored interface link failure to briefly shut down all of its interfaces (except the heartbeat interfaces) after the failover occurs:

config system ha set link-failed-signal enable end

Usually this means each interface of the former primary unit is shut down for about a second. When this happens the switch should be able to detect this failure and clear its MAC forwarding tables of the MAC addresses of the former primary unit and pickup the MAC addresses of the new primary unit. Each interface will shut down for a second but the entire process usually takes a few seconds. The more interfaces the FortiGate unit has, the longer it will take.

Normally, the new primary unit also sends gratuitous ARP packets that also help the switch update its MAC forwarding tables to connect to the new primary unit. If link-failed-signal is enabled, sending gratuitous ARP packets is optional and can be disabled if you don‘t need it or if its causing problems. See 'Disabling gratuitous ARP packets after a failover' on page 1217.

Katoomba

Explorer

Can we please rename this article to "HA link-failed-signal and gratuitous ARP (GARP)"? This would make it so much easier to search on.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded