FortiGate firewall clusters group-id

Giuliano — Sat, 03 Jul 2010 15:53:31 +0000

A newly installed FortiGate cluster (a simple two node HA active-passive setup) and some packet loss issues…
Ping from the LAN side to the Internet (or from the firewall itself) resulted in about 20% packet loss, while the other way around (WAN to firewall’s main public IP) didn’t work at all.

I used the following command to check my MAC addresses:

FORTIGATE-PRI # diagnose hardware deviceinfo nic wan1
[..]
Current_HWaddr 00:09:0f:09:00:08
Permanent_HWaddr 00:09:0f:d1:be:ef
[..]

Then resorted to the “show mac” switches facilites (some Cisco, some ProCurve) to know on which network ports that particular MAC lied… Only to discover that the cluster’s “logical” MAC address (00:09:0f:09:00:08) wasn’t really located where I expected it to be.
Well, FortiGate’s MAC addresses aren’t randomly generated. They have predictable values that depend on the firewall’s port number. The eight port (or wan1, in my case) will always have a virtual MAC as the one above. What will happen if you have two clusters (as we had) sitting on the same L2 network segment (on the same broadcast domain, that is)? You said MAC address conflict? You’re right.
The solution is simple, use the group-id directive to tweak the logical MAC address, i.e.:

config system ha
set group-id 10
end

Changes the second right-most bytes of the MAC, from 00 to 0a:

before 00:09:0f:09:00:08
after 00:09:0f:09:0a:08

Point is that the “FortiOS High Availablity Handbook” explains the case very thoroughly! See page 192, paragraph “Diagnosing packet loss with two FortiGate HA clusters in the same broadcast domain”. We’re so used to discardable product documentation that sometimes we don’t even try to look for clues where they should normally reside.
Instead of troubleshooting, this time, I should really have Read The (unexpectedly) Fine Manual…

FortiGate High Availability interface addressing

Giuliano — Thu, 07 Jan 2010 15:01:51 +0000

When setting up High Availability on FortiGate, one thing struck me as a bit unusual. Differently from other firewall clustering solutions (correct me if I’m wrong), FortiGate devices don’t force you to assign both physical and logical IP addresses on interfaces. You are supposed to configure logical IP addresses only. This implies that you can’t directly access a specific node/firewall in your cluster. You have to SSH into the Master unit and, from there, log into the Subordinate one(s). Here are the relevant CLI commans:

FW-NODE-A # get system ha status
Model: 100
Mode: a-p
Group: 0
Debug: 0
ses_pickup: disable
Master:129 FW-NODE-A FG100C3000000000 0
Slave :128 FW-NODE-B FG100C3000000001 1
number of vcluster: 1
vcluster 1: work 169.254.0.1
Master:0 FG100C3000000000
Slave :1 FG100C3000000001

FW-NODE-A # execute ha manage ?
please input peer box index.
<1> Subsidary unit FG100C3000000001

FW-NODE-A # execute ha manage 1

FW-NODE-B $

I wonder what would happen if the Master unit were to hang. I mean: stuck itself in a state where the failover mechanism doesn’t work and neither does SSH/HTTPS access. How could you remotely force a failover to another node? In such a scenario, is a physical power cycle of the master unit the only option?

108.bz » High Availability

FortiGate firewall clusters group-id

FortiGate High Availability interface addressing