CSS11500 - Service Hit Counts

[cisco_lite]

Hi,

I can see the below service hits counts on CSS11500. The load balance algorithm is defaulted to round robin. However, I still notice an uneven service hits counts in the pool. What could be the reason ? What does service hit counts mean. Is it just the number of hits or the active connections. If the connection is still active, would the service hits reflect that.

> show summary

Owner Content Rules State Services Service Hits

TEST Master Test-1 8151

Test-2 1468

Also what is the difference between Total Local Connections, Total Connections, Current Connections and Load on 'show service' command.

[cisco_lite]

Correction to the above...

The load balancing alg is

advanced-balance sticky-srcip-dstport

Please advise.

[ciscocsoc · Accepted solution]

Hi,

Once you bring stickiness into the picture then normal load-balancing algortihms no longer apply.

You need to consider the netmask on the advanced-balance statement (default 255.255.255.255), along with any NAT and proxy usage. The distribution of users across subnets will also make a difference.

What you're seeing is not entirely unexpected.

HTH

Cathy

[cisco_lite]

I would like to understand more on stickiness based on source/destination IP.

Lets say a new user accesses the VIP. I believe for a new user, the load balance type is round robin (despite configured setting). The CSS/ACE performs a hash on the source/destination IP and stores it. For subsequent access from the same source, it uses the stored hash value and forwards to the same server.

Please advise whether this understanding is correct and whether the first time access is always round robin no matter what advance-balance type is configured.

[ciscocsoc · Accepted solution]

From the CSS Content Load-Balancing Configuration Guide Ch11:

"If the CSS determines that a client is already stuck to a particular service, then the

CSS places the client request on that service, regardless of the load balancing

criteria specified by the matched content rule. If the CSS determines that the

client is not stuck to a particular service, it applies normal load balancing to the

content request."

You understanding is correct and round-robin is the default LB algorithm.

HTH

Cathy

[cisco_lite]

Subsequent to the above, can you take me through the hash algorithm which decides what server should the request be forwarded to.

For e.g.

Source IP: 1.1.1.1

Destination IP: 2.2.2.2 (VIP)

Server 1: 3.3.3.1

Server 2: 3.3.3.2

Now, applying the hash

1.1.1.1 + 2.2.2.2 + (some hash alg) = Server1

and

1.1.1.2 + 2.2.2.2 + (some hash alg) = Server2

Is it possible to calculate this value manually and verify through the CSS table whether the hash is correct and forwarding to the right server. Or is it too much to verify.

If the application team raises the concern that load balance is not happening equally then the above calculation may help. Can the sticky table ever go haywire i.e. forwarding the traffic wrongly.

Also, is it possible to combine stickiness while changing the default round-robin LB alg i.e. making it based on the load of the destination server. At least this will make sure that at any point in time, the servers will get equal hits even though the sticky sessions are running high on one machine.

[ciscocsoc]

I don't have access to any more information than you do about the hash algorithms used.

I suspect the information would be Cisco proprietory, so we couldn't be told anyway.

Chapter 10 of the previously referenced manual give you the available balance options - e.g. balance leastconn.

If you think you have a real problem with the load distribution then raise a TAC case.

Cathy

[cisco_lite]

Thanks.

Would you know the resulting difference between stickiness based on source only or based on source+destination IP. Is one more efficient or beneficial than the other.

[ciscocsoc]

It really all depends on the randomness of the information. If everything came from the same source IP - the megaproxy problem - then hashing on the source wouldn't be a good idea.

There should be no significant difference in the outcome for random inputs.

Only you know how your network and applications are organised.

Cathy

[cisco_lite]

"It really all depends on the randomness of the information. If everything came from the same source IP - the megaproxy problem - then hashing on the source wouldn't be a good idea."

If the initial hit happens by way of round-robin, then how does it matter whether source remains the same or changes. Because, the initial round-robin logic determines what the client should be stuck to. And also if the destination remains the same (I believe the VIP) what will be the difference.

[veriton]

I think the point is if you're using src or src+dst routing then it's not really round-robin as soon as you have a skew in source IPs.

Where I've seen it is if you have an enterprise app with all users coming through a firewall (perhaps from a branch office) with a NAT'ed address (i.e. single src IP).