Active/Active HA 10G LACP LAN connection

[bcote]

Hi everyone,

proud new owner of a pair of 1500D that I am going to implement in the coming months. My current test setup is Active/Active HA with a single 1G port connected to the LAN side(to a Cisco 6509 VSS Core). The production environment(Active/Passive) currently has 2 x 10G port per firewall appliance to each Core. So example, FW1 to Core1(active) and FW1 to Core2(redundant). Same thing goes for FW2. My goal is to have redundant connections in a similar fashion with the Fortigates. I know it supports 802.3ad, but I want to make sure it is implemented correctly, especially as this will change all the rules and static routes currently being sent to a single port. 

I haven't been able to find good information(cookbook,tech docs,...) to truly determine the Best practices, so before I open a ticket with support, I thought checking with the forums would probably be better.

Is anyone currently running A/A HA with redundant LAN ports to their Core's or am I over-complicating it all?

Thanks for your input

Ben

[ede_pfau · Accepted solution]

Congrats for the 1500D! Fun to play with...

We've connected my customer's 1500D cluster cross-wise to a HPE switch stack, using 2x 2port LACP trunks. The stack acts just like one single switch, even for LACP trunks. The 2 lines in a LACP trunk terminate on 2 different chassis in the stack. This way, one switch could fail without forcing the FGT to fail over, just reducing bandwidth. And one FGT can fail without losing bandwidth.

But it does cost 4 10G ports to get this redundancy.

[hklb]

Hi

I think HA a-a is not necessary if your firewall is not undersized. It more complicated to troubleshoot and the performence is improve only for 20%..

You can create a LACP interface without any problem and it's works very well on 1k5D. I suggest to use ports on the same NP6 (like 33-34,35-36, 37-38, 39-40)..

Lucas

[emnoc]

A-A in a single vdom setup buys very little to nothing. If you had multi-vdom vcluster1 and vcluster2 and load-blance vdom that I see that as an advantage

As far as  LACP to a VSS cluster that would be best-practice and simple to deploy.

Ken

[ede_pfau · Accepted solution]

Congrats for the 1500D! Fun to play with...

We've connected my customer's 1500D cluster cross-wise to a HPE switch stack, using 2x 2port LACP trunks. The stack acts just like one single switch, even for LACP trunks. The 2 lines in a LACP trunk terminate on 2 different chassis in the stack. This way, one switch could fail without forcing the FGT to fail over, just reducing bandwidth. And one FGT can fail without losing bandwidth.

But it does cost 4 10G ports to get this redundancy.

[bcote]

Hi guys,

thanks a lot for all the replies. As far as the A/A vs A/P setup, I am still on the fence on that one. I understand that the increase in performance is more from the offloading of UTM services than actual throughput increase, but I was told it was a bit more then 20%. Of course, that all depends on the load and how many rules require heavy UTM security services activated I presume. I have a really good SE inside Fortinet that knows my environment and will be able to confirm if going A/A wouldn't be necessary for us. I do intend on building more VDOM's as we build out on Fortinet, but that is for the future. Current setup would run a single "root" vdom to keep things simple and grow from there. 

As for the LACP part, I am currently using 4 x 10G in my current setup, so once the switch over is completed, I would simply be reusing those same 10G interfaces which shouldn't cause any issue. So just to confirm what you said ede_pfau, it would look like this : 

FW1 port 39 --->Core-VSS --physical port Core1 te1/4/1

FW1 port 40 --->Core-VSS --physical port Core2 te2/4/1

FW2 port 39 --->Core-VSS --physical port Core1 te1/4/2

FW2 port 40 --->Core-VSS --physical port Core2 te2/4/2

Both being configured in LACP. I read somewhere(might of been older Fortinet gear/firmware) that some were having issues with LACP Active and had to put either the Core or the Fortinet as Passive for the connection to work. Or even going Static, which defeats the purpose of LACP. Is that still the case today? 

Thanks again for all the information 

Cheers,

Ben

[emnoc · Accepted solution]

You should have no problems, we run ACTIVE on all FGTs running a mix of 5.2.x and 5.4.x with zero issues to include  1500s. We are running VSS and vPCdomain in  6500s an NXOS gear btw.

ken

[bcote]

Hi Emnoc,

I was able to configure a LAG on the LAN side without any hiccups so far. Traffic is flowing nicely and it was much easier than I thought it would be. For whatever reason, I expect the LAG to be a CLI configuration but everything was done on the GUI side and as soon as the Channel group was added on the 6509 VSS side, port lit up and everything was good. 

Maybe the last question I have concerning HA and LACP connectivity is based of a ''warning'' from the technical document http://help.fortinet.com/fos50hlp/56/Content/FortiOS/fortigate-high-availability/HA_config_802.htm

Under "Link aggregation, HA failover performance, and HA mode", it states that I need to create two LAG's on the switch side so that the subUnit can participate in LACP negotiations and if this isn't done in Active/Active, it simply won't work as both units need to be able to process packets(including LACPDU) in that type of setup.

So on the Fortigate side, as an example, I created my LAG with port 39-40 which is automatically replicated on both units. On the Core VSS side, I need to have one Channel-group for FW1 going to the two physical 6509's and then one channel-group to FW2 going to the two physical 6509's. It actually makes sense that way, I just want to confirm I actually configure it correctly when the time comes. If I don't do it this way, then I need to go Active/Passive from what I can read through in the documentation.

Once again, thanks for the information you've given me so far.

[ede_pfau]

I can confirm everything that you've posted.

Going a-a is IMHO not so much a question of performance - if you need the extra % you're undersized anyway. In a-p mode the cluster members have much less data to sync which relieves CPU and memory, so that in general a-p mode is considered more stable. It's what I run in 100% of all managed clusters.

You're right with the trunks as well. As I'm not a Cisco guy (:-) 3Com) I can't tell if both switches are stacked, i.e., one unit. Doesn't matter in this case. You would need 2 trunks if not stacked, or if using an a-a cluster.

One caveat with LACP:

there's a setting for the LACPDU frequency. Some switches expect one per second, Cisco uses one per 30 s. In the CLI you can adjust that on the FGT ("slow" or "fast"). A mismatch would be hard to read from the switch logs.