Re: [load balancing] Verisign and Load Balancers

From: KJ & JC Salchow (
Date: Fri Feb 16 2001 - 22:27:37 EST

  • Next message: tony bourke: "Re: [load balancing] Cascading switches off of a Foundry switch"

    ----- Original Message -----
    From: "Alex Samonte" <>
    To: <>
    Sent: Friday, February 16, 2001 6:27 PM
    Subject: Re: [load balancing] Verisign and Load Balancers

    > The new 600 card had to go to a SMP box (finally working SMP in F5's
    > BSD code!). But you're still going to max out your cpu's
    > and impact normal HTTP performance.

    Not entirely true, the 600 card (and multiple cards) will run on the v3.x
    which does not have SMP. And you're not going over the CPU's performance -
    see below.

    > This is a recent code fix they did. Unfortunately, the F5 itself can't
    > much more than 200 conn/s anyways. The rainbow cards do not do the bulk
    > encryption/decryption of packets. That's left for the general purpose
    > CPU to do. At 200 conn/s the F5's cpu is pegged at 100% utilized.

    There are Rainbow cards which do bulk encryption, the reason most people
    don't utilize them is because the bulk encryption is generally RC4 which is,
    by design, built to be fast and efficient as a software implementation -
    whereas the RSA encryption used in the asymetric key exchange is fast and
    efficient in straight hardware. If you look at the stages of SSL, the bulk
    encryption is not difficult or processor intensive - it's essentially a
    onetime pad cipher - which equates to simple substitution cipher with a
    unique key at least as long as the message to avoid repitition. This is not
    tough - programmatically or processor wise. That's what makes PGP such a
    great system - it uses the RSA for the transmission of the onetime pad
    cipher and then uses that to perform bacis substitution. Yes, I know this
    is a little simplified, but its accurate enough to argue the impact of bulk
    encryption on the processor. If it weren't for the asymetric key exchange -
    the part everyone is off loading - SSL would have almost no impact on the

    As to handling more than 200 conn/s - I've never seen an F5 box that I've
    worked on or supported at more than 54% processor utilized no matter what
    they were doing. Most of the real work on the BIG-IP revolves around
    memory, not processor - and when compared to the other "general purpose
    processors" I'd much rather have the F5's Pentium III than the ones used by
    Alteon, Cisco or Foundry. Which brings us back to the SMP. With v4.0 F5
    will be on the "unified" BSD kernel which will support SMP. And I'm sure
    I'd rather have dual PIII 890's than anything anyone else has. I also
    question the 100% processor utilization because most people will test their
    SSL tps by doing nothing but flooding a box with NEW SSL sessions - NEW
    sessions means NEW keys which are offloaded to the Rainbow card. I have a
    hard time believing that the F5 box hits 100% utilization doing nothing buy
    handing off SSL handshakes.

    > And you also want it to handle all your non encrypted load balancing too.
    > Not much CPU left for that.

    And this again depends on what else you are doing. Is all your
    non-encrypted traffic doing header parsing? That will eat up more CPU than
    handling the SSL handshakes and bulk encryption - but again - the F5 has the
    right processor for the job which is why their throughput doesn't degrade at
    Layer 7 like most other products. RSA is off-loaded and bulk encryption is
    easy - heavy header parsing or extremely complex rule-sets can and will eat
    up the processor quickly - but this is an administrative issue as well. If
    you write your rules correctly and plan ahead, you shouldn't need overly
    complex rules.

    > It's a serious flaw in having the SSL accelerator inline with all of
    > your non SSL traffic.

    No this I can agree with. Even with the F5 box there is a limit to the
    amount of SSL you can handle from a pure NEW connections per second rating
    on the Rainbow cards and by having them directly inline with the rest of
    your site does present some scalability issues. That's why many people use
    stand alone SSL (which F5 has as well) being load balanced calling back to a
    load balanced VIP (I think in another message you demonstrated this in the
    "one-arm" fashion - I would use a three interface BIG-IP to avoid sending
    traffic accross the internal interface as many times - the same thing I do
    for server-side cahces). In fact, in another life we actually had different
    paths for encrypted and non-encrypted traffic. This served to keep us
    mindful of what was on the wire as well.

    On the other hand - how many people are doing that many NEW SSL sessions per
    second? This is another of those sticky litle requirement issues that seems
    to crop up. You do NOT need to support 1000 NEW SSL session/second just
    because you have 1000 users using SSL. This is about as bad as the people
    who use load balancing for their Internet servers and swear they need Gig
    throughput - even though they only have a T1 to the Internet.

    Lastly, doing the SSL at the LB puts the encryption domain as close to the
    server without impacting the ability of the LB to make intelligent decisions
    on encrypted as well as non-encrypted traffic. Putting SSL in front of the
    LB increases the amount of time sensitive information traverses the network
    in clear text. Believe it of not - this bothers some people.

    > -Alex

    P.S. I don't disagree with everything you said - that's why I picked out the
    pieces. :-) Thanks for the conversation.

    This archive was generated by hypermail 2b30 : Fri Feb 16 2001 - 22:28:19 EST