- CheckMates
- :
- Products
- :
- General Topics
- :
- Re: FIN timer in connection table is very high
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
FIN timer in connection table is very high
I have created several scripts with the tool "fw ctl conntab" in the last days. This shows many parameters to the connections and the timer settings of the connection. I noticed that in many versions (e.g. R80.40 JHF 120, R81 and R81.10) the FIN timers are set very high partly approximately 10 hours. This concerns various firewall versions.
This means that many connections are still in the connection table with the status "DST-FIN, SRC-FIN, BOTH-FIN" for this time.
According to "TCP end timeout" the values should be much lower (20 sec vs 5 sec).
Is this a bug?
On the corresponding firewalls, the timers are still set to the default values.
- Tags:
- performance
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I assume this would need a TAC case to dig into.
My feeling is this is probably a cosmetic bug of some sort.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Agree with Phoneboy here, this command wasn't even documented until I revealed it in my 2018 CPX speech and it is kind of known for having strange cosmetic issues that don't indicate an actual problem:
sk126573: Incorrect output of "fw ctl conntab" when CoreXL is enabled
CET (Europe) Timezone Course Scheduled for July 1-2
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am currently researching an issue and hope to get some answers.
Version R80.20 T160
Hardware: 5600 (CoreXL = 2)
Throughput, typically 300Mbps but sometimes there are spikes that caused interface drops and I see all RX-ERR, RX-DRP and RX-OVR for a busy interface. The overall drops are under 0.0001%.
# fwaccel stats -s
Accelerated conns/Total conns : (100%)
Accelerated pkts/Total pkts : (99%)
F2Fed pkts/Total pkts : (0%)
# fwaccel stat
Accept Templates : disabled by Firewall
Layer XYZ Security disables template offloads from rule #5
Throughput acceleration still enabled.
All the high hit rules are below rule #5. Does this means that they are still getting accelerated? I have checked the top source/destination pairs in SXL table but I did not see any of these matching the high hit rules. Based on that it is hard to believe that the firewall is doing 99% acceleration?
When I run this command:
fwaccel conns | grep <IP_Address>
For most IP's I see the normal output that has mostly "established"
Flags are: ..N............ OR ..N......L.....
But for some IP addresses (from high hit rules) I only see "Both FIN"
What does that indicates?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
hi,
we did run in a similar issue with R80.30 and understood following:
TCP end timeout: A TCP connection will only terminate TCP end timeout seconds after two FIN packets (one in each direction: client-to-server, and server-to-client) or an RST packet.
When a TCP connection ends (FIN packets sent or connection reset) the Security Gateway will keep the connection in the connections table for another TCP end timeout seconds, to allow for stray ACKs of the connection that arrive late.
Regards
