best practices...ACE

[mohsin.khan]

I am trying to get myself familier theoratically with ACE before actual deployment, so here are some questions...

First, we often hear the term offloading the SSL to ACE, to make it work on L7 and make decision based on header, quesion arises as to how simple is this to work on ACE at Layer 7 rather than on layer 4? Is it really worthit to go for it, and in which scenarios?

Mutliple Contexts, is there any central way to measure the overall resource consumption done by all/selective context? what are the benchmarks/limitations (not just the count) for ACE module for 6500? Is it prductive/or wast to have FT for each context, or FT is one per box?

Howuseful it is to have http over ssl (i know it depends on requirement, need to know the impact on the box itself)

TCP Reuse, Persistant LB & Header Insert, can these features be used in L4 model, or is it really L7 thing?

Can a single context of ACE be used for multiple contexts of a boundry ASA (i don't know why i am asking for this)

[Syed Iftekhar Ahmed]

SSL offloading is not just needed for making L7 based decisions but is also beneficial

for performance & certificate management.

* On Web Servers typically native SSL processing happens in Software (unless they are using SSL acceleration cards)

, as a result they handle fewer requests, will have far slower response time, and significantly decreased total throughput.

* SSL processing is computationally intensive, SSl offloading takes the SSL processing off the Web server

* Since the back-end WEb/App servers do not need to process any encrypted data,

they more effectively serve data or run applications.

* Overall certificate Management gets easier

(as you have to deploy/renew only one cert, versus N certs for N servers)

With Load balancing SSL traffic using Layer 4 parameters you can ensure persistence only by using

"Source IP" or "SSL ID" (the unencrypted fields).Source IP based persistence is not recommended if Mega Proxies are used.

SSL ID based persistence is not reliable as some IE browsers renegotiate it during a session.

The only viable option is to use cookies/Header values to stick client to a single server during

a session. If SSL offload is not configured, a loadbalancer cannot read the headers and cannot ensure

persistence (if IP based persistence is not an option).

Similarly there are scenarios where you want to make decisions based on L7 based info and due to encrypted traffic

LoadBalancer cant read the headers. For e.g lets suppose you are running an internet facing application in 3 languages,

If the loadbalnacer can read header (SSL offloading in place) it can select Server-X dedicated

for language X and Server-Y for language-Y requests. There is a lot of valuable information in Headers which Loadbalancers

can look and utilize. If the traffic is encrytpted & SSL offloading is not in place, it wont be able to make "Intelligent decisions".

"show resource usage" will give you resources used each context.

One FT link is used for all contexts. Each context uses the same link.

Withing configuration you can select which context will be active on which ACE peer.

Any feature that utilizes TCP fields are L4 & any feature that goes beyond that can be called L7

Persistence can be L4 ( Source IP) 0r L7 (cookie, headers..)

Header Insert is Layer7 (You are opening the header)

You can share ASAs inside with multiple ACE contexts. (Not true for FWSM).

HTH

Syed Iftekhar Ahmed

[mohsin.khan]

Great stuffed, Pawned :),,, thanks...