This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Buying Decision: Astaro vs Fortigate Throughput

I want to procure an hardware appliance for my office of 100 users. And there is a battle happening between Astaro and Fortigate specifications.

We are comparing Astaro 220 with Fortigate 300C (for similar pricing) and could see that Fortigate has 8 Gbps of firewall throughput while Astaro displays 3 Gbps. What does this mean?

Also Fortigate exhibits 2 Million concurrent connections while Astaro does 300,000 connections. How does this affect our operations?

We are a group of 100 users, 60 Mbps WAN uplink, a web server hosted in-house, most of the users making Skype voice calls, and moderate VPN usage.

I am really comfortable with Astaro, but how I could convince people to buy it?
Thank you for any insight.


This thread was automatically locked due to age.
  • I echo everyone else, don't base it on numbers.

    I believe astaro and Fortigate will offer you a hardware trail (astaro offered me one but i didn't want it) so give both a try for yourself?
  • But from my vendor, the 300C is way cheaper than 220. Am I missing something here?


    What are you looking to purchase?  An Astaro Full Guard Bundle, or just selected pieces?  And for what term?
  • Thanks for the input guys!

    @BAlfson:

    But from my vendor, the 300C is way cheaper than 220. Am I missing something here?


    That's totally true and will stay always that way, but like You ask You need to support the expensive vs the cheapest, and this is Easy, I got this case very continued with customers, Fortigate doesn't have hard drive, so forget about collect, archive, and analyze logs between 24 hrs, If You want logs, reports, an archive logs You must buy another box the Forti analyzer (more electricity, more maintenance, more space occupy on your rack, jet another appliance to renew) it's not just the Throughput it's about compare apples with apples, and that numbers from Fortigate are fake compared with an real life operation, how another people says those numbers it's on labs. Hope that this post help You to take the best decision [;)]
  • That supposed ASIC version?  That's just a cutesy way of saying it's a custom cpu running a stripped down OS.  they pull everything from the cloud..there's no onboard anything in terms of storage or whatnot.


    Re: ASIC vs CPU:  You clearly do not understand the difference between an ASIC and a CPU.  CPU's are general purpose, their transistors are masked in such a way that they can be made to do many things at an acceptable speed, since all their transistors are divided up to cater for many tasks.  A CPU is a jack of all trades but master of none.

    An ASIC on the other hand is Application Specific, thus Application Specific Integrated Circuit.  An ASIC's transistors are masked in such a way that it does one or a few things extremely fast, since all transistors are dedicated to one or a few specific tasks.  An ASIC is not a jack of all trades, but most certainly by far is a master of one or a few.

    A 3D accelerator GPU chipset is an example of where ASIC's can be used to accelerate specific tasks to an extreme degree.

    Some FortiGate's do contain ASIC's in the form of encryption and compression accelerators for VPN and WAN acceleration, also with ASIC's which perform basic packet filtering at incredible speed (offloading the task from the main CPU) and also with ASIC regular expression engines for super fast anti-virus and IPS pattern matching.

    For one example, to see how impressive the FortiGates packet filtering ASIC's can be, note the FortiGates quoted speeds for their ASIC based models are the same regardless of packet sizes between 1,500 bytes, 512 bytes or 64 bytes.  With a software firewall running on a general purpose CPU, the performance drops as packet sizes get smaller and more frequent, which is why Packets Per Second tends to be a more meaningful measure of the speed of a packet filter than bytes per second.

    ASIC based FortiGate's are insanely fast, but if you enable something which cannot avoid a high amount of CPU intervention, then like any firewall performance will drop.  The beauty of the ASIC based FortiGates is that there is typically far less need for the CPU to intervene, due to the various ASIC's taking the load in the areas that they specifically excel in.

    Re: pulling everything from the cloud and having no onboard storage:  this is just completely wrong.  The FortiGate's download AV and IPS signature updates and FortiGuard info like blacklists, etc periodically like any vendors product would, but DOES store these along with base databases for each within their units.  The firmware images contain base images of this data for example.  FortiGates have enough flash based storage for this task and some can be upgraded with SSD's, so the claim that they "pull everything from the cloud" due to not having storage is just silly.

    BTW, I'm not an employee, nor do I own stock, I am however a very happy FortiNet admin of the last 4 years or so.  I have not tried Astaro, so I cannot comment on them comparatively against FortiGates.

    But what I do know, is that when I tested 310B's against Juniper SSG-550's and some Checkpoint appliance, I found that I could show the 310B in some respects to exceed FortiNet's claims, in other respects my testing gear was the limiting factor (FortiGate 310B's never dropped below no-firewall baseline).  And I pushed these firewalls hard enough to find the fail-open/fail-closed scenarios for AV for example.  I could easily kill the Junipers SSG's and the Checkpoint, but could only cause AV fail-open on the FortiGate 310B (configurable to fail-closed).

    ASIC based FortiGates are really fast and not in any way "cutesy custom CPU's".
  • Hi, ShaneJP, and welcome to the User BB!

    Not sure how you found your way here, but your Fortigate contact owes you and your wife a dinner in the finest restaurant in town! [[;)]]

    My first jobs were with IBM manufacturing, and I've been in the industry ever since.  I lived through the heyday of ASICs in the mid 1990s, and was long a proponent of them.  Certainly, at least by ten years ago, the improvement in CPUs had made them more cost-effective for most applications than ASICs.

    Where compactness, low heat and limited functionality are important, ASICs can be cost-effective. Radios (in wireless routers, cell phones, etc.) and high-end graphics processors come to mind.  Beyond such narrow applications, it's usually quicker and cheaper to use a modern CPU even if the only circuits used on it are ones that could have been supplied by an ASIC.

    As for CPUs, today, some SandyBridge Intel processors include what is, in essence, an on-board ASIC to handle IPsec en/decryption.  That the additional circuitry is included on the silicon with the CPU reduces its cost to a few percentage points of what an external ASIC would cost.

    Am I saying that it's not possible to produce a cost-effective ASIC-based UTM? - No.  I am saying that it is possible to define a test suite that will "prove" ([[;)]]) that one solution is faster than another, and that the only real way to evaluate a fit is to actually try the devices in the environment where they will be used.

    Cheers - Bob
    PS One of the decisions for each customer is the choice of hardware platform.  In some cases, where a relatively-small number of users and devices would overload an Astaro appliance, the choice is made to use a virtual or software appliance on much more powerful hardware.
  • Hi, ShaneJP, and welcome to the User BB!

    Not sure how you found your way here, but your Fortigate contact owes you and your wife a dinner in the finest restaurant in town! [[;)]]


    Haha, thanks Bob.

    I have a Google Alert setup with various FortiNet specific terms so that I can get a quick heads up on vulnerabilities and people trying to find their way around FortiGates, etc.  Sometimes those alerts bring me to something like this discussion, other times I'm alerted to a new proxy or method to circumvent FortiGate filtering.


    My first jobs were with IBM manufacturing, and I've been in the industry ever since.  I lived through the heyday of ASICs in the mid 1990s, and was long a proponent of them.  Certainly, at least by ten years ago, the improvement in CPUs had made them more cost-effective for most applications than ASICs.


    You must have spotted the error in Williams claim that FortiGate ASIC's are "a cutesy way of saying it's a custom cpu running a stripped down OS" then?

    Nothing cutesy about an ASIC's that can allow UTM, VPN and packet filtering of 64 byte packets at 10Gbit/S each, simultaneously.  They are certainly not CPU's!

    http://www.fortinet.com/sites/default/files/whitepapers/Accelerating_UTM_Specialized_Hardware.pdf


    Where compactness, low heat and limited functionality are important, ASICs can be cost-effective. Radios (in wireless routers, cell phones, etc.) and high-end graphics processors come to mind.  Beyond such narrow applications, it's usually quicker and cheaper to use a modern CPU even if the only circuits used on it are ones that could have been supplied by an ASIC.


    In the late 80's I was working in electronics for the Navy.  Back then a lot of digital gear was discrete using IC's packed with a few logic gates and circuits would have to be creatively made up with them for simple things, or simple CPU's would need to be used for complex things.  Before then, some quite complex things were being done with simple computers made from various types of amplifiers and gearbox setups with 3-phase motors and sensors.  Very interesting, but I digress.


    As for CPUs, today, some SandyBridge Intel processors include what is, in essence, an on-board ASIC to handle IPsec en/decryption.  That the additional circuitry is included on the silicon with the CPU reduces its cost to a few percentage points of what an external ASIC would cost.


    I'm aware of and very happy about this.  One drawback to external ASIC usage (external being off-CPU) is that very small transactions can be slower with the ASIC than had it just been done on CPU, due to the fact that the CPU needs to get the small transaction out to the ASIC, with setup costs and propagation delay, etc and then accept the return data.  Although the ASIC might seem like it should be faster even for the smallest transactions, the time/cycle and latency cost of offloading from CPU to ASIC meant that expected gains were lost for small jobs.  Thankfully this can be dealt with in software, by not allowing a transaction of a smaller than x size to be dealt with by the ASIC and instead being performed on-CPU.


    Am I saying that it's not possible to produce a cost-effective ASIC-based UTM? - No.  I am saying that it is possible to define a test suite that will "prove" ([[;)]]) that one solution is faster than another, and that the only real way to evaluate a fit is to actually try the devices in the environment where they will be used.


    I'm as sceptical as the next guy when it comes to vendor claims, but I've worked with FortiGate 310B's every day for the last 4 years or so and I've seen the minimal impact enabling these features has thanks to the use of the ASIC's.  I'm used to seeing bigger impacts from CPU/software only firewalls.  The Juniper SSG's do something similar with FPGA's.  One risk with these sorts of systems, is when a vendor provides the slowest possible CPU to glue it all together, so that when the CPU is called on for edge cases, you feel the pain.  I know some Cisco systems have suffered from this with the slowest MIPS CPU's they can glue ASIC's together with.


    The FortiGate-60C comes to mind as a demonstration of a cost-effective ASIC-based UTM. ASIC SoC unit which can be had for $600. Certainly this is on the low end of town and I cannot vouch for it since I have not tested it yet.  But it's so cheap I wouldn't mind one for home for Skunkworking ideas...

    FortiGate-60C | Fortinet

    Network security is perfect for those edge cases where ASIC's can help though.  There are ASIC systems available which allow for in-line Snort IPS at 10Gbit/S.  I don't know of a CPU/software based system which could come close to that, let alone with a small packet attack.

    Also consider, no matter how fast a CPU can be made with the smallest transistors, the same 1"x1" silicon dedicated to a task with an ASIC design can be much faster for certain applications.  The advance of CPU's does not occur without the advance of ASIC's.


    Why not cater for the worst case with in-silicon packet filtering for a flood of smallest possible packets at gigabit saturation speeds which does not impact the system CPU and allows your secure network to continue to access your DMZ network with 0 impact?

    Or IPS at gigabit speeds (310B limited to 800Mbit, 300C apparently at 1.4Gbit which I can't vouch for) to 10Gbit for higher end ASIC accelerated gear.

    Since modern CPU's come with built in crypto and sometimes related compression ASIC style on-silicon, this can likely be dropped.  Especially since the value on the desktop/laptop is not likely to go away, since the benefits of VPN, SSL and full disk encryption are not going to go away.


    Cheers - Bob
    PS One of the decisions for each customer is the choice of hardware platform.  In some cases, where a relatively-small number of users and devices would overload an Astaro appliance, the choice is made to use a virtual or software appliance on much more powerful hardware.


    Hmm, I'm all for virtual UTM for visibility into and protection of virtual environments (since threats can be hidden from external old-school security appliances), but given that virtualization presents a new layer for attack and that every x86 implementation was vulnerable according to the Tavis Ormandy of Google white paper on the subject, I won't dare suggest the use of virtual firewalls for perimeter or non-VM security.

    Cheers,


    Shane
  • Good discussion, Shane.

    I'd like to own a Ferrari, but I probably wouldn't ever get it up even to 90MPH.  Instead, I drive Toyotas, and I likely never would have gotten anyplace faster with a Ferrari. [;)]

    All that to say that I don't disagree with anything you say, just that speed alone isn't the only consideration for a UTM, and that he should try them both.

    Cheers - Bob
  • Good discussion, Shane.

    I'd like to own a Ferrari, but I probably wouldn't ever get it up even to 90MPH.  Instead, I drive Toyotas, and I likely never would have gotten anyplace faster with a Ferrari. [;)]

    All that to say that I don't disagree with anything you say, just that speed alone isn't the only consideration for a UTM, and that he should try them both.

    Cheers - Bob


    Hi Bob,

    To be sure, I didn't feel we were disagreeing.  I just don't like to see great tech being belittled with incorrect statements.  I get hassled by tech company partners all the time to replace systems we have that are working perfectly, because they claim there's a problem with them.  So often those tech partners just make up or parrot BS to sell what they sell over what they don't.

    I'm sure Astaro is great, but the claim of Williams that the ASIC's in FortiGate gear are just cutesy little CPU's running a stripped down OS, is bogus.  Same for the no storage claim.  In fact, the no-HDD, solid state nature of FortiGates is a feature.

    The company I work for is lucky enough to have a decent budget, so we could afford the Ferrari, although the FortiGate 310B was the cheapest of what we were trialling at the time (we did not try Astaro back then).  Luckily its weakest performance area was well above our needs for that area and the 310B's were within budget, so in some areas we got Ferrari performance that we did not need.

    But like Ferrari's, ASIC's can come with some quirks too!

    As I'm sure you know, once an ASIC is made, unlike FPGA's an ASIC pretty much cannot be patched.  If there is a design flaw in the ASIC, then often the fix is to disable that portion of the ASIC or work around it within software, rendering the performance enhancement that design provided useless.

    As an example, the NP2 hardware accelerated NIC's on regular FortiGate 310B's will drop Ethernet frames that are larger than 64 bytes if those frames use padding.  The Ethernet IEEE 802.3 3.2.7 spec states that an Ethernet frame must be exactly 64 bytes if padding is used and non-conformant frames should be dropped.

    Unfortunately, not all devices and systems honoured the standard, including VMware's ESX 3.0.1 and 3.0.2, some Nortel switches and WDM's, some Cisco IP phones and Foundry load balancers.  But the NP2 powered FortiGate devices do honour the standard by dropping those frames.  As a consequence, if you had a regular FortiGate 310B with these systems, you would have to either patch where possible, or otherwise replace hardware at whichever point is cheapest.

    FortiGate actually offers an alternative 310B model which does not drop those faulty frames, even though the spec states it should, for those who need to allow broken systems to work.  If the 310B were FPGA or just software based, you would just enable/disable the feature.  With an ASIC that wasn't designed to take this problem into consideration you have to swap the unit out if you had no other recourse.

    So ASIC's need to be done right, because it can be expensive to get wrong!

    Thankfully we've not had any troubles like this though.

    Cheers,


    Shane
  • Thanks again for your contribution here.  I think you pretty-much covered the +s and -s of ASICs vs. CPUs in a fair way.  I'm glad William was in one of his "politician" modes and used such colorful language to describe ASICs! [;)]

    Cheers - Bob
  • ok then...how much stoarge is on the fortigates now?  Asics aren't the end all be all as your first defense mentioned..now that you've been honest about he drawbacks and not just posturing about them being ultimately superior then a real conversation can continue..[:)]