Skip to main content
nsantin
nsantin
New Member
December 28, 2014
Question

Aggregate port within same switch interface

  • December 28, 2014
  • 6 replies
  • 13289 views

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!

 

    6 replies

    nsantin
    nsantinAuthor
    New Member
    December 28, 2014

    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
    emnoc
    New Member
    December 29, 2014

    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
    nsantinAuthor
    New Member
    December 29, 2014

    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
    emnoc
    New Member
    December 29, 2014

    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
    nsantinAuthor
    New Member
    December 29, 2014

    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
    emnoc
    New Member
    December 29, 2014

    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.

     

     

    Terms & ConditionsAccessibility statement