Slow response for a down service

[henry-ho]

When a service (TCP) is down,

the client requesting via VIP does not detect the service is down on the server till abt 25 sec later.

If bypassing the CSS, the client requesting the service directly on the server detect the service is down almost immediately.

Any parameter can be configured on the CSS to reduce the delay.

Any explaination of the behaviour.

[jfoerster]

HI,

depending on your configuration this might be true. Do you reassign connections or do you have a "sorry server" if the server fails? Is there more than one server assigned to the VIP? What's your health-checking method?

Kind Regards,

Joerg

[sagdas]

Hi,

What kind of content rule are you using. Is it a layer 3 or 5. Can you paste the rule and the service which are giving you the problem.

Regards,

Sagar

[henry-ho]

Below are the configuration

service LD23_Test

ip address 10.80.20.139

keepalive type tcp

protocol tcp

keepalive frequency 10

keepalive retryperiod 2

keepalive maxfailure 1

keepalive port 8101

service LD24_Test

ip address 10.80.20.140

keepalive type tcp

protocol tcp

keepalive frequency 10

keepalive retryperiod 2

keepalive maxfailure 1

keepalive port 8101

active

owner ChehHon

content Test

protocol tcp

port 8101

add service LD23_Test

add service LD24_Test

advanced-balance sticky-srcip

balance leastconn

vip address 10.80.9.50

active

[Gilles Dufour]

The CSS should have no effect on this.

When service goes dow, active connections remain with the dead server and traffic to/from the dead server is still forwarded by the CSS.

To detect the connection has been lost, the client needs to send a packet to the VIP.

The CSS Will forward this packet to the dead server and if the server is still alive but only the service is down, a RESET should be sent by the server to the client and the connection is closed immediately.

However, if the server is completely dowm, no reset is sent by the server and the connection needs to timeout for the client to detect the connection has been lost.

As you can see, the CSS should no affect the time it takes for the application to detect the connection was lost.

To convince yourself, you can capture a sniffer trace on the client when going to the vip and when going directly to the server and see where is the difference.

Regards,

Gilles.

[sagdas]

Hi,

You can reduce the keepalive frequency and also add this command in the content rule.

flow-reset-reject

In case a server goes down, this will send a reset to the client.

Regards,

Sagar

[henry-ho]

When all the load balanced service is down, VIP is not able to ping.

The VIP thus not able to reply the TCP sync ack session request by the client.

The flow-reset-reject seems does not resolve the delay.

Is there any command to enable VIP to be pingable even though all service is down?

[sagdas]

Hi,

If the service is down, the rule is down. So the VIP will be not be pingable. Did you try the keepalive frequency ?

Regards,

Sagar

[jfoerster]

HI,

the only method to keep a VIP up if all servers offering are service are failing is a >>sorry service<< telling the client that this service is right now out of operation. If this sorry service fails you are having the same issue that the VIP is not accessible.

Cheers

Joerg