[c-nsp] Cisco load balancers with SSL offload

[Gert Doering]

Hi,

thanks a lot to all who answered.  

Indeed, there is lots of different variants to choose from...

(I assume that both the CSM and the ACE can do SSL "out of the box", and
you just need to have the right license, that is, "don't buy extra 
doughter cards"?)

To answer a few of your questions:


On Mon, Apr 16, 2007 at 10:00:00AM -0500, James Slepicka wrote:
> We're doing SSL termination on CSS11503s (available on the 11501S-C and 
> above).  The 11503 is modular and price can vary greatly based on 
> config, so I won't toss out any numbers.
> 
> After a few tweaks to solve poor performance issues (ssl-queue-delay, in 
> particular), I've been pretty happy with them.  I'm curious to know, 
> aside from the fact that it's an aging platform, why you're not.

Well, the customer setups that we maintain for them are only using older
models, like the CSS11150 - which *is* an old box.

My main gripes with it is:

  - not very powerful (read: they are maxing out the box's CPU at below
    70-80 Mbit/s)

  - no SSL offloading (Cisco used to sell a separate box for that)

  - no useful way to figure out what the box is doing - like "*why* is 
    your CPU at 100%?  How many sessions/seconds?  bits/sec? ..."

  - convoluted way to get outgoing NAT to work


> p.s. -- Though I have limited experience with them, I'd recommend 
> staying away from the Radware boxes.  We, and the Radware tech we had 
> installing them, ran into tons of problems.

Haven't considered those :-) - but thanks for the warnings.

(Regarding Citrix Netscalers: they *have* some icky corners, but most
of their behaviour is fairly well documented, and what I love most is
their tracing capabilities - like "monitor *this* interface for *x*
seconds and then give me a pcap file with the packets in it")


On Mon, Apr 16, 2007 at 04:53:34PM +0100, Phil Mayers wrote:
> If you can talk about it, I'd be *very* interested to hear about the 
> Foundry problems - though I know you said don't ask!

Our main problems with those (*different* customer) is that you can't
do useful SSL offloading for multiple different domains without ending
up with a very convoluted configuration both on the Foundries and on
the server.

That is: the customer has www.<customer>.de, .at, .ch, .nl, ... and you
have a different certificate + IP address for it.  So far, no problem, but
when trying to define backend servers (services) to balance the requests
*to*, you can't use the same port number on the HTTP server.

So you end up balancing .de to port 80, .at to port 1080, .ch to port 2080,
... on the backend machines - which makes "add a new TLD" a real nightmare
(*and* you need to have health checks on every single port, otherwise there
is no way to make the box stop balancing .at to a given backend server
even when it already noticed that port 80 = .de is dead).

The second issue we have is that cookie based persistance doesn't seem
to work for SSL sessions (we received a configuration fragment for that
from foundry last week, but it means "rewrite all our config", so we
couldn't test that one yet).


gert

-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de