Aggregate port within same switch interface

[nsantin]

Hi, I'm testing Aggregate Links on a HA cluster of FGT100D

Do I have to treat the aggregate link as a completely separate interface (routing, policy,etc) or can I have it as a subset of an existing "Hardware Switch" interface?

I'm trying to setup 3 lags (6ports) together with a bunch on individual ports all configured as one switch (and one IP subnet). 

Is this possible?

Or do I need to assign each lag an IP, then have a policy between the 4 components (3 LAGs and 1 switch)?

Thanks!

[nsantin]

Ok, I think I figured it out, looks like I need to create a zone instead. I made the mistake of first configuring all my "lan" ports as a hardware switch then did all my routing/policies using the "hardwareSwitch" interface. 

It appears I've made quite the mess.

If i'm correct, then I need to create my 3 aggregate interfaces, then move all my ports out of the hardware switch and create a new software switch. The move everything into a new zone.

Then go back to my policies and routings and change everything from the old hardware switch interface to the new zone interface.

This sound correct?

RTFM

[emnoc]

I don't think you can add a 802.3ad lag into a switch-interface but give it a try and let's us know. As far as zone, the zone concept should see all interfaces as a L3 interface, so I don't quite understand what you mean by

The move everything into a new zone

Just remember when you start playing with zones it chances a lot on how you can apply fwpolicies to just one member in the zone.

[nsantin]

Hi Eddie,

Couldn't get the LAGs into a virtual switch, the CLI gave an error that the interface wasn't in the datastore (doesn't see them)

I did get them into a zone, but looks like zones are just an administrative bundle, (like VIP groups) and you need policies between LAGs.

looks like Im going to throw in the towel on this, would have been nice to build a virtual switch that included multiple LAGs and manage it all as one interface, maybe that will come out in a future release.

I was trying to connect 3 ESX5.5 servers using LACP directly into the FGT, not worth the policy mess i'll need to create, for now I'll stick with LBT on the ESX.

[emnoc]

I'm not Eddie but FWIW, we built the same but use a cheap HP switch. I have KVMs server in a LAG group to the HP switch and the same with our FGT90D

I would just place the  ESX server in a LAG bundle and assign them in their own L3 boundary and then apply fwpolicys between ESX guestOS to other GuestOS or internet. Here's an example of what we did with  FGT100D I have 6 ports used by  3 VMservers in a softwitch PBX hosted env. Each guest is a plumbed as a unique tag and  I have zones for KVM01 thru 3  for simplicy of  policies

Just be aware of  intrazone and interzone issues and all is well.

[nsantin]

That's exactly what I wanted to do with the VM Data network, but I was hoping to eliminate the need for more hardware (points of failure).

BTW, did you notice any improvements using LAG vs LBT with your VM Hosts? (not including storage which I have on a different network). Was it worth it?

[emnoc]

We didn't run LBT in this env ( VMware ) but I have in a true nexus DC. It's the smarter way to go for vserver  nic teaming and if you don't trust of have  had problems  with LACP.  I have had zero problems LACP bundle btw so the performance gains if any is minimal if any.

On the FGT100D, we have looked at seriously deploying 140D due to the greater  port density, but as usual my customer are cheap to save a dime or dollar. Right now it's a golden design but as they grow, they will exhaust ports which means I have  them to buy more fortigate and get more business configuring more fortigates

Nothing bad about more business.