SmartView Monitor "Top QoS Rules" view shows that almost all traffic matches the "No Match" rule when SecureXL is enabled

Support Center > Search Results > SecureKnowledge Details

Technical Level

Solution ID	sk118720
Technical Level
Product	QoS, SmartView Monitor
Version	R77.30 (EOL), R80.10 (EOL), R80.20, R80.30, R80.40, R81, R81.10
OS	Crossbeam XOS, Gaia, IPSO 6.2, SecurePlatform 2.6
Date Created	06-Jul-2017
Last Modified	06-Jul-2021

Symptoms

SmartView Monitor "Top QoS Rules" view shows that almost all traffic matches the "No Match" rule.
Example:
Kernel debug ('fw ctl debug -m RTM + rtm view_add per_conn') on Security Gateway shows that sometimes SmartView Monitor fails to read the QoS rule.

Examples:
- ;svmClassifyKviews : [first time] Conn: =<[192.168.0.141(c0a8008d) 192.168.1.1(c0a80101)] [65054 53] [17]> cl_in: 1, cl_out: -1, s_in: -1, s_out: -1; ;get_fg_matched_rules: Get rule for ifn 1, dir: 0; ;get_fg_matched_rules: The ifn:1 is not active. (direction 0); ;svmClassifyKviews : could not read matched rule from FloodGate;
- ;svmClassifyKviews : [mismatch] Conn: <[192.168.0.141(c0a8008d) 192.168.1.1(c0a80101)] [65054 53] [17]>; ;get_fg_matched_rules: Get rule for ifn 3, dir: 1; ;get_fg_matched_rules: The ifn:3 is not active. (direction 1); ;svmClassifyKviews : could not read matched rule from FloodGate;
In addition, whenever a new SmartView Monitor view is opened, the connections are re-classified, which causes "no-match" for a short moment.
Disabling SecureXL resolves the issue.

Cause

When SecureXL is enabled, interface information is saved in advance also for the other direction (in case the connection will be accelerated - i.e., if packet is 'Client-to-Server', then the same interface is saved for 'Server-to-Client' direction).

However, since interface information is saved, an interface mismatch can not occur. As a result, a QoS rule is not reclassified (which is per direction, unlike in FireWall rules) for the other direction.

Solution

Note: To view this solution you need to Sign In .