| CPUG | |
| The Check Point User Group | |
| A Resource For The Check Point Community. Fast. Useful. Independent. | |
|
| |||||||
![]() |
| | LinkBack | Thread Tools | Display Modes |
| |||
| I have a customer experiencing high CPU utilization and need to pinpoint the problem. I noticed these mesages in the log. fw_log_drop: Packet proto=17 x.x.x.x:10000 -> x.x.x.x:6275 dropped by fwchain_frag Reason: wait for more fragments Is this due to the following: Cause The problem occurs because the server & client are using SACK TCP options. When using "SACK options", this may result in big gaps between the sent packets. TCP Streaming, in its term, performs sanity checks on the gaps and TCP window. It may drop the packets that are out of the "10k" pre-defined window default size. Solution To increase the window size from the command line run: "fw ctl set int fwtcpstr_max_window 65536" I am also seeing these messages: fw_log_drop: Packet proto=6 x.x.x.x:44559 -> x.x.x.x:80 dropped by fwconn_memory_check Reason: no memory available Is this caused be reaching the maximum number of connections in the connections table. Will increasing the size of the connection table alleviate the problem. Last edited by jabberw0cky; 2006-06-27 at 16:38. |
| |||
| Hi, Did you manage to resolve the below problem? I don't understand, why UDP protocol have defragmentation problem. Thanks fw_log_drop: Packet proto=17 x.x.x.x:10000 -> x.x.x.x:6275 dropped by fwchain_frag Reason: wait for more fragments |
![]() |
| Thread Tools | |
| Display Modes | |
| |