Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
60C Link Aggregation
Hi guys,
I' ve been googling and searching here, but haven' t found an answer.
Does the 60C support link aggregation?
The data sheet here: http://www.fortinet.com/sites/default/files/productdatasheets/FortiGate-60C.pdf
Says " Multi-Link Aggregation (802.3ad)"
However, I' ve seen some internet search mentions of the 60C not supporting link aggregation.
Anyone know the truth?
- « Previous
- Next »
29 REPLIES 29
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Definitely... but that doesn' t quite answer the bit about how the fortigate handles the two interface connections internally, which was my big problem... I wanted to combine those two connections using aggregation, or interface redundancy, or something. I wanted a single IP across 2 connections, and each of those connections to a separate switch.
Essentially I' ve concluded that I agree with you I' d prefer not to use a software switch.. and so I' m going to do what is the only other option available to me since the 60C doesn' t support aggregation and " full mesh" ... meaning I' ll hook 60-C #1 up to switch #1... and 60-C #2 to switch #2... cross-connect switch 1 to switch 2... and just use fail-over monitoring so that if switch #1 died, then I' d fail-over to 60-C #2, which is setup on switch #2.
Not as good as a full mesh, because my setup wouldn' t be resilient against the unlikely scenario of 60-c #1 and switch #1 both dying at the same time.. but still pretty good.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You could use the internal ports on each 60C in ' switch mode' , and connect each FGT to both switches. The switches should be linked to each other as well. But this setup, as well as your proposal, requires Spanning Tree protocol to be active on the switches. If available, Rapid STP is preferable as it converges more quickly.
Basically, a HA cluster is ONE device, with one IP address and only one MAC address. Any additional connection after the first between the cluster and the switches must be put into the ' blocked' state by the Spanning Tree protocol, or you will experience a broadcast storm.
So I don' t see why you shouldn' t configure a full mesh (4 connections) of which only 1 will be active/forwarding at any time. This is called resiliency, second best to ' full mesh active' . The latter would require that your switches form a cluster like the FGTs, called ' virtual cluster' (Juniper) or IRF (HP). IMHO a bit oversized for a pair of 60Cs.
Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You could use the internal ports on each 60C in ' switch mode' , and connect each FGT to both switches. The switches should be linked to each other as well. But this setup, as well as your proposal, requires Spanning Tree protocol to be active on the switches. If available, Rapid STP is preferable as it converges more quickly.This is exactly what i have done, use the " built-in-switch" of the 60C.
FCNSA, FCNSP
---
FortiGate 200A/B, 224B, 110C, 100A/D, 80C/CM/Voice, 60B/C/CX/D, 50B, 40C, 30B
FortiAnalyzer 100B, 100C
FortiMail 100,100C
FortiManager VM
FortiAuthenticator VM
FortiToken
FortiAP 220B/221B, 11C
FCNSA, FCNSP---FortiGate 200A/B, 224B, 110C, 100A/D, 80C/CM/Voice,
60B/C/CX/D, 50B, 40C, 30BFortiAnalyzer 100B, 100CFortiMail
100,100CFortiManager VMFortiAuthenticator VMFortiTokenFortiAP 220B/221B,
11C
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I know you know, and I' m glad you figured it out previously and tested it in practice. I just wanted to point out that you' d have to configure STP on the switch(es), or create network loops otherwise.
Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi guys,
Yep I' m with you... with my setup it' s a bit trickier than that because I have 3 VLANs to worry about (LAN WAN DMZ), so I can' t get away with using only the internal switch.
I' d have to enable interface mode and create software switches to accommodate all 3 VLANS.
However, I read this:
http://kb.fortinet.com/kb/viewContent.do?externalId=FD31769&sliceId=1
Which indicates " soft switch interfaces cannot be monitored by HA or used as HA heartbeat interfaces."
So end of the day I won' t be able to go that route if I can' t use HA monitoring on the software switches.
So still thinking my only option is just to go with one FGT hooked up to each switch and use FGT fail-over in case of switch failure
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
em, the 60C has got 4 independent interfaces even in switch mode - switch, WAN1, WAN2, DMZ. One of them would be your HA link, the switch for the VLANs. Should suffice.
Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thing is -
I have 2 FGTS and 3 VLANs: WAN, LAN, DMZ on 2 trunked switches.
I want each VLAN to have a redundant connection to each switch. So that' s 6 cables to each firewall, 12 cables total.
That' d mean something like (for each of fw01 and fw02):
WAN VLAN on switch01 connected to WAN1
WAN VLAN on switch 02 connected to WAN2
LAN VLAN on switch 01 connected to internal 1
LAN VLAN on switch 02 connected to internal 2
DMZ VLAN on switch 01 connected to DMZ
DMZ VLAN on switch 02 connected to internal 3
internal 5 for heartbeat between fw01/fw02
But the part I' ve been talking about above is how I can link those interfaces internally in the FGT. E.g. I want WAN1 and WAN2 in this example to be like a single interface with a single IP address. Same for internal1/2 and DMZ/internal3.
As per the subject of the thread, the best way is link aggregation or interface redundancy.. but those aren' t available... and a software switch is an option, but it' s not HA monitorable, doesn' t fail over as quickly, and has some downsides in performance I think.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think this is overly complicated, i.e. a bit theoretical. If you just connect each FGT to one switch you will have redundancy at 100% - if one switch dies, the disconnected FGT will fail over to it' s sibling, and traffic continues to flow. Only in A-A mode you' d notice less throughput. Just make sure you monitor at least one connection to the switch so that a switch failure gets noticed.
Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yep, that' s also what I was saying above the last couple posts..
I' ve also decided to do it that way instead since otherwise I' d need a 200B with link aggregation to " do it the right way" with link aggregation and a full mesh setup.
Thanks for all the help guys, think I' ve got this settled
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Beware that creating a software switch causes traffic to traverse CPU!
As a FG60C has limited CPU power, I want to warn you for the implications. You may as yourself what the added value is of creating a sub version of redundant links in this setup.
Cheers, Eric
Rackmount your Fortinet --> http://www.rackmount.it/fortirack
Rackmount your Fortinet --> http://www.rackmount.it/fortirack

- « Previous
- Next »