[c-nsp] Cisco load balancers with SSL offload

[Tom Sands]

We use the CSS extensively (almost 1,000 deployed) and while we have 
some minor issues from time to time, they are pretty reliable, feature 
rich, support SSL, and are very cost competitive (especially if you are 
trying to compare to an F5).

We've also tested the ACE, and have several in production.  It's going 
to be a definite upgrade from the CSS when some of the little kinks are 
worked out.  We are currently using their 6500 module, and have the 
actual appliance that is going to be released in testing.  There are 
some nice features that are coming on them.



------------------------------------------------------
Tom Sands			  				
Chief Network Engineer				
Rackspace Managed Hosting	    	
	   	
------------------------------------------------------

R.L. Nevot wrote:
> 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/
>>
> _______________________________________________
> 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/
> 


Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace
Managed Hosting. Any dissemination, distribution or copying of the enclosed
material is prohibited. If you receive this transmission in error, please
notify us immediately by e-mail at abuse at rackspace.com, and delete the
original message. Your cooperation is appreciated.