CSS TCP RST to dead VIP address

Martin Kyrc · ‎03-04-2008

When all services goes down, telnet to VIP address is trying to connect. CSS don't send TCP RST to the client (it's enabled). tcpdump shows only TCP SYN packets to the CSS, but no response from CSS. It's a bug, or feature? :)

CSS version: 07.50.1.03

css1# sh rule domino domino-tomcat

Name: domino-tomcat Owner: domino

State: Active Type: HTTP

Balance: Round Robin Failover: N/A

Persistence: Enabled Param-Bypass: Disabled

Session Redundancy: Enabled Redundancy Global Index: 12

IP Redundancy: Master

FlowTimeout: 8

L3: 172.24.1.23

L4: TCP/8009

Url:

Redirect: ""

TCP RST client if service unreachable: Enabled

Rule Services & Weights:

1: domino-tomcat-1-Down, S-1

2: domino-tomcat-2-Down, S-1

after configuring 'flow tcp-reset-vip-unavailable' in global config mode, CSS send TCP RST to the client.

My question:

When is 'flow tcp-reset-vip-unavailable' enabled, is needed to configure "TCP RST client if service unreachable: Enabled" in the content?.

Gilles Dufour · ‎03-04-2008

Looks like you found the answer to your question already.

Indeed without the special reset command, the CSS does not send any RESET to client initiating a connection to a down vip.

The rule shows

TCP RST client if service unreachable: Disabled

Gilles.

Marlon Malinao · ‎05-06-2008

Hi Gilles,

Sorry if i enter your conversation, i dont know the link to create a new conversation, i have a slightly similar problem with TCP RST, One of my Webserver behind the CSS11501 which is an IBM Web server, is trying to connect to a 3rd party CRL provider via port 80, but we dont want to connect this the CRL provider, we have an archive local CRL on the server itself so that the Web server dont need to connect to the internet to get the latest CRL and used the local CRL, in order for the server to stop connecting to the CRL provider and only check the local CRL the server must recieve a RST packet from the Load Balancer or Firewall. on the Firewall it is already blocked and in the Load Balancer i created a deny rule for this traffic, but when i do a sniffing behind the load balancer w/in the same segment of the webserver there is no RST coming from the load balancer for that session, i can see some RST coming from the loadbalancer to the webserver but i think it is for other sessions.

below is the sample sniffer follow tcp stream from webserver connecting to the CRL provider.

562 181.129839 172.20.13.4 203.116.162.171 TCP 45658 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 TSV=1210167687 TSER=0

563 184.128361 172.20.13.4 203.116.162.171 TCP 45658 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 TSV=1210167692 TSER=0

570 190.129026 172.20.13.4 203.116.162.171 TCP 45658 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 TSV=1210167704 TSER=0

607 202.130154 172.20.13.4 203.116.162.171 TCP 45658 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 TSV=1210167728 TSER=0

636 226.132590 172.20.13.4 203.116.162.171 TCP 45658 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 TSV=1210167776 TSER=0

currently we are running 07.40.2.02.

Hope you can help me with this problem.

Regards,

Marlon

Gilles Dufour · ‎05-06-2008

Marlon,

have you tried the command mentioned here :

flow tcp-reset-vip-unavailable

You could also try the following ones :

flow-reset-reject Send TCP RST to client for when active flows are rejected

flow-srvdown-reset Send TCP RST to client when service goes to a down state

Gilles.

Marlon Malinao · ‎05-06-2008

Hi Gilles,

Im refering to outgoing traffic from my web Server behind the load Balancer, My webserver is trying to connect to our CRL provider public IP via http, what happenss, is that it takes the web server to try 5 times (same sourceport) within 45 seconds before the webserver look to its local CRL. somehow i dont see any RST packet coming from Load balancer even though i applied an ACL thats why webserver keep on trying to connect to the CRL, we want to quickly send a RST packet from LB to Web server so that the Webserver will terminates the session and check its Local CRL.

Thanks and Best Regards,

Marlon

Gilles Dufour · ‎05-08-2008

if you block the traffic with an acl, the loadbalance won't even see the request and will have no reason to send a reset.

As I said, if you need any further assistance, send us your config and a trace in front of the css showing the request from your server coming in.

Gilles.

Marlon Malinao · ‎10-13-2008

Hi Gilles,

Sorry for the late reply, i dont apply the ACL option, and we found out that is caused by the application bug.

Thanks for Help.

I just want to ask you some basic questions about CSS monitoring the services.

How can i monitor the services (ie 80 and 443) of the real servers. So that when the CSS11501 detects that one of the services of one of the real servers is down, it will not forward the traffic to that server. Or is the CSS is configured to monitor the services by default?

Because we are planning to upgrade one of the webservers (web01) while web02 is running, if we shutdown the service 80 and 443, does it affect the end-user, will CSS automatically redirect it to web02?

Regards,

Marlon

Marlon Malinao · ‎10-13-2008

Here is my sample configuration

!************************** SERVICE **************************

service WEB01-79-HTTP

ip address 172.20.13.4

keepalive type tcp

keepalive port 80

active

service WEB01-79-HTTPS

ip address 172.20.13.4

keepalive type tcp

keepalive port 443

active

service WEB01-80-HTTP

ip address 172.20.13.5

keepalive type tcp

keepalive port 80

active

service WEB01-80-HTTPS

ip address 172.20.13.5

keepalive type tcp

keepalive port 443

active

service WEB01-82-HTTP

ip address 172.20.13.6

keepalive type tcp

keepalive port 80

active

service WEB01-82-HTTPS

ip address 172.20.13.6

keepalive type tcp

keepalive port 443

active

service WEB01-83-HTTP

ip address 172.20.13.7

keepalive type tcp

keepalive port 80

active

service WEB01-83-HTTPS

ip address 172.20.13.7

keepalive type tcp

keepalive port 443

active

service WEB01-79

ip address 172.20.13.4

active

service WEB01-80

ip address 172.20.13.5

active

service WEB02-82

ip address 172.20.13.6

active

service WEB02-83

ip address 172.20.13.7

active

!*************************** OWNER ***************************

owner VRL

content VIP

redundancy-l4-stateless

content WEB-HTTP1

vip address 172.20.10.85

protocol tcp

port 80

advanced-balance sticky-srcip

add service WEB01-79-HTTP

add service WEB01-82-HTTP

redundancy-l4-stateless

active

content WEB-HTTP2

vip address 172.20.10.86

port 80

protocol tcp

advanced-balance sticky-srcip

add service WEB01-80-HTTP

add service WEB01-83-HTTP

redundancy-l4-stateless

active

content WEB-HTTPS1

advanced-balance sticky-srcip

vip address 172.20.10.85

protocol tcp

port 443

add service WEB01-79-HTTPS

add service WEB01-82-HTTPS

redundancy-l4-stateless

application ssl

sticky-inact-timeout 20

active

content WEB-HTTPS2

advanced-balance sticky-srcip

vip address 172.20.10.86

protocol tcp

port 443

add service WEB01-80-HTTPS

add service WEB01-83-HTTPS

redundancy-l4-stateless

application ssl

sticky-inact-timeout 20

active

content WEB01-79

add service WEB01-79

vip address 172.20.10.79

redundancy-l4-stateless

active

content WEB01-80

add service WEB01-80

vip address 172.20.10.80

redundancy-l4-stateless

active

content WEB02-82

add service WEB02-82

vip address 172.20.10.82

redundancy-l4-stateless

active

content WEB02-83

add service WEB02-83

vip address 172.20.10.83

redundancy-l4-stateless

active

!*************************** GROUP ***************************

group WEB01-79

add service WEB01-79

vip address 172.20.10.79

redundancy-l4-stateless

active

group WEB01-80

add service WEB01-80

vip address 172.20.10.80

redundancy-l4-stateless

active

group WEB02-82

add service WEB02-82

vip address 172.20.10.82

redundancy-l4-stateless

active

group WEB02-83

add service WEB02-83

vip address 172.20.10.83

redundancy-l4-stateless

active