07-22-2011 02:07 PM
We are having a issue that when user from internet connect to us on–1.1.1.1 port 443 –the connection dropped after 1hour and 6 minutes.
On Firewall we have
Public ip –1.1.1.1 ---static natted to 192.168.1.1 (vip)
Then we have Cisco css load balancer
192.168.1.1 is a vip on load balancer
Then it has real or 3 hosts:
192.168.2.1
192.168.2.2
192.168.2.3
Then the real’s are connected to ccs with layer 2 switch
When I connect directly to the real’s i.e 192.168.2.1 on port 443 all good never times out .
Looks like some setting in the firewall or css is wrong which is timing out .
I went and removed firewall and hit the vip directly i.e 192.168.1.1 on port 443 it dropped the connection , looks like i need
oneconnect algo or some other setting needs to be changed on css--need help.
On firewall I have increased the time out no luck
timeout xlate 6:00:00
timeout conn 4:00:00 half-closed 0:55:00 udp 0:09:00 icmp 0:00:09
timeout sunrpc 3:10:00 h323 3:05:00 h225 3:00:00 mgcp 0:35:00
timeout mgcp-pat 0:35:00 sip 3:30:00 sip_media 0:32:00
timeout uauth 0:35:00 absolute
Cannot find any timeout setting on css
Any advice thanks
Solved! Go to Solution.
07-22-2011 06:24 PM
Hi Greg,
Generally problems with dropped sessions are due to idle connections between the client and the CSS; it would be a little bit difficult to T-Shoot this using packet captures considering the traffic is over SSL and the connection times out after an hour.
You can add this command under the content rule doing the SSL passthrough in order to instruct the CSS to keep idle flows a little longer in the conn table before it reclycles them.
flow-timeout-multiplier 40
If you are using a source group for source NAT you can it there as well.
HTH
__ __
Pablo
07-25-2011 09:47 AM
Hi Greg,
999 is OK for testing but you need to be careful with the orphan flows left on the conn table that will consume valuable resources.
About the keepalive retyperiod, no you don't need to modify anything under the services configuration; keepalive are just to check aliveness of the physical services they don't play a role in the conn table.
HTH
__ __
Pablo
07-22-2011 06:24 PM
Hi Greg,
Generally problems with dropped sessions are due to idle connections between the client and the CSS; it would be a little bit difficult to T-Shoot this using packet captures considering the traffic is over SSL and the connection times out after an hour.
You can add this command under the content rule doing the SSL passthrough in order to instruct the CSS to keep idle flows a little longer in the conn table before it reclycles them.
flow-timeout-multiplier 40
If you are using a source group for source NAT you can it there as well.
HTH
__ __
Pablo
07-25-2011 08:28 AM
Thanks
I will try flow-timeout-multiplier 999
User Configured Values for Content Rule Flow Timeout
Port Content Rule Timeout
0 Test 999
content Test
add service Test1
vip address 192.168.1.13
flow-timeout-multiplier 999 - have added this config
active
service Test1
ip address 192.168.2.13
keepalive type tcp
keepalive retryperiod 2 -----------------Do i have to increase the values
keepalive maxfailure 2
keepalive frequency 2
redundant-index 25
keepalive port 9003
port 9443
active
Thanks-- testing it now .
07-25-2011 09:47 AM
Hi Greg,
999 is OK for testing but you need to be careful with the orphan flows left on the conn table that will consume valuable resources.
About the keepalive retyperiod, no you don't need to modify anything under the services configuration; keepalive are just to check aliveness of the physical services they don't play a role in the conn table.
HTH
__ __
Pablo
08-05-2011 07:27 AM
Thanks pablo.nxh all fixed.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide