Slashdot Mirror

← Back to Stories (view on slashdot.org)

F5 Fires Back On Open Source SSL Accelerator

Posted by timothy on 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."

83 of 120 comments (clear)

  1. Less expensive alternatives to F5.... by AbbeyRoad · · Score: 1

    Try protobalance.com

    1. Re:Less expensive alternatives to F5.... by Darby · · Score: 1

      http://kemptechnologies.com/

      Happy customer.

  2. How is that different from F5? by Anonymous Coward · · Score: 2, Interesting

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

    1. Re:How is that different from F5? by Anonymous Coward · · Score: 2, Insightful

      And custom software and encryption accelerator cards.

    2. Re:How is that different from F5? by Script+Cat · · Score: 5, Funny

      I once worked on binary load lifters which are very similar to your F5 load balances in many respects.

    3. Re:How is that different from F5? by psydeshow · · Score: 1

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

    4. Re:How is that different from F5? by idontgno · · Score: 1

      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

      --
      Welcome to the Panopticon. Used to be a prison, now it's your home.
    5. Re:How is that different from F5? by gavint · · Score: 1

      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, other software, support and testing. Obviously there is also some profit, as you can see from their accounts, but if people thought this was unreasonable they would buy an alternative - there are plenty out there.

  3. Shill by LordKazan · · Score: 1, Interesting

    Shilling much?

    --
    If you cannot keep politics out of your moderation remove yourself from the Mod Lottery.. NOW!
    1. Re:Shill by drinkypoo · · Score: 1, Troll

      The parent has a point; this response is not only predictable, but precisely the same kind of FUD 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.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    2. Re:Shill by RiotingPacifist · · Score: 1, Troll

      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.

      --
      IranAir Flight 655 never forget!
  4. Re:Win by Midnight+Thunder · · Score: 1

    'cobbled together set of components designed to mimic similar functionality.'

    And in certain cases do a pretty darn good job of it. Just don't expect us to be there 24/7, since the developers might be in a different time zone.

    --
    Jumpstart the tartan drive.
  5. Why by jgtg32a · · Score: 1

    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.

    1. Re:Why by Anonymous Coward · · Score: 1, Insightful

      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

  6. Re:Nothing wrong with cobbled together by backwardMechanic · · Score: 1

    I thought "integrated solution" was business speak for "cobbled together"? You mean there's a difference?

  7. Re:Win by corsec67 · · Score: 1

    But, if you had a few developers spread out (say Europe, USA, and Japan) in enough time zones, you could have 24/7 support.

    --
    If I have nothing to hide, don't search me
  8. Common response by Lord+Grey · · Score: 3, Interesting

    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.

    --
    // Beyond Here Lie Dragons
    1. Re:Common response by spinkham · · Score: 2, Insightful

      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 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.

      --
      Blessed are the pessimists, for they have made backups.
    2. Re:Common response by 222 · · Score: 2, Informative

      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 measure, but SSL offload is just an added benefit.

    3. Re:Common response by Dare+nMc · · Score: 1

      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 hand) linux based system 8 years ago over a big iron system. But you know what, that allowed us to learn to support/test our own system, and look through the FUD that any "Big Iron" sales person will fling your way. Now that this updates to the linux system are more "supported" than the big Iron servers (Home office bought the big iron system, it now has less features, and in order to catch up they have to keep buying upgraded software, hardware, and licenses...)
      So if you hold onto your employees, your company will likely be better off with any system they are allowed to use/touch/change, than one they pay for and forget about until something changes, and don't be surprised if you scramble to get a response like "we don't support that on the box you have anymore, here buy the new more expensive one".

    4. Re:Common response by Mr.+Sanity · · Score: 1

      ...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.

    5. Re:Common response by 222 · · Score: 2, Interesting

      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

      You also might want to look at this discussion; its not directly related but has some good commentary:

      http://ask.slashdot.org/article.pl?sid=02/06/26/2026217

    6. Re:Common response by Raenex · · Score: 1

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

    7. Re:Common response by Burkin · · Score: 1

      Because it's easier to attack someone when you take the quote you want out of its context?

    8. Re:Common response by Bert64 · · Score: 1

      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.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    9. Re:Common response by zyzko · · Score: 1

      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't hire a full time admin. But as with SAN/NAS boxes SSL accelerators are not excatly very complicated - a sysadmin with few years experience can get a grip of a homegrown solution within days (without manufacturers expensive training courses).

  9. Re:Nothing wrong with cobbled together by lawaetf1 · · Score: 2

    Yes, usually $30k or more in difference.

    --
    CommentBot 0.7a running with args "-module irritate,disagree -target random"
  10. Justifying the Price Tag, nothing more... by geekmux · · Score: 5, Insightful

    Finally, someone who isn't a raisin sack aptly describes all of FOSS: 'cobbled together set of components designed to mimic similar functionality.'

    Ah, FOSS may be cobbled together at times, and it also may be as polished and clean as many commercial apps, but it still does not erase the bottom line that F5 is still charging an asinine amount of money for their hardware. And in this economy, the financial bottom line tends to speak volumes over F5 coming out and trying to justify their price tag with a weak "yeah, but yours sucks" argument.

    This reminds me of my first time opening up the lid on a $30,000 Nokia Firewall-1 rack-mount firewall "appliance". They wanted to sell me a $2000 "upgrade". When I slid the mobo out of the fancy chassis, I found I was staring at a generic Intel mobo with a slot-1 celeron proc and 64MB of SDRAM. I then found out that the $2000 "upgrade" was merely a Pentium Proc and 256MB SDRAM stick. Needless to say, I've been rather tainted with justification for commercial hardware.

    1. Re:Justifying the Price Tag, nothing more... by Zeinfeld · · Score: 1
      At $50K, the F5 offering is hardly going to save anyone much in the way of SSL certs.

      But a lower cost open source accelerator might well do so. Offloading the RSA operations to a server farm makes excellent sense. But what might well make a lot more sense is to find a way to use graphics processor cards as SSL accelerators. They are not purpose designed but they are made in vast volume and contain all the parts for a vector processor machine.

      A machine that sells a thousand units a year is going to be a lot more expensive price/performance wise than one based on a chip that sells by the hundred million.

      If I was starting out 18 months ago I might well think of building something like that. But I strongly suspect that we will see several products of that type being announced next week at RSA.

      BTW before folk start accusing me of shilling for my employer, I no longer work there. I am now spending my time making podcasts (see http://quantumofstupid.com) and building daleks in my basement. p Just burning a podcast on Ubuntu at the moment which should be up in about an hour and will be putting together a podcast to handicap and explain the prospects of interesting announcements at next week's RSA cryptographers panel later on today.

      --
      Looking for an Information Security student project suggestion?
      Try http://dotcrimeManifesto.com/
    2. Re:Justifying the Price Tag, nothing more... by russg · · Score: 1

      I don't understand your argument. You want to say that the vendor used off the shelf components and imply that for this reason the application wasn't worthy of the costs? In reality the hardware is a very small cost compared to the application development and maintenance. I'm so happy that vendors have been steadily moving to commodity hardware since I date back to years when special built hardware was the norm and it was an enormous cost.

    3. Re:Justifying the Price Tag, nothing more... by Dr_Barnowl · · Score: 1

      I think he was more miffed about being asked to shell out $2000 for about $300 of components.

      It's better than the rates that IBM used to charge to send an engineer to snip a single wire link, but not much better.

    4. Re:Justifying the Price Tag, nothing more... by LordLimecat · · Score: 1

      Part of his complaint seems to be that while it may be fine to pay boatloads for the device because of an OS, its a bit lame for the vendor to then use the situation to try to make ridiculous profits on the extras that DONT have those R&D costs.

      I would feel its less of an issue when there arent licensing restrictions that prevent you from doing the hardware upgrade yourself, and it would be excellent if NAS | Firewall | router | etc vendors were willing to sell you support and a bootable flash card containing the OS, as well as having the option to buy the appliance. Then they could charge whatever fee helps them to turn a profit, and WE could worry about the hardware costs.

    5. Re:Justifying the Price Tag, nothing more... by Fulcrum+of+Evil · · Score: 3, Interesting

      But what might well make a lot more sense is to find a way to use graphics processor cards as SSL accelerators.

      Stick a GTX250 in your server and use a CUDA enabled RSA codec and you're set.

      --
      "We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
    6. Re:Justifying the Price Tag, nothing more... by AmiMoJo · · Score: 1

      The only real difference between FOS and commercial software, from a purely business point of view, is the support available.

      With commercial software you get masses of marketing bullshit and a hotline to India if anything goes wrong. With FOS you get to choose your own support people, quicker fixes for security problems and the option to pay someone to add any feature you like.

      Unfortunately, the latter transfers responsibility on to management who can no longer just blame the vendor. It's harder to purchase too because it doesn't come with a glossy brochure.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    7. Re:Justifying the Price Tag, nothing more... by afidel · · Score: 1

      You could EASILY save $50k on cert's considering an EV cert is ~$1K/server/year, if you have a few dozen domains and a handful of servers being load balanced then over the three year (conservative) life of the device it could save you money. If you have a large LB farm it's pretty much a no brainer. Of course there are few organizations that buy a BigIP just to save on SSL certs, they are usually bought to allow a scalable, reconfigurable, dynamic farm of servers to handle high traffic loads.

      --
      There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
    8. Re:Justifying the Price Tag, nothing more... by Bert64 · · Score: 1

      A lot of commercial appliances these days are also a bundle of OSS code with a fancy frontend slapped on top and as you pointed out, installed on bargain basement hardware.
      Some of these companies are up front about it, and you're paying for the support package... Others actually try to hide the true nature of their appliances.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    9. Re:Justifying the Price Tag, nothing more... by Bert64 · · Score: 1

      A lot of these vendors nowadays use not only commodity hardware, but rebranded OSS software on top of it...
      How many of these appliances are based on Linux or BSD?
      A lot are also based on quite old versions, and the vendor specific updates tend to trickle down a lot slower than upstream patches do...
      Quite often you just don't get value for money at all, you receive commodity hardware and free software and pay a premium for it.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    10. Re:Justifying the Price Tag, nothing more... by idontgno · · Score: 1

      How many of these appliances are based on Linux or BSD?

      Well, ironically (and yet apropos at the same time), F5 BIG-IP products. (Currently, Linux; in an earlier incarnation, they ran BSDi; the organization I worked for had a few of these installed at that time.)

      --
      Welcome to the Panopticon. Used to be a prison, now it's your home.
    11. Re:Justifying the Price Tag, nothing more... by MassacrE · · Score: 1

      How would an accel. save you a dime on certificates?

    12. Re:Justifying the Price Tag, nothing more... by mother_reincarnated · · Score: 1

      Technically you only need one (pair) of real certs since your servers won't be talking SSL to browsers.

      How that translates into ROI is between you, your 0 or more diet[y|ies], and your CA...

  11. You must be smart when buying these things by C_Kode · · Score: 4, Insightful

    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.

    1. Re:You must be smart when buying these things by RiotingPacifist · · Score: 1

      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

      --
      IranAir Flight 655 never forget!
    2. Re:You must be smart when buying these things by Bert64 · · Score: 1

      So the commercial offerings can and do fail as well...
      With your own OSS based setup you have a chance of fixing it, with a commercial setup all you can really do is cast blame, but how exactly does casting blame help you get real work done?

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
  12. Re:Win by sqlrob · · Score: 4, Insightful

    'Cobbled Together' describes most proprietary development as well.

  13. Re:Win by janeuner · · Score: 2, Insightful

    'cobbled together set of components designed to mimic similar functionality.'

    http://en.wikipedia.org/wiki/Object-oriented_programming

  14. CHAINING PROXIES vs INTEGRATED SOLUTIONS by RiotingPacifist · · Score: 3, Insightful

    I'm a huge fan of chaining proxies, one program doing one thing then passing it on to the next, for the security, compatibility & debugging (contrary to what TFA say's you can check the pieces of a chain, but with an integrated solution you can't) benefits. The article does however raise a good point, the integrated solutions will have better performance:

    # TCP connection setup and teardown processing
    # Inspection of application data (layer 7 inspection is rarely computationally inexpensive)

    Which means you'd have to consider the options carefully when looking for an accelerator

    --
    IranAir Flight 655 never forget!
  15. Re:Win by fuzzyfuzzyfungus · · Score: 4, Insightful

    Ah, but it is harder to see the cobblers, so it must be better.

  16. Proving a (price) Point... by geekmux · · Score: 2, Insightful

    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 shrinking IT budgets, I'm finding it harder and harder to justify uber-elite solutions with obscene price tags.

  17. Re:Win by hackus · · Score: 4, Interesting

    It is even worse than that I am afraid.

    Most commercial products do not even have a dividing line between "cobbled" and "polished" now days.

    How many different commercial off the shelf Wireless AP's now days come with "cobbled" open source software?

    I do not mind paying for software, I do. I just do not like companies that rip off the open source community, then whine and complain when their proprietary code is leaked to the net and it is a crime along with prison and fines, if you touch our code. Apparently you can do anything you like with GNU software.

    I want to see Cisco execs in jail like the Pirate Bay people. Unlike the Pirate Bay people though they are actively making a direct profit from breaking the law.

    5 years in the pen along with 50 Million put in a trust to start and fund more open source projects. Preferably building open wireless drivers for more cards.

    http://www.guardian.co.uk/technology/blog/2008/dec/12/cisco-fsf-opensource

    -Hack

    --
    Got Geometrodynamics? Awe, too hard to figure out? Too bad.
  18. Of course I could produce something similar by russg · · Score: 5, Informative

    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.

    1. Re:Of course I could produce something similar by Jah-Wren+Ryel · · Score: 2, Interesting

      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.

      --
      When information is power, privacy is freedom.
  19. SSL on a USB keychain device? by coryking · · Score: 1

    Is there any reason you couldn't put an SSL accelerator on a USB device? Lots of servers have a ton of unused USB ports sitting around. If you could make it USB, you wouldn't have to rip open the web server/reverse proxy server to install it. Sure somebody might walk off with the device, but if you can mitigate that somehow, is there anything technically wrong with the idea?

    1. Re:SSL on a USB keychain device? by Mr.+Sanity · · Score: 1

      If your appliance can handle having the SSL ops throttled to USB 2.0 bandwidth levels, then odds are, you don't need something like an F5. If your question is aimed more at doing this for a small operation, then it may be feasible. But in that situation, the server acting as a load-balancer probably has the cycles to spare to do it on one of its cores.

    2. Re:SSL on a USB keychain device? by Kaboom13 · · Score: 1

      USB is slow, and is CPU dependent. What you gain in offloading the ssl to an usb device you would lose a decent chunk of to USB overhead. USB is the redheaded step-child of the server world for a reason.

  20. F5 is pretty useless too... by SuperBanana · · Score: 4, Insightful

    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.

    --
    Please help metamoderate.
    1. Re:F5 is pretty useless too... by Anonymous Coward · · Score: 3, Interesting

      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 packets. So most of the flexibility argument is moot.

      Without knowing your former boss's case, I can't address it directly. In my own experience, cases drag on when it is difficult to gather the data necessary to show the problem. Often the customer is the bottleneck, and this tracks with customer attitude. The less cooperative and helpful tend to be the least patient as well. "I can't get you tcpdumps! Fix it!" It is also often the case that F5 gets blamed because we're more responsive than the other vendors in the equation and the customers can at least talk to someone.

      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.

      If what you need is simple load balancing, you don't need F5. Many situations require more. And yes, the F5 solution is more integrated in a meaningful way than a chain of separate proxies.

    2. Re:F5 is pretty useless too... by idontgno · · Score: 1

      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, freak accident? Sure. We'll stipulate that. But also valid. Statistical evaluation is the tool of marketing. The current, real-world, bare-metal case at hand is reality. "It usually works" is unacceptable. "It works for everyone but you" is even worse.

      If what you need is simple load balancing, you don't need F5. Many situations require more. And yes, the F5 solution is more integrated in a meaningful way than a chain of separate proxies.

      "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?

      Now, all that said, I generally like F5 products. I've been in large military data centers where the load-balancer of choice was BIG-IP, and almost always it worked out well. Performance was good, reliability was good, and it certainly made DoD PKI easy to deploy.

      But your response would have been completely unacceptable if we had a problem with our F5 products and you were handling our case. Entirely blaming the customer for the joint (customer and tech) inability to resolve a crippling problem is just wrong.

      --
      Welcome to the Panopticon. Used to be a prison, now it's your home.
    3. Re:F5 is pretty useless too... by Skuld-Chan · · Score: 1

      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 - we can fix stuff fast, but if you like to dick around - have fun.

    4. Re:F5 is pretty useless too... by bernywork · · Score: 1

      "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 deployed on the same device this is minimized)
              * Multiple log files
      "

      Simply, going from kernel memory to user memory doing the work, back to kernel memory (For the IP stack), back to user memory, back to kernel memory, back to kernel memory (Hang on, where was I?) That's right, I was running around all over the place causing latency, lets not forget that writing IO takes CPU time, as the article stated TCP connection setup and tear down and everything else, and it's going to add latency and thus decrease the bandwidth capability of the box.

      --
      Curiosity was framed; ignorance killed the cat. -- Author unknown
    5. Re:F5 is pretty useless too... by C_Kode · · Score: 1

      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 the only option. I seriously doubt that will be ever the case considering the price of an F5 and what is required before I purchase one.

  21. Large volume ETL problem by melted · · Score: 1

    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.

  22. Re:Win by abigor · · Score: 1

    The code used in Linksys routers is available for download. How is Cisco breaking the law?

  23. Re:Win by MikeFM · · Score: 1

    Have you seen non-free code? FOSS may be a cobbled together mess but the vast majority of non-free code is much worse.

    --
    At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
  24. Re:Nothing wrong with cobbled together by blippo · · Score: 1

    It's the margin on selling things to people who should know their job better.

  25. I hate to say aynthing in defense of F5, but: by wsanders · · Score: 1

    > F5 is still charging an asinine amount of money for their hardware

    Actually, you are paying for the software. Plus support. documentation, etc, that is generally OK. If your IT staff is an army of untrained contractors and support contract administrators it is probably worth it.

    But then in a past job I had to stand at attention in front of the CEO and answer the question "WHY THE FUCK DO WE HAVE THESE F5 DEVICES?", and "Because our CIO likes them?" is not really a good answer in a situation like that. So - Am I biased? A tad!

    --
    Give a man a fish and you have fed him for today. Teach a man to fish, and he'll say "WHERE'S MY FISH, YOU IDIOT?"
  26. Re:Win by Wrath0fb0b · · Score: 1

    I do not mind paying for software, I do. I just do not like companies that rip off the open source community, then whine and complain when their proprietary code is leaked to the net and it is a crime along with prison and fines, if you touch our code. Apparently you can do anything you like with GNU software.

    No, you have to follow the terms of the license that the creators voluntarily agreed to.

    I want to see Cisco execs in jail like the Pirate Bay people.

    Did they violate the terms of the GPL. I see their source code posted, so I don't think so ....

  27. Got news for ya pal by Weaselmancer · · Score: 2, Insightful

    Everything made today is a "cobbled together set of components." The chips come from Taiwan or Korea or Germany, the plastic from China, the metal from the USA or pretty much anywhere else...you name it. That's why we have standards - so you can replace one part with another.

    The difference is in the quality of the cobbling.

    And the final proof is in dollars per something-or-other, engineering aside. In this case SSL throughput. Let's see some benchmarks and let's see some dollar signs. Then we'll decide what's useless and what isn't.

    --
    Weaselmancer
    rediculous.
  28. aSSL anyone? by cybernytrix · · Score: 1

    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.

    1. Re:aSSL anyone? by cybernytrix · · Score: 1

      Yes, but there are ways to get around all these problems and still be able to do it! The idea is to use a combination of HTTPS and HTTP wisely so that AJAX requests can be done without the HTTPS overhead. HTTPS is only used once during login.

  29. Right tool for the job^H^H^H company by neurovish · · Score: 2, Insightful

    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.

  30. Marketing barrage by jlmale0 · · Score: 2, Insightful

    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 at Big-IPs defense of their product; they're obligated.

    The best thing to take away from all this, if you're in the market for SSL offloading, is to print out the article and slashdot discussion, pass it to the check-writer and let her use it as leverage to get an additional 5% savings off list.

  31. Re:Win by abigor · · Score: 1

    I did read it. It's all to do with Linksys, which was a Cisco acquisition, and the source has been available for ages. So I'm not sure what the FSF is complaining about - unfortunately, there are no specifics given.

  32. Re:Win by Bert64 · · Score: 1

    The messiest FOSS code i have seen, is where a commercial product has been opened up... Quite often it takes several months of OSS development before the mess can even be compiled - proprietary code tends not to have configure scripts or similar, and is nastily kludged to build in a particular unchanging environment.

    --
    http://spamdecoy.net - free throwaway anonymous email - avoid spam!
  33. Re:Nothing wrong with cobbled together by Bert64 · · Score: 1

    While these "integrated solutions" do have some value inherent in the integration and support, many of them are based on commodity hardware and free software and are massively overpriced... The vendors selling these things don't want people to realise their true value, as it will significantly reduce their profit margins.

    --
    http://spamdecoy.net - free throwaway anonymous email - avoid spam!
  34. Re:Win by abigor · · Score: 1

    I happen to know that code rather well, and it's all there, at least for the routers. Cisco hasn't added anything they haven't released. The existing complaints that I know of (and the ones Google turns up) mostly have to do with build scripts, as what you download can be annoying to build. And it's true that they can be slow to release source when new firmware comes out, but they always do in the end.

    Anyway, the poster above that I initially responded to implied that Cisco has released nothing (false), and wants to see Cisco execs imprisoned (absurd).

  35. turnaround time? Riiiight by SuperBanana · · Score: 1

    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?

    --
    Please help metamoderate.
  36. "Mimic"? It actually DOES it by cbreaker · · Score: 1

    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. Very cool, very flexible devices. Unfortunately, only one out of the last 5 companies I've worked for were able to actually buy one.

    SO, you can put together a solution that doesn't MIMIC the BigIP. It can actually do the same things. Might not be as pretty, but it will work.

    There's going to be some people that think twice about F5 because of this nonsense. I mean, what kind of company lashes out like this for no reason? It makes them sound like crybabies.

    Lower your prices or shut up about it. If you charge $50,000 for a server that can be had for $5000 minus the F5 software and people are buying, then they really don't have anything to complain about. The people the original article was targeted at were not likely to be potential F5 customers.

    --
    - It's not the Macs I hate. It's Digg users. -
  37. Re:Original article was a lame fanboy piece by cbreaker · · Score: 1

    Wow, you miss the point too. The point of the original article was "because you might not be able to afford a BigIP doesn't mean you can't get a lot of the functionality with Open Source software."

    Not "You should use this always." Not "BigIP sucks." You filled in your own blanks - why? There were no blanks to fill in.

    Sure, the open source solution isn't perfect, but it's a decent one if you can't afford a pair of fifty thousand dollar boxes but you want offloading, caching, and load balancing.

    --
    - It's not the Macs I hate. It's Digg users. -
  38. Re:"Mimic"? It actually DOES it by mother_reincarnated · · Score: 1

    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. :)

  39. Re:Win by Jah-Wren+Ryel · · Score: 1

    I happen to know that code rather well, and it's all there, at least for the routers.

    b) Defendant was again distributing a new version of QuickVPN without providing correspond-
          ing source code;
    c) Defendant was distributing executable copies of GCC, Binutils, and GDB in conjunction
          with the Firmware for several of its products (including the WAP440N, WMA11B, WVC54G,
          WVC54GC, WRV200, WAG300N, and EFG120/EFG250) without providing the correspond-
          ing source code to these Programs.

    http://www.fsf.org/licensing/complaint-2008-12-11.pdf

    --
    When information is power, privacy is freedom.
  40. Re:"Mimic"? It actually DOES it by cbreaker · · Score: 1

    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 even put together a DNS failover system in it too. (I always hated the 3DNS though..)

    Personally, I'd go with a more simple solution based on Squid if I needed something to do many of these things and I couldn't afford a BigIP (which most organizations can not) but Squid won't do everything either.

    Besides, what do you think F5 does? The operating system is Linux and they use a lot of open source code in their systems. They just "duct tape" things together better.

    --
    - It's not the Macs I hate. It's Digg users. -
  41. o3 Returns Fire by sarkeizen · · Score: 1

    The writer of the article response to Lori's claims

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

  42. Re:Win by MikeFM · · Score: 1

    Very true. It's often not portable at all. Which is why you'll see a lot of 'Enterprise' software that only runs on a single platform whereas my free open source programs run on all flavors of Windows, OS X, Linux, BSD, AIX, etc. Give me FOSS any day over proprietary crapware.

    --
    At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.