Comware

Hello!

I am in process of configuring MLAG with two FortiGate acting as Active/Passive and two HP FlexFabric connected via IRF.
I want to check if the topology showed in the attached picture works fine with respect to IRF.

Thanks for your input in this.

Hi, IF the IRF stack (which is a single logical entity from the standpoint of each Firewall appliance) is going to see - let me use this figurative terminology - both the Firewall appliances as a single logical entity (so the Firewalls Cluster is exactly like the IRF Stack and I don't believe this is what the IRF will see) then "Yes, you could create just two BAGGs, one per side" BUT if the answer is "No, the IRF will not see a single logical entity but two separate ones (Active and Passive appliances)" THEN "No, you can't setup just two BAGGs, one per side" and you can't also proceed with the proposed design because BAGGs sourcing from the IRF must co-terminate into a logical entity (a single Firewall Appliance).

You can create a BAGG sourcing from the Active Firewall appliance with its member links terminating into IRF Member 1 and IRF Member 2 and, concurrently, you can also create the another one BAGG sourcing from the Passive Firewall appliance with its member links terminating into IRF Member 1 and IRF Member 2 (basically links sourcing from each Firewall appliance are distributed into both IRF Members and are sourced from each Firewall appliance, not from both Firewall appliances as in the case of real Multi-Chassis LAGs), on IRF side you are going to create two corresponding BAGGs (one terminating its links into the Active Firewall appliance and the other one into the Passive Firewall appliance).

As written, the only exception shows up IF the Firewalls Cluster is going to act as a single logical entity from the upstream/downstream peers standpoint (from the IRF standpoint, in your case); generally, the presence of a feature like the Multi-Chassis LAG (MC-LAG) capability on a Stack shows that you're dealing with a Cluster which is capable of acting as a single logical entity and so BAGGs (MC-LAGs) can use links sourced by any of its members (but the termination should also be a single logical entity, the IRF in this case). Verify that.

Thanks Parnassus.
Your reply is always full of information.
The FortiGate Active/Passive doesn't look like stack as the Master and slave kind of thing. The slave with work as subordinate and take control when master is not there.
This was one of the blog I was following for my design.
https://www.madari.co.il/2016/08/hpe-flexfabric-irf-with-fortigate-ha.html

This is a technical document I found today which is pointing to the same design you mentioned above.
https://community.fortinet.com/t5/FortiGate/Technical-Tip-High-Availability-basic-deployment-design/ta-p/196942

Original Message:
Sent: Nov 25, 2022 05:57 AM
From: Davide Poletto
Subject: HP MLAG with FortiGate

Hi, IF the IRF stack (which is a single logical entity from the standpoint of each Firewall appliance) is going to see - let me use this figurative terminology - both the Firewall appliances as a single logical entity (so the Firewalls Cluster is exactly like the IRF Stack and I don't believe this is what the IRF will see) then "Yes, you could create just two BAGGs, one per side" BUT if the answer is "No, the IRF will not see a single logical entity but two separate ones (Active and Passive appliances)" THEN "No, you can't setup just two BAGGs, one per side" and you can't also proceed with the proposed design because BAGGs sourcing from the IRF must co-terminate into a logical entity (a single Firewall Appliance).

You can create a BAGG sourcing from the Active Firewall appliance with its member links terminating into IRF Member 1 and IRF Member 2 and, concurrently, you can also create the another one BAGG sourcing from the Passive Firewall appliance with its member links terminating into IRF Member 1 and IRF Member 2 (basically links sourcing from each Firewall appliance are distributed into both IRF Members and are sourced from each Firewall appliance, not from both Firewall appliances as in the case of real Multi-Chassis LAGs), on IRF side you are going to create two corresponding BAGGs (one terminating its links into the Active Firewall appliance and the other one into the Passive Firewall appliance).

As written, the only exception shows up IF the Firewalls Cluster is going to act as a single logical entity from the upstream/downstream peers standpoint (from the IRF standpoint, in your case); generally, the presence of a feature like the Multi-Chassis LAG (MC-LAG) capability on a Stack shows that you're dealing with a Cluster which is capable of acting as a single logical entity and so BAGGs (MC-LAGs) can use links sourced by any of its members (but the termination should also be a single logical entity, the IRF in this case). Verify that.

Hi, in my opinion you are forced to plan a setup as I described above because - at best - the HA Cluster of two FortiGate firewalls (no matter if they are deployed in Active/Passive or Active/Active mode) could not be considered as a "Single Logical Entity" from the connected peers' standpoint.

Indeed I'm pretty sure the two FortiGate firewalls - deployed as an HA Cluster entity - aren't able to provide any Multi-Chassis LAG capability to downstream/upstream peers but only standard (in-chassis) LAG (where each chassis is responsible of its own LAGs and it's not able to "virtualize" them against possible peers) .

See, as example here and note how the two FortiGate firewalls in the example are connected to a series of downstream FortiSwitch Clusters (each one acting instead as a Virtual Switch), Clusters that - exactly like the IRF stack - are capable to provide (and to support) Multi-Chassis LAGs to downstream peers and, in the case of the example, more importantly to upstream FortiGate firewalls deployed as an HA Active/Passive Cluster.

Also there is a question of WHY having two unit Fortigate HA cluster configured?

Is it because of two independent separate ISP routes to internet (exactly what I have), in which case ISP could/need configure BGP to be used on Fortigate HA cluster

------------------------------
spgsitsupport
------------------------------

Original Message:
Sent: Nov 26, 2022 07:54 AM
From: Davide Poletto
Subject: HP MLAG with FortiGate

Hi, in my opinion you are forced to plan a setup as I described above because - at best - the HA Cluster of two FortiGate firewalls (no matter if they are deployed in Active/Passive or Active/Active mode) could not be considered as a "Single Logical Entity" from the connected peers' standpoint.

Indeed I'm pretty sure the two FortiGate firewalls - deployed as an HA Cluster entity - aren't able to provide any Multi-Chassis LAG capability to downstream/upstream peers but only standard (in-chassis) LAG (where each chassis is responsible of its own LAGs and it's not able to "virtualize" them against possible peers) .

See, as example here and note how the two FortiGate firewalls in the example are connected to a series of downstream FortiSwitch Clusters (each one acting instead as a Virtual Switch), Clusters that - exactly like the IRF stack - are capable to provide (and to support) Multi-Chassis LAGs to downstream peers and, in the case of the example, more importantly to upstream FortiGate firewalls deployed as an HA Active/Passive Cluster.

Original Message:
Sent: 11/28/2022 4:50:00 AM
From: spgsitsupport
Subject: RE: HP MLAG with FortiGate

Also there is a question of WHY having two unit Fortigate HA cluster configured?

Is it because of two independent separate ISP routes to internet (exactly what I have), in which case ISP could/need configure BGP to be used on Fortigate HA cluster

------------------------------
spgsitsupport
------------------------------

Original Message:
Sent: Nov 26, 2022 07:54 AM
From: Davide Poletto
Subject: HP MLAG with FortiGate

Hi, in my opinion you are forced to plan a setup as I described above because - at best - the HA Cluster of two FortiGate firewalls (no matter if they are deployed in Active/Passive or Active/Active mode) could not be considered as a "Single Logical Entity" from the connected peers' standpoint.

Indeed I'm pretty sure the two FortiGate firewalls - deployed as an HA Cluster entity - aren't able to provide any Multi-Chassis LAG capability to downstream/upstream peers but only standard (in-chassis) LAG (where each chassis is responsible of its own LAGs and it's not able to "virtualize" them against possible peers) .

See, as example here and note how the two FortiGate firewalls in the example are connected to a series of downstream FortiSwitch Clusters (each one acting instead as a Virtual Switch), Clusters that - exactly like the IRF stack - are capable to provide (and to support) Multi-Chassis LAGs to downstream peers and, in the case of the example, more importantly to upstream FortiGate firewalls deployed as an HA Active/Passive Cluster.

A single WAN is the most fragile part of the setup. So having HA cluster is "nice" but only semi-solution in such case (but that is my own opinion)

------------------------------
spgsitsupport
------------------------------

For redundancy  purpose
Original Message:
Sent: Nov 28, 2022 04:49 AM
From: sebastian cerazy
Subject: HP MLAG with FortiGate

Also there is a question of WHY having two unit Fortigate HA cluster configured?

Is it because of two independent separate ISP routes to internet (exactly what I have), in which case ISP could/need configure BGP to be used on Fortigate HA cluster

------------------------------
spgsitsupport

Original Message:
Sent: Nov 26, 2022 07:54 AM
From: Davide Poletto
Subject: HP MLAG with FortiGate

Hi, in my opinion you are forced to plan a setup as I described above because - at best - the HA Cluster of two FortiGate firewalls (no matter if they are deployed in Active/Passive or Active/Active mode) could not be considered as a "Single Logical Entity" from the connected peers' standpoint.

Indeed I'm pretty sure the two FortiGate firewalls - deployed as an HA Cluster entity - aren't able to provide any Multi-Chassis LAG capability to downstream/upstream peers but only standard (in-chassis) LAG (where each chassis is responsible of its own LAGs and it's not able to "virtualize" them against possible peers) .

See, as example here and note how the two FortiGate firewalls in the example are connected to a series of downstream FortiSwitch Clusters (each one acting instead as a Virtual Switch), Clusters that - exactly like the IRF stack - are capable to provide (and to support) Multi-Chassis LAGs to downstream peers and, in the case of the example, more importantly to upstream FortiGate firewalls deployed as an HA Active/Passive Cluster.

Thanks
Original Message:
Sent: Nov 26, 2022 07:54 AM
From: Davide Poletto
Subject: HP MLAG with FortiGate

Hi, in my opinion you are forced to plan a setup as I described above because - at best - the HA Cluster of two FortiGate firewalls (no matter if they are deployed in Active/Passive or Active/Active mode) could not be considered as a "Single Logical Entity" from the connected peers' standpoint.

Indeed I'm pretty sure the two FortiGate firewalls - deployed as an HA Cluster entity - aren't able to provide any Multi-Chassis LAG capability to downstream/upstream peers but only standard (in-chassis) LAG (where each chassis is responsible of its own LAGs and it's not able to "virtualize" them against possible peers) .

See, as example here and note how the two FortiGate firewalls in the example are connected to a series of downstream FortiSwitch Clusters (each one acting instead as a Virtual Switch), Clusters that - exactly like the IRF stack - are capable to provide (and to support) Multi-Chassis LAGs to downstream peers and, in the case of the example, more importantly to upstream FortiGate firewalls deployed as an HA Active/Passive Cluster.