Description
This article explains the meaning of for the counter fields in ‘diagnose sys session full-stat’ output.
Solution
Below is the output of the ‘diagnose sys session full-stat’ debug commands output:
diag sys session full-stat
session table: table_size=262144 max_depth=1 used=24
misc info: session_count=12 setup_rate=0 exp_count=0 clash=0
memory_tension_drop=0 ephemeral=0/131062 removeable=0
delete=0, flush=0, dev_down=0/0 ses_flush_filters=0
flush_work_num=0
TCP sessions:
3 in ESTABLISHED state
firewall error stat:
error1=00000000
error2=00000000
error3=00000000
error4=00000000
tt=00000000
cont=00000000
ids_recv=00000000
url_recv=00000000
av_recv=00000000
fqdn_count=00000000
fqdn6_count=00000000
……………
'removable': counts the number of existing firewall sessions that are candidates for deletion/removal in the event that a new session needs to be created and there is no memory left to create the new session unless an existing session is deleted first.
'delete': counts the number of firewall sessions that were deleted either by user action or because some feature required a specific session to be deleted to avoid an anomaly occurring. Some examples of this are:
'flush': counts the number of times a request was made to flush firewall sessions matching specific criteria either by user action or because some feature required those sessions to be deleted in order to avoid an anomaly occurring.
The reason this is separate from delete is that a request to remove a specific session is much more efficient to implement than a request to delete all sessions matching a specific criteria and so it is useful to know how many times the more expensive flush was done.
'dev_down': counts the number of times a request was made to delete all firewall sessions related to an IPsec interface that has been taken administratively down.
'tt': is always 0 from FOS 3.00 onwards. Back in FOS 2.80, it counted the number of times that traffic triggered an IKE negotiation.
'cont': counts the number of packets that were sent to IPS, given a pass, and now continue (hence the name) on for processing by a proxy (historically one that was performing AV). The count is displayed in hexadecimal.
'ids_recv': counts the number of packets that are sent to IPS for processing. Note that if the model supports nTurbo and it is enabled then packets delivered to IPS via nTurbo path are not counted here. The count is displayed in hexadecimal.
'ids_recv': is always 0 from FOS 3.00 onwards. Back in FOS 2.80, it counted the number of URL rating requests sent by the kernel to the urlfilter process.
'av_recv': counts the number of packets that are sent to one or more proxies for processing. Historically this meant the proxy that performed AV (hence the antivirus in the name) but since FOS 3.00 it has also counted other cases where traffic is proxied such as the SIP ALG. The count is displayed in hexadecimal.
'fqdn_count': counts the number of FQDN entries that currently exist in the kernel corresponding to the FQDNs defined in config firewall address, config firewall address6, and config firewall service. The count is displayed in hexadecimal.
'error1': Indicates there was a mismatch between the encryption state of the packet received and the session the packet belongs to. Either the packet was plain text when the session says it should have been decrypted (such as during a spoof), or the packet was decrypted properly but the session has no associated IPsec tunnel.
'error2': Counts the number of times that on egress the chosen interface does not match the expected interface as cached in the session and thus the packet is dropped and the session is deleted. Mostly related to cases where this can happen is with policy-based IPsec.
'error3': When an expectation is created in order to open a pinhole in the firewall, the expectation is linked to the session whose traffic was being processed which resulted in the creation of the expectation. The number of expectation sessions that can simultaneously be connected to be parent session is capped. The error3 count is incremented each time the cap is reached.
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.