search

mylesagray / blog-comments

Comments for Blah, Cloud. Hugo blog
0 stars 0 forks source link

Fortigate High Availability – Active/Active – Part 2 – Implementation | Blah, Cloud #48

Open mylesagray opened 2 years ago

mylesagray commented 2 years ago

Written on 02/25/2018 12:35:21

URL: https://blah.cloud/infrastructure/fortigate-high-availability-activeactive-part-2-implementation/

mylesagray commented 2 years ago

Comment written by RD on 02/18/2014 05:48:12

Why are you running old firmware?

mylesagray commented 2 years ago

Comment written by Myles Gray on 02/19/2014 15:00:27

Hardly old firmware, it's 5.0.5, Patch 5.0.6 was only released recently (then pulled) then re-released, excuse my lack of confidence in it.

mylesagray commented 2 years ago

Comment written by ron.wilkerson@gmail.com on 04/21/2014 17:01:19

Thanks for the article.
Is it correct to presume that the config from the fw with the higher priority will get replicated to the fw with the less priority?

mylesagray commented 2 years ago

Comment written by Myles Gray on 04/21/2014 21:57:57

Correct Ron, the higher priority unit's config overwrites the lower priority unit.

mylesagray commented 2 years ago

Comment written by Cory Pechon on 07/09/2014 04:46:49

Thanks for the article. I'm sitting here with 2x 60d's in an HA pair. They each have an equal priority. However if I'm pinging the management IP for the cluster ("internally") and I go: workstation >> switch (single vlan) >> forti a and forti b >> and I pull the link on the master, I lose my connection. I thought active active would be able to accept / forward traffic on either device? If I pull the cluster interlink it fails over and starts responding / forwarding traffic.

mylesagray commented 2 years ago

Comment written by Myles Gray on 07/09/2014 07:47:23

Hi Cory,

HA is designed to run with complete failure - not so much link failure - it is expected that you would use 2x switches and have redundant links to the firewalls, either through stacked switches and 802.3ad aggregates or with separate switches and Fortigate's "Zone" features for grouping interfaces as a sort of switch.

That said however, you can use "Port Monitoring" in the HA section of the FG to enable dead link detection and enable failover based on a link-down event.

You should also check out remote-link failover so that you can enable failover based on whether a link not directly connected to the switch (e.g. link between the HA switch and the LAN) fails: http://docs-legacy.fortinet.com/fos50hlp/50/index.html#page/FortiOS%205.0%20Help/HA_failover.086.62.html

The reason it fails over when you disconnect the cluster interconnect (of which you really should have 2x) is because communication between the cluster units is lost resulting in each unit thinking the other has failed - however this could quickly turn ugly as you will end up with 2x devices having the same IP addresses on their interfaces and duplicate IPs are bad.

This condition is commonly known as split-brain where each unit thinks it's the master and serves as such.

Have a look at the HA section of the Best Practices guide for more info: http://docs.fortinet.com/uploaded/files/1954/Best_Practices_52.pdf

I think if you configure your port monitoring it will do what you want - ideally remote-link monitoring but I don't know how redundant or robust your backend is.