Skip to main content
AdrianOlson
New Member
March 15, 2014
Solved

Software Switch performance

  • March 15, 2014
  • 12 replies
  • 15298 views
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?
    Best answer by ede_pfau

    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.

    12 replies

    ede_pfau
    SuperUser
    ede_pfauAnswer
    SuperUser
    March 16, 2014

    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.

    ShrewLWD
    New Member
    March 20, 2014
    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
    March 20, 2014
    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.
    ShrewLWD
    New Member
    March 20, 2014
    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
    March 20, 2014
    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.
    Dave_Hall
    New Member
    March 20, 2014
    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.
    ShrewLWD
    New Member
    March 21, 2014
    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 Member
    March 23, 2014
    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
    New Member
    March 25, 2014
    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.
    rwpatterson
    New Member
    March 25, 2014
    Not quite your answer, but I have the WiFi (wlan), wan2, Internal2, Internal4 and Internal6 built into a switch in NAT/Route mode on a FWF80CM without issue. The DHCP is forwarded to a Windows box, and both wired and wireless share the same IP address space happily. Hope that does something for your testing. Here' s an idea for you:
  • Create a second VDOM in NAT/Route mode
  • Create a VLAN, same number on both
  • Pass the VLAN traffic across the inter VDOM links
  • Bridge the VLAN and internal on one, and the VLAN and WiFi on the other.
  • ede_pfau
    SuperUser
    SuperUser
    March 25, 2014
    No doubt it works, the original question was about the performance hit. As I said, the 80C still is a work horse with a decent CPU. Not comparable to the 60D, 90D, 100D which boast high throughput for accelerated traffic but falter with SSL traffic and soft switching. With a newer model, it would be best to pick a model with hardware switch support.