[c-nsp] Replacement for Cisco ACE load balancers

[Matthew Huff]

Heh. I hate the ACE gui mode. I think I used it once...

L2 load balancing is a big plus for us. We are currently using the ACE with inline mode (L2 bridging). Most of our traffic is not
HTTP, but a combination of internal application and commercial ones (Exchange, etc...), so some HTTP, but not a majority.

----
Matthew Huff             | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC       | Phone: 914-460-4039
aim: matthewbhuff        | Fax:   914-460-4139


> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Phil
> Mayers
> Sent: Monday, February 04, 2013 1:10 PM
> To: Chris Marlatt
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Replacement for Cisco ACE load balancers
> 
> On 04/02/13 17:56, Chris Marlatt wrote:
> 
> > The Foundry/Brocade ServerIron's/ADX line work's quite well in a L2 or
> > L3 environment without NAT or being in-line. Enabling DSR (direct server
> > return, in an L2 environment) means the LB doesn't have to be within the
> > path of the normal switching/routing and their ADX line has support for
> > true multi-10Gb throughputs. DSR also means you're not burning up the
> 
> Interesting. Is it particularly / prohibitively expensive? Several other
> vendors hinted that a 10gig SLB device was "way out of proportion to our
> needs" and "very expensive".
> 
> > "Application Throughput" limits of the device on other traffic patterns.
> > Stability is stellar when it comes to these units, I've some of my
> > ServerIron 4G's online for over 1,200 days (1,277 and counting) without
> > blinking.
> 
> This is an excellent point. We run several services in DSR mode, which
> the ACE obviously handles fine, and I'd encourage everyone that can do
> this, on whatever platform, to do so.
> 
> However, DSR is fairly simplistic, and requires config on the server
> (provision of the virtual IP) which often can be a pain, depending on
> your platform and level of network/server team integration.
> 
> We also find that port rewriting, SSL termination and header/cookie
> insertion are pretty common requirements, which pretty much means inline
> (either on packet path, or source NAT to direct return traffic back to SLB).
> 
> > Each vendor has it's strengths and weaknesses and whereas I'm quite
> > pleased with the Foundry/Brocade models the only area I would say they
> > need work in a robust API interface to help automate changes. However
> > they have made recent improvements in their multi-tendency support.
> 
> One thing I will note - the Cisco ACE management product (ANM) is... not
> great, to put it politely. If GUI management is a concern, then factor
> that in ;o)
> _______________________________________________
> 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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5339 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20130204/da72f982/attachment.bin>