cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1131
Views
0
Helpful
7
Replies

ip fragment collection timeout

ct_yau
Level 1
Level 1

Hello,

I am having a problem with the CSS. When I "Show ip-fragment-stats", the "Collection Timeout" count keep increasing and clients failed. However, I cannot find any command to adjust the time for collection. I think the timeout in the CSS is too short because the clients work well with the reals but not the VIP. I am using CSS11500 with WebNS version 7.30.1.06.

Please help.

CT Yau

Hong Kong

7 Replies 7

ct_yau
Level 1
Level 1

Apart from "Collection Timeout" I also have the "Flow Timeout" count increasing.

Please help!

CT Yau

Hong Kong

Hi,

What is exactly the problem you are having ?

If you have a lot of terminal sessions disconnecting.

Thus your clients are connecting to a vip that is hosted for a terminal server farm behind the css you could. Try to add the following to your content rules flow-timeout-multiplier 40 . (40 * 16 sec = 10 min)

This will keep garbage collection process from killing flows that it sees as idle. Default flow time out is 16 sec.

Good luck

Thanks for your information. I have already tried the flow-timeout-multiplier but there was no change.

It is a web application and I am using only layer 4 content rules (tcp + port). I am having the server farm in a site and some clients in another site. The two sites are connected with two Cisco routers with VPN bundled. With ipsec, it is inevitable that some ip packet fragmentation will occur.

By default, CSS does not flow-process ip fragments. A few applications load-balanced by CSS failed as soon as ipsec was turned on. I then issued the command "tcp-ip-fragment enable" to the CSS. Most applications works but one particular application continue to fail (there is no response on the client's browser). The "show ip-fragment-stat" command shows increments in the "Collection Timeout" and "Flow Timeout" counters. There is no problem if I connect to the reals.

Anything I can look into?

Some more information:

Actually I have a pair of CSS11501 with redundant-vip and redundant-interface. I found that the CSS with the master VIP is having "Collection Timeout" and "Flow Timeout" while the backup CSS is having "Inserting Fragment" count increments.

Strange i will try to look into it further.

A bit drastic measure is trying to change maxmtu size on clients or servers. But i would try to snif connection on both sides first what exactly is happening when clients try to cinnect to the vip of the serverfarm that's not responding to clients over ipsec wan connection

HI,

is the config of the VPN doing fragmentation even if the DF bit is set? try to use path MTU discovery instead of fragmenting packets as fragmented packets behind a VPN-Link are often giving you a hard time. I suppose the clients support path MTU. If not try to adjust the tcp-mss value at the first hop router the client uses.

Kind regards,

joerg

If the DF bit of a packet is set and fragmentation is needed after adding the ipsec overhead, the VPN router will drop the packet and the whole thing will not work. Supposedly the router will also issue ICMP messages to the client and the client will re-submit with the DF bit off but I never made it work. Actually I needed to issue a "crypto ipsec df-bit clear" command in the router to make things 90% work.

What I finally did to make the whole things work is to issue a "crypto ipsec fragmentation after-encryption" command in the VPN routers. In this way all the fragmentation and fragment reassembly will be done by the pair of VPN routers and the ip fragments do not reach the CSS. But it increases the processing overhead at the VPN routers.

I have solved my problem by means of configuring the VPN routers but I still do not know what went wrong in the CSS's and what can be done there. Any idea from brighter minds?

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: