Check Point QoS

NGX (R60)
IMPORTANT
Check Point recommends that customers stay up-to-date with the latest
service packs and versions of security products, as they contain security
enhancements and protection against new and changing attacks.

For additional technical information about Check Point products, consult Check Point’s SecureKnowledge at:

https://secureknowledge.checkpoint.com/

See the latest version of this document in the User Center at:
http://www.checkpoint.com/support/technical/documents/docs_r60.html

Part No.: 700726

May 2005
© 2003-2005 Check Point Software Technologies Ltd.
All rights reserved. This product and related documentation are protected by copyright
and distributed under licensing restricting their use, copying, distribution, and
decompilation. No part of this product or related documentation may be reproduced in
any form or by any means without prior written authorization of Check Point. While every
precaution has been taken in the preparation of this book, Check Point assumes no
responsibility for errors or omissions. This publication and features described herein are
subject to change without notice.
RESTRICTED RIGHTS LEGEND:
Use, duplication, or disclosure by the government is subject to restrictions as set forth in
subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at
DFARS 252.227-7013 and FAR 52.227-19.
TRADEMARKS:
©2003-2005 Check Point Software Technologies Ltd. All rights reserved.
Check Point, Application Intelligence, Check Point Express, the Check Point logo,
AlertAdvisor, ClusterXL, Cooperative Enforcement, ConnectControl, Connectra, CoSa,
Cooperative Security Alliance, Eventia, Eventia Analyzer, FireWall-1, FireWall-1 GX,
FireWall-1 SecureServer, FloodGate-1, Hacker ID, IMsecure, INSPECT, INSPECT XL,
Integrity, InterSpect, IQ Engine, Open Security Extension, OPSEC, Policy Lifecycle
Management, Provider-1, Safe@Home, Safe@Office, SecureClient, SecureKnowledge,
SecurePlatform, SecuRemote, SecureXL Turbocard, SecureServer, SecureUpdate,
SecureXL, SiteManager-1, SmartCenter, SmartCenter Pro, Smarter Security,
SmartDashboard, SmartDefense, SmartLSM, SmartMap, SmartUpdate, SmartView,
SmartView Monitor, SmartView Reporter, SmartView Status, SmartViewTracker,
SofaWare, SSL Network Extender, Stateful Clustering, TrueVector, Turbocard, UAM,
User-to-Address Mapping, UserAuthority, VPN-1, VPN-1 Accelerator Card, VPN-1 Edge,
VPN-1 Pro, VPN-1 SecureClient, VPN-1 SecuRemote, VPN-1 SecureServer, VPN-1
VSX, VPN-1 XL, Web Intelligence, ZoneAlarm, ZoneAlarm Pro, Zone Labs, and the Zone
Labs logo, are trademarks or registered trademarks of Check Point Software
Technologies Ltd. or its affiliates. All other product names mentioned herein are
trademarks or registered trademarks of their respective owners. The products described
in this document are protected by U.S. Patent No. 5,606,668, 5,835,726, 6,496,935 and
6,850,943 and may be protected by other U.S. Patents, foreign patents, or pending
applications.
THIRD PARTIES:
Entrust is a registered trademark of Entrust Technologies, Inc. in the United States and
other countries. Entrust’s logos and Entrust product and service names are also
trademarks of Entrust Technologies, Inc. Entrust Technologies Limited is a wholly owned
subsidiary of Entrust Technologies, Inc. FireWall-1 and SecuRemote incorporate
certificate management technology from Entrust.
Verisign is a trademark of Verisign Inc.
The following statements refer to those portions of the software copyrighted by University
of Michigan. Portions of the software copyright © 1992-1996 Regents of the University of
Michigan. All rights reserved. Redistribution and use in source and binary forms are
permitted provided that this notice is preserved and that due credit is given to the
University of Michigan at Ann Arbor. The name of the University may not be used to
endorse or promote products derived from this software without specific prior written
permission. This software is provided “as is” without express or implied warranty.
Copyright © Sax Software (terminal emulation only).
The following statements refer to those portions of the software copyrighted by Carnegie
Mellon University.
Copyright 1997 by Carnegie Mellon University. All Rights Reserved.
Permission to use, copy, modify, and distribute this software and its documentation for
any purpose and without fee is hereby granted, provided that the above copyright notice
appear in all copies and that both that copyright notice and this permission notice appear
in supporting documentation, and that the name of CMU not be used in advertising or
publicity pertaining to distribution of the software without specific, written prior
permission.CMU DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN
NO EVENT SHALL CMU BE LIABLE FOR ANY SPECIAL, INDIRECT OR
CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,
NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
The following statements refer to those portions of the software copyrighted by The Open
Group.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
Check Point Software Technologies Ltd.
U.S. Headquarters: 800 Bridge Parkway, Redwood City, CA 94065, Tel: (650) 628-2000 Fax: (650) 654-4233, info@CheckPoint.com
International Headquarters: 3A Jabotinsky Street, Ramat Gan, 52520, Israel, Tel: 972-3-753 4555 Fax: 972-3-575 9256, http://www.checkpoint.com
NONINFRINGEMENT. IN NO EVENT SHALL THE OPEN GROUP BE LIABLE FOR ANY
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
The following statements refer to those portions of the software copyrighted by The
OpenSSL Project. This product includes software developed by the OpenSSL Project for
use in the OpenSSL Toolkit (http://www.openssl.org/).
THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY *
EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
The following statements refer to those portions of the software copyrighted by Eric
Young. THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND ANY
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE. Copyright © 1998 The Open Group.
The following statements refer to those portions of the software copyrighted by Jean-loup
Gailly and Mark Adler Copyright (C) 1995-2002 Jean-loup Gailly and Mark Adler. This
software is provided 'as-is', without any express or implied warranty. In no event will the
authors be held liable for any damages arising from the use of this software. Permission
is granted to anyone to use this software for any purpose, including commercial
applications, and to alter it and redistribute it freely, subject to the following restrictions:
1. The origin of this software must not be misrepresented; you must not claim that you
wrote the original software. If you use this software in a product, an acknowledgment in
the product documentation would be appreciated but is not required.
2. Altered source versions must be plainly marked as such, and must not be
misrepresented as being the original software.
3. This notice may not be removed or altered from any source distribution.
The following statements refer to those portions of the software copyrighted by the Gnu
Public License. This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the Free Software
Foundation; either version 2 of the License, or (at your option) any later version. This
program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY;
without even the implied warranty of MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE. See the GNU General Public License for more details.You
should have received a copy of the GNU General Public License along with this program;
if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139,
USA.
The following statements refer to those portions of the software copyrighted by Thai
Open Source Software Center Ltd and Clark Cooper Copyright (c) 2001, 2002 Expat
maintainers. Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the "Software"), to deal in the
Software without restriction, including without limitation the rights to use, copy, modify,
merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit
persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or
substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT
WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE
OR OTHER DEALINGS IN THE SOFTWARE.
GDChart is free for use in your applications and for chart generation. YOU MAY NOT re-
distribute or represent the code as your own. Any re-distributions of the code MUST
reference the author, and include any and all original documentation. Copyright. Bruce
Verderaime. 1998, 1999, 2000, 2001. Portions copyright 1994, 1995, 1996, 1997, 1998,
1999, 2000, 2001, 2002 by Cold Spring Harbor Laboratory. Funded under Grant P41-
RR02188 by the National Institutes of Health. Portions copyright 1996, 1997, 1998, 1999,
2000, 2001, 2002 by Boutell.Com, Inc. Portions relating to GD2 format copyright 1999,
2000, 2001, 2002 Philip Warner. Portions relating to PNG copyright 1999, 2000, 2001,
2002 Greg Roelofs. Portions relating to gdttf.c copyright 1999, 2000, 2001, 2002 John
Ellson (ellson@graphviz.org). Portions relating to gdft.c copyright 2001, 2002 John Ellson
(ellson@graphviz.org). Portions relating to JPEG and to color quantization copyright
2000, 2001, 2002, Doug Becker and copyright (C) 1994, 1995, 1996, 1997, 1998, 1999,
2000, 2001, 2002, Thomas G. Lane. This software is based in part on the work of the
Independent JPEG Group. See the file README-JPEG.TXT for more information.
Portions relating to WBMP copyright 2000, 2001, 2002 Maurice Szmurlo and Johan Van
den Brande. Permission has been granted to copy, distribute and modify gd in any
context without fee, including a commercial application, provided that this notice is
present in user-accessible supporting documentation. This does not affect your
ownership of the derived work itself, and the intent is to assure proper credit for the
authors of gd, not to interfere with your productive use of gd. If you have questions, ask.
"Derived works" includes all programs that utilize the library. Credit must be given in
user-accessible documentation. This software is provided "AS IS." The copyright holders
disclaim all warranties, either express or implied, including but not limited to implied
warranties of merchantability and fitness for a particular purpose, with respect to this
code and accompanying documentation. Although their code does not appear in gd 2.0.4,
the authors wish to thank David Koblas, David Rowley, and Hutchison Avenue Software
Corporation for their prior contributions.
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this
file except in compliance with the License. You may obtain a copy of the License at http:/
/www.apache.org/licenses/LICENSE-2.0
The curl license
COPYRIGHT AND PERMISSION NOTICE
Copyright (c) 1996 - 2004, Daniel Stenberg, <daniel@haxx.se>.All rights reserved.
Permission to use, copy, modify, and distribute this software for any purpose
with or without fee is hereby granted, provided that the above copyright
notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE
OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Except as contained in this notice, the name of a copyright holder shall not be used in
advertising or otherwise to promote the sale, use or other dealings in this Software
without prior written authorization of the copyright holder.
The PHP License, version 3.0
Copyright (c) 1999 - 2004 The PHP Group. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, is
permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of
conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of
conditions and the following disclaimer in the documentation and/or other materials
provided with the distribution.
3. The name "PHP" must not be used to endorse or promote products derived from this
software without prior written permission. For written permission, please contact
group@php.net.
4. Products derived from this software may not be called "PHP", nor may "PHP" appear
in their name, without prior written permission from group@php.net. You may indicate
that your software works in conjunction with PHP by saying "Foo for PHP" instead of
calling it "PHP Foo" or "phpfoo"
5. The PHP Group may publish revised and/or new versions of the license from time to
time. Each version will be given a distinguishing version number. Once covered code has
been published under a particular version of the license, you may always continue to use
it under the terms of that version. You may also choose to use such covered code under
the terms of any subsequent version of the license published by the PHP Group. No one
other than the PHP Group has the right to modify the terms applicable to covered code
created under this License.
6. Redistributions of any form whatsoever must retain the following acknowledgment:
"This product includes PHP, freely available from <http://www.php.net/>".
THIS SOFTWARE IS PROVIDED BY THE PHP DEVELOPMENT TEAM ``AS IS'' AND
ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE PHP
DEVELOPMENT TEAM OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN
IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
This software consists of voluntary contributions made by many individuals on behalf of
the PHP Group. The PHP Group can be contacted via Email at group@php.net.
For more information on the PHP Group and the PHP project, please see <http://
www.php.net>. This product includes the Zend Engine, freely available at <http://
www.zend.com>.
This product includes software written by Tim Hudson (tjh@cryptsoft.com).
Copyright (c) 2003, Itai Tzur <itzur@actcom.co.il>
All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are
permitted provided that the following conditions are met:
Redistribution of source code must retain the above copyright notice, this list of
conditions and the following disclaimer.
Neither the name of Itai Tzur nor the names of other contributors may be used to
endorse or promote products derived from this software without specific prior written
permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Copyright (c) 1998, 1999, 2000 Thai Open Source Software Center Ltd
Permission is hereby granted, free of charge, to any person obtaining a copy of this
software and associated documentation files (the "Software"), to deal in the Software
without restriction, including without limitation the rights to use, copy, modify, merge,
publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons
to whom the Software is furnished to do so, subject to the following conditions: The
above copyright notice and this permission notice shall be included in all copies or
substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR
IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.
Copyright © 2003, 2004 NextHop Technologies, Inc. All rights reserved.
Confidential Copyright Notice
Except as stated herein, none of the material provided as a part of this document may be
copied, reproduced, distrib-uted, republished, downloaded, displayed, posted or
transmitted in any form or by any means, including, but not lim-ited to, electronic,
mechanical, photocopying, recording, or otherwise, without the prior written permission of
NextHop Technologies, Inc. Permission is granted to display, copy, distribute and
download the materials in this doc-ument for personal, non-commercial use only,
provided you do not modify the materials and that you retain all copy-right and other
proprietary notices contained in the materials unless otherwise stated. No material
contained in this document may be "mirrored" on any server without written permission of
NextHop. Any unauthorized use of any material contained in this document may violate
copyright laws, trademark laws, the laws of privacy and publicity, and communications
regulations and statutes. Permission terminates automatically if any of these terms or
condi-tions are breached. Upon termination, any downloaded and printed materials must
be immediately destroyed.
Trademark Notice
The trademarks, service marks, and logos (the "Trademarks") used and displayed in this
document are registered and unregistered Trademarks of NextHop in the US and/or other
countries. The names of actual companies and products mentioned herein may be
Trademarks of their respective owners. Nothing in this document should be construed as
granting, by implication, estoppel, or otherwise, any license or right to use any Trademark
displayed in the document. The owners aggressively enforce their intellectual property
rights to the fullest extent of the law. The Trademarks may not be used in any way,
including in advertising or publicity pertaining to distribution of, or access to, materials in
this document, including use, without prior, written permission. Use of Trademarks as a
"hot" link to any website is prohibited unless establishment of such a link is approved in
advance in writing. Any questions concerning the use of these Trademarks should be
referred to NextHop at U.S. +1 734 222 1600.
U.S. Government Restricted Rights
The material in document is provided with "RESTRICTED RIGHTS." Software and
accompanying documentation are provided to the U.S. government ("Government") in a
transaction subject to the Federal Acquisition Regulations with Restricted Rights. The
Government's rights to use, modify, reproduce, release, perform, display or disclose are
restricted by paragraph (b)(3) of the Rights in Noncommercial Computer Software and
Noncommercial Computer Soft-ware Documentation clause at DFAR 252.227-7014 (Jun
1995), and the other restrictions and terms in paragraph (g)(3)(i) of Rights in Data-
General clause at FAR 52.227-14, Alternative III (Jun 87) and paragraph (c)(2) of the
Commer-cial
Computer Software-Restricted Rights clause at FAR 52.227-19 (Jun 1987).
Use of the material in this document by the Government constitutes acknowledgment of
NextHop's proprietary rights in them, or that of the original creator. The Contractor/
Licensor is NextHop located at 1911 Landings Drive, Mountain View, California 94043.
Use, duplication, or disclosure by the Government is subject to restrictions as set forth in
applicable laws and regulations.
Disclaimer Warranty Disclaimer Warranty Disclaimer Warranty Disclaimer Warranty
THE MATERIAL IN THIS DOCUMENT IS PROVIDED "AS IS" WITHOUT WARRANTIES
OF ANY KIND EITHER EXPRESS OR IMPLIED. TO THE FULLEST EXTENT POSSIBLE
PURSUANT TO THE APPLICABLE LAW, NEXTHOP DISCLAIMS ALL WARRAN-TIES,
EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, IMPLIED
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE,
NON INFRINGEMENT OR OTHER VIOLATION OF RIGHTS. NEITHER NEXTHOP NOR
ANY OTHER PROVIDER OR DEVELOPER OF MATERIAL CONTAINED IN THIS
DOCUMENT WARRANTS OR MAKES ANY REPRESEN-TATIONS REGARDING THE
USE, VALIDITY, ACCURACY, OR RELIABILITY OF, OR THE RESULTS OF THE USE
OF, OR OTHER-WISE RESPECTING, THE MATERIAL IN THIS DOCUMENT.
Limitation of Liability
UNDER NO CIRCUMSTANCES SHALL NEXTHOP BE LIABLE FOR ANY DIRECT,
INDIRECT, SPECIAL, INCIDENTAL OR CONSE-QUENTIAL DAMAGES, INCLUDING,
BUT NOT LIMITED TO, LOSS OF DATA OR PROFIT, ARISING OUT OF THE USE, OR
THE
INABILITY TO USE, THE MATERIAL IN THIS DOCUMENT, EVEN IF NEXTHOP OR A
NEXTHOP AUTHORIZED REPRESENTATIVE HAS ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES. IF YOUR USE OF MATERIAL FROM THIS DOCUMENT RESULTS
IN
THE NEED FOR SERVICING, REPAIR OR CORRECTION OF EQUIPMENT OR DATA,
YOU ASSUME ANY COSTS THEREOF. SOME STATES DO NOT ALLOW THE
EXCLUSION OR LIMITATION OF INCIDENTAL OR CONSEQUENTIAL DAMAGES, SO
THE
ABOVE LIMITATION OR EXCLUSION MAY NOT FULLY APPLY TO YOU.
Copyright © ComponentOne, LLC 1991-2002. All Rights Reserved.
BIND: ISC Bind (Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC"))
Copyright 1997-2001, Theo de Raadt: the OpenBSD 2.9 Release
Table Of Contents

Chapter 1 Overview
Summary of Contents 11
What is Quality of Service 12
Internet Bandwidth Management Technologies 12
Overview 12
Superior QoS Solution Requirements 13
Benefits of a Policy-Based Solution 13
How Does Check Point Deliver QoS 14
Features and Benefits 15
Traditional Check Point QoS vs. Check Point QoS Express 16
Workflow 17

Chapter 2 What’s New in Check Point QoS

What’s New in Check Point QoS 19
Support of Windows Groups Using Authenticated QoS 19
Citrix ICA Support 19
Performance Enhancements 19
Load Sharing 20
VPN-1 Net Support 20

Chapter 3 Introduction to Check Point QoS

Check Point QoS’s Innovative Technology 21
Technology Overview 22
Check Point QoS Architecture 24
Basic Architecture 24
Check Point QoS Configuration 26
Concurrent Sessions 28
Interaction with VPN-1Pro and VPN-1 Net 29
Interoperability 29

Chapter 4 Basic QoS Policy Management

Overview 31
Rule Base Management 31
Overview 32
Connection Classification 33
Network Objects 33
Services and Resources 34
Time Objects 34
Bandwidth Allocation and Rules 34
Default Rule 35
QoS Action Properties 36

5
 Example of a Rule Matching VPN Traffic 37
Bandwidth Allocation and Sub-Rules 37
Implementing the Rule Base 39
To Verify and View the QoS Policy 39
To Install and Enforce the Policy 39
To Uninstall the QoS Policy 40
To Monitor the QoS Policy 40

Chapter 5 Check Point QoS Tutorial

Introduction 41
Building and Installing a QoS Policy 42
Step 1: Installing Check Point Modules 44
Step 2: Starting SmartDashboard 44
To Start SmartDashboard 44
Step 3: Determining QoS Policy 47
Step 4: Defining the Network Objects 48
To Define the Gateway London 49
To Define the Interfaces on Gateway London 53
To Define the QoS Properties for the Interfaces on Gateway London 59
Step 5: Defining the Services 60
Step 6: Creating a Rule Base 60
To Create a New Policy Package 61
To Create a New Rules 61
To Modify New Rules 63
Step 7: Installing a QoS Policy 68
Conclusion 69

Chapter 6 Advanced QoS Policy Management

Overview 71
Examples: Guarantees and Limits 71
Per Rule Guarantees 72
Per Connections Guarantees 75
Limits 76
Guarantee - Limit Interaction 76
Differentiated Services (DiffServ) 77
Overview 78
DiffServ Markings for IPSec Packets 78
Interaction Between DiffServ Rules and Other Rules 78
Low Latency Queuing 79
Overview 79
Low Latency Classes 79
Interaction between Low Latency and Other Rule Properties 84
When to Use Low Latency Queuing 84
Low Latency versus DiffServ 85
Authenticated QoS 86
Citrix MetaFrame Support 86
Overview 86
Limitations 87

6 Table of Contents
 Load Sharing 87
Overview 87
Check Point QoS Cluster Infrastructure 89

Chapter 7 Managing Check Point QoS

Defining QoS Global Properties 94
To Modify the QoS Global Properties 94
Specifying Interface QoS Properties 95
To Define the Interface QoS Properties 96
Editing QoS Rule Bases 98
To Create a New Policy Package 99
To Open an Existing Policy Package 99
To Add a Rule 99
To Rename a Rule 101
To Copy, Cut or Paste a Rule 101
To Delete a Rule 102
Modifying Rules 102
Modifying Sources in a Rule 103
Modifying Destinations in a Rule 106
Modifying Services in a Rule 108
Modifying Rule Actions 110
Modifying Tracking for a Rule 115
Modifying Install On for a Rule 115
Modifying Time in a Rule 118
Adding Comments to a Rule 120
Defining Sub-Rules 121
Working with Differentiated Services (DiffServ) 122
To Define a DiffServ Class of Service 123
To Define a DiffServ Class of Service Group 125
To Add QoS Class Properties for Expedited Forwarding 125
To Add QoS Class Properties for Non Expedited Forwarding 126
Working with Low Latency Classes 127
To Implement Low Latency Queuing 128
To Define Low Latency Classes of Service 129
To Define Class of Service Properties for Low Latency Queuing 129
Working with Authenticated QoS 130
To Use Authenticated QoS 130
Managing QoS for Citrix ICA Applications 131
Disabling Session Sharing 132
Modifying your Security Policy 133
Discovering Citrix ICA Application Names 133
Defining a New Citrix TCP Service 136
Adding a Citrix TCP Service to a Rule (Traditional Mode Only) 136
Installing the Security and QoS Policies 137
Managing QoS for Citrix Printing 137
Configuring a Citrix Printing Rule (Traditional Mode Only) 137
Configuring Check Point QoS Topology 138
Viewing the Check Point QoS Modules Status 138

Table of Contents 7
 To Display the Status of Check Point QoS Modules Controlled by the SmartCenter Server
138
Enabling Log Collection 139
To Turn on QoS Logging 139
To Confirm that the Rule is Marked for Logging 140
To Start SmartView Tracker 140

Chapter 8 SmartView Tracker

Overview of Logging 143
Examples of Log Events 147
Connection Reject Log 147
LLQ Drop Log 147
Pool Exceeded Log 148
Examples of Account Statistics Logs 149
General Statistics Data 149
Drop Policy Statistics Data 150
LLQ Statistics Data 150

Chapter 9 Command Line Interface

Check Point QoS Commands 151
Setup 152
fgate Menu 152
Control 153
Monitor 154
Utilities 155

Chapter 10 Check Point QoS FAQ (Frequently Asked Questions)

Questions and Answers 159
Introduction 160
Check Point QoS Basics 160
Other Check Point Products - Support and Management 163
Hardware Support 165
Policy Creation 165
Capacity Planning 167
Protocol Support 168
Installation/Backward Compatibility/Licensing/Versions 169
How do I? 169
General Issues 171

Chapter 11 Deploying Check Point QoS

Deploying Check Point QoS 173
Check Point QoS Topology Restrictions 173
Sample Bandwidth Allocations 175
Frame Relay Network 175

Appendix A Debug Flags

8 Table of Contents
fw ctl debug -m FG-1 Error Codes for Check Point QoS 179

Table of Contents 9
10 Table of Contents
CHAPTER 1

Overview

In This Chapter

What is Quality of Service page 12

Internet Bandwidth Management Technologies page 12
How Does Check Point Deliver QoS page 14
Features and Benefits page 15
Traditional Check Point QoS vs. Check Point QoS Express page 16
Workflow page 17

Summary of Contents
Chapter 1, “Overview”,” presents an overview of Quality of Service and how it is
delivered by Check Point QoS.
Chapter 2, “What’s New in Check Point QoS””, presents an overview of the new
features of FloodGate-1.
Chapter 3, “Introduction to Check Point QoS””, presents an overview of
FloodGate-1, including technologies and architecture.
Chapter 4, “Basic QoS Policy Management”,” describes how to manage a basic
FloodGate-1 QoS Policy Rule Base.
Chapter 5, “Check Point QoS Tutorial”,” is a short tutorial describing how to define a
QoS Policy.
Chapter 6, “Advanced QoS Policy Management”” describes the more advanced policy
management features of Check Point QoS that enable you to refine basic QoS policies.
Chapter 7, “Managing Check Point QoS”,” describes how to manage FloodGate-1,
including modifying and changing policies and rules.

11
What is Quality of Service

Chapter 8, “SmartView Tracker””, describes the features and tools that are available for
monitoring Check Point QoS.
Chapter 9, “Command Line Interface”,” discusses how to work with Check Point QoS
via the Command Line.
Chapter 10, “Check Point QoS FAQ (Frequently Asked Questions)”,” is a compilation
of frequently asked questions and their answers.
Appendix A, “Debug Flags”Debug Flags” is a list of debugging error codes.

What is Quality of Service

Quality of Service is a set of intelligent network protocols and services that are used to
efficiently manage the movement of information through a local or wide area networks.
QoS services sort and classify flows into different traffic classes, and allocate resources to
network traffic flows based on user or application ID, source or destination IP address,
time of day, application specific parameters, and other user-specified variables.
Fundamentally, QoS enables you to provide better service to certain flows. This is done
by either raising the priority of a flow or limiting the priority of another flow.

Internet Bandwidth Management Technologies

In This Section

Overview page 12
Superior QoS Solution Requirements page 13
Benefits of a Policy-Based Solution page 13

Overview
When you connect your network to the Internet, it is most important to make efficient
use of the available bandwidth. An effective bandwidth management policy ensures that
even at times of network congestion, bandwidth is allocated in accordance with
enterprise priorities.
In the past, network bandwidth problems have been addressed either by adding more
bandwidth (an expensive and usually short term “solution”) or by router queuing,
which is ineffective for complex modern Internet protocols.

12
 Superior QoS Solution Requirements

Superior QoS Solution Requirements

In order to provide effective bandwidth management, a bandwidth management tool
must track and control the flow of communication passing through, based on
information derived from all communication layers and from other applications.
An effective bandwidth management tool must address all of the following issues:
• Fair Prioritization
It is not sufficient to simply prioritize communications, for example, to specify a
higher priority for HTTP than for SMTP. The result may well be that all
bandwidth resources are allocated to one service and none to another. A bandwidth
management tool must be able to divide the available resources so that more
important services are allocated more bandwidth, but all services are allocated some
bandwidth.
• Minimum Bandwidth
A bandwidth management tool must be able to guarantee a service’s minimum
required bandwidth. It must also be able to allocate bandwidth preferentially, for
example, to move a company’s video conference to the “head of the line” in
preference to all other internet traffic.
• Classification
A bandwidth management tool must be able to accurately classify communications.
However, simply examining a packet in isolation does not provide all the
information needed to make an informed decision. State information — derived
from past communications and other applications — is also required. A packet’s
contents, the communication state and the application state (derived from other
applications) must all be considered when making control decisions.

Benefits of a Policy-Based Solution

Based on the principles discussed in the previous section, there are basically three ways
to improve the existing best-effort service that enterprise networks and ISPs deliver
today:
• Add more bandwidth to the network.
• Prioritize network traffic at the edges of the network.
• Guarantee QoS by enforcing a set of policies that are based on business priorities
(policy-based network management) throughout the network.
Of these, only policy-based network management provides a comprehensive QoS
solution by:
• Using policies to determine the level of service that applications or customers need.
• Prioritizing network requests.

Chapter 1 Overview 13
How Does Check Point Deliver QoS

• Guaranteeing levels of service.

How Does Check Point Deliver QoS

Check Point QoS (previously called FloodGate-1), a policy-based QoS management
solution from Check Point Software Technologies Ltd., satisfies your needs for a
bandwidth management solution. Check Point QoS is a unique, software-only based
application that manages traffic end-to-end across networks, by distributing
enforcement throughout network hardware and software.
Check Point QoS enables you to prioritize business-critical traffic, such as ERP,
database and Web services traffic, over less time-critical traffic. Check Point QoS allows
you to guarantee bandwidth and control latency for streaming applications, such as
Voice over IP (VoIP) and video conferencing. With highly granular controls, Check
Point QoS also enables guaranteed or priority access to specific employees, even if they
are remotely accessing network resources through a VPN tunnel.
Check Point QoS is deployed with VPN-1® Pro. These integrated solutions provide
QoS for both VPN and unencrypted traffic to maximize the benefit of a secure,
reliable, low-cost VPN network.
FIGURE 1-1 Check Point QoS Deployment

Check Point QoS leverages the industry's most advanced traffic inspection and
bandwidth control technologies. Check Point-patented Stateful Inspection technology
captures and dynamically updates detailed state information on all network traffic. This
state information is used to classify traffic by service or application. After a packet has

14
 Benefits of a Policy-Based Solution

been classified, Check Point QoS applies QoS to the packet by means of an innovative,
hierarchical, Weighted Fair Queuing (WFQ) algorithm to precisely control bandwidth
allocation.

Features and Benefits

Check Point QoS provides the following features and benefits:
• Flexible QoS policies with weights, limits and guarantees: Check Point QoS
enables you to develop basic policies specific to your requirements. These basic
policies can be modified at any time to incorporate any of the Advanced Check
Point QoS features described in this section.
• Integration with VPN-1 Pro or VPN-1 Net: Optimize network performance for
VPN and unencrypted traffic: The integration of an organization’s security and
bandwidth management policies enables easier policy definition and system
configuration.
• Performance analysis through SmartView Tracker: monitor the performance of
your system by means of log entries recorded in SmartView Tracker.
• Integrated DiffServ support: add one or more Diffserv Classes of Service to the
QoS Policy Rule Base.
• Integrated Low Latency Queuing: define special classes of service for “delay
sensitive” applications like voice and video to the QoS Policy Rule Base.
• Integrated Authenticated QoS: provide QoS for end-users in dynamic IP
environments, such as remote access and DHCP environments.
• Integrated Citrix MetaFrame support: deliver a QoS solution for the Citrix ICA
protocol.
• No need to deploy separate VPN, Firewall and QoS devices: Check Point QoS and
VPN-1 Pro share a similar architecture and many core technology components,
therefore users can utilize the same user-defined network objects in both solutions.
• Proactive management of network costs: Check Point QoS’s monitoring systems
enable you to be proactive in managing your network and thus controlling network
costs.
• Support for end-to-end QoS for IP networks: Check Point QoS offers complete
support for end-to-end QoS for IP networks by distributing enforcement
throughout network hardware and software.

Chapter 1 Overview 15
Traditional Check Point QoS vs. Check Point QoS Express

Traditional Check Point QoS vs. Check Point QoS Express

Both Traditional and Express modes of Check Point QoS are included in every product
installation. Express mode enables you to define basic policies quickly and easily and
thus “get up and running” without delay. Traditional mode incorporates the more
advanced features of Check Point QoS.
You can specify whether you choose Traditional over Express or vice versa, each time
you install a new policy.
TABLE 1-1 shows a comparative table of the features of the Traditional and Express
modes of Check Point QoS.
TABLE 1-1 Check Point QoS Traditional Features vs. Check Point QoS Express Features

Feature Check Point Check Point Find out more on

QoS QoS Express page...
Traditional
Weights * * “Weight” on page 34
Limits (whole rule) * * “Limits” on page 35
Guarantees (whole rule) * * “Guarantees” on page 35
Authenticated QoS * “Authenticated QoS” on
page 86
Logging * * “Overview of Logging”
on page 143
Accounting * *
Support of platforms and HW * *
accelerator
High Availability and Load * *
Sharing
Guarantee (Per connection) * “Per Connections
Guarantees” on page 75
Limit (Per connection) * “Limits” on page 35
LLQ (controlling packet delay * “Low Latency Queuing”
in Check Point QoS) on page 79
DiffServ * “Differentiated Services
(DiffServ)” on page 77
Sub-rules *
Matching by URI resources *

16
 Benefits of a Policy-Based Solution

TABLE 1-1 Check Point QoS Traditional Features vs. Check Point QoS Express Features

Feature Check Point Check Point Find out more on

QoS QoS Express page...
Traditional
Matching by DNS string *
TCP Retransmission *
Detection Mechanism
(RDED)
Matching Citrix ICA *
Applications

Workflow
The following workflow shows both the basic and advanced steps that the System
Administrator may follow in the installation, setup and operational procedures of Check
Point QoS:
FIGURE 1-2 Workflow Steps

1 Verify that Check Point QoS is installed on top of VPN-1Pro or VPN-1 Net.
2 Start SmartDashboard. See “Step 2: Starting SmartDashboard” on page 44.
3 Define the Global Properties of Check Point QoS. See “Defining QoS Global
Properties” on page 94.
4 Define the Check Point Gateway’s Network Objects. See the SmartCenter Guide.

Chapter 1 Overview 17
Workflow

5 Setup the basic rules and sub-rules governing the allocation of QoS flows on the
network. See “Editing QoS Rule Bases” on page 98. After the basic rules have
been defined, you may modify these rules to add any of the more advanced features
described in step 8.
6 Implement the Rule Base. See “Implementing the Rule Base” on page 39.
7 Enable log collection and monitor the system. See “Enabling Log Collection” on
page 139.
8 Modify the rules defined in step 4 by adding any of the following advanced
features:
• DiffServ Markings. See “Working with Differentiated Services (DiffServ)” on
page 122.
• Define Low Latency Queuing. See “Working with Low Latency Classes” on
page 127.
• Define Authenticated QoS. See “Working with Authenticated QoS” on page
130
• Define Citrix ICA Applications. See “Managing QoS for Citrix ICA
Applications” on page 131.

18
CHAPTER 2

What’s New in Check

Point QoS

In This Chapter

What’s New in Check Point QoS page 19

What’s New in Check Point QoS

Support of Windows Groups Using Authenticated QoS
This new feature allows QoS where the QoS module uses already defined Windows
Groups. It does so by querying the UserAuthority Server. Consult the UserAuthority
Guide section of the SecureAgent for more technical information.

Citrix ICA Support

Introducing the QoS solution for Citrix ICA protocol:
• Classifying all ICA applications running over Citrix through layer 7.
• Differentiating between the Citrix traffic based on ICA published applications to
ICA printing traffic.

Performance Enhancements
• NGX R60 includes enhanced throughput capabilities. The maximum throughput
supported by Check Point QoS (depending on the type of traffic):
• Long UDP packets have increased:
• more than 1.1Gbps in Express Mode, or

• up to 890Mbps in Traditional Mode

• Real-world traffic has increased:

19
What’s New in Check Point QoS

• up to 330Mbps in Express Mode, or

• up to 255Mbps in Traditional Mode
These numbers were measured on a high performance SecurePlatform server.

Load Sharing
We present the first QoS fault-tolerant solution for cluster load sharing that deploys a
unique distributed WFQ bandwidth management technology. You can specify a
unified QoS policy per virtual interface of the cluster. The resulting bandwidth
allocation will be identical to that obtained by installing the same policy on a single
server.

VPN-1 Net Support

Check Point QoS can be installed along with the VPN-1 Net product.

20
CHAPTER 3

Introduction to Check
Point QoS

In This Chapter

Check Point QoS’s Innovative Technology page 21

Check Point QoS Architecture page 24
Interaction with VPN-1Pro and VPN-1 Net page 29

Check Point QoS’s Innovative Technology

FloodGate-1 is a bandwidth management solution for Internet and Intranet gateways
that enables network administrators to set bandwidth policies to solve or alleviate
network problems like the bandwidth congestion at network access points. The overall
mix of traffic is dynamically controlled by managing bandwidth usage for entire classes
of traffic, as well as individual connections. FloodGate-1 controls both inbound and
outbound traffic flows.
Network traffic can be classified by Internet service, source or destination IP address,
Internet resource (for example, specific URL designators), user or traffic direction
(inbound or outbound). A Check Point QoS Policy consists of rules that specify the
weights, limits and guarantees that are applied to the different classifications of traffic.
A rule can have multiple sub-rules, enabling an administrator to define highly granular
Bandwidth Policies.
FloodGate-1 provides its real benefits when the network lines become congested.
Instead of allowing all traffic to flow arbitrarily, FloodGate-1 ensures that important
traffic takes precedence over less important traffic so that the enterprise can continue to
function with minimum disruption, despite network congestion. FloodGate-1 ensures
that an enterprise can make the most efficient use of a congested network.

21
Check Point QoS’s Innovative Technology

FloodGate-1 is completely transparent to both users and applications.

FloodGate-1 implements four innovative technologies:
• Stateful Inspection: FloodGate-1 incorporates Check Point’s patented Stateful
Inspection technology to derive complete state and context information for all
network traffic.
• Intelligent Queuing Engine: This traffic information derived by the Stateful
Inspection technology is used by FloodGate-1’s Intelligent Queuing Engine (IQ
EngineTM) to accurately classify traffic and place it in the proper transmission queue.
The network traffic is then scheduled for transmission based on the QoS Policy.
The IQ Engine includes an enhanced, hierarchical Weighted Fair Queuing (WFQ)
algorithm to precisely control the allocation of available bandwidth and ensure
efficient line utilization.
• WFRED (Weighted Flow Random Early Drop): FloodGate-1 makes use of
WFRED, a mechanism for managing packet buffers that is transparent to the user
and requires no pre-configuration.
• RDED (Retransmission Detection Early Drop): FloodGate-1 makes use of RDED,
a mechanism for reducing the number of retransmits and retransmit storms. This
Check Point mechanism, drastically reduces retransmit counts, greatly improving
the efficiency of the enterprise’s existing lines. The increased bandwidth that
FloodGate-1 makes available to important applications comes at the expense of less
important (or completely unimportant) applications. As a result purchasing more
bandwidth can be significantly delayed.

Technology Overview
FloodGate-1’s four innovative technologies are discussed in more detail in this section.

Stateful Inspection
Employing Stateful Inspection technology, FloodGate-1 accesses and analyzes data
derived from all communication layers. This state and context data is stored and
updated dynamically, providing virtual session information for tracking both
connection-oriented and connectionless protocols (for example, UDP-based
applications). Cumulative data from the communication and application states, network
configuration and bandwidth allocation rules are used to classify communications.
Stateful Inspection enables FloodGate-1 to parse URLs and set priority levels based on
file types. For example, FloodGate-1 can identify HTTP file downloads with *.exe or
*.zip extensions and allocates bandwidth accordingly.

22
 Technology Overview

Intelligent Queuing Engine

FloodGate-1 uses an enhanced WFQ algorithm to manage bandwidth allocation. A
FloodGate-1 packet scheduler moves packets through a dynamically changing
scheduling tree at different rates in accordance with the QoS Policy. High priority
packets move through the scheduling tree more quickly than low priority packets.
Check Point QoS leverages TCP’s throttling mechanism to automatically adjust
bandwidth consumption per individual connections or classes of traffic. Traffic bursts
are delayed and smoothed by FloodGate-1’s packet scheduler, holding back the traffic
and forcing the application to fit the traffic to the QoS Policy. By intelligently delaying
traffic, the IQ Engine effectively controls the bandwidth of all IP traffic.
The preemptive IQ Engine responds immediately to changing traffic conditions and
guarantees that high priority traffic always takes precedence over low priority traffic.
Accurate bandwidth allocation is achieved even when there are large differences in the
weighted priorities (for example 50:1). In addition, since packets are always available
for immediate transmission, the IQ Engine provides precise bandwidth control for both
inbound and outbound traffic, and ensures 100% bandwidth utilization during periods
of congestion. In addition, in Traditional mode it uses per connection queuing to
ensure that every connection receives its fair share of bandwidth.

WFRED (Weighted Flow Random Early Drop)

WFRED is a mechanism for managing the packet buffers of FloodGate-1. WFRED
does not need any preconfiguring. It adjusts automatically and dynamically to the
situation and is transparent to the user.
Because the connection of a LAN to the WAN creates a bottleneck, packets that arrive
from the LAN are queued before being retransmitted to the WAN. When traffic in the
LAN is very intense, queues may become full and packets may be dropped arbitrarily.
Dropped packets may reduce the throughput of TCP connections, and the quality of
streaming media.
WFRED prevents FloodGate-1’s buffers from being filled by sensing when traffic
becomes intense and dropping packets selectively. The mechanism considers every
connection separately, and drops packets according to the connection characteristics
and overall state of the buffer.
Unlike mechanisms such as RED/WRED, which rely on the TOS byte in the IP
header (which is seldom used), WFRED queries FloodGate-1 as to the priority of the
connection, and then uses this information. WFRED protects “fragile” connections
from more “aggressive” ones, whether they are TCP or UDP, and always leaves some
buffer space for new connections to open.

Chapter 3 Introduction to Check Point QoS 23

Check Point QoS Architecture

RDED (Retransmit Detect Early Drop)

TCP exhibits extreme inefficiency under certain bandwidth and latency conditions. For
example, the bottleneck that results from the connection of a LAN to the WAN causes
TCP to retransmit packets. RDED prevents inefficiencies by detecting retransmits in
TCP streams and preventing the transmission of redundant packets when multiple
copies of a packet are concurrently queued on the same flow. The result is a dramatic
reduction of retransmit counts and positive feedback retransmit loops. Implementing
RDED requires the combination of intelligent queuing and full reconstruction of TCP
streams, capabilities that exist together only in FloodGate-1.

Check Point QoS Architecture

In This Section

Basic Architecture page 24

Check Point QoS Architecture page 24
Check Point QoS Configuration page 26

Basic Architecture
The architecture and flow control of Check Point QoS is similar to Firewall.
Check Point QoS has three components:
• SmartConsole
• SmartCenter Server
• Module
The components can be installed on one machine or in a distributed configuration on
a number of machines.
Bandwidth policy is created using SmartDashboard. The policy is downloaded to the
SmartCenter Server where it is verified and downloaded to the QoS Modules using
CPD (Check Point Daemon), which is run on the module and the SmartCenter Server.
The QoS module uses the Firewall chaining mechanism (see below) to receive, process
and send packets. QoS uses a proprietary classifying and rule-matching infrastructure to
examine a packet. Logging information is provided using Firewall kernel API.

QoS Module
The major role of the QoS module is to implement a QoS policy at network access
points and control the flow of inbound and outbound traffic. It includes two main
parts:

24
 Basic Architecture

• QoS kernel driver

• QoS daemon

QoS Kernel Driver

The kernel driver is the heart of QoS operations. It is in the kernel driver that IP
packets are examined, queued, scheduled and released, enabling QoS traffic control
abilities. Utilizing Firewall kernel module services, QoS functionality is a part of the
cookie chain, a Check Point infrastructure mechanism that allows modules to operate
on each packet as it travels from the link layer (the machine network card driver) to the
network layer (its IP stack), or vice versa.

QoS Daemon (fgd50)

The QoS daemon is a user mode process used to perform tasks that are difficult for the
kernel. It currently performs 2 tasks for the kernel (using Traps):
• Resolving DNS for the kernel (used for Rule Base matching).
• Resolving Authenticated Data for an IP (using UserAuthority - again for Rule Base
matching).
• In CPLS configuration, the daemon updates the kernel of any change in the cluster
status. For example, if a cluster member goes down the daemon recalculates the
relative loads of the modules and updates the kernel.

QoS SmartCenter Server

The QoS SmartCenter Server is an add-on to the SmartCenter Server (fwm). The
SmartCenter Server, which is controlled by Check Point SmartConsole clients,
provides general services to Check Point QoS and is capable of issuing QoS functions
by running QoS command line utilities. It is used to configure the bandwidth policy
and control QoS modules. A single SmartCenter Server can control multiple QoS
modules running either on the same machine as the SmartCenter Server or on remote
machines. The SmartCenter Server also manages the Check Point Log Repository and
acts as a log server for the SmartView Tracker. The SmartCenter server is a user mode
process that communicates with the module using CPD.

QoS SmartConsole
The main SmartConsole application is Check Point SmartDashboard. By creating
"bandwidth rules" the SmartDashboard allows system administrators to define a
network QoS policy to be enforced by Check Point QoS.
Other SmartConsole clients are the SmartView Tracker - a log entries browser; and
SmartView Status which displays status information about active QoS modules and
their policies.

Chapter 3 Introduction to Check Point QoS 25

Check Point QoS Architecture

FIGURE 3-1 Basic Architecture - Check Point QoS Components

Check Point QoS in SmartDashboard

Check Point SmartDashboard is used to create and modify the QoS Policy and define
the network objects and services. If both VPN-1Pro and Check Point QoS are
licensed, they each have a tab in SmartDashboard.
FIGURE 3-2 QoS Rules in SmartDashboard

The QoS Policy rules are displayed in both the SmartDashboard Rule Base, on the
right side of the window, and the QoS tree, on the left (see FIGURE 3-2).

Check Point QoS Configuration

The SmartCenter Server and the QoS Module can be installed on the same machine or
on two different machines. When they are installed on different machines, the
configuration is known as distributed (see FIGURE 3-3).

26
 Check Point QoS Configuration

FIGURE 3-3 Distributed FloodGate-1 Configuration

FIGURE 3-3 shows a distributed configuration, in which one SmartCenter Server

(consisting of a SmartCenter Server and a SmartConsole) controls four QoS Modules,
which in turn manage bandwidth allocation on three FloodGated lines.
A single SmartCenter Server can control and monitor multiple QoS Modules. The QoS
Module operates independently of the SmartCenter Server. QoS Modules can operate
on additional Internet gateways and interdepartmental gateways.

Client/Server Interaction
The SmartConsole and the SmartCenter Server can be installed on the same machine
or on two different machines. When they are installed on two different machines,
FloodGate-1 implements the Client/Server model, in which a SmartConsole controls a
SmartCenter Server running on another workstation.

Chapter 3 Introduction to Check Point QoS 27

Check Point QoS Architecture

FIGURE 3-4 QoS Client/Server Configuration

In the configuration depicted in FIGURE 3-4, the functionality of the SmartCenter

Server is divided between two workstations (Tower and Bridge). The SmartCenter
Server, including the database, is on Tower. The SmartConsole is on Bridge.
The user, working on Bridge, maintains the QoS Policy and database, which reside on
Tower. The QoS Module on London enforces the QoS Policy on the FloodGated line.
The SmartCenter Server is started with the cpstart command, and must be running if
you wish to use the SmartConsole on one of the client machines.
A SmartConsole can manage the Server (that is, run the SmartConsole to communicate
with a SmartCenter Server) only if both the administrator running the SmartConsole
and the machine on which the SmartConsole is running have been authorized to access
the SmartCenter Server.
In practice, this means that the following conditions must be met:
• The machine on which the Client is running is listed in the
$FWDIR/conf/gui-clients file.
You can add or delete SmartConsoles using the Check Point configuration
application (cpconfig).
• The administrator (user) running the GUI has been defined for the SmartCenter
Server.
You can add or delete administrators using the Check Point configuration
application (cpconfig).

Concurrent Sessions
In order to prevent more than one administrator from modifying a QoS Policy at the
same time, FloodGate-1 implements a locking mechanism. All but one open policy is
‘Read Only’.

28
 Interoperability

Interaction with VPN-1Pro and VPN-1 Net

In This Section

Interoperability page 29

Interoperability
FloodGate-1 must be installed together with VPN-1 Pro or VPN-1 Net on the same
system. FloodGate-1 is installed on top of a VPN-1 Pro or VPN-1 Net. Because
FloodGate-1 and VPN-1 Pro or VPN-1 Net share a similar architecture and many core
technology components, users can utilize the same user-defined network objects in
both solutions. This integration of an organization’s security and bandwidth
management policies enables easier policy definition and system configuration. Both
products can also share state table information which provides efficient traffic inspection
and enhanced product performance. FloodGate-1’s tight integration with VPN-1 Pro
or VPN-1 Net provides the unique ability to enable users that deploy the solutions in
tandem to define bandwidth allocation rules for encrypted and
network-address-translated traffic.

SmartCenter Server
If FloodGate-1 is installed on a machine on which VPN-1 Pro or VPN-1 Net is also
installed, FloodGate-1 uses the VPN-1 Pro or VPN-1 Net SmartCenter Server and
shares the same objects database (network objects, services and resources) with VPN-1
Pro or VPN-1 Net. Some types of objects have properties which are product specific.
For example, a VPN-1 Pro has encryption properties which are not relevant to
FloodGate-1, and a FloodGate-1 network interface has speed properties which are not
relevant to VPN-1 Pro.

Chapter 3 Introduction to Check Point QoS 29

Interaction with VPN-1Pro and VPN-1 Net

30
CHAPTER 4

Basic QoS Policy

Management

In This Chapter

Overview page 31
Rule Base Management page 31
Implementing the Rule Base page 39

Overview
This chapter describes the basic QoS policy management that is required to enable you
to define and implement a working QoS Rule Base. More advanced QoS policy
management features are discussed in Chapter 6, “Advanced QoS Policy
Management””.

Rule Base Management

In This Section

Overview page 32
Connection Classification page 33
Services and Resources page 34
Time Objects page 34
Bandwidth Allocation and Rules page 34
Default Rule page 35

31
Rule Base Management

QoS Action Properties page 36

Example of a Rule Matching VPN Traffic page 37
Bandwidth Allocation and Sub-Rules page 37

Overview
QoS policy is implemented by defining an ordered set of rules in the Rule Base. The
Rule Base specifies what actions are to be taken with the data packets. It specifies the
source and destination of the communication, what services can be used, and at what
times, whether to log the connection and the logging level.
The Rule Base comprises the rules you create and a default rule (see Default Rule
page 35). The default rule is automatically created with the Rule Base. It can be
modified but cannot be deleted. The fundamental concept of the Rule Base is that
unless other rules apply, the default rule is applied to all data packets. The default rule
is therefore always the last rule in the Rule Base.
A very important aspect of Rule Base management is reviewing SmartView Tracker
traffic logs and particular attention should be paid to this aspect of management.
Check Point QoS works by inspecting packets in a sequential manner. When Check
Point QoS receives a packet belonging to a connection, it compares it against the first
rule in the Rule Base, then the second, then the third, and so on. When it finds a rule
that matches, it stops checking and applies that rule. If the matching rule has sub-rules
the packets are then compared against the first sub-rule, then the second and so on until
it finds a match. If the packet goes through all the rules or sub-rules without finding a
match, then the default rule or default sub-rule is applied. It is important to understand
that the first rule that matches is applied to the packet, not the rule that best matches.
After you have defined your network objects, services and resources, you can use them
in building a Rule Base. For installation instructions and instructions on building a
Rule Base, see “Editing QoS Rule Bases” on page 98.
The QoS Policy Rule Base concept is similar to the Security Policy Rule Base. General
information about Policy Rule Bases can be found in the SmartCenter Guide.

32
 Connection Classification

FIGURE 4-1 SmartDashboard Rule Base Window

Note - It is best to organize lists of objects (network objects and services) in groups
rather than in long lists. Using groups gives you a better overview of your QoS Policy and
leads to a more readable Rule Base. In addition, objects added to groups are automatically
included in the rules.

Connection Classification
A connection is classified according to four criteria:
• Source: A set of network objects, including specific computers, entire networks,
user groups or domains.
• Destination: A set of network objects, including specific computers, entire
networks or domains.
• Service: A set of IP services, TCP, UDP, ICMP or URLs.
• Time: Specified days or time periods.

Network Objects
Network objects serve as the sources and destinations that are defined in QoS Policy
rules. The network objects that can be used in FloodGate-1 rules include workstations,
networks, domains, and groups.
Information about network objects can be found in the SmartCenter Guide.

User Groups
Check Point QoS allows you to define User Groups that are comprised of predefined
users. For example, all the users in the marketing department can be grouped together
in a User Group called Marketing. when defining a Source in a rule you can then use
this group as a possible Source, instead of adding individual users to the Source of the
rule.

Chapter 4 Basic QoS Policy Management 33

Rule Base Management

Services and Resources

FloodGate-1 allows you to define QoS rules, not only based on the source and
destination of each communication, but also according to the service requested. The
services that can be used in FloodGate-1 rules include TCP, Compound TCP, UDP,
ICMP and Citrix TCP services, IP services
Resources can also be used in a FloodGate-1 Rule Base. They must be of type URI for
QoS.

Time Objects
Check Point QoS allows you to define Time objects that are used is defining the time
that a rule is operational. Time objects can be defined for specific times and/or for
specific days. The days can further be divided into days of the month or specific days of
the week.

Bandwidth Allocation and Rules

A rule can specify three factors to be applied to bandwidth allocation for classified
connections:

Weight
Weight is the relative portion of the available bandwidth that is allocated to a rule.
To calculate what portion of the bandwidth the connections matched to a rule receive,
use the following formula:
this rule’s portion = this rule’s weight / total weight of all rules with open connections
For example, if this rule’s weight is 12 and the total weight of all the rules under which
connections are currently open is 120, then all the connections open under this rule are
allocated 12/120 (or 10%) of the available bandwidth.
In practice, a rule may get more than the bandwidth allocated by this formula, if other
rules are not using their maximum allocated bandwidth.
Unless a per connection limit or guarantee is defined for a rule, all connections under a
rule receive equal weight.
Allocating bandwidth according to weights ensures full utilization of the line even if a
specific class is not using all of its bandwidth. In such a case, the left over bandwidth is
divided among the remaining classes in accordance with their relative weights. Units
are configurable, see “Defining QoS Global Properties” on page 94.

34
 Default Rule

Guarantees
A guarantee allocates a minimum bandwidth to the connections matched with a rule.
Guarantees can be defined for:
• the sum of all connections within a rule
A total rule guarantee reserves a minimum bandwidth for all the connections under
a rule combined. The actual bandwidth allocated to each connection depends on
the number of open connections that match the rule. The total bandwidth allocated
to the rule can be no less than the guarantee, but the more connections that are
open, the less bandwidth each one receives.
• individual connections within a rule
A per connection guarantee means that each connection that matches the particular rule
is guaranteed a minimum bandwidth.
Although weights do in fact guarantee the bandwidth share for specific connections,
only a guarantee allows you to specify an absolute bandwidth value.

Limits
A limit specifies the maximum bandwidth that is assigned to all the connections
together. A limit defines a point beyond which connections under a rule are not
allocated bandwidth, even if there is unused bandwidth available.
Limits can also be defined for the sum of all connections within a rule or for individual
connections within a rule.
For more information on weights, guarantees and limits, see “Action Type” on page
36.

Note - Bandwidth allocation is not fixed. As connections are opened and closed,
FloodGate-1 continuously changes the bandwidth allocation to accommodate competing
connections, in accordance with the QoS Policy.

Default Rule
A default rule is automatically added to each QoS Policy Rule Base, and assigned the
weight specified in the QoS (FloodGate-1) page of the Global Properties window. You
can modify the weight, but you cannot delete the default rule (see “Weight” on page
34).
The default rule applies to all connections not matched by the other rules or sub-rules
in the Rule Base.

Chapter 4 Basic QoS Policy Management 35

Rule Base Management

In addition, a default rule is automatically added to each group of sub-rules, and applies
to connections not classified by the other sub-rules in the group (see “To Verify and
View the QoS Policy” on page 39).

QoS Action Properties

The restrictions on bandwidth for connections to which a rule applies are defined in
the QoS Action Properties window.

Action Type
By this stage, you should already have decided whether your policy is Traditional mode
or Express mode, see “Traditional Check Point QoS vs. Check Point QoS Express” on
page 16.
You can select one of the following Action Types:
• Simple
• Advanced
TABLE 4-1 shows which Action Types you can select in Traditional or Express modes.
TABLE 4-1 Action Types Available

Action Type Traditional Mode Express Mode

Simple Yes Yes

Advanced Yes No

Simple

The following actions are available:

• Apply rule to encrypted traffic only
• Rule weight
• Rule limit
• Rule guarantee

Advanced

The same actions that are available in Simple mode are available in Advanced mode
with the addition of the following:
• Per connection limit
• Per rule guarantee
• Per connection guarantee

36
 Example of a Rule Matching VPN Traffic

• Number of permanent connections

• Accept additional connections

Example of a Rule Matching VPN Traffic

VPN traffic is traffic that is encrypted in the same gateway by Check Point VPN. VPN
traffic does not refer to traffic that was encrypted by a non-Check Point product prior
to arriving at this gateway. This type of traffic can be matched using the IPSec service.
When Apply rule only to encrypted traffic is checked in the QoS Action Properties
window, only VPN traffic is matched to the rule. If this field is not checked, all types
of traffic (both VPN and non-VPN) are matched to the rule.
Use the Apply rule only to encrypted traffic field to build a Rule Base in which you
define QoS actions for VPN traffic which are different than the actions that are applied
to non-VPN traffic. Since Check Point QoS uses the First Rule Match concept, the
VPN traffic rules should be defined as the top rules in the Rule Base. Below them rules
which apply to all types of traffic should be defined. Other types of traffic skip the top
rules and match to one of the non-VPN rules defined below the VPN traffic rules. In
order to completely separate VPN traffic from non-VPN traffic, define the following
rule at the top of the QoS Rule Base:
TABLE 4-2 VPN Traffic Rule

Name Source Dest Service Action

VPN rule Any Any Any VPN Encrypt, and

other configured
actions

All the VPN traffic is matched to this rule. The rules following this VPN Traffic Rule
are then matched only by non-VPN traffic. You can define sub-rules below the VPN
Traffic rule that classify the VPN traffic more granularly.

Bandwidth Allocation and Sub-Rules

When a connection is matched to a rule with sub-rules, a further match is sought
among the sub-rules. If none of the sub-rules apply, the default rule for the specific
group of sub-rules is applied (see “Default Rule” on page 35).
Sub-rules can be nested, meaning that sub-rules themselves can have sub-rules. The
same rules then apply to the nested sub-rules. If the connection matches a sub-rule that
has sub-rules itself, a further match is sought among the nested sub-rules. Again if none
of the sub-rules apply, the default rule for the specific group of sub-rules is applied.

Chapter 4 Basic QoS Policy Management 37

Rule Base Management

Bandwidth is allocated on a top/down approach. This means that sub-rules cannot

allocate more bandwidth to a matching rule, than the rule in which the sub-rule is
located. A nested sub-rule, therefore, cannot allocate more bandwidth than the sub-rule
in which it is located.
A Rule Guarantee must likewise always be greater than or equal to the Rule Guarantee
of any sub-rule within that rule. The same applies to Rule Guarantees in sub-rules and
their nested sub-rules., as shown in the following example.
Example:

TABLE 4-3 Bandwidth Allocation in Nested Sub-Rules

Rule Name Source Destination Service Action

Rule A Any Any ftp Rule Guarantee -

100KBps
Weight 10
Start of Sub-Rule A

Rule A1 Client-1 Any ftp Rule Guarantee -

100KBps
Weight 10
Start of Sub-Rule A1

Rule A1.1 Any Any ftp Rule Guarantee -

80KBps
Weight 10
Rule A1.2 Any Any ftp Weight 10
End of
Sub-Rule A1

Rule A2 Client-2 Any ftp Weight 10

End of
Sub-Rule A

Rule B Any Any http Weight 30

In this example any extra bandwidth from the application of Rule A1.1 is applied to
Rule A2 before it is applied to Rule A1.2.

38
 To Verify and View the QoS Policy

Implementing the Rule Base

When you have defined the desired rules, you should perform a heuristic check on the
Rule Base to check that the rules are consistent. If a Rule Base fails the verification, an
appropriate message is displayed.
You must save the Policy Package before verifying. Otherwise, changes made since the
last save will not be checked.
After verifying the correctness of the Rule Base, it must be installed on the
FloodGate-1 Modules that will enforce it. When you install a QoS Policy, the policy is
downloaded to these QoS Modules. There must be a QoS Module running on the
object which receives the QoS Policy.

Note - The QoS Module machine and the SmartCenter module machine must be properly
configured before a QoS Policy can be installed.

In This Section

To Verify and View the QoS Policy page 39

To Install and Enforce the Policy page 39
To Uninstall the QoS Policy page 40
To Monitor the QoS Policy page 40

To Verify and View the QoS Policy

1 Select Policy>Verify to perform a heuristic check on the Rule Base to check that
the rules are consistent.
2 Select Policy>View to view the generated rules as ASCII text.

To Install and Enforce the Policy

Perform the following steps in order to install and enforce the QoS policy:
1 Once the rule base is complete, select Install from the Policy menu. The Install
Policy window is displayed. Specify the QoS modules on which you would like to
install your new QoS policy. By default, all QoS modules are already selected. (In
order for an object to be a QoS module, it needs to have FloodGate-1 checked
under Check Point Products in the Object Properties window).
The objects in the list are those that have FloodGate-1 Installed checked in their
definition (see “Specifying Interface QoS Properties” on page 95).

Chapter 4 Basic QoS Policy Management 39

Implementing the Rule Base

You may deselect and reselect specific items, if you wish. The QoS Policy is not
installed on unselected items.
2 Click OK to install the QoS Policy on all selected hosts. The installation progress
window is displayed.

To Uninstall the QoS Policy

You can uninstall QoS Policy from any or all of the QoS Modules in which it is
installed.
1 Choose Uninstall from the Policy menu to remove the QoS Policy from the
selected QoS Module. The Install Policy window is displayed.
2 Deselect those QoS Modules from which you would like to uninstall the QoS
policy.
3 Click OK.

To Monitor the QoS Policy

Check Point SmartView Monitor allows you to monitor traffic through a floodgated
interface. For more information, see SmartView Monitor Guide.

40
CHAPTER 5

Check Point QoS

Tutorial

In This Chapter

Introduction page 41
Building and Installing a QoS Policy page 42
Conclusion page 69

Introduction
This chapter presents a step by step guide to building and installing a QoS Policy in
Check Point QoS. This tutorial is based on the network configuration shown in
FIGURE 5-1 on page 42.
This tutorial is based on a simple network configuration, but working through it will
familiarize you with the many issues involved in building and installing a FloodGate-1
QoS Policy. Each step in the process is described in detail so that by the end of this
tutorial you will have developed a practical knowledge of building and installing a
usable QoS policy.
The tutorial walks you through the steps involved in physically installing a network,
and then introduces you to SmartDashboard and Check Point QoS, in which you
configure the network and implement QoS policy.

41
Building and Installing a QoS Policy

FIGURE 5-1 Example Network Configuration

This example shows a typical network configuration for an organization with offices
located in London, Oxford and Cambridge. The Check Point QoS Module is located
in London where the gateway to the Internet will comprise 3 interfaces. The
SmartCenter Server is located at Oxford while the SmartConsole is installed at
Cambridge. Within the private local network there are the Marketing and Engineering
departments. In this tutorial you are shown how a QoS policy is implemented to
regulate and optimize the flow in Internet traffic to these departments.

Building and Installing a QoS Policy

The following steps represent the workflow that must be followed in order to build and
install a QoS Policy on the network shown in FIGURE 5-1. Each of these steps is then
described in detail in the sections that follow:

42
1 Install the appropriate Check Point Modules on each machine, as needed (see
TABLE 5-1).
TABLE 5-1 Check Point Modules to Install on Each Machine

Computer Function Check Point Module to

install
London QoS Module; the Gateway QoS Module
to the Internet VPN-1 Pro Module (required)
Oxford SmartCenter Server SmartCenter Server, QoS
Add-on
Cambridge SmartConsole SmartDashboard

Note - In order to manage QoS modules, you need to install Check Point QoS on the
SmartCenter Server as well as on the module.

2 Start SmartDashboard and display the QoS tab.

3 Determine the type of QoS Policy you want to implement.
4 Define the network objects to be used in the Rule Base.
You define only those objects that are explicitly used in the Rule Base and do not
have to define the entire network.
5 Define any proprietary services used in your network.
You do not have to define the commonly used services. These are already defined
for you in FloodGate-1. In most cases, you need only specify a name, for network
objects and services because Check Point QoS obtains the object’s properties from
the appropriate databases (DNS, YP. hosts file).
6 Create a new QoS Rule Base and the rules that comprise that Rule Base.
7 Install the Rule Base on the QoS Module machine, which will enforce the QoS
Policy.
Each of these steps are described in detail in the sections that follow.

In This Section

Step 1: Installing Check Point Modules page 44

Step 2: Starting SmartDashboard page 44
Step 3: Determining QoS Policy page 47

Chapter 5 Check Point QoS Tutorial 43

Building and Installing a QoS Policy

Step 4: Defining the Network Objects page 48

Step 5: Defining the Services page 60
Step 6: Creating a Rule Base page 60
Step 7: Installing a QoS Policy page 68

Step 1: Installing Check Point Modules

This step describes the physical installation of the Check Point Products at the various
locations in the example on page 42. In this tutorial you do not physically install the
network but you do run the QoS Module on SmartDashboard.
Detailed installation instructions are available in the Getting Started Guide.
Install QoS in the following sequence:
1 Install QoS and VPN-1 Pro or VPN-1 Net modules on London.
2 Install SmartConsole on Cambridge.
3 Install SmartCenter Server on Oxford.
4 On Oxford, define Cambridge as a SmartConsole.
5 On Oxford, define the administrators who will be allowed to manage the QoS
Policy.
6 Establish a secure connection (SIC) between the SmartCenter Server at Oxford and
the QoS Module at London.

Step 2: Starting SmartDashboard

You must start SmartDashboard in order to be able to access Check Point QoS. For the
purposes of this tutorial, and although all the regular log on procedures are described in
this section, you must run SmartDashboard in Demo Mode, selecting the Advanced
option. This section describes how to start SmartDashboard and access its QoS tab to
be able to enter and install the QoS Policy you are defining.

To Start SmartDashboard
1 From the menu, select Programs > Check Point SmartConsole R60 >
Start
SmartDashboard. The Welcome to Check Point SmartDashboard window (FIGURE
5-2) is displayed:

44
 To Start SmartDashboard

FIGURE 5-2 SmartDashboard Login Window

2 You can log in using either your:

• User Name and Password

a Select User Name.

b Enter your user name and password in the designated field.

• Certificate
a Select Certificate.

b Select the name of your certificate file from the dropdown list.

c You can browse for the file using by clicking .

d Enter the password you used to create the certificate in the Password field.

3 Enter the name of the machine on which the SmartCenter Server is running. You
can enter one of the following:
• A resolvable machine name

• A dotted IP address

4 To work in local mode, check Demo Mode and select Advanced from the
drop-down list.
5 (Optional) Check Read Only if you do not wish to modify a policy,
6 (Optional) Click More Options >> to display the Certificate Management and
Advanced Options (FIGURE 5-3).

Chapter 5 Check Point QoS Tutorial 45

Building and Installing a QoS Policy

FIGURE 5-3 (SmartDashboard Login Window - More Options

7 (Optional) Click Change Password to change the certificate password.

8 (Optional) Check Use compressed connection to compress the connection to the
SmartCenter Server.
9 (Optional) Enter the text describing why the administrator wants to make a change
in the security policy in the Session Description field. The text appears as a log
entry in the SmartView Tracker in the Session Description column (in Audit mode
only).

Note - If the Session Description column does not appear in the SmartView Tracker, use
the Query Properties pane to display it. For more information on the SmartView Tracker,
see the chapter called SmartView Tracker in the SmartCenter Guide.

10 (Optional) Check Do not save recent connections information if you do not want
your connection settings saved.
11 Click Less Options << to hide the Certificate Management and Advanced options.

46
 Step 3: Determining QoS Policy

12 Click OK The SmartDashboard main window FIGURE 5-4 is displayed:

FIGURE 5-4 SmartDashboard Main Window .

13 Click the QoS tab display the QoS Rule Base. The QoS tab (FIGURE 5-5) is
displayed.
FIGURE 5-5 QoS Tab

Step 3: Determining QoS Policy

To implement an effective QoS Policy, you must first determine how you currently use
your network, and then identify and prioritize the types of traffic and the users who are
going to use the network.

Chapter 5 Check Point QoS Tutorial 47

Building and Installing a QoS Policy

For example, a typical QoS Policy would be:

• HTTP traffic should be allocated more bandwidth than RealAudio.
• Marketing should be allocated more bandwidth than Engineering.
You will create the rules to implement this policy in “Step 6: Creating a Rule Base” on
page 60.

Step 4: Defining the Network Objects

You must now define the Network Objects including London, the gateway on which
the QoS Module is running, and its interfaces, as well as the sub-networks for the
Marketing and Engineering departments.
This step describes, as an example, how the gateway London will be defined.

48
 To Define the Gateway London

To Define the Gateway London

1 Using one of the methods described in TABLE 5-2, open the Properties window

Chapter 5 Check Point QoS Tutorial 49

Building and Installing a QoS Policy

(FIGURE 5-8 on page 53.)

TABLE 5-2 Creating a New Gateway

From the... ... proceed as follows

Manage menu • From the Manage menu, choose Network Objects.
The Network Objects window (FIGURE 5-6) is
displayed.
FIGURE 5-6 Network Objects Window

• Click New and choose Check Point > Gateway from

the menu. The Check Point Gateway - General
Properties window is displayed (FIGURE 5-7).

Objects toolbar • If the Objects toolbar is not visible, then, from the
View menu choose Toolbars > Objects.to display it.
• Select from the toolbar. The Network Objects
window (FIGURE 5-6) is displayed.
• Click New and choose Check Point > Gateway from
the menu. The Check Point Gateway - General
Properties window is displayed (FIGURE 5-7).

Network Objects tree • Right-click Network Objects in the Network

Objects tree and choose New > Check
Point>Gateway from the menu. The Check Point
Gateway - General Properties window is displayed
(FIGURE 5-7).

50
 To Define the Gateway London

FIGURE 5-7 Check Point Gateway - General Properties Window

Chapter 5 Check Point QoS Tutorial 51

Building and Installing a QoS Policy

2 In the Check Point Gateway - General Properties window (FIGURE 5-7) enter the
information shown in TABLE 5-3 to define London’s gateway.
TABLE 5-3 London’s Check Point Gateway - General Properties Window

Field Value Explanation

Name London This is the name by which the object
is known on the network; the
response to the hostname command.
IP Address 192.32.32.32 This is the interface associated with
the host name in the DNS — get this
by clicking Get Address.
For gateways, this should always be
the IP address of the external
interface.
Comment QoS Module This is the text that is displayed at the
(gateway) bottom of the Network Objects
window when this object is selected
Check Point • Select the Version These settings specify the Check
Products from the Point products installed on London,
drop-down list. and their version number.
• Check VPN-1 Pro Check Point QoS must be installed
(if needed), on any gateway on which a QoS
FireWall-1and QoS Module is installed.
(FloodGate-1). Note that if multiple Check Point
products are installed on a machine,
they must all be the same version
number.
Secure Internal Establishes a secure communication
Communication
channel between Check Point
Modules.
The Check Point Gateway - General Properties window now has the information
shown in FIGURE 5-8 on page 53.

52
 To Define the Interfaces on Gateway London

FIGURE 5-8 Check Point Gateway - General Properties Window

To Define the Interfaces on Gateway London

1 Click Topology in the tree on the left side of the Check Point Gateway -London
window. The Topology page Check Point Gateway - London window (FIGURE 5-9)
is displayed.

Chapter 5 Check Point QoS Tutorial 53

Building and Installing a QoS Policy

FIGURE 5-9 Check Point Gateway - London Topology Window

2 The easiest and most reliable way to define the interfaces is to click Get.., which
automatically retrieves general and topology information for each interface. If you
choose this method of configuring the gateway, the topology fetched suggests the
external interface of the gateway based on the QoS Module routing table. You
must ensure that this information is correct.
Alternatively, click Add. The Interface Properties window (FIGURE 5-10) is
displayed.

54
 To Define the Interfaces on Gateway London

FIGURE 5-10 Interface Properties - General Tab

3 Enter the information on the three interfaces listed in TABLE 5-4, TABLE 5-5 and
TABLE 5-6 in the General and Topology tabs of this window.
4 Click OK after you have entered the information from each table to add the
interface to the Check Point Gateway - London - Topology window.

Chapter 5 Check Point QoS Tutorial 55

Building and Installing a QoS Policy

The data for each of the three interfaces of London is as follows:

TABLE 5-4 Field Values — Interface Properties Window — le0

Field Value Explanation

General tab
Name le0
Net Address 192.32.32.32
Net Mask 255.255.255.0
Topology tab
Topology Check External (leads Specifies to which network this
out to the Internet). interface leads.
Anti-Spoofing Check Perform Specifies that each incoming packet
Anti-Spoofing based on will be examined to ensure that its
network topology. source IP address is consistent with
the interface through which it entered
the machine.
Spoof Tracking Check Log. Specifies that when spoofing is
detected, the event will be logged.

56
 To Define the Interfaces on Gateway London

TABLE 5-5 Field Values — Interface Properties Window — le1

Field Value Explanation

General tab
Name le1
Net Address 192.32.42.32
Net Mask 255.255.255.0
Topology tab
Topology Check Internal (leads to Specifies to which network this
the local network). interface leads.
IP addresses Check Network defined Specifies that the standard IP
behind this by the interface IP and addressing scheme is being used.
interface Net Mask.

Anti-Spoofing Check Perform Specifies that each incoming packet

Anti-Spoofing based on will be examined to ensure that its
network topology. source IP address is consistent with
the interface through which it entered
the machine.
Spoof Tracking Check Log. Specifies that when spoofing is
detected, the event will be logged.

Chapter 5 Check Point QoS Tutorial 57

Building and Installing a QoS Policy

TABLE 5-6 Field Values — Interface Properties Window — le2

Field Value Explanation

General tab
Name le2
Net Address 199.199.199.32
Net Mask 255.255.255.0
Topology tab
Topology Check Internal (leads to Specifies to which network this
the local network). interface leads.
IP addresses Check Network defined Specifies that the standard IP
behind this by the interface IP and addressing scheme is being used.
interface Net Mask.

Anti-Spoofing Check Perform Specifies that each incoming packet

Anti-Spoofing based on will be examined to ensure that its
network topology. source IP address is consistent with
the interface through which it entered
the machine.
Spoof Tracking Check Log. This specifies that when spoofing is
detected, the event will be logged.
After the three interfaces have been defined, they are listed in the Check Point Gateway
- London - Topology window (FIGURE 5-11).

58
 To Define the QoS Properties for the Interfaces on Gateway London

FIGURE 5-11 Check Point Gateway - Topology Page

To Define the QoS Properties for the Interfaces on Gateway

London
1 In the Check Point Gateway - London - Topology window (FIGURE 5-11),
double-click London’s external interface (le0), or select it and click Edit. The
Interface Properties window is displayed.

2 Click the QoS tab. The Interface Properties - QoS tab (FIGURE 5-12) is displayed.

Chapter 5 Check Point QoS Tutorial 59

Building and Installing a QoS Policy

FIGURE 5-12 Interface Properties Window - QoS tab

3 Check both Inbound Active and Outbound Active.

4 From the Rate dropdown list set both rates to 192000 - T1 (1.5 Mbps).

5 Click OK to exit the Interface Properties window.

6 Click OK to exit the Check Point Gateway - London - Topology window.

Step 5: Defining the Services

The QoS Policy required for this tutorial does not require the definition of new
proprietary services. The commonly used services HTTP and RealAudio are already
defined in FloodGate-1.

Step 6: Creating a Rule Base

After defining your network objects and services, you are now ready to create the Rule
Base that will comprise your QoS policy rules. When you start SmartDashboard, the
last Policy Package that was used is displayed. The Policy Package comprises the Rule
Bases of all the tabs that are displayed in the SmartDashboard window. This tutorial is
only concerned with the QoS Rule Base which is accessed when you select the QoS
tab. In this step you close this Policy Package and create a new Policy Package in
which you have the QoS Rule Base for the rules that you are about to create.

60
 To Create a New Policy Package

The new Rule Base is created with a Default Rule (see “Default Rule” on page 35).
After you have created the Rule Base you must add the rules that will enforce the QoS
Policy determined in “Step 3: Determining QoS Policy” on page 47.

To Create a New Policy Package

1 In SmartDashboard select New from the File menu. The Save window is displayed
requesting that you save the displayed Policy Package before creating a new one.
2 Click Save and continue. The New Policy Package window is displayed
FIGURE 5-13 New Policy Package Window

3 Enter the name in the New policy Package Name field.

4 Check Security and Address Translation (if needed).
5 Check QoS. and select Traditional mode.
6 Click OK. The new Policy Package is created together with a Default Rule and is
displayed in the QoS tab (FIGURE 5-14).
FIGURE 5-14 New Rule Base In the QoS Tab

To Create a New Rules

This procedure describes how to create the two new rules required to enforce the Rule
Base. Create two rules: Web Rule and RealAudio Rule.

Chapter 5 Check Point QoS Tutorial 61

Building and Installing a QoS Policy

1 Click the QoS tab to access the QoS Rule Base.

2 Right-click in the Name field of the QoS tab and select Add Rule above from the
menu that is displayed. The Rule Name window is displayed.
FIGURE 5-15 Rule Name Window

3 Enter Web Rule as the Rule Name.

4 Click OK. The rule is added to the Rule Base.

5 Repeat steps 1 to 3 and create a new rule with the name of RealAudio Rule. The
QoS tab in SmartDashboard lists all the rules in the Rule Base.
FIGURE 5-16 QoS Tab with Rules

Rule Properties
When a new rule is created it has the default values assigned by the System
Administrator. You must change these values so that they correctly reflect the policies
you want.
The next procedure describes how to change these rules so that they reflect the values
shown in TABLE 5-7.
TABLE 5-7 Changing Rules Default Values

Rule Name Source Destination Service Action

Web Rule Any Any HTTP Weight

35
RealAudio Any Any RealAudio Weight 5
Rule
Default Any Any Any Weight
10

62
 To Modify New Rules

To Modify New Rules

1 In the QoS tab, right-click in the Service field of the Web Rule and select Add
from the menu that is displayed. The Add Object window (FIGURE 5-17) is
displayed.
FIGURE 5-17 Add Object Window

2 Select HTTP from the list.

3 Click OK. The Web Rule’s Service is changed.
4 Repeat steps 1 to 3 but change the service of the RealAudio rule to RealAudio.

5 Right-click in the Action field of the Web Rule and select Edit Properties from the
menu that is displayed. The QoS Action Properties window (FIGURE 5-18) is
displayed.
FIGURE 5-18 QoS Action Properties Window

6 Change the Rule Weight to 35 and Click OK.

Chapter 5 Check Point QoS Tutorial 63

Building and Installing a QoS Policy

7 Repeat steps 5 and 6 and change the weight of the RealAudio Rule to 5.

Classifying Traffic by Service

Even an exhaustive Rule Base will generally not explicitly define rules for all the
“background” services (such as DNS and ARP) in the traffic mix, but will let the
Default rule deal with them.
FIGURE 5-19 Service Rules in the GUI

Note how the structure of the Rule Base is shown at the left of the window
(FIGURE 5-19) as a tree, with the Default Rule highlighted in both the tree and the
Rule Base. (For a description of the Rule Base window, see Chapter 4, “Basic QoS
Policy Management”.”).
The effect of these rules is that, when connections compete for bandwidth, they receive
bandwidth in accordance with the weights assigned by the rules that apply to them. For
example, TABLE 5-8 describes what happens when there are four active connections.
TABLE 5-8 Service Rules - four active Connections

connections relevant rule bandwidth remarks

HTTP Web Rule 70% 35 / 50 (the total weights)
RealAudio RealAudio Rule 10% 5 / 50
FTP Default sharing 20% 10 /50; a rule applies to all the
connections together
TELNET Default sharing 20% 10 /50; a rule applies to all the
connections together
It is important to note that the bandwidth allocation is constantly changing. Bandwidth
is allocated among connections according to their relative weight. As the connection
mix changes — as it does continuously as connections are opened and closed —
FloodGate-1 changes the bandwidth allocation in accordance with the QoS Policy, so
that bandwidth is never wasted. For example, if the HTTP, FTP and TELNET
connections are all closed, and the only remaining connection is the RealAudio
connection, RealAudio will receive 100% of the bandwidth.

64
 To Modify New Rules

Suppose now that the TELNET and FTP connections are closed. TABLE 5-9 shows
the result.
TABLE 5-9 Service Rules - two active Connections

connections relevant rule bandwidth remarks

HTTP Web Rule 87.5% 35/40 (the total weights)
RealAudio RealAudio Rule 12.5% 5/40
Both HTTP and RealAudio benefit from the bandwidth released by the closed
connections. Even though RealAudio is assigned a very small weight compared to
HTTP, it will never “starve,” even in the event of heavy HTTP traffic.

Note - In practice, you will probably want to give a high relative weight to an interactive
service such as TELNET, which transfers small amounts of data but has an impatient user
at the keyboard.

Classifying Traffic by Source

The second part of the QoS Policy (“Marketing should be allocated more bandwidth
than Engineering.””) can be expressed in the following rules:
TABLE 5-10 Marketing is Allocated More Bandwidth Than Engineering

Rule Name Source Destination Service Action

Marketing Marketing Any Any Weight

Rule 30
Engineering Engineerin Any Any Weight
Rule g 20
Default Any Any Any Weight
10

Using the same principles described in “To Create a New Rules” on page 61 and “To
Modify New Rules” on page 63, create new rules and modify them to reflect the
values shown in TABLE 5-10. The effect of these rules is similar to the effect of the
rules in TABLE 5-8 on page 64, except for:
• the different weights
• the fact that allocation is based on source rather than on services.

Chapter 5 Check Point QoS Tutorial 65

Building and Installing a QoS Policy

Classifying Traffic by Service and Source

TABLE 5-11 shows all the rules together in a single Rule Base.
TABLE 5-11 All the Rules Together

Rule Name Source Destination Service Action

Web Rule Any Any HTTP Weight

35
RealAudio Any Any RealAudio Weight 5
Rule
Marketing Marketing Any Any Weight
Rule 30
Engineering Engineerin Any Any Weight
Rule g 20
Default Any Any Any Weight
10

In this Rule Base, bandwidth allocation is based both on sub-networks and on services.

First Rule Match Principle

In the Rule Base in TABLE 5-11, it is possible that more than one rule can be relevant
to a connection. However, FloodGate-1 works according to a first rule match
principle. Every connection is examined against the QoS Policy and receives bandwidth
according to the action defined in the first rule that is matched.
If a user in Marketing initiates an HTTP connection, both Web Rule and Marketing
Rule are theoretically relevant. Because Web Rule comes before Marketing Rule in
the Rule Base, the connection will be given a weight of 35. Marketing Rule will no
longer be relevant to this connection.
In order to differentiate HTTP traffic by source, it would be necessary to create
sub-rules for Web Rule. See “Sub-Rules” on page 68.

Note - The actual bandwidth allocated to a connection at any given moment depends on
the weights of the other connections that are active at the same time.

66
 To Modify New Rules

Guarantees and Limits

In addition to using weights, you can define bandwidth allocation by using guarantees
and limits. You can define guarantees and limits for whole rules, or for individual
connections within a rule.
For example, the Web Rule shown in the Rule Base in TABLE 5-11 on page 66
allocates 35% of available bandwidth to all the HTTP connections combined. The
actual amount of bandwidth received by connections under this rule depends on
available bandwidth and on the open connections that match the other rules.
A guarantee can be used mainly to specify bandwidth in absolute measures (such as bits
or bytes) instead of relative weights. Note however that 35% of available bandwidth
(specified in the example above) is assured to you. You may get more bandwidth if
there are few connections backlogged to other rules, but you will not get less
bandwidth. The bandwidth allocated is absolutely guaranteed. In TABLE 5-12, Web
Rule is guaranteed 20 KBps. The connections under Web Rule will receive a total
bandwidth of 20 KBps. Any remaining bandwidth will be allocated to all the rules,
Web Rule included, according to their weights.

TABLE 5-12 Guarantee Example

Rule Name Source Destination Service Action

Web Rule Any Any HTTP Guarantee 20

KBps
Weight 35
RealAudio Any Any RealAudio Weight 5
Rule
Marketing Marketing Any Any Weight 30
Rule
Engineering Engineeri Any Any Weight 20
Rule ng
Default Any Any Any Weight 10

For more information and examples of guarantees and limits, see “Examples:
Guarantees and Limits” on page 71 and “Bandwidth Allocation and Rules” on page 34.

Chapter 5 Check Point QoS Tutorial 67

Building and Installing a QoS Policy

Sub-Rules
Sub-rules are rules within a rule. For example, you may wish to allocate bandwidth for
HTTP connections by source, so that HTTP connections from Marketing receive
more bandwidth than other HTTP traffic. In this case, you would define sub-rules
under Web Rule as follows:
TABLE 5-13 Defining Sub-Rules

Rule Name Source Destination Service Action

Web Rule Any Any HTTP Weight 20

Start of Sub-Rule

Marketing HTTP Marketing Any Any Weight 10

Default Any Any Any Weight 1
End of Sub-Rule

Sub-Rules are created in a similar manner to Rules as described in “To Create a New
Rules” on page 61, However to create a sub-rule you right-click in the Name field of
the rule in which you want to create the sub-rule and select Add Sub-Rule from the
menu that is displayed.
The sub-rule means that for connections under Web Rule bandwidth should be allocated
according to the weights specified: 10 for HTTP traffic from the Marketing department
and 1 for everything else.
The bandwidth allocated to the Web Rule according to its weight (20). This weight is
further divided between its sub-rules in a 10:1 ratio. Note that there will be two
Default rules: one for the Rule Base as a whole and another for the sub-rules of Web
Rule.

The Source, Destination and Service fields of the sub-rule must always be a “sub-set”
of the parent rule otherwise the sub-rule will be ineffective.

Step 7: Installing a QoS Policy

After you have defined the Rule Base, you can install the QoS Policy on the QoS
Modules by selecting Install from the Policy menu.
The Install Policy window (FIGURE 5-20) is displayed, showing a list of gateways
defined as FloodGate-1 Modules (see “Step 4: Defining the Network Objects” on page
48).

68
 Step 7: Installing a QoS Policy

FIGURE 5-20 Install Policy Window

Select the specific QoS Modules on which to install the QoS Policy. Check Point QoS
will enforce the QoS Policy on the directions specified in the interface properties of
each selected module. and click OK
For further information, see “Implementing the Rule Base” on page 39.

Conclusion
You have now completed all the steps that were required to install the network
described in Figure 5-1 on page 42, and to define the Rule Base that will implement
the required policy QoS policy.
As a result, you should have a much better understanding of how QoS policy can be
implemented using Check Point QoS. It is strongly recommended however that you
now spend some time and refer to Chapter 7, “Managing Check Point QoS”” for
further information.

Chapter 5 Check Point QoS Tutorial 69

Conclusion

70
CHAPTER 6

Advanced QoS Policy

Management

In This Chapter

Overview page 71
Examples: Guarantees and Limits page 71
Differentiated Services (DiffServ) page 77
Low Latency Queuing page 79
Authenticated QoS page 86
Citrix MetaFrame Support page 86
Load Sharing page 87

Overview
This chapter describes the more advanced QoS policy management procedures that
enable you to refine the basic QoS policies described in Chapter 4, “Basic QoS Policy
Management””.

Examples: Guarantees and Limits

The QoS Action properties defined in the rules and sub-rules of a QoS Policy Rule
Base interact with one another to determine bandwidth allocation.
The guidelines and examples in the sections that follow explain how to use guarantees
and limits effectively.

71
Examples: Guarantees and Limits

In This Section

Per Rule Guarantees page 72

Per Connections Guarantees page 75
Limits page 76
Guarantee - Limit Interaction page 76

Per Rule Guarantees

1 The bandwidth allocated to the rule is a combination of the guaranteed bandwidth,
plus the bandwidth that is given to the rule because of its weight. The guaranteed
bandwidth is first “extracted” from the total bandwidth and set aside so that the
guarantee can be upheld. The remaining bandwidth is then distributed according to
the weights specified by all the rules. This means that the amount of bandwidth
that is guaranteed to a rule is the guaranteed bandwidth plus the rule’s share of
bandwidth according to weight.
Example:

TABLE 6-1 Total Rule Guarantees

Rule Name Source Destination Service Action

Rule A Any Any ftp Rule Guarantee -

100KBps
Weight 10
Rule B Any Any http Weight 20

The link capacity is 190KBps.

In this example, Rule A receives 130KBps, 100KBps from the guarantee, plus
(10/30) * (190-100).
Rule B receives 60KBps, which is (20/30) * (190-100).
2 If a guarantee is defined in a sub-rule, then a guarantee must be defined for the rule
above it. The guarantee of the sub-rule can also not be greater than the guarantee
of the rule above it.

72
 Per Rule Guarantees

Example:

TABLE 6-2 Guarantee is Defined in Sub-rule A1, But Not in Rule A Making the Rule
Incorrect

Rule Name Source Destination Service Action

Rule A Any Any ftp Weight 10

Start of Sub-Rule

Rule A1 Client-1 Any ftp Rule Guarantee -

100KBps
Weight 10
Rule A2 Client-2 Any ftp Weight 10
End of
Sub-Rule

Rule B Any Any http Weight 30

This Rule Base is not correct because the guarantee is defined in sub-rule A1, but
not in Rule A. To correct this, add a guarantee of 100KBps or more to Rule A.
3 A rule guarantee must not be smaller than the sum of guarantees defined in its
sub-rules.

Chapter 6 Advanced QoS Policy Management 73

Examples: Guarantees and Limits

Example:

TABLE 6-3 Example of an Incorrect Rule Base

Rule Name Source Destination Service Action

Rule A Any Any ftp Rule Guarantee -

100KBps
Weight 10
Start of Sub-Rule

Rule A1 Client-1 Any ftp Rule Guarantee -

80KBps
Weight 10
Rule A2 Client-2 Any ftp Rule Guarantee -
80KBps
Weight 10
Rule A3 Client-3 Any ftp Weight 10
End of
Sub-Rule

Rule B Any Any http Weight 30

This Rule Base is incorrect because the sum of guarantees in Sub-Rules A1 and A2
is (80 + 80) = 160, which is greater that the guarantee defined in Rule A
(100KBps). To correct this, define a guarantee not smaller than 160KBps in Rule
A, or reduce the guarantees defined in A1 and A2.
4 If a rule’s weight is low, some connections may receive very little bandwidth.

74
 Per Connections Guarantees

Example:

TABLE 6-4 If a Rule’s Weight is Low, Some Connections May Receive Very Little
Bandwidth

Rule Name Source Destination Service Action

Rule A Any Any ftp Rule Guarantee -

100KBps
Weight 1
Start of Sub-Rule

Rule A1 Client-1 Any ftp Rule Guarantee -

100KBps
Weight 10
Rule A2 Client-2 Any ftp Weight 10
End of
Sub-Rule

Rule B Any Any http Weight 30

The link capacity is 190KBps.

Rule A is entitled to 103KBps, which are the 100KBps guaranteed, plus (190-100)
* (1/31). FTP traffic classified to Sub-Rule A1 receives the guaranteed 100KBps
which is almost all the bandwidth to which Rule A is entitled. All connections
classified to Sub-Rule A2 together receive only 1.5KBps, which is half of the
remaining 3KBps.
5 The sum of guarantees in rules in the upper level should not exceed 90% of the
capacity of the link.

Per Connections Guarantees

1 If the Accept additional connections is checked, connections exceeding the number
defined in the Number of guaranteed connections are allowed to open. If you leave
the field adjacent to Accept additional connections empty, the additional
connections receive bandwidth allocated according to the Rule Weight defined.
2 If Per connection guarantees are defined both for a rule and for its sub-rule, the Per
connection guarantee of the sub-rule should not be greater than the Per connection
guarantee of the rule.

Chapter 6 Advanced QoS Policy Management 75

Examples: Guarantees and Limits

When such a Rule Base is defined, a connection classified to the sub-rule receives the
Per connection guarantee that is defined in the sub-rule. If a sub-rule does not have a
Per connection guarantee, it still receives the Per connection guarantee defined in the
parent rule.

Limits
1 If both a Rule Limitand a Per connection limit are defined for a rule, the Per
connection limit must not be greater than the Rule Limit.
2 If a limit is defined in a rule with sub-rules, and limits are defined in all the
sub-rules, the rule limit should not be greater than the sum of limits defined in the
sub-rules.
Having a rule limit that is greater than the sum of limits defined in the sub-rules is
never necessary, because it is not possible to allocate more bandwidth to a rule than the
bandwidth determined by the sum of the limits of its sub-rules.

Guarantee - Limit Interaction

1 If a Rule Limit and a Guarantee per rule are defined in a rule, then the limit should
not be smaller than the guarantee.
2 If both a Limit and a Guarantee are defined in a rule, and the Limit is equal to the
Guarantee, connections may receive no bandwidth, as in the following examples:

76
 Guarantee - Limit Interaction

Example:

TABLE 6-5 No Bandwidth Received

Rule Name Source Destination Service Action

Rule A Any Any ftp Rule Guarantee —

100KBps
Rule Limit 100KBps
Weight 10
Start of Sub-Rule

Rule A1 Client-1 Any ftp Rule Guarantee

—100KBps
Weight 10
Rule A2 Client-2 Any ftp Weight 10
End of
Sub-Rule

Rule B Any Any http Weight 30

The Guarantee in sub-rule A1 equals the Guarantee in rule A (100KBps). When there
is enough traffic on A1 to use the full Guarantee, traffic on A2 does not receive any
bandwidth from A (there is a limit on A of 100KBps).
The steps that lead to this situation are as follows:
• A rule has both a guarantee and a limit, such that the limit equals the guarantee.
• The rule has sub-rules with Total Rule Guarantees that add up to the Total Rule
Guarantee for the entire rule.
• The rule also has sub-rule(s) with no guarantee.
In such a case, the traffic from the sub-rule(s) with no guarantee may receive no
bandwidth.

Differentiated Services (DiffServ)

In This Section

Overview page 78
DiffServ Markings for IPSec Packets page 78
Interaction Between DiffServ Rules and Other Rules page 78

Chapter 6 Advanced QoS Policy Management 77

Differentiated Services (DiffServ)

Overview
DiffServ is an architecture for providing different types or levels of service for network
traffic. Packets are marked in the IP header TOS byte, inside the enterprise network as
belonging to a certain Class of Service, or QoS Class. These packets are then granted
priority on the public network.
DiffServ markings have meaning on the public network, not inside the enterprise
network. (Effective implementation of DiffServ requires that packet markings be
recognized on all public network segments.)

DiffServ Markings for IPSec Packets

When DiffServ markings are used for IPSec packets, the DiffServ mark can be copied
from one location to another in one of two ways:
• :ipsec.copy_TOS_to_inner — The DiffServ mark is copied from the IPSec
header to the IP header of the original packet after decapsulation/decryption.
• :ipsec.copy_TOS_to_outer — The DiffServ mark is copied from the original
packet’s IP header to the IPSec header of the encrypted packet after encapsulation.
This property should be set, per QoS Module, in $FWDIR/conf/objects_5_0.c.
The default setting is:
:ipsec.copy_TOS_to_inner (false)
:ipsec.copy_TOS_to_outer (true)

Interaction Between DiffServ Rules and Other Rules

A DiffServ rule specifies not only a QoS Class, but also a weight, in the same way that
other QoS Policy Rules do. These weights are enforced only on the interfaces on
which the rules of this class are installed.
For example, suppose a DiffServ rule specifies a weight of 50 for FTP connections.
That rule is installed only on the interfaces for which the QoS Class is defined. On
other interfaces, the rule is not installed and FTP connections routed through those
other interfaces do not receive the weight specified in the rule. To specify a weight for
all FTP connections, add a rule under “Best Effort.”
DiffServ rules can be installed only on interfaces for which the relevant QoS Class has
been defined in the QoS tab of the Interface Properties window (FIGURE 7-3 on
page 97). “Best Effort” rules (that is, non-DiffServ rules) can be installed on all
interfaces of gateways with QoS Modules installed. Only rules installed on the same
interface interact with each other.

78
 Overview

Low Latency Queuing

In This Section

Overview page 79
Low Latency Classes page 79
Interaction between Low Latency and Other Rule Properties page 84
When to Use Low Latency Queuing page 84
Low Latency versus DiffServ page 85

Overview
For most traffic on the Web (including most TCP protocols), the WFQ (Weighted Fair
Queuing, see “Intelligent Queuing Engine” on page 23) paradigm is adequate. This
means that packets reaching FloodGate-1 are put in queues and forwarded according to
the interface bandwidth and the priority of the matching rule. Using this standard
policy, FloodGate-1 avoids dropping packets as often as possible, because such drops
may adversely affect TCP. Avoiding drops, however, means holding (possibly long)
queues, which may lead to non-negligible delays.
For some types of traffic, such as voice and video, bounding this delay is important.
Long queues are inadequate for these types of traffic because they lead to substantial
delay. Fortunately, for most “delay sensitive” applications, there is no need to drop
packets from queues in order to keep them short.
Instead, the fact that the streams of these applications have a known, bounded bit rate
can be utilized. If FloodGate-1 is configured to forward as much traffic as the stream
delivers, then only a small number of packets accumulate in the queues and delay is
negligible.
FloodGate-1 Low Latency Queuing makes it possible to define special Classes of
Service for “delay sensitive” applications like voice and video. Rules under these classes
can be used together with other rules in the QoS Policy Rule Base. Low Latency
classes require you to specify the maximal delay that is tolerated and a Constant Bit
Rate. FloodGate-1 then guarantees that traffic matching rules of this type is forwarded
within the limits of the bounded delay.

Low Latency Classes

For information on installing Low Latency Classes, see “Low Latency Classes” on page
79.

Chapter 6 Advanced QoS Policy Management 79

Low Latency Queuing

For each Low Latency class defined on an interface, a constant bit rate and maximal
delay should be specified for active directions. FloodGate-1 checks packets matched to
Low Latency class rules to make sure they have not been delayed for longer than their
maximal delay permits. If the maximal delay of a packet has been exceeded, it is
dropped. Otherwise, it is transmitted at the defined constant bit rate for the Low
Latency class to which it belongs.
If the Constant Bit Rate of the class is defined correctly (meaning that it is not smaller
than the expected arrival rate of the matched traffic), packets are not dropped (provided
that the delay exceeds some minimum, see “Computing Maximal Delay” on page 81).
On the other hand, when the arrival rate is higher than the specified Constant Bit
Rate, packets exceeding this constant rate are dropped to ensure that those transmitted
are within the maximal delay limitations.

Note - The maximal delay set for a Low Latency class is an upper limit. This means that
packets matching the class are always forwarded with a delay not greater, but often
smaller, than specified.

Low Latency Class Priorities

In most cases, one Low Latency class is sufficient to serve all bounded delay traffic. In
some cases, however, the user may need to define more than one Low Latency class.
For this purpose, Low Latency classes are assigned one out of five priority levels (not
including the Expedited Forwarding class, see “Low Latency versus DiffServ” on page
85). These priority levels are relative to other Low Latency classes.
It is advisable to define more than one Low Latency class if different types of traffic
require different maximal delays.
The class with the lower maximal delay should get a higher priority than the class with
the higher delay. The reason for this is that when two packets are ready to be
forwarded, one for each Low Latency class, the packet from the higher priority class is
forwarded first. The remaining packet (from the lower class) then encounters greater
delay. This implies that the maximal delay that can be set for a Low Latency class
depends on the Low Latency classes of higher priority.
Other Low Latency classes can affect the delay incurred by a class and therefore must be
taken into consideration when determining the minimal delay that is feasible for the
class. This is best done by initially setting the priorities for all Low Latency classes
according to maximal delay, and then defining the classes according to descending
priority. When you define class two, for example, class one should already be defined.
For more information on the effects of class priority on computing maximal delay, see
“Computing Maximal Delay” on page 81.

80
 Low Latency Classes

Logging LLQ Information

SmartView Tracker enables you to log extensive information for all aspects of LLQ.
For more information, see “SmartView Tracker” on page 143.

Computing the Correct Constant Bit Rate and Maximal Delay

Limits on Constant Bit Rate

For each direction of an interface (inbound and outbound), the sum of the constant bit
rates of all the Low Latency classes cannot exceed 20% of the total designated
bandwidth rate. The 20% limit is set to ensure that “Best Effort” traffic does not suffer
substantial delay and jitter as a result of the existing Low Latency class(es).

Computing Constant Bit Rate

To compute the Constant Bit Rate of a Low Latency class, you should know the bit
rate of a single application stream in traffic that matches the class and the number of
expected streams that are simultaneously opened. The Constant Bit Rate of the class
should be the bit rate of a single application, multiplied by the expected number of
simultaneous streams.
If the number of streams exceeds the number you expected when you set the Constant
Bit Rate, then the total incoming bit rate exceeds the Constant Bit Rate, and many
drops occur. You can avoid this situation by limiting the number of concurrent
streams. For more information, see “Ensuring that Constant Bit Rate is Not Exceeded
(Preventing Unwanted Drops)” on page 83.

Note - Unlike bandwidth allocated by a Guarantee, the constant bit rate allocated to a Low
Latency class on an interface in a given direction is not increased in the event that more
bandwidth is available.

Computing Maximal Delay

To compute the maximal delay of a Low Latency class, you should take into account
both the maximal delay that streams matching the class can tolerate in FloodGate-1 and
the minimal delay that FloodGate-1 can guarantee this stream.
It is important not to define a maximal delay that is too small, which may lead to
unwanted drops. The delay value defined for a class determines the number of packets
that can be queued in the Low Latency queue before drops begin to occur. The smaller
the delay, the shorter the queue. Therefore, an insufficient maximal delay may cause
packets to be dropped before they have the chance to be forwarded. It is advisable to
allow for at least several packets to be queued, as explained in the steps below.

Chapter 6 Advanced QoS Policy Management 81

Low Latency Queuing

If you are using Check Point SmartView Tracker, it is recommended to use the default
Class Maximal Delay defined in the LLQ log. In order to obtain this default number,
you must first configure the correct Constant Bit Rate for the Class and you must give
an estimation for the Class Maximal Delay. For more information, see “SmartView
Tracker” on page 143. Alternately, you can set the Class Maximal Delay, as described in
the steps that follow. If you use the following method you can set the delay of the class
by obtaining estimates for the upper and lower bounds, and setting the delay to a value
between the bounds:
1 Estimate the greatest delay that you can set for the class:
a Refer to the technical details of the streaming application and find the delay
that it can tolerate.
For voice applications, for example, it is commonly stated that the user starts
to experience irregularities when the overall delay exceeds 150 ms.
b Find or estimate the bound on the delay that your external network
(commonly the WAN) imposes. Many Internet Service Providers publish
Service Level Agreements (SLAs) that guarantee certain bounds on delay.
c The maximal delay should be set at no more than the delay that the streaming
application can tolerate minus the delay that the external network introduces.
This ensures that when the delay introduced by FloodGate-1 is added to the
delay introduced by the external network, and does not exceed the delay
tolerated by the streaming application.
2 Estimate the smallest delay that you can set for the class:
a Find the bit rate of the streaming application in the application properties, or
using Check Point SmartView Monitoring (see SmartView Monitor Guide).

Note - Even if you set the Constant Bit Rate of the class to accommodate multiple
simultaneous streams, conduct the following calculations with the streaming rate of a
single stream.

b Estimate the typical packet size in the stream. You can either find it in the
application properties or monitor the traffic.
If you do not know the packet size, you can use the size of the MTU of the
LAN behind FloodGate-1. For Ethernet, this number is 1500 Bytes.
c Many LAN devices, including switches and NICs, introduce some burstiness
to flows of constant bit rate by changing the delay between packets. For
constant bit rate traffic generated in the LAN and going out to the WAN, it

82
 Low Latency Classes

is therefore recommended to monitor the stream packets on the FloodGated

gateway (on the internal interface that precedes FloodGate-1) to get an
estimate of burst size.
d If no burstiness is detected, the minimal delay of the class should be no
smaller than:
× packet size
3-----------------------------------
bit rate

This enables three packets to be held in the queue before drops can occur.
(Note again that the bit rate should represent a single application, even if you
set the Constant Bit Rate of the class to accommodate multiple streams.)
If burstiness is detected, set the minimal delay of the class to be at least:
( burst size + 1 ) × packet size
---------------------------------------------------------------------
bit rate

3 The maximal delay that you choose for the class should be between the smallest
delay (estimated in step 2 on page 82) and the greatest delay (estimated in step 1 on
page 82). Setting it very close to either of these values is not recommended.
However, if you expect the application to burst occasionally, or if you don’t know
whether the application generates bursts at all, then you should set the delay close
to the greatest value.
4 When you enter the maximal delay you calculated, you may get an error box
containing the message “The inbound/outbound maximal delay of class... must be
greater than... milliseconds.”
This can occur if the Class of Service that you define is not of the first priority (see
“Low Latency Class Priorities” on page 80). The delay value displayed in the error
message depends on the Low Latency classes of higher priority, and on interface
speed.
Set the maximal delay to a value no smaller than the one printed in the message.

Ensuring that Constant Bit Rate is Not Exceeded (Preventing

Unwanted Drops)
As explained in “Logging LLQ Information” on page 81, if the aggregate bit rate going
through the Low Latency class exceeds the Constant Bit Rate of the class, then drops
occur. This situation may occur when the number of streams actually opened exceeds
the number you expected when you set the Constant Bit Rate.
To ensure that more streams than allowed are opened through a Low Latency Class,
define a single rule under the class, with a per connection guarantee as its Action. In the
Per Connection Guarantee field of the QoS Action Properties window, define the per

Chapter 6 Advanced QoS Policy Management 83

Low Latency Queuing

connection bit rate that you expect, and in the Number of guaranteed connections field
define the maximal number of connections that you allow in this class. The Accept
additional non-guaranteed connections option should not be checked.

In this way, you can limit the number of connections to the number you used to
compute the Constant Bit Rate of the class.

Interaction between Low Latency and Other Rule Properties

To activate a Low Latency class, you should define at least one rule under it in the QoS
Policy Rule Base, however you may define more than one rule. The traffic matching
any Low Latency class rule receives the delay and Constant Bit Rate properties defined
for the specified class and is also treated according to the rule properties (weight,
guarantee and limit).
You can use all types of properties in the rules under the Low Latency class, including
Weight, Guarantee, Limit, Per Connection Guarantee and Per Connection Limit.
To better understand the integration of Low Latency class and rule properties, consider
the class with its rules as a separate network interface forwarding packets at a rate
defined by the Constant Bit Rate with delay bounded by the class delay, and with the
rules defining the relative priority of the packets before they arrive at the interface. If a
rule has a relatively low priority, then packets matching it are entitled to a small portion
of the Constant Bit Rate, and hence prone to more drops if the incoming rate is not
small enough.
Note - Using sub-rules under the low latency class is not recommended because they
make it difficult to compute the streams that suffer drops and the drop pattern.
Guarantees and limits are not recommended for the same reasons (with the exception of
Per Connection Guarantees, as described in “Ensuring that Constant Bit Rate is Not
Exceeded (Preventing Unwanted Drops)” on page 83.

When to Use Low Latency Queuing

Use Low Latency Queuing in the following cases:
• When low delay is important, and the bit rate of the incoming stream is known.
This is the case for video and voice applications. In such cases, specify both the
maximal delay and the Constant Bit Rate of the class.
• When controlling delay is important, but the bit rate is not known in advance. The
most common example is Telnet. This application requires fast responses, but the
bit rate is not known in advance. In addition, even if the stream occasionally
exceeds the Constant Bit Rate, you do not want to experience drops. It is
preferable to experience a somewhat larger delay. In such cases, set the Constant
Bit Rate of the class to an upper estimate of the stream rate, and set a very large

84
 Low Latency versus DiffServ

maximal delay (such as 99999 ms). The large delay ensures that packets are not
dropped even in the event of a burst exceeding the Constant Bit Rate. They are
queued and forwarded according to the Constant Bit Rate.

Note - When the incoming stream is smaller than the Constant Bit Rate, the actual delay is
much smaller than 99999 ms (in the example above), because packets are forwarded
almost as soon as they arrive. The 99999 ms bound is effective only for large bursts.

Do not use a Low Latency Class when controlling delay is not of prime importance.
For most TCP protocols (such as HTTP, FTP and SMTP) the other type of
FloodGate-1 rule is more appropriate. Use Weights, Limits and Guarantees in such
cases, so the exact priority of the traffic is imposed without having to take care of bit
rate and delay. FloodGate-1 enforces the policy with minimal drops. Moreover,
weights and guarantees dynamically fill the pipe when some types of expected traffic are
not present, while Low Latency Queuing firmly bounds its traffic by the Constant Bit
Rate.

Low Latency versus DiffServ

Low Latency classes differ from DiffServ classes in that they do not receive type of
service (TOS) markings. Packets are not marked as Low Latency in a universal manner,
and this preferential treatment can only be guaranteed for the QoS Module through
which they pass.
The exception to this rule is the Expedited Forwarding DiffServ class. Any DiffServ
class defined as an Expedited Forwarding class automatically becomes a Low Latency
class of highest priority. Such a class receives the conditions afforded it by its DiffServ
marking both in FloodGate-1 and in the rest of the network.

Note - To use the Expedited Forwarding class as DiffServ only, without delay being
enforced, specify a Maximal Delay value of 99999 in the Interface Properties tab (see
“Low Latency Classes” on page 79).

When to Use DiffServ and When to Use LLQ

If you need to limit the delay for some types of traffic, you should use Low Latency
Queuing except in the following two cases, when you should mark your traffic using a
DiffServ class (see “When to Use Low Latency Queuing” on page 84):
• when your ISP supports DiffServ, meaning that you can receive a different level of
QoS according to the DiffServ marking that you apply to the IP packets.
• when your ISP provides you with several Classes of Service using MPLS. In this
case, DiffServ marking serves to “communicate” to your ISP the Class of Service
that you expect every packet to receive.

Chapter 6 Advanced QoS Policy Management 85

Authenticated QoS

Authenticated QoS
Check Point Authenticated QoS provides Quality of Service (QoS) for end-users in
dynamic IP environments, such as remote access and DHCP environments. This
enables priority users, such as corporate CEOs, to receive priority service when
remotely connecting to corporate resources.
Authenticated QoS dynamically prioritizes end-users, based on information gathered
during network or VPN authentication. The feature leverages Check Point
UserAuthority technology to classify both inbound and outbound user connections.
The User Authority Server (UAS), maintains a list of authenticated users. When you
query the UAS, Check Point QoS retrieves the data and allocates bandwidth
accordingly.
FloodGate-1 supports Client Authentication, including Encrypted Client
Authentication, and SecuRemote/SecureClient Authentication. User and Session
Authentication are not supported.
For information about Client Authentication, see Firewall and SmartDefense Guide.

Citrix MetaFrame Support

In This Section

Overview page 86
Limitations page 87

Overview
Citrix MetaFrame is a client/server software application that enables a client to run a
published application on a Citrix server farm from the client's desktop. It provides:
• Load balancing by automatically directing a client to the server with the lightest
load in a server farm and by allowing publishing and application management from
a single server in that farm.
• A secure encryption option via the ICA (Independent Computing Architecture)
protocol developed by Citrix.
One of the disadvantages of using Citrix ICA is that, uncontrolled, printing traffic
would consume all the available bandwidth, leaving mission critical applications
struggling for bandwidth. There is, therefore, a critical need to provide service
differentiation both between Citrix and other types of traffic, as well as within Citrix
(layer 7) traffic.

86
 Limitations

Check Point QoS, from NG with Application Intelligence (R55), solves the problem
by:
• Classifying all ICA applications running over Citrix through layer 7.
• Differentiating between the Citrix traffic based on ICA published applications, ICA
printing traffic (Priority Tagging) and NFuse.
For further information, see “Managing QoS for Citrix ICA Applications” on page
131.
Check Point QoS, from NG with Application Intelligence (R55) manages QoS for
printing over Citrix using the following service:
• Citrix_ICA_printing service: Citrix ICA printing traffic service.

For further information, see “Managing QoS for Citrix Printing” on page 137.

Limitations
• The Citrix TCP services are supported in Traditional mode QoS Policies only.
• Session Sharing must be disabled.
• The number of applications that are detected by the inspection infrastructure is
limited to 2048. Console errors will be sent if this limit is exceeded. These errors
are harmless and will not affect your system. Simply restart the machine.
• Versions of MetaFrame prior to 1.8 are not supported because there is no packet
tagging in these versions.
• Only one Citrix TCP service can be allocated per single rule.

Load Sharing
Overview
Load Sharing is a mechanism that distributes traffic within a cluster of gateways so that
the total throughput of multiple machines is increased. Check Point QoSs architecture
guarantees that Load Sharing will provide either:
• Two-way Stickiness - all packets of a single connection use the same machine in
both directions.
• Conversation Stickiness - all packets of control/data connections within a
conversation use the same machine in both directions.
In Load Sharing configurations, all functioning machines in the cluster are active, and
handle network traffic (Active/Active operation). If there is a failure in one of the
machines, its connections are redistributed amongst the remaining operational machines
in the cluster.

Chapter 6 Advanced QoS Policy Management 87

Load Sharing

If any individual Check Point gateway in the cluster becomes unreachable, transparent
failover occurs to the other machines, thus providing High Availability. All connections
are shared between the remaining gateways without interruption.

Note - The new Check Point High Availability is a special type of load sharing that
automatically works with QoS Load Sharing. These modes can be safely switched. To
enforce the change though, The QoS policy has to be reinstalled.

All cluster servers share the same set of so called "virtual" interfaces. Each virtual
interface corresponds to an outgoing link. An example of a typical cluster setting is
presented in FIGURE 6-1.
FIGURE 6-1 Cluster Example

88
 Check Point QoS Cluster Infrastructure

Check Point QoS provides a fault-tolerant QoS solution for cluster load sharing that
deploys a unique, distributed WFQ bandwidth management technology. The user is
able to specify a unified QoS policy per virtual interface of the cluster. The resulting
bandwidth allocation is therefore identical to that obtained by installing the same policy
on a single server.

Note - Under a load state there are a few connections that are backlogged active for short
periods of time. In such cases the Load Sharing function in ClusterXL are not spread
evenly, but in this case there is no congestion and therefore no need for QoS.

Check Point QoS Cluster Infrastructure

This section describes the cluster infrastructure needed for QoS load sharing.

Cluster State
ClusterXL introduces a member's load value. A member's load, calculated in
percentages, is assigned to each member by the cluster. The load is different for
ClusterXL multicast and unicast modes. Generally the load for the N members in the
cluster equals (100 / N)%. If number of cluster members changes dynamically (due to
failover or recovery) the load is dynamically adjusted by the cluster to the appropriate
value.

Changes in Cluster State

Cluster members are informed of changes in a fellow cluster member’s load. All cluster
members, including the causer member recalculate their rates with respect to the new
load.
In this way, on the next re-calculation of rates the failed machine’s unutilized
bandwidth, will be divided between the active cluster members. This guarantees correct
work and the quick recovery of the system when faults have occurred.

Rates Calculation Algorithm

QoS Load Sharing uses a member's load value in order to obtain correct rates allocation
for QoS rules.
The rates of the cluster members are calculated in the context of each virtual network
interface. These calculations are used for enforcing the scheduling policy of a virtual
network interface by setting the local rates of the corresponding real network interface
of the cluster members. The cluster member executes this calculation each time
ClusterXL informs them of changes in the cluster state.

Chapter 6 Advanced QoS Policy Management 89

Load Sharing

Basically, in a centralized policy the rate of a rule is divided equally between the
matching connections. In load sharing, the set of connections is evenly split between
the cluster members by the decision function. Therefore, any rule and sub-rule of a
cluster member is assigned a fraction of the original rate that is proportional to the load
of member in the cluster. To achieve a guaranteed rate, the limit and allotment of each
centralized policy rule are recalculated proportionally to the load of the each member.
Finally, a member's physical interface limit is calculated as a portion of the cluster
interface limit, proportional to the member's load.
Note - If for any reason the QoS daemon cannot retrieve a load from the Check Point Load
Sharing, it calculates the load statically according to the (100 / N)% formula. Where N is
the number of members configured in the cluster topology and which are not necessarily
active.

Per-connection guarantees are processed separately (Per-connection limit

implementation remains unchanged by the load sharing mechanism.)

Per-Connection Guarantee Allocation

Each rule with a per connection guarantee manages its rate budget. A rule's budget is
the sum of all per connection guarantee rates over the number of per-connection
guarantee connections allowed under this rule.
In order to decide whether a new connection receives its per-connection guarantee,
the overall rate, which has already been granted to the matched rule's per-connection
guarantee is checked. If this rate is below the rule's budget then the new connection is
granted its per-connection guarantee.
This budget is also divided among cluster members proportionally to their cluster load.
So, generally, each member will process only half the allowed per-connection
guarantee matched to the rule. In this way the cluster as a whole will grant
per-connection guarantee service according to the cluster’s QoS policy.

Example of Rates Calculation

Consider a cluster consisting of two machines with one virtual interface configured to
the rate of 125KBps. The centralized scheduling policy as well as the corresponding
local scheduling policies are shown in FIGURE 6-1.

90
 Check Point QoS Cluster Infrastructure

FIGURE 6-2 Centralized Policy Rates

Conclusion
The decision function distributes traffic evenly between all cluster members and the
resultant load sharing allocates exactly the same rates to the rules/connections as would
be done by a centralized policy.

Chapter 6 Advanced QoS Policy Management 91

Load Sharing

92
CHAPTER 7

Managing Check Point

QoS

In This Chapter

Defining QoS Global Properties page 94

Specifying Interface QoS Properties page 95
Editing QoS Rule Bases page 98
Modifying Rules page 102
Defining Sub-Rules page 121
Working with Differentiated Services (DiffServ) page 122
Working with Low Latency Classes page 127
Working with Authenticated QoS page 130
Managing QoS for Citrix ICA Applications page 131
Managing QoS for Citrix Printing page 137
Viewing the Check Point QoS Modules Status page 138
Enabling Log Collection page 139

This chapter describes how to configure and manage Check Point QoS. The
procedures described in this chapter all presuppose that you have already started the
SmartDashboard application as described on page 44.

93
Defining QoS Global Properties

Defining QoS Global Properties

You can define the QoS Global Properties, including the maximum weight of a QoS
rule, the default value for the weight of a new QoS rule, the unit of measure for
displaying transmission rates, and various timeout values for the implementation of the
QoS rules.

To Modify the QoS Global Properties

1 From the Policy menu, choose Global Properties or click the Edit Global Properties
icon in the toolbar. The Global Properties window is displayed.
2 Click FloodGate-1in the tree that appears on the left side of the page. The
FloodGate-1 page of the Global Properties window is displayed (FIGURE 7-1).
FIGURE 7-1 Global Properties Window - FloodGate-1 Page

3 The following properties that apply to QoS rules are displayed. You can change
any of these fields:
In the Weight area:

94
 To Modify the QoS Global Properties

• Maximum weight of rule: The maximum weight that can be assigned to rules.
The default value is 1000, but can be changed to any number.
• Default weight of rule: The weight to be assigned in the Action column by
default to new rules, including new Default rules.
In the Rate area:
• Unit of measure: The unit specified in FloodGate-1 windows by default for
transmission rates (for example, Bps - Bytes per second).
In the Authenticated timeout for QoS area:
• Authenticated IP expires after: If a user has been authenticated, all connections
that are opened within the specified time receive the guaranteed bandwidth
connection. Any connection opened after the specified time will be queried
with the User Authority Server (UAS) again.
• Non authenticated IP expires after: If a user has previously tried and failed to be
authenticated by the QoS Policy, then all connections that are opened within
the specified time will not receive the guaranteed bandwidth connection. This
means that they will not match that specific rule during that time.
• Unresponded queried IP expires after: The User Authority Server (UAS)
database is queried to see if a user’s IP has been previously authenticated using
Client Authentication or SSL. Until an answer is received, connections from
this user will be classified to the next matching rule. If an answer is not received
within the specified time, there will be another query.

Note - Click Set Default to restore the default settings for the Authentication timeout
for QoS parameters.

4 Click OK to save the changes to the QoS Global Properties.

Specifying Interface QoS Properties

You must first define the network objects, that is, the gateway and its interfaces on
which QoS controls traffic flow. For further information, see Network Objects in
SmartCenter Guide.

Chapter 7 Managing Check Point QoS 95

Specifying Interface QoS Properties

After defining the interfaces you can specify the QoS properties for those interfaces.
This is done in the QoS tab of the Interface Properties window. Defining the interface
QoS properties involves setting the Inbound and Outbound active transmission rates
and specifying the Differentiated Services (DiffServ) and Low Latency classes. You can
change these definitions at any time.

Note - The QoS tab is only enabled for the interfaces of gateways that have FloodGate-1
checked under Check Point Products in the General Properties of the Check Point
Gateway window, as shown in FIGURE 7-2 on page 96.

To Define the Interface QoS Properties

1 Open the Properties window for the appropriate gateway by double-clicking the
gateway in the Objects Tree, or by choosing the gateway from the list in the
Network Objects window. The Check Point Gateway - General Properties window is
displayed (FIGURE 7-2).
FIGURE 7-2 Check Point Gateway - General Properties

96
 To Define the Interface QoS Properties

2 Choose Topology in the tree on the left side of the Check Point Gateway - General
Properties window. The Check Point Gateway - Topology window is displayed.
3 If a list of the gateway’s interfaces are not already present, click Get... to
automatically retrieve the interfaces’ information. If you choose this method of
configuring the gateway, the topology fetched suggests the external interface of the
gateway based on the QoS Module routing table. You must ensure that this
information is correct.
Alternatively, clicking Add displays the Interface Properties window. Interface
information can then be defined in the General and Topology tabs of this window.
4 Double-click on the appropriate interface, or select it and click Edit. The Interface
Properties window is displayed.

5 Click the QoS tab. The QoS tab is displayed (FIGURE 7-3).
FIGURE 7-3 Interface Properties Window - Q oS Tab

Note - The interfaces on the WAN side (or the interface connected to the slower network)
should usually be set to active. On a simple gateway with only two interfaces, FloodGate-1
should be installed only on the interface connected to the WAN. If the gateway also
controls DMZ traffic, you may want to install FloodGate-1 on the interface connected to
the DMZ.

6 Check Inbound Active to enable FloodGate-1 to control traffic on this interface in

the inbound direction.
7 From the Rate dropdown list select the available bandwidth in the inbound
direction, or enter the interface rate manually.

Chapter 7 Managing Check Point QoS 97

Editing QoS Rule Bases

8 Check Outbound Active to enable FloodGate-1 to control traffic on this interface in

the outbound direction.
9 From the Rate dropdown list select the available bandwidth in the outbound
direction, or enter the interface rate manually.
Note - Ensure that the rates correspond to the actual physical capacity of the interfaces,
as FloodGate-1 does not verify these values.

If the rate is incorrectly defined as less than the line’s real capacity, FloodGate-1will not
use more than the capacity defined, and the excess capacity will remain unused. If the
rate is incorrectly defined as more than the line’s real capacity, FloodGate-1 will not
control the traffic correctly.

10 In the DiffServ and Low Latency classes area, you can specify the Differentiated
Services (DiffServ) and Low Latency Queuing classes to be used on the interface.
You can Add, Edit or Remove a class. Refer to “Working with Differentiated
Services (DiffServ)” on page 122 and “Working with Low Latency Classes” on
page 127 for more details on adding or editing DiffServ and Low Latency Classes.
For information about DiffServ and Low Latency classes, see “Differentiated
Services (DiffServ)” on page 77 and “Low Latency Queuing” on page 79.
11 Click OK to save the changes to the interface QoS properties.

12 Repeat from step 4 above for each of the relevant interfaces.

Editing QoS Rule Bases

A Policy Package comprises several Rule Bases, depending on the policy types selected.
Qos policy is implemented by defining an ordered set of rules in the Rule Base. The
Rule Base is comprised of those rules which you create and a default rule. The default
rule is automatically created with the Rule Base. It can be modified but cannot be
deleted. The fundamental concept of the Rule Base is that unless other rules apply, the
default rule is applied to all data packets. The default rule is therefore always the last
rule in the Rule Base.
The Rule Base specifies what actions are to be taken with the data packets. It specifies
the source and destination of the communication, what services can be used, at what
times, whether to log the connection and the logging level.
A QoS Rule Base is applied to specific gateways and interfaces. After you have created
the Policy Package and defined its QoS rules you must install it on the relevant QoS
Modules.
For further details, refer to “Overview” on page 31.

98
 To Create a New Policy Package

In This Section

To Create a New Policy Package page 99

To Open an Existing Policy Package page 99
To Add a Rule page 99
To Rename a Rule page 101
To Copy, Cut or Paste a Rule page 101
To Delete a Rule page 102

To Create a New Policy Package

1 From the File menu choose New. The New Policy Package window is displayed.
2 Enter the name of the Policy Package in the New Policy Package Name field. This
name cannot:
• Contain any reserved words or spaces.

• Start with a number.

• Contain any of the following characters:%, #, ‘, &, *,!, @, ?, <, >, /, \, :.

• End with any of the following suffixes: .w, .pf, .W.

3 In the QoS area, select whether you want Traditional mode or Express mode. See
“Interaction with VPN-1Pro and VPN-1 Net” on page 29.
4 Click OK to save the Policy Package to a new file. The new Policy Package is saved
and a Default Rule is automatically created.

To Open an Existing Policy Package

1 From the File menu choose Open. The Open Policy Package window is displayed.
2 Double-click on the appropriate Policy Package, or select it and click Open. The
selected Policy Package is displayed.

To Add a Rule
When you add rules to a Policy Package you can position the new rule at any location
in the Policy Package. The Default Rule which is automatically created with the Rule
Base must always remain in the last position in the Rule Base.
1 Position your mouse cursor in the Name field of the QoS tab, at the position where
you want to add a new rule.

Chapter 7 Managing Check Point QoS 99

Editing QoS Rule Bases

2 You can add the new rule either from the Rule menu or the toolbar, as described
in TABLE 7-1, or you can also right-click on any name in the Name column of a
rule to display the Rule menu, as described in TABLE 7-2.
TABLE 7-1 Adding a Rule

To add a rule Select from menu Toolbar

Button
After the last rule Rules > Add Rule > Bottom

Before the first rule Rules > Add Rule > Top

After the current rule Rules > Add Rule > Below

Before the current rule Rules > Add Rule > Above

To the current rule Rules > Add Sub-Rule

Note - The current rule is the one that is highlighted. To select a rule, click on its name.

TABLE 7-2 Description of Rule Menu Items

Menu Option Explanation

Add Rule above Adds a rule before the current rule.
Add Rule below Adds a rule after the current rule.
Add Sub-Rule Adds a sub-rule after the current rule.
Delete Rule Deletes the current rule.
Copy Rule Copies the current rule to the clipboard.
Cut Rule Deletes the current rule and puts it in the clipboard.
Paste Rule Pastes the rule in the clipboard (a sub-menu is
displayed from which you can select whether to
paste the rule above or below the current rule).

100
 To Rename a Rule

TABLE 7-2 Description of Rule Menu Items

Menu Option Explanation

Add Class of Service Specifies a Class of Service (see “Differentiated
Services (DiffServ)” on page 77 and “Low Latency
Queuing” on page 79). A sub-menu is displayed
from which you can select whether the Class of
Service is to be added above or after the current rule.
Hide Rule Hides the current rule. The rule is still part of the
Rule Base and will be installed when the QoS Policy
is installed.
Disable Rule Disables the current rule. The rule appears in the
Rule Base but is not enforced by the QoS Policy.
Rename Rule Renames the current rule.
Matching Method Starting from FloodGate-1 NG this feature is not
relevant since it is kept for backward compatibility
only (version 4.1).
3 Select one of the options for creating the new rule. The Rule Name window is
displayed.
4 Enter the name of the rule in the Rule Name field.
5 Click OK. The rule is added to the Rule Base at the selected position and is
comprised of the default values defined in the FloodGate-1 page of the Global
Properties window (FIGURE 7-1 on page 94). Follow the procedures described in
the pages that follow to modify this rule.

To Rename a Rule
1 In the QoS tab, double-click on the rule you want to rename, or right-click on the
rule and select Rename Rule. The Rule Name window is displayed.
2 Enter the rule name in the Rule Name field.
3 Click OK to save the rule name.

To Copy, Cut or Paste a Rule

You can copy, cut or paste a rule using either the Edit or Rules menus or the
right-click menu of the selected rule.
1 In the QoS tab, select the rule you want to copy, cut or paste.

Chapter 7 Managing Check Point QoS 101

Modifying Rules

2 From the Edit or Rules menu, choose one of the options described in TABLE 7-3.
TABLE 7-3 Copying, Cutting and Pasting Rules

Action Select from menu Toolbar

Button
Cut Edit>Cut

Copy Edit>Copy

Paste Edit>Paste

If you choose Paste, then the Paste menu will be opened. You must then select
Bottom, Top, Above, or Below to specify where in the Rule Base to paste the rule.

To Delete a Rule
You can delete a rule using either the Edit or Rules menus or the right-click menu of
the selected rule.
1 In the QoS tab, select the rule you want to delete.
2 From the Edit or Rules menu, choose one of the options described in TABLE 7-4.
TABLE 7-4 Deleting a Rule

Action Select from menu Toolbar Button

Cut Edit>Cut or

3 Click Yes to delete the selected rule.

Modifying Rules
You can modify any of the rule fields, as often as you like, until the rule is in the form
that you require. This includes specifying the source and destination of each
communication, what services can be used at what times (including TCP, Compound
TCP, UDP, and ICMP services), the actions to be taken with the data packets,
whether you want to maintain a log of the entries for the selected rule, and on which
interfaces of the QoS module the rule is enforced.

102
 Modifying Sources in a Rule

FIGURE 7-4 SmartDashboard Rule Base Window

This section describes the procedures for modifying the various fields in a rule. Refer to
“Overview” on page 31 for more details about rules.

In This Section

Modifying Sources in a Rule page 103

Modifying Destinations in a Rule page 106
Modifying Services in a Rule page 108
Modifying Rule Actions page 110
Modifying Tracking for a Rule page 115
Modifying Install On for a Rule page 115
Modifying Time in a Rule page 118

Modifying Sources in a Rule

You can modify the source(s) of the communication in a rule. You can add as many
sources as required. In addition, you can restrict the sources of the rule to particular
user groups, or to user groups originating from specific locations.

In This Section

To Add Sources to a Rule page 104

To Add User Access to the Sources of a Rule page 104
To Edit, Delete, Cut, Copy or Paste a Source in a Rule page 105
To View Where an Object is Used page 106

Chapter 7 Managing Check Point QoS 103

Modifying Rules

To Add Sources to a Rule

1 From the Rule Base choose the rule you want to modify.
2 Right-click in the Source column of the selected rule and select Add. The Add
Object window is displayed (FIGURE 7-5), listing the network objects defined in
the Security Policy and the QoS Policy.
FIGURE 7-5 Add Object Window

Note - You can also use the Add Object window to define new objects and delete or
modify objects.

3 Select one or more network objects (using the standard Windows selection keys) to
add to the rule’s Source.
4 Click OK. The objects are added to the Source field. You can add as many sources
as required.

To Add User Access to the Sources of a Rule

1 From the Rule Base choose the rule you want to modify.
2 Right-click in the Source column of the selected rule and select Add Users Access.
The User Access window is displayed (FIGURE 7-6).

104
 Modifying Sources in a Rule

FIGURE 7-6 User Access Window

3 Choose one of the user groups to add to the rule’s Source.

4 Select whether you want to restrict the Location, as follows:

• No restriction: There is no restriction on the source of the users. For example, if
you choose All Users and check No restriction, then AllUsers@Any will be
inserted under Source in the rule.
• Restrict to: The source is restricted to the network object you select in the list
box. For example, the source object in the rule will be AllUsers@Local_Net.
5 Click OK to add the user access to the rule source.

To Edit, Delete, Cut, Copy or Paste a Source in a Rule

You can edit, delete, cut, copy or paste a source in a rule using the right-click menu of
the selected source.
1 From the Rule Base choose the rule you want to modify.
2 Right-click on the Source of the selected rule and select one of the following
options:
• Edit: The appropriate window is opened, according to the type of object
selected, and you can change the object’s properties. (Alternatively, you can
double-click on an object in the Source column of the selected rule to edit it.)
• Delete: The selected object is deleted. If you delete the last source object in the
rule it is replaced by Any.

Chapter 7 Managing Check Point QoS 105

Modifying Rules

• Cut:The selected object is cut and put it in the clipboard.

• Copy: The selected object is copied to the clipboard.
• Paste: The object is pasted from the clipboard to the rule’s Source.

To View Where an Object is Used

You can view where the selected object is used (in queries, active policies, and so on).
1 From the Rule Base choose the rule you want to modify.
2 Right-click on the Source of the selected rule and choose Where Used. The Object
References window is displayed (FIGURE 7-7), showing you where the selected
object is used (in queries, active policies, and so on).
FIGURE 7-7 Object References Window

3 Click Close to return to the rule.

Modifying Destinations in a Rule

You can modify the destination(s) of the communication in a rule. You can add as
many destinations as required.

In This Section

To Add Destinations to a Rule page 107

To Edit, Delete, Cut, Copy or Paste a Destination in a Rule page 107
To View Where an Object is Used page 110

106
 Modifying Destinations in a Rule

To Add Destinations to a Rule

1 From the Rule Base choose the rule you want to modify.
2 Right-click in the Destination column of the selected rule and select Add. The Add
Object window is displayed (FIGURE 7-5), listing the network objects defined in
the Security Policy and the QoS Policy.

Note - You can also use the Add Object window to define new objects and delete or
modify objects.

3 Select one or more network objects (using the standard Windows selection keys) to
add to the rule’s Destination.
4 Click OK. The objects are added to the Destination field. You can add as many
destinations as required.

To Edit, Delete, Cut, Copy or Paste a Destination in a Rule

You can edit, delete, cut, copy or paste a destination in a rule using the right-click
menu of the selected source.
1 From the Rule Base choose the rule you want to modify.
2 Right-click on the Destination of the selected rule and select one of the following
options:
• Edit: The appropriate window is opened, according to the type of object
selected, and you can change the object’s properties. (Alternatively, you can
double-click on an object in the Destination column of the selected rule to edit
it.)
• Delete: The selected object is deleted. If you delete the last destination object in
the rule it is replaced by Any.
• Cut: The selected object is cut and put it in the clipboard.

• Copy: The selected object is copied to the clipboard.

• Paste: The object is pasted from the clipboard to the rule’s Destination.

To View Where an Object is Used

You can view where the selected object is used (in queries, active policies, and so on).
1 From the Rule Base choose the rule you want to modify.
2 Right-click on the Source of the selected rule and choose Where Used. The Object
References window is displayed (FIGURE 7-7), showing you where the selected
object is used (in queries, active policies, and so on).

Chapter 7 Managing Check Point QoS 107

Modifying Rules

3 Click Close to return to the rule.

Modifying Services in a Rule

You can modify the service(s) in a rule. You can add as many services as required,
however, you can only add one URI for QoS resource in a single rule.
Note - Previous versions of FloodGate-1 have not limited the number of URIs for
QoS resources allowed per rule. If you are using a QoS Policy originally designed
for use with a previous FloodGate-1 version, be sure to redefine any rule that has
more than one resource in its Service Field.

In This Section

To Add Services to a Rule page 108

To Add a Service with a Resource to a Rule page 108
To Edit, Delete, Cut, Copy or Paste a Service in a Rule page 109
To View Where an Object is Used page 110

To Add Services to a Rule

1 From the Rule Base choose the rule you want to modify.
2 Right-click in the Service column of the selected rule and select Add. The Add
Object window is displayed (FIGURE 7-5), listing the network objects defined in
the Security Policy and the QoS Policy.
3 Select one or more network objects (using the standard Windows selection keys) to
add to the rule’s Service.
4 Click OK. The objects are added to the Service field. You can add as many services
as required. However only one TCP Citrix or URI for QoS service is allowed.

To Add a Service with a Resource to a Rule

1 From the Rule Base choose the rule you want to modify.
2 Right-click in the Source column of the selected rule and select Add with
Resources. You can only add one service with a resource to a rule, so this option
will only be available if you have not already added a service with a resource to this
rule. The Services with Resource window is displayed (FIGURE 7-8).

108
 Modifying Services in a Rule

FIGURE 7-8 Services with Resource Window

3 Choose one of the services in the Location area and then select the appropriate
resource from the Resource dropdown list. For further information, refer to:
• Only resources of type URI for QoS can be added to the FloodGate-1 Rule
Base. URI for QoS is used for identifying HTTP traffic according to the URL
(URI).
• Do not use the protocol prefix (http://) when setting up a URI resource.
HTTP services with URI for QoS resources can be defined on all ports.
4 Click OK to add the service with a URI for QoS resource to the rule.

Note - Only one resource is allowed in a single rule.

To Edit, Delete, Cut, Copy or Paste a Service in a Rule

You can edit, delete, cut, copy or paste a service in a rule using the right-click menu
of the selected service.
1 From the Rule Base choose the rule you want to modify.
2 Right-click on the Service of the selected rule and select one of the following
options:
• Edit: The appropriate window is opened, according to the type of object
selected, and you can change the object’s properties. (Alternatively, you can
double-click on an object in the Service column of the selected rule to edit it.)
• Delete: The selected object is deleted. If you delete the last service object in the
rule it is replaced by Any.

Chapter 7 Managing Check Point QoS 109

Modifying Rules

• Cut:The selected object is cut and put it in the clipboard.

• Copy: The selected object is copied to the clipboard.
• Paste: The object is pasted from the clipboard to the rule’s Service.

To View Where an Object is Used

You can view where the selected object is used (in queries, active policies, and so on).
1 From the Rule Base choose the rule you want to modify.
2 Right-click on the Service of the selected rule and choose Where Used. The Object
References window is displayed (FIGURE 7-7), showing you where the selected
object is used (in queries, active policies, and so on).
3 Click Close to return to the rule.

Modifying Rule Actions

You can modify the default properties of a rule. The options available vary according to
the action type of rule, that is whether the rule is defined as simple or advanced. The
advanced rule action type enables you to specify limits and guarantee allocation on a
per connection basis.

In This Section

To Edit the Rule Actions page 110

To Reset the Rule Actions to Default Values page 114

To Edit the Rule Actions

1 From the Rule Base choose the rule you want to modify.
2 Right-click in the Action column of the selected rule and select Edit Properties.
The QoS Action Properties window is displayed, as follows:
• If the Action Type of the rule is defined as Simple, the QoS Action Properties
window is displayed (FIGURE 7-9).

110
 Modifying Rule Actions

FIGURE 7-9 QoS Action Properties - Simple

• If the Action Type of the rule is defined as Advanced, the QoS Action Properties
window is displayed (FIGURE 7-10).

Chapter 7 Managing Check Point QoS 111

Modifying Rules

FIGURE 7-10QoS Action Properties - Advanced

Note - When Express QoS has been installed, Advanced Actions are not available.

3 The following properties are displayed for a QoS rule with a simple action type.
You can change any of these fields:
In the Action Typearea:
• Simple: The full set of actions with the exception of the Guarantee Allocation
and the per connection limit features.
• Advanced: The full set of actions with the Guarantee Allocation feature included.

In the VPN Traffic area:

• Allow rule only to encrypted traffic: Check this box if you want the rule to be
matched only by VPN traffic. If you do not check this field, rules will be
matched by all traffic types, both VPN and non-VPN traffic. VPN traffic means
traffic that is encrypted in this same gateway by Check Point VPN. This field
does not apply to traffic that was encrypted prior to arriving to this gateway.
This type of traffic can be matched using the "IPSec" service, see the

112
 Modifying Rule Actions

SmartCenter Guide. For further explanation on how to use this check box for
prioritizing VPN traffic over non-VPN, see “Example of a Rule Matching VPN
Traffic” on page 37.
In the Action Properties area you can define the restrictions on bandwidth for
connections to which the rule applies in the following fields:
• Rule Weight: Enables you to define the weight of the rule. This field is checked
by default and has the value defined in the Global Properties window in
“Defining QoS Global Properties” on page 94. It is recommended to leave this
value as is to avoid a complete loss of bandwidth. For detailed information see
“Weight” on page 34.

Warning - 0 rate in conjunction with 0 guarantee can lead to the rule’s complete loss of
bandwidth. To prevent this from happening, retain some ratio in the Rule Weight. The
default is 10.

• Rule Limit: Enables you to restrict the total bandwidth consumed by the rule.
For detailed information see “Limits” on page 35.
Tip - When using weights or guarantees, the weighted fair queuing algorithm that
Check Point QoS makes use of assures that no bandwidth is ever wasted. Spare bandwidth is
divided among the backlogged rules. However, if you set a rule limit, it will not use spare
bandwidth above this limit.

• Rule Guarantee: Enables you to define the absolute bandwidth allocated to the
rule. For detailed information see “Guarantees” on page 35.

Note - The number you enter for the Rule Guarantee cannot be larger than the Rule Limit.

4 (Optional) The following additional properties are displayed for a QoS rule with an
advanced action type. You can change any of these fields:
In the Limitarea:
• Rule Limit: Enables you to restrict the total bandwidth consumed by the rule.
For detailed information see “Limits” on page 35.
Tip - When using weights or guarantees, the weighted fair queuing algorithm that
Check Point QoS makes use of assures that no bandwidth is ever wasted. Spare bandwidth is
divided among the backlogged rules. However, if you set a rule limit, it will not use spare
bandwidth above this limit.

Chapter 7 Managing Check Point QoS 113

Modifying Rules

• Per connection limit: Enables you to set a rule limit per connection.

Note - The number you enter for the Rule Guarantee cannot be larger than the Rule Limit.

In the Guarantee Allocationarea:

• Guarantee: Enables you to allocate a minimum bandwidth to the connections
matched with a rule. For detailed information see “Guarantees” on page 35.
• Per rule: Enables you to define the absolute bandwidth allocated to the rule.

Note - The number you enter for the Per rule cannot be larger than the Rule Limit.

• Per connection: Enables you to manage the bandwidth at the

connection-level.
• Per connection guarantee: Enables you to restrict the absolute bandwidth
allocated per connection.
• Number of guaranteed connections: Enables you to allocate a minimum
number of guaranteed connections

Note - The Number of guaranteed connections multiplied by the Per connection

guarantee cannot be greater than the rule limit.

• Accept additional connections: Check this checkbox to allow connections

without per connection guarantees to pass through this rule and receive any
left over bandwidth. Enter the maximum amount of bandwidth that is
allowed for this option in the text box. This only occurs if all other
conditions have been met.

Note - Select a non-zero rule weight when Accept additional non-guaranteed

connections is checked.

5 Click OK to update the QoS action properties for the rule.

To Reset the Rule Actions to Default Values

1 From the Rule Base choose the rule you want to modify.

114
 Modifying Tracking for a Rule

2 Right-click in the Action column of the selected rule and select Reset to Default.
The action properties for the selected rule are reset to their default values. The
default values are defined in the FloodGate-1 page of the Global Properties window
(see “Defining QoS Global Properties” on page 94).

Modifying Tracking for a Rule

You can choose whether you want to maintain a log of the entries for the selected rule.
If you do want to log the entries, you also have the option of logging the entries in
account format. For further information on tracking and logging, see “Overview of
Logging” on page 143. For information on how to turn logging on, see “Enabling Log
Collection” on page 139.

To Modify Tracking for a Rule

1 From the Rule Base choose the rule you want to modify.
2 Right-click in the Track column of the selected rule. The menu that is displayed
has the following options:
TABLE 7-5 Track Menu

Track Meaning
None: No logging is done for this connection.
Log: Logging is done for this connection.
Account: Logging for this connection is done in Accounting format.

3 Select the required option.

Modifying Install On for a Rule

The Install On field specifies on which interfaces of the QoS module the rule is
enforced. You can select any number of Install On objects.
Note - In order to install a QoS Policy on a gateway, you must ensure that the
gateway has a QoS module installed in the Global Properties window and that the
interface is defined in the QoS tab of the Interface Properties window. (See
“Defining QoS Global Properties” on page 94. and “Specifying Interface QoS
Properties” on page 95.)

Chapter 7 Managing Check Point QoS 115

Modifying Rules

In This Section

To Modify Install On for a Rule page 116

To Delete an Install On for a Rule page 117
To View Where an Object is Used page 118

To Modify Install On for a Rule

1 From the Rule Base choose the rule you want to modify.
2 Right-click in the Install On column of the selected rule and select Add. The Add
Interface window is displayed (FIGURE 7-11).
FIGURE 7-11Add Interface Window

3 (Optional) Click Select Targetsto select additional installable targets. The Select
Installation Targets window is displayed (FIGURE 7-12).

116
 Modifying Install On for a Rule

FIGURE 7-12Select Installation Targets Window

a To add any target(s) to the list of Installed Targets, select the target(s) in the
Not in Installation Targets area and click . The selected target(s)
are added to the In Installation Targetsarea.
b To remove a target(s) from the In Installation Targets area, select the target(s)
and click . The selected targets are returned to the Not in
Installation Targets area.
c Click OK. The selected targets now appear in the Add Interface window
(FIGURE 7-11).
4 Select from the list of targets in the Add Interface window:
• A module (and all its interfaces on which QoS is defined), or

• An interface (in both directions), or

• One direction of an interface

5 Click OK. The selected interface is added to the Install On field.

To Delete an Install On for a Rule

You can remove an interface for a rule. The rule will no longer be enforced for the
interface.
1 From the Rule Base choose the rule you want to modify.

Chapter 7 Managing Check Point QoS 117

Modifying Rules

2 Right-click on the Service of the selected rule and select Delete. The selected
object is deleted.

To View Where an Object is Used

You can view where the selected object is used.
1 From the Rule Base choose the rule you want to modify.
2 Right-click on the Install On of the selected rule and choose Where Used. The
Object References window is displayed (FIGURE 7-7), showing you where the
selected object is used.
3 Click Close to return to the rule.

Modifying Time in a Rule

You can specify the times that the rule is enforced. You add any number of time
objects to a rule.

In This Section

To Modify Time in Rules page 118

To Edit or Delete a Time Object for a Rule page 120
To View Where an Object is Used page 120

To Modify Time in Rules

1 From the Rule Base choose the rule you want to modify.
2 Right-click in the Time column of the selected rule and select Add. The Add Object
window is displayed (FIGURE 7-13).

118
 Modifying Time in a Rule

FIGURE 7-13Add Object Window - Time Objects

3 (Optional) You can edit a time object:

a Select the required time object and click Edit to modify a time object. The
Time Properties window is displayed (FIGURE 7-14). (Alternatively, you can
double-click on an object in the Time column of the selected rule to edit it.)
FIGURE 7-14Time Properties Window

b Edit the fields in the Time Properties window, as required.

c Click OK. The Time Object Properties are amended.

Chapter 7 Managing Check Point QoS 119

Modifying Rules

4 Select the required time object in the Add Object window. The time object is
added to the rule.

To Edit or Delete a Time Object for a Rule

You can edit or delete a time object in a rule using the right-click menu of the selected
service.
1 From the Rule Base choose the rule you want to modify.
2 Right-click on the Time of the selected rule and select one of the following
options:
• Edit: The appropriate window is opened, according to the type of object
selected, and you can change the object’s properties. (Alternatively, you can
double-click on an object in the Time column of the selected rule to edit it.)
• Delete: The selected object is deleted. If you delete the last time object in the
rule it is replaced by Any.

To View Where an Object is Used

You can view where the selected object is used (in queries, active policies, and so on).
1 From the Rule Base choose the rule you want to modify.
2 Right-click on the Service of the selected rule and choose Where Used. The Object
References window is displayed (FIGURE 7-7), showing you where the selected
object is used (in queries, active policies, and so on).
3 Click Close to return to the rule.

Adding Comments to a Rule

You can add a comment to a rule.

To Add Comments to Rules

1 From the Rule Base choose the rule you want to modify.
2 Right-click in the Comment column of the selected rule and select Edit. The
Comment window is displayed (FIGURE 7-15). You can also open this window by
double-clicking in the Comment column of the selected rule.

120
 Adding Comments to a Rule

FIGURE 7-15Comment Window

3 Type any text you wish to add in the text box.

4 Click OK. The comment is added to the rule.

Defining Sub-Rules
Sub-rules are rules that allocate bandwidth more specifically within a rule. For example,
consider the rule shown in FIGURE 7-16.
FIGURE 7-16 Rule Base with Sub-Rules

The bandwidth allocated to the ABC_VPN rule is further allocated among the sub-rules
ABC_VPN_ERP through Default under ABC_VPN (see the rule tree).

In This Section

To Define Sub-Rules page 121

To View Sub-Rules page 122

To Define Sub-Rules
1 Select the rule under which the sub-rule is to be defined.
2 Right-click in the Rule Name column.
3 Select Add Sub-Rule from the menu. The Rule Name window is displayed.

Chapter 7 Managing Check Point QoS 121

Working with Differentiated Services (DiffServ)

4 Enter the sub-rule name and click OK. The new sub-rule together with a default
sub-rule is automatically created, under the rule selected in 1 above, using the
default values defined.
5 You may modify the sub-rules by following the same procedures for editing rules
described on page 99.
6 Add new sub-rules by following the same procedures for creating rules described
on page 99.

To View Sub-Rules
The sub-rules under a main rule can be seen by expanding the rule in the QoS Rule
Tree.
To view sub-rules in the Rule Base itself, click one of the sub-rules in the relevant
main rule. The Rule Base shows all the sub-rules for that rule.

Working with Differentiated Services (DiffServ)

A DiffServ rule specifies not only a QoS Class, but also a weight, in the same way that
other QoS Policy Rules do. These weights are enforced only on the interfaces on
which the rule is installed.
Refer to “Differentiated Services (DiffServ)” on page 77 for additional information on
DiffServ.

In This Section

To Implement DiffServ Marking in FloodGate-1 page 122

To Define a DiffServ Class of Service page 123
To Define a DiffServ Class of Service Group page 125
To Add QoS Class Properties for Expedited Forwarding page 125
To Add QoS Class Properties for Non Expedited Forwarding page 126

To Implement DiffServ Marking in FloodGate-1

1 Define one or more DiffServ Classes of Service using the QoS Classes window.
You may also define a Class of Service Group.
For more information, see “To Define a DiffServ Class of Service” on page 123.

122
 To Define a DiffServ Class of Service

2 In the QoS tab of the Interface Properties window of all interfaces on which the
DiffServ class will be implemented (see “Specifying Interface QoS Properties” on
page 95), click Add under DiffServ and Low Latency classes to add a new class, or
Edit to edit the properties of an existing class. See “Specifying Interface QoS
Properties” on page 95.
3 In the Add QoS Class Properties window, select the QoS class and define the
Inbound and Outbound parameters.
4 Click OK. You can now add QoS Classes to the QoS Policy Rule Base.
5 Right-click in the Name column of a rule and choose Add Class of Service, or
choose Add QoS Class from the Rules menu.
6 Specify whether the class should appear above or after the rule in the Rule Base.
7 Choose the required Class of Service from the dropdown menu in the Add Class of
Service window (FIGURE 7-17).
FIGURE 7-17Add Class of Service Window

8 Click OK. A DiffServ class header appears in the Rule Base.

9 Add rules under the QoS Class you defined, by either:
• Choosing Rules > Add Rule > Below from the menu, or
• Right-clicking on the QoS Class and choosing Add Rule > Below from the menu

To Define a DiffServ Class of Service

1 From the Manage menu select QoS>QoS Classes. The QoS Classes window
(FIGURE 7-18) is displayed.

Chapter 7 Managing Check Point QoS 123

Working with Differentiated Services (DiffServ)

FIGURE 7-18QoS Classes Window

2 Click New to define a new DiffServ class and select DiffServ Class of Service to
display the Class of Service Properties window (FIGURE 7-19).
FIGURE 7-19Class of Service Properties Window

3 Enter the following details in the Class of Service Properties window:

• Name: The name of the Class of Service.

• Comment: The text to be displayed when this class is selected in the QoS Classes
window (FIGURE 7-18).
• Color: Select a color from the dropdown list.

• Type: Select a type from the dropdown list. You may choose a predefined or
user defined class.
• DiffServ code: This is a read-only field that displays the DiffServ marking as a
bitmap.
4 Click OK to create the new DiffServ Class of Service.

124
 To Define a DiffServ Class of Service Group

To Define a DiffServ Class of Service Group

1 From the Manage menu select QoS > QoS Classes. The QoS Classes window
(FIGURE 7-18) is displayed.
2 Click New to define a new DiffServ class and select DiffServ Class of Service Group
to display the Group Properties window (FIGURE 7-20).
FIGURE 7-20QoS Class of Services Group Window

3 Enter the following details in the Group Properties window:

• Name: The name of the group.
• Comment: The text to be displayed when this class is selected in the QoS Classes
window (FIGURE 7-18).
• Color: Select a color from the dropdown list.
• To add a DiffServ class to the group, select the class in the list box labeled Not
in Group, and click .
• To delete a class from the group, select the class in the list box labeled In Group,
and click .
4 Click View expanded group to display all members of the selected DiffServ group.
5 Click OK to create the new DiffServ Class of Service Group.

To Add QoS Class Properties for Expedited Forwarding

1 From the QoS tab of the Interface Properties window FIGURE 7-3 on page 97,
click Add or Edit.

Chapter 7 Managing Check Point QoS 125

Working with Differentiated Services (DiffServ)

2 From the menu that is displayed select either Low Latency Classes or DiffServ >
Expedited Forwarding. The Add Low Latency QoS Class Properties window
FIGURE 7-21 is displayed if you selected Low Latency Classes. If you selected
DiffServ Expedited Forwarding, a similar window with the identical fields is
displayed.
FIGURE 7-21Add Low Latency QoS Class Properties Window

3 Enter the required information as detailed below. You should define at least one
inbound or outbound direction.
• Class: Select a Low Latency class from the list of defined classes.

• Inbound: Define the portion of the interface’s inbound capacity to be reserved.

• Constant Bit Rate: The constant bit rate at which packets of this class will be
transmitted.
• Maximal Delay: The maximum delay that will be tolerated for packets of this
class. Those packets that exceed this delay are dropped.
• Outbound: Define the portion of the interface’s outbound capacity to be
reserved by defining a Constant Bit Rate and a Maximum Delay as described
above.
4 Click OK. The new class is added.

To Add QoS Class Properties for Non Expedited Forwarding

1 From the QoS tab of the Interface Properties window FIGURE 7-3 on page 97,
click Add or Edit.
2 From the menu that is displayed select DiffServ>Others. The Add DiffServ QoS class
Propertieswindow is displayed (FIGURE 7-21).

126
 To Add QoS Class Properties for Non Expedited Forwarding

FIGURE 7-22DiffServ QoS class Properties Window

3 Enter the required information as detailed below. You should define at least one
inbound or outbound direction.
• Class: Select a DiffServ class from the list of defined classes.

• Inbound: Define the portion of the interface’s inbound capacity to be reserved.

• Guaranteed bandwidth: The bandwidth guaranteed to be marked with the
QoS Class.
• Bandwidth Limit: The upper limit of the bandwidth to be marked with the
QoS Class. Traffic in excess of the Bandwidth Limit will not be marked. For
example, if the interface’s capacity is 256MB and Bandwidth Limit to 192MB,
then traffic beyond 192MB will not be marked.
• Outbound: Define the portion of the interface’s outbound capacity to be marked
by defining a Guaranteed Bandwidth and a Bandwidth Limit as described above.
4 Click OK. The new class is added.

Working with Low Latency Classes

FloodGate-1 Low Latency Queuing makes it possible to define special classes of service
for “delay sensitive” applications like voice and video. Rules under these classes can be
used together with other rules in the QoS Policy Rule Base. Low Latency classes
require you to specify the maximal delay that is tolerated and a Constant Bit Rate.
FloodGate-1 then guarantees that traffic matching rules of this type are forwarded
within the limits of the bounded delay.
For more detailed information, please see “Low Latency Queuing” on page 79.

Chapter 7 Managing Check Point QoS 127

Working with Low Latency Classes

In This Section

To Implement Low Latency Queuing page 128

To Define Low Latency Classes of Service page 129
To Define Class of Service Properties for Low Latency Queuing page 129

To Implement Low Latency Queuing

Having defined one or more Low Latency Classes of Service, you can implement Low
Latency Queuing as follows:
1 In the QoS tab of the Interface Properties window of all interfaces on which Low
Latency classes are implemented (see “Specifying Interface QoS Properties” on page
95), click Add under DiffServ and Low Latency classes to add a new class, or Edit to
edit the properties of an existing class.
2 In the window (FIGURE 7-21 on page 126), select the
Add QoS Class Properties
Low Latency classand define the Inbound and Outbound parameters (see “To Add
QoS Class Properties for Expedited Forwarding” on page 125).
3 Click OK. You can now add Low Latency Classes to the QoS Policy Rule Base.
4 Right-click in the Name column of a rule and choose Add Class of Service, or
choose Add QoS Class from the Rules menu.
5 Specify whether the class should appear above or below the rule in the Rule Base.

Note - The order of the classes in the Rule Base must be DiffServ, followed by Low
Latency, and then Best Effort. You will not be able to add a Low Latency class to the Rule
Base above any DiffServ classes you may have.

6 Choose the required Class of Service from the dropdown menu in the Add Class of
window (FIGURE 7-23).
Service
FIGURE 7-23Add Class of Service Window

7 Click OK. A class header appears in the Rule Base.

8 Add rules under the QoS Class you defined, by either:

128
 To Define Low Latency Classes of Service

• Choosing Rules>Add Rule>Below from the menu, or

• Right-clicking on the QoS Class and choosing Add Rule>Below from the menu.

To Define Low Latency Classes of Service

Before a Low Latency class can be implemented on an interface and used in the
FloodGate-1 Rule Base, it must be defined.
1 From the Manage menu select QoS>QoS Classes. The QoS Classes window is
displayed (FIGURE 7-18 on page 124).
2 Define the Low Latency Class of Service as described in “To Define a DiffServ
Class of Service” on page 123.
3 To define a new Low Latency class, click New and select Low Latency Class of
Service to display the Class of Service Properties window (FIGURE 7-24 on
page 129).

To Define Class of Service Properties for Low Latency

Queuing
1 From the Manage menu select QoS>QoS Classes. The QoS Classes window is
displayed (FIGURE 7-18 on page 124).
2 Click New and select Low Latency Class of Service to display the Class of Service
Properties window (FIGURE 7-24).
FIGURE 7-24Low latency Class of Service Properties Window

3 Enter the following details:

• Name: The name of the Class of Service.

• Comment: Enter the text to be displayed when this class is selected in the QoS
Classes window (FIGURE 7-18 on page 124).

Chapter 7 Managing Check Point QoS 129

Working with Authenticated QoS

• Color: Select a color from the dropdown list.

• Class Priority: Select one of the five priority types from the dropdown list (Class
1 being the highest priority).
4 Click OK. The new Low Latency Class of Service is saved.

Working with Authenticated QoS

Check Point Authenticated QoS provides Quality of Service (QoS) for end-users in
dynamic IP environments, such as remote access and DHCP environments. This
enables priority users, such as corporate CEOs, to receive priority service when
remotely connecting to corporate resources.
For more detailed information, please see “Authenticated QoS” on page 86.

To Use Authenticated QoS

In order to apply Authenticated QoS in a rule, follow these steps:
1 Make sure that the UAS package is installed on the module that performs
Authenticated QoS.
2 Make sure that the User Authority Server, under Check Point Products Installed, is
checked on the VPN-1 Pro Module upon which you are installing the policy.
3 Create a group in Manage>Users>New>Group in the menu. The Group Properties
window is displayed.
FIGURE 7-25 Group Properties Window

130
 To Use Authenticated QoS

4 Include all the user(s) whom you want to give priority by selecting the user and
clicking .
To remove a user from the group, select the user and click .
5 Make a rule and in the Source column, right-click and select Add User Access.
For example, if the CEO of your company is in a remote location and wants to
access his email and without waiting too long, create a rule as follows:
TABLE 7-6 A Rule that Allows Access to email from a Remote Location

Rule Source Destination Service Action

Name

CEO CEO@localnet Any Pop-3 Weight 10

Guarantee 50,000
Bps

Note - To minimize the resources taken up by Authenticated QoS, it is recommended that

Authenticated QoS rules refer to specific services, and unless absolutely necessary, you
should not include Any in the Service field.

6 Install the policy.

Note - The user must be authenticated in the UAS in order for the QoS policy to be
enforced.

Policy-wide properties for Authenticated QoS can be defined in the FloodGate-1 page
of the Global Properties window (FIGURE 7-1 on page 94). For more information, see
“Defining QoS Global Properties” on page 94.

Managing QoS for Citrix ICA Applications

In order to deliver a QoS solution for the Citrix ICA protocol, complete the following
procedures:
1 Disable session sharing in the Citrix Program Neighborhood.
2 Modify your Security Policy to allow the Citrix_ICA and Citrix_ICA_Browsing
services.

Note - The Any service does not include the Citrix ICA service.

Chapter 7 Managing Check Point QoS 131

Managing QoS for Citrix ICA Applications

3 Discover the Citrix application names, as defined by the Citrix Administrator, and
retrieve your Citrix ICA application names from the SmartView Tracker. This
includes turning on the application detection check box and installing Security and
QoS Policies.
4 Define new Citrix TCP services with the application names you have detected.
5 Add the appropriate Citrix TCP services to rules in your QoS Policy.
6 Install the QoS Policy.

In This Section

Disabling Session Sharing page 132

Modifying your Security Policy page 133
Discovering Citrix ICA Application Names page 133
Defining a New Citrix TCP Service page 136
Adding a Citrix TCP Service to a Rule (Traditional Mode Only) page 136
Installing the Security and QoS Policies page 137

Disabling Session Sharing

Citrix enables session sharing by default. In this mode, traffic from all the applications
used by a specific client share the same TCP connection. In order for Check Point
QoS to prioritize different Citrix ICA applications from the same client, you must
disable session sharing. This means that every application uses a separate TCP
connection (all going to the same server port, 1494, from different source ports).
You should contact the Citrix Administrator to configure the correct mode.

To Disable Session Sharing:

1 Double-click the Citrix Program Neighborhood icon placed on the desktop by the
Citrix install program.
2 Click the Settings icon or select Application Set Settings from the File menu.
3 Select the Default Options tab.
4 Select something other than Seamless Window from the Window Size dropdown list.

132
 Modifying your Security Policy

Modifying your Security Policy

You must modify your Security Policy to enable the new Citrix_ICA TCP and
Citrix_ICA_Browsing UDP services. The Citrix_ICA service initializes the stateful
inspection of the Citrix ICA protocol. The Citrix_ICA service is not included in the
Any service of the Security Policy and must therefore be enabled in one of the
following ways:
• In the Security tab add a rule to your Security Policy with the Citrix_ICA TCP
service. Similarly, add a rule for the Citrix_ICA_Browsing service. Alternatively,
you can add simply add the Citrix_metaFrame group, which incorporates both the
Citrix_ICA TCP and Citrix_ICA_Browsing UDP services.
OR
1 Expand the TCP branch of the Services Tree. Double-click on the Citrix_ICA
service. The TCP Service Properties - Citrix _ICA window is displayed.
2 Click Advanced. The Advanced TCP Service Properties window is displayed.
3 Check Match for Any to turn on the Citrix ICA protocol inspection without having
to add a specific rule for the Citrix_ICA service (if the Any service is allowed).

Discovering Citrix ICA Application Names

In order to discover the Citrix ICA application name, as defined by the Citrix
Administrator, use Check Point QoS to snoop the wire and send logs (of type alert) to
the SmartView Tracker, recording the Citrix ICA application name. The Citrix ICA
application detection is turned off by default.

Note - The frequency of recording an application name log (alert) is 24 hours.

Advanced: If you want to reset the application detection cache in order to re log a
Citrix ICA application on the wire even if it was logged in the past 24 hours use the
following command line instruction:
fw tab -t fg_new_citrix_app -x

To Enable Citrix ICA Application Name Logging:

1 Double-click on the gateway in the Network Objects Tree. The Check Point
Gateway - General Properties window is displayed.

Chapter 7 Managing Check Point QoS 133

Managing QoS for Citrix ICA Applications

2 Choose Logs and Masters > Additional Logging in the tree on the left side of the
Check Point Gateway - General Properties window. The Additional Logging
Configuration window is displayed.
FIGURE 7-26 Additional Logging Configuration Window

3 Check Detect new Citrix ICA application names to enable Check Point QoS to log
the Citrix application names.
4 Click OK. Citrix ICA application name detection is enabled.
5 Create a Security Policy with a valid rule that uses the Citrix_ICA service.
6 Install the QoS and Security policies on the QoS Module and let it run for a period
of time. See "Installing the QoS Policy" on page 68.

Note - The QoS policy content is irrelevant to the application detection feature.

134
 Discovering Citrix ICA Application Names

7 View the QoS log entries using SmartView Tracker (the entries are of Type Alert
and contain the Citrix ICA application names). Once you have the application
names you can turn off the application detection, as well as define new Citrix TCP
services to use in a QoS policy. For example:
FIGURE 7-27Record Details Window

Note - It is a pre-requisite that the Citrix_ICA TCP be enabled in the Security Policy.

To Disable Citrix ICA Application Name Logging:

1 Double-click on the gateway in the Network Objects Tree. The Check Point
Gateway - General Properties window is displayed.

2 Choose Logs and Masters > Additional Logging in the tree on the left side of the
Check Point Gateway - General Properties window. The Additional Logging
Configuration window is displayed.
3 Uncheck Detect new Citrix ICA application names so that Check Point QoS will
not log the Citrix application names.
4 Click OK. Citrix ICA application name detection is disabled.
5 Install the QoS Policy.

Chapter 7 Managing Check Point QoS 135

Managing QoS for Citrix ICA Applications

Defining a New Citrix TCP Service

A new service type was introduced in the Smart DashBoard, Citrix TCP.

To Define a New Citrix TCP Service

1 Right-click on the Citrix TCP branch of the Services Tree, and select New Citrix
TCP. The Citrix Service Properties window is displayed.

2 Enter the following details in the Citrix Service Properties window, as shown in the
example below:
• Name: The name of the new service.
• Comment: A comment describing the new service.

• Color : Select a color from the dropdown list.

• Application: The exact name (case insensitive) of the Citrix Application.

FIGURE 7-28Citrix Service Properties Window

Note - The application name is case insensitive.

3 Click OK to create the new Citrix Class of Service.

Adding a Citrix TCP Service to a Rule (Traditional Mode Only)

Once you have created a new Citrix TCP service, you can add the service to a rule in
your QoS Policy, in the usual manner. See “Editing QoS Rule Bases” on page 98.

136
 Installing the Security and QoS Policies

Installing the Security and QoS Policies

Once you have created the appropriate Security and QoS Policies these must be
installed.

Managing QoS for Citrix Printing

In This Section

Configuring a Citrix Printing Rule (Traditional Mode Only) page 137

Configuring Check Point QoS Topology page 138

Printing generates relatively large quantities of data, causing the TCP connection to
consume excessive quantities of bandwidth. Clearly, from a QoS perspective this type
of connection should be identified and the bandwidth made available to these
connections should be limited.
There are three primary methods of printing in the MetaFrame environment, IP
Network printing, MetaFrame Auto-Creation of printers and local MetaFrame printing.
Check Point QoS provides a solution for printing traffic using the MetaFrame
Auto-Creation of printers printing method, by classifying each ICA connection as
either a printing or a non-printing connection.
A connection that is classified as printing is assigned to a Citrix printing rule. This rule
can be configured to limit printing traffic and thus avoid excessive consumption of
bandwidth. A connection that is classified as non-printing is assigned to a rule according
to the regular matching method.
Classification of the connection is dynamic and is based on examining the ICA priority
bits of each packet. An ICA connection is therefore matched dynamically to one of 2
different rules depending on the type of data passing through the connection at any
point in time.
It is recommended that you limit the bandwidth per connection for printing to 25Kbps.
This value represents the average bandwidth utilization of a single non-printing Citrix
ICA session versus an additional 150Kbps of bandwidth per session that printing often
requires. This preserves bandwidth for other traffic.

Configuring a Citrix Printing Rule (Traditional Mode Only)

Define a printing rule to which all ICA connections that are in a printing state are
assigned.

Chapter 7 Managing Check Point QoS 137

Viewing the Check Point QoS Modules Status

To Configure a Citrix Printing Rule

1 Position your cursor in the Name field of the QoS tab, at the position where you
want to add a new rule.
2 Right-click and select one of the Add Rule options. The Rule Name window is
displayed.
3 Enter the rule name in the Rule Name field.
4 Click OK to save the rule name.
5 Right-click in the Service column and select Add. The Add Object window is
displayed, listing the network objects defined in the Security Policy and the QoS
Policy.
6 Select the predefined Citrix_ICA_printing service and click OK. The service is added
to the rule.
7 Right-click in the Action column and select Edit Properties. The QoS Action
Properties window is displayed.
8 Select Advanced in the Action Type area.
9 Select Per connection limit in the Limit area.
10 Enter a per connection limit of 25 Kbps in the Per connection limit field
(recommended).
11 Click OK.

Configuring Check Point QoS Topology

When the MetaFrame Auto-Creation of printers printing method is used, the Citrix
printing traffic passes from the Citrix Server to the Citrix Client. To enforce QoS on
this traffic, Check Point QoS must be installed on the Gateway external interface on
the inbound direction, or on the Gateway internal interface on the outbound direction,
that is, Flood-Gate-1 must be able to "see" the traffic passing from the Citrix Server to
the Citrix Client.

Viewing the Check Point QoS Modules Status

To Display the Status of Check Point QoS Modules Controlled
by the SmartCenter Server
Use the Check Point SmartView Status application and the SmartView Monitor. For
information about the Check Point SmartView Status, see the SmartCenter Guide.

138
 To Turn on QoS Logging

Enabling Log Collection

In order for a connection to be logged, the QoS logging flag must be turned on and
the connection’s matching rule must be marked with either Log or Account in the
Track field of the rule. For further information on how Check Point QoS’s logging
features work see “Overview of Logging” on page 143.

In This Section

To Turn on QoS Logging page 139

To Confirm that the Rule is Marked for Logging page 140
To Start SmartView Tracker page 140

To Turn on QoS Logging

A QoS Module logs to the Check Point log if Turn on QoS Logging is checked in the
Additional Logging page (under Logs and Masters) of the QoS Module’s Properties
window (FIGURE 7-29 on page 139). By default Qos Logging is turned on.
FIGURE 7-29 Properties Window - Additional Logging Configuration

Chapter 7 Managing Check Point QoS 139

Enabling Log Collection

To Confirm that the Rule is Marked for Logging

1 Select the rule whose connection will be logged.
2 Confirm that either Log or Account appear in the Track field. See “To Modify
Tracking for a Rule” on page 115.
FIGURE 7-30 Track Logging or Accounting

To Start SmartView Tracker

To start SmartView Tracker, double-click on the SmartView Tracker icon, or choose
SmartView Tracker from the Window menu in the SmartDashboard window.
FIGURE 7-31 Log showing FloodGate-1 Entries

Note - The SmartCenter Server reads the Log File and sends the data to the SmartConsole
for display. The SmartConsole only displays the data.

It is now possible to view log data according to:

• Rule Name

140
 To Start SmartView Tracker

• Rules using DiffServ

• Control type having to do with install and uninstall logs
For more information, see “SmartView Tracker” in the SmartCenter Guide.

Chapter 7 Managing Check Point QoS 141

Enabling Log Collection

142
CHAPTER 8

SmartView Tracker

In This Chapter

Overview of Logging page 143

Examples of Log Events page 147
Examples of Account Statistics Logs page 149

Overview of Logging
The SmartView Tracker enables you to view entries in the Log File. Each entry in the
Log File is a record of an event or an account record. The SmartView Tracker gives
you control over the information displayed in the Log File. You can navigate through
the Log File and select the log entries that you would like to display. You can view the
log entries for all the installed Check Point products or for a selected product, such as
Check Point QoS or VPN.
Two types of events are logged. TABLE 8-1 on page 144 describes the features unique
to event logs and TABLE 8-2 on page 146 describes the features unique to accounting
logs.
The following two conditions must be met for a connection to be logged:
• The QoS logging checkbox must be selected in the Gateway Properties -
Additional Logging Configuration window shown in FIGURE 7-29 on page 139
must be selected. (By default this is automatically selected.)
• The connection’s matching rule must be marked with either Log or Account in the
Track field of the rule. Refer to “To Confirm that the Rule is Marked for
Logging” on page 140 and “To Modify Tracking for a Rule” on page 115.
Further information on how to start the SmartView Tracker can be found in “Enabling
Log Collection” on page 139.

143
Overview of Logging

The following table describes the non-accounting events logged by SmartView

Tracker:
TABLE 8-1 SmartView Tracker Non-Accounting Log Events

Log Event Data Returned Presentation Express or

Traditiona
l modes
Connection Reject
QoS rejects a The name of the Generated as Traditional
connection when the matching rule on a reject log. mode only.
number of guaranteed account of which the Unified with PCG is a
connections is connection was rejected. the initial feature of
exceeded and/or when connection Traditional
you have configured log. mode.
the system not to
accept additional
connections.
Running Out of Packet Buffers

144
TABLE 8-1 SmartView Tracker Non-Accounting Log Events

Log Event Data Returned Presentation Express or

Traditiona
l modes
• QoS’s global packet A string explaining the New log Traditional
buffers are exhausted. nature of the problem record mode only.
• One of the and the size of the created each
interface-direction’s relevant pool. time a global
packet buffers is problem is
exhausted. A report is reported.
generated a maximum
of once per 12 hours.
LLQ Packet Drop
When a packet is The statistics are Unified with Traditional
dropped from an LLQ computed from the last the initial Mode only.
connection. A report is time an LLQ Packet connection LLQ is a
generated a maximum Drop log was generated log. feature of
of once per 5 minutes. for all relevant interface Traditional
directions. The mode.
following are logged:
1. number of bytes
dropped from the
connection.
2. average delay
computed for all the
connection’s packets
that were not
dropped.
3. maximum delay of a
connection packet.
4. maximum delay
difference between
two consecutive
successfully transmitted
packets.

Chapter 8 SmartView Tracker 145

Overview of Logging

TABLE 8-2 Explaining the Accounting SmartView Tracker Log

TABLE 8-3

Logged Data Returned Express or Traditional

modes
General Statistics
The total bytes transmitted Inbound & outbound Both
through QoS for each bytes transmitted by
relevant interface and Check Point QoS.
direction.
Drop Policy Statistics
• Total bytes dropped from Traditional Mode only
the connection as a result of
QoS’s drop policy.
• Count of the bytes
dropped from the
connection because the
maximum used memory
fragments for a single
connection was exceeded
LLQ Statistics
Statistics about the LLQ The following are Traditional Mode only.
connection. logged: LLQ is a feature of
5. number of bytes Traditional mode.
dropped from the
connection due to
delay expiration
6. average packet delay.
jitter which is computed
as the maximum delay
difference between two
consecutive packets.

146
 Connection Reject Log

Examples of Log Events

In This Section

Connection Reject Log page 147

LLQ Drop Log page 147
Pool Exceeded Log page 148

This section describes the log events in the SmartView Tracker:

Connection Reject Log

The connection is rejected because the rule exceeds the number of guaranteed
connections, where Accept additional non guaranteed connections is unchecked in the
QoS Action Properties window (see “QoS Action Properties” on page 36). The log will
include the name as well as the class of the rule in the following format:
rule_name:<class>-><name>.

In the following example, the rule belongs to the class Best_Effort. The name of the
rule (rule_name) is udp2.
TABLE 8-4 Connection Reject Log — Example

... Time Product Interface Type Action Information ...

... 15:17: QoS daemo log reje rule_name:Bes ...

09 n ct t_Effort->udp
2

LLQ Drop Log

When a packet from the LLQ connection is dropped, LLQ information is computed
and logged from the last time a log was generated. This information includes significant
data logged from the relevant interface-direction. In the following example, the
information logged includes:
• s_in_llq_drops: The number of bytes dropped from the connection on the
Server-In interface direction.
• s_in_llq_avg_xmit_delay: The average delay computed for all the connection's
packets that were not dropped on the Server-In interface direction.
• s_in_llq_max_delay: The maximum delay of a connection packet that was not
dropped on the Server-In interface direction.

Chapter 8 SmartView Tracker 147

Examples of Log Events

• s_in_llq_xmit_jitter: The maximum delay difference between two consecutive

successfully transmitted packets of the connection on the Server-In interface
direction. Any packets which are dropped in between the two successfully
transmitted packets are ignored.
• s_in_llq_recommended_delay: The default delay that can be entered into the Add
Low Latency QoS Class Properties window in order to achieve a minimal number of
dropped bytes.
TABLE 8-5 LLQ Drop Log — Example

TABLE 8-6

... Product Type Information ...

... QoS log s_in_llq_drops:3000 ...

s_in_llq_avg_xmit_delay: 900
s_in_llq_max_delay: 1351
s_in_llq_xmit_jitter: 1351
s_in_llq_recommended_delay:2000

In the above example relevant data was observed only on the Server-In interface
direction, therefore only Server-In counters are available.
Note - There are several reasons why logging might not occur on a specified interface
direction:
• QoS might not be installed on all the interfaces directions.
• No packets were seen on other interface directions.
• Data on other interface directions might not be significant, for instance, the
values logged might be all zeroes.

Pool Exceeded Log

The designated size of the pool is exceeded, whether the pool is set for a particular
interface direction, or whether it represents the global pool. In the following example,
the information logged includes:
• an interface direction (ifdir) has a pool size of 8 fragments
• the interface name is E100B1, and the direction is outbound (marked by little cube
juxtaposed to the interface name which has an outward pointing arrow) in the
Inter. column.

148
 General Statistics Data

TABLE 8-7 Pool Exceeded Log — Example

TABLE 8-8

.. Product Interface Type Information ...

.

... QoS E100B contr info:Ifdir Memory Pool ...

1 ol Exceeded Pool_size:8

Examples of Account Statistics Logs

In the Check Point SmartView Tracker, the account logs always include the
segment_time information (the time from which the information about the log was
gathered) in the Information column.
TABLE 8-9 The Mandatory Fields in Account Logs

TABLE 8-10

... Product Type Information ...

... QoS Account segment_time 8May2002 12:24:57 ...

In This Section

General Statistics Data page 149

Drop Policy Statistics Data page 150
LLQ Statistics Data page 150

Account Logs may include any or all of the above information:

Note - Only significant data is logged and presented in the same log record.

General Statistics Data

These statistics include the number of bytes transmitted through QoS in any relevant
interface direction. In the following example:
• s_in_bytes: 5768 bytes were transmitted through Check Point QoS on the
Server-In interface direction.
• s_out_bytes: 154294 bytes were transmitted through Check Point QoS on the
Server-Out interface direction.

Chapter 8 SmartView Tracker 149

Examples of Account Statistics Logs

TABLE 8-11 General Statistics Data — Example

TABLE 8-12

... Information ...

... s_in_bytes:5768 s_out_bytes: ...

154294

Drop Policy Statistics Data

The number of bytes dropped from the connection in any relevant interface direction
as a result of drop policy are logged. The drop policy is aimed at managing FloodGate-1
packet buffers, see “WFRED (Weighted Flow Random Early Drop)” on page 23. This
includes the total number of bytes dropped from the connection since it exceeded its
allocation. In the following example:
• s_out_total_drops: 3914274 bytes were dropped from the connection as a result
of drop policy, on the Server-Out interface direction.
• s_out_exceed_drops: Out of total number of drops (s_out_total_drops) 3914274
bytes were dropped from the connection because it exceeded its allowed number of
fragments, on the Server-Out interface direction.
TABLE 8-13 Drop Policy Statistics Data — Example

TABLE 8-14

... Information ...

... s_out_total_drops:3914274 s_out_exceed_drops: ...

3914274

LLQ Statistics Data

Data items are the same as in “LLQ Drop Log” on page 147, but are computed from
the beginning of the connection and not from the last time a log was generated.

150
CHAPTER 9

Command Line Interface

In This Chapter

Check Point QoS Commands page 151

Setup page 152
fgate Menu page 152
Control page 153
Monitor page 154
Utilities page 155

Check Point QoS Commands

TABLE 9-1 lists the QoS command names.
TABLE 9-1 FloodGate-1 Command Names

VPN-1 Pro and FloodGate-1 Description

Installed on the Same Machine
etmstart Starts FloodGate-1
etmstop Stops FloodGate-1
fgd50 FloodGate-1 daemon

151
Setup

Setup
In This Section

cpstart and cpstop page 152

etmstart page 152
etmstop page 152

cpstart and cpstop

Generally, to stop and start the QoS Module you are required to stop the
VPN-1 Pro using the cpstop and cpstart commands. In the event that you would
like to stop the QoS Module only, you can use the QoS specific etmstart and
etmstop commands. For more on cpstop and cpstart, see the SmartCenter Guide.

etmstart
etmstart loads the FloodGate-1 Module, starts the FloodGate-1 daemon (fgd50), and
retrieves the last policy that was installed on the FloodGate-1 module.

etmstop
etmstop kills the FloodGate-1 daemon (fgd50) and then unloads the FloodGate-1
policy and Module.

fgate Menu
The following menu is displayed when typing fgate from the command line.
FIGURE 9-1 fgate Menu

152
Control
In This Section

fgate page 153

fgate load page 153
fgate unload page 153
fgate fetch page 153

fgate
The fgate program is used to manage FloodGate-1. Its specific action is determined by
the first command line argument, as described in the following sections:

fgate load
fgate load runs a verifier on the policy file. If the policy file is valid, fgate compiles
and installs a QoS Policy to the specified QoS Modules. It can only be run from the
SmartCenter Server.

Syntax
fgate load <rule-file.F> [targets]

If targets is not specified, the QoS Policy is installed on the local host.

fgate unload
fgate unload uninstalls a QoS Policy from the specified QoS Modules. It can only be
run from both the SmartCenter Server and localhost.

Syntax
fgate unload [targets]

If targets is not specified, the QoS Policy is uninstalled from the local host.

fgate fetch
fgate fetch retrieves the QoS Policy that was last installed on the local host. You
must specify the machine where the QoS Policy is found. Use “localhost” in case there
is no SmartCenter Server or if the SmartCenter Server is down. You may specify a list
of SmartCenter Servers, which will be searched in the order listed.
fgate fetch -f attempts to retrieve policies from all management
stations, one after the other until it succeeds. If the module fails to
retrieve a policy from a SmartCenter Server, it tries to retrieve one
from itself.

Chapter 9 Command Line Interface 153

Monitor

Syntax
fgate fetch [-f | servers]

Examples
fgate fetch localhost
fgate fetch -f
fgate fetch mgmt_server_name

Monitor
In This Section

fgate stat page 154

fgate ver page 155

fgate stat
fgate stat displays the status of target hosts in various formats. If this command is
launched from a SmartCenter server this command can be run on an array of modules.
If this command is launched from a module, the status of the module is returned.

Usage
fgate stat [targets]

The default format displays the following information for each host: product, version,
build number, policy name (Express or Traditional), install time and interfaces number.
If no target is specified, the status of localhost is shown. Example:
fgate stat
FIGURE 9-2 fgate stat Output

154
 Examples
fgate stat
fgate stat gateway1 gateway2

fgate ver
fgate ver displays the FloodGate-1 version number. If the -k option is included, both
the kernel version build number and QoS executable version build number are
returned. Without the -k, only the QoS executable version is specified.

Syntax
fgate ver [-k]

Utilities
In This Section

fgate log page 155

fgate ctl page 155
fgate debug page 156
fgate kill page 156

fgate log
fgate log turns logging on or off in the kernel. It can be used in order to save
resources without reinstalling your QoS policy. the stat option returns the current
state of logging.

Syntax
fgate log < on | off | stat >

By default, fgate log is turned on.

fgate ctl
fgate ctl sends control information to the QoS kernel module.

Chapter 9 Command Line Interface 155

Utilities

Syntax
fgate ctl etmreg

parameter meaning
etmreg etmreg is for Unix platforms only. fgate ctl turns
on or off the QoS kernel.

fgate debug
fgate debug turns on a debug flag which sends additional debugging information to the
fgd logfile: $FGDIR/log/fgd.elg. The default is off.

Syntax
fgate debug < on | off >

fgate kill
fgate kill sends a signal to a FloodGate-1 daemon. The SmartCenter Server does
not run the QoS daemon therefore this command is valid only on modules.

Syntax
fgate kill [-t sig_no] proc-name

parameter meaning
[-t sig_no] proc-name If the file
$FWDIR/tmp/<proc-name>.pid exists, send sig_no to
the pid given in the file.
If no signal is specified, signal 15 (SIGTERM) is sent.
The FloodGate-1 daemon writes the pids to files in the log directory upon startup.
These files are named $FWDIR/tmp/<daemon_name>.pid. For example, the file
containing the pid of the FloodGate-1 snmp daemon is $FWDIR/log/snmpd.pid.

Examples

The following command:

fgate kill fgd

sends signal 15 to the FloodGate-1 fgd daemon.

156
The following command:
fgate kill -t 1 fgd

sends signal 1 to the FloodGate-1 fgd daemon.

Chapter 9 Command Line Interface 157

Utilities

158
CHAPTER 10

Check Point QoS FAQ

(Frequently Asked
Questions)

In This Chapter

Questions and Answers page 159

Questions and Answers

In This Section

Introduction page 160

Check Point QoS Basics page 160
Other Check Point Products - Support and Management page 163
Hardware Support page 165
Policy Creation page 165
Capacity Planning page 167
Protocol Support page 168
Installation/Backward Compatibility/Licensing/Versions page 169
How do I? page 169
General Issues page 171

159
Questions and Answers

Introduction
Question: What is Check Point QoS?

Check Point QoS is a policy-based, Quality of Service (QoS) solution for

VPNs, private WANs and Internet links. It optimizes network performance
by assigning priority to business-critical applications and end users. Check
Point QoS is tightly integrated with VPN-1® Pro
Question: How can I comment on this FAQ?

For comments and ideas regarding this FAQ or Check Point QoS in general,
please send email to: fgfaq@checkpoint.com
For additional technical information about Check Point QoS, consult Check
Point’s SecureKnowledge database at
http://support.checkpoint.com/kb/
Question: Where can I find further information regarding Check Point QoS?

Find further details about Check Point QoS at

http://www.checkpoint.com/products/accelerate/FloodGate-1.html
Question: Do I have to know how to administrate Provider-1/SiteManager-1 to manage
Check Point QoS?

Knowing how to administrate Provider-1/SiteManager-1 is not mandatory,

but prior knowledge of Provider-1/SiteManager-1 is helpful when working
with Check Point QoS.

Check Point QoS Basics

Question: When should I use Traditional mode and when should I use Express mode?

Traditional mode should be used if you need fine-tuned functionality and

enhanced Check Point QoS features. Express mode should be selected if
your system requires only basic QoS.
Question: What are the benefits of using each mode?

Traditional mode provides you with optimal QoS functionality, whereas

Express mode increases performance and needs less CPU and less memory.
Question: Can I change from Express mode to Traditional mode and vice versa?

You can change a policy from Express mode to Traditional mode, however,
you cannot change a policy from Traditional mode to Express mode.
Therefore it is recommended that if you are unsure which to install, you

160
 Check Point QoS Basics

should begin with Express mode, maintaining the option to transition to

Traditional mode, if you find that your policy required heightened Check
Point QoS functionality.
Question: What is the highest weight I can use in a rule?

Weights are relative. The only limitation is the Maximum weight of rule
parameter, which is defined in the Global Properties window under Check
Point QoS. The default parameter is 1000, but can be changed to any
number.

Note - This parameter is only used to assist in input validation.

In the example shown in TABLE 10-1, you can see the significance of the
value of the weight allocated in two different policies. In the example both
the HTTP and FTP connections initially enjoy an equal share of the
available bandwidth, although they each had a weight of 500 in Policy 1 and
a weight of 2 in Policy 2.
By adding a third rule to both policies you can significantly change the
result. for example, An SMTP connection with a weight of 100 can be
added to each policy. Due to the high initial weights used in Policy 1, there
is an insignificant change to the amount of bandwidth available for the
HTTP connection in Policy 1 + third rule. However, due to the low initial
weights used in Policy 2, the amount of bandwidth that is available to the
HTTP connection in Policy 2 + third rule is significantly reduced.
TABLE 10-1 Example of Highest Weight Differentiation

Policy 1 HTTP gets ...and Comment

equals
HTTP weight = 500, 500/(500+500) =½ Equal weight is given to
FTP weight =500 each rule.
Policy 2
HTTP weight = 2, 2/(2+2) =½ Equal weight is given to
FTP weight =2; each rule.

Policy 1 + third rule

Chapter 10 Check Point QoS FAQ (Frequently Asked Questions) 161

Questions and Answers

Policy 1 HTTP gets ...and Comment

HTTP weight = 500,
FTP weight =500,
SMTP weight = 100
Policy 2 + third rule
HTTP weight = 2,
FTP weight =2;
SMTP weight = 100
equals
500/(500+500+ = Due to the initial high
100) 500/1100 value of the weights in
Policy 1, the amount of
bandwidth available to the
HTTP connection is only
marginally less than in
Policy 1 even after the
introduction of the third
rule.
2/(2+2+100) = 2/104 Due to the low value of
the weights in Policy 2,
the amount of bandwidth
available to the HTTP
connection is now
significantly less as a result
of the introduction of the
third rule.

Question: Should I install Check Point QoS on the external or the internal interface?

While Check Point QoS can run on both interfaces, it is highly

recommended to position Check Point QoS on the external interface only.
Question: What is the difference between guarantees and weights?

Guarantees and weights are similar in their behavior. Despite the difference
in their dictionary meaning, they both guarantee the allocated bandwidth to
the matched traffic. The differences between them are:
• Guarantees are stated in absolute numbers (for example, 20000bps) and weights
are stated in relative numbers (for example, 100).
• Guarantees are allocated their share of bandwidth before weights. For example if
you have a link of 1.5 MB:
Your Rule Base is:
• HTTP Guarantee 1Mb
• FTP Weight 40

• SMTP Weight 10

162
 Other Check Point Products - Support and Management

The result is:

• first 1 MB for HTTP is allocated, then
• 0.4 MB for FTP is allocated and 0.1MB for SMTP is allocated.

Use guarantees to define bandwidth in absolute terms or for per connection

guarantees.
Question: How does Check Point QoS handle TCP retransmitted packets?

When a retransmission is detected, Check Point QoS checks to see if the

retransmitted data is already contained in the Check Point QoS queue. If so,
the packet is dropped. This unique Check Point QoS capability eliminates
retransmissions that consume up to 40% of a WAN link, and saves memory
required to store duplicated packets.
Question: Which Firewall resources does Check Point QoS support in the Rule Base?

Check Point QoS can use its resources to inspect HTTP traffic. Resources
are defined using the URI for QoS option and can contain specific URLs or
files. For example, you can limit Web surfing to the site
http://www.restrict-access-to-this-site.com. You need to add a QOS URI
resource that looks for the string “www.restrict-access-to-this-site.com”
(without http://). Then use the resource in a Check Point QoS rule and add
a limit.
Question: Do guarantees waste bandwidth?

No. Check Point QoS uses a sophisticated queuing mechanism. An

application only takes as much bandwidth as it needs. Any unused bandwidth
is then available for use by other applications.
Question: How do I know if loaned bandwidth is available for applications that may
need it back?

There is no loaned bandwidth in Check Point QoS. Bandwidth that is not

utilized by a guarantee/weighted rule is immediately (on a per-packet basis)
distributed to the other connections, according to their relative priorities.
The important thing to remember is Resolution (referring to level of
granularity). Check Point QoS allocates bandwidth on a per packet basis.
Therefore, only one packet is allocated at a time, resulting in the most
accurate scheduling policy.

Other Check Point Products - Support and Management

Question: Where is Check Point QoS placed in the Provider-1/SiteManager-1 Inspection
chain?

Chapter 10 Check Point QoS FAQ (Frequently Asked Questions) 163

Questions and Answers

Check Point QoS is composed of two Modules:

• QoS Policy, which is in charge of rule matching
• QoS Scheduling, which is in charge of packet scheduling
Question: Does Check Point QoS work With Provider-1/SiteManager-1?

Yes. One of Check Point QoS’s most important features is its unique and
sophisticated integration with Provider-1/SiteManager-1. Its integration
features include:
• accurate classification of VPN traffic (inside the VPN tunnel)
• classification of NATed traffic
• shared network objects and topology (that save you time and effort in
administration)
• common Check Point SmartDashboard with an advanced GUI but a familiar
look and feel
• authenticated Quality of Service allows you to assign bandwidth to VPN remote
users
• DiffServ Support and Check Point QoS bring Better than Frame Relay QoS to
the VPN world
• log verification
Question: Is SmartView Monitor a part of Check Point QoS?

No. As of NG with Application Intelligence (R55), SmartView is a separate

product that is bundled with Check Point QoS.
Question: Does Check Point QoS support Load Sharing configurations?

Yes, Check Point QoS supports all ClusterXL configurations. Check Point QoS
supports the SYNC mechanism and therefore can be used with CPLS/CPHA or
third-party solutions. For OPSEC partner solutions, see the OPSEC Website:
http://www.opsec.com/ for certification.
Question: Does Check Point QoS support NATed traffic?

Check Point QoS has full support for NATed traffic, including matching,
scheduling, limiting and all other Check Point QoS features.
Question: What is the maximum number of QoS Modules I can manage?

QoS Modules management is identical to VPN/FireWall Module

management. Thus, the maximum number of Modules is identical to the
maximum number of VPN/FireWall Modules that are managed.

164
 Hardware Support

Question: Do I need to run QoS on the SmartCenter Server?

Yes, in order to manage a QoS Module you need to install Check Point
QoS on the SmartCenter Server.

Hardware Support
Question: What platforms does Check Point QoS support?

Check Point QoS supports the following platforms:

• Solaris 8 UltraSPARC (32 bit and 64 bit)
• Solaris 9 UltraSPARC (64 bit only)
• Windows NT 4.0 - Server and Workstation (SP6a)
• Windows 2000 - Server and Professional (SP1, SP2, SP3)
• Red Hat Linux - 7.0 (kernels 2.2.16, 2.2.17, 2.2.19)
• Red Hat Linux - 7.2 (kernels 2.4.9-31)
• Red Hat Linux - 7.3 (kernels 2.4.18-5)
• CP - SecurePlatform
• IPSO 3.7
Question: Is Check Point QoS available on appliances?

Yes. Check Point QoS is available on Nokia appliances and on several

Linux-based appliances.
Question: Does Check Point QoS support multiple CPUs?

Check Point QoS can run on multiple CPU machines.

Question: Does Check Point QoS improve performance with multiple CPUs?

Using Check Point QoS with VPNx on a multiple CPU machine creates a
major performance improvement over using a single CPU machine. When
running Check Point QoS and Provider-1/SiteManager-1 on a multiple
CPU machine, performance improvements are expected.
Question: Does Check Point QoS work with SecureXL?

Check Point QoS and Performance Pack cannot run simultaneously on the
same gateway.

Policy Creation
Question: When should I use LLQ (Low Latency Queuing)?

Chapter 10 Check Point QoS FAQ (Frequently Asked Questions) 165

Questions and Answers

LLQ is best suited for VoIP applications, Video conferencing and other
multimedia applications. LLQ is targeted for applications where:
• a minimal guaranteed bandwidth is required for adequate performance
• low delay and Jitter are required
Question: Is QoS Rule Base “first match”?

From Check Point QoS NG forward, all QoS rules are matched on the “first
match” principle. Meaning that only the first rule that applies to a
connection is activated.
For example, if you have a rule for CEO traffic and a rule for HTTP traffic,
the rule that appears first within the Rule Base will be matched to all CEO
surfing.
Correct Rule Base (CEO is the first match)
1 SRC=CEO => Guarantee = 128Kbps
2 Service=HTTP => Limit = 64Kbps
Incorrect Rule Base (CEO traffic will be limited)
1 Service=HTTP => Limit = 64Kbps
2 SRC=CEO => Guarantee = 128Kbps
Question: I am using QoS on multiple modules. What is the best way to organize my
Rule Base?
• If you are managing Modules with identical bandwidth and you want an
identical policy for all Modules, define as All in the Install On field.
• If you are managing Modules with varied bandwidths and want an identical
policy for all Modules, you can have one policy installed on all modules. It is
best to use weights since they assign relative bandwidth and not a fixed one.
Remember that weights also guarantee bandwidth allocation.
• If you are managing Modules with varied bandwidths and want a different
policy for all Modules, you can use different sub-rules for each module. You
can also use common rules that are matched for Modules.
Question: When should I use Sub-rules?

Sub-rules should be used when there is hierarchy between objects. For

example, when you want to manage bandwidth according to organizational
structure, such as within an organization that has R&D, Marketing and
operation divisions.
Question: How can I see the top bandwidth-hogging applications?

166
 Capacity Planning

From the command line run the command rtmtopsvc.

Capacity Planning
Question: What are Check Point QoS’s memory requirements?

To run Check Point QoS, the following amount of free memory is needed
(in addition to the memory needed for Provider-1/SiteManager-1):
FIGURE 10-1 Check Point QoS memory requirements

Number of Manageme Module (or Management+ Module)

connection nt
s
5,000 0 MB 32.5 MB
10,000 0 MB 39 MB
25,000 0 MB 57 MB
50,000 0 MB 91 MB
100,000 0 MB 156 MB

• These numbers include SmartView Monitor and UserAuthority.

• Connections are counted in the Firewall connection table.
• Note that the default size for the connection table is 25,000.
• On an average, each connection requires 1300 bytes.
Question: How do I know which machine I need to run Check Point QoS?

Deciding on a hardware platform and vendors involves many aspects and

each buyer has their own specific considerations such as support, price,
appliances, knowledge, and so on.
As far as performance is concerned, CPU performance is the main factor in
Check Point QoS performance. With Check Point QoS’s reduced memory
footprint and 2003 memory prices, memory should not usually be the cause
of a bottleneck.
Question: How do I tune Check Point QoS performance?

Here are some tips on fine-tuning Check Point QoS performance:

1 Upgrade to the newest Check Point QoS version available. Major improvements in
performance have been introduced in
Check Point QoS NG FP1 and NG FP2.

Chapter 10 Check Point QoS FAQ (Frequently Asked Questions) 167

Questions and Answers

2 In most cases you need to install Check Point QoS only on the external interfaces
of the gateway.
3 Unless you are using limits for inbound traffic, installing Check Point QoS only in
the outbound direction will provide you with most of the functionality and
improvements.
4 Put more frequent rules at the top of your Rule Base. You can use SmartView
Monitor to analyze how much a rule is used.
5 Turn “per connection limits” into “per rule limits”.
6 Turn “per connection guarantees” into “per rule guarantees”.
Question: What is the maximum bandwidth supported by Check Point QoS?

Check Point QoS NG FP1 can support up to 1.13GBps and 890MBps (in
Traditional Mode) of traffic of long UDP packets. In real-world traffic and in
the Rule Base, Check Point QoS supports 330GBps (In Express Mode) and
255 MBps (in Traditional Mode) of traffic.

Protocol Support
Question: What protocols/services are supported by Check Point QoS?

See: http://www.checkpoint.com/products/protect/vpn-1_firewall-1_appsupport.html

Note - New services and applications are added on a permanent basis.

Question: Can I prioritize system administration traffic?

Yes. This can be done in any of the following ways:

• Guarantees for administrators based on authentication
• Guarantees for administrators based on IPs, networks
• Guarantees for applications only administrators use (for example,
Provider-1/SiteManager-1 control protocols, PC-Anywhere)
• Combinations of all the above
Question: Does Check Point QoS support Citrix applications?

Yes, Citrix applications can be differentiated from one another. In addition,

Check Point QoS can identify Citrix ICA printing traffic and re-classify it to
a proper rule.

168
 Installation/Backward Compatibility/Licensing/Versions

Question: Does Check Point QoS support SIP?

Yes. Starting from Check Point QoS FP2, the SIP protocol is supported.
Question: Does Check Point QoS support H323?

Yes. Starting from Check Point QoS FP1, the H323 protocol is supported
Question: Does Check Point QoS support GRE?

Yes. This protocol is supported.

Installation/Backward Compatibility/Licensing/Versions
Question: When will Check Point QoS next feature pack be available?

Check Point QoS feature packs/releases are usually shipped at the same time
Provider-1/SiteManager-1 feature packs are released.

How do I?
Question: How do I guarantee performance for my mail server?

You need to add a rule matching your email traffic. You can do this by
either matching the source/destination of your mail server, or matching mail
protocols (SMTP, POP3, Exchange). For this rule, define a weight or
guarantee that meets the needs of the priorities you want to set.
Question: How do I ensure Quality of Service for Voice Over IP?

Check Point QoS FP1 introduced the VoIP-tuned mechanism Low Latency
Queuing (LLQ). This mechanism is tuned to achieve best latency for
constant bit rate applications, like VoIP.
To limit the number of connections admitted, use LLQ with a per
connection guarantee. For voice, you want to give each conversation a
guaranteed bandwidth. Usually you would want an admission policy that
does not accept additional calls if bandwidth is not adequate.

Note - This is equivalent to the busy tone in old voice system.

Question: How can I prioritize traffic for remote users?

Chapter 10 Check Point QoS FAQ (Frequently Asked Questions) 169

Questions and Answers

Using the Authenticated QoS feature of Check Point QoS, you can
prioritize bandwidth allocation for remote VPN users and Windows domain
user groups. To configure the Windows domain users please refer to the
UserAuthority Guide and read the SecureAgent -> System Setup section.
Question: How do I guarantee performance for my ERP applications?

You need to add a rule matching your ERP traffic. You can do this by either
matching the source/destination of your ERP server, or matching application
protocols (SAP, BAAN, ORACLE). For this rule, define a weight or
guarantee that meets the needs of the priorities you want to set. If your ERP
application is not a predefined service, you can either add it manually or use
the first method.
If you are using ERP over HTTP, check “How can I provide bandwidth for
my intranet applications”?

Question: Can I use Check Point QoS to prevent Denial of Service Attacks?

Check Point QoS’s main goal is not an Anti-Denial of Service tool.

However, there are many situations in which Check Point QoS can be used
to detect, monitor and prevent such attacks. Using SmartView Monitor and
Check Point QoS you can perform detection and monitoring.
Prevention can be achieved in the following ways:
• by limiting applications that are known to be a part of DOS attacks (for
example, ICMP, suspicious URLs).
• by providing guarantees for important traffic (for example, ERP, MAIL,
VoIP).
• by providing guaranteed bandwidth for authenticated users using
Authenticated QoS. Authenticated users can be identified with digital
signatures and can rely on VPN authentication and encryption. Check Point
QoS guarantees that these users will get their bandwidth. The attacker cannot
authenticate to the VPN and will not get bandwidth for the attack.
Question: Why is limiting bandwidth for Napster better than blocking It?

Blocking "nonwork-related" applications might cause users to find a way to

bypass blocking. Prioritizing bandwidth lets users continue with their
activities without damaging critical business processes. Consider a university
where the Internet connection is being used for peer-to-peer file downloads
like Napster and Kazaa. Blocking these services completely may encourage
the students find a smart way to bypass the block, which in turn might cause
legal problems. Check Point QoS offers smarter solutions:

170
 General Issues

• Limiting the allocated bandwidth for such applications – this can be done
with or without the students’ knowledge.
• Limiting the allocated bandwidth during daytime, and providing more
bandwidth at night.
• Providing guarantees to important users (Professors, MIS) while allowing
students to use the reminder of the bandwidth.

General Issues
Question: My machine is experiencing certain technical failures. What should I do?

Check the Web for updated release notes on known issues and limitations.
Contact your vendor for further support.
Question: I set up a guarantee/limit but in SmartView Monitor it seems to be broken?

If you are looking at very low traffic limit (for example, 1000 Bytes per
second) at a high frequency (update every 2 seconds) it might look, as if the
limit is broken since Check Point QoS does not fragment packets. If you
lower the sampling frequency of SmartView Monitor (update every 8
seconds) you will see that limits are kept.
Question: Can Check Point QoS prompt a user for authentication in order to use the
Authenticated QoS feature?

No. In order to use Authenticated QoS, Provider-1/SiteManager-1 must

perform an authentication session prior to the classification of the connection
by Check Point QoS.
Question: Can I deploy Check Point QoS on LAN environments?

Yes. You will need to position the hardware to support the network traffic
you want to prioritize. Check Point QoS is best deployed in congestion
points for network traffic.
Question: What happens if a line’s bandwidth (as defined in the QoS tab of the Interface
Properties window) is less than its physical (“real”) bandwidth?

Check Point QoS will only allocate as much bandwidth as is defined in the
Interface Properties window. Additional bandwidth will not be allocated
regardless of the physical bandwidth of the interface.
Question: What happens if a link bandwidth (of the link defined in Check Point QoS) is
more than its physical (“real”) bandwidth?

Chapter 10 Check Point QoS FAQ (Frequently Asked Questions) 171

Questions and Answers

Check Point QoS will attempt to transmit more than the physical bandwidth
allows. This can cause random traffic drops in the next hop that result in the
loss of critical packets.

172
CHAPTER 11

Deploying Check Point

QoS

In This Chapter

Deploying Check Point QoS page 173

Sample Bandwidth Allocations page 175

Deploying Check Point QoS

Check Point QoS Topology Restrictions
Check Point QoS can manage up to the maximum number of external interfaces
supported by Firewall, subject to the following restrictions. (Refer to the Firewall
documentation for further information):
1 All of the traffic on a managed line must go through the gateway.
2 Each managed line must be connected (directly or indirectly via a router) to a
separate physical interface on the QoS machine. Two managed lines may not share
a physical interface to the QoSmachine, nor may two lines be connected to the
same router.
For example, in the configuration depicted in FIGURE 11-1, the routers can pass
traffic to each other through the hub without the QoS Module being aware of the
traffic.

173
Deploying Check Point QoS

FIGURE 11-1 Two Lines Connected to a Single Interface

In addition, you cannot manage two lines connected to a single router (as in
FIGURE 11-2), since traffic may pass from one line to the other directly through the
router, without the QoS Module being aware of the traffic.
FIGURE 11-2 Two Lines Connected to a Router

An example of a correct configuration is depicted in FIGURE 11-3.

FIGURE 11-3 Correct Configuration

174
 Frame Relay Network

Sample Bandwidth Allocations

Frame Relay Network
In the network depicted in FIGURE 11-4, the branch offices communicate with the
central site and vice versa, but they do not communicate directly with each other or
with the Internet except through the central site. The Web server makes important
company documents available to the branch offices, but the database server supports the
company’s mission-critical applications.
The problem is that most of the branch office traffic is internal and external Web
traffic, and the mission-critical database traffic suffers as a result. The network
administrator has considered upgrading the 56K lines, but is reluctant to do so, not only
because of the cost but also because upgrading would probably not solve the problem.
The upgraded lines would still be filled mostly with Web traffic.
FIGURE 11-4 Frame Relay Network Example

Chapter 11 Deploying Check Point QoS 175

Sample Bandwidth Allocations

The goals are as follows:

1 Allocate the existing bandwidth so that access to the database server gets the largest
share.
2 Take into account that the branch offices are connected to the network by 56K
lines.
These goals are accomplished with the following Rule Base:
TABLE 11-1 Main Rules

Rule Name Source Destination Service Action

Office 1 Office 1 Any Any Weight 10

Limit
56KBps
... ... ... ... ...
Office n Office n Any Any Weight 10
Limit
56KBps
Default Any Any Any Weight 10

Each office has sub-rules, as follows:.

TABLE 11-2 Office Sub-Rules

Rule Name Source Destination Service Action

Start of Sub-Rule

Database Rule Any Database database-service Weight 50

Server
Web Rule Any Web Server http Weight 10
Branch Offices Any Any Any Weight 10
End of Sub-Rule

The sub-rules give database traffic priority over Web traffic and other traffic.

Assumptions
The following assumptions are made in this example:
• The problem (and its solution) apply to traffic outbound from the central site.

176
 Frame Relay Network

Note that FloodGate-1 shapes the branch office lines in the outbound direction
only. FloodGate-1 shapes inbound traffic only on directly controlled interfaces (that
is, interfaces of the FloodGated machine).
• The central site has the capacity to handle the network’s peak traffic load.
• There is no traffic between the offices.

Chapter 11 Deploying Check Point QoS 177

Sample Bandwidth Allocations

178
Appendix A

Debug Flags

Note - Error is turned on by default.

fw ctl debug -m FG-1 Error Codes for Check Point QoS

TABLE A-1 fw ctl debug -m FG-1 Error Codes for Check Point QoS

Command Usage
Line
All commands begin with: fw ctl debug -m FG-1...
driver Driver Attachment
error General Error Flag
chain Main Steps Of QoS Packet Processing
install For Future Use
pkt Packet recording mechanism
citrix Citrix processing
ls Load sharing
tcp TCP Retransmission Detection
sched Packet Scheduling
policy QOS Policy Rules Matching
url QOS URL Matching
dns DNS Related Messages

179
 TABLE A-1 fw ctl debug -m FG-1 Error Codes for Check Point QoS

Command Usage
Line
rtm SmartView Monitor Interaction
auth Authenticated QOS
log Logging
conn Connections Processing
drops Drop Policy
rates Reporting Rule/Connection Rates
dropsv Verbose Version Of Drop Policy
timers Timer Events
chainq Internal Chain Q Mechanism
llq Low Latency Queuing
verbose Used With Other Flags - Adds More Information
automatch Report Matching Process (Debug Version Only)
autosched Report Scheduling Process (Debug Version
Only), a good way of reporting of rates on rules

180
Index

A by source 65
Client/Server
defining classes 123, 125
definition of 77
interaction 27 Expedited Forwarding class 85
Add Class of Service window 123, commands interaction with other rules 78
128 cpstart 152 IPSec packets 78
Add Interface window 116 etmstart 151, 152
Add QoS Class Properties versus Low Latency
etmstop 151, 152 Queuing 85
window 123, 128
Adding Comments to a Rule 120 fgate 152 Disabling Session Sharing 132
allocation of bandwidth 171 fgd50 151
Authenticated IP 95 Comment window 121
Authenticated QoS 130 comments
definition 86 adding to a rule 120 E
using 130 concurrent sessions 28
configuration enforcing 39
distributed 26 enforcing and installing, difference
Configuring a Citrix Printing between 39
B Rule 137
Configuring Check Point QoS
ERP applications 170
example
Topology 138 Account Statics Logs 149
bandwidth connections
allocating 34 Connection Reject Log 147
classifying 33 Drop Policy Statistics Data 150
sample allocations 175 constant bit rate
Bandwidth Policy General Statistics Data 149
computing 81
fetching last installed on LLQ Drop Log 147
ensuring it is not exceeded 83
host 153 LLQ Statistics Data 150
in defining a class 80
loading 153 Pool Exceeded Log 148
limits on 81
Expedited Forwarding 85
cpconfig 28 External Interfaces 162

C
Check Point QoS
D F
architecture 29 default rule 35, 64
deploying 86 fgate 153
for sub-rules 36 fgate fetch 153
displaying page 94 default weight 95
distributed configuration 26 fgate load 153
defaults
Global Properties 94 reset to 95 fgate stat 154
installing and configuring 29 rule weight 95 fgate unload 153
topology restrictions 173 units 95 fgate ver 155
Citrix 168 Defining Sub-Rules 121 fgate ctl 155
Citrix ICA Application Names 133 Denial of Service Attacks 170 fgate debug 156
Citrix MetaFrame Support 86 difference between guarantees and fgate log 155
Citrix Printing Rule 137 weights 162 fgate stat command 154
Class of Service Properties Differentiated Services first rule match principle 66
window 129 (DiffServ) 122 FloodGate Module 26
classifying traffic Differentiated Services, see DiffServ logging 139
by service and source 66 DiffServ status 138
FloodGate-1

181
 configuration 26 Load Sharing 87 defining 43
GUI Management Client 26 loading a Bandwidth Policy 153 New Citrix TCP Service 136
FloodGate-1 loaned bandwidth 163 new rule
FloodGate requirements 13 log default weight 95
installation sequence 44 Connection Reject 144 next feature pack availability 169
new features in NG 19 Drop Policy Statistics 146 Non-authenticated IP 95
technology overview 22 General Statistics 146
FloodGate-1 Topology 138 LLQ Packet Drop 145
LLQ Statistics 146
Running Out of Packet P
Buffers 144
G viewing 143 prioritize system administration
traffic 168
log collection
Get Interfaces button 97 enabling 139 Properties window 139
GRE 169 Log Viewer 140
guarantees 67 starting 140
definition 35
interaction with limits 76
viewing 143
Low Latency class Q
per connection 35, 75 overview 79
total rule 35 priorities 80 QoS Class
using 71 Low Latency Classes 127 adding 123, 128
Low Latency Queuing adding to Rule Base 123, 128
class priorities 80 definition 78
classes 79 DiffServ 77
H constant bit rate 80 editing 123, 128
Low Latency Queuing 79
defining classes 129
H323 169 implementation 128 QoS Classes window 123, 125, 129
interaction with other rule QoS for Citrix ICA
properties 84 Applications 131
maximal delay 80 QoS for Citrix Printing 137
I overview 79
QoS logging
turning on 139
versus DiffServ 85 QoS Policy
Intelligent Queuing Engine 22, 23 when to use 84 installing 68
Interface Properties opening QoS low traffic limit 171 installing and enforcing 39
tab 96
Interface Properties window 123, monitoring 40
128 uninstalling 40
QoS tab 97, 123, 128
interfaces
M verifying and viewing 39
QoS Rule tree 26
activating 97 Queried IP 95
mail server 169
Get Interfaces 97 matching method
properties of 95 first rule 66
IP
authenticated 95
maximal delay
computing 81
R
non-authenticated 95 in defining a class 80
queried 95 rate units 95, 99
maximum weight 95 RDED 22, 24
memory requirements 167 resources
Modifying your Security Policy 133 URI for QoS 34
multiple modules 166
L Retransmission Detection Early
Drop 24
Rule Base
LAN environments 171
limits 67 N adding QoS Classes 123, 128
display 33, 103
definition 35 management 31
interaction with guarantees 76 Napster 170 rules
using 71 network objects 33

182
 adding and inserting 100 Time in a Rule 118 Workstation Properties 49, 96,
adding to Rule Base 99 time objects 118 97
adding under QoS Classes 123, top bandwidth hogging 166 Workstation Properties window
128 top bandwidth hogs 166 General page 52
copying 102 track 115, 116 Topology page 53, 97
Turn on QoS Logging 139
cutting 102
default 35
default weight 95
deleting 102
modifying 102
U
naming 101 URI for QoS resources 34
pasting 102 Users Access
properties of 62 adding 104
source 104, 107, 108, 110, 114 Users Access window 104
time 118 utilities
track 115, 116 fgate ctl 155
fgate debug 156
fgate kill 156
fgate log 155
S
services 34
defining 43 V
Services with Resource window 108
simple window definitions 114 viewing
SIP 169 log 143
SmartDashboard 26 Voice Over IP 169
starting 43 VPN-1 Pro
SmartDashboard Rule Base Editor interoperability 29
window 33, 103 sharing objects with 29
SmartDashboard Rule Base
window 33, 103
source
adding to a rule 104, 107, 108,
110, 114
W
classifying traffic by 65
Weight 94
Stateful Inspection 22 Weighted Fair Queuing 22, 23
status weights
of hosts, displaying using calculating 34
command-line interface 154 setting maximum 95
Status Manager 138 WFRED 22, 23
Sub-rules 166 windows
sub-rules Add Class of Service 123, 128
bandwidth allocation for 37
Add Interface 116
default rule 36
Add Object 104, 107, 108
defining 121
Add QoS Class Properties 123,
example 68
128
viewing 122
Class of Service Properties 129
Interface Properties 123, 128
Properties 139
T QoS Action Properties 36
QoS Classes 122, 123, 125, 129
TCP retransmitted packets 163 Services with Resource 108
TELNET Users Access 104
typical QoS Policy for 65

183
184