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 <[EMAIL PROTECTED]> 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 > [EMAIL PROTECTED] > fax: +49-89-35655025 > [EMAIL PROTECTED] > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
