As I understand, the "persistent rebalance" is like KeepAlive. If so, what is the default keepAlive timeout? If someone knows, could you point out the reference/docs?
what platform ? CSS CSM ACE ?
Persistence rebalance means we will inspect all http request inside the same tcp connection and rebalance when needed.
This is not related to any timeout.
As a Cisco employee, you should use internal communication alias !!!!
Exactly when should we enable Persistence Rebalance, and is the behavior
the same between ACE & CSM modules?
We have both on our network.
I read through the config guides for ACE and CSM multiple times, but am still not exactly
sure how they should behave.
It sounds like ACE would send requests to the same destination servers, while CSM would
send them to different ones.
According to the ACE config guide
"Enabling HTTP Persistence Rebalance
With persistence rebalance enabled, when successive GET requests result in load balancing
that chooses the same Layer 7 class in the load-balancing policy, the ACE sends the
request to the real server used for the last GET request. This behavior prevents the ACE
from load balancing every request and recreating the server-side connection on every GET
request, producing less overhead and better performance.
When it is enabled and after a connection is established, the ACE sends all subsequent
requests to the same destination. Load balancing is not involved after the initial
According to the CSM config guide
"Configuring Persistent Connections
Persistent connection support in the CSM allows for each successive HTTP request in a
persistent connection to be switched independently. As a new HTTP request arrives, it may
be switched to the same server as the prior request, it may be switched to a different
server, or it may be reset to the client preventing that request from being completed.
As of software release 2.1(1), the CSM supports HTTP 1.1 persistence. This feature allows
browsers to send multiple HTTP requests on a single persistent connection. After a
persistent connection is established, the server keeps the connection open for a
configurable interval, anticipating that it may receive more requests from the same
client. Persistent connections eliminate the overhead involved in establishing a new TCP
connection for each request."
If you don't know what it does, you probably don't need it.
Usually, you need persistent rebalance if you do stickyness and receive connections from proxy servers (1 connection for multiple clients).
As indicated by the config guide, in case of ACE, if there is no reason to re-balance (no stickyness or sticky info still point to the same server) we do not re-balance.
However, the CSM will always make a new balancing decision even if not needed.
We're in process of migrating from CSM to ACE.
On CSM, persistent rebalance is enabled under vservers by default, so we never bothered w/ it.
Since you need to explicitly enable it using a http map on ACE, we're trying to figure out exactly what it does.
We asked our SE about it once, and he said it's good to have it, so we left it enabled on our CSM's.
We just can't remember all the details.
One of the documents I came across says it only works if we have L7 class-maps.
Is that true?
What if we only have the default L7 class-maps, does that count?
class-map loadbalance CMAP1
"Usually, you need persistent rebalance if you do stickyness and receive connections from proxy servers (1 connection for multiple clients)."
We do use sticky quite a bit, but I am not sure if clients are coming from proxies, like AOL.
Based on the info I laid out above, do you think we need to have it enabled?
We already have an SR open w/ TAC, but the assigned engineer is not responsive...he only gave me a lame one sentence response, and haven't replied to my emails or returned my phone calls for two days.
Indeed, the persistent rebalance command is only making sense if you have an L7 configuration. (ie: sticky cookie but NOT sticky srcip)
What's your case number ?
I can have a look at your config and tell you immediately if you need the command or not.
Our case number is SR611843353.
We're not a government agency or any sort of top secret organization, so please feel free to comment on anything.
The CSE said it behaves the same on CSM & ACE.
I guess that's not entirely true...
We use a few sticky cookie instances.
If I understand you correctly, we should enable persistant rebalance for those apps.
This is where I get confused though - the reason we chose sticky was to make sure clients get stuck to the same servers.
Wouldn't persistant rebalance actually create problems if clients are sent to a different server?
the only place where you need persistent rebalance is : vserver P_CRMSQLRP_80
This is the only place where you actually need to inspect HTTP traffic to make the correct loadbalancing decision.
ACE & CSM will both work the same way if you persistence rebalance enable and the http request contains a cookie.
They will stick the client based on the cookie to the appropriate server.
However, with persistence rebalance, if a request (not the first one) comes in with no cookie, ACE will keep the connection open with the actual server while the CSM will rebalance.
My customer uses ACE, they have L7 rules for cookie and url match.
When a customer logs into the home page they are sent a cookie from the server and all is ok. When they login again they are sent back to the same server matching on the L7 rules. Their web site offers a remember me service (keep cookie), or remove cookie for security. When they remove the cookie, the ACE still sends them back to the server under the L7 match, and they get a page under construction message, as the servers have no home pages and the request is for "/". What should have happended was the policy should have hit the default class and sent them to the servers with the home page. This is the case for 2 mins, after which it works.
Also setting the firefox value network.http.keep-alive=false it works ok.
There is no sticky configuration, is this expected from the ACE, as it sounds correct from your previous conversations.
persistence rebalance is disabled by default on ACE.
You need to enable it with a parameter-map and assign it to the right policy.
They have persitence rebalance enabled, always have done as this is a long term install. However this is the 1st use of a l7 rule combining a cookie value and url.
I think this issue could be related to bug CSCsy21634, requring persistant-rebalance strict configuring. However they have 2.1.5 code, and will require an update.