[c-nsp] Cisco load balancers with SSL offload

[R.L. Nevot]

IMHO, I'm not a big fan of cisco in this kind of questions.
You may take a look for F5 networks (6400) or maybe Juniper DX

I have bad experiences with CSSs and CSMs, but not tested ACEs

Regards.

On 4/16/07, Gert Doering <gert at greenie.muc.de> wrote:
>
> 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
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>