Support Center > Search Results > SecureKnowledge Details
Limitations of Check Point QoS
Solution

Limitations of Check Point QoS

  • Enforcing DiffServ on marked packets

    Normally, network nodes that support Diffserv can perform the following operations:

    • Classify incoming packets according to IP address or service information and mark the TOS field in the IP header with a DSCP (DiffServ code point) value.

    • Apply a QoS policy on incoming packets according to IP address or service information.

    • Apply a QoS policy (namely a PHB; per-hop behavior) on incoming packets according to their existing DSCP.

    Check Point QoS can only perform the first 2 operations. It does not look at the existing DSCP value of incoming packets. This means that in order to allow Check Point QoS to play an active part in the DiffServ environment it will need to re-classify and re-mark the packets. This forces the user to redefine the classification rules.

    Note: A non-QoS gateway does not modify the DSCP bits. A QoS gateway can be configured to modify them.

    For example: If there is a Check Point QoS gateway behind a DiffServ-enabled router, the user will need to configure VoIP traffic, as class EF, on both the router and the Check Point QoS gateway.

    Note: This is a problem only when the Check Point QoS gateway is behind a router, because if it is on the border of the DiffServ-enabled network, it will need to mark the packets anyway.

  • Support of P2P and Instant Messaging

    File transfer and instant messaging traffic over HTTP (port 80 tunneling) is not supported by Check Point QoS. This means, for example, that it is not possible to lower the bandwidth for file transfers over HTTP, without harming normal HTTP browsing traffic.

    Note: It is possible to control P2P traffic, if it uses a different, known port. For controlling such traffic it is possible to use the P2P_File_Sharing_Applications service.



  • Support of ClusterXL when physical IP addresses of cluster members and Cluster Virtual IP address are configured on different subnets

    QoS recognizes the cluster members according to the network subnet of the cluster.

    If the physical IP addresses of cluster members and Cluster Virtual IP address are configured on different subnets (which is a supported configuration), QoS does not recognize the cluster members (by the current design). In such a configuration, QoS rules might not be applied - refer to sk105610.

 

Related Solutions:

Give us Feedback
Please rate this document
[1=Worst,5=Best]
Comment