Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
AdrianOlson
New Contributor

Software Switch performance

I have a FWF-60D that i have created a software switch to bridge the Internal and WIFI networks into a single network. I also have a DMZ network, but when I do a file transfer to the DMZ network from the internal, I only get about 23MB/s. While transferring I also see the CPU usage @ 100%. Is this a by product of the software switch? my knowledge leads me to believe in this scenario I am CPU limited and not hardware limited (GbE). Am I on the right track? Are there any other ways to achieve this?
FWF-60D - 5.0.6 FWF-30D - 5.0.6 FGT-100D - 5.0.6
FWF-60D - 5.0.6 FWF-30D - 5.0.6 FGT-100D - 5.0.6
1 Solution
ede_pfau
SuperUser
SuperUser

hi, and welcome to the forums (though a little late). You' re absolutely right. Software switch (as opposed to hardware switch) means just that - the CPU handles all packets. Especially the Fortigates with SoC (system on chip) offer relatively weak CPUs, 20C/40C/60C and the D series. In a 80C the effect is way less noticeable. Look here for a list of Fortigate models and their hardware: https://forum.fortinet.com/FindPost/100451 Only in some of the latest midrange FGTs and using FOS v5 you can create a hardware switch. For a workaround consider just routing the WiFi subnet.

Ede Kernel panic: Aiee, killing interrupt handler!

View solution in original post

Ede Kernel panic: Aiee, killing interrupt handler!
13 REPLIES 13
ede_pfau
SuperUser
SuperUser

hi, and welcome to the forums (though a little late). You' re absolutely right. Software switch (as opposed to hardware switch) means just that - the CPU handles all packets. Especially the Fortigates with SoC (system on chip) offer relatively weak CPUs, 20C/40C/60C and the D series. In a 80C the effect is way less noticeable. Look here for a list of Fortigate models and their hardware: https://forum.fortinet.com/FindPost/100451 Only in some of the latest midrange FGTs and using FOS v5 you can create a hardware switch. For a workaround consider just routing the WiFi subnet.

Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
ShrewLWD
Contributor

Hey Ede, I have a question about this then. Assume the wifi interface MUST be on the same subnet as the internal. We can already agree soft-switch is a CPU killer. Separate to the complexity, how much of a hit to the CPU would creating a transparent VDOM, assigning just the wifi interface to it, then using VDOM-Linking back in to the internal VDOM be, versus soft-switch? I understand enabling VDOM already breaks up the resources of the entire box, but would that allow the traffic to be SoC traffic again?
ede_pfau
SuperUser
SuperUser

I frankly have no idea but guesses... The VDOM itself will not hit CPU much - you sacrifice some memory, though. In the newer FOS versions you have ' internal' inter-VDOM links so that won' t cost you any physical ports at all. AFAI remember noone else has tried this and reported on the forums in the past years. Would you dare to be the first and let us know for sure? My thought would still be how to avoid having the WiFi on the same subnet. What you achieve by bridging is that broadcasts can reach the WiFi clients. If the reason is DHCP broadcasts then you could do with DHCP relay intstead. Maybe you could give us a hint what the pressing requirement is that makes you think of bridging.
Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
ShrewLWD
Contributor

Hi ede, I wasn' t expecting an answer to soon, so I am already down the path of doing a before and after testing of a 60C, 5.0.6. first with software switch, then VDOMLinking. In our line of work, we require our techs to walk around with a tablet and software being pulled from the server on the LAN side. They also need to send print jobs back to the internal network. There are a few other things, but those are the primary ones. Believe me, if we could, we would separate them in a heartbeat. I' ll let you know what I find.
ede_pfau
SuperUser
SuperUser

I might be dumb, or inexperienced, but I' d think that all of the tasks you mention could be done in a routed environment as well. Printing? Pulling software might be special on account of the method/software used. Anyway, we' ll see what you find.
Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
Dave_Hall
Honored Contributor

Personally, never tried creating a soft switch between the wifi and Internal interfaces on anything lower than an 80CM, but find it hard to believe the 60D hitting 100% CPU utilization - you don' t have rogue detection enabled? (Eats up a lot of CPU usage). Never tried this myself, but came across it once before...we had to deploy a fgt at a remote site that had a locked-down Cisco router which was basically NATing the connection between 2 different subnets (between two buildings about 500 feet part). Not sure if this is something you may or even want to try/do though in your case.

NSE4/FMG-VM64/FortiAnalyzer-VM/6.0 (FWF30E/FW92D/FGT200D/FGT101E/FGT81E)/ FAP220B/221C

NSE4/FMG-VM64/FortiAnalyzer-VM/6.0 (FWF30E/FW92D/FGT200D/FGT101E/FGT81E)/ FAP220B/221C
ShrewLWD
Contributor

Hi all, sorry, its a little slower completing this test (the never ending hey-can-you' s!). For part one, I set up a 60C with softswitch (wifi and internal). I hooked up a wireless N laptop to the wifi, and another laptop wired (gig speed). I then had both simultaneously download an ISO of Windows 7 64Bit from digitalRiver (they have a really nice pipe). Its a 3.09GB download. (I also had one grab the home edition, one grab the professional, so they would be unique files). The wired finished first, the wireless took another few minutes (we have a 2Gig connection to the internet). During that time, the CPU fluctuated between 80-100% (no UTM enabled), then 65-80 after the wired completed. The interface was sluggish to move around in, too. I' ve now got it set up for VDOMs, with wifi in the transparent vdom, and 2-way vdom linking enabled. I' ve run into a small issue with it not broadcasting the SSID, so I am still working on that. The wired laptop pulled the same ISO, and, obviously, the CPU barely blipped.
Matthew_Mollenhauer
New Contributor III

Would it make sense to keep them on separate subnets and setup multicast policies between the interfaces. I had a similar situation on the 60CX that I use in my lab (which just happens to my at my home) I was wanting to get Bonjour running between Wired and Wireless so that I could use Apple Remote on the iPad and so I could print directly to my printer from my Macbook and iPad. To solve this I simply setup a multicast Policy for Bonjour and it all started working. I also setup another policy to allow my DLNA server to be discovered from wireless. It may take a little work to find the correct addresses being used, but I' d have to imagine in the end it would have to be the most efficient use of CPU. Regards, Matthew
ShrewLWD
Contributor

Sorry guys, I am still stuck, unable to get an SSID to broadcast in the transparent VDOM. As for the other questions, given our IP structure (across almost 200 locations) and software requirements (software locked to LAN ip ranges only, etc.) we HAVE to have the wifi be on the same subnet. We have considered and tested many different scenarios, but have found the minute the wifi is on a different subnet, too many things break, and/or will require too many changes across the topology, for us to move away from same subnet. Has anyone else had success enabling an SSID in transparent mode, on a smaller box (60C/D, 80?). Yes, I did verify it is set to broadcast-ssid enable. Its all default configured, no special setups.
Announcements
Check out our Community Chatter Blog! Click here to get involved
Labels
Top Kudoed Authors