cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1087
Views
0
Helpful
4
Replies

Css dropping connection

Greg Bhullar
Level 1
Level 1

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

2 Accepted Solutions

Accepted Solutions

pablo.nxh
Level 3
Level 3

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

View solution in original post

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

View solution in original post

4 Replies 4

pablo.nxh
Level 3
Level 3

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

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 .

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

Thanks pablo.nxh all fixed.

Review Cisco Networking for a $25 gift card