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.
Parents
  • 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.
Reply
  • 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.
Children
  • 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