Support Center > Search Results > SecureKnowledge Details
SmartView Monitor "Top QoS Rules" view shows that almost all traffic matches the "No Match" rule when SecureXL is enabled
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 .