CSM maxconn behavior

[limko]

Can anyone explain the behavior of the maxconn command under vserver? If I have maxconn=1000, what will happen to connection 1001?

[seilsz]

In your example, connections above 1000 will be dropped.

Reference:

http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40%40.1dd6abec/0#selected_message

~Zach

[limko]

I configured the maxconn in the CSM and the limit is frequently exceeded. That means a lot of connections will be dropped. What should I do if I do not want any connections to be dropped? Instead, I want them to be bypassed. The CSM is serving connections to CE7325.

[seilsz]

Are you trying to protect the CE from being overloaded?

~Zach

[limko]

Yes, I want to protect the CE and do not want connections to be dropped at the same time.

[seilsz · Accepted solution]

You may want to try the 'bypass gateway' command introduced in ACNS 5.1. I'm not positive this works with load bypass on the CE, it may only work with authentication and unknown protocol bypass.

If it does work, you can remove the maxconns from your vserver and allow load bypass on the CE to redirect traffic when the CE becomes overloaded.

~Zach

[limko]

That sounds like a good idea, but I gotta test it before configuring it into the production network.

My current config has 2 serverfarms. One of the serverfarms is a backup to the first one. This backup will kick in when the first serverfarm become unavailable, and traffic to the backup will be bypassed.

Here's some info about the CSM config;

serverfarm BACKUPROUTE

no nat server

no nat client

predictor forward

!

serverfarm BRF-CE-FARM

no nat server

no nat client

predictor hash address destination

real x.x.x.x

maxconns 13000

inservice

real y.y.y.y

maxconns 13000

inservice

!

vserver BRF-CE

virtual 0.0.0.0 0.0.0.0 tcp www

serverfarm BRF-CE-FARM backup BACKUPROUTE

persistent rebalance

inservice

!

Pls correct me if I'm wrong: With the above config, when individual CE reaches the maxconn, traffic will not be sent to BACKUPROUTE. Instead it will be dropped.

[jfoerster]

HI,

from my understanding the backup service will be used if the connections exceed both connection limits. If the connection limit of one CE is exceeded every new connection will be placed to the second CE.

Cheers,

Joerg

[limko]

Hmm... I thought the backup is for serverfarm only. And the maxconn is only applicable to real servers.

[jfoerster]

Yes this i true but if a real is taken "out of service as the max conn is reached and no operational real is remaining than the backup kicks in in my opinion.

Cheers,

Joerg

[Gilles Dufour]

joerg is correct.

This is the way to go.

create a backup serverfarm with predictor forward.

Once all your CE reach maxconn, the backup will be used and traffic will be simply forwarded.

Regards,

Gilles.

[limko]

So in my case, the primary serverfarm has 2 real servers. If the 1st realserver is operational & the 2nd reached Maxconn, the backup will not kick in. At the same time, the 2nd realserver is not serving the additional requests. So, what will happen to these requests?

[jfoerster]

HI,

if your 2nd real reaches the limit and the first has still some connections left until it reaches the MAX-Conn the connections will be places to this real. As soon as both are reaching the limit the backup will kick in.

Cheers,

Joerg

[limko]

Hi Joerg,

If that's the behaviour with the "predictor hash address destination", then that sounds safe, as long as it's not dropping any connections. tq.

[jfoerster]

Hi,

well it's the behaviour of a serverfarm with configured boundaries like maxconnections. The predictor is an "advanced" load balancing mechanism which ensures that certain destianation IP's are forwarded to the same CE. I personally would prefer a predictor hash URL in a caching environment but destination IP should do the job as well... Only if a server moves from IP1 to IP2 (i.e. due to global server loadbalancing) you will store content twice.

In terms of your concern that connections are drop I want to say that no connection is dropped except you backup serverfarm is overloaded...

Kind regards,

Joerg