Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Encryption Hardware IT

F5 Fires Back On Open Source SSL Accelerator 120

Posted by timothy from the first-name-basis dept.
Random Feature writes "In response to Build an Open Source SSL Accelerator, in which o3 magazine detailed how to build a solution comparable to an F5 BIG-IP 6900 on the cheap, F5 Fires Back claiming it's not as cheap as it appears and pointing out the potential performance implications of a 'cobbled together set of components designed to mimic similar functionality.' The discussion on the performance of the Open Source solution based on Opteron RSA operation processing capabilities brings into question the validity of the 'more SSL TPS for cheaper' argument presented by o3."
This discussion has been archived. No new comments can be posted.

F5 Fires Back On Open Source SSL Accelerator More

F5 Fires Back On Open Source SSL Accelerator

Comments Filter:

  • How is that different from F5? (Score:2, Interesting)

    by Anonymous Coward

    The F5 load balancers we have (admittedly not the newest) are just standard ATX & PCI off the shelf products and BSD.

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      And custom software and encryption accelerator cards.

    • Re:How is that different from F5? (Score:5, Funny)

      by Script Cat ( 832717 ) on Friday April 17, 2009 @09:41AM (#27612771)
      I once worked on binary load lifters which are very similar to your F5 load balances in many respects.

      • We used to cobble together SSL Accelerators from womp rats back home, and they're not much less scalable than a BIG IP-6900.

    • Linux, now. Formerly BSDi BSD/OS, but Wind River Systems bought out BSDi in 2001 and pretty much EOL'd BSD/OS by 2004.

      Linky [wikipedia.org]

    • Re: (Score:1)

      by gavint ( 785035 )

      They're two generations old.

      The generation after that ran Linux (they dropped BSD) on a server motherboard and a Broadcom switchplane at the front to do the simple stuff.

      I've not seen inside the latest generation but I'm told they use a completely custom-fabricated motherboard which integrates the two parts. These still run Linux. Both use SSL accelerator chips.

      That said, the hardware is only a small part of what you're paying for, you're also paying for the TMOS operating system, administration interface,

  • Shill (Score:2, Interesting)

    by LordKazan ( 558383 )

    Shilling much?

    • Re: (Score:2, Troll)

      by drinkypoo ( 153816 )

      The parent has a point; this response is not only predictable, but precisely the same kind of FUD [slashdot.org] used to sell closed-source products. The difference is that since the F5 is made up of the same stuff that you can roll yourself, it's even less warranted.

    • Re: (Score:2, Troll)

      by RiotingPacifist ( 1228016 )

      you know your a shill when:
      *Page served on aspx
      *You make lists that contain just 2 valid criticisms then bloat it out to 5 with shillness

      * TCP connection setup and teardown processing
      * Inspection of application data (layer 7 inspection is rarely computationally inexpensive)
      * Execution of functionality (caching, security, acceleration, etcâ¦) [does their software magically do these without executing the different operations]
      * Transfer of data between proxies (when deployed on the same device this is minimized) [A way of doing it, which is impossible to do with their stack, vs a way both systems can be deployed]
      * Multiple log files [cat log1 log2 log3 log4 > logALL too much? I'm sure many loggers could make it even simpler and that's assuming you don't prefer separate log files, for separate steps in the operation]

      *You use very artificial scenarios to make your point:

      In situations where images are being delivered over a LAN, for example, this will not provide any significant performance benefit and in fact will likely degrade performance.

      would you really need ssl acceleration for your lan? would it really be the same one you use for web serving?

      He also claims it's impossible to secure a Linux box against ARP poisoning and DoS attacks, which is a shame because in amongst the shilling there are some good points.

  • Why would they actually respond to that article, from what it appeared to me the general mood on /. was that it was neat but would be more trouble than its worth.

    • Re: (Score:1, Insightful)

      by Anonymous Coward

      Because a lot of us in the technology industry will read /. and investigate the technologies discussed. F5 had to respond in order to provide a counterclaim. You can't let something like the aforementioned article go without response, especially on a forum that will be frequented by those who have a chance of understanding what they or O3 magazine was talking about in the first place.

      Rejoice, for /. == 1337

    • Re: (Score:1, Flamebait)

      by Galactic Dominator ( 944134 )

      Maybe because the "general mood on Slashdot" is completely and utterly irrelevant to people who might be interested in such a solution?

  • Common response (Score:4, Interesting)

    by Lord Grey ( 463613 ) * on Friday April 17, 2009 @09:36AM (#27612635)
    At the risk of being flamed as a troll and getting modded to hell, I'd like to point out that F5's response is exactly the same kind of thing one hears when comparing special-purpose (or custom-written) software to the integration of COTS applications, libraries or frameworks. Sure, with the latter option you get something that works, eventually, but at what cost to maintainability and performance?

    I say this after coming out of a meeting where a large Rube Goldberg system of Java tools was presented as the best solution to a high-volume ETL problem that has particular performance and distribution requirements. The resemblance is uncanny.

    I'm all for not reinventing the wheel, but if that's what is required, then just do it.

    • Re: (Score:3, Insightful)

      by spinkham ( 56603 )

      If you have the experience with Linux based fail over solutions and apache or nginx to pull this off, more power to you. Go ahead and save some bucks, but make sure you test the heck out of it first, and have a plan for updates and failures.
      If not, the money you would save is probably not worth the potential downtime you could experience.

      Big iron boxes have big iron price tags, and you can almost always hack together something cheaper. The question is how much more reliable, easy to configure, and easy to

      • I don't think it is much different, in the "test the heck out of it", etc. It is more can your company afford to internalize the risk, and does your contract with the vendor reduce that. And can you afford the extra time required to DIY. Regardless the solution, you better test the heck out of it if you can't afford the downtime. In times like these it is often more of a, if you can't afford the big iron, then do what you can afford. for example, that is why I went to a (unrelated to the discussion at

      • Re: (Score:2)

        by Bert64 ( 520050 )

        What these big vendors don't want, is for smaller companies with capable staff creating their own massively cheaper appliances... This will force the big vendors to bring their prices back down to more realistic levels. A lot of these companies are very top heavy, and would experience significant pain if they had to operate on a less extortionate profit margin or against competition.

      • Re: (Score:2)

        by zyzko ( 6739 )

        Big iron boxes have big iron price tags, and you can almost always hack together something cheaper. The question is how much more reliable, easy to configure, and easy to upgrade is the big iron? In most organizations, buying equipment is cheaper in the long run then buying experience and maintenance for a home grown solution.

        Yes, but big iron boxes are just boxes. They might have special hardware optimized to do what they do, but it just might also be cheaper to DIY. Case in point - EMC Celerra: It is basicly a Redhat with custom management software (with nice but quite expensive hardware). Doing the same thing homegrown (iSCSI + NAS-gui) can be cheaper and you can even have more features. You can buy a support contract and you have a clear upgrade path, and there are propably contractors willing to work for you even if you can

    • Re: (Score:3, Informative)

      by 222 ( 551054 )
      With all due respect, load balancing SSL isn't exactly rocket science. It serves a fairly straight-forward purpose. Hell, I did something like this with an Apache box serving as a reverse proxy to an internal web server; my setup isn't designed to accommodate the load discussed in this article, but it does just that. Connections from the outside are secure between my Apache box and the outside world, and my internal web server doesn't worry about a thing.

      The Apache reverse proxy was more of a security meas

      • ...my setup isn't designed to accommodate the load discussed in this article...

        Color me surprised. If your solution can't play in the big leagues that an F5 is aiming at, then what are you bragging about?

        An F5 isn't aimed at the problem you solved (at least not at that small a scale). It's intended for high-traffic, bandwidth-intensive applications and sites. Did you post to confirm the premise of the article? If so, I totally missed that, what with the way text often fails to convey tone.

        • Re: (Score:3, Interesting)

          by 222 ( 551054 )
          Again, with all due respect load balancing is something that the Apache crowd figured out a long time ago. My particular setup might not be ripe for the big leagues, but reproduced on an industrial scale Apache is quite capable. I also wasn't "bragging", I was simply sharing my personal experience with this sort of thing. I often appreciate it when other slashdotters do the same.

          If you'd like more info on Apache HA, I'd start here:

          http://httpd.apache.org/docs/2.2/mod/mod_proxy_balancer.html [apache.org]

          You also

        • Re: (Score:2)

          by Raenex ( 947668 )

          Why did you cut off the ", but it does just that." part?

          • Re: (Score:1)

            by Burkin ( 1534829 )
            Because it's easier to attack someone when you take the quote you want out of its context?

    • Interesting. We use perl scripts and Pentaho to do VERY high volume ETL. One could argue it's a bit Rube Goldberg, but it also works without a hitch, and software cost us $0.

  • You must be smart when buying these things (Score:5, Insightful)

    by C_Kode ( 102755 ) on Friday April 17, 2009 @09:37AM (#27612663) Journal

    You must be smart when buying stuff like this.

    First off, if I'm handling 25k+ SSL TPS, point blank, I pay the money for an F5. A home built solution will only get you fired when something goes seriously wrong.

    Secondly, if an F5 is out of your budge and you aren't handling 10s of thousands of SSL TPS, look elsewhere. Kemp Technologies makes a solution that support up to 10k SSL TPS for less than half the price and even cheaper if you handle even less. If you're not even handling a thousand of TPS, let your Apache servers handle SSL and be done with it.

    • You must be smart when buying stuff like this. First off, if I'm handling 25k+ SSL TPS, point blank, I pay the money for an F5. A home built solution will only get you fired when something goes seriously wrong.

      I agree you must be wise with your purchases. At times, commercial hardware is justified. That being said, the entire point of the original article was to prove that there's NOT THAT much magic behind F5 hardware to justify the price tag. Accelerating SSL isn't rocket science, nor is it some uber-secret. The main point here was an attempt to prove the FOSS can and will do exactly what commercial software and hardware does at a micro-fraction of the cost. As I've said before, in this economy and shrinki

    • A home built solution will only get you fired when something goes seriously wrong.

      If you need commercial support, pay for it, my guess is that it will come to less than 45k

    • F5 is pretty useless too... (Score:5, Insightful)

      by SuperBanana ( 662181 ) on Friday April 17, 2009 @10:42AM (#27614215)

      First off, if I'm handling 25k+ SSL TPS, point blank, I pay the money for an F5. A home built solution will only get you fired when something goes seriously wrong.

      An old boss has spent the last FOUR WEEKS with F5 and Cisco trying to figure out why their F5 load balancer starts dropping ACKS on the floor...at connection rates well under advertised capacity of the particular model in question, which has been in production use for months/year+. How the fuck about that- a load balancer that craps out...under load. How useful. The bug is triggered daily when this particular unnamed CA major internet company hits peak usage in the day.

      At least with the open source community, you can hire someone to look at the code, or report the bug and try and get it fixed by the community. F5 has been completely useless, reportedly.

      • Re: (Score:3, Interesting)

        by Anonymous Coward

        Posting anonymously...'cause I work at F5, 3rd tier support.

        I'd have to say your former boss' experience and opinion are atypical. Our customer sats are *awesome*, and the problems we address are the most complex. Turnaround time for serious bugs is *incredibly* fast. Open Source fast. Enhancements and minor tweaks, maybe never, and yeah, you can't add them yourself. Unless the behavior you want is in packet processing, in which case you can use TCL based iRules to do unimaginably brutal things to your

        • So your answer is, "Our stuff rox, if yours isn't working it's your fault."

          Weak.

          "Your snark is well constructed, but logically inert. F5 stuff handles the biggest loads going. Name a vendor that can compete on pps, thruput or other performance stat. Then show evidence from a repeatable, reasonable test rather than benchmarketing."

          -1, off-topic. (And also -1, marketing.)

          He's not talking about throughput, other than the fact that in his specific case, BIG-IP doesn't have it. Corner case, exceptional case, f

          • Actually his experience is pretty accurate - I used to work as a Tier 3 for a particular enterprise application. I'd tell TAM's and Tier 2's all the time that engineering can turn around fixes rather quickly if we have a test case and some data to go on.

            Sadly our most vocal customers who had cases that would drag on for ages almost always refused to offer data, or give me access to custom applications or workflows so I could reproduce the issue etc.

            All he's saying is - if you cooperate and do what I say - w

            • Re: (Score:2)

              by C_Kode ( 102755 )

              I started this idiot thread and I'm on your side, but being a commodity trading platform, it's not always "ok" to give the access they (F5 or whoever) ask for. So to that point, I understand.

              Still, if I need that type of performance, I go F5. If you are having major issues with F5, chances are it's your network that is the problem and not the F5. F5 works period. Sure there are some things it has issues with, but nothing is perfect. If it doesn't work with F5, I'm not going to roll my own unless it's t

          • "integrated in a meaningful way" isn't particularly meaningful, except in a market-buzzword sense. Care to cite concrete examples of how integration improves throughput in BIG-IP products?

            How about FTFA:

            "Chaining proxies incurs latency at every point in the process. If you chain proxies, you are going to incur latency in the form of:

            * TCP connection setup and teardown processing
            * Inspection of application data (layer 7 inspection is rarely computationally inexpensive)
            * Execution of functionality (caching, security, acceleration, etc...)
            * Transfer of data between proxies (when d

        • Turnaround time for serious bugs is *incredibly* fast.

          Uh huh. After being given pcap files/traffic graphs/response time graphs, F5 said it was a known bug and fixed in a certain release.

          So they did an upgrade through change control, rolled it out. Absolutely no difference. That's when F5 started claiming that it wasn't their fault.

          The interesting bit is that the bug very closely resembles a 1-2 year old FreeBSD bug...how about that, huh?

  • Of course I could produce something similar (Score:5, Informative)

    by russg ( 64596 ) on Friday April 17, 2009 @10:37AM (#27614087) Homepage

    Let me first state that I over see a large deployment of F5 systems and I have compared commercial offerings in this space many times over the years. I have a deep understanding of the tools available and see the work product every day.

    Both articles are great for debate. Showing that FOSS and tools available could produce a solution that resembles a commercial product is wonderful in promoting the power and breadth of FOSS. F5's response is good but also a bit disappointing as I find they have much more than is covered in their response.

    I'm honestly surprised that F5 responded at all as there's really no comparison between the solutions for real world work loads and support. First and foremost is the thought that these are only load-balancers. The term used most appropriately today is "ADC" (Application Delivery Controller). The reason is that they not only perform load-balancing but reverse proxy cache, compression, acceleration, tuning, and in-stream logic decisions.

    F5's products allow you to create profiles for services that are reusable and easy to maintain. You can deliver new configurations in minutes. They also work with the major application vendors to produce proper configurations that you can use out of the box. iRules (TCL) is an awesome tool directly integrated into the product that as F5's tag line says, "With iRules you can". Even with all of the this power and robust tools you will see little or no impact on high performance applications.

    F5 also offers the community DevCentral which, in my opinion, gives back to the community in a proper FOSS style.

    I won't even go into the underlying architecture such as the TMM kernel and separate management kernel.

    F5's article does state one thing very clear and I would want to emphasis it. Humans cost far more over time than capitol expenditures.

    I believe that F5 has taken FOSS to proper pedestal in the industry. If anyone thought for one second that FOSS was toys and not to be considered for serious work loads then F5 proves them wrong. Cisco has been trying to chase F5 for years and are still nowhere near them. F5 systems are my swiss-army knife of networking and I'm proud to purchase and use them from my FOSS background but also know they save my butt every day.

    • Re: (Score:3, Interesting)

      by Jah-Wren Ryel ( 80510 )

      I'm honestly surprised that F5 responded at all as there's really no comparison between the solutions for real world work loads and support.

      Me too. If anything, making a defensive response like that is going to lend credence to the other side of the argument. People who know what F5 does don't need to be convinced, but those don't know are now thinking "hey, F5 is afraid of this." Seems like bad marketing to me.

  • Why even bother with SSL? If your main audience is the web crowd, you can simply use something like aSSL [http://assl.sullof.com/]. Then transfer statically encrypted content via http. This does work for most but not all. I know I'll get flamed to death, but I just filed for a patent that addresses the Achilles heal of aSSL - man-in-the-middle attacks.

  • Right tool for the job^H^H^H company (Score:3, Insightful)

    by neurovish ( 315867 ) on Friday April 17, 2009 @12:33PM (#27616641)

    If a site is big enough that it really needs the performance/scale of such an F5 appliance, then the price tag is not that great and likely reflects .001% of the IT budget or less. Some shops will be better served with the cheap OSS solutions, and others would blow one up fairly quickly. If you blow it up fairly quickly and the $50k price tag is also hard to justify, then your cost of doing business is severely out of whack.

  • Marketing barrage (Score:2, Insightful)

    by jlmale0 ( 1087135 )
    Simply enough, they're firing back because with the popularity of slashdot, now every time some manager goes to scope out Big-IP or their 6900 the slashdot discussion and the original project will rise to the top of the search results.

    Big IP isn't worried about this home grown solution, because in the end, businesses buy warranties, maintenance and upgrade paths. Something the FOSS solution doesn't have prepackaged.

    Enjoy o3's article; it's a great project. Have fun building it, but don't take offense
  • The guy from F5 is a jackass. He basically turned what was a reasonable article that did no bashing of their products into a big deal. He rehashed all the tired old arguments against open source software "Single vendor" "support" "Admin overhead" .... blah blah blah. We know! We've heard it all before..

    F5 makes great devices but not everyone can afford them, so this article showed how you could achieve most of the same results with open source software. I've used the BigIP and I liked working with it.

    • cbreaker,

      The 6900 does not have a white box hardware equivalent. You will just have to take my word for that.

      Much more importantly that duct-taped baby is NOT actually doing the same things. The fact that seemingly intelligent people in the /. community don't grasp that might be why this person decided they needed to rebutt the article

      Oh and btw you're so totally busted- we all know you didn't even read the blog or you would know that LORI isn't a GUY. :)

      • I did read it. I didn't pay attention to who wrote it. Sue me.

        I didn't have to read every detail because I'm already familiar with most of that software.

        You obviously have a predisposition against open sourced software solutions because of your derogatory statements like "duct-taped baby."

        It's semantics. Okay, so under the hood it works differently. But the net result is similar with a full solution (not just the SSL accelerator part) - load balancing, offloading, caching.. If you wanted to, you could

  • The writer of the article response to Lori's claims

    http://o3magazine.blogspot.com/2009/04/ssl-accelerator-strikes-nerve-with-f5.html [blogspot.com] ...and nails her on a few I'd say.

Slashdot Top Deals

Wherever you go...There you are. - Buckaroo Banzai

Close