Cid 2.41 Ug

Content Inspection Director
Software Version: 2.41
7 July 2006
Table of Contents
Table of Contents
Chapter 1 - Introduction & Overview.............................. 1-1
Introduction ............................................................................. 1-2
Introducing CID ............................................................................. 1-3
CID Overview .......................................................................... 1-5
Content Management Load Balancing ......................................... 1-6
Flow Management ........................................................................ 1-9
Special Protocol Treatment ........................................................ 1-11
Technical Description ................................................................. 1-15
Chapter 2 - Device Management..................................... 2-1

Configuring Device IP Host Parameters for the First Time ..... 2-2
Device IP Host Parameters Introduction ....................................... 2-3
Erasing the Configuration file ........................................................ 2-8
Resetting the Device ..................................................................... 2-9
Version Management and Device Upgrading ....................... 2-10
Introducing Upgrades ................................................................. 2-11
Software Version Update ............................................................ 2-13
Saving and Restoring Configuration Files .................................. 2-18
Upgrading Licenses .................................................................... 2-20
Upgrading Boot Versions ............................................................ 2-24
Device Configuration Options ............................................... 2-25
APSolute Insite ........................................................................... 2-26
Command Line Interface ............................................................ 2-27
Device Access ....................................................................... 2-30
Bandwidth Management Access ................................................ 2-31
Users Table ................................................................................ 2-32
CID User Guide III

Table of Contents
Configuring SNMP ...................................................................... 2-34

Web Based Management ........................................................... 2-48
Telnet and SSH .......................................................................... 2-51
FTP Content Management ......................................................... 2-54
RADIUS Authentication .............................................................. 2-60
Management Ports ..................................................................... 2-62
.................................................................................................... 2-63
Ping Physical Port Permissions .................................................. 2-70
Dedicated Management Port ...................................................... 2-71
Device Tuning ....................................................................... 2-72
Device Tuning Parameters ......................................................... 2-73
Tuning Memory Check ................................................................ 2-74
Device Services .................................................................... 2-75
NTP Support ............................................................................... 2-76
Daylight Saving Time Support ................................................... 2-78
DNS Client .................................................................................. 2-79
Show Tech Support .................................................................... 2-81
Policy Scheduler ......................................................................... 2-82
Device Reporting ................................................................... 2-84
Notifications - General ................................................................ 2-85
E-mail Notification ....................................................................... 2-86
Syslog ......................................................................................... 2-88
Event Log ................................................................................... 2-89
Chapter 3 - Basic Switching & Routing.......................... 3-1

Port Settings ........................................................................... 3-2
Port Mirroring ................................................................................ 3-3
Port Trunking ................................................................................ 3-6
Virtual LAN .............................................................................. 3-8
What is a Virtual LAN? .................................................................. 3-9
CID VLAN Types ........................................................................ 3-10
VLAN Configuration .................................................................... 3-12
VLAN Auto Learn ........................................................................ 3-16
IV CID User Guide

Table of Contents
VLAN Tagging Support ............................................................... 3-18

Redundancy ............................................................................... 3-22
Bridging ..................................................................................... 3-23
IP Addressing & Routing ...................................................... 3-24
IP Addressing ............................................................................. 3-25
Routing ....................................................................................... 3-26
Alternate Default Gateway .......................................................... 3-28
Routing Information Protocol ...................................................... 3-29
Open Shortest Path First ............................................................ 3-32
Chapter 4 - Basic Application Switching ....................... 4-1

Farm Management .................................................................. 4-2
Farm Management Overview ....................................................... 4-3
Dispatch Methods ......................................................................... 4-7
URL Table and Parameters ........................................................ 4-11
Static URL Table ......................................................................... 4-14
Configuring Farms ...................................................................... 4-16
Configuring Dispatch Methods .................................................... 4-20
Configuring Content Based Rules .............................................. 4-21
Server Management .............................................................. 4-25
Servers Overview ....................................................................... 4-26
Physical Servers ......................................................................... 4-31
Server Load Balancing .......................................................... 4-36
Client Table Management ........................................................... 4-37
Content Servers Overview .......................................................... 4-39
Configuring Servers .................................................................... 4-42
Alias Port .................................................................................... 4-50
Sticky Clients Support ................................................................. 4-51
Server Health Check ................................................................... 4-52
Cache Load Balancing .......................................................... 4-53
What is Caching? ........................................................................ 4-54
How Does Cache Load Balancing Work? ................................... 4-56
CID Cache Load Balancing ........................................................ 4-57
CID User Guide V

Table of Contents
Client-Server Combinations ........................................................ 4-60

P2P/Kazaa Caching .................................................................... 4-67
Web Cache Coordination Protocol (WCCP) 2 ............................ 4-74
Enhanced Cache Coordination ................................................... 4-76
Local Triangulation ................................................................ 4-77
What is Local Triangulation? ...................................................... 4-78
Configuring CID with Local Triangulation ................................... 4-80
Server Spoofing .................................................................... 4-86
What is Server Spoofing? ........................................................... 4-87
Network Address Translation ................................................ 4-88
NAT Types .................................................................................. 4-89
Client NAT .................................................................................. 4-90
Server Based NAT ...................................................................... 4-94
Farm Based NAT ...................................................................... 4-106
Chapter 5 - Advanced Features ...................................... 5-1

Flow Management ................................................................... 5-2
What is Flow Management? ......................................................... 5-3
Where to Use Flow Management ................................................. 5-6
Configuring CID with Flow Management ...................................... 5-7
Content Load Balancing ........................................................ 5-19
URL Policies ............................................................................... 5-20
URL Policies with Mime-Type ..................................................... 5-21
URL Match .................................................................................. 5-22
HTTP Match ................................................................................ 5-23
MIME Type Support .................................................................... 5-25
Configuring CID with Anti-Virus Servers ..................................... 5-28
Special Protocol Treatment ................................................... 5-45
FTP Content Management ......................................................... 5-46
POP3 Support ............................................................................ 5-53
RADIUS Based Classification ..................................................... 5-58
HTTP Advanced Features .......................................................... 5-62
VI CID User Guide

Table of Contents
SSL Content Check .............................................................. 5-65

What is an SSL Content Check? ................................................ 5-66
Spoofed AV Gateway Configuration ........................................... 5-68
Proxy AV Gateway Configuration ............................................... 5-71
DNS and NTP Services ......................................................... 5-78
DNS Services ............................................................................. 5-79
Chapter 6 - Redundancy.................................................. 6-1

CID Redundancy ..................................................................... 6-2
Introducing CID Redundancy ........................................................ 6-3
Active / Backup Setup ................................................................... 6-5
Interface Grouping ........................................................................ 6-6
Mirroring ........................................................................................ 6-8
Proprietary ARP Redundancy ............................................... 6-10
Proprietary ARP .......................................................................... 6-11
Backup Fake ARP ...................................................................... 6-12
VRRP Redundancy ............................................................... 6-24
Introducing VRRP ....................................................................... 6-25
VRRP Redundancy Notes .......................................................... 6-30
Direct Server Connection with VRRP ......................................... 6-41
Chapter 7 - Health Monitoring......................................... 7-1

Introducing Health Monitoring ................................................. 7-2
Configuring Health Checks ..................................................... 7-5
Global Configuration ..................................................................... 7-6
Global Parameters Setup ............................................................. 7-7
Health Checks Database .............................................................. 7-9
Binding and Groups .................................................................... 7-16
Regular Health Check ................................................................. 7-19
Group Health Check ................................................................... 7-22
Farm Health Check ..................................................................... 7-23
Health Check Methods .......................................................... 7-25
CID User Guide VII

Table of Contents
Predefined Methods .................................................................... 7-26

User Defined Methods ................................................................ 7-39
Configuration Examples ........................................................ 7-44
Chapter 8 - Bandwidth Management .............................. 8-1

Introduction to Bandwidth Management ................................. 8-2
What is Bandwidth Management .................................................. 8-3
Bandwidth Management Policies ............................................ 8-7
What is Bandwidth Management Policy ....................................... 8-8
Bandwidth Management Classification Criteria ............................ 8-9
Bandwidth Management Rules ................................................... 8-12
Bandwidth Management Classes ......................................... 8-18
Services ...................................................................................... 8-19
Networks ..................................................................................... 8-25
Port Groups ................................................................................ 8-26
VLAN Tag Groups ...................................................................... 8-27
Protocol Discovery ................................................................ 8-33
What is Protocol Discovery ......................................................... 8-34
Protocol Discovery Policies ........................................................ 8-35
Interface Classification .......................................................... 8-37
Port Bandwidth ........................................................................... 8-38
Interface Classification ................................................................ 8-39
Chapter 9 - Security ......................................................... 9-1

Security Overview .................................................................. 9-2
Security Introduction ..................................................................... 9-3
Security Modules .......................................................................... 9-6
Setting Up Security Policies in the Connect and Protect Table .. 9-10
Enabling Protection and Setting Up General Security Parameters 9-12
Defining Connectivity .................................................................. 9-19
Suspend Table ........................................................................... 9-23
Managing the Signatures Database ...................................... 9-25
VIII CID User Guide

Table of Contents
Protection Profiles and Groups Supplied by Radware ................ 9-26

Security Signatures File Update ................................................. 9-36
Intrusions .............................................................................. 9-43
Introduction to Intrusions ............................................................ 9-44
Intrusion Prevention Profiles ....................................................... 9-46
Setting Up Intrusion Prevention Using Profiles and Groups ....... 9-47
Defining Intrusion Prevention with User-Defined Settings .......... 9-48
Setting Up Attacks and Filters .................................................... 9-49
Custom Attack Groups ................................................................ 9-64
Creating a New User-Defined Intrusion Prevention Profile ......... 9-66
DoS/DDoS ............................................................................ 9-72
Introducing DoS/DDoS ............................................................... 9-73
DoS/DDoS Protection Services .................................................. 9-74
Introduction to DoS Shield .......................................................... 9-75
Setting Up DoS Shield Using Radware Profiles ......................... 9-80
Defining DoS Shield with User-Defined Settings ........................ 9-81
Introduction to Application Security ............................................ 9-92
Setting Up Application Security for DoS/DDoS Using Profiles and Groups
9-93
Defining Application Security Profiles with User-Defined Settings 9-94
Behavioral DoS ................................................................... 9-106
Introduction to Behavioral DoS ................................................. 9-107
Behavioral DoS Global Parameters .......................................... 9-109
Behavioral DoS Advanced Settings .......................................... 9-112
Connection Limit ................................................................. 9-119
Creating Connection Limiting Policies ...................................... 9-120
SYN Flood Protection .......................................................... 9-123
Introduction to SYN Flood Protection ....................................... 9-124
Before Setting Up SYN Flood Protection .................................. 9-129
SYN Flood Protection General Settings ................................... 9-130
Creating Custom SYN Attacks .................................................. 9-134
Configuring SYN Flood Protection Policies .............................. 9-136
SYN Flood Reporting ................................................................ 9-140
CID User Guide IX

Table of Contents
Protocol Anomalies ............................................................. 9-142

Anomalies Introduction ............................................................. 9-143
Setting Up the Anomalies Module Using Predefined Profiles ... 9-144
Defining Anomalies with User-Defined Settings ....................... 9-145
Anti-Scanning ...................................................................... 9-156
Introduction to Anti-Scanning .................................................... 9-157
Setting Up Anti-Scanning Using Profiles and Groups ............... 9-158
Defining Anti-Scanning with User-Defined Settings .................. 9-159
Session Table ..................................................................... 9-171
What is the Session Table ........................................................ 9-172
Session Table Lookup Mode .................................................... 9-173
Configuring the Session Table .................................................. 9-174
Evasion Techniques ............................................................ 9-176
Introduction to Evasion Techniques .......................................... 9-177
IP Reassembly and Min IP Fragmentation ............................... 9-178
TCP Reassembly ...................................................................... 9-182
Security Events and Reports ............................................... 9-184
Events and Event Reporting ..................................................... 9-185
Reporting Channels .................................................................. 9-190
Security Reports ....................................................................... 9-197
Chapter 10 - Application Switching Platforms ............ 10-1

Introduction to Intelligent Application Switches ..................... 10-2
Application Switch 1 .................................................................... 10-3
Physical Description ............................................................ 10-11
Application Switches Physical Description ............................... 10-12
Device Installation ............................................................... 10-26
Checking the Contents ............................................................. 10-27
X CID User Guide

Table of Contents
Mounting the Device ................................................................. 10-28

Connecting the Device to Your Network ................................... 10-29
Device Interfaces ................................................................ 10-31
Interfaces - Introduction ............................................................ 10-32
Specifications ...................................................................... 10-37
Specification Table ................................................................... 10-38
Gigabit Ethernet Specifications ................................................. 10-42
Serial Cable Pin Assignment ............................................... 10-44
Trouble Shooting. ................................................................ 10-46
Chapter A - Troubleshooting .......................................... A-1

Troubleshooting Topics .......................................................... A-2
CID Limitations ....................................................................... A-5
Chapter B - Loopback Interfaces.................................... B-1

AIX ......................................................................................... B-4
HP-UX .................................................................................... B-5
Linux ...................................................................................... B-6
Solaris .................................................................................... B-8
Windows NT ........................................................................... B-9
Chapter C - Regular Expressions ................................... C-1
Chapter D - Glossary ....................................................... D-1

Commonly Used Terms ......................................................... D-2
List of Abbreviations ............................................................... D-6
Index...................................................................................... 1
CID User Guide XI

Table of Contents
XII CID User Guide

Table of Figures
Table of Figures
Figure 1-1 CID Content Load Balancing .............................................. 1-6
Figure 1-2 Flow Management ............................................................. 1-9
Figure 1-3 RADIUS Based Classification........................................... 1-12
Figure 2-1 FTP Proxy Content Management Configuration............... 2-55
Figure 3-1 Transparent CIDs in VLAN ............................................... 3-12
Figure 3-2 VLAN Tagging Example ................................................... 3-19
Figure 4-1 Farm Policy Components ................................................... 4-3
Figure 4-2 URL Table Based Server Direction Configuration ............ 4-12
Figure 4-3 Client Table Configuration ................................................ 4-38
Figure 4-4 CID with Transparent Content Servers............................. 4-45
Figure 4-5 Caching Example.............................................................. 4-54
Figure 4-6 Proxy and Non-Proxy GET Request................................. 4-59
Figure 4-7 CID with Transparent Servers in VLAN Environment ....... 4-61
Figure 4-8 P2P/Kazaa Caching.......................................................... 4-69
Figure 4-9 Local Triangulation Network Setup................................... 4-78
Figure 4-10 Local Triangulation with Returned Cache Pages............ 4-81
Figure 4-11 CID NAT Operation......................................................... 4-91
Figure 4-12 Server Based NAT Configuration ................................... 4-95
Figure 4-13 NAT to Remote Servers................................................ 4-101
Figure 4-14 Farm Based NAT Configuration.................................... 4-106
Figure 5-1 Clients from Networks A & B .............................................. 5-3
Figure 5-2 Network A Client Redirection.............................................. 5-4
CID User Guide XIII

Table of Figures
Figure 5-3 Network B Client Redirection.............................................. 5-5

Figure 5-4 Flow Management .............................................................. 5-6
Figure 5-5 Cache Farm and URL Filter Farm in Spoofed Mode .......... 5-8
Figure 5-6 Cache Farm and URL Filter Farm in Non-Spoofed Mode 5-14
Figure 5-7 Single Interface Servers with MIME Type Support ........... 5-29
Figure 5-8 Dual Interface Gateway Servers with MIME Type Support 5-34
Figure 5-9 Single Interface Proxy Servers with MIME Type Support. 5-40
Figure 5-10 FTP Proxy Content Management Configuration............. 5-47
Figure 5-11 POP3 Interception Configuration .................................... 5-54
Figure 5-12 RADIUS Configuration.................................................... 5-59
Figure 5-13 SSL Content Check General Scheme ............................ 5-66
Figure 5-14 Traffic Flow in Spoofed AV Gateway .............................. 5-68
Figure 5-15 HTTPS Traffic Flow in Proxy AV Gateway ..................... 5-71
Figure 5-16 HTTP Traffic Flow in Proxy AV Gateway........................ 5-72
Figure 6-1 CID Redundancy Scheme .................................................. 6-4
Figure 6-2 Proprietary Redundancy with Routing .............................. 6-14
Figure 6-3 Proprietary Redundancy with Bridging ............................. 6-17
Figure 6-4 Proprietary Parallel Redundancy with Routing ................. 6-20
Figure 6-5 Redundant CID Configuration with VRRP ........................ 6-31
Figure 6-6 Parallel Redundant CIDs with VRRP................................ 6-35
Figure 6-7 Direct Server Connection with VRRP and Routing........... 6-42
Figure 6-8 Direct Server Connection with VRRP and Bridging .......... 6-44
Figure 6-9 Redundant CIDs with VRRP and Direct Connection ........ 6-47
Figure 7-1 Health Monitoring of Multiple Logical Servers .................. 7-45
Figure 7-2 Group Health Check ......................................................... 7-49
Figure 9-1 Connect and Protect Table ............................................... 9-10
Figure 9-2 Security Settings Window ................................................. 9-12
XIV CID User Guide

Table of Figures
Figure 9-3 Custom Attack Configuration ............................................ 9-49

Figure 9-4 Filter Configuration Window.............................................. 9-50
Figure 9-5 Attack Group Configuration Window................................. 9-64
Figure 9-6 DoS Shield Traffic Flow Diagram...................................... 9-77
Figure 9-7 Filter Configuration ........................................................... 9-82
Figure 9-8 Attack Group Configuration Window............................... 9-103
Figure 9-9 Delayed Binding Process................................................ 9-125
Figure 9-10 SYN Protection Policies............................................... 9-133
Figure 9-11 SYN Attack Configuration Window ............................... 9-134
Figure 9-12 Attack Group Configuration Window............................. 9-153
Figure 9-13 Attack Group Configuration Window............................. 9-168
Figure 10-1 Application Switch 1........................................................ 10-3
Figure 10-6 Application Switch 1 - Front Panel View ...................... 10-13
Figure 10-7 Application Switch 2 - Front Panel............................... 10-16
Figure 10-8 Application Switch 3 - Front Panel View ....................... 10-19
Figure 10-9 Application Switch 4 Front Panel View ........................ 10-22
Figure 10-10 Application Switch 5 Front Panel View ....................... 10-24
Figure B-1 Loopback Interface Example............................................. B-2
CID User Guide XV

Table of Figures
XVI CID User Guide

Before You Begin
Important Notice
This guide is delivered subject to the following conditions and restrictions:
Copyright Radware Ltd. 2006 All rights reserved.
The copyright and all other intellectual property rights and trade secrets
included in this guide are owned by Radware Ltd.
The guide is provided to Radware customers for the sole purpose of obtaining
information with respect to the installation and use of the Content Inspection
Director (CID), and may not be used for any other purpose.
The information contained in this guide is proprietary to Radware and must be
kept in strict confidence.
It is strictly forbidden to copy, duplicate, reproduce or disclose this guide or any
part thereof without the prior written consent of Radware.
CID User Guide I

Before You Begin
Safety Instructions
CAUTION
Due to the risks of electrical shock, and energy, mechanical, and fire hazards,
any procedures that involve opening panels or changing components must be
performed by qualified service personnel only.
To reduce the risk of fire and electrical shock, disconnect the device from the
power line before removing cover or panels.
SERVICING
Do not perform any servicing other than that contained in the operating
instructions unless you are qualified to do so. There are no serviceable parts
inside the unit.
HIGH VOLTAGE
Any adjustment, maintenance, and repair of the opened instrument under
voltage should be avoided as much as possible and, when inevitable, should
be carried out only by a skilled person who is aware of the hazard involved.
Capacitors inside the instrument may still be charged even if the instrument
has been disconnected from its source of supply.
GROUNDING
Before connecting this device to the power line, the protective earth terminals
of this device must be connected to the protective conductor of the (mains)
power cord. The mains plug shall only be inserted in a socket outlet provided
with a protective earth contact.
Do not use an extension cord (power cable) without a protective conductor
(grounding).
II CID User Guide

Before You Begin
FUSES
Ensure that only fuses with the required rated current and of the specified type
are used for replacement. The use of repaired fuses and the short-circuiting of
fuse holders must be avoided. Whenever it is likely that the protection offered
by fuses has been impaired, the instrument must be made inoperative and be
secured against any unintended operation.
LINE VOLTAGE
Before connecting this instrument to the power line, ensure the voltage of the
power source matches the requirements of the instrument. Refer to the
Specifications for information about the correct power rating for the device.
TRADEMARKS
CID and Configware are trade names of Radware Ltd. This document contains
trademarks registered by their respective companies.
SPECIFICATION CHANGES
Note: Specifications are subject to change without notice.
Note: This equipment has been tested and found to comply with the limits for a
Class A digital device pursuant to Part 15 of the FCC Rules and EN55022
Class A, EN 50082-1 For CE MARK Compliance. These limits are designed to
provide reasonable protection against harmful interference when the
equipment is operated in a commercial environment. This equipment
generates, uses and can radiate radio frequency energy and, if not installed
and used in accordance with the instruction manual, may cause harmful
interference to radio communications. Operation of this equipment in a
residential area is likely to cause harmful interference in which case the user
will be required to correct the interference at his own expense.
CID User Guide III

Before You Begin
CID
If you purchased this device, make note of the following additional instructions.
RESTRICT AREA ACCESS

The DC powered equipment should only be installed in a Restricted Access
Area.
INSTALLATION CODES
This device must be installed according to country national electrical codes. For
North America, equipment must be installed in accordance to the US National
Electrical Code, Articles 110-16, 110-17, and 110-18 and the Canadian
Electrical Code, Section 12.
OVERCURRENT PROTECTION
A readily accessible listed branch-circuit over current protective device rated 15
A must be incorporated in the building wiring.
DC POWER CONNECTION
1. The equipment shall be connected directly to the DC Supply System
earthing electric conductor.
2. All equipment in the immediate vicinity shall be earthed in the same way,
and shall not be earthed elsewhere.The DC supply system is to be local, for
example within the same premises as the equipment.
3. There shall be no disconnect device between the earthed circuit conductor
of the DC source (return) and the point of connection of the earthing
electrode conductor
IV CID User Guide

Before You Begin
)Caution - To Reduce the Risk of Electrical Shock and Fire

1. This equipment is designed to permit connection between the earthed
conductor of the DC supply circuit and the earthing conductor equipment.
See Installation Instructions.
2. All servicing should be undertaken only by qualified service personnel.
There are not user serviceable parts inside the unit.
3. DO NOT plug in, turn on or attempt to operate an obviously damaged unit.
4. Ensure that the chassis ventilation openings in the unit are NOT
BLOCKED.
5. Replace a blown fuse ONLY with the same type and rating as is marked on
the safety label adjacent to the power inlet, housing the fuse.
6. Do not operate the device in a location where the maximum ambient
temperature exceeds 400 C / 1040 F.
7. Be sure to unplug the power supply cord from the wall socket BEFORE
attempting to remove and/or check the main power fuse.
)Attention: Pour Reduire Les Risques d'Electrocution et d'Incendie

1. Toutes les opérations d'entretien seront effectuées UNIQUEMENT par du
personnel d'entretien qualifié. Aucun composant ne peut être entretenu ou
remplacé par l'utilisateur.
2. NE PAS connecter, mettre sous tension ou essayer d'utiliser unensemble
qui est défectueux de manière évidente.
3. Assurez vous que les ouvertures de ventilation du châssis NE SONT PAS
OBSTRUEES.
4. Remplacez un fusible qui a sauté, SEULEMENT par un fusible du même
type et de même capacité, comme indiqué sur l'étiquette de sécurité
proche de l'entrée de l'alimentation qui contient le fusible.
5. NE PAS UTILISER l'équipement dans des locaux dont la température
maximale dépasse 40°C.
6. Assurez vous que le cordon d'alimentation a été déconnecté AVANT
d'essayer de l'enlever et / ou vérifier le fusible de l'alimentation générale.
CID User Guide V

Before You Begin
)Manahmen zum Schutz vor elektrischem Schock und Feuer

1. Alle Wartungsarbeiten sollten ausschlielich von geschultem
Wartungspersonal durchgefuhrt werden. Keine im Gert befindlichen Teile
durfen vom Benutzer gewartet werden.
2. Offensichtlich defekte oder beschdigte Gerte durfen nicht angeschlossen,
eingeschaltet oder in Betrieb genommen werden.
3. Stellen Sie sicher, dass die Beluftungsschlitze am Gert nicht blockiert sind.
4. Ersetzen Sie eine defekte Sicherung ausschlielich mit Sicherungen laut
Sicherheitsbeschriftung.
5. Betreiben Sie das Gert nicht in Rumen mit Temperaturen uber 40C.
6. Trennen Sie das Netzkabel von der Steckdose bevor Sie die
Hauptsicherung prufen oder austauschen.
VI CID User Guide

Before You Begin
About This Guide

• Chapter 1 - Introduction & Overview
This chapter presents an introduction and a general overview of the main
features of CID (Content Inspection Director).
• Chapter 2 - Device Management
This chapter explains the CID management and maintenance processes,
including the management interfaces and methods by which CID devices
are accessed, configured and operated.
• Chapter 3 - Basic Switching and Routing
This chapter provides theoretical explanations about switching and routing
in general, describes how CID participates in the processes of switching
and routing, and presents several aspects of the practical implementation
of CID.
• Chapter 4 - Basic Application Switching
This chapter describes the farm and server management concepts and the
related features. This chapter also provides examples of common
configurations of application switching and load balancing schemes as
implemented in Content Inspection Director (CID).
• Chapter 5 - Advanced Features
This chapter presents additional advanced features of the CID devices.
• Chapter 6 - Redundancy
This chapter introduces the redundancy concept and guides you through
the related features. It also provides common examples of the various CID
redundancy configurations.
• Chapter 7 - Health Monitoring
This chapter provides the Health Monitoring module included in the
Radware SynApps architecture
• Chapter 8 - Bandwidth Management
This chapter presents the capabilities of the CID Bandwidth Management
module.
CID User Guide VII

Before You Begin
• Chapter 9 - Security
This chapter provides a general overview of the APSolute Insite Security
modules and the sub modules within as well as an explanation of the
signatures data base and Radware Security update service (SUS). Also
provided in this chapter is an explanation of the tuning process.
• Chapter 10 - Application Switching Platforms
This chapter provides an explanation of Radwares Application Swithching
Platforms, Device Interfaces, list of specifications, Serial Cable Pin
Assignment and a trouble shooting section
• Appendix A - Troubleshooting
This appendix provides troubleshooting solutions to some common CID
problems, and describes known CID limitations.
• Appendix B - Loopback Interfaces
This appendix describes the loopback alias setup for CID, according to the
operating system. Procedures are included for AIX, HP-UX, UNIX, Linux,
Solaris and Windows NT.
• Appendix C - Regular Expressions
This appendix provides an overview of the basic syntax of regular
expressions used in CID modules.
• Appendix D - Glossary and Abbreviations
The glossary provides explanations of common terms and concepts used in
network configurations.
• Index
VIII CID User Guide

Before You Begin
Document Conventions
This guide uses the following documentation conventions:
• Command paths in the GUI are presented as: File > Save As.
• Windows systems use a two-button mouse. To drag and drop an object,
click and hold the left mouse button on the object, drag the object to the
target location, then release the button.
• Screen displays can differ slightly from those included in this guide,
depending on the system you use. For example, Microsoft Windows
screens are different from X-Windows screens.
• Various icons are used through the document to indicate the following:
Note: Important information that requires additional attention.
Tip: A recommendation, or an optimum way to perform an

action.
Configuration Guidelines: General description of the con-

figuration process.
To Statement: Detailed operating instructions that explain

the step by step configuration process.
Example: An example configuration of an actual scenario.
CID User Guide IX

Before You Begin
X CID User Guide

CHAPTER 1
Chapter 1 - Introduction & Overview
Chapter 1, Introduction & Overview, presents an introduction and a
general overview of the main features of CID.
This chapter contains the following sections:
• Introduction, page 1-2
• CID Overview, page 1-5
CID User Guide 1-1

Introduction
Section 1-1 Introduction

Section 1-1 Introduction describes the purpose, main functions and
benefits of CID and discusses CIDs‘ role on your network.
This section includes the following topics:
• Introducing CID, page 1-3
1-2 CID User Guide

Introducing CID
Radware’s Content Inspection Director (CID) is a smart Internet Traffic
Management (ITM) device that utilizes routing capabilities. The CID
transparently intercepts Internet-bound user traffic and intelligently load
balances the applicable traffic among the content servers.
CID is designed to fulfill the needs of large organizations that require
100% content inspection in conjunction with redundant high-speed
connectivity, but without performance degradation or downtime. To
prevent bottlenecks and single points-of-failure in the gateway content
inspection solution, CID uses load balancing mechanisms to manage
servers and server farms.
Distributing the inspection load across several content inspection
resources, greatly improves network performance and ensures Internet
connectivity uptime.
Separating the different protocols and file types into several content
inspection devices also speeds up the traffic. Features such as
ongoing health checks and transparent fail-over support, ensure that
the content inspection server is not a single point-of-failure and that its
resources are always optimized.
Using CID on your network you can achieve these benefits:
• Speed: Up to 500% increase in content inspection speed.
• Capacity: Increased capacity and volume of inspected traffic
through the aggregation of content inspection servers into farms.
• Secure Web Access: Secure web access with low latency while
maintaining the best content security possible. Web page content is
analyzed in real-time to prevent any malicious content or scripts
from entering the network. Areas that were traditionally considered
bottlenecks, are eliminated.
• Content Security: Improved content inspection speed and
elimination of malicious traffic is ensured by the distribution of
content based on IP protocols such as HTTP, FTP, SMTP and on
traffic file type.
• Scalability: Scalable architecture with Gigabit connectivity
accommodates the needs of high capacity networks. As the need
arises, additional content inspection servers can be added to the
existing content inspection architecture.
CID User Guide 1-3

Introduction
• Availability: Health monitoring and traffic redirection provide high

availability. If one of the Content Inspection devices fails, CID
reroutes the traffic to another device.
• Interoperability: CID offers full compatibility with all types of
content inspection servers and anti-virus gateways.
• Sequential load balancing: Flow management enables
sequential load balancing of several server farms, each providing a
different service. Specific content inspection policies can be
assigned based on source, destination and traffic type.
Load Balancing
CID includes several advanced load-balancing algorithms that
intelligently distribute traffic between Content Inspection devices.
Several flexible load-balancing algorithms are used for each server
farm. CID Provides the flexibility to utilize any set of these load
balancing techniques for each cluster of Content Inspection devices in
order to optimize traffic flow through the network.
CID allows you to set up heterogeneous server farms, that is farms that
utilize servers of varying performance and load capabilities. CID
intelligently redirects traffic among servers in a farm, based on each
server’s specific performance capabilities. This allows for additional
flexibility when expanding or reducing resources within a farm.
CID Role in the Network

CID is installed in the path of a user community to the Internet. The
device must also be installed so that traffic between the anti-virus
servers and the users flows through the CID. CID can be installed into
a network as a bridge or as a router. When installed as a router, CID
supports these protocols: RIP, RIPII, OSPF, and VRRP.
1-4 CID User Guide

Section 1-2 CID Overview

Section 1-2 CID Overview discusses the system architecture and
specifications of the CID. This section includes the following topics:
• Content Management Load Balancing, page 1-6
• Flow Management, page 1-9
• Special Protocol Treatment, page 1-11
• Technical Description, page 1-15
CID User Guide 1-5

CID Overview
Content Management Load Balancing

CID is designed to perform load balancing on content inspection
servers, such as cache servers, anti-virus servers, URL filters and so
on. User traffic is distributed among content servers that can be
heterogeneous.
CID transparently intercepts Internet-bound user traffic and intelligently
load balances the traffic between the content servers that operate
transparently or non-transparently. As a result, users do not have to
have any browser configuration, pointing them to a proxy server.
In addition, CID also provides a Virtual IP address for the content
farms, so as to facilitate users who need to operate non-transparently.
Figure 1-1 illustrates the Content Load Balancing concept.
Server Farm Farm
1 4 3 2
Clients CID Router Internet
Figure 1-1 CID Content Load Balancing
1-6 CID User Guide

Properties:
• CID performs Load Balancing by selecting a server and then
redirecting the client request to the server which maintains client
server persistency.
• The selected server sends the clients request to the Internet which
maintains server site persistency.
• CID receives the reply from the Internet, and sends it to the
relevant server which maintains server site persistency.
• The server returns the reply to the client which maintains client
server persistency.
Server Types
CID supports the following server types:
• Gateway: Server that uses two interfaces.
• Transparent Server: Server that serves the clients transparently,
that is without changing the client’s request.
• Regular Server: Non-transparent server or proxy server.
• Cache Server: Cache server is a proxy server that stores-and-
forwards Web pages.
• Content Server: Other servers, such as anti-virus servers, URL
filtering servers and others which have the ability to check the
content up to Layer 7, search for a specific content and block it
(forbidden URLs, viruses and others).
Cache Load Balancing

In some environments, the use of cache servers, also called “proxy
cache” or “proxy” servers, can significantly improve network
performance, and at the same time it reduces the use of bandwidth and
additional content servers.
The CID optimizes the use of cache servers through intelligent load
balancing and transparent traffic interception. When a user makes a
request to the Internet, CID checks for the content available on each
cache to maximize cache-hit ratio, cache-hit ratio indicates the
efficiency of the cache, the higher the hit ratio, the more requests the
CID User Guide 1-7

CID Overview
cache serves by itself, which results in an improvement in user

response time and saves network bandwidth. By transparently
intercepting traffic, CID can optimize cache use without burdening the
network administration with the requirement for configuring user
browsers.This ability also allows for improved network performance
and cache server optimization.
Spoofing
Server Spoofing is a process of one device talking to another device
using the address of a third device. CID uses the Server Spoofing
capability to enable cache servers to retrieve pages on behalf of the
client with the client's source address.
1-8 CID User Guide

Flow Management
CID Flow Management feature leverages the Farm Management
capability by sequentially load balancing several server farms, each
providing a different service. Traffic flow is designed for packets that
arrive from the client, are examined by CID, load balanced within a
farm, returned from the selected server to CID, examined again and
load balanced within a different farm, and so on.
The farm selection decision is based on the source IP and on the MAC
address. This way CID can distinguish between clients and servers,
even if the servers use spoofing.
Initially, farms and servers are configured then the policies handling the
different traffic classifications for this farm are defined. Adding farms to
a farm cluster element adds control to the distribution of traffic, by
matching the various polices to the correct farms, including sending the
traffic through multiple farms when a traffic condition meets those
predefined polices.
The example in Figure 1-2 illustrates the flow management concept.
Users CID Access Router Internet
1 8
2 3 4 5 6 7
URL Filter Cache Server Anti Virus Gateway
Figure 1-2 Flow Management
CID User Guide 1-9

CID Overview
Properties:
1. The Client sends a request to the Internet. The request packet is
intercepted by the CID.
2. CID redirects the packet to the URL farm which checks the
packet’s content.
3. The URL server returns the packet to the CID.
4. CID then sends the packet to the Cache server which checks the
content.
5. The Cache server returns the packet to the CID.
6. CID sends the packet to the Anti-Virus server which checks the
packet’s content.
7. The Anti-Virus server returns the packet back to the CID.
8. CID then sends the packet to the Internet through the Access
Router.
1-10 CID User Guide

Special Protocol Treatment

Special protocol treatments implemented in CID include the following
IP protocols:
• RADIUS
• POP3
• FTP
• HTTP
RADIUS Classification
The RADIUS service allows authenticating and storing of the account
information for network users. CID employs a special feature for the
RADIUS support, RADIUS Based Classification.
With RADIUS Based Classification, CID can provide service to clients,
based on a configured RADIUS profile. The RADIUS profile identifies
the user and allows CID to apply farm policies or cluster flow policies
according to the attributes that are defined in the RADIUS Policy Table.
This capability enables service providers and large networks to identify
dial-up and NATed users by authentication tokens and not by source IP
address. CID monitors the traffic and checks the RADIUS messages
for user privileges. According to this information, CID assigns clients to
networks that are added to the Network Table. The networks can then
be used when defining farm policies, flow clusters, BWM policies and
so on.
CID releases a client from the network table when the NAS (Network
Access Server) sends a RADIUS stop accounting message, or when
the IP address is assigned to a new user.
CID works with RADIUS in the following modes:
• Transparent Mode
In Transparent Mode, CID can be installed between the NAS and
the RADIUS server.
• Proxy Mode
In Proxy Mode, CID can be installed as RADIUS proxy.
CID User Guide 1-11

CID Overview
Figure 1-3 illustrates the configuration used in RADIUS based

classification.
Farm1 Farm2
Clients NAS CID Router Internet
RADIUS Server
Figure 1-3 RADIUS Based Classification
Properties:
RADIUS based classification involves the following stages:
1. When the client initiates a dial-up session, the call (whether a
phone or a broadband call) is terminated by the NAS (Network
Access Server), which sends the client username and password to
the RADIUS Server.
1-12 CID User Guide

2. The RADIUS server replies with the allocated client IP address

and with the user attribute value. CID intercepts the RADIUS
handshake traffic, and adds the client to the Network Table using
its allocated IP address.
3. NAS completes the client dial-up session by assigning the client
IP address and establishing the PPP link x.
POP3
CID supports interception and redirection of POP3 traffic destined to a
POP3 proxy server. POP3 sessions are transparently intercepted and
redirected to the servers. The sessions are intercepted and sent to the
IP address of the server, to open a POP3 session with the proxy agent
of the server. The client is unaware of the POP3 proxy server's
existence, and supposes that it is directly connected to the POP3 host
on the Internet. To provide POP3 support, CID transforms the client's
command
from: USER(user name)
to: USER(user_name#destination_IP)
This transformation allows the POP3 proxy to extract the destination
POP3 host and then to open the POP3 session to that host, on behalf
of the client. This is done transparently to the client or in the destination
IP address that is taken from Layer 3 information of the client request.
FTP
When deploying an FTP proxy server for FTP caching or FTP content
inspection, CID provides special treatment for these servers. CID
intercepts FTP sessions of non-configured client and load balances it
to the FTP proxy server farm. CID transforms the client’s command
from: username:password
to: username:password@destination_IP
This transformation allows the FTP proxy server to extract the original
destination FTP host and then to open the FTP session to that host, on
behalf of the client. This is process is transparent for the client.\
CID User Guide 1-13

CID Overview
HTTP
When deploying non- transparent cache server (Proxy server), CID can
transform a regular HTTP request into a Proxy format
from: GET HTTP/1.1
to: GET HTTP://HOST/HTTP/1.0
where the host used is the host of the original request.
1-14 CID User Guide

Technical Description
CID software is managed by a network interface and can run on one of
the following platforms:
• Application Switch 1
Network Management
CID can be managed through the following network interfaces:
• APSolute Insite (SNMP based GUI)
• Secure Web based management
• SSH II
• Telnet
• HP OpenView for Sun Solaris
• Command Line Interface
Note: For the detailed CID platform technical specifications and
physical specifications, please refer to the CID data sheet, through the
Radware Web site: http://www.radware.com/content/products/cid/
techspec
CID User Guide 1-15

CID Overview
1-16 CID User Guide

CHAPTER 2
Chapter 2 - Device Management
Chapter 2, Device Management, explains the CID management and
maintenance processes, as well as explaining the management
interfaces and methods by which CID devices are accessed,
configured and operated.
The maintenance procedures presented here include information about
upgrading and tuning of CID devices. In addition, this chapter contains
explanations about the process of system notifications regarding
possible system failures.
This chapter includes the following sections:
• Section 2-1: Configuring Device IP Host Parameters for the First
Time, page 2-2
• Section 2-2: Version Management and Device Upgrading, page 2-
10
• Section 2-3: Device Configuration Options, page 2-25
• Section 2-4: Device Access, page 2-30
• Section 2-5: Device Tuning, page 2-72
• Section 2-6: Device Services, page 2-75
• Section 2-7: Device Reporting, page 2-84
CID User Guide 2-1

Configuring Device IP Host Parameters for the First Time
Section 2-1 Configuring Device IP Host

Parameters for the First Time
Section 2-1 Configuring Device IP Host Parameters for the First Time
explains how you can establish connection with the device as well as
how to erase the configuration file.
• Device IP Host Parameters Introduction, page 2-3
• Erasing the Configuration file, page 2-8
• Resetting the Device, page 2-9
2-2 CID User Guide

Device IP Host Parameters Introduction

The Device IP host parameters enables the user to establish
communication with the device via:
• Secure WBM
• Web Based Management
• SNMP (Simple Network Management Protocol) v1, 2C, 3.
• Telnet
• SSH Client
To manually configure the Devices IP host parameters for the

first time:
1. Connect the serial console to the device as follows:
a. Open a terminal emulation program with the following
parameters:
Bits per second: 19200
Data bits: 8
Parity: None
Stop bits: 1
Flow Control: None
2. Ensure that the ASCII terminal is running on the Nms.
3. Turn on the power to the device. After the Boot process is complete
the following start-up menu appears: Select the @ symbol to
access the Startup Configuration window as shown below in Table
2-1..
Table 2-1 Startup Configuration
# Description Enable
0 IP Address
1 IP subnet mask
2 Port number
CID User Guide 2-3

Table 2-1 Startup Configuration
3 Default router IP address
4 RIP version (0,1,2) [0]
5 Enable OSPF (y/n) [n]
6 OSPF area ID
7 User Name
8 User Password
9 Enable Web Access (y/n) [y]
10 Enable Secure Web Access (y/n) [y]
11 Enable Telnet Access (y/n) [y]
12 Enable SSH Access (y/n) [y]
13 SNMP Configuration
Table 2-2 SNMP Startup Configuration
0 Supported SNMP versions [1 2 3]
1 Community [Public]
2 SNMP Root User radware
3 Privacy Protocol (NONE/DES)

[DES]
4 Privacy Password radware
5 Authentication Protocol (NONE/SHA/

MD50 [MD5]
2-4 CID User Guide

Table 2-2 SNMP Startup Configuration
6 Authentication Password radware
7 NMS IP Address 0.0.0.0
8 Configuration File Name
4. Enter the number of the parameter for which you require to define
the information.
5. Enter the parameters configuration and click Enter. The value of
the parameter is displayed in the screen.
If you do not require to access this command line, the Startup
Configuration window is automatically displayed.
Note: This startup configuration window appears only when the
device has no previous configuration.
Startup Configuration Parameter List

The following list defines the parameters in the Startup
Configuration window:
• IP Address: The IP address of the interface is the only
mandatory parameter. This address is used to access the
device.
• IP Subnet Mask: The IP subnet mask address of the device.
The default value of this parameter is the mask of the IP
address class.
• Port Number: Device port number to which the IP interface is
defined. The default value is 1.
• Default Router IP Address: The IP Address of the router
through which the NMS can be reached. The default value for
this parameter is 0.0.0.0, which means that no default router is
configured.
• RIP Version: The RIP version used by the network router. The
default value for this parameter is: disable.
CID User Guide 2-5

• OSPF Enable: This parameter enables or disables the OSPF

protocol. The default value is: disable.
• OSPF Area ID: When the OSPF protocol is enabled, you can
enter an area ID other than the default value. Enter an ID in the
form of an IP address. The default value is 0.0.0.0.
• User Name: A user name which is added to the Users Table.
The default user name is radware.
• User Password: The password used to access the device
remotely using WBM, Telnet or SSH. The default password is
radware.
• Web Access: Indicates whether Web access to the device is
enabled. The default is: No.
• Secure Web Access: Indicates whether Secure Web access
to the device is enabled. The default is: No
• Telnet Access: Indicates whether Telnet access to the device
is enabled. The default is No.
• SSH Access: Indicates whether Web access to the device is
enabled. The default is No
• SNMP Configuration: Enters the SNMP Configuration sub
menu.
SNMP Startup Configuration Parameter List

The following list defines the SNMP Startup Configuration:
• Supported SNMP Versions: Indicates which versions of the
SNMP protocol are supported by the device. Default value 1&2&3.
possible values: 1 or 2 or 3 or 1,2 or 1,3 or 2,3
• Community Name: Device Community name. Enter the selected
community name. The default community name is public.
• SNMP Root User: Defined the use for SNMPv3. default value is
"radware"
• Privacy Protocol: Indicates whether to enable privacy or disable.
Possible values: NONE or DES. Default value "NONE" .
• Privacy Password: Defines the password for the SNMPv3 User.
Default – no password.
2-6 CID User Guide

• Authentication Protocol: Defines whether to use authentication

and the authentication protocol. Must be use in conjunction with
privacy. Default value – "None". Possible values "NONE" / "SHA" /
"MD5.
• Authentication Password: Defines the password for the SNMPv3
authentication. Default – no password.
• NMS IP address: The required NMS IP address. Enter a value if
you require to limit the device to a single specified NMS. The
default value is 0.0.0.0 (any NMS).
• Configuration file Name: The name of the file, in a format
required by the server, which contains the configuration. Select this
parameter when you require to download a configuration file as
NMS. The file must be located on the NMS, and the NMS must be
located on a TFTP server. When you exit the Startup Configuration
window, the device loads the configuration file from the NMS,
resets and starts operating with the new configuration. The default
value is: no name.
Notes:
• The device enters a default value for the parameters that are
incomplete, with the exception of the IP Address, which is
mandatory. A validity check of all the parameters is then performed.
• An initial default configuration is provided. When a device boots up
for the first time, if the Start-Up is not used for 30 seconds, and a
bootp server is not found within another 30 seconds, default
settings are assigned to the device. The initial default configuration
consists of a private IP Address (192.168.1.1), a subnet mask
(255.255.255.0) port 1, an NMS IP Address (0.0.0.0, allowing any
station to manage the device using SNMP), community string of
public, Telnet, SSH, SSL and WBM are enabled with a default user
of radware with password radware.
CID User Guide 2-7

Erasing the Configuration file

You may require to erase the configuration in order to restore the
factory default.
To erase the configuration file:

1. Reboot the device and hit any key to stop the auto-boot process.
CPU: RadWare BOOMER - MPC740/750
DRAM size: 128M
Flash size: 16M
BSP version: 5.33
Creation date: Jan 30 2005, 12:49:26
Press any key to stop auto-boot...
2. In order the erase the configuration file, press "q0" and press
enter and then "q1".
3. Press "@" to reboot the device.
2-8 CID User Guide

Resetting the Device

You may reset the device at any given time.
To reset the device via APSolute Insite:

1. From the main window, click Device.
2. From the Device dropdown menu, select Reboot.
3. Select the device you wish to reboot, then click Ok.
To reset the device via the Reset butto from the Device:
1. Press the reset button located on the front panel of the device.
CID User Guide 2-9

Version Management and Device Upgrading
Section 2-2 Version Management and Device

Upgrading
Section 2-2 Version Management and Device Upgrading describes the
interfaces and methods for upgrading the CID device.
• Introducing Upgrades, page 2-11
• Software Version Update, page 2-13
• Saving and Restoring Configuration Files, page 2-18
• Upgrading Licenses, page 2-20
• Upgrading Boot Versions, page 2-24
2-10 CID User Guide

Introducing Upgrades
You can upgrade all Radware devices to newer versions with a
straightforward FLASH process. Depending on the maintenance
contract, you may be eligible for new versions with new features or only
for the maintenance versions.
Performing the CID device upgrade involves two steps:
1. Save the current device configuration.
2. Upgrade the device software.
Radware releases the updated versions of CID software that can be
uploaded to your device.
You can upgrade a device using one of the following methods:
• APSolute Insite
• Web Based Management
A Device Upgrade enables the new features and functions on the
device without altering the existing configuration. In exceptional
circumstances, new firmware versions are incompatible with legacy
configuration files from earlier firmware versions. This most often
occurs when users attempt to upgrade from very old firmware to the
most recently available version.
New major firmware versions require a password. This password can
be obtained from the Radware corporate Web Site. You must obtain
this password before you load the upgrade file onto the Radware
device. If you do not supply the correct password during the upgrade
process, you cannot proceed. In case of a maintenance-only upgrade,
the password is not required.
The password is based on the firmware version file and on the Base
Mac Address of the CID unit.
CID User Guide 2-11

Notes:
• Before upgrading to a newer software version, it is recommended
to save the existing configuration file.
• Before performing the upgrade process refer to the “Upgrading
Notes” from MRN and RN.
• When using mirroring, it is recommended to use the same CID
software version for the main and for the backup devices. It is
recommended to disable Mirroring on both the active device and
the backup device prior to the upgrading the device.Re-enabling
mirroring should be done only after both active and backup devices
have the same software version.
• When downgrading to a software version that does not support the
current license of the device, the license will be lost. Please contact
Radware's helpdesk for more information.
2-12 CID User Guide

Software Version Update

For product versions prior to the ones listed in Table 2-3 (below) a
single software version was loaded on Application Switch 1, Application
Switch 2 or Compact Application Switch. The software was burnt in
duplicate on the internal flash.
Table 2-3 Product Version
Product Version
CID 2.10
CSD 4.10
FP 3.21
LP 4.21
WSD 8.10
From these versions forward, the way in which flash memory space is
managed was changed to a File System mechanism. This allows for
the following:
• Use of compact flash in Application Switch 2, 3 and above.
• More flexible memory management
• Prevent boot version changes caused by different memory
allocation requirements (main reason for boot version changes).
• Security upgrades
• Two different software versions in the memory (only one may be
active) - with the possibility to change active version by toggling
between the two.
To display list of software versions loaded on the device:

• From the Command Line Interface use command
system file-system software
• From Web-based management click on File menu > Software List
option.
CID User Guide 2-13

• From APSolute Insite, open the device set-up (double-click on the

device icon), click on Device Updates > Downloads table.
To change active software version:

• From the command line interface use command system file-
system config act-appl set X, where X is the application
index as displayed previously.
• From Web-based management click on File menu and choose the
Software List option. Select the inactive version (Active Field has
value False) and change the Active Parameter to True and click on
Set to record your preferences. You will be prompted to reboot the
device.
Note: Each software version has its own configuration file.
Flash Memory Management

Table 2-4Displays the Flash Memory for the Application Switches
Table 2-4 Flash Memory Management
Switch Internal Flash Compact Flash
AS1 2 Application Software Not available

versions
AS2 and Backup Application version 2 Application Software

above versions
CAS 2 Application Software Not available

versions
On AS2 and above a copy of an application software version is loaded

in the internal flash for backup purposes. On the internal flash only IP
host parameters are saved to allow communication with the device in
case of compact flash problems.
Note: Do not power up or reboot Application Switch 2 and above when
the compact flash card is not inserted.
2-14 CID User Guide

Software Version Update

You can download a new software version by using either WBM or via
APSolute InsiteAPSolute Insite.For versions using File Systems
mechanism the firm ware file is in TAR format, while for previous
versions it appears in binary (BIN) format.
Note: Before initiating software version update on Application Switch 3
or Application Switch 2 running file system version, ensure that a back-
up application is installed in the internal flash * see Backup Version
Update, page 2-17.
To upgrade the software version via Web Based Management:

1. From the File menu select Software Upgrade. The Update Device
Software window appears.
2. From the Update Device Software window, set the following
parameters according to the explanations provided:
Password: Enter the case-sensitive password you
have obtained from Radware corporate
Web Site for this upgrade: http://
www.radware.com/content/support/
pwordgen/default.asp
Software Version: Specify the actual version to be
loaded using X.XX.XX format.
File: Select the appropriate firmware file.
Enable New Version: Select the Enable New Version
check box to apply the recent
upgrade.
Note: The device operates according
to the new version after the software
download process is complete,
otherwise the device operates
according to the previous version.
3. To accept your preferences, click Set. You will be prompted to
reset the device.
CID User Guide 2-15

Note: When upgrading from a minor version or bug fix version

AB.CD.EF to version AB.CX.XX a password is not required, for
example when upgrading from 8.21.05 to 8.23.12 a password is not
required.
2-16 CID User Guide

To update software version via APSolute Insite:

1. From the device application window, double-check on the device
icon. The device setup (device specific) window appears.
2. From the Setup tab, click Device Upgrades. The Device
Upgrades dialog box appears.
3. In the File Name text box, type the name of the file, OR click
Browse to find the desired file.
4. In the Password text box, type the password received with the
new software version.
Note: The password is case sensitive
5. In the New Version text box, type the software version number as
specified in the new software documentation.
Note: If Enable New Version check box is selected (default) the
device operates according to the new version after the software
download process is complete, otherwise the device operates
according to the previous version.
6. Click Set. The status of the upload is displayed in the Progress
Status bar. You are prompted to restart the device.
Backup Version Update

On Application Switch 2, the backup application version (internal flash)
is updated automatically when a new application version that includes
a new boot version is downloaded to the device.
On Application Switch 3 and above it is not necessary to update
backup application version when there is a new boot version - compact
flash and internal flash have separate boot memories.
If however you wish to manually update the backup application version
or install it, it is possible via the CLI command: system file-system
files copy-to-flash x, where x is the index of the new
application you want to use (existing applications and their indexes are
displayed by: system file-system config act-appl
command).
CID User Guide 2-17

Saving and Restoring Configuration Files

It is recommended to save existing configurations on each Radware
device. If a change to the configuration results in problems,
administrators can restore a previous configurations to the unit. Files
are stored locally on the desktop or laptop running APSolute Insite in a
binary format. You can perform this procedure also from WBM.
Notes:
• When downloading a configuration file using WBM, the
configuration can not be uploaded to a device that was configured
to use only to SNMPv3.
• When downloading a configuration file using CWI and SNMPv3,
the configuration can not be uploaded to a device that supports
only SNMPv1.
• The Configuration file of the device, that contains SNMPv3 users
with authentication, can only be used by the specific device that the
users configured. When exporting the configuration file to another
device, the passwords need to be re-entered, since passwords (of
SNMPv3 users) can not be exported from one device to another.
Therefore there must be at least one user in the user table (to be
able to change the password) in case the configuration file is
uploaded to another device. Note that this is relevant for SNMPv3
RFC.
To save an existing configuration:

1. From the main window, select
Device > Configuration File > Download.
2. Click the Browse button and navigate to the file you wish to save.
3. Select the required configuration file and click Ok. The current
configuration is saved.
To restore an existing configuration file:

Device > Configuration File > Upload.
2. Click the Browse button and navigate to the file to restore.
3. Select the required configuration file and click Ok. The selected
configuration is restored.
2-18 CID User Guide

4. After the restored configuration has been applied to the Radware

device, reboot the unit.
The downloaded configuration file appears in BER format. If you wish
to view the BER format file, you must convert it to ASCII format.
However, the configuration file that is being uploaded to the device,
must be in BER format.
To convert a BER file to ASCII format:

1. From the main window, select Device > Configuration File > Edit.
The Edit window opens.
2. From the Edit window, select Convert from BER to ASCII.
3. Click the Browse button and navigate to the BER file you wish to
convert to ASCII.
4. Select the required configuration file and click Ok. The file format
is converted to ASCII.
CID User Guide 2-19

Upgrading Licenses
You can upgrade software capabilities of CID by means of the licensing
mechanism, for example to add SynApps support. For Application
Switch 3, you can add support for the 10 Gigabit Ethernet Port using
the hardware licensing mechanism.
Note: For more information regarding obtaining licenses, please
contact the Radware Technical Support.
The Licensing Mechanism

In order to change license, you need to insert a new license code. The
license provided to you, is a one-time license, meaning that once this
license is changed, the old license code cannot be re-used. For
example, if a SynApps license was given to you on a trial basis and not
purchased, Radware provides you with another license, without
SynApps support, the old license cannot be reused.
The license is based on the MAC address of the device, and on a
license ID that is changed every time a new license is inserted.
To get a license upgrade, you need to send the MAC address and the
current license ID of the device.
To perform a license downgrade, you need to send the MAC address
and the current license ID of the device. Once you receive and insert
this new license, a screen capture of the License Upgrade window, or
the output of system license get CLI command, must be sent to
Radware to prove that you are using the new license. After that
Radware assured that the old license cannot be re-used.
To upgrade a software license:

1. From the main window, double click the CID icon. The CID window
appears.
2. From the Set-Up tab, click Device Upgrades. The Device
Upgrades dialog box appears.
3. From the Device Upgrades dialog box, click Licence Upgrade.
The Licence Upgrade pane appears displaying the current license
in the New Licence Code text box.
2-20 CID User Guide

4. In the New Licence Code text box, type your new license code.
Note: The license code is case sensitive.
5. Click Ok. The Information box prompts you to reset the device in
order to validate the license.
6. Click Ok to perform the reset. The reset may take a few minutes.
A success message is displayed on completion.
Upgrading Hardware Licenses

For Application Switch 3, you can add support for 10 Gigabit Ethernet
Port by means of the hardware licensing mechanism. This feature is
only available for Application Switch 3.
To upgrade a hardware license:

1. From the main window, double click on the CID icon. The CID
window appears.
2. From the CID window, click Set-Up > Device Upgrades. The
Device Upgrades dialog box appears.
3. From the Device Upgrades dialog box, click the Hardware
Licence tab. The Licence Upgrade pane appears displaying the
current license in the New Licence Code text box.
4. In the New Licence Code text box, type your new license code.
Note: The license code is case sensitive.
5. Click Ok. The Information box prompts you to reset the device in
order to validate the license.
6. Click Ok to perform the reset. The reset may take a few minutes.
A success message is displayed on completion.
CID User Guide 2-21

Upgrading Licenses Using CLI

The following procedure enables you to upgrade your software and
hardware licenses using the command line interface.
To upgrade a software license using CLI:

1. In the command line interface, type system license get.
2. Click Enter. The current license code is displayed.
3. Type system license set <new license code>.
4. Click Enter. The license updated message is displayed in the
command line.
Note: To implement the upgrade, the device must be reset.
5. Type reboot in order to reset the device, then type yes to

confirm the reset.
To upgrade a hardware license using CLI:

1. In the command line interface, type: system hardware
license
2. Click Enter. The current license code is displayed.
3. Type: system hardware license set <new license
code>
4. Click Enter. A license updated message is displayed in the
command line.
Note: To implement the upgrade, the device must be reset.
5. Type reboot in order to reset the device, then type yes to

confirm the reset.
2-22 CID User Guide

Upgrading Licenses Using WBM

You can perform license upgrades using Web Based Management.
To upgrade a license using WBM:

1. From the Device menu, select License Upgrade. The License
Upgrade window appears.
2. In the Insert your License Code text box, type the code of the new
license and click Set.
CID User Guide 2-23

Upgrading Boot Versions

As Radware's product line develops, it may become necessary to
upgrade a device's Boot Code to support new firmware. To support
new firmware, you may need to upgrade a device's Boot Code. For
information regarding upgrading boot versions, refer to Boot Version
Update, page 10-34.
2-24 CID User Guide

Section 2-3 Device Configuration Options

Section 2-3 Device Configuration Options describes the interfaces and
methods for CID device configuration and permissions.
• APSolute Insite, page 2-26
• Command Line Interface, page 2-27
CID User Guide 2-25

Device Configuration Options
APSolute Insite
APSolute Insite is the main management interface for all Radware
devices. This application allows the system administrator to configure,
modify and manage all types of Radware devices in an enterprise
network. Rather than focusing on a single device, APSolute Insite
presents the entire network configuration in a graphical format, with
settings and configuration options organized in a logically related
manner.
Notes:
• For further information regarding APSolute Insite, refer to the
APSolute Insite User Guide.
• For an explanation of how to access statistics about device
performance, and how to work with statistical graphs, refer to the
APSolute Insite User Guide.
2-26 CID User Guide

Command Line Interface

Access to the Command Line Interface (CLI) requires a serial cable
and a terminal emulation application. Although each product has a
slightly different list of commands, the majority of the available options
are the same:
bwm Policy management and classification
classes Configures traffic attributes used for

classification
device Device Settings
health- Advanced Health Monitoring

monitoring
help Displays help for the specified

command
login Login into the device
logout Logout of the device
CID CID parameters
manage Device management configuration
net Network configuration
ping Sends echo requests
reboot Reboot the device
redundancy Redundancy settings
security Security settings
services General networking services
statistics Device statistics configuration
system System parameters
CID User Guide 2-27

Device Configuration Options
CLI Supported Capabilities

Radware's Command Line Interface can be used through console
access, Telnet, or SSH. CLI provides the following capabilities:
• Consistent, logically structured and intuitive command syntax.
• A system config command to view the current configuration of
the device, formatted as CLI command lines.
• Pasting the output of system config, or part of it, to the CLI of
another device, using the system config set command. This
option can be used for easy configuration replication.
• Help and command completion keys.
• Command line editing keys.
• Command history.
• Configurable prompt.
• Configurable banner for Telnet and SSH.
• Ping: Ping other hosts on the network to test availability of the
other hosts.
• Traceroute: Use the command trace-route <destination
Host >. Output format:
CID#trace-route www.radware.com
trace-route to host 209.218.228.203:
1: 50ms 50ms 50ms 212.150.43.130
2: 50ms 50ms 50ms 80.74.101.129
3: 50ms 50ms 50ms 192.116.214.2
4: * * *
5: 50ms 50ms 50ms 80.74.96.40
• Telnet client: to initiate a telnet session to remote hosts. Use the
CLI command telnet <Host>.
• SSH client: to initiate a telnet session to remote hosts. Use the CLI
command ssh <Host>.
• DNS Client: uses configured DNS servers to query IP addresses
of a hostname. Use the command services dns nslookup
<hostname>.
2-28 CID User Guide

Make sure to enable DNS and set DNS servers appropriately, using the
services DNS client commands. The DNS client also enables using
host names rather than IP addresses in commands such as trace-
route, ping, telnet, and so on. The DNS client is configurable also from
APSolute Insite.
Notes:
• For description of the DNS Client, refer to page 2-79.
• For more information concerning CLI commands, refer to the
Radware CLI Reference Manual.
CID User Guide 2-29

Device Access
Section 2-4 Device Access

Section 2-4 Device Access describes the interfaces and methods
related to CID device security.
All Radware devices are equipped with a variety of security features
and settings that help prevent unauthorized access and tampering with
units. In addition to the predefined security, you can use the SynApps
license to upgrade the security level for your network.
• Bandwidth Management Access, page 2-31
• Users Table, page 2-32
• Configuring SNMP, page 2-34
• Web Based Management, page 2-48
• Telnet and SSH, page 2-51
• RADIUS Authentication, page 2-60
• Management Ports, page 2-62
• Ping Physical Port Permissions, page 2-70
• Dedicated Management Port, page 2-71
2-30 CID User Guide

Bandwidth Management Access

Radware devices also provide a packet-filtering database, which can
be configured to control access to the unit and through the unit, based
on a variety of factors, such as protocol, port, and source or destination
addresses.
Bandwidth Management Configuration Guidelines:

• From the main window, click BWM Management.
Management Ports
Access to any of the devices can be limited to specified physical
interfaces. Interfaces connected to insecure segments of a network can
be configured to discard some or all kinds of management traffic
directed at the device itself. Administrators may wish to allow certain
types of management traffic to a Radware device, such as SSH, while
denying others (such as SNMP or Telnet). If an intruder attempts to
access the device through a disabled port, the Radware unit does not
allow access and generates syslog and CLI traps as notification.
Port Management Configuration Guidelines:

From the main menu select; General > Device
Permissions > Management Settings.
CID User Guide 2-31

Device Access
Users Table
You can create a list of personnel authorized to access the device.
Entries in this table allow access to the Radware device through any
enabled access method (Web, Telnet, SSH, SWBM). When Trace
Status is enabled, users can receive e-mail notifications of changes
made to the device.
To set the Users Table:

1. From the main window, select General > Device Permissions.
The Device Permissions window appears.
2. Select the Users Table tab and click Add. The Edit Device Users
window appears.
3. From the Edit Device Users window, set the following parameters
according to the explanations provided:
Device Name: Select the device name.
User Name: Type the name of the user.
Password: Type the password for the user.
E-mail: Type the e-mail address of the user.
Notification: Define the minimum severity level of traps that
are sent to this user.
Values: None (the user receives no traps);
Info; Warning; Error; Fatal (the user receives
traps with severity info or higher).
Default: None
Trace Status: Enable this option to notify users of
configuration changes made in the device. For
more information see Configuration Trace,
page 2-86.
Values: Administrator; Operator.
Default: Operator.
4. Click Ok to apply the setup and exit the window. The new device
permission is listed in the Users Table.
2-32 CID User Guide

Note: User and Password can be up to 19 characters.
CID User Guide 2-33

Device Access
Configuring SNMP
The Simple Network Management Protocol (SNMP) is an application
layer protocol that facilitates the exchange of management information
between network devices. SNMP is a part of the Transmission Control
Protocol/Internet Protocol (TCP/IP) protocol suite. Radware devices
work with the following versions of SNMP: SNMPv1, SNMPv2 and
SNMPv3.
Network management systems contain two primary elements:
managers and agents. The Manager is the console through which the
network administrator performs network management functions.
Agents are the entities that interface to the actual device being
managed allowing changing or retrieving objects in the device.These
objects are arranged in what is referred to as management information
base (MIB). SNMP is the protocol that allows managers and agents to
communicate for the purpose of accessing these objects.
This section explains how to configure SNMP on CID. Configuration
examples for SNMP versions 1, 2 and 3 are included.
SNMPv3 is composed of 2 layers of communication between the
manager and the agent:
• User Security Model (USM), which provides Secure
Communication, including message integrity and privacy.
• View-Based Access Control Model (VACM), which provides
granular access permissions. For example, a user can have write
access to limited portions or the MIB, and read access to wider
portions.
Note: By default, APSolute Insite connects to the CID device using
SNMPv1.
To connect to device using SNMPv3:

1. From the CID main toolbar, click Add and select the CID icon. The
CID icon appears on the map.
2. Double click the CID icon. The CID Connect To Device dialog box
appears.
2-34 CID User Guide

3. In the CID Connect To Device dialog box, type the Device IP

Address and select the SNMPv3 check box. The SNMPv3 pane
opens.
4. Set the Authentication and Privacy parameters as defined in the
Users Table, see page 2-35.
5. Click Ok. The CID device is connected using SNMPv3.
To view the SNMP tab:

2. Click the SNMP tab. The SNMP pane appears, displaying the
current permissions.
Defining SNMP Users

With SNMPv3 user-based management each user can have different
permissions based on the user name and connection method.
You can create a new user by cloning the definitions of one of the
existing users.
In the User Based Security Model window, you can define users who
can connect to the device and you can store the access parameters for
each SNMP user.
To define a new SNMP user:

2. Click the SNMP tab. The SNMP pane appears, displaying the
current permissions.
3. From the SNMP pane, click Users. The User Based Security
Model window appears.
4. From the User Based Security Model window, click Add, then set
the following parameters according to the explanations provided:
Clone From User: Select the existing user from which
you want to clone the definitions.
CID User Guide 2-35

Device Access
User Name: Type the name of the new user, up to

18 characters.
Authentication Type the protocol to be used during
Protocol: the authentication process.
Default: None, meaning using clear
text during the session. Possible
values are MD5 and SHA.
Authentication Type the password to be used during
Password: the authentication process.
User Privacy Protocol: Type the algorithm to be used for
encryption.
Default: None, which means that the
data is not encrypted. Possible value
is DES.
Privacy Password: Type the password required to use
privacy.
Notes:
• Privacy is only supported in conjunction with authentication
• The User Name parameter is also called Security Name
5. Click Ok to apply the setup and exit the window. A new user is
defined for access to SNMP.
Note: The Configuration file of the device, that contains SNMPv3 users
with authentication, can only be used by the specific device that the
users configured. When exporting the configuration file to another
device, the passwords need to be re-entered, since passwords (of
SNMPv3 users) can not be exported from one device to another.
Therefore there must be at least one user in the device‘s user table (to
be able to change the password) in case the configuration file is
uploaded to another device. Note that this is according to SNMPv3
RFC.
SNMP - VACM Edit Security to Group

SNMPv3 permissions are defined for groups of users. In cases that
there is a need to grant to the same user different permissions based
2-36 CID User Guide

on the connection method, it is possible to associate the same user to

more than one group. For example, if user A connects to a Radware
device using SNMPv3 with authentication and privacy, the user gets
Read-Write permissions, while if the same user A connects to a
Radware device with authentication and without privacy (data is not
encrypted), then this user gets Read-Only permissions.
You can associate users with groups listed in the VACM Edit Security to
Group window. Access rights are defined for groups of users.
To configure VACM Edit Security to Group:

2. From the Device Permissions window, click the SNMP tab. The
SNMP pane appears.
3. From the SNMP pane, click Add. The VACM Edit Security to
Group window appears.
4. From the VACM Edit Security to Group window, set the following
Security Model: Select the SNMP version to be
associated with this group.
Possible values: SNMPv1, SNMPv2
or User Based (SNMPv3).
Security Name: Select a relevant security name, that
is the name as defined in the Users
Table.
Group Name: Select a name from a list of all the
available group names.
5. Click Ok to save the setup and to exit the window.
VACM - MIB View

The View Table defines subnets of the MIB tree. Those views are used
to allow Read - Write access based on the MIB tree. The same Family
View Name can be used for multiple entries to allow maximum
flexibility; each entry can include or exclude parts of the entire MIB tree.
CID User Guide 2-37

Device Access
For example, you can grant Read access to all MIBs starting with
1.3.6.1 but not to MIBs that start with 1.3.6.1.2 and yet, to give access
to MIBs that start with 1.3.6.1.2.1 and 1.3.6.1.5.
To set the parameters of the VACM MIB Tree:

1. From the CID main window, select General > Device Permissions
and from the Device Permissions window, click the SNMP tab. The
SNMP pane appears.
2. From SNMP pane, click Access. The VACM Group Access
window appears.
3. From the VACM Group Access window, click View. The VACM
MIB View window appears.
4. From the VACM MIB View window, set the following parameters
Family View Name: Type the name of this entry as explained
above.
Family Subtree: Type the object ID of the MIB subtree.
Type: Define whether the object of this entry is
included or excluded in the MIB view.
5. Click Update to apply the setup and click Ok to exit the window.
SNMP - Access
The Access Table binds the groups, views and security models. This is
the table that grants permissions to the groups, based on the SNMP
version.
You can define the access rights for each group and Security Model in
the VACM Group Access window. Range of objects which can be
accessed for a read, write or notify action is specified through the Read
View Name, Write View Name and the Notify View Name parameters
and depends on the defined Security Model. The Read, Write, and
Notify permissions are configured for Family View names, which are
defined in the VACM - MIB View window, see page 2-37.
2-38 CID User Guide

To set the parameters of the SNMP Access Table:

SNMP pane appears.
3. Click Access. The VACM Group Access window appears.
4. Click Add. The VACM Edit Group Access window appears.
5. From the VACM Edit Group Access window, set the following
Group Name: Type the name of your group.
Security Model: Select the SNMP version that represents
the required Security Model.
The security models are predefined sets of
permissions that can be used by the groups.
These sets are defined according to the
SNMP versions. By selecting the SNMP
version for this parameter, you determine
the permissions set to be used.
Possible values: SNMPv1, SNMPv2 or User
Based (SNMPv3).
Security Level: Select the security level:
• No Authentication: No authentication
or privacy are required.
• Auth Not Private: Authentication is
required, but Privacy is not required
• Auth Private: Both authentication and
privacy are required
Default: No Authentication.
Read View Name: Select an item from a list of all the available
views that are configured in the VACM - MIB
View window and provide the Read access
to the Object IDs specified in the selected
view.
CID User Guide 2-39

Device Access
Write View Name: Select an item from a list of all the available
views that are configured in the VACM - MIB
View window and provide the Write access
view.
Notify View Select an item from a list of all the available
Name: views that are configured in the VACM - MIB
View window and provide the Notify access
view.
6. Click Ok to save the setup and exit from the window.
SNMP - Target Address

In SNMP v3, this table contains transport addresses to be used in the
generation of traps. If the tag list of an entry contains a tag from the
SNMP Notify Table, this target is selected for reception of notifications.
For SNMP version 1 and 2 this table is used to restrict the range of
addresses from which SNMP requests are accepted. If the Transport
Tag of an entry in the community table is not empty it must be included
in one or more entries in the Target Address Table.
To add a new SNMP Target Address:

1. From the main window select General > Device Permissions and
from the Device Permissions window, click SNMP. The SNMP pane
appears.
2. From the SNMP pane, click Targets. The Target Address window
appears.
3. From the Target Address window, click Add. The Edit Target
Address dialog box appears. Set the following parameters
Name: Type the name of this entry.
2-40 CID User Guide

Target Address: Type the IP address of the management

station that is used:
• To provide access to the specified IP
address only
• To send SNMP traps to that IP address.
Target Port: Type the number of the Target Port. The
TCP port to be used: 161 for SNMP Access
and 162 for SNMP Traps.
Default:162.
Tag List: A list of tags separated by spaces. This tag
must be the same tag as the Community
Transport Tag in the Community Table.
Default: v3Traps.
Parameters: The name of the entry in the Parameters
Table to be used when sending the SNMP
Traps.
Tip: The SNMP Target Address window also allows you to access the
SNMP Target Parameters window, see page 2-41.
SNMP - Target Parameters

The Target Parameters table contains parameters to be used in
generating a message. Entries in this table are referenced in the Target
Address table.
To set the Target Parameters:

1. From the main window, select General > Device Permissions and
appears.
2. From the SNMP pane, click Targets. The Target Address window
appears.
3. From the Target Address window, click Parameters.The Target
Parameters window appears.
CID User Guide 2-41

Device Access
4. From the Target Parameters window, click Add. The Edit Target
Parameters dialog box appears. Set the following parameters
Name: Name of the new parameter for the
Target Address.
Message Processing Select the model from: SNMP Ver 1;
Model: SNMPVer 2c; SNMP Ver 3
Security Model: Select the security model as
explained on page 2-39.
Possible values: SNMP Ver 1; SNMP
Ver 2c; User Based.
Security Name: Type the security name of the user.
Security Level: Select the security level:
• No Authentication: No
authentication or privacy are
required.
• Auth Not Private:
Authentication is required, but
Privacy is not required
• Auth Private: Both
authentication and privacy are
required
5. Click Ok to save the setup and click Ok to exit the Target
Parameters and Target Address windows.
SNMP - Community Table

The purpose of the community table is to allow backwards compatibility
with SNMPv1 and SNMPv2. The Community Table maps community
strings to users. Once a user is connected to Radware device with
SNMPv1 or SNMPv2, the device checks the Community String sent in
the SNMP packet. Based on the Community String, the device maps
the Community Sting to a pre-defined user, which belongs to a group,
2-42 CID User Guide

with certain access rights. Therefore, when working with SNMPv1 or

SNMPv2, users, groups, and access must be defined as well.
Note: The SNMP Community Table is used only for SNMP v1 and v2.
To configure the SNMP Community Table:

SNMP pane appears.
3. From the SNMP pane, click Community. The Community window
appears. Click Add then set the following parameters according to
the explanations provided:
Index: Type a descriptive name for this entry.
Community Type the string for community.
Name:
Security Name: Type the user name associated with the
community string.
Community This string specifies a set of target
Transport Tag: addresses from which the SNMP agent
accepts SNMP requests and to which traps
may be sent. The target addresses
identified by this tag are defined in the
Target Address Table, see page 2-40.
If this string is empty, addresses are not
checked when an SNMP request is
received or when a trap is sent. If this string
is not empty, the transport tag must be
contained in the value of the Tag List
parameter of at least one entry in the Target
Address Table.
CID User Guide 2-43

Device Access
SNMP - Notify Table

Using the SNMP Notify Table you can select management targets that
receive notifications including the type of notification to be sent to each
selected management target. The Tag parameter contains a string that
is used to select entries in the Target Address table, see SNMP - Target
Address, page 2-40. An entry in the Target Address table whose tag list
contains the tag of one or more entries of the notification table, is
selected for reception of notifications.
To set the notifications for the target Address:

1. From the main window, select General > Device Permissions and
appears.
2. From SNMP pane, click Targets. The Target Address window
appears.
3. From the Target Address window, click Notify. The Notify Table
window appears.
4. From the Notify Table window, click Add. The Edit Notify Table
appears.
5. From the Edit Notify Table window, set the following parameters
Name: Type the name of the entry.
Tag: This string selects one or more entries in the
Target Address table. All entries in this table
whose tag list contains this tag are selected for
reception of notifications.
Type: Select the type of notification, for example trap.
6. Click Ok to apply the setup and click Ok twice again to exit the
Notify Table window and the Target Address window.
2-44 CID User Guide

Example - SNMPv3 Access To the Device With

Authentication and Privacy
The following example shows how to configure a Radware device to
allow access using only SNMPv3, MD5 as the authentication protocol
and DES as the privacy protocol. Since the user with limited access
privileges cannot create a user with unlimited access, the first user
must be created via the CLI or WBM.
Configuration:
1. From Web Based Management, select

Security > SNMP > User Table and create a new entry by
configuring the following parameters according to the explanations
provided:
User Name: administrator
Authentication MD5
Protocol:
Authentication password
Password:
Privacy Protocol: DES
Privacy Password: password
2. Open APSolute Insite.
3. From the CID main toolbar, click Add and select the CID icon. The
CID icon appears on the map.
appears.
5. From the CID Connect To Device dialog box, type the Device IP
opens.
The pre-configured User Name for SNMPv3 is "radware". When
connecting using that User Name, neither Authentication nor
Privacy are required.
6. Click Ok. The device is connected using SNMPv3.
CID User Guide 2-45

Device Access
7. From the main menu, select General > Device Permissions.

8. Click SNMP. The SNMP tab appears containing the following
configuration options: Targets, Views, Users, Community, Access.
9. From the SNMP tab, click Access. The VACM Group Access
window appears.
10. From the VACM Group Access window, click Add, then set the
following parameters according to the explanations provided:
Group Name: admin
Security Model: USM
Security Level: AuthPrivate
Read View Name: iso
Write View Name: iso
Notify View Name: iso
11. Click Ok and Ok again.
12. To associate the user administrator with the admin group, from the
SNMP tab, click Add. In the VACM - Edit Security To Group dialog
box appears, set the following parameters according to the
explanations provided:
Security Model: USM
Security Name: administrator
Group Name: admin
13. Click Ok and Ok again to close all the windows.
14. Reconnect to the device using SNMPv3, User Name "admin" and
Password "password" both for Authentication and Privacy
protocols.
• To create additional users with the same access rights, open
the Users window, and add a new user. The new user can be
cloned from the existing logged in user, or from a different user,
see page 2-35.
• To associate a new user with a group, from the SNMP window,
click Add and associate the new user with its group.
2-46 CID User Guide

To restrict SNMPv1 and SNMPv2 access to the device, remove the

"public" community entry from the Community window, see page 2-42.
CID User Guide 2-47

Device Access
Web Based Management

Each Radware device can be managed using a web-based interface
enabled from General > Preferences. Web access can also be
confined to SSL; administrator can specify the TCP port for the Web
Based Management and the secure Web Based Management (WBM).
Web Based Management graphical user interface (GUI) does not
require any installation on a client, and is designed for easy and fast
single device management.
When using Web Based Management, On-line help is also available
from the Radware corporate Web site. However, you can specify a
custom location for the help files.
Web Based Management is supported using the following Internet
browsers:
• Internet Explorer version 6 (when using Windows operating
systems) with cumulative security update for IE 6 sp-1.
• Mozilla when using Linix operating systems..
Note: In WBM, Online Help is available by clicking on the? Help icon
that appears in every screen.
Web Based Management Features

• HTTP Summary Page: Using the Device Monitoring summary
page, you can get a quick view of the farm and server health. The
summary page also provides a launching point from which to 'drill
down' to more specific health and configuration information. You
can configure an interval during which the page is refreshed (any
number of seconds between 10 to 3600). The Device Monitoring
window is accessible from the WBM Device menu.
• HTTP Button to Switch Between Active and Backup Device:
Using the Web-based interface, you can switch between the active
device and the associated backup device. This functionality is also
accessed from the Device Monitoring window.
• Secure Web Based Management: An HTTPS session. By default,
the device has self-signed Radware SSL certificates. However, you
can specify your own self-signed SSL certificate.
2-48 CID User Guide

• Web Based Management Access Level: You can set Web Based
Management Access Level to Super (default) or Read Only. This
setting effects both WBM and Secure WBM.
When Web Based Management Access Level is set to Read Only,
then users using Web Based Management or Secure Web Based
Management experience the following limitations:
• Can not change the configuration of the device.
• Can not view the Community Table or User Table.
• Have no access to SSH Public Key Table.
• SSL keys and certificates cannot be viewed.
• Configuration File cannot be sent to the device or received from
the device.
• Software update to the device is not allowed.
• Can not reset the device.
This configuration is accessible using Configware from Services
menu, selecting Web Based Management, or using the CLI
command manage web access-level.
Note: Setting this parameter requires restarting the device
To create a new SSL certificate:

1. From the Services menu, select SSL > Certificates.
2. Click Create. The Create Self Signed Certificate window appears.
3. In the Create Self Signed Certificate window, set the following
Common Name: The name of the organization‘s
contact.
Organizational Unit: The name of the organization‘s sub-
unit or branch.
Organization: The name of the organization.
Locality: The name of the city in which the
organization is located.
State/Province The state or province of the company‘s
location.
CID User Guide 2-49

Device Access
Country: The country of residence or the

organization.
Fully Qualified Domain The complete URL address of the
company.
Key Size: Can be either RSA 512 bits, RSA 768
bits or RSA 1024.
Save Key File As: The user defined name of the self-
signed certificate‘s key
Save Certificate As: The user defined name of the self-
signed certificate.
4. Fill in the relevant parameters and then click Ok.
Note: SSL Keys and certificates are not exported as part of the
configuration.
2-50 CID User Guide

Telnet and SSH

Radware products support Telnet and SSH management access.
Telnet is enabled from
General > Preference > Device Access > Telnet Parameters.
SSH is enabled from
General > Preference > Device Access > SSH Port.
You can specify the TCP port for Telnet management and SSH.
Note: CID supports up to two simultaneous Telnet or SSH sessions.
Time-outs are added for logging into CLI through Telnet and SSH. After
establishing of CLI session with the device, user name and password
must be inserted within 30 seconds. In case of 3 incorrect logins, the
terminal is locked for 10 minutes and no further logins are accepted
from that IP address. Once a login is successfully completed, the CLI
session closes after 5 minutes of idle time. not sure if this info here or o
CLI Timeouts
It is possible to configure the timeout for Telnet, SSH and the CLI
sessions. In addition to the session timeout, system administrators can
also configure the authentication timeout. Authentication timeout is the
time that the user has in order to complete the authentication process,
starting from the moment the user established the Telnet or SSH
connection.
Configurable Parameters:
• "Session Timeout - Timeout (in minutes) required for the device to
maintain connection during periods of inactivity. Default value is 5
minutes for Telnet and SSH and unlimited for the CLI. Optional
values 1 - 120 minutes.
• "Authentication Timeout - Timeout (in seconds) required to
complete the authentication process. Available for Telnet and SSH
only. Default value is 30 seconds. Optional values 10 - 60 second.
Note: In order not to affect the performance of the device, a special
task checks the timeout every 10 second. This means that the
actual timeout can be up to 10 seconds longer.
CID User Guide 2-51

Device Access
Enabling Management Applications on Specific Physical

Ports
The Enabling Telnet and Web Based Management on Specific Port
feature makes it possible to launch configuration tools such as SNMP
based applications, Telnet. SSH, Secure Web and Web Based
Management, only through those physical ports which are defined by
the user. In the same manner, it is also possible to disable launching
Telnet or WBM through specific ports.
To enable web managed ports:

Device > Device Permissions > Management Settings.
The Management Settings tab appears, showing the current device
in the Device dropdown list.
2. From the Device dropdown list, select the device.
3. From the Management Ports parameter, select the required

management application.
Management applications are: SNMP; Telnet; SSH; Web; SSL
Default: SNMP; Enable All.
2-52 CID User Guide

4. To select the specific physical ports for the application, check the
ports you wish to enable or disable or check Enable All or
Disable All.
5. Click Apply to save the setup. The window remains open.
6. To configure ports for another web management application, from
the Management Ports parameter select the application and the
active ports, as in steps 2 and 3.
7. Click Apply to save the setup and Ok to exit the window.
CID User Guide 2-53

Device Access
FTP Content Management
FTP Proxy Support

When deploying an FTP (File Transfer Protocol) proxy server for FTP
caching or FTP content inspection, CID provides special treatment for
these servers. CID intercepts FTP sessions of non-configured client
and load balances it to the FTP proxy server farm. CID transforms the
client “username: password” command to
"username:password@domain". This transformation allows the FTP
proxy server to extract the original destination FTP host and then to
open the FTP session to that host, on behalf of the client. This process
is transparent for the client. By default, CID supports both passive FTP
sessions and active FTP sessions.
2-54 CID User Guide

Figure 2-1 shows a typical FTP Proxy Content Management setup.
Internet FTP Content Servers

100.1.1.1
100.1.1.2
Access Router
100.1.120
Network Side Port 2

100.1.1.10
CID
Virtual IP Address
10.1.1.100
Port 1
Users Side 10.1.1.10
Client 1 Client 2
10.1.1.1 10.1.1.2
Figure 2-1 FTP Proxy Content Management Configuration
Properties:
• Network side and users side are on different IP subnets.
• The virtual IP address of the CID is 10.1.1.100.
• Users are not configured to the CID.
• Content servers work in FTP Proxy mode.
• The delimiter ('@') is proxy dependent, and may vary.
• Configuring ftp-session service supports both passive and active
FTP sessions.
CID User Guide 2-55

Device Access
Configuration:
1. Define two IP Addresses on the CID:
a. Double click on the CID icon and from the CID Connect to
device window that now appears, type the device‘s IP address:
10.1.1.10 and click Ok.
b. Add the second IP address: Double click on the CID icon. The
CID window appears.
c. Click Add. The Edit CID Interface window appears.
d. From the Edit CID Interface window set the following
IF Num: F-2
IP Address: 100.1.1.10
Click Ok to exit all windows.
2. Add the default router and a default gateway:
a. Double click on the CID icon. The CID window appears.
b. Click on Networking and select Routing Table. The CID
Routing Table appears.
c. From the CID Routing Table set the following parameters
Destination IP 0.0.0.0
Address:
Network Mask: 0.0.0.0
Next Hop: 100.1.1.20
IF Number: F-2
Metric: 1
Type: Remote
d. Click Ok to exit all windows:
3. Add the servers:
a. From the CID toolbar, click the Add menu and from the
dropdown menu add a local server by defining the following
Server Name: Server 1
2-56 CID User Guide

b. Click Add and then click Ok.
c. In the same manner, add the second server by defining the
following parameters according to the explanations provided.
d. Click Add and then click Ok.
4. Add a farm:
a. From the Traffic Redirection window, select the Farms tab and
click Add. The Edit CID Farm window appears.
b. From the Edit CID Farm window that appears, set the following
Farm Name: (For Example) Farm 1
Multiplexed for Port: Disabled
VIP Address: 10.1.1.100
Admin Status: Selected
Transform Request: Selected
c. Ensure that the Transparent Mode is enabled.
5. Add the servers to the farm:
a. From the CID Traffic Redirection window list of farms, select the
farm and click Add. The Edit CID Farm window appears.
b. From the Edit CID Farm window, click Add. The CID Farm
Servers window appears.
c. From the CID Farm Servers, set the following parameters
Server Name: Server 1 & Server 2
Transparent Mode: Disabled
Server Delimiter: @
d. Click Add and then Ok.
6. Add a local network:
CID User Guide 2-57

Device Access
a. From the CID Toolbar, click Traffic Redirection. The CID

Traffic Redirection window appears.
b. From the CID Traffic Redirection window list of farms, select the
farm, then click the Farm Policies button. The Farm Policies
window appears.
c. From the Farm Policies window, click the Classes button. The
CID Classes window appears.
d. From the CID Classes window, click the Networks button. The
CID Network Table window appears.
e. Click the Modify tab and from the Modify pane, click Add and
then set the following parameters according to the explanations
provided:
Network Name: Local
Network Mode: IP Range
From Address: 10.1.1.1
To Address: 10.1.1.2
f. Click Ok and then Ok to return to the Farm Policies window.
7. Add a new policy for HTTP:
a. From the Farm Policies window, right click Modify Farm
Policy and select Add. From the pane that appears, set the
Policy Name: http
Index: 1
Service Type: Regular Service
Service: ftp session
Source Address: Users
Destination Address: any
Direction: oneway
Description: FTP Proxy Configuration
Operational Status: Active
Cluster Farm: 10.1.1.100
b. Click Add Policy and then Ok to exit the window.
2-58 CID User Guide

FTP Address Multiplexing Support

Traditional load balancing of FTP sessions supports only cases where
the same FTP server controls both the Control Session and Data
Session of the File Transfer Protocol.
CID supports load balancing of FTP sessions where the FTP server,
which hosts the Control Session, refers the FTP client to use a different
FTP server for the Data Session using the PASV command.
Configuration
No special configuration is needed by the user in order for CID to
support the FTP Address Multiplexing.
Transparent FTP Support

The Transparent FTP feature supports FTP content servers that
intercept FTP sessions transparently and open a session on behalf of
the client. CID redirects FTP clients to proxy servers that support fully
transparent FTP. This mode is in addition to the proxy FTP.
CID User Guide 2-59

Device Access
RADIUS Authentication
With RADIUS Authentication, you can use RADIUS servers to
determine whether a certain user may or may not gain access to CID
management, using CLI, Telnet, SSH or Web Based Management. You
can also select whether to use the User Table when RADIUS servers
are not available.
Radware devices provide additional security by authenticating the
users who access the device for management purposes. Before a
management session starts, the Radware device can authenticate the
user with a RADIUS server.
To set the RADIUS Authentication:

General > Management Permissions. The Management
Permissions window appears.
2. From the Management Permissions window, click RADIUS. The
RADIUS pane appears.
3. From the RADIUS pane, set the following parameters according
to the explanations provided:
Authentication Define the Authentication method.
Method:
Values: Local Users Table; RADIUS:
RADIUS & Local Users Table.
Note: The last option means that RADIUS
servers are used but when unavailable, the
Local Users Table is used.
Main RADIUS IP Define the IP address of the primary server.
Address:
Main RADIUS The access port number of the primary
Port: RADIUS server.
Values: 1645;1812. Default: 1645.
Main RADIUS Type the authentication password for the
Secret: primary RADIUS server.
2-60 CID User Guide

Backup RADIUS Define the backup IP address of the

IP Address: RADIUS server.
Backup RADIUS Define the backup access port number of
Port: the primary RADIUS server.
Values: 1645;1812. Default:1645.
Backup RADIUS Type the authentication password for the
Secret: backup RADIUS server.
RADIUS Timeout: Define the length of time the device waits
for a reply from the RADIUS server before a
retry, or (if the RADIUS Retries value is
exceeded) before the device acknowledges
that the server is offline.
Default: 5.
RADIUS Retries: Define the number of connection retries to
the RADIUS server, when the RADIUS
server does not respond to the first
connection attempt.
Note: Once the RADIUS Retries value to
the main RADIUS server is exceeded, and
if all connection attempts have failed
(RADIUS Timeout), then the backup
RADIUS server will be used.
Default: 3.
4. Click Apply and Ok to apply the setup and to exit the window.
Notes:
• The RADIUS Authentication feature is available for CLI, Telnet,
SSH and Web Based Management and Secure Web but not for
APSolute Insite.
• Radware devices must have access to the Radius Server and must
allow Radware device access.
CID User Guide 2-61

Device Access
Management Ports
APSolute Insite is the main management interface for all Radware
products. Additional management interfaces that allow you to configure
and operate Radware devices include:
• Web Based Management (WBM)
• Command Line Interface (CLI)
You can connect a CID device to the management interfaces through
the network physical interface or through the serial port. CID supports
the following port types:
• In the network connection: SNMP, HTTP, HTTPS, Telnet, SSH.
• In the serial port connection: RS-232 up to 115 Kbps (default is
19,200 Kbps).
The following table lists the CID physical interfaces and the supporting
management interfaces:
Table 2-5 Supported Interfaces
Port APSolute Web Based Command

Insite Management Line Interface
SNMP +
V1, V3
HTTP +
Secure Web: +
Telnet +
SSH +
RS-232 +
2-62 CID User Guide

Example - Configuring Read-Only Permissions for

SNMPv1 and Full Access for SNMPv3
This example shows how to allow SNMPv1 access to the device by
adding an entry in the Community Table using the configuration of the
example on page 2-45.
Configuration:
1. From the main window select, Device > Add Radware Device
>CID. The CID icon appears in the main window.
appears.
opens.
4. Define SNMPv3 parameters as explained in the previous
example, see page 2-45.
7. From the Device Permissions window click SNMP. The SNMP
pane appears containing the following configuration options:
Targets, Views, Users, Community, Access. These options are
explained throughout this configuration example.
8. From the SNMP pane, click Community. The Community window
appears.
9. From the Community window, click Add, then set the following
Index: SNMPv1 Access
Community Name: password
Security Name: administrator
10. Click Ok when and Ok again to close the Community window.
CID User Guide 2-63

Device Access
11. From the SNMP window, click Access. The VACM Group Access
window appears.
12. From the VACM Group Access window, click Add, then set the
Group Name: admins
Security Model: SNMPv1
Security Level: No Authentication
Read View Name: iso
Write View Name: None
Notify View Name: iso
13. Click Ok and Ok again to return to the SNMP window.
14. To create a VACM entry for User Administrator and Security
Module SNMPv1, from the SNMP window, click Add. The VACM
Edit Security To Group dialog box appears.
When the SNMPv1 session is initiated to the device with the
community name "password", the device associates the user name
"administrator" with the Group "admins" based on the information from
the VACM Edit Security To Group dialog box. According to the settings
of the VACM Group Access window, only Read permissions are set for
the User Administrator in SNMPv1.
Note: APSolute Insite supports only SNMPv3 and SNMPv1.
2-64 CID User Guide

Example - Changing the Default Community Name

When Using SNMPv1 and SNMPv2
According to the default configuration of the device, the default
Community Name is "public". This example shows how to change the
default Community Name from "public" to any other name.
Configuration:
appears.
Address, use the default Device Community Name and click Ok.
The device is connected using SNMPv1.
5. Click the SNMP tab. The SNMP tab appears.
6. From the SNMP window, click Community. The Community
window appears.
7. To add a new entry to the Community table, from the Community
window, click Add. The Edit Community dialog box appears.
8. In the Edit Community dialog box, set the following parameters for
the new entry according to the explanations provided:
Index: a descriptive text
Community Name: new_community
Security Name: public
9. Click Ok and return to the main map.
10. Right click on the device icon and click Connect. The CID
Connect To Device dialog box appears.
11. From the CID Connect To Device dialog box, type the new
Community Name and click Ok.
12. Repeat the steps 4-8, and this time delete the old public entry
from the Community Table.
CID User Guide 2-65

Device Access
Example - Allowing SNMPv1 and SNMPv2 Access to

Predefined Management Stations
This example shows how to restrict management access to a Radware
device for SNMPv1 and SNMPv2, allowing only the predefined
Network Management Stations to access the device.
Configuration:
appears.
Address, use the default Device Community Name and click Ok.
The device is connected using SNMPv1.
4. From the main menu, select Device > Device Permissions. The
Device Permissions window appears.
5. Click the SNMP tab. The SNMP tab appears.
6. From the SNMP window, click Community. The Community
window appears.
7. From the Community window, select the required entry and click
Edit. The Edit Community dialog box appears.
8. In the Community Transport Tag text box, type "nms", click Ok
and Ok again to return to the main SNMP window.
9. From the SNMP window, click Targets. The Target Address
window appears.
10. From the Target Address window, click Notify. The Notify window
appears.
11. From the Notify window, click Add. The Notify Table dialog box
appears. Set the following parameters according to the
Name: Type a descriptive name.
2-66 CID User Guide

Tag: NMS
Note: The value must be the same as the
Community Transport Tag in the Community
Table.
12. Click Ok and return to the Target window.
13. From the Target window, click Add to add a new entry to the table
by setting the following parameters according to the explanations
provided:
Name: Type a descriptive name.
Target Address: Type the IP address of the NMS.
Target port: 161
Tag List: nms
Parameters: public-v1
14. Click Ok to close the Target window.
CID User Guide 2-67

Device Access
Example - Sending Secured SNMP Traps to Specific

Users
The following example shows how to configure a Radware device to
send SNMP traps using secure channel over SNMPv3. This example is
based on the example on page 2-45.
Configuration:
appears.
opens.
4. In the User Name text box, type: administrator.
6. From the main menu, select Device > Device Permissions. The
7. Click the SNMP tab. The SNMP pane appears containing the
following configuration options: Targets, Views, Users, Community,
Access.
8. From the SNMP tab, click Target. The Target Address window
appears.
9. From the Target Address window, click Parameters. The Target
10. From the Target Parameters window, click Add. The Edit Target
Parameters dialog box appears, then set the following parameters
Name: Secure Traps
Message Processing SNMP Ver 3
Model:
Security Model: User Based
Security Name: Administrator
2-68 CID User Guide

Security Level: Auth Private

11. Click Ok twice, and return to the Target Address window.
12. From the Target Address window, click Add and set the following
Name: Admins_NMS
Target Address: 10.204.100.18
Target Port: 162
Tag List: V3Traps
Parameters: Secure Traps
13. Click Ok to apply the setup and Ok again to close all windows.
14. From the main menu, click General > Events & Traps. The
Events & Traps window appears.
15. Using interface other that APSolute Insite, connect to the device.
The Events & Traps window displays SNMP traps that the device
sends using SNMPv3 with Authentication and Privacy.
CID User Guide 2-69

Device Access
Ping Physical Port Permissions

CID allows you to define which physical interfaces can be pinged.
When a ping is sent to an interface for which ping is not allowed, the
packet is discarded. By default, all interfaces of the device allow ping
To define the ports to be pinged

1. From the main toolbar, Click Split view. The front panel icon
appears on the right hand side of the main window.
2. Right click the port you wish to ping and from the dropdown menu
that appears, check the Ping Port State option.
2-70 CID User Guide

Dedicated Management Port

To provide better security for device management in case of port
failures, you can define a Dedicated Management Port, which is a
physical port of the device that is used for management traffic only.
When a failure occurs on any of the physical or logical ports and the
Dedicated Management Port is used, port failures do not affect the
device reach ability via the management port. This port can be any port
of the device.
The following notes apply to Dedicated Management Port behavior:
• No traffic is forwarded through the Management Port.
• The Management Port cannot be a member of any VLAN.
• The Management Port is not included in Interface Grouping. It is
automatically excluded from Interface Grouping decisions. You
cannot change Interface Grouping behavior for the configured
Management Port.
• The Management Port is automatically excluded from Interface
Grouping and is not affected by Interface Grouping being activated.
For more information on Interface Grouping, see Interface
Grouping, page 6-6.
• Only traffic with the port's specific MAC and IP interface(s) is
accepted (or broadcast traffic). Other traffic to the Management
Port is discarded.
• Routing entries for the Management Port can be added to the
Routing Table. These entries are required in order to send replies
for management sessions.
The configuration is performed for each device.
To define a Dedicated Management Port:

1. In the main window, double-click the device icon. The Set-Up
window appears.
2. In the Set-Up window, select Access. The Access pane appears.
3. From the Dedicated Management Port dropdown list, select the
port that you want to define as management port and click Ok.
CID User Guide 2-71

Device Tuning
Section 2-5 Device Tuning

Section 2-5 Device Tuning describes the interfaces and methods for
CID device tuning as well as providing an explanation of how to
configure the Tuning Memory Check.
• Device Tuning Parameters, page 2-73
• Tuning Memory Check, page 2-74
2-72 CID User Guide

Device Tuning Parameters

To determine the maximum number of entries allowed in the various
tables, you can use these Device Tuning Table tabs:
• BWM Settings
• Advanced Settings
• URL Handling Settings
• Health Monitoring Settings
• NAT Settings
You can also define the security parameters for your previously defined
security policy. The values in the fields are synchronized and any
changes are implemented after the device reset.
To edit the device tuning settings in APSolute Insite:

1. Double click on the CID icon. The Content Inspection window
appears.
2. Click the Global tab. The Global pane opens. Check the services
group which you want to tune on the device and click Edit
Settings. The device tuning settings table for the selected
category opens.
Note: It is strongly advised that Device Tuning only be carried out after
consulting with the Radware Technical Support.
CID User Guide 2-73

Device Tuning
Tuning Memory Check

The Device Tuning Table enables you to pre-check whether the
configured values will not cause memory allocation problems. For
every value you update in a CID table, the device can check whether
sufficient memory is available. This is done automatically when you
update tuning values in APSolute Insite. However, following the tuning
changes, you can perform a manual check using Web Based
Management or CLI.
In Web Based Management, select:
Services >Tuning > Memory Check.
In CLI, use the command:
system tune test-after-reset-values.
2-74 CID User Guide

Section 2-6 Device Services

Section 2-6 Device Services describes additional device-related CID
utilities. This section includes the following topics:
• NTP Support, page 2-76
• Daylight Saving Time Support, page 2-78
• DNS Client, page 2-79
• Show Tech Support, page 2-81
• Policy Scheduler, page 2-82
CID User Guide 2-75

Device Services
NTP Support
Network Time Protocol (NTP) enables users to synchronize devices by
distributing an accurate clock across the network. In predefined
intervals, a device sends “time query” messages to the Network Time
Server. The server then sends the date and time to the device.
Enabling or disabling the NTP feature results in different levels of
accuracy. When NTP is disabled, the time and date have to be set
manually for the device. When NTP is enabled, several parameters
need to be configured: the IP address of the Network Time Server, the
polling interval (in seconds), the time zone offset from GMT and the
NTP server port (default 123).
To configure NTP:
1. In the main window, double-click on the device icon. The Set-Up

window appears.
2. In the Set-up window, select Networking > NTP. The Network
Time Protocol Preferences window appears.
3. In the Network Time Protocol Preferences window set the
NTP Server Type in the address of the NTP Server.
Address:
Active Enables or disables the NTP feature
Checkbox:
(default: disabled).
Note: The NTP Server Address must be
configured in order to enable the NTP
feature.
NTP Port: The NTP server port (default: 123).
NTP Checking The interval, in seconds that a time query

Interval: message is sent to the NTPserver (default:
172,800).
Time Zone: The time zone offset from GMT (default: -12)
2-76 CID User Guide

4. Click Apply > Ok.
CID User Guide 2-77

Device Services
Daylight Saving Time Support

Radware devices support daylight saving time. The user has to
configure the daylight saving time start and end dates and times.
During the daylight saving time period, the device automatically adds
one hour to the system clock. The device also indicates whether it is on
standard time or daylight saving time using the Daylight Saving
Designations indicator.
Note: When the system clock is manually configured, the system
time is changed only when daylight saving time starts or ends. This
means that if daylight saving time is enabled during the daylight
saving time period, the device does not change the system time.
To configure Daylight Saving Time in APSolute Insite:

1. In the main window, double-click the device icon. The Set-Up
window appears.
2. In the Set-Up window, click Networking button. From the
dropdown list select Daylight Saving. The Daylight Savings Time
Settings dialog box appears.
3. From the Daylight Saving Status dropdown list, select Enable to
enable daylight saving time.
4. Configure the daylight saving time start and end dates and time.
In the Daylight Saving Begins [dd/mm:hh] field, enter the date and
time that daylight saving time begins. In the Daylight Saving Ends
[dd/mm:hh] field, enter the date and time that daylight saving time
ends.
5. Click Apply. Click OK.
2-78 CID User Guide

DNS Client
You can configure CID to operate as DNS client. When the DNS client
is disabled, IP addresses cannot be resolved. When the DNS client is
enabled, IP addresses can be resolved in the following ways:
• Using the configured DNS servers to which DNS client sends
queries about IP addresses of a hostname.
• Using the pre-defined static table that includes hostnames and IP
addresses.
To display the DNS table:

1. From the main window, click Traffic Redirection. The Traffic
Redirection window appears.
2. From the Traffic Redirection window, select the DNS tab. The DNS
window appears.
3. To enable the DNS client, select the Client DNS checkbox.
4. In the DNS Primary Address text box, type the address of the
primary DNS server that is used to query IP addresses of
hostnames.
5. In the DNS Alternate Address text box, type the address of the
backup DNS server that is used to query IP addresses of
hostnames in case the primary server is not in service.
6. To display the dynamic DNS table in the CLI, type the following
command:
services dns nslookup <hostname>
The DNS table is displayed.
To define the static DNS table:

1. From the main window, click APSolute OS >Traffic Redirection.
The Traffic Redirection window appears.
window appears.
4. From the DNS window, select the Static DNS option. The Static
DNS Table window appears.
CID User Guide 2-79

Device Services
5. From the Static DNS Table window, set the following parameters
Host Name: The URL name for which you want to
set the IP address.
IP Address: The IP address of the URL.
6. Click Add to apply. The new client is listed in the Static DNS
Table.
7. Click Ok to apply the setup and exit.
2-80 CID User Guide

Show Tech Support

Radware's customers use the CLI in order to configure, monitor and
debug Radware devices. In case of problems, debugging is required
and many CLI commands, such as printout of Client Table, buffer
usage and others are needed.
A new command which aggregates all the CLI commands, needed by
Radware's technical support is now available. The output of this
command is a text file, which can be downloaded and then send to
Radware's technical support.
The command is available via:
• APSolute Insite – From the Device menu, select "Download
Technical Support File"
• Web Based Management – From File menu, select "Support" and
click on the "Download Support File" button.
• CLI - The device allows displaying the output of the command on
the terminal or to generate a file and send it via TFTP.
• To display the output on the terminal, use the CLI command:
manage support display.
• To generate a file and send it via TFTP to a TFTP server, use
the command: manage support tftp put <file name>
<TFTP server's IP>. Adding the flag –v will also display the
output of the command.
Note: It is not possible to download the configuration file from the
device, while the command Show Tech Support command is
running.
CID User Guide 2-81

Device Services
Policy Scheduler
System administrators may require that specific policies will not be
active during certain hours of the day, or a certain policy will only be
activated at a specific time of the day for specific duration time. For
example – a school's library, may want to block instant messaging
during school hours, but allowing instant messages after school hours
or an enterprise may give high priority for mail traffic between 08:00 –
10:00. Generic 10.20 introduces the ability to schedule the activation
and inactivation of specific Bandwidth Management policies. By the
use of the new feature called Event Scheduler the user can now
create “events” which can then be attached to a policy's configurations.
“Events” define the date and time in which an action should be
performed.
Configurable Parameters
For each “event” it is possible to configure the following parameters:
• Name: The name of the event
• Frequency: Whether the event occurs once, daily or weekly.
• Days: If the Frequency chosen is daily or weekly, the user must
configure on which day the event should occur.
• Time (HHMM): The time on the designated day (if multiple days
are chosen then the “Time” value is the same for all configured
days) when the event should occur. The default Time value is 12:00
am (0000).
• Date (DDMMYYYY): If the Frequency chosen is once, then it is
required to configure the date on which the event should occur.
For each Bandwidth Management Policy it is possible to configure the
following parameters:
• Activation Schedule: The name of the Event which activates the
policy
• Inactivation Schedule: The name of the Event which inactivates
the policy
Once an event has been configured it should then be attached to a
Bandwidth Management policy. Once the event occurs, the device
2-82 CID User Guide

activates or inactivates the Bandwidth Management policy and then it

performs "Update Policy" action.
CID User Guide 2-83

Device Reporting
Section 2-7 Device Reporting

Section 2-7 Device Reporting describes the CID Reporting feature
which distributes warning messages about failures and problems in
network elements. Reporting distribution methods and configuration
are described.
• Notifications - General, page 2-85
• E-mail Notification, page 2-86
• Syslog, page 2-88
• Event Log, page 2-89
2-84 CID User Guide

Notifications - General
Most administrators prefer to receive a warning message about a
network or server outage. To help minimize the impact of failure in
devices such as firewalls, routers or application servers, all Radware
devices provide a choice of notification methods:
CLI Traps, Syslog, E-mail.
To send traps by CLI, Telnet and SSH, the command is:
manage terminal traps-outputs set-on
For console only:
manage terminal traps-outputs set normal
CLI Traps
When connected to any Radware product through a serial cable, the
device generates traps when events occur. For example, if a Next Hop
Router fails, CID generates the following error:
10-01-2003 08:35:42 WARNING NextHopRouter 10.10.10.10
Is Not Responding to Ping.
Send Traps To All CLI Users

This option enables you to configure whether traps will be sent only to
the serial terminal or also to SSH and Telnet clients.
CID User Guide 2-85

Device Reporting
E-mail Notification
You can configure the device to send e-mail messages to users listed
in the device's User Table. For each user, you can set the level of
SNMP Traps notification the user receives. This is done in the Users
table; each user is assigned a level of severity and receives traps
according to that severity or higher.
The severity levels are: Info, Warning, Error and Fatal, see Web Based
Management, page 2-48. When assigned the severity level of Error, the
user receives e-mail traps of events with severity levels of Error and
Fatal. This configuration applies both for SNMP traps and for SMTP
email notifications. SMTP notifications are enabled globally for the
device.
In addition to the SNMP traps, another method of notification has been
added to the device. Using the Send E-mail on Errors option, you can
configure traps to be sent by e-mail to predefined users with different
levels of severity.
E-mail Notifications Configuration Guidelines:

From the main window, select; Options > Preferences > Traps and
SMTP.
Configuration Trace
CID is able to monitor any configuration changes on the device, and
report those changes by sending out e-mail notifications. Every time
the value of a configuration variable changes, information about all the
variables in the same MIB entry is reported to users. Configuration
reports are enabled for each user in the Users Table, see page 2-48.
Note: CID optimizes the mailing process by gathering reports and
sending them in a single notification message once the buffer is full or
once a timeout of 60 seconds expires.
The notification message contains the following details:
• Name of the MIB variable that was changed
• New value of the variable
• Time of configuration change
2-86 CID User Guide

• Configuration tool that was used (Configware, Telnet, SSH, WBM)

• User name, when applicable.
CID User Guide 2-87

Device Reporting
Syslog
Event traps can also be mirrored to a syslog server. On CID, as on all
Radware products, you can configure the appropriate information,
using the General > Preferences > Traps and SMTP option. Any traps
generated by the Radware device will be mirrored to the specified
syslog server.
The current Radware syslog mechanism enables you to define the
status and the event log server address. You can also define additional
notification criteria such as Facility and Severity, which are expressed
by numerical values. Facility indicates the type of device of the sender,
while Severity indicates the importance or impact of the reported event.
The user defined Facility value is used when the device sends Syslog
messages. The default value is 21, meaning “Local Use 6". The
Severity value is determined dynamically by the device for each
message that is sent.
2-88 CID User Guide

Event Log
Radware devices keep track of events in the event log. Its is possible to
download the event log for later analysis.
CID User Guide 2-89

Device Reporting
2-90 CID User Guide

CHAPTER 3
Basic Switching &
Chapter 3 -
Routing
Chapter 3, Basic Switching & Routing, provides theoretical
explanations about switching and routing in general, describes how
CID participates in the processes of switching and routing, and
presents several aspects of the practical implementation of CID.
• Section 3-1: Port Settings, page 3-2
• Section 3-2: Virtual LAN, page 3-8
• Section 3-3: IP Addressing & Routing, page 3-24
CID User Guide 3-1

Port Settings
Section 3-1 Port Settings

Section 3-1 Port Settings describes the CID features that assist with
traffic and port management.
• Port Mirroring, page 3-3
• Port Trunking, page 3-6
3-2 CID User Guide

Chapter 3 - Basic Switching & Routing
Port Mirroring
Port Mirroring enables the device to duplicate traffic from one physical
port on the device to another physical port on the device. This is useful
for example when an Intrusion Detection System (IDS) device is
connected to one of the ports on the CID device. You can choose to
mirror either received and transmitted traffic, received traffic only, or
transmitted traffic only. You can also decide whether to duplicate the
received broadcast packets.
Configuration Guidelines:
The Port Mirroring feature is configured as follows:
1. From the Set-Up window, select Networking > Port Mirroring.
The Port Mirroring Table window appears.
2. In the Port Mirroring window, click Add. The Edit Port Mirroring
window appears.
CID User Guide 3-3

Port Settings
3. in the Edit Port Mirroring window, set the following parameters

Input Port: The port from which the traffic is mirrored.
Output Port: The port to which traffic is mirrored.
Recieve/ Select the direction of traffic to be mirrored.
Transmit:
Promiscious Enable or disable depending on whether you
Mode: require received broadcasts packets to be
mirrored.
4. .Click Ok. Your preferences are recorded.
Note: Traffic from a port participating in a switched VLAN cannot
be mirrored, due to the switching of traffic in the ASIC.
Port Mirroring Limitations:

• Up to two output ports can be used for a single input port.
• Currently Port Mirroring is supported for Fast Ethernet ports only.
• The mirroring input port cannot be part of a Switched VLAN.
• A port that participates in Port Mirroring as an Output Port, cannot
be part of a VLAN (Regular or Switched) or have an IP address.
• The Input Port, from which traffic is mirrored, must be an interface
with a configured IP address, or an interface, which is part of a
VLAN (Regular or Switched) with a configured IP address.
• The Mirrored Port, to which the traffic is mirrored, must not have an
IP address, or be part of a VLAN (Regular or Switched) with a
configured IP address.
Port Mirroring Notes:

The following notes apply to all Application Switching platforms.
• It is possible to copy traffic from one Input Port to multiple Output
Ports, or from many Input Ports to one Output Port.
• Traffic generated by the device itself such as connectivity checks or
management traffic, is not mirrored.
• Regular VLAN traffic with destination multicast MAC is not always
mirrored.
3-4 CID User Guide

• When mirroring traffic from a port which is a part of Switched VLAN,

traffic between hosts on this VLAN is switched by the ASICs of the
device. This type of traffic is not mirrored.
• When mirroring traffic is received on a port which is a part of
Switched VLAN, and the mirrored port is configured to mirror
Receive Broadcast packets, these packets are mirrored from all
ports on the Switched VLAN.
CID User Guide 3-5

Port Settings
Port Trunking
Port Trunking (also known as Link Aggregration) is a method of
increasing bandwidth by combining physical network links into a single
logical link. Link aggregation increases the capacity and availability of
the communications channel between devices - both switches and end
stations - by using the Fast Ethernet and Gigabit Ethernet technology.
Multiple parallel physical links between two devices can be grouped
together to form a single logical link. Link aggregation also provides
load balancing where processing and communications activities are
distributed across several links in a trunk, to prevent single link
overloading. Treating multiple LAN connections as one aggregated
link, ensures the following advantages:
• Higher link availability
• Increased link capacity
• Improvements in existing hardware
No upgrading to higher-capacity link technology is necessary.
Radware devices support port trunking according to the IEEE 802.3ad
standard for link aggregation. Link Aggregation is supported on:
• Links using the IEEE 802.3 MAC
• Point-to-point links
• Links operating in full duplex mode
Aggregation is permitted only among links with same speed and
direction. On Radware devices, bandwidth increments are provided in
units of 100Mbps and 1Gbps respectively.
MAC Client traffic can be distributed across multiple links. To guarantee
the correct ordering of frames at the receiving-end station, all frames
belonging to one conversation must be transmitted through the same
physical link. The algorithm for assigning frames to a conversation
depends on the application environment. Radware devices can define
conversations upon Layer 2, 3 or 4 information, or on combined Layers.
The failure or replacement of a single link within a Link Aggregation
Group does not cause failure from the perspective of a MAC client.
Radware port trunking function allows you to define up to eight trunks.
Up to eight physical links can be aggregated into one trunk. All trunk
configuration is Static.
3-6 CID User Guide

In port trunking configuration, the port speed and duplex must be fixed
and must not be in the Auto Negotiation mode.
Port Trunking Configuration Guidelines

1. From main window, double click the CID icon. The Set-Up window
appears.
1. From the Set-Up window, select Networking > Link Aggregation.
The CID Link Aggregation window opens.
2. Select Hashing for Layers 2, 3 and 4.
3. From the Trunks Table, select the trunk and click Edit. The Edit
Link Aggregation window opens.
4. Assign (link) ports to the selected trunk by checking in the Trunk
index column for the port.
5. Click Ok to apply the changes.
6. From the Link Aggregation window, click Apply and Ok to exit the
window.
7. Create the interface for the new trunk, by defining the IP address
for the trunk.
CID User Guide 3-7

Virtual LAN
Section 3-2 Virtual LAN

Section 3-2 Virtual LAN, explains the types of virtual LAN networks,
their functionality and configuration in CID.
• What is a Virtual LAN?, page 3-9
• CID VLAN Types, page 3-10
• VLAN Configuration, page 3-12
• VLAN Auto Learn, page 3-16
• VLAN Tagging Support, page 3-18
• Redundancy, page 3-22
• Bridging, page 3-23
3-8 CID User Guide

What is a Virtual LAN?

A Virtual LAN (VLAN) is a group of devices that share the same
broadcast domain within a switched network. Broadcast domains
describe the extent that a network propagates a broadcast frame
generated by a device.
Some switches may be configured to support single or multiple VLANs.
When a switch supports multiple VLANs, the broadcast domains are
not shared between the VLANs.
• The device learns the Layer 2 addresses on every VLAN port.
• Known unicast frames are forwarded to the relevant port.
• Unknown unicast frames and broadcast frames are forwarded to
all ports.
CID User Guide 3-9

Virtual LAN
CID VLAN Types

CID VLAN provides bridging functionality among ports assigned to the
same VLAN. CID supports the following types of VLANs:
• Regular VLAN
• Switched VLAN
Regular VLAN
A Regular type VLAN can be described as an IP Bridge (a software
bridge) between multiple ports that incorporate all the traffic redirection
of the passing traffic at all layers (Layer 2-Layer 7). Two Protocols can
be used with Regular VLANs:
IP Protocol: The VLAN must be assigned an IP address. All of the
traffic between the ports is intercepted transparently by the CID
application. Packets that need intelligent intervention are checked and
modified by CID and then forwarded to the relevant port. Other packets
are simply switched by CID as if they were on the same wire.
Other Protocol: A VLAN with the protocol "Other" cannot be assigned
an IP address. This type of VLAN is used to bridge the non-IP traffic
through CID. Note that this option can be defined also with the
Switched type VLAN (Switched VLAN protocol) for wire-speed
performance.
Switched VLAN
Switched VLAN provides wire-speed VLAN capabilities implemented
through the hardware switch fabric of the CID device. Depending on
the Protocol defined for the Switched VLAN, frames are treated
accordingly:
Switched VLAN Protocol: Frames arriving at VLAN port are switched
according to Layer 2 information. CID application does not intercept
any traffic.
IP Protocol: Frames arriving at VLAN port are switched according to
Layer 2 information, except for frames with Layer 2 address same as
3-10 CID User Guide

CID port Layer 2 address. Frames with CID Layer 2 destination are
processed by the CID application and then forwarded accordingly.
CID User Guide 3-11

Virtual LAN
VLAN Configuration
In Figure 3-1, CID is configured with two VLANs: Network side VLAN
(with address 100003) and user side VLAN (address 100005). Both
VLANs are defined as Switched type, to gain wire-speed throughput.
To enable CID to perform Traffic Redirection policies on traffic destined
to the Internet, VLAN protocol is set to IP. This requires clients to
configure CID as their default router.
Network
Side VLAN
100003
Internet
Router Server
192.1.1.100 192.1.1.11
P1 P2
CID User Side

VLAN
P3 P4 100005
Client Client
193.1.1.1 193.1.1.2
Figure 3-1 Transparent CIDs in VLAN
3-12 CID User Guide

VLAN Definitions in CID:

Interface Number Protocol VLAN Type
100003 IP Switched
100005 IP Switched
To create a VLAN:
1. From the Set-Up window, select Networking > VLAN. The CID
Virtual LAN window appears.
2. To connect a physical port on the device to the VLAN you are
defining, select one of the checkboxes in the Assign Port to
VLAN pane.
3. Set the remaining parameters according to the explanations
provided:
Interface The interface number of the VLAN,
Number: automatically assigned by the management
station.
Type: Select the bridge type.
Regular: The device acts as a bridge.
Switch: The Switch type is a Layer 2 VLAN.
Switched VLAN can be stand-alone or part of
a Regular VLAN.
Protocol: Select the protocol for the VLAN, according to
the VLAN Type: IP or Switch VLAN.
Note: Otherwise the protocol is IP or Other.
4. Click Add. The new VLAN is listed in the CID Virtual LAN table.
Tip: At any stage you can edit any of these parameters (for example
change the protocol) and click Update to apply the new setup.
Note: CID supports 64 VLAN‘s however an IP address can only be

assigned to 36 VLAN‘s only.
CID User Guide 3-13

Virtual LAN
To configure VLAN Parameters:

1. From Set-Up window select Networking > VLAN. The CID Virtual
LAN window appears.
2. From the CID Virtual LAN window, click Parameters. The
Parameters pane appears.
3. From the Parameters pane set the following parameters
IP VLAN Auto Check to enable this function. CID
Config: automatically detects and adds physical ports
to existing IP VLANs according to the incoming
IP broadcasts and ARP requests.
801.1q Check to enable this function, if you want the
Environment environment to support VLAN tagging.
VLAN Check to enable the policy in order to return
Forwarding packets from server to client according to
Policy: Layer 3 information. When this policy is not
enabled, packets are returned according to
Layer 2 information. See page 3-17.
Note: Layer 2 information supports transparent
configuration within the network.
VLAN Tag Choose whether to retain or overwrite.
Handling
Auto Config Define this parameter when using the VLAN
Aging Time: Auto Config option.
Range:10 -3600 seconds. Default: 3600.
Ethernet Type: Define the Ethernet type for user defined
VLANs.
Ethernet Type Define the mask on Ethernet type for user
Mask: defined VLANs.
Bridge Type the MAC Address to be used by CID.
Address:
Bridge Type: Define the type of bridging to perform.
Default: Transparent-only
3-14 CID User Guide

Bridge Define the Aging Time, that is the period for the
Forwarding unused entries to be retained in the
Table Aging Forwarding Table.
Time:
Note: This counter is reset each time the entry
is used. When the defined Aging Time expires,
unused entries are deleted from the table.
Range (in seconds): 10-3600. Default: 3600.
4. Click Apply to save the setup and click Ok to close the window.
Note: In the Bridge Set-Up tab of the CID Virtual LAN window, you
can monitor, add and edit the bridge forwarding nodes. Refer to
Bridging, page 3-23.
CID User Guide 3-15

Virtual LAN
VLAN Auto Learn

Configuring CID with VLANs is useful for the transparent CID
installation. The common configuration is to connect CID in VLAN
mode as a bridge. Although this is a transparent installation, static
routes must be defined on CID to accommodate networks with multiple
subnets, such as networks of large organizations or ISPs where each
subnet has its own access router, all routers connect to a central point,
typically the Internet access router.
CID supports the ability to learn the MAC addresses of the approaching
clients. When a new client is treated by CID (either if the client
approached the Farm IP, or was intercepted by CID), CID learns the
source MAC address of the client's request, thus allowing CID to send
all server's responses (answers) to that client, using the learned MAC
as the destination MAC address in the response packet.
This ability eliminates the need for configuration and maintenance of
each network in the CID's Routing Table, and leaves the CID operation
transparent to the network structure and to the network topology
modifications that may take place.
Note: For the “Auto Learn” mechanism to operate correctly, a default
gateway (Next Hop Router) must be defined on all servers and clients.
VLAN Auto Learn Configuration Guidelines:

The VLAN Auto Learn requires no user configuration and is active
when a VLAN is defined.
3-16 CID User Guide

VLAN Forwarding Policy for Layer 2 and Layer 3

When VLAN is enabled, CID forwards the client’s traffic and redirects it
to selected servers according to the Layer 2 addresses, thus
supporting transparent configuration within the network. When a packet
is returned from a server to a client, CID can forward the packet
according to Layer 2 information or according to Layer 3 information.
You can define the return policy of the packet by selecting the VLAN
Forwarding Policy checkbox in the CID Virtual LAN Parameters
window.
• Layer 2: Requires no user configuration but requires clients and
servers to define an NHR. Layer 2 is the default policy and returns
the packets based on the client MAC address.
• Layer 3: CID returns the packet based on the client IP address.
When configuring a VLAN with a Forwarding Policy set to Layer 3,
you must add static routing entries to the Routing Table, see
Setting up the Routing Table, page 3-27.
To enable a VLAN Forwarding Policy:

7. From the Parameters pane check VLAN Forwarding Policy and
click Ok. The forwarding policy is now enabled.
8. Reboot the system to apply the policy.
CID User Guide 3-17

Virtual LAN
VLAN Tagging Support

VLAN Tagging is an IEEE standard (802.1q) for supporting multiple
VLANs associated with the same switch port. Each VLAN is tagged
with a unique identifier to allow the identification of different VLANs
traffic on the same physical port.
VLAN Tagging provides an indication in the Layer 2 header by which
the switch decides through which port to connect to the VLAN on the
other switch. When two VLANs are configured across two different
switches, usually there is a connection between each of the VLANs on
one switch, to the corresponding VLAN on a second switch. This is
done by a single cable connecting the two switches. The ports that
inter-connect the switches, for example port 10 on each, belong to all of
the VLANs on that switch. In this case, the switch needs to know to
which VLAN to send traffic coming from port 10, as this port belongs to
all the VLANs.
VLAN Tagging (802.1q Environment) support can be used with CID,
where CID is connected to multiple VLANs on the same switch, and
different cache servers are assigned to different VLANs.
Each VLAN is tagged with a unique tag to allow the identification of
different VLAN traffic on the same physical port.
The tagging support is based on the local subnet to which the traffic is
sent; therefore packets cannot be tagged by the destination subnet if it
is not local to the CID. The switch connected to the CID must be
configured consistently with the CID tagging configuration.
Each IP interface has a VLAN tag associated with it.
CID recognizes an IP interface as a physical port/IP address
combination.
3-18 CID User Guide

Example - VLAN Tagging

In Figure 3-2, tag 101 is associated to IP interfaces 1 & 3 and tag 102 is
associated to IP Interfaces 2 & 4. This guarantees that hosts on VLAN
10.1.1.1 do not see any traffic destined to VLAN 20.1.1.0 even if a
destination MAC address is a broadcast address.
Clients Clients
P1 P2
VLAN CID VLAN

10.1.1.0 20.1.1.0
P3 P4
Clients Clients
Figure 3-2 VLAN Tagging Example

P1: 10.1.1.1 Tag: 101
P2: 20.1.1.1. Tag: 102
P3: 10.1.1.2 Tag: 101
P4: 20.1.1.2 Tag:102
CID User Guide 3-19

Virtual LAN
All the packets sent to any destination host on a tag-configured IP

interface carry the VLAN tag, including:
• All health checking packets from the CID to the cache servers.
• ARP requests and responses from the CID to the cache servers.
• Unicast ARPs between redundant CIDs.
• Gratuitous ARPs, which are part of the redundancy mechanism.
If an IP interface does not have a VLAN tag configured, packets are
sent without a tag (standard Layer 2 MAC header). The permissible
VLAN IDs to be configured on a CID range from 1 to 4063.
Note: The CID automatically sets the 802.1p prioritization portion of the
tag (the first 3 bits) to 000.
To add a VLAN Tag to a network:

1. From the Set-Up window, click Add. The Interface window
appears.
2. In the Interface window, set the following parameters according to
If Num: The number of the interface.
IP Address: The IP address of the interface.
Network Mask: The associated subnet mask.
Broadcast From the dropdown list select either:
Type: ZEROFILL - indicates a broadcast address
filled with zeros.
ONEFILL - indicates a broadcast address filled
with ones.
Forward Whether the device forwards incoming
Broadcast: broadcasts to this interface.
VLAN Tag: When multiple VLANs are associated with the
same switch port, the switch needs to identify
to which VLAN to direct incoming traffic from
that specific port. VLAN tagging provides an
indication in the Layer 2 header that enables
the switch to make the correct decision. Type
the Tag to be associated with this IP Interface.
3-20 CID User Guide

3. Click Ok to exit all windows.

CID allows preserving existing VLAN Tags on incoming traffic that
passes through the device. Configuration of this feature is done in the
VLAN Tagging window from the Device menu.
To retain the existing VLAN Tags:

1. From the Set-Up window select Networking > VLAN. The CID
3. From the Parameters pane, set the following parameters according
802.1q Set this value to Enabled.
Environment:
Default?
VLAN Tag Set this value to Retain.
Handling:
Retain: The device preserves the existing
VLAN tags on the incoming traffic. Traffic
generated by the device is tagged
according to the IP Interface configuration.
Overwrite: The device performs VLAN
Tagging of the outgoing traffic according to
the IP Interface configuration.
CID sets tags for packets according to the
following parameters: destination IP of the
packet in case it is on the same local
subnet with CID, OR MAC address of the
firewall that is configured on CID and
through which the packet is sent.
Default: Overwrite
4. Click Ok to save the setup and exit the window.
Note: In case a packet arrives without a VLAN tag, CID sets a tag
according to destination local subnet or server.
CID User Guide 3-21

Virtual LAN
Redundancy
When working with VLANs, two CIDs can operate together, one
backing up the other. A special provision in the CID prevents the
occurrence of network-bridging loop. The CID can transparently
intercept traffic not destined to its MAC address through the
configuration of VLANs.
For further information on Redundancy configurations,
refer to Chapter 6, Redundancy.
3-22 CID User Guide

Bridging
When a VLAN is defined, CID performs bridging among interfaces
assigned to the same VLAN. Bridging within a VLAN means that CID
learns the MAC addresses of frames arriving from each physical
interface, and maintains a list of MAC addresses per interface. When a
frame arrives from one interface, CID looks for the frame destination
addresses within its address list according to the following conditions:
• If the destination address is listed in the same interface of the
source address, CID discards the frame.
• If the destination address is listed in another interface, CID
forwards the frame to the relevant interface.
• If the address is not listed in any interface, CID broadcast the frame
to all interfaces participating the VLAN.
CID enables you to modify the Address lists by registering additional
MAC addresses per interface. This is done from the Bridge Set-Up
menu.
To add a MAC address to a port:

2. From the CID Virtual LAN window, click the Bridge Set-up tab,
select the relevant port to which you wish to add a MAC address
and click Add.The Edit Global Forwarding Table window appears.
3. From the Edit Global Forwarding Table window, set the following
MAC address: Type in the relevant MAC address for
the port.
Port: Select the port.
Status: Define the status for the port:
Permanent or Delete On Reset
4. Click Apply, then Ok.
5. what next?
CID User Guide 3-23

IP Addressing & Routing
Section 3-3 IP Addressing & Routing

Section 3-3 IP Addressing & Routing deals with the configuration of
VLAN addressing and routing.
• IP Addressing, page 3-25
• Routing, page 3-26
• Alternate Default Gateway, page 3-28
• Routing Information Protocol, page 3-29
• Open Shortest Path First, page 3-32
3-24 CID User Guide

IP Addressing
IP addresses are 32-bit binary numbers, for example:
11000000101010000000000100010100.
Each 32-bit IP address consists of two sub-addresses, one identifying
the network and the other identifying the host to the network, with an
imaginary boundary separating the two.
The location of the boundary between the network and host portions of
an IP address is determined through the use of a subnet mask. A
subnet mask is another 32-bit binary number that acts like a filter when
it is applied to the 32-bit IP address. By comparing a subnet mask with
an IP address, systems can determine which portion of the IP address
relates to the network, and which portion relates to the host.
• Anywhere the subnet mask has a bit set to "1", the underlying bit in
the IP address is part of the network address.
• Anywhere the subnet mask is set to "0", the related bit in the IP
address is part of the host address.
Setting Up Interface IP Addresses

You can set up the IP addresses for CID interfaces using the main
Setup window. You are required to assign an IP address and IP
Network Mask for each defined interface.
CID performs routing between the all defined IP interfaces.
CID User Guide 3-25

Routing
Routing is the CIDs ability to forward IP packets to their destination
using an IP Routing Table. The IP Routing Table stores information
about destinations and how they can be reached. By default, all
networks directly attached to CID are registered in the IP Routing
Table. Other entries to the table can either be statically configured by
users or dynamically created through a routing protocol. When CID
forwards an IP packet, the IP Routing Table is the resource for
establishing the next-hop IP address and the next-hop interface.
• For a direct delivery, when the destination is a neighboring node,
the next-hop MAC address is the destination MAC address for the
IP packet.
• For an indirect delivery, when the destination is not a neighboring
node, the next-hop MAC address is the address of an IP router
according to the IP Routing Table.
The destination IP address does not change on the path from source to
destination. The destination MAC (Layer 2 information) is manipulated
to move a packet across networks and then the MAC of the destination
host is applied when the packet arrives on the destination network.
Compliance Notes
CID support for IP routing is compliant with the RFC1812 router
requirements. Dynamic addition and deletion of IP interfaces is also
supported. This ensures that extremely low latency is maintained.
The IP router supports RIP I, RIP II and OSPF routing protocols. OSPF
is an intra-domain IP routing protocol, intended to replace RIP in bigger
or more complex networks. OSPF and its MIB are supported as
specified in RFC 1583 and RFC 1850, with some limitations.
3-26 CID User Guide

Setting up the Routing Table

The Routing Table allows you to configure routing and to define the
default gateway.
To configure routing:
6. From the Set-Up window, select Networking > Routing
Table.The CID Routing Table window appears.
7. Click Add. The Edit Route window appears.
8. From the Edit Route window, set the following parameters
Destination IP The destination IP address for the route.
Address:
Network The network mask of the destination subnet
Mask: (IP).
Next Hop: The IP address of the next hop towards that
destination subnet. The next hop must reside
on a subnet which is local to the device.
IF Number: The IF (interface) Index number of the local
interface or VLAN through which the next hop of
this route is reached.
Metric: Number of hops to the destination network.
Type: Define how remote routing is handled,
Values: Remote (Forwards packets); Reject
(Discards packets); Local (read-only).
Default: Remote
9. Click Ok to close all the windows.
To configure a default gateway:

1. Follow steps 1-2 as explained above.
2. From the Edit Route table (see step 4 above), type the relevant
value for the Next Hop parameter. Destination IP Address and
Network Mask remain at default values (0.0.0.0).
3. To close all the windows, click Ok.
CID User Guide 3-27

Alternate Default Gateway

CID enables you to define up to 15 default gateways on the device,
providing high availability between the default gateways. Each default
gateway may be checked using the Health Monitoring module. By
using the Health Monitoring Binding Table it is possible to bind the
health checks to the configured Alternate Default Gateways. To bind a
new health check to an alternate default gateway, first define the
required health check using the Health Monitoring Check Table and
then using the Binding Table bind the check to the relevant default
gateway. All configured alternate default gateways appear in the
Binding Table's Server dropdown list.
Note: CID supports binding health checks only to the newly configured
alternate default gateways, meaning that after an upgrade from a lower
version, if it is required to bind a health check to the already existing
default gateway, the check must be deleted and then reconfigured.
For further information on Health Checks and Binding, refer to
Chapter 7, Health Monitoring.
To configure an alternate default gateway:

4. From the Set-Up window, select Networking > Routing
Table.The CID Routing Table appears.
5. Click Add. The Edit Route table appears, where you can add a
new default gateway and add a value for Next Hop.
7. From the main window, click Health Monitoring. The CID Health
Checks window appears.
8. Click Add. The Edit Active Health Check window appears.
9. From the Edit Active Health Check window, set the following
Check Element: Select the new default gateway.
Health Check Name: Define the name of the health check.
3-28 CID User Guide

Routing Information Protocol

Routing Information Protocol (RIP) is a commonly-used protocol for
managing router information within a self-contained network such as a
corporate local area network or an interconnected group of such LANs.
RIP is classified by the Internet Engineering Task Force (IETF) as one
of several internal gateway protocols (Interior Gateway Protocol). RIP
is intended for small homogeneous networks.
Using RIP, a gateway host (with a router) sends its entire routing table,
which lists all the other hosts that it recognizes to its closest neighbor
host every 30 seconds. The neighbor host then passes the information
on to its next available neighbor and so on until all hosts within the
network have the same knowledge of routing paths. This is known as
network convergence. RIP uses a hop count as means to determine
network distance. Other protocols use more sophisticated algorithms
including timing. Each host with a router in the network uses the routing
table information to determine the next host to route a packet to a
specified destination.
CID supports RIP versions 1 and 2.
To configure RIP:
1. From the Set-Up window, select Networking > RIP. The CID RIP
2. From the CID RIP Parameters window, set the following
Leak OSPF Controls redistribution of routes from OSPF to
Routes: RIP. When enabled, all routes learned through
(checkbox) OSPF are advertised into RIP.
Note: For information about OSPF, refer to a
description on page 3-32.
Leak Static Controls redistribution of routes from static
Routes: routes to RIP. When enabled, you define all the
(checkbox) static routes in the Routing Table.
Enable RIP: Check to enable this protocol.
(checkbox)
3. Click Edit. In the CID Edit RIP window that appears.
CID User Guide 3-29

4. From the CID Edit RIP window, set the following parameters
IP Address: The IP address of the current interface.
(read-only)
Outgoing RIP: Select the type of RIP to be sent:
• RIP Version 1: Sends RIP updates
compliant with RFC 1058.
• RIP Version 2: Multicasts RIP-2
updates.
• Do Not Send: No RIP updates are sent.
Default: RIP Version 1
Incoming RIP: Select the type of RIP to be received:
• RIP 1: Accepting RIP 1.
• RIP 2: Accepting RIP 2.
• Do Not Receive: No RIP updates are
accepted.
Default Metric: Select the Metric for the default route entry in
RIP updates, originated on this interface.
Default: 0.
Note: 0 (Zero) indicates that no default route
must be originated; in this case, a default
route through another router may be
propagated.
Virtual Distance: Define the virtual number of hops assigned
to the interface. This enables fine-tuning of
the RIP routing algorithm.
Default: 1
Status: Define the status of the RIP in the router.
Values: Valid; Invalid. Default: Valid.
3-30 CID User Guide

Auto Send: Enable (check) this option to minimize

network traffic when CID is the only router on
the network.
Note: When this option is enabled, the
device advertises RIP messages with the
default metric only. This allows some
stations to learn the default router address.
If the device detects another RIP message,
Auto Send is disabled.
CID User Guide 3-31

Open Shortest Path First

The Open Shortest Path First (OSPF) protocol was developed for IP
networks and based on the shortest path first or link-state algorithm for
interior gateway routing.
With OSPF you can build a more stable network, because fast
convergence prevents such problems as routing loops and Count-to-
Infinity (when routers continuously increment the hop count to a
particular network).
Routers use link-state algorithms to send information to all access
nodes in a network by calculating the shortest path to each node based
on the Internet topography. After sending the routing information, each
router sends the portion of the Routing Table (keeping track of routers
to particular network destinations) that describes the state of its own
links.
The OSPF algorithms allow more frequent updates, but require a lot of
CPU power and memory.
3-32 CID User Guide

CHAPTER 4
Basic Application
Chapter 4 -
Switching
Chapter 4, Basic Application Switching, describes the farm and server
management concepts and the related features. This chapter also
provides examples of common configurations of application switching
and load balancing schemes as implemented in Content Inspection
Director (CID).
This chapter includes the following main sections:
• Section 4-1: Farm Management, page 4-2
• Section 4-2: Server Management, page 4-25
• Section 4-3: Server Load Balancing, page 4-36
• Section 4-4: Cache Load Balancing, page 4-53
• Section 4-5: Local Triangulation, page 4-77
• Section 4-6: Server Spoofing, page 4-86
• Section 4-7: Network Address Translation, page 4-88
CID User Guide 4-1

Farm Management
Section 4-1 Farm Management

Section 4-1, Farm Management, describes the farm-related CID
features designed to maximize utilization of the existing network
resources when providing various services.
• Farm Management Overview, page 4-3
• Configuring Dispatch Methods, page 4-20
• Dispatch Methods, page 4-7
• URL Table and Parameters, page 4-11
• Static URL Table, page 4-14
• Configuring Farms, page 4-16
• Configuring Client Table, page 4-37
• Configuring Dispatch Methods, page 4-20
• Configuring Content Based Rules, page 4-21
4-2 CID User Guide

Chapter 4 - Basic Application Switching
Farm Management Overview

CID is designed to load balance Content servers, such as cache
servers, anti-virus servers or URL filters. Traffic is distributed within a
group of heterogeneous content servers. CID transparently intercepts
the Internet-bound user traffic and intelligently load balances the traffic
among the content servers that operate transparently or non-
transparently. As a result, users do not need browser configurations
that point them to a proxy server. In addition, CID also provides Virtual
IP addresses for the content farms, to facilitate users who need to
operate non-transparently.
CID operation is based on three main components bound together into
a Farm Policy: Farm, Network and Service.
Figure 4-1 illustrates this model.
Service
Network
Farm
Figure 4-1 Farm Policy Components

Farm: A group of servers that provide the same service. Servers are
grouped in farms according to the type of service that they provide - for
each service you can define a farm on CID. When a new request for
service arrives, CID identifies the required service and selects the most
available server within the farm that provides this service. In that
manner CID optimizes the server operation and improves the overall
quality of service.
Each CID farm is identified by its VIP (Virtual IP Address). This address
is used by configured clients to approach the farm. Each server within a
CID farm is recognized by its IP address. That IP address can be
CID User Guide 4-3

Farm Management
hidden from the clients, making the process of server selection

transparent for the users.
A Farm definition includes server farm functions such as load balancing
scheme for client-server persistency, content based rule for server-site
persistency, connectivity check methods and more.
Network: A range of network IP addresses.
Service: An application that can be a TCP or a UDP port number, or a
complex service that combines several basic services.
CID enables users to build a Farm Policy based on a rule that
combines these components. For example, a rule that takes into
consideration client traffic that arrives from (or is destined to) a certain
network, is identified by the defined Service, and then is redirected to a
Farm for packet or session treatment.
4-4 CID User Guide

Packet Treatment Basics

To benefit from the powerful engine that classifies each and every
packet arriving at CID, you need to create an appropriate policy for CID
decisions. Two types of policies are used:
• Farm based policy is used in a single farm network configuration.
• Cluster based policy is used in a network configuration that uses
multiple farms.
Each policy contains information about the source network (or a single
IP), destination network (or a single IP) and service. The service can
consist of a basic filter, a filter group or an advanced filter.
Basic filter: Specifies the application (for example, the TCP
destination port 80, or the UDP source ports 100 -200).
Filter group: A collection of basic filters with a logical OR condition.
You can use this service to create a group of applications that you want
to send to the same farm.
Advanced filter: A collection of basic filters with a logical AND
condition.
When a packet arrives, CID first checks whether the incoming packet
should be treated, or whether it can be forwarded to the next hop router
(NHR). When one of the following two conditions is met, CID treats the
packets:
• The packet’s destination IP is the address of one of the CID farms -
this indicates that the client is a configured client.
• There is a match between the packet's information (source IP,
destination IP and application) and a predefined policy on CID.
If neither condition is met, CID routes (forwards) the packet according
to the packet’s Routing Table information.
CID User Guide 4-5

Farm Management
Farm Related Features

CID provides a wide range of features to assist you to effectively build
both basic and complex network configurations and redirection
schemes. All features are farm-associated, enabling a fast and easy
configuration, including:
• Content Based Policies, such as URL Match, HTTP Match, Token
Match. Defined by the Match Method parameter.
• Content Servers Definitions.
See "Client Table Management" on page 4-37.
• Network Address Translation.
See "Network Address Translation" on page 4-88.
• URL Policies.
See "Static URL Table" on page 4-14.
• Preferred Sites.
See "Static URL Table" on page 4-14.
Farm Based Policy

A farm based policy binds a farm to a network and a service.
Configuring a farm policy involves the following steps:
1. Define a network.
2. Define a service (define a new service or select an existing
service).
3. Define a farm and assign servers to the farm.
4. Set a farm policy.
4-6 CID User Guide

Dispatch Methods
Dispatch Methods are the load balancing algorithms that determine
how the client requests are distributed between servers in the farm.
CID receives requests for service from clients and decides to which
server to direct each request. During this process, CID finds the best
server to provide the requested service. The criteria by which CID
selects the best server are defined by the Dispatch Method.
Dispatch Methods are defined only for new sessions. Existing sessions
are handled by the Client Table, see
You can define the Dispatch Method during the process of CID Farm
configuration, according to farm characteristics and users’ needs.
Criteria may vary for different applications. For example, the number of
users is a significant factor for a Web farm, while the amount of traffic
can be more important for an FTP farm.
The following Dispatch Methods are available on CID:
• Cyclic
• Fewest Number of Users
• Fewest Number of Users - Local
• Least Amount of Traffic
• Least Amount of Traffic - Local
• NT- 1
• NT- 2
• Private - 1
• Private - 2
• Destination Hashing
• Source Hashing
• HM Load Statistics
• WCCP
CID User Guide 4-7

Farm Management
Cyclic. When the Cyclic Dispatch Method is defined, CID forwards

the traffic dynamically to each server in a round-robin fashion.
Least Amount of Traffic. Directs traffic dynamically to the server
with the least traffic. A new request for service that is sent to CID is
directed to the server with the least amount of traffic at that given time.
The amount of traffic is defined as packets per second (pps) from CID
to the server and from the server to CID (back to the client), as is
recorded in CID Client Table for all traffic forwarded to that server.
Note: The session number is defined by the active Client Table entries
to this server.
Fewest Number of Users. Directs traffic dynamically to the server
with the least number of users.
Least Amount of Traffic - Local. Directs users to the server with
the least traffic which includes the locally configured farm. Users of
other farms are not considered. This Method can be used when same
servers participate in multiple farms. When this Method is selected, CID
looks for the server with least amount of traffic only within the farm that
is currently addressed by the client. Traffic of other farms is not
considered.
For example: Server 1 and Server 2 provide service A and service B.
These servers are used as part of Farm A to provide service A and as
part of Farm B to provide service B. When the client's request for
service A is sent to Farm A, which uses this Dispatch Method, CID
considers only the traffic that is related to service A. The traffic that is
related to service B on the same servers is not considered by CID. CID
looks for a server with the least amount of traffic related to service A,
and forwards client's request to this server.
Fewest Number of Users - Local. Directs users to the server
with the fewest users that includes the locally configured farm. Users of
other farms are not considered. This method can be used when the
same servers participate in multiple farms. When this method is
selected, CID looks for the server with fewest number of users only,
within the farm that is currently addressed by the client. Traffic of other
farms is not considered.
4-8 CID User Guide

For example, Server 1 & Server 2 can provide service A and service B.
These servers are used as part of Farm A to provide service A and as
part of Farm B to provide service B. When the client’s request for
service A is sent to Farm A, which uses this Dispatch Method, CID
looks for a server with the fewest number of requests for service A. The
requests for service B that exist on the same servers are not
considered by CID.
NT- 1 and NT-2. When either method is selected, CID queries the
farm servers for Windows NT SNMP statistics. CID forwards the farm’s
clients to the least busy server according to the servers’ reported
statistics. You can select from a list of statistics. The parameters are
considered according to the weights that you define in the first
Windows NT weights scheme for the NT-1, and second Windows NT
weights scheme for the NT-2.
Note: To use these Dispatch Methods, you need to configure the
Windows NT scheme and set the weight of the statistics parameters.
For configuration guidelines, see page 4-20.
Private - 1 and Private - 2. CID queries the farms’ servers for
private SNMP parameters, as defined in the first private weights
scheme. The ratios of users on the servers is balanced according to
the statistics.
When either mentod is selected, CID queries the farm’s servers for
private SNMP parameters according to a predefined private weights
scheme. The ratios of sessions on the servers is balanced according to
the statistics. You need to define which MIB variables are queried and
to set the private weights scheme. The parameters are considered
according to the weights that you define in the first private weights
scheme for the Private-1 and second private weights scheme for the
Private-2.
Note: To use these Dispatch Methods, you need to configure the
Private scheme and set the weight of the statistics parameters. For
configuration guidelines, see page 4-20.
Destination Hashing. CID uses a deterministic algorithm to
convert the URL or IP address of the site to a numerical value, which is
assigned to a specific cache server. This method is uncommon and can
be used when there are several customers sharing the same cache
CID User Guide 4-9

Farm Management
server farm (POP), and it is required to maintain a URL requested by

two clients, each of a different customer, on only one cache.
Source Hashing. Enables sticky connection. CID uses a
deterministic algorithm to convert the client IP address to a numerical
value, which is assigned to a specific cache server. In this method, the
client is always directed to the same cache server if it is available.
When the Hashing Dispatch Method is applied, CID selects a server for
a session using a static Hash function. Using this method enables CID
to repeatedly direct requests from the same client to the same server
within a farm. This Dispatch Method also provides support for reverse
proxy Web farms, avoiding data replication among the proxy servers.
A static Hash function enables CID to choose the server for a session
on the basis of the session’s information. The input for the Hash
function is usually the Client IP only. A formula is applied to this IP
address. The output that is received, is a numeric value.
Hashing provides persistency on the basis of the client IP address. For
each request from the same client, CID applies the same formula and
receives the same output number. This ensures that the same server
within the farm is selected for all requests from the same client IP.
When Layer 7 policies are used, Hashing ensures that all requests for
the same host name are sent to the same server. For Reverse Proxy
support this is done by using Hashing of the URL requested by the
client.
HM Load Statistics. Enables Response Time load balancing. This
method load balances the servers in the farm based on the least
loaded server as calculated by the Response Level.
WCCP. WCCP (Web Cache Coordination Protocol) specifies
interactions between Cisco routers and Web caches to establish and
maintain the transparent redirection of selected types of traffic flowing
through a group of routers. This method aims to optimize the resource
usage and lower the response times.
For more information on this feature, see Enhanced Cache
Coordination, page 4-76.
4-10 CID User Guide

URL Table and Parameters

When a request for a Web page is handled by CID, the requested URL
is entered in the URL Table. The URL entries allow CID to keep track of
the cache servers storing the cached pages. The ability to monitor the
requested URLs helps optimize the device performance by ensuring
that requests are referred to the same cache server that already stores
the information, instead of having another cache server fetch the
information from a distant Web server. In addition, the URL Table
prevents the duplication of information on several cache servers,
effectively keeping the server-site persistency.
Note: In some cases the CID does not need to use the URL Table, for
example, when performing anti-virus load balancing.
The URL Table presents three usage modes:
• Use URL Table: Select this option when caching is required and
previous site cached data is needed which leads to better response
time. This option should also be selected when URL policies are in
use.
• Do Not Use URL Table: While previous visits to sites are irrelevant
or while supporting sticky sessions such as sticky chat and
distribution hashing.
• Static Entries: The device forwards clients to the server if the
entries are listed in the URL Table; otherwise the device forwards
clients to the Internet (limited to transparent clients). This option
should also be selected when reverse caching is required.
For setting up the URL Handling options, refer to page 4-17.
CID User Guide 4-11

Farm Management
Table 4-1 shows an example of a CID URL Table.
Table 4-1 CID URL Table Example
Requested Requested Server Type Last Number

URL Address Address Activity of
Time Hits
www.site.com 130.0.0.1 Dynamic 23 2
www.cnn.com 130.0.0.1 Dynamic 33 4
www.radware.com 130.0.0.2 Dynamic 12
Figure 4-2 illustrates the server direction configuration based on the

URL Table information.
Clients
www.site.com
CID
192.0.0.5
www.cnn.com
192.0.0.8 www.radware.com
Server 1 Server 2
130.0.0.1 130.0.0.2
192.0.0.20
Farm
1.1.1.1
Figure 4-2 URL Table Based Server Direction Configuration
4-12 CID User Guide

The URL Table can operate in various modes according to the Content
Based Rule. Selection of the Content Based Rule depends on these
network configuration parameters:
• Address
• Host Name
• URL Match
• HTTP
• MIME Type
• P2P
For the descriptions of these parameters and configuration of the
Content Based Rules, refer to page 4-21.
Enhanced URL Retrieval

When CID is enabled with this option, CID performs additional
checking of the HTTP header.
For example: A client sends a request for cnn.com (URL1) and that
Web site then sends a request for another URL, for example
“Advertisement” (URL2). CID caches the URL1 request to Cache
Server1. While caching the URL2 request, CID checks the Refer field in
the HTTP header of URL2. Having established that URL’s header
includes URL1, CID caches the URL2 request to Cache Server1, and
not Cache Server2.
This capability enhances the reliability of host name retrieval.
CID User Guide 4-13

Farm Management
Static URL Table

Typically, CID is used by organizations in order to reduce the
bandwidth costs. Another approach is to use CIDs to provide a better
service for certain preferred sites. This means that the content
inspection is performed only for the sites which were registered and
pre-paid for that service.
When this approach is used, the configuration of URL Policies
determines the static content of the URL Table, and no dynamic entries
are added. Requests to URLs not configured in the URL Policies for
that farm, are either forwarded directly to the Internet, in case of
intercepted clients, or discarded, in case of configured clients.
To configure Static URL Table:

1. From the main window click APSolute OS > Traffic Redirection >
Redirection . The Redirection pane appears.
2. From the Redirection pane, click URL Policies. The URL Policies
window appears.
3. From the URL Policies window, set the following parameters
Device Name: Select the device name.
Farm Address: Type the IP address of the farm for which the
preferred sites are configured.
Host Address: Type the hostname or destination IP address
of the URL for which you want to set a policy.
4-14 CID User Guide

Mode: Select the policy mode:

• Direct: CID does not cache the URL, but
connects the client directly to it.
• Blocked: The CID does not cache the
URL or connect the client. The connection
is reset.
• Local Server: Assigns the URL to a
specific cache server in the farm,
irrespective of the configured redirection
mode.
Note: To set Direct URL policies, you must
enable DNS support and configure DNS
servers.
Server Type the IP address of the server to which the
Address: static URL is assigned.
Note: This field is not relevant if Direct or
Blocked mode is configured.
Load File Mode: See step 3.
4. Optionally, to upload URL policies from a file, in the Load From
File area, select the Load File Mode: Direct or Blocked, and then
click Load.
5. In the Open window, browse to the location of the required file and
click Open. The file is uploaded to the device.
CID User Guide 4-15

Farm Management
Configuring Farms
Farm Configuration Guidelines:

1. From the main window double click on the CID icon. The CID
Connect to Device window appears. Type the device‘s IP address
and click Ok.
2. From the main window, click APSOlute OS > Traffic
Redirection. The CID Traffic Redirection window appears.
3. Click the Farms tab. The Farms pane appears. Click Add.
The Edit CID Farms window appears where you can set the
parameters of the farm.
Port Multiplexing
Port Multiplexing is a port address translation that allows CID to accept
traffic destined to a specific port and translate that traffic to a different
port before forwarding it to a server farm. When client requests for
service are destined to a configured Multiplexed Farm Port, CID
changes the destination port of the request to the configured
Multiplexed Server Port before forwarding the request to the selected
server.
The process of the address translation includes the following stages:
1. The client sends the request for service using a destination port of
the farm, for example HTTP port 80.
2. When this port is the configured Multiplexed Farm Port, then
before forwarding the request, CID changes the destination port.
Note: Server Weight is not supported when the Cyclic Dispatch Method
is selected in the farm to a particular server in the farm. The new
destination is configured according to the predefined Multiplexed
Server Port parameter.
To enable Multiplexed Farm Port:

1. From the main window, select APSolute OS >Traffic Redirection
>Farms > Add. The Farm window appears
2. In the Farm window, select Traffic Settings and select an item
from Multiplexed Farm Port dropdown list.
4-16 CID User Guide

To configure global URL Handling parameters:

1. From the main window, double click on the CID icon. The CID
setup window appears.
2. In the Setup window select Global . The Global pane appears.
Select the URL Handling Settings radio button. The URL
settings parameters are listed with the default values.
3. In the Set-Up window Global tab, click Edit Settings. The CID
URL Handling window appears.
4. From the CID URL Handling window, set the following parameters
URL Life Time: The period for which URLs remain listed in
the URL Table.
URL The maximum number of users that can be
Connection directed to a server for a service provided by
Limit: the farm.
Refresh URL Enables or disables URL refreshing which
Status: periodically cleans the URL Table based on
defined Life Time and number of hits.
Refresh Defines the frequency of refresh.
Interval:
Add Forbidden When this feature is enabled, CID inserts
Site to URL URLs of sites, from which an HTTP reply of
Table: 403 (forbidden) has been received, into the
URL Table. CID then sends future requests
for these URLs directly to the Internet and not
to the Cache Server. Through this process
CID allows for the possibility that though the
client may access a site, the Cache Server
may be denied.
Enhanced URL Enables or disables checking of the URL
Retrieval: referral field in the HTTP header, see page 4-
13.
Re-balancing: Enables or disables URL Balancing which
balances the number of host names, by hits,
on each cache server.
CID User Guide 4-17

Farm Management
Re-balancing The host names to transfer are chosen in

Algorithm: chronological order on First Found basis.
Re-balancing Defines the frequency of URL Balancing.
Interval:
Remove Entry Enables or disables the configuration of the
at End of Client Table.
Session:
Remove: Client entry is cleared from the
Client Table at the end of the session, TCP,
FIN or RST FLAG. This is the default and the
recommended mode for this feature.
Leave: Client entry remains in the Client
Table at the end of the session.
Re-balancing When this ratio is reached (meaning a
Ratio: disparity between the number of host names),
URL balancing begins.
Re-balancing When this threshold is reached (meaning the
Threshold: difference between the number of host names
on servers), rebalancing begins.
Client Table Enables or disables configuration of the hash
Hash Mode: function to allow "sticky client".
IPandPort: Enables the regular hashing
function based on the client's IP address and
source port. This means that packets sent
from a single IP address, but using different
source ports, are sent to different servers
based on the decisions of the device. This is
the default and the recommended mode for
this feature.
IPOnly: Enables the Sticky Client Support by
performing the hash function based on the
client's IP address only. This means that all
packets from this IP address, regardless of
the source port, are sent to the same server.
5. Click Apply and OK to close the window.
4-18 CID User Guide

6. Reboot the device in order to implement the URL handling

definitions.
CID User Guide 4-19

Farm Management
Configuring Dispatch Methods
Dispatch Method Configuration Guidelines:

1. From the main window, add a CID device and assign a relevant IP
Address.
2. From the main window, click APSolute OS > Traffic Redirection.
The CID Traffic Redirection window appears.
3. From the main window, double click on a farm (previously
created). The Edit CID Farm window appears.
4. From the Edit CID Farm window, select Traffic Settings and from
the Dispatch Method dropdown list, select the dispatch method.
Note: Ensure that Use URL Table is selected in the Use URL
Table field.
The NT-1, NT-2, and Private-1, Private-2 dispatch methods include
load balancing parameters, consequently their configuration involves
additional steps.
Configuration Guidelines for NT-1, NT-2, Private-1, Private-2

1. Follow steps 1-3 of the general dispatch method configuration.
2. From the Edit CID Farm window, select Traffic Settings and from
the Dispatch Method dropdown list, select the dispatch method,
NT1, or NT2. the Load Balancing option button is enabled.
3. Click Load Balancing. The CID Load Balancing Algorithms
window appears. The Scheme field in the Windows NT tab shows
the selected dispatch method. Default parameter values are
displayed.
4. Define the parameters for the selected method, and click Ok to
apply the settings. Click Ok again to exit the Edit Farm window.
The selected farm will apply the defined dispatch method.
Note: For Private 1 and 2 the configuration procedure is the same.
The parameters for these methods are defined in the Private tab of
the CID Load Balancing Algorithms window.
4-20 CID User Guide

Configuring Content Based Rules

The URL Table is configured from the Content Based Rule field which
is accessible from the Edit CID window.
To configure a Content Based Rule:

1. From the main window, click Add and from the dropdown menu
add a CID device.
2. Double click the CID device icon, from the CID Connect to Device
window that appears, assign an IP Address to the device, then
click Ok.
The CID Traffic Redirection window appears.
4. From the CID Traffic Redirection window, select the Farms tab.
From the Farms table, double click the farm (previously created).
The Edit CID Farm window appears.
5. From the Edit CID Farm window, select the Traffic Settings tab.
From the Content Based Rule dropdown menu, select the
relevant rule according to the URL Table parameters as explained
in Table 4-2 on page 22.
Note: Ensure that Use URL Table option is selected in the Use
URL Table field.
6. Click Ok to apply the setup. The farm information is updated in the
CID Traffic Redirection Farms Table.
7. Click Apply and Ok to exit the window.
CID User Guide 4-21

Farm Management
Table 4-2 lists the Content Based Rules and provides their short
deceptions.
Table 4-2 CID Content Based Rules
Parameter Description
Address Sessions are evaluated according to the packet’s

destination IP address from the client to the Internet.
If the destination IP address is a known address and is
registered in the URL Table, CID redirects the packet
to the indicated server. If the destination is a new IP
address, CID chooses a server, redirects the session,
and registers the new address in the URL Table.
CID performs load balancing decisions for the client
traffic, based on the client‘s source IP and destination
port. For example, if a user arrives with source IP
192.1.1.1 and destination port 80, CID handles all
subsequent requests from that client to port 80 the
same way.
Host Name CID checks the HTTP data of the sessions and
identifies the host name for the request (such as
www.company.com). The URL Table entries are host
names and not IP addresses. Requests for known host
names are redirected to the server that was chosen for
this host name.
If the session carries a new host name, a new server is
chosen, the session is redirected, and a new entry is
made into the URL Table. When working in this mode,
CID performs delayed binding.
4-22 CID User Guide

Table 4-2 CID Content Based Rules (cont.)
URL Match CID can enforce predefined policies: Direct, Block or

Local Server. Based on the URI (CID search of the
HTTP GET request for specific information), CID treats
the requested URI in one of the three manners.
For example, CID can search for CGI-BIN scripts and
forward those requests directly to the Internet. It can
also search for “.vbs” in the Get Request and block
such traffic. When CID uses the URL Match table
mode, decisions are made based on the URL, or part
of it. When working in this mode, CID performs
delayed binding.
HTTP Match CID can redirect requests based on: HTTP header;
HTTP request contents; the request method itself
(GET, POST), or additional message headers.
Headers contain additional information about the
request, such as browser type, connection type
(persistent or not), cookies, destination host. If the
administrator wishes to direct a category of clients (for
example, Netscape users) to a specific cache server,
he can direct them to the Internet, or block users with
certain characteristics. When working in this mode,
CID performs delayed binding.
MIME Type Some Content Security servers use security policies

based on MIME Types. MIME (Multipurpose Internet
Mail Extensions) is a specification for formatting non-
ASCII messages, so that they can be sent over the
Internet and displayed by a client-side application
(such as an e-mail application, or a Web browser).
Some MIME Types are considered 'trusted', and the
Content Server does not need to process them.
CID enables high throughput by defining traffic
redirection policies based on MIME Type, so that only
distrusted data is forwarded to the Content Servers,
hence saving processing power.
CID User Guide 4-23

Farm Management
Table 4-2 CID Content Based Rules (cont.)
P2P Supports Peer-to-Peer (P2P) sharing technology

which enables individual Kazaa users to connect to
each other directly, without the need for a central point
of management. CID supports caching of Kazaa v1
and Kazaa v2.
The MIME Type rule should be used for load balancing anti-virus
servers.
4-24 CID User Guide

Section 4-2 Server Management

Section 4-2, Server Management, presents the server management
features.
• Servers Overview, page 4-26
• Physical Servers, page 4-31
CID User Guide 4-25

Server Management
Servers Overview
Farm servers are logical entities that are associated with application
services provided by physical servers that run these applications.
The process of adding and configuring servers in the CID farm consists
of two main stages:
1. Adding physical servers
2. Setting up farm servers
Adding physical servers means adding the hardware elements to the
network and defining them as servers. This is done using APSolute
Insite after the actual installation of the physical server is performed.
For each service provided by a physical server, you can define a farm
server and attach it to the farm that provides this service. Configuring
farm servers means organizing the servers the way you use their
services.
A physical server that provides multiple services may participate in
multiple farms. In each farm this physical server is represented by a
unique farm server that provides one specific service. Each service is
accosted with a farm, and you can define its own load balancing
scheme and customized health checks. By that way, in case one of the
services provided by a physical server is not available, other services
can still be used.
To enable tracking of all the farm servers associated with the specific
physical server, farm servers are organized in groups, identified by the
server name. All farm servers with the same server name are
considered by CID as running on the same physical server.
Farm server parameters are configured per farm and per server and
control the process of providing a particular service.
Physical server configuration is performed for each Server Name, and
applies to all farm servers on the same CID with the same name,
implying they all run on the same machine.
Server Configuration Guidelines:

1. Configure the physical server’s parameters
2. Configure the farm server’s parameters
4-26 CID User Guide

Server Types
Server types are:
• Regular: A local server, which is the default server type.
• Local Triangulation: local server that has the feature enabling it to
send the response from server directly to client, bypassing CID.
Server Parameters
• Server Description: A free text field that allows you to type a
description for each server. The Server Description can be up to 80
characters long.
• Server Weight: Weight of the server in a farm is server’s priority, or
server’s importance. You can define that a particular server in a
farm has more weight than other servers. This means that more
traffic is forwarded to this server than to other servers.
Server weights operate as ratios. For example, when the Dispatch
Method is set to Least Number of Users, the weights determine the
ratio of the number of users between the servers. If the Least
Amount of Traffic method is used, the weights determine the ratio
of the amount of traffic between the servers. The weight ranges
from 1 to 10,000. A server with weight 2 receives twice the amount
of traffic as a server with weight 1. The default weight is 1.
Note: Server Weight is not supported when the Cyclic Dispatch Method
is selected in the farm.
• Connection Limit: Connection Limit is the maximum number of
users that can be directed to a server for a service provided by the
farm. The number of users depends on the Sessions Mode,
because it is determined by the number of active entries in the
Client Table for sessions destined to the specific server.
When the Regular mode is selected, all the requests for service
from a single client IP destined to the same server are reflected by
a single entry in the Client Table.
When the Entry Per Session or Server Per Session modes are
selected, the number of active entries destined to the same server
is higher that in the Regular mode.
CID User Guide 4-27

Server Management
The default value for the Connection Limit parameter is 0. When

this parameter is configured to 0, this mechanism is disabled for
this server and there is no user number limit.
• Connection Limit Exception: The Connection Limit parameter
can be exceeded, in case an existing client opens a new session
and according to the Sessions Mode the session uses the same
server. This applies, for example, when using the Entry Per
Session Sessions Mode or the Client Grouping Mask feature, To
enable exceeding of the Connection Limit parameter, you can
enable the Connection Limit Exception parameter, which defines
how CID behaves when there is a conflict between Connection
Limit and persistency scheme. The Connection Limit Exception
parameter is defined for each farm.
• Bandwidth Limit: Bandwidth Limit is the maximum amount of
bandwidth in Kbps allowed for this application server. If traffic
through that server exceeds the configured limit for any given
second, CID drops excess packets. The default value is No Limit.
Note: The limit is measured in Kbps, so 1Mbps is represented with a
bandwidth limit of 1000. A value of 0 means that there is no bandwidth
limit.
On a per farm basis CID can be configured with an upper threshold
for Kilobytes per second (Kbps) for that farm. If traffic through that
farm exceeds the configured limit for any given second, CID drops
excess packets.
• Response Threshold: Using Farm connectivity checks with HTTP
Page check, the Response Threshold parameter defines the
number of milliseconds in which the server may reply to the GET
command. When the server's reply takes longer, the status of the
logical server is set to No New Sessions. The default value is 0.
• Client NAT: Using the Client NAT parameter, you can enable the
Client NAT feature for the given farm server. Using Client NAT for a
servers means that CID hides source IP addresses of clients that
access the server in the farm. For detailed description of this
feature, see Network Address Translation, page 4-88.
• Admin Status: Admin Status is the user defined management
status of the server that you can change at any stage of server’s
configuration or operation. The following options are available:
4-28 CID User Guide

• Enabled: The server is active and ready to reply new requests

for service.
• Disabled: The server is not active. When setting the Admin
Status to Disabled, CID removes all the entries relevant to this
server from the Client Table, stops sending new requests for
service to this server and disconnects all the connected clients.
• Shutdown: The server cannot get new requests for service.
The existing sessions are completed according to the Aging
Time.
Tip: Before performing maintenance procedures, set the Shutdown
Admin Status. You can start maintenance procedures after completion
of active sessions.
• Operation Mode: A farm server can be configured to have one of
the following operational modes:
• Regular: The server's health is checked, as long as it is
available the server is eligible for receiving client requests. This
is the default operation mode.
• Backup: The server's health is checked, but the server does
not receive any client requests. The server becomes eligible for
client requests when all the servers in the Regular mode have
failed.
Note: You can also set a server to provide backup for a specified
server. Backup servers configured on the farm level are activated only
when all the active servers are down, see Backup Server Address.
CID User Guide 4-29

Server Management
To enable Connection Limit Exception:

• From the main window, click APSolute OS >Traffic Redirection >
Edit CID Farm. The Edit CID Farm window appears.
• From the Edit CID Farm window, select the Traffic Settings tab
and then select the Connection Limit Exception checkbox.
To define Bandwidth Limit for a farm:

• From the main window, click Traffic Redirection > Edit CID Farm.
From the Edit CID Farm window, click on Traffic Settings then set
the Bandwidth Limit parameter.
4-30 CID User Guide

Physical Servers
Physical servers are hardware units configured to operate as an
integral part of the network. Before setting up a physical server, you
must connect the server to the CID device on the hardware level. Once
hardware connections are completed, you can start adding physical
servers to the APSolute Insite map. The parameters of the physical
server are defined globally and are applied to all the farm servers that
use the physical server.
Table 4-3 describes physical servers’ setup parameters.
Table 4-3 Physical Server Parameters
Server Name The physical server name. The Server name defines
the name of the farm servers group that are
associated with this physical server. Adding a new
server to a farm using a Server Name that was
already defined in another farm, implies that it is the
same physical server.
Recovery When a server's operational status is changed from

Time inactive to active (dynamically or administratively), the
server is not eligible to receive client data for this
period of time. This parameter applies to all servers in
all farms that share the same Server Name. Once
recovery time elapses, the server becomes eligible for
receiving clients requests.
When this value is at 0, the server is eligible
immediately after changing operational status from
inactive to active.
CID User Guide 4-31

Server Management
Table 4-3 Physical Server Parameters (cont.)
Connection The maximum number of Client Table entries that can

Limit run simultaneously on the physical server, depending
on farm’s Sessions Mode. When the limit is reached,
new requests for service are no longer directed to this
server but all open sessions are continued. When this
parameter is configured to 0 (default), this mechanism
is disabled for this physical server and there is no user
number limit.
Note: When configuring Connection Limit for the
physical server, ensure that this value in the farm
servers with the same Server name is lower or equal
to Connection Limit in the physical server. The total
number of active sessions that run simultaneously on
the farm servers must not be higher that the physical
server’s Connection Limit.
Warm-up The time, in seconds, after the server is up, during

Time which clients are sent slowly to this server so that the
server can reach its capacity gradually. CID internally
raises the weight of the server for this period of time,
at the end of which the server's weight reaches the
pre-configured weight.
When this parameter is set to 0 (default), the server
performs activation at full weight upon a change in
operational status from “inactive" to "active” and after
waiting the Recovery Time.
Note: This option is not applicable for farm servers
when using the Cyclic Dispatch Method.
IP Address The IP addresses of the server. For each farm server

associated with this physical server, you define an IP
address.
Global Server Enables this server to be available to other remote

(checkbox) CID devices to provide Global load balancing solution
architecture.
4-32 CID User Guide

To add a server to a farm:

1. From the CID toolbar, click Add and from the dropdown menu
select a local server.
2. From main window double click the server icon. The Server
window appears.
3. From the Server window, set the following parameters for the
physical server according to the explanations provided:
Server Name: (For example) Server 1
IP Address: Add an IP address
4. Add a farm to CID:
a. From the main window, select Traffic Redirection. The CID
Traffic Redirection window appears.
b. From the Traffic Redirection window click Farms. The Farms
pane appears.
c. From the Farms pane click Add. The Edit CID Farm window
appears.
d. From the Edit CID Farm window, set the following parameters
Device CID
Farm Name: (For example) Farm 1
VIP Address: Type the VIP address
Active Farm: Selected
Mode: Active
e. Click Ok. The Edit CID Farm window closes and a new farm
appears in the Farms table.
5. Add a farm server to the farm:
a. From the Farms pane, select the farm that you have created
and click Edit. The Edit CID Farm window appears.
b. From the Edit CID Farm window click Farm Servers then click
Add. The CID Farm Servers window appears.
CID User Guide 4-33

Server Management
c. From the CID Farm Servers window, set the following

Type: Regular
Admin Status: Enabled
Server Address: The address of the server
Operation Mode: Regular
d. Click Ok. The CID Farm Servers window closes and the new
server appears in the Farm Servers table.
6. Set up the physical server parameters.
a. From the APSolute Insite network map, double click the
server’s icon. The Server window appears.
b. From the Settings tab, set the parameters of the physical
server as explained in Table 4-3, and click Ok to apply.
Multiplexed Farm/Server Port

Port Multiplexing is a port address translation that allows CID to accept
traffic destined to a specific port and translate that traffic to a different
port before forwarding it to a server farm. When client’s requests for
service are destined to the configured Multiplexed Farm Port, CID
changes the destination port of the request to the configured
Multiplexed Server Port before forwarding the request to the selected
server.
The process of the address translation includes the following stages:
1. The client sends the request for service using a destination port of
the farm, for example HTTP port 80.
2. When this port is the configured Multiplexed Farm Port, then
before forwarding the request, CID changes the destination port to
a particular server in the farm. The new destination is configured
according to the predefined Multiplexed Server Port parameter.
3. When the response is sent from the server to the client, CID
changes the source port back to the farm’s port, for example from
port 8080 to port 80.
4-34 CID User Guide

For Multiplexed Farm / Server Port there are pre-defined values: FTP,
HTTP, SMTP, DNS, NNTP, HTTPS, Disable, or any port number.
The default value is Disable, meaning port multiplexing is not used for
the server.
For example, the Server port is 8080 and it is defined during the server
configuration process. The Farm port is 80 and it is defined during the
farm configuration process.
Multiplexed Farm Port Configuration Guidelines:

1. From the main window, select APSolute OS > Traffic Redirection.
2. From the Traffic Redirection window, select the Farms tab, select
the farm to configure and click Edit. The Edit CID Farm window
appears.
3. From the Edit CID Farm window, select the Multiplexed Farm
Port for the farm.
4. Click the Farm Servers tab, and edit each server in the farm and
then select the Traffic Settings tab and edit the Multiplexed port.
CID User Guide 4-35

Server Load Balancing
Section 4-3 Server Load Balancing

Section 4-3, Server Load Balancing, describes the farm-related CID
features designed to maximize utilization of the existing network
resources when providing various services.
• Client Table Management, page 4-37
• Content Servers Overview, page 4-39
• Alias Port, page 4-50
• Sticky Clients Support, page 4-51
• Server Health Check, page 4-52
4-36 CID User Guide

Client Table Management

To maintain client-server persistency in a CID farm, CID uses the Client
Table. This table keeps track of the client - server connections for each
of the local farms. When a client first approaches a CID farm, CID
checks whether an entry for this client already exists in the Client Table:
• If the appropriate entry is found, the client is directed to the server
that appears in the Client Table. In this case, there is no need to
make a load balancing decision.
• If an entry does not exist, a server is selected according to the load
balancing considerations that are defined by the Dispatch Method.
An entry is made into the Client Table indicating the selection of the
server.
Once an entry is created in the Client Table, all subsequent packets
that arrive from the client to the CID farm are forwarded to the server
indicated in the Client Table entry. The traffic in the opposite direction
Configuring Client Table

The Client Table provides information about the way a client is sent to
the server, for example, if Port Multiplexing is used.
You may need to ensure that certain clients always access a specific
server on the server farm, irrespective of load balancing
considerations. You can configure such clients using the Client Table
window. If the packet has to be treated by CID, CID first searches the
Client Table to check whether this is a new session or an existing
session. For an existing session, there is no need to make a load
balancing decision.
The following table shows an example of Client Table information:
Farm Client Server Source Destination Server Attached

Address Address Address Port Port Port Time
1.1.1.1 192.0.0.5 130.0.0.1 1062 80 8080 234
1.1.1.1 192.0.0.8 130.0.0.1 1011 80 8080 332
1.1.1.1 192.0.0.20 130.0.0.2 1079 80 8080 643
CID User Guide 4-37

Figure 4-3 displays a farm configuration according to the Client Table

example.
Clients
www.site.com
CID
192.0.0.5 www.radware.com
192.0.0.8
Server 1 Server 2
130.0.0.1 130.0.0.2
192.0.0.20
Farm Address 1.1.1.1
Figure 4-3 Client Table Configuration
When a session is already established, CID updates the Attached Time

in the Client Table and sends the client to the same server that serves
the client. However, when one of the following conditions is met, CID
removes the entry from the Client Table:
• One of the servers within a farm becomes unavailable.
• The value of the Attached Time parameter is equal to the value of
the Aging Time parameter. For the explanation of these
parameters, see page 3-14.
• When the Remove Entry at Session End flag is set to Remove
under the CID tweaks. This removes the session when CID detects
a FIN or RST packet.
4-38 CID User Guide

Content Servers Overview

CID is designed to load balance content servers, such as cache
servers, anti-virus servers, URL filters and others. User traffic that is
distributed among these content servers can be heterogeneous.
Because CID transparently intercepts Internet-bound traffic and
intelligently load balances the traffic between the content servers,
users do not need any browser configuration to direct them to a "proxy"
server.
To facilitate users who need to operate non-transparently, CID provides
a Virtual IP address for the content farms. CID intelligently directs
sessions to the most available server, sending repeated requests for
the same site to the same cache server when it load balances cache
servers.
Server Types
CID supports several types of content servers. Each server can be
installed in a one-leg configuration or in a two-leg configuration. All
server types may be configured in the regular mode (using their own IP
address) or spoofed mode (using the clients IP address) including:
• Gateway: A Gateway is a server that uses two interfaces: the
interface that receives, processes and forwards the traffic, and the
interface that the traffic is forwarded to. The name of the gateway
server indicates its location in the network topology. Gateways
need to be part of the traffic flow - in most cases these servers are
bottlenecks in the network due to their limited processing power.
When CID load balances gateways, it moves the servers from the
traffic flow and also ensures that the packet that leaves the second
interface of the selected server returns to the same server.
When using gateways, CID sends the packet to the MAC address
of the server, and the server uses the client's IP address as the
source IP (spoofing).
• Transparent Server: A server that serves the clients transparently.
When CID forwards traffic to a transparent server, it sends the
traffic to the server's MAC address, while the destination IP is the
IP address of the real site's IP, and the client’s requests remain
unchanged.
CID User Guide 4-39

• Regular Server: A server that serves the clients non-transparently.

The clients have to send the requests to the IP address of the
server and to the MAC address of the server. When a non-
transparent proxy server is in use, the clients send their requests
directly to the proxy server which then fetches the content on behalf
of the client. The requests are sent to the proxy server using the
protocol that this proxy server supports.
For HTTP, the clients have to configure their browsers to use a
proxy server; for POP3 the users have to configure their mail client
to use a proxy server as their POP3 server, and to send the real
mail server along with their username using a special delimiter.
When CID load balances proxy servers, it can automatically
transform the requests to a proxy form, so the clients do not have to
change their configuration.
• Cache Server: A proxy server that stores-and-forwards Web
pages. When a client configures the Web browser to use a cache
server, the client's browser does not connect to the requested Web
server on the Internet; instead, the client's browser connects to the
cache server, and asks it to get the URL for the client. When a
cache server receives a request for an Internet service (it can be a
request for a Web page or a file download using FTP) from a user,
the cache server looks in its local cache of previously downloaded
Web pages.
Cache server returns the found page to the user without having to
retrieve the content from the Internet. If the page is not in the
cache, the cache server acts on behalf of the client, using one of its
own IP addresses (or the client's IP address, for cache servers that
support spoofing) to request the page from a server out on the
Internet. When the page is returned, the cache server forwards it to
the user who made the initial request.
• Content Server: A server, such as anti-virus or a URL filtering,
server that has the ability to check the content up to Layer 7 to
search for a specific content and block it.
Many kinds of content servers are in use and each vendor uses a
different operation method. For example, the anti-virus servers can
be installed as a gateway. With that method, the Content server
uses two interfaces and routes the traffic from one interface to
another.
A Content server can also operate as a proxy server without the
4-40 CID User Guide

caching capabilities, or it can have a single interface. CID supports

all vendors and types of content servers.
• Physical Server: Physical server is a hardware unit configured to
operate as an integral part of the network. Before setting up a
physical server, you must connect the server to the CID device on
the hardware level.
Once hardware connections are completed, you can start adding
physical servers to the APSolute Insite map. The parameters of the
physical server are defined globally and are applied to all the farm
servers that use the physical server.
CID User Guide 4-41

Configuring Servers
To add a server to a farm:

1. From the CID toolbar, click Add and from the dropdown menu add
a local server.
2. Double click the Server icon. The Server window appears.
3. From the Server window define the server and set its physical
Server Name: Type the name for the server, for example:
Server 1.
Admin Status: Check/Enable.
Recovery Time: Type the value (in seconds)
Warm Up Time: Type the value (in seconds)
Connection Limit: Type the value (number of clients)
IP Address: Type the IP address for the server.
Global Server: Check to enable.
Note: For explanations of the server physical parameters, refer to
Table 4-3 on page 31.
4. Click Add. The new server IP appears in the Server IP Address
list. The window remains open.
5. In the same manner, add more servers as explained in steps 2-3.
6. Click Ok to apply the setup and exit the window.
7. Add a farm to the map:
a. From the main window, select APSolute OS >Traffic
b. From the Traffic Redirection window select the Farms tab.
From the Farms pane, click Add. The Edit Farm window
appears.
c. From the Edit CID Farm window select the Farm Servers tab,
provided:
4-42 CID User Guide

Multiplexed for Port: Disable this option.

VIP Address: Type the VIP address.
Admin Status: Check/enable this option.
d. Click Ok to apply.
8. Add a farm server to the farm:
a. From the CID Traffic Redirection window Farms tab, select the
farm that you have created and click Edit. The Edit CID Farm
window appears.
b. From the Farm Servers tab, click Add. The CID Farm Servers
window appears.
c. From the CID Farm Servers, set the following parameters
Admin Status: Enable
Server Address: Select the address of the server
Weight: 1
Multiplexed Server Select Disabled or HTTP
Port:
Connection Limit: 0
Local Triangulation: Check to Enable
Transparent Mode: Select the mode according to the
(checkbox) type of server to configure:
For Transparent server: Check
For Proxy non-transparent
server: Clear
Server Delimiter: @
Alternative Server Select from the dropdown list.
Address:
d. Click Ok. The CID Farm Servers window closes and the new
farm server appears in the Farm Servers table in the Edit CID
Farm window.
CID User Guide 4-43

e. Click Ok and Ok again to exit all windows.

Note: The port number that the server is listening on can be used
only when port multiplexing is enabled and defined in the farm
configuration, see page 4-35.
4-44 CID User Guide

Example - CID with Transparent Content Servers

Figure 4-4 illustrates a configuration where clients and content servers
are on different subnets. In this type of configuration, in addition to the
basic operation, CID acts as a router and users are configured to CID
or transparently intercepted by CID.
Switch 1 CID Switch 2 Internet
P1 P2
Clients CID VIP Router

10.1.1.20 Address 100.1.1.20
10.1.1.100
Server Server
100.1.1.2 100.1.1.1
Figure 4-4 CID with Transparent Content Servers
Properties:
• Network side and user side are on different subnets.
• The virtual IP address of CID is 10.1.1.100.
• Users are not configured on CID and thus traffic is transparently
inspected by CID.
• Content servers are transparent.
• Content servers use port 80 for the HTTP traffic.
Note: An example of CID configuration with transparent servers in
a VLAN environment is provided on page 4-61.
CID User Guide 4-45

Configuration:
1. Define the interfaces for ports 1 and 2.
a. From the main window double click on the CID icon. The CID
Connect to device window appears. Type the device‘s IP
address: 10.1.1.10 and click Ok.
b. Double click on the CID icon again.The Content Inspection
Director window appears.
c. In the CID window, click Add. The Edit CID window appears.
d. From the Edit CID window, set the following parameters
IF Num: F-2
Broadcast Type
Forward Broadcast Selected
VLAN Tag 0
e. Click Ok. The Edit CID window remains open.
2. Define the default gateway:
a. From the Set-Up window, select Networking > Routing
b. From the CID Routing Table, click Add. The Edit Route window
appears.
c. From the Edit Route window, set the following parameters
Address:
Network Mask: 0.0.0.0.
Next Hop: 100.1.1.20
IF Number: F-1
Metric: 1
Type: Remote
d. Click Ok to exit all windows.
4-46 CID User Guide

3. Add two servers to the map:

a. From the CID toolbar, click Add and from the dropdown menu
add a local server. Set the following parameters according to
c. In the same manner add the second server by setting the
4. Add a farm to the map:
a. From the main window, click APSolute OS >Traffic
Redirection. The Traffic Redirection window appears.
b. From the Traffic Redirection window, select the Farms tab and
then click Add. The Edit CID Farm window appears.
c. From the Edit CID Farm window, set the following parameters
Note: Ensure that the Transparent Mode is enabled.

5. Add servers to the farm:
a. From the Edit CID Farm, click Add. The CID Farm Servers
window appears.
CID User Guide 4-47

b. From the CID Farm Servers window, set the following

Transparent Mode: Enabled
Note: Ensure that the Transparent Mode is enabled.
c. Click Add and then click Ok.

a. From the CID Traffic Redirection window, select the desired
farm and click Farm Policies. The Farm Policies window
appears.
b. From the Farm Policies window, select Classes > Networks >
Modify > Add. Set the following parameters according to the
Network Name: Local
c. Click Ok and then Ok to return to the Farm Policies window.
a. From the Farm Policies window, right click the Modify Farm
Policy tab and select Add. From the pane that now appears,
set the following parameters according to the explanations
provided:
Policy Name: http
Index: 1
Service http
Source Address: Local
Direction oneway
Description example 1
4-48 CID User Guide


Cluster Farm 10.1.1.100
Note: Users can be configured to the IP Address of the farm or to
the farm host name. When the Host Name rule is used, CID has to
be configured as DNS Server.
CID User Guide 4-49

Alias Port
An Alias Port enables CID to work with non-standard ports. For
example, if a Web server works on the TCP port 81 which, unlike port
80, is not a standard, CID treats this port as an HTTP port.
To configure Alias Ports:

1. From the Traffic Redirection window, select a farm and click Edit.
2. From the Edit CID Farm window, click Alias. The Alias Ports
window appears.
3. From the Alias Ports window, set the following parameters
Port Number: Type the Port Number.
Well Known Port Type the well known port number.
Number:
Port Type: Select the port type for this alias.
Values: TCP; UDP; Both.
4. Click Add and then Ok.
4-50 CID User Guide

Sticky Clients Support

CID allows maintaining client stickiness to a Cache Server regardless
of TCP/UDP ports, using any Dispatch Method. CID uses the hash
function to access the Client Table. Typically, the hash function uses
the source IP and source port which indicates that a new Client Table
entry is used for each source IP and source port combination. CID
allows using the source IP only as the input for the hash function,
implying that the same server is to be used for different sessions of the
same client (using the same farm).
To enable Sticky Clients Support:

1. From the Traffic Redirection window, select a farm and click Edit.
2. From the Edit CID Farm window, click the Traffic Settings tab.
The Traffic Settings pane appears.
3. From the Traffic Settings pane Dispatch Method dropdown menu,
select Source Hashing.
CID User Guide 4-51

Server Health Check

CID can be configured to monitor the status of servers in its farms to
ensure that they are available and that they can handle the load
balancing requests to content servers. For this purpose, two categories
of health checks are available:
• Basic Health Check, which is also referred to as the Farm
Connectivity Check.
• Advanced Health Check, which is performed by the Health
Monitoring Module.
Both options are available from the CID Health Monitoring menu
(where the HM module is installed).
Note: The CID Health Monitoring Module is described in detail in
Chapter 7, Health Monitoring.
The Farm Connectivity check examines these functionalities:
• Ping
• HTTP Port (checks that port 80 is available)
• HTTP Page (checks the availability of a specific Web page)
• Un-cached HTTP Page (also checks the internet connection)
In HTTP Port checks, the CID periodically opens a session with the
server on port 80. A successful connection indicates that the server is
available. Failure to establish a successful connection on the specified
port means that CID considers the server unavailable for traffic. When
a failure occurs, CID continues to check for the server's availability and
generates a syslog trap that the server is "Not In Service".
For HTTP Page checking, CID can periodically perform HTTP GETs
from the cache server for a predefined URL. CID examines the HTTP
header of the server response and considers responses with HTTP
status code of 200 (status Ok) to indicate a healthy cache server. CID
can also be configured to pull an un-cached page from servers in the
farm by sending an HTTP request for a specified page using the
"pragma - no cache” command. This instructs the server to respond
with fresh content, not with content from cache. This method can be
used to ensure that the server can actually access an external site and
retrieve the specified page. Health check attributes, its method,
intervals, and number of retries can be configured according to need.
4-52 CID User Guide

Section 4-4 Cache Load Balancing

Section 4-4, Cache Load Balancing, presents the Cache Load
Balancing functions and enhancements as implemented in CID.
• What is Caching?, page 4-54
• How Does Cache Load Balancing Work?, page 4-56
• CID Cache Load Balancing, page 4-57
• Client-Server Combinations, page 4-60
• P2P/Kazaa Caching, page 4-67
• Web Cache Coordination Protocol (WCCP) 2, page 4-74
• Enhanced Cache Coordination, page 4-76
CID User Guide 4-53

What is Caching?
The role of caching is to store the frequently accessed Web content, in
order to shorten response time and save network bandwidth.
Figure 4-5 illustrates a caching configuration example.
When the first user, User A, types the URL:
http://www.radware.com in the browser, the cache gets the
request for this page but does not have the content. The cache gets the
Web page from the original Web server for radware.com and keeps
the page in its local storage, such as memory or disk. The cache then
replies to the user with the requested Web content. When User B tries
to access the same Web page later on, the cache gets the request
again, finds the content on its local storage and replies to the user
without having to go to the origin Web server. User B gets the response
much more quickly than User A. The network bandwidth is saved
because the cache does not have to access to the origin server over
the Internet again.
www.radware.com/home/logo.gif
User A
Cache Server Local Servers
User B www.radware.com/home/logo.gif
Figure 4-5 Caching Example

Tip: It is useful to remember that each Web page actually consists of
multiple objects. The browser retrieves each object and then
assembles and displays the complete page.
4-54 CID User Guide

Because caches make requests to origin servers on behalf of the end

user, they are also called proxy cache or proxy servers.
If a requested object is in the cache local storage so that the cache
serves the object by itself, it is called a “cache hit”. If the cache does
not store the requested object, it is called a “cache miss”. In case of
“cache miss”, the cache obtains the object from the origin server.
The cache-hit ratio is defined as the number of hits expressed as a
percentage of the total requests received by the cache. Cache-hit ratio
indicates the efficiency of the cache. The higher the hit ratio, the more
requests the cache serves by itself, which results in an improvement in
user response time and saves network bandwidth.
CID User Guide 4-55

How Does Cache Load Balancing Work?

Load balancing across caches is different from load balancing across
servers. In the case of server load balancing, the local balancer tries to
configure which server has the least load, in order to send the next
request. When load balancing across caches, attention is paid to the
content available on each cache to maximize cache-hit ratio. If a
request for example www.presents.com/home/products.gif is
sent to cache 1 for the first time, the cache retrieves from the original
server.
When a subsequent request for the same object is received:
• If the load balancer sends this to cache 2, it‘s inefficient because
now cache 2 must also go to the original server and get the object.
• If the load balancer remembers that this object is already in cache
1, and forwards all subsequent requests for this object to cache 1,
the cache-hit ratio is increased and the response time to the end
user is improved.
4-56 CID User Guide

CID Cache Load Balancing

CID is designed to load balance cache servers. CID transparently
intercepts Internet-bound user traffic and intelligently load balances the
traffic between the cache servers that operate transparently or non-
transparently. Due to this, users do not have to have any browser
configuration that directs them to a proxy server. CID provides a Virtual
IP address for the cache farms, so as to facilitate users who need to
operate non-transparently. CID intelligently directs sessions to the most
available server, sending repeated requests for the same site to the
same cache server while it load balances cache servers.
CID can significantly improve network performance, and at the same
time it can cut costs by reducing the use of bandwidth and additional
content servers. Moreover, you can save time normally spent
configuring client browsers to use cache servers, because CID can
intercept all client requests by itself, even if the client browsers are not
configured to use a proxy server when it load balances cache servers.
Client Types
There are two types of clients in a cache server environment:
• Configured Clients: Configured clients are clients that configure
their Web browser (or mail client) to use a content/proxy server.
When the client's Web browser is configured to use a proxy server,
all the HTTP requests are sent to the proxy server using the cache
server's IP as the destination IP address (Layer 3), cache server
port number (Layer 4) and proxy request type (Layer 7).
• Intercepted Clients: Intercepted clients send regular requests that
are directed to their default gateway. The destination IP address is
the IP address of the Internet Web site (Layer 3), the destination
port is the application port number and the request type is a regular
HTTP request (Layer 7).
CID User Guide 4-57

Cache Server Types

There are two types of cache servers:
• Proxy Non-Transparent Cache Server: When using a non-
transparent proxy server, the clients must send a proxy request.
The server expects to receive a special type of request containing
the destination IP address of the proxy server, a proxy-connection
keep-alive and the GET request containing the entire requested
URL (this is how the proxy knows which URL to retrieve). To use a
non-transparent cache server, the client must send an HTTP
request which differs from a typical HTTP request in the following
parameters:
• The destination IP of the packet is that of the cache server
instead of the site's IP.
• The GET header field containing the complete requested URL.
• A Proxy-Connection header field is used instead of the normal
Connection header field.
• Proxy Transparent Cache Server: When using transparent
servers, the client is not necessarily aware of the cache server. The
client sends the request to the Internet Web site, but the cache
server intercepts the request and fetches the content of the
requested URL and stores the content locally. Intercepted traffic is
sent to transparent caches/proxies without any IP header
manipulation.
With transparent proxies, an asymmetric traffic flow can easily be
achieved in the network (traffic flow of client > CID > cache >
client), because no IP header manipulation is necessary.
• CID also supports spoofed servers. A spoofed server uses the
clients original IP address and the servers’ source port.
4-58 CID User Guide

Proxy and Non-Proxy GET Request

Figure 4-6 shows the example of both types of the GET Request.
Non Proxy GET Request
Proxy GET Request
Figure 4-6 Proxy and Non-Proxy GET Request

Note: The URL for Proxy GET Request is part of the GET command,
see Line 1.
CID User Guide 4-59

Client-Server Combinations
CID supports several combinations of clients and servers; in situations
where there are many clients on a network with a proxy server, CID has
the ability to intercept the clients’ requests and change them from an
HTTP request to a PROXY request. This is an advantage because
there is no need to configure the entire network to use the proxy server,
but it still forces all clients to use the proxy server.
Table 4-4 shows the available combinations of clients and types of
cache servers:
Table 4-4 Client-Server Combinations
Client Type Server Type CID Supported

Configuration
Configured Non-transparent Clients are configured to the
cache Servers Farm.
Configured Transparent Cannot work because the

transparent cache server
expects to receive the IP
address of the Internet Web
site, while configured clients
send the IP address of the
proxy as the IP address of
the Internet Web site.
Intercepted Non-transparent CID intercepts the client

traffic and transforms the
client requests from an HTTP
request to a Proxy request.
Intercepted Transparent CID sends the original client

traffic without an IP header
manipulation, using the Layer
2 address of the selected
cache server and CID.
Note: Transparent and Non-Transparent mode are enabled from the

CID Server’s Farm window.
4-60 CID User Guide

Example - CID with Transparent Cache Servers in

VLAN Environment
The Figure 4-7 example illustrates a configuration where a CID is
added to an existing network in a VLAN configuration. CID is a
transparent device that requires no client configuration. Clients can be
either configured to CID, or configured transparently.
Internet
Content
Router
Inspection
10.1.1.20
Server
10.1.1.4
Network Side P2
IP VLAN Virtual IP
Interface CID Address
10.1.1.1 10.1.1.100
User Side P1
Client Client
10.1.12 10.1.1.3
Figure 4-7 CID with Transparent Servers in VLAN Environment
CID User Guide 4-61

Properties:
• Network side and user side are on different subnets.
• Users are non-configured to CID, thus intercepted by CID.
• Cache servers are transparent.
• Cache servers use port 80 for HTTP traffic.
Configuration:
1. Define an IP VLAN that includes ports 1 and 2.
b. From the CID window, select Networking > VLAN. The CID
c. From the CID Virtual LAN window, click the Set-Up tab. The
Set-Up pane appears.
d. From the Set-Up pane, set the following parameters according
Assign Port to VLAN F1 - Selected
F2 - Selected
Type: Regular
Protocol: IP
2. Enable the VLAN Forwarding policy:
a. From the CID Virtual LAN window, select the Parameters tab
and select the VLAN Forwarding policy checkbox.
b. Click Ok to apply the setup and exit the window.
3. Define an IP interface with the address 10.1.1.1 to be associated
with the VLAN.
• If an IP interface with the 10.1.1.1 address is already
defined, edit the interface to associate the 10.1.1.1 address
with the VLAN (10000X).
• If there is no defined IP interface with the 10.1.1.1 address,
define one.
4-62 CID User Guide

a. From the CID window, select Networking > Routing

b. Click Add. The Edit Route window appears.
Address:
Next Hop: 10.1.1.20
IF Number: F1
Metric: 1
Type: Remote
d. Click Ok to apply the setup and exit the window.
5. Add a server:
a. From the main window, click Add and select a local server.
b. Double click on the Server icon. The Server window appears.
Assign the IP address of 10.1.1.4 to the server and click Ok.
6. Add a new farm to the CID:
a. From the Traffic Redirection window, click the Farms tab and
b. From the Edit CID Farm window, set the following parameters
Multiplexed for Port: Disable
c. Click Ok to apply the setup. The Edit CID Farm window
remains open.
d. From the Edit CID Farm window, click Add. The CID Farm
e. From the Server Name parameter, assign a name to the server
and click Ok.
7. Add a new network:
CID User Guide 4-63


appears.
b. From the CID Farm Policies window, click Classes. The CID
Classes window appears.
c. From the CID Classes window, click the Modify tab and click
Add. The Edit Network Table appears.
d. From the Edit Network Table, set the following parameters
Network Name: Local
e. Click Ok and then Ok again. From the CID Classes window,
click Update Active Classes.
a. From the CID Farm Policies window, click Modify Farm Policy
and then click HTTP then, set the following parameters
Policy Name: http
Index: 1
Service: http
Source Address: Any
Destination Address: Any
Direction: One way
Description: Example
4-64 CID User Guide

b. Click Add Policy and then click Ok.

Note: Ensure that:
• The default router of the CID is the internet router at 10.1.1.20.
• The default router of the content server is CID.
9. To operate the load balancing in a VLAN network topology, set
your VLAN to be a regular VLAN type.
CID User Guide 4-65

Example - CID with Non-Transparent Cache Servers

When servers are of the non-transparent type and clients are not
configured, CID intercepts client traffic and transforms client requests
from the HTTP GET request to the Proxy GET request.
Configuring CID with non-transparent cache servers is similar to
configuring CID with transparent cache servers in VLAN environment,
with the following exceptions:
• When setting the parameters in the Edit CID Farm window, enable
(check) Transform Request from the Traffic Settings tab.
• When setting the parameters in the CID Farm Servers window,
disable (clear) Transparent Mode.
4-66 CID User Guide

P2P/Kazaa Caching
CID provides support for Peer-to-Peer (P2P) sharing technology. P2P
technology enables individual users running Kazaa Media Desktop
(KMD) application to connect to each other directly, without the need
for a central point of management. CID supports caching of Kazaa v1
and Kazaa v2.
CID supports Kazaa sessions which are initiated by the uploader and
the downloader. Support for sessions initiated by the downloader is
required in cases where the remote Kazaa peer is located behind a
firewall.
CID accelerates Kazaa v2 caching by initially intercepting all traffic
destined to a predefined port range, and then performs delayed binding
to search for Kazaa signatures. This method reduces false positive
cases, which results in non-Kazaa traffic cache redirection.
Notes:
• Kazaa v2 protocol uses a range of ports. CID intercepts the Kazaa
port range, however this parameter is network dependent, and the
values of 1000-6000 are a general recommended value.
• Kazaa v1 can use also Content Based Rule = IP Address, as there
is no need to search for a signature within the packets.
Farm Policy Configuration Guidelines:

Setting a Farm policy to support the Kazaa protocol is performed in the
CID Traffic Redirection window and involves the following steps:
1. Define a new Content Servers Farm with Content Based Rule: P2P.
2. For Kazaa v1, define two Basic TCP filters:
a. Filter for Kazaa session initiated by the uploader:
destination port = any; source port = 1214.
b. Filter for Kazaa session initiated by the downloader:
destination port = 1214; source port = any.
3. For Kazaa v2, define two Basic TCP filters:
a. Filter for Kazaa session initiated by the uploader:
destination port = any, source port range:1000-6000.
CID User Guide 4-67

b. Filter for Kazaa session initiated by the downloader:

destination port range:1000 -6000; source port = any.
4. Create a new service group for Kazaa v1 or Kazaa v2, containing
the two defined regular filters.
5. Define a Farm Policy for the service group by setting the following
Service Type: Grouped Service
Service: Kazaa
Support for other P2P Protocols

While setting Farm Policies with service assigned to the service ports,
you can configure other P2P protocols, which use well-known ports.
Table 4-5 lists the P2P protocols and their corresponding port numbers
for configuration:
Table 4-5 P2P Protocols and Supporting Ports
Protocol Port Number Type of Traffic

Kazaa v1 TCP: 1214 inbound
TCP: 1214 outbound
Gnutella TCP: 6346, 6347 inbound
TCP: 6346, 6347 outbound
eDonkey / eMule TCP: 4661, 4662 outbound
UDP: 4665, 4672 outbound
TCP: 4662, 4771 inbound
UDP: 4672, 4665 inbound
4-68 CID User Guide

Example - P2P/Kazaa Caching

Figure 4-8 shows an example of P2P Kazaa caching configuration.
Internet
Virtual IP
Router
Address
10.1.1.20
10.1.1.100
P2
IP VLAN I/F
P3 10.1.1.1
CID
Server P2P P1
10.1.1.4
Clients
Figure 4-8 P2P/Kazaa Caching
Configuration:
1. Define an IP VLAN that includes ports 1 and 2:
a. Double click the CID icon. The Set-Up window appears.
b. In the Set-Up window, select Networking > VLAN. The CID
CID User Guide 4-69

c. From the CID Virtual LAN window, click on the Set-Up tab. The
Set-Up pane appears.
d. From the Set-Up pane, set the following parameters according
Assign Port to VLAN F1 - Selected
F2 - Selected
F3 - Selected
Type: Regular
Protocol: IP
2. Enable VLAN Forwarding policy:
a. From the CID Virtual LAN window, select the Parameters tab
then select VLAN Forwarding Policy checkbox.
b. Click Ok to apply the setup and exit the window.
3. Define an IP interface with the address 10.1.1.1 to be associated
with the VLAN.
b. In the Set-Up window click Add. The Interface window appears.
c. In the Interface window, set the following parameters according
• If an IP interface with the 10.1.1.1 address is already
defined, edit the interface to associate the 10.1.1.1 address
with the VLAN (1000X).
• If there is no defined IP interface with the 10.1.1.1 address,
define one.
a. From the Set-Up window select Networking > Routing Table.
The CID Routing Table appears.
b. From the CID Routing Table click Add. The Edit Route
window appears.
Destination IP Address: 0.0.0.0
4-70 CID User Guide

Next Hop: 10.1.1.20

IF Number: F1
Metric: 1
Type: Remote
5. Add a server:
a. From the main window, click Add and select a local server.
b. Double click the Server icon. The Server window appears.
c. From the Server window assign the server an IP address of
10.1.1.4.
6. Add a new farm to the CID:
a. From the Traffic Redirection window, select the Farms tab and
Admin Status: Checked
Content Based Rule: P2P
c. Click Ok. The Edit CID Farm window remains open.
d. From the Edit CID Farm window, click Add. The CID Farm
Servers window appears. From the Server Name parameter
add the server and click Ok.
7. Define two basic TCP filters:
a. From the main window, select Traffic Redirection. From the
CID Traffic Redirection window, select the desired farm and
click Farm Policies. The Farm Policies window appears.
b. From the Farm Policies window, click Classes. The CID
CID User Guide 4-71

c. From the CID Classes window, click Add Regular, then set the
Filter for Kazaa session initiated by uploader:
Service Name: Kazaa uploader
Protocol: TCP
Destination Port: any
Source Range: From: 1000; To: 6000
Filter for Kazaa session initiated by downloader:
Service Name: Kazaa downloader
Protocol: TCP
Destination Port: From: 1000; To: 6000
Source Range: Any
d. Click Ok and then Ok again. From the CID Classes window,
click Update Active Classes.
8. Create a new Service Group for Kazaa v2, containing the two
regular filters that you defined.
a. From the CID Classes window, select Add Group.
b. From the Basic Services list, select the predefined services;
Kazaa uploader, Kazaa downloader and then click Add
Service and click Ok.
a. From the Farm Policies window, click Modify Farm Policy and
then click HTTP, then set the following parameters according to
Policy Name: http
Index: 1
Service: Kazaa
Source Address: Any
Direction: One way
4-72 CID User Guide

Note: Ensure that:
• The default router of the CID is the internet router at 10.1.1.20.
• The default router of the content server is CID.
10. To operate the load balancing in a VLAN network topology, set
your VLAN to be a regular VLAN type.
CID User Guide 4-73

Web Cache Coordination Protocol (WCCP) 2

WCCP V2.0 protocol specifies interactions between one or more Cisco
routers as well as one or more web-caches. The purpose of the
interaction is to establish and maintain the transparent redirection of
selected traffic types flowing through a group of routers. The selected
traffic is redirected to a group of web-caches with the aim of optimizing
resource usage and lowering response times. The protocol does not
specify any interaction between the web-caches within a group or
between a web cache and a web-server.
CID supports WCCPv2 in the same manner as Cisco routers support,
which endeavors to provide uniform cache resource allocation in a
mixed environment where the same cache servers farm is accessed by
Radware devices and Cisco devices.
CID WCCPv2 is implemented according to IETF Internet draft
draftwilson-wrec-wccp-v2-00 from July 13, 2000 with the following
notes:
• Forwarding Method is set to L2 rewrite.
• Service ID is set to standard (HTTP).
• Redirection is with hash assignment.
• GRE encapsulation is not supported for the communication
between Radware device and a cache server.
• Only one farm can be configured with WCCP.
When a cache server wants to join a caching farm it sends a "here I
am" packet. If the source IP of the cache server who sent the packet
configured as a server in the WCCP farm, CID sends an "I see you"
packet back to the cache, otherwise it ignores the packet from the
server. The cache sends another "here I am" packet and to complete
the connection, the CID sends an "I see you" packet. After all the
caches completed establishing their connection with the CID, the cache
with the lowest IP sends a "Redirect Assign" packet, containing the
load balancing hash table.
WCCP Configuration Guidelines:

WCCPv2 is configured as part of server farm configuration from the
CID Edit Farm window:
4-74 CID User Guide

• Set Dispatch method to: WCCP.

• Set Check Connectivity Status to: Disabled.
• Configure the cache servers as part of a server farm, and then
apply the dedicated WCCP settings.
• The WCCP address of cache servers should be configured to the
actual CID interface address, and not the farm VIP
• Define a farm policy to intercept the client's traffic and forward it to
the WCCP farm.
Notes:
• Only one farm can support WCCP.
• CID supports WCCP version 2 only
CID User Guide 4-75

Enhanced Cache Coordination

WCCP (Web Cache Coordination Protocol) v2.0 specifies interactions
between one or more Cisco routers and one or more Web caches. The
purpose of the interaction is to establish and maintain the transparent
redirection of selected traffic types flowing through a group of routers.
Selected traffic is redirected to a group of Web caches with the aim of
optimizing resource usage and lowering response times. This protocol
does not specify any interaction between the Web caches within a
group or between a Web cache and a Web server.
CID versions 2.02 and later support WCCP v2.0 in the same manner
as Cisco router support, to provide a uniform cache resource allocation
in a mixed environment where the same cache servers farm is
accessed by both Radware devices and Cisco devices.
CID WCCP v2.0 configuration is done in Web Based Management and
is implemented as follows:
• Forwarding Method is set to L2 Rewrite
• Service ID is set to Standard (HTTP)
• Redirection is with hash assignment
• WCCP is applied to a single farm.
Notes:
• To apply WCCP, cache servers must be configured as part of a
server farm.
• The WCCP address of a cache server must be configured to the
CID interface address, and not the farm VIP.
• GRE encapsulation is not supported for the communication
between Radware device and a cache server.
• WCCP can be supported by a single farm only.
WCCP Configuration Guidelines:

WCCP v2.0 is configured as part of the server farm configuration, from
the CID Edit Farm window, and involves these steps:
1. Define the Dispatch Method as WCCP.
2. Disable the Check Connectivity Status.
4-76 CID User Guide

Section 4-5 Local Triangulation

Section 4-5, Local Triangulation, explains how response time maybe
reduced by using Local Triangulation and how to configure CID with
Local Triangulation.
• What is Local Triangulation?, page 4-78
• Configuring CID with Local Triangulation, page 4-80
• Local Triangulation with Transparent Servers, page 4-85
CID User Guide 4-77

Local Triangulation
What is Local Triangulation?

The Local Triangulation feature provides the ability to send server’s
responses to a request for service directly to the client. Sending
responses that way reduces the number of hops through which the
reply packet passes. That improves the response time. The traffic
passing through CID is reduced, since most of the incoming requests
are rather small and outbound traffic typically represents the bulk of
data exchanged between clients and servers.
When working in the Local Triangulation mode, the inbound traffic must
flow through CID as in the regular configuration.When a new request
for service arrives, CID selects the best server for the required service.
The response from servers to clients is sent directly to the client,
without passing through CID. The client can be located at the same
network as CID and the servers, or can be located behind the router.
Clients initiated traffic must flow through CID in order to direct it to the
selected server. Traffic from servers to clients can go directly to the
client, without passing through CID.
Figure 4-9 illustrates an example of Local Triangulation configuration.
CID
1 2
Clients Servers
Figure 4-9 Local Triangulation Network Setup
4-78 CID User Guide

Using Local Triangulation requires a server configuration with a

loopback adapter. A loopback address is a valid IP address assigned to
a server but the server does not respond to ARP requests destined to
the loopback address. The address assigned to the loopback adapter
is the Virtual IP address. The server responds directly to client with the
CID Virtual IP, eliminating the need for server-to-client traffic to flow
through the CID.
Local Triangulation is dependent on the operating systems installed on
the farm’s servers. For more information regarding loopback adapter
configuration, consult the manufacturer of the server's OS. Setting up
of loopback interfaces is described in Chapter B, Loopback Interfaces.
Local Triangulation is effective for one-leg topologies, and reduces
traffic on the CID interface.
CID determines the tag that is used according to the destination IP of
the packet after CID has made all the required modifications to the
packet. For example, when using Local Triangulation, CID forwards
packets to servers with a destination IP of the farm, hence these
packets are tagged according to the tag in the configuration of the IP
interface associated with the farm IP.
Note: Local Triangulation is supported only when the CID Content
Based Rule is set to Address Mode, see Table 4-2 on page 22.
CID User Guide 4-79

Local Triangulation
Configuring CID with Local Triangulation

Farm servers can be configured to operate as Local Triangulation type
servers.
Local Triangulation Configuration Guidelines:

Configuring the Local Triangulation mode involves the following steps:
1. Setting up farm servers to operate in the Local Triangulation mode.
2. Enabling this feature in the servers themselves.
Tip: You can add both Local Triangulation type servers and Regular
type servers to the same farm.
4-80 CID User Guide

Example - CID with Local Triangulation

The example shown in Figure 4-10 illustrates a CID configuration that
enables content servers to return cached pages directly to the client,
without having to pass through CID on the way to the client.
CID Virtual IP Address

10.1.1.100
Network Server P1 10.1.1.10
Router
10.1.1.20
Server 1 Server 2 Clients

10.1.1.3 10.1.1.4 10.1.1.1
10.1.1.2
Internet
Figure 4-10 Local Triangulation with Returned Cache Pages
Properties:
• CID is installed in a one-leg topology.
• Network side subnet and server side subnet are on the same LAN.
All connections can be made to the same switch.
• Servers support non-transparent proxy.
• Servers are configured with loopback adaptor with an IP address
which is the same as the CID virtual IP.
• Clients use a proxy server with IP address 10.1.1.100.
CID User Guide 4-81

Local Triangulation
• Clients use HTTP traffic on port 80.
Configuration:
1. Connect the device:
b. In the Set-Up window type the device‘s IP address: 10.1.1.10.
c. Click Ok.
2. Add a default gateway:
d. From the Set-Up window, select Networking > Routing Table.
The CID Routing Table window appears.
e. From the CID Routing Table window, click Add. The Edit Route
dialog box appears.
f. From the Edit Route dialog box, set the following parameters
Address:
Next Hop: 10.1.1.20
IF Number: F-1
Metric: 1
Type: Remote
g. Click Ok to close all windows.
3. Add the servers:
a. From the CID toolbar, click Add and select a local server.
Note: To add servers you must be in Map view and then link them
to the device.
c. From the Server window, set the following parameters
Recovery Time: 0
4-82 CID User Guide

Warm-up Time 0
Connection Limit: 0
Global Server: Cleared
e. In the same manner, add a second server by setting the
Recovery Time: 0
Warm-up Time: 0
Connection Limit: 0
f. Click Add and then Ok.
4. Add a farm:
a. From the Traffic Redirection window, click the Farm tab and
Farm Name: Type the farm name, for example:
Farm 1
Multiplexed for Port: Disable/uncheck.
Admin Status: Select/check.
Content Based Rule: Address
c. Click Apply. Edit CID window remains open.
a. From the Edit CID window, click Add. The CID Farm Server
window appears.
CID User Guide 4-83

Local Triangulation
b. From the CID Farm Server window, set the following

Local Triangulation: Selected
Transparent Mode: Cleared
c. Add a second server by setting the following parameters
Local Triangulation: Selected
Transparent Mode: Cleared
d. Click Ok. The Farm Servers window closes.
6. Add an HTTP policy:
a. From the Traffic Redirection window, select the desired farm
and click Farm Policies. The Farm Policies window appears.
b. From the Farm Policies window, click Modify Farm Policy and
then click HTTP then set the following parameters according to
Policy Name: http
Index: 1
Service: http
Source Address: Any
Direction: One way
c. Click Add Policy and then click Ok.
4-84 CID User Guide

Example - Local Triangulation with Transparent

Servers
CID supports the Local Triangulation scheme using non-transparent
servers. This configuration is applicable for non-configured clients. CID
intercepts client traffic, while responses to clients are transmitted
directly from the servers. The network topology is the same as
described in Local Triangulation, page 4-77.
Properties:
• CID is installed in one-leg topology with default gateway 10.1.1.20.
• Clients are not configured to use a proxy server.
• Clients are configured with CID as their default gateway.
• Clients use HTTP traffic on port 80.
• Servers support transparent proxy mode (no need to define a
loopback adapter).
• Servers are configured with router 10.1.1.20 as their default
gateway.
Configuration:
1. Follow steps 1-7 as explained in: CID with Local Triangulation,
page 4-81.
2. When adding servers in CID Farm Servers window, set the
Server Name: Type the server name.
Local Triangulation: Select.
Transparent Mode: Select.
CID User Guide 4-85

Server Spoofing
Section 4-6 Server Spoofing

Section 4-6, Server Spoofing, describes how CID uses Server Spoofing
in order to provide cache servers with the capability to retrieve pages
on behalf of the client with the client's source address.
• What is Server Spoofing?, page 4-87
4-86 CID User Guide

What is Server Spoofing?

Server Spoofing is a process of one device talking to another device
using the address of a third device. This type of support for CID is
essential to provide cache servers with the capability to retrieve pages
on behalf of the client with the client's source address.
When a client sends a request, CID intercepts the request to the
content server. The content server sends the request to the destination
using the original source address. When the reply arrives to CID, CID
initially directs it to the content server although the reply is destined to
the client address. The content server handles the reply and sends it to
the client. The destination does not know that the cache server has
initiated the request on behalf of the client.
CID User Guide 4-87

Network Address Translation
Section 4-7 Network Address Translation

Section 4-7, Network Address Translation, describes the feature as
implemented in CID.
• NAT Types, page 4-89
• Client NAT, page 4-90
• Server Based NAT, page 4-94
• Farm Based NAT, page 4-106
4-88 CID User Guide

NAT Types
Network Address Translation is the ability to hide the IP addresses of
the clients from the servers. Using this feature causes CID to replace
the original source IP of a request with the configured NAT IP before
forwarding the request to the server.
These are the NAT types:
• Client
• Server
• Server Based
• Farm Based
Full Support for NAT in VLAN Mode

As well as in the Router mode, CID supports NAT in VLAN mode. This
means that if NAT is enabled, you can NAT packets in a VLAN
configuration.
ICMP Support for NAT

Dynamic NAT needs special support for ICMP ICMP (ping) which is a
protocol stack on top of IP (like TCP and UDP).
Ping messages are identified by the Identifier field of the ICMP echo
message. NAT is used on TCP and UDP packets, both containing a
port number field - unlike the ICMP echo message. Therefore, when a
packet requires NAT, CID stores the Identifier field of the echo
message.
CID User Guide 4-89

Client NAT
When client NAT addresses are configured, the NATed IP address
range has to be specified. Up to 128 ranges of NAT addresses can be
configured. Farm addresses are defined for the Farm Based NAT and
the server addresses are defined for the Server Based NAT. When a
client matching to a farm policy approaches a farm, CID selects a
server and NATs the client IP address and port using the configured
NAT address range for a farm or a server. The reply arriving from the
server to CID replaces the NAT address and port with the original client
address and port, before forwarding the reply to the client. When no
NAT addresses are configured in the NAT Addresses Table, Client NAT
is not performed.
Client NAT provides the following capabilities:
• In the installation process, client NAT enables the enforcement of
the return path, so that no special configuration, such as default
gateway or an explicit route, is required on the servers.
• A server, or a firewall in front of the servers, is able to verify that
traffic came through CID, for example in order to limit access to the
servers, thus providing higher security.
4-90 CID User Guide

Figure 4-11 illustrates an example scheme of a CID NAT operation.
Internet Router CID 1 Request Clients

Source Address:
10.1.1.1
4 Return
Destination
Address: 10.1.1.1 10.1.1.1
3 Reply 2 Load Balancing

Destination NAT to Server 10.1.1.2
Address: 20.1.1.1 Source Address:
20.1.1.1
Servers
100.1.1.1
Figure 4-11 CID NAT Operation
Properties:
1. Client 10.1.1.1. sends a request, which is intercepted by CID.
2. CID performs load balancing and selects a server to forward the
clients request. When selected, CID replaces clients original
source address with a NAT address (20.1.1.1 in this example).
3. The server sends a reply to the client using the NAT Address
20.1.1.1 as the destination address.
4. CID receives the reply packet, replaces the destination address
20.1.1.1 with the clients original address 10.1.1.1 and sends it to
the client.
CID User Guide 4-91

NAT Configuration Guidelines:

Configuring NAT involves the following steps:
1. Change the NAT Tuning Parameters.
2. Enable NAT.
3. Configure the NAT Addresses.
To change the NAT tuning parameters:

1. Double click the CID icon. The Set-Up window appears.
2. In the Set-Up window, select the Global tab.
3. In the Global pane, select NAT Settings > Edit Settings. The
NAT Settings window appears.
4. From the NAT Settings window, set the following parameters
NAT Specify the number of IP addresses to be used
Addresses: by NAT.
Range: >0-128. Default: 0.
Note: Before enabling Client NAT, this
parameter must be set to a value higher than
zero.
NAT Ports per Specify the number of ports to be used with
Address: each IP address.
Range: 1024-64512. Default: 64512.
Note: CID uses a port range starting at 1024
that ends according to the NAT Ports per
Address Value.
6. Restart the device to apply the Tuning parameter changes.
To enable NAT:
2. From the Set-Up window, enable/check NAT.
4-92 CID User Guide

To configure NAT addresses:

2. In the Traffic Redirection window enable/check NAT.
3. Click NAT Addresses. The CID NAT Addresses window appears.
4. From the CID NAT Addresses window, set the following
From Address Enables you to configure the NAT for the
entire client range or specifically for
clients listed for an individual application.
Enter the IP Address.
To Addresses: The translated NAT IP address. This can
be any legal address. The default
address is 0.0.0.0. If the NAT IP is set to
0.0.0.0, CID leaves the source address
and port as is. Only the IP address is
ever changed.
Note: When the feature is globally enabled, it should also be enabled
specifically for each required farm or application server. However, NAT
cannot be enabled globally before the Tuning parameter of the NAT
Addresses Table is set to a value higher than 0.
CID User Guide 4-93

Server Based NAT

When server based NAT is selected, CID performs NAT only when the
selected server is up. In farm based NAT, CID always performs NAT
even if the selected server is down.
You can configure NAT for servers when accessing the Internet. The
procedure involves these stages:
1. Configure a new virtual farm with no servers.
2. Configure a farm policy for the farm.
3. Configure NAT for the farm.
Redundancy
In a redundant CID scenario, the same NAT Addresses and farm
policies should be configured on both CID devices.
Client Table mirroring should not be used with Client NAT, as Client
NAT entries in the Client Table are not mirrored.
Note: For more information about redundancy, see Chapter 6,
Redundancy
4-94 CID User Guide

Example - Server Based NAT

Figure 4-12 illustrates a typical setup for Server Based NAT. In this
configuration clients and contents servers are on the same subnets.
Client NAT enables enforcement of the return path so that no special
configuration such as default gateway is required on the servers.
Internet
Router
100.1.1.20
Port 1
100.1.1.10
CID
Virtual IP Address:
10.1.1.100
Port 2
10.1.1.10
Clients Servers
10.1.1.1 20.1.1.1
10.1.1.2 20.1.1.2
Figure 4-12 Server Based NAT Configuration
CID User Guide 4-95

Properties:
• Network side and user side are on the same subnets.
• Users are configured with CID at their default gateway.
• Clients are NATed with the following addresses 10.1.1.200 and
10.1.1.201, cache assigned to a different server.
Configuration:
1. Connect the device and define the interfaces for ports 1 and 2.
a. Double click the CID icon and from the Set-Up window that
appears, type the IP address for the device: 10.1.1.20,
b. Click Ok.
c. Double click the CID icon again. The Set-Up window appears.
d. In the Set-Up window, click Add. The Interface window
appears.
e. In the Interface window, set the following parameters
IF Num: F-2
Broadcast Type: Onefill
Forward Broadcast: Selected
VLAN Tag: 0
f. Click Ok. The CID window remains open.
a. From the Set-Up window, select Networking > Routing Table.
The Routing Table window appears.
b. In the Routing Table window , click Add. The Edit Physical
Route window appears.
c. From the Edit Physical Route window, set the following
Address:
4-96 CID User Guide


Next Hop: 100.1.1.20
IF Number: F-1
Metric: 1
Type: Remote
d. Click Ok, Apply and then click Ok.
3. Add two servers.
Note: In order to add servers you must be in Map view and then
link the server to the device using the link button.
a. From the CID toolbar, click Add and from the dropdown menu
add a local server by setting the following parameters
Recovery Time 0
Warm-up Time 0
Connection Limit 0
b. Click Ok.
c. In the same manner, add another server by setting the
Recovery Time 0
Warm-up Time 0
Connection Limit 0
d. Click Ok.
CID User Guide 4-97

4. Add a farm to the CID:

a. From the CID Application window, click Traffic Redirection.
b. From the Traffic Redirection window, click the Farms tab and
click Add. The Edit CID Farm window appears.
c. From the Edit CID Farm window, set the following parameters
d. Click Ok and double click the Farm icon. The Edit CID Farm
window appears.
e. From the Edit CID Farm window, select the Traffic Settings
tab, disable the Transform Request option and enable the
Reply Direct to Client option.
a. From the Edit CID window, select the Farm Servers tab and
click Add. The CID Farm Server window appears.
b. From the Server Name parameter, add server 2 and click Ok.
Add server 1 and click Ok.
c. From the Edit CID window, click Ok to apply the setup.
6. Add a network:
appears.
b. From the Farm Policies window, click Classes > Networks >
Modify > Add, then set the following parameters according to
Network Name: Local
From Address: 10.1.1.1.
4-98 CID User Guide

c. Click Ok and then Ok again, then click Update Active

Classes.
d. From the Farm Policies window, right click Modify Farm Policy
and select Add. From the pane that appears, set the following
Policy Name: http
Index: 1
Service: http
Direction: One way
Description: Type a relevant description
e. Click Add Policy and click Ok.
7. Enable NAT:
b. From the Set-Up window click the Global tab and select
Advanced Settings. The Advanced Settings window appears.
c. In the Advanced Settings window, click Edit Settings.The CID
Advanced Settings window appears.
d. Change the NAT Addresses parameter to 2.
e. Define the NAT Ports. Click Ok and then Ok again.
8. Reboot the device:
a. Right click on the CID icon and click Reboot.
9. Create NAT entries:
a. From the Traffic Redirection window, click on NAT and select
the NAT checkbox, then set the following parameters according
From IP Address: 10.1.1.200
To IP Address: 10.1.1.200
CID User Guide 4-99

Farm Address: 10.1.1.100

Server Address 10.1.1.11
b. Create another NAT entry as described in the previous step by
setting the following parameters according to the explanations
provided:
To IP Address: 10.1.1.201
Server Address: 10.1.1.1
c. Click Ok.
4-100 CID User Guide

Example - NAT to Remote Servers

The example shown in Figure 4-13 illustrates a configuration of NAT to
remote servers. To avoid direct replies to the client by passing the CID,
it is required to NAT the session. This forces the server to reply to CID
because the source IP is the CID NAT. This example applies for both
configured and transparent users.
Users
101.1.1.10
Router
Port 1
10.1.1.20
Port 1
10.1.1.100
Client Client CID

10.1.1.1 10.1.1.10 VIP Address
10.1.1.2 10.1.1.100
Figure 4-13 NAT to Remote Servers
Properties:
• Network side and users side are on the same subnet.
• Remote content inspection server is on a different subnet:
101.1.10.
• Users are configured to the CID.
• Clients sent to the remote server are NATed using IP Address
200.1.1.1.
CID User Guide 4-101

Configuration:
1. Define the interface for Port 1.
b. In the Set-Up window type the IP address for the device:
10.1.1.100, and click Ok.
a. From the Set-Up window, select Networking > Routing Table.
The CID Routing Table appears.
b. In the CID Routing Table, click Add. The Edit Route window
appears.
c. In the Edit Route window, set the following parameters
according to the explanations provided
Address:
Next Hop: 10.1.1.20
IF Number: F-1
Metric: 1
Type: Remote
d. Click Ok.
3. Add a server:
Note: To add a server you must be in Map view and then link the
server to the device by using the Link button.
a. From the CID main toolbar, click Add and from the dropdown
menu add a local server.
Server Name: Server
Recovery Time: 0
Warm-up Time: 0

Connection Limit: 0
d. Click Ok.
4.Add a farm to the CID:
a. From the CID main window, click APSOlute OS >Traffic
b. In the Traffic Redirection window, click Farms > Add. The
Farm window appears.
c. In the Farm window, set the following parameters according to
d. Click Ok. The Edit CID Farm window remains open.
5. Add the server to the farm:
a. From the Farm window, click Add. The CID Servers window
appears.
b. From the Server Name parameter, add the server and click Ok.
6. Add a network:
a. From the Traffic Redirection window, select the desired farm
and click Farm Policies. The Farm Policies window appears.
b. From the Farm Policies window, click Classes > Networks >
Modify > Add then set the following parameters according to
Network Name: Local
From Address: 10.1.1.1.
c. Click Ok and then Ok again and then click Update Active
Classes.

7. Add a new HTTP:

a. From the Farm Policies window, right click Modify Farm
Policy and then click Add, then set the following parameters
Policy Name: http
Index: 1
Service: http
Direction: One way
Description: NAT to remote servers
configuration.
8. Enable NAT:
b. In the Set-Up window click Global. The Global pane appears.
c. In the Global pane select NAT Settings then click Edit
Settings. The NAT Settings window appears.
d. In NAT Settings window, set the following parameters
NAT Address: 1
NAT Per Ports: 64000
Address:
a. Click Apply and then Ok.
b. From the Traffic Redirection window, select the NAT tab and
enable/check NAT and set the following parameters according


Server Address: Farm NAT
c. Click Apply and then Ok.

Farm Based NAT

When Farm Based NAT is enabled, CID performs NAT even if the
selected server is down.
Farm Based NAT is effective when NATing servers in a farm when
accessing the Internet. In this case, a server source address in a
request (1) is first NATed, and then forwarded to the Internet (2). When
a reply arrives from the internet (3), CID replaces the NATed address
with the servers' address, and forwards the reply (4) to the server.
Internet Router CID Clients

3
1 4
Servers
Figure 4-14 Farm Based NAT Configuration
Farm Based NAT Configuration Guidelines:

1. Define a new farm with a Virtual IP. There is no need to assign
specific servers to the farm.
2. Configure a Farm Policy to intercept the servers traffic.
3. Configure NAT and associate it to the VIP of the farm.

CHAPTER 5
Chapter 5 - Advanced Features
Chapter 5, Advanced Features, presents additional advanced features
of Content Inspection Director.
• Section 5-1: Flow Management, page 5-2
• Section 5-2: Content Load Balancing, page 5-19
• Section 5-3: Special Protocol Treatment, page 5-45
• Section 5-4: SSL Content Check, page 5-65
• Section 5-5: DNS and NTP Services, page 5-78
CID User Guide 5-1

Flow Management
Section 5-1 Flow Management

Section 5-1 Flow Management, describes the CID Flow Management
feature which leverages the Farm Management capability by
sequentially load balancing several server farms, each providing a
different service.
• What is Flow Management?, page 5-3
• Where to Use Flow Management, page 5-6
• Configuring CID with Flow Management, page 5-7
5-2 CID User Guide

What is Flow Management?

The Flow Management capability allows CID to redirect client traffic to
two farms or more. Flow Management is required whenever the first
farm in a farm cluster is spoofed, that is when a regular farm policy
cannot detect the originator of the packet arriving to the device.
Traffic flow designed for a packet involves the following process:
A packet arrives from the client, is examined by CID, load balanced
within a farm, returned from the selected server to CID, examined
again and load balanced within a different farm, and so on.
The farm selection decision is based on the source IP and MAC
addresses. This enables CID to distinguish between clients and
servers, even when the servers are using spoofing.
Figure 5-1 illustrates two types of clients: clients arriving from Network
A and clients arriving from Network B.
Network A CID Access Router Internet
Network B
URL Filters Cache Servers Anti Virus
Figure 5-1 Clients from Networks A & B
CID User Guide 5-3

Flow Management
As shown in Figure 5-2, Network A clients are sequentially redirected

through the farm including these services: URL Filtering, Caching and
Anti-virus checking. Network A clients are registered to a flow cluster
including: URL Filters, Cache Servers and Anti Virus checking.
Network A
1 CID Access Router Internet
Network B 2 3 4 5 6 7
Figure 5-2 Network A Client Redirection

Configuration of this type involves defining an appropriate farm with
servers, and defining the policies to handle the various traffic types for
this farm. Adding farms to a farm cluster ensures control of traffic
distribution by matching defined polices to the correct farms. This may
include sending the traffic through multiple farms when a predefined
policy applies to a specific traffic condition.
5-4 CID User Guide

As shown in Figure 5-3, Network B clients are registered to the

Caching and Anti-Virus services only.
Network A
CID Access Router Internet
Network B 2 3 4 5
Figure 5-3 Network B Client Redirection

Notes:
• NAT may be used only in the last redirection stage (number 6 in the
Figure).
• When using flow management farm policies may not be used in
conjunction with flow management.
CID User Guide 5-5

Flow Management
Where to Use Flow Management

The following table shows where to use Flow Management.
Farm 1 Farm 2 Configuration Mode
Non-Spoofed Non-Spoofed Farm Policies
Non-Spoofed Spoofed Farm Policies
Spoofed Non-Spoofed Flow Management
Spoofed Spoofed Flow Management
Figure 5-4 illustrates the general flow management scheme on CID.
Clients CID Router Internet
Farm 1 Farm 2
Figure 5-4 Flow Management

When only the last farm in the cluster is spoofed, it is possible to use
farm policies in order to redirect the client traffic to the first farm, and
then another farm policy is used to redirect Farm1 traffic to Farm2.
5-6 CID User Guide

Configuring CID with Flow Management

Two examples of CID configurations with flow management are
provided in this section to illustrate the use of various server types:
• Configuration 1: Cache farm and URL filter farm, where all the
servers work in the Spoofed Mode, keeping the client's IP.
• Configuration 2: Cache farm and URL filter farm, where the
servers do not work in the Spoofed Mode. This means that the
sessions initiated by the servers are using the IP address of the
servers and not the original client's IP).
CID User Guide 5-7

Flow Management
Example - Configuration 1: Cache Farm and URL

Filter Farm in Spoofed Mode
All traffic with source IP of the local network and HTTP protocol are
intercepted by CID. Initially the traffic is sent to one of the URL filters,
based on the availability of the servers and on load balancing
decisions. Then the URL filter initiates a new session with the original
client’s IP address. CID intercepts this request and forwards it to one of
the cache servers.
Internet
192.168.1.254
Clients CID Access Router

192.168.1.10-100 192.168.1.253 192.168.1.254
Cache Server Cache Server URL Filter URL Filter

192.168.1.200 192.168.1.201 192.168.1.202 192.168.1.203
Figure 5-5 Cache Farm and URL Filter Farm in Spoofed Mode
5-8 CID User Guide

To configure Cache Farm and URL Filter Farm in Spoofed

Mode:
1. Double click the CID icon the Set-Up window appears.
2. In the Set-Up window, type the IP address: 192.168.1.253, and
click Ok.
3. Right click the CID icon and from the dropdown menu, select
SetUp. The Set-Up window appears.
4. In the Set-Up window, select Networking > VLAN. The Virtual
LAN window appears.
5. In the Virtual LAN window, select VLAN 100001 and assign
(check) ports 1 to 6 to the VLAN. Click Update and Ok.
6. In the Set-Up window, select the existing interface
(192.168.1.253) and click Edit. The Interface window appears.
7. In the Interface window, set the IF Number to VLAN 100001 and
click Ok.
8. Define the default gateway.
a. From the Set-Up window, click Networking > Routing
Table.The Routing Table window appears.
b. In the Routing Table, click Add. The Edit Physical Route
window appears.
c. In the Edit Physical Route window, set the following parameter
according to the explanation provided:
Next Hop Router: 192.168.1.254
and click Ok.
9. Add servers:
Note: To add servers you must be in Map view and then link the
server to the device by using the Link button.
a. From the Content Inspection Director main toolbar, click Add
and from the dropdown menu select a local server. The new
server appears on the network map.
CID User Guide 5-9

Flow Management

Server Name: Server
Admin Status: Check to enable.
Recovery Time: 0
Warm-up Time: 0
Connection Limit: 0
IP Address: 192.168.1.200
Global Server: Do not check.
d. Click Add, and Ok.
e. In the same manner, add the other three servers
(192.168.1.201; 192.168.1.202; 192.168.1.203).
10. Add a Cache Farm to the CID:
a. From the main window, click APSOlute OS > Traffic
b. In the Traffic Redirection window, select the Farm tab and then
click Add. The Farm window appears.
Farm Name: Cache Farm
Multiplexed Farm Port: Disable
The Edit CID Farm window remains open.
11. Bind the Servers to the Cache Farm.
a. From the Farm window, click Add. The CID Farm Servers
window appears.
b. From the Server Name dropdown menu, choose the first server
(192.168.1.200), select the Transparent mode checkbox and
click Ok.
c. In the same manner, add the second server (192.168.1.201)
and click Ok.
5-10 CID User Guide

d. From the Edit CID Farm window, click the Traffic Settings tab,
provided:
Dispatch Method: Cyclic (can be any)
Content Based Rule: Host Name Mode
Use URL Table: Use URL Table
Transform Request: Do not check.
Server Keeps Client Check/select.
IP:
e. Click Ok.
f. Add a second farm as explained in step 10. in the Edit CID
Farm window, set the following parameters according to the
Farm Name: URL Filter Farm
g. Bind servers to the URL Filter Farm as explained in step 9. Add
servers with the following addresses: 192.168.1.202 and
192.168.1.203.
h. After adding the two cache servers, click the Traffic Settings tab
and set the following parameters according to the explanations
provided:
Dispatch method: Cyclic (can be any)
Content Based Rule: Host Name
Transform Request: Cleared
Server Keeps Client Check/select.
IP:
i. Click Ok.
12. Create a farm cluster:
CID User Guide 5-11

Flow Management
a. From the Traffic Redirection window, click Cluster > Add. The
Farm Cluster dialog box appears.
b. In the Cluster Name parameter, type a relevant name, for
example, Cluster1 and click Apply.
c. From the Farm Address parameter, select the URL Filter Farm
(1.1.1.2) and click Add.
d. Click Add again to add the Cache Farm (1.1.1.1) to the cluster.
Now, when a packet arrives to the cluster, first it is forwarded to
the URL filter farm. After being inspected, the packet is sent to
the cache server and then to the Internet.
13. Create a cluster policy:
a. From the Cluster tab, highlight the farm cluster you created and
click Policies. The CID Farm Cluster Policies window appears.
Note: You may be prompted to enable BWM and to reboot the
CID, if so click Ok and follow instructions.
b. From the CID Farm Cluster Policies window, click the Modify
tab and click Add. The Edit Policy window appears.
c. From the Edit Policy window, click New Network. The Edit
Network Table dialog box appears.
d. From the Edit Network Table dialog box set the following
Network Name: Local Network
To Address: 192.168.1.100
e. From the Edit Policy window, set the following parameters
Policy Name: HTTP Traffic
Service Name: HTTP
Source: Local Network
Destination: Any
Farm Cluster: Cluster 1
5-12 CID User Guide

f. Click Ok.
g. Click Update Active Policies.
CID User Guide 5-13

Flow Management
Example - Configuration 2: Cache Farm and URL

Filter Farm in a Non-Spoofed Mode
All traffic with the source IP of the local network and HTTP protocol is
intercepted by the CID. Initially, the traffic is sent to one of the URL
Filters, based on the availability of the servers and on load balancing
decisions. Then the URL Filter initiates a new session using its own IP
address. The CID intercepts this request and forwards it to one of the
Cache Servers (using the second farm policy)
Figure 5-6 illustrates this type of configuration..
Clients CID Access Router Internet

192.168.1.10-100 192.168.1.253 192.168.1.254 192.168.1.254
Cache Server Cache Server URL Filter URL Filter

192.168.1.200 192.168.1.201 192.168.1.202 192.168.1.203
Figure 5-6 Cache Farm and URL Filter Farm in Non-Spoofed Mode
5-14 CID User Guide

To configure Cache Farm and URL Filter Farm in a Non-

Spoofed Mode:
2. In the Set-Up window click Add. The Interface window appears.
3. In the Interface window, type 192.168.1.253 for the IP address
and click Ok.
4. Double click on the CID icon again.The Set-Up window appears.
5. In the Set-Up window select Networking > VLAN. The Virtual
LAN window appears.
6. In the CID Virtual LAN window table, select VLAN 100001 and
assign ports 1 to 6 to the VLAN. Click Update and Ok.
7. In the Set-Up window, select the interface (192.168.1.253) and
click Edit. The Interface window appears.
8. In the Interface window, set the IF Number to VLAN 100001 and
click Ok.
a. From the Set-Up window, click Networking > Routing Table.
b. In the Routing Table window, click Add. The Edit Phyisical
Route window appears.
d. Click Ok.
10. Add servers:
Note: To add a server you must be in
a. From the CID main toolbar, click Add and from the dropdown
menu add a local server.
b. Double click on the Server icon.The Server window appears.
CID User Guide 5-15

Flow Management

Server Name: Server
Recovery Time: 0
Warm-up Time: 0
Connection Limit: 0
IP Address: 192.168.1.200
Global Server: Do not check.
d. Click Add, and Ok.
e. In the same manner, add the other three servers
(192.168.1.201; 192.168.1.202; 192.168.1.203).
11. Add a Cache Farm to the CID:
a. From the main window, click Traffic Redirection. The Traffic
b. From the Traffic Redirection window, click the Farm tab and
then click Add. The Farm window appears.
c. From the Farm window, set the following parameters according
Admin Status: Check/select.
The Farm window remains open.
12. Bind the servers to the Farm:
window appears.
b. From the dropdown menu, choose the first server
(192.168.1.200), check Transparent Mode and click Ok.
c. In the same manner, add the second server (192.168.1.201).
5-16 CID User Guide

d. From the CID Farm Server window, set the following

Dispatch Method: Cyclic (can be any method)
Transform Request: Do not check.
Server Keeps Client IP: Do not check.
e. Click Ok.
13. Add a second farm as explained in step 10. by setting the
Farm Name: URL Filter Farm
Admin Status: Check/select.
14. Bind servers to URL Filter Farm as explained in step 9. Add the
servers with the following addresses: 192.168.1.202 and
192.168.1.203.
15. After adding the two cache servers, click Traffic Settings then set
the following parameters according to the explanations provided:
Dispatch Method: Cyclic (can be any method)
Server Keeps Client IP: Cleared
16. Click Ok.
17. Highlight the URL Filter Farm and click Farm Policies. The Farm
Policies window appears.
18. From the Farm Policies window, click Classes > Networks. The
Networks Table appears.
19. From the Networks Table, click Modify and click Add. The Edit
Network Table appears.
CID User Guide 5-17

Flow Management
20. From the Edit Network Table, set the following parameters
Network Name: Local Network
To Address: 192.168.1.100
21. Create another network for the URL Filters as explained
previously by setting the following parameters according to the
explanations provided:.
To Address: 192.168.1.203
22. Click Ok twice to return to the Farm Policy window and click
Update Active Classes.
23. Add a new policy, right click Modify Farm Policy and then click
Add, then set the following parameters according to the
Policy Name: Clients
Service: HTTP
Source Address: Local Network
Destination Address Any
Direction: Oneway
Farm Cluster: 1.1.1.2
24. Click Add Policy.
Note: This policy intercepts all the HTTP traffic of the clients and
sends it to the URL filter.
5-18 CID User Guide

Section 5-2 Content Load Balancing

CID optimizes performance of anti virus services, URL filtering service
and caching by inspection of the traffic content. CID can perform traffic
bypass or direction of relevant traffic only to anti-virus servers, while
maintaining high availability and accelerated throughput.
Section 5-2 Content Load Balancing, describes the methods for CID
load balancing. This section includes the following topics:
• URL Policies, page 5-20
• URL Policies with Mime-Type, page 5-21
• URL Match, page 5-22
• HTTP Match, page 5-23
• MIME Type Support, page 5-25
CID User Guide 5-19

Content Load Balancing
URL Policies
CID allows you to set traffic redirection policies based on the URL
content in the HTTP GET request. You can block specific URLs, to
make CID avoid retrieving data from the site and reset the connection.
You may also configure CID to avoid caching certain sites, and route
clients directly to the Internet. The URL Policies window is used to
configure those preferred sites.
You can select one of three policies for each URL in the Policies table:
• Direct: This policy can be used for real-time or non-cacheable
pages, for example news and stock quote requests. CID does not
send these requests to a cache server; but sends them directly to
the Internet, thus saving time and providing a quick response.
• Block: This policy effectively enforces limited control on clients.
When a client requests a particular site that has been blocked, CID
disallows the request to that URL. Good examples of this are adult
entertainment or gambling sites.
• Local Server: This policy enables the CID to direct a specific URL
to a specific cache server within a certain cache farm. It is a
powerful way to enforce limited control on clients.
URLs can be manually configured or they can be loaded from the list.
When implementing URL policies, system administrators are required
to set the Content Based Rule to URL Match, to enable the users to
configure the URL Policies Table.
URL Policy Configuration Guidelines:

1. Add a CID device and assign an IP address (Connect).
2. Add a farm:
a. From the main window, click APSolute OS > Traffic
b. From the Farms table, double click on the farm. The Farm
window appears.
c. From the Farm window, click on Traffic Settings and change
the Content Based Rule to URL Match.
d. Click Ok.
5-20 CID User Guide

URL Policies with Mime-Type

One of the common configurations of CID is Anti-Virus load balancing.
In order to improve network performance and accelerate the traffic, CID
redirects to the selected anti-virus server only the non-trusted traffic,
however the trusted traffic (configured by the user) is sent directly to
the internet without scanning. By not scanning images and other
trusted data, CID improves the Anti-Virus performance by 500%.
When a Content Base Rule is configured to "URL Match" or "HTTP
Match" or "Mime-Type" and URL Policies are in use, the URL Policies
have precedence over URL Match and HTTP Match. For example - if
the user configured a URL Policy for www.radware.com with a "Direct"
mode, and also a URL Match - ".gif" with a "Block" mode, a request for
www.radware.com/logo.gif would be sent directly to the internet. When
a non-trusted file type is configured for a specific file type, and the file
type appears in a URL with a direct mode, the file is sent directly to the
internet without virus inspection.
CID User Guide 5-21

URL Match
In this mode, the CID analyzes the URL in all client HTTP requests.
The URL string of the client request is parsed and decisions are based
on whether a match is made to a set of predefined criteria or not.
The URL Match policies are configured per cache farm. Each policy
instructs the CID to forward the request to a local cache server, forward
directly to the Internet, or block the request in case a URL string
matches the string in the policy. Also for each cache farm, a “default”
policy is created that defines for CID what to do if no matching URL
Match polices are found - send direct or to a local cache.
For example, a farm can be configured to send all traffic to the Internet
by default and a policy can be set to send all requests with “gif” to the
local servers. This would cause only the requests for pictures in the.gif
format to be redirected to the cache servers.
Up to 50 URL Match policies can be configured per farm.
5-22 CID User Guide

HTTP Match
CID can make load balancing decisions based on the HTTP header
information. When CID works in the HTTP Match mode, any HTTP
header field can be used, allowing CID to search in the HTTP reply
packet for any field, such as the user-agent, the accept-language, the
host, or the content-type field.
When implementing HTTP Match policies, you can set one of three
policies for each URL that is listed in the table:
• Direct: This policy can be used for sending traffic directly to the
Internet, without sending it to the servers. When CID load balances
anti-viruses, it searches in the Content-Type field for the trusted
files and sends the trusted files directly to the Internet.
• Block: This policy effectively enforces limited control on clients.
When a client requests a particular content that has been blocked,
CID disallows the request to that traffic type. URLs can be blocked
using this mode. CID searches for the host field of the HTTP
header and blocks predefined hosts. CID can also block specific
file types, based on the Content-Type field.
• Local Server: This policy enables CID to direct specific traffic to a
specific cache server within a certain cache farm, thus effectively
enforcing limited control on clients. When CID servers reverse the
cache servers, it is possible to redirect clients to the cache servers
based on their language or browser type.
HTTP Match Configuration Guidelines:

Configuring an HTTP Match policy involves two steps:
1. Define the HTTP header field to be searched in the HTTP Match
Table, by selecting Match Method: HTTP Match.
For example: “user-agent” or “accept-language”.
2. Define the HTTP field value (Token) and the associated policy in
case of a match between the HTTP header field and the token
value, by selecting Match Method: Token Match.
For example: “en”, “se”.
CID User Guide 5-23

To configure an HTTP match policy:

1. Add a CID device and assign an IP address.
2. Add a farm.
3. From the Traffic Redirection window table, double click on the
farm item you want to configure. From the Farm window, click
Traffic Settings and change the Content Based Rule to HTTP
Match.
4. From the Traffic Redirection window, click Redirection and
change the Match Method to HTTP Match.
5. Click Add and add an HTTP Header of Accept-Language.
6. From the Traffic Redirection window, change the Match Method to
Token Match and then click Add.
7. Change the mode to Block and for the Token Value type the
language code (for example - “en” for English, “it” for Italic).
5-24 CID User Guide

MIME Type Support

Some Content Security servers use security policies based on Multi-
purpose Internet Mail Extensions Types. A Multi-purpose Internet Mail
Extension (MIME) is a specification for formatting non-ASCII messages
so that they can be sent over the Internet and displayed by a client-side
application (typically e-mail applications, or Web browsers).
What is MIME Type Support?

CID has unique features to support the load balancing of anti-virus
servers with the ability to decide what traffic to redirect to those
servers, based on the MIME types. In order to reduce the load on the
anti-virus software, CID pre-windows all network traffic, differentiating
between trusted and non-trusted files, and sending to the servers only
non-trusted traffic. This subsequently eliminates bottlenecks and
accelerates content delivery. Many files, such as images, video and
sound are unlikely to contain viruses, and CID can send those files
directly to the client or Internet without the need to scan them. By doing
so, the load on the anti-virus servers is reduced.
How MIME Type Support Works

When CID load balances anti-virus servers, set the Content Base Rule
to “MIME Type”. The traffic flow when using MIME Type support is as
follows:
• Intercepting Clients Requests: CID intercepts GET requests that
arrive from the clients. CID either sends the traffic to one of the
anti-virus servers for inspection, or forwards the traffic to the
Internet, depending on the File Type used in the GET request. CID
redirects all the traffic to the selected anti-virus server (bases on
load balancing decisions) excepts Trusted File Types.
• Inspecting Servers Reply: CID inspects the MIME Type used in
the server's reply as appeared in the HTTP header. By the MIME
Type contained in the reply, CID can tell if the reply is trusted or not:
• A reply to an non-trusted request is always sent to the Content
Server (the same server that handled the request).
• A trusted reply to a trusted request is sent directly to the client
CID User Guide 5-25

• An distrusted reply to a trusted request is sent with RST to the

client. If there are retransmissions from the server, they will be
discarded.
Notes:
• In order to be able to inspect each GET received from the client,
CID breaks HTTP 1.1 persistency.
• The Content Servers must be locally connected to CID, as CID
uses their MAC address for forwarding.
MIME Type Support Configuration Guidelines:

1. Define ‘trusted’ traffic:
You can configure trusted and distrusted file types using the URL
Match Table. Trusted file types should be configured with the Direct
policy. This configuration influences the behavior of CID for
outbound traffic, from the clients to the Internet.
2. Check returned data:
You can configure the trusted and distrusted MIME file types using
the HTTP Match Table. First specify the relevant HTTP Header that
is to be inspected (typically Content-Type), in the HTTP Header
Settings window. Then specify the MIME Types in the Token
Settings window. MIME Types can be configured with Direct policy
(meaning - a trusted MIME Type), or with Block policy (distrusted),
which is the default.
Up to 15 MIME Types can be configured. Typical MIME Types that
are considered trusted are images (MIME Types image/gif, image/
jpeg and image/tiff), video (MIME Types video/mpeg, video/
quicktime, video/x-msvideo and video/x-sgi-movie) and audio
(MIME Types audio/mpeg, audio/x-pn-realaudio, audio/x-realaudio
and audio/x-wav).
Tip: Alternate content-types can be returned per requested file type.
It is recommended to configure alternate content-types as well.
5-26 CID User Guide

Notes:
• When configuring the URL Match Table, it is recommended to add
values in the format of '.jpg ' (with a space) rather than '.jpg'. This is
not required for content-type values (should remain '/jpg').
• When configuring values such as '.jpg ' in the URL Match table, it is
recommended to configure additional HTTP content-type matches
in addition to '/jpg' such as '/jpeg' and '/jpe'.
Examples:
jpg /jpg, /jpeg, /jpe
tif /tif, /tiff
mpeg /mpeg,/mpg,/mpe
html /htm, /html
Support Dual Interface Servers for MIME Type

When using URL Type MIME Type, CID supports multi-interfaces
Application Servers, as well as single interface Servers. If an
Application Server has two interfaces, you need to define the second
address of the server as the alternate server address. Using this
feature, CID forwards requests to the IP address of the server (to the
“internal interface” of the server). If the reply from the Application
Server is sent to CID through another interface of the server, which is
associated with the Alternate IP address (server’s “external interface”),
the CID forwards the replies to that interface. Using two interfaces
enables a better server performance.
CID User Guide 5-27

Configuring CID with Anti-Virus Servers

The following configuration examples show how CID performs content
Load Balancing by means of the Anti-Virus servers. The CID
configurations presented here enable interception of HTTP, FTP and
SMPT traffic for the clients. All FTP and SMTP traffic is load balanced
between the anti-virus servers. HTTP traffic is load balanced according
to content type.
All the examples shown here include support for MIME Type. The
difference between the configurations is in the servers’ interface usage:
• Single Interface Servers with MIME Type Support.
• Dual Interface Servers with MIME Type Support.
• Single Interface Servers in Proxy Mode with MIME Type Support.
In the following examples CID intercepts all the traffic that passes
through its interfaces, and load balances the relevant traffic among the
anti-virus servers within the farm. This topology is easy to implement
and does not require any changes in the network. In complex networks,
where there are several IP networks behind the CID, there is no need
to define any static routes, because the CID can configure the network
topology using the “VLAN auto learn” feature.
5-28 CID User Guide

Example - Single Interface Servers with MIME Type

Support
The example in Figure 5-7 illustrates the configuration of anti-virus
servers which use a single interface - all traffic is sent to the interface of
the anti-virus server, and is returned from the same interface.

192.168.1.253 192.168.1.254
Server 1 Server 2
192.168.1.100 192.168.1.101
Figure 5-7 Single Interface Servers with MIME Type Support
Configuration:
1. Double click the CID icon. The CID Connect to Device window
appears.
2. Type the device‘s IP address (for this example 192.168.1.253)
and click Ok.
3. Assign ports to VLAN.
a. Double click the CID device icon again.The Set-Up window
appears.
b. In the Set-Up window, select Networking > VLAN. The CID
CID User Guide 5-29

c. Select VLAN 10001.

d. Add (check) ports 1- 4 to the VLAN.
e. Click Update and Ok.
4. From the Set-Up window, select the existing interface
(192.168.1.253) and click Edit.The Interface window appears.
5. In the Interface window, set the IF Num value to 100001 and then
click Ok.
6. Add a static route to the default gateway:
a. From the Set-Up window, select Networking >Routing Table.
The Routing Table appears.
b. Click Add. The Edit Physical Route window appears.
7. Add local servers.
a. From the main toolbar, click Add and from the dropdown menu
add a local server, by defining the following parameters
IP Address: 192.168.1.100
IP Address: 192.168.1.101
8. Create a farm:
a. From the main window, select APSolute OS >Traffic
b. In the Traffic Redirection window, select the Farms tab and
then click Add. The Farm window appears.
5-30 CID User Guide


the explanations provided
Farm Name: Anti_Virus_Farm
a. In the Farm window, click Add.The CID Farm Servers window
appears, set the following parameters according to the
Transparent Mode: Selected
b. In the same manner, add the second server and click Ok.
10. In the Farm window, select Traffic Settings. The Traffic Settings
pane appears.
11. In the Traffic Settings pane, set the following parameters according
Dispatch Method: Cyclic
Content Based Rule: MIME Type
Use URL Table: Do not use URL Table
Server Keeps Client IP: Selected
12. In Traffic Redirection window, select Redirection. The
Redirection pane appears.
13. In the Redirection pane ensure that the Match Method is set to
URL Match.
14. Click Add. The URL Match window appears.
15. In the URL Match window, set the following parameters according
Farm IP: 1.1.1.1
URL Match Policy: Direct
Matching URL: gif, jpeg, avi, mid, tiff
CID User Guide 5-31

URL Description: Type the relevant URL Description

16. In the Traffic Redirection window, click the Redirection tab. The
17. In the Match Method dropdown menu, select HTTP Match and
click Add. The HTTP Match window appears. In the HTTP
Header field, type: content-type, and click Ok.
18. In the same manner as explained in step 13 and 14, select the
Token Match, Match Method and click Add. The Token Match
window appears.
19. In the Token Match window, set the following parameters
Farm IP: 1.1.1.1
Mode: Direct
Token Value (type in) /extension/gif/jpg/avi/mid
20. In the Traffic Redirection window, select the Farms tab, select the
Anti_Virus farm (1.1.1.1) and click Farm Policies. The Farm
21. Configure classes.
a. In the Farm Policies window, click Classes. The Classes
window appears.
a. In the Classes window, click Networks. The Network Table
window appears.
b. In the Network Table, click the Modify tab and then click Add.
The Edit Network Table appears.
c. In the Edit Network Table, set the following parameters
Network Name: Local Net
Network Mode: IP Mask
IP Address: 192.168.1.0
Address Mask: 255.255.255.0
d. Click Ok.
5-32 CID User Guide

e. In the Classes window, right click on the Grouped service

under Services, and select New Service. The New Service
Pane appears
f. In the New Service pane set the following parameters
Service Name: Virus_Scan
Basic Services: Check the protocols supported by
the anti-virus: HTTP; SMTP; FTP
g. Click Add Service and then Ok.
22. Create a new farm policy:
a. In the Farm Policies window, right click Modify Farm Policy
and click Add. The Policy pane appears.
b. In the Policy pane, set the following parameters according to
Policy Name: Virus Scan
Index: 1
Service: Virus_Scan
Source Address: Local_net
Direction: Oneway
c. Click Add Policy and then click Update Active Classes.
d. Click Ok to apply the policy setup and exit the window.
CID User Guide 5-33

Example - Dual Interface Servers with MIME Type

Support
Figure 5-8 shows a configuration example of anti-virus servers with two
interfaces that operate as a gateway. All the traffic is sent to one
interface of the anti-virus server, and the returned traffic is sent to
another interface.
Local Clients CID Access Router Internet

192.168.1.1-99 192.168.1.253 192.168.1.254
10.10.1.100 10.10.1.101
10.10.2.100 10.10.2.101
Figure 5-8 Dual Interface Gateway Servers with MIME Type Support
Properties:
• Connect the local network and the access router to ports 1 and 2.
• Connect the anti-virus servers to port 3 and 4 (network 10.10.1.0)
and port 5 and 6 (network 10.10.2.0).
• Set the default gateway of the anti-virus servers to 10.10.2.1.
• Set a static route on the anti-virus server to route network
192.168.1.0/24 to 10.10.1.1 (to enable the anti-virus server to
return the traffic back to the CID).
5-34 CID User Guide

Configuration:
1. Double click on the CID deviceicon. The CID Connect to device
window appears. Type the device‘s IP address (for this example
192.168.1.253) and click Ok.
2. Assign ports to VLAN:
a. Double click on the CID icon. The Set-Up window appears.
b. From the Networking menu, select VLAN. The Virtual LAN
window appears.
c. Select VLAN 100001 and assign ports 1 and 2 to the VLAN.
Click Update.
d. Click Add and add VLAN 100002 and VLAN 100003.
e. Assign ports 3 & 4 to VLAN 100002, and ports 5 & 6 to VLAN
100003. Click Update and Ok.
3. In the Set-Up window select the existing interface (192.168.1.253)
click Edit.The Interface window appears. Set the IF Num to
100001 and then click Ok.
4. Create two more interfaces:
b. Click Add. The nterface window appears.
c. From the Interface window, set the following parameters
VLAN 100002: 10.10.1.1
VLAN 100003: 10.10.2.1
a. From the Set-Up window select Networking >Routing Table.
c. From the Edit Physical Route window set the following
parameter according to the explanation provided:
6. Add a local server:
CID User Guide 5-35

add a Local server by defining the following parameters
IP Address: 10.10.1.100
10.10.2.100
Click Add and then click Ok.
7. Add the second server as explained in the previous step and set
these parameters:
IP Address: 10.10.1.101
10.10.2.101
Click Add and then click Ok.
8. Create a farm:
a. From the CID main window, select APSolute OS > Traffic
b. Click Farm > Add. The Farm window appears.
a. In the Farm window click Add.The Farm Servers window
appears.
b. From the CID Farm Servers window, set the following
c. Add the second server. Click Ok.
5-36 CID User Guide

10. In the Farm window select Traffic Settings. The Traffic Settings
pane appears.
11. In the Traffic Settings pane, set following parameters according to
Server Spoofing: Selected
Trap All Ports: Cleared
Click Ok.
12. From the main window, select APSolute OS > Traffic
Redirection > Redirection. The Redirection pane appears.
13. In the Redirection pane, ensure that the Match Method is set to
URL Match and click Add. The URL Match window appears.
14. In the URL match window, set the following parameters according
Farm IP: 1.1.1.1
URL Description: Type the relevant URL Description.
15. From the Redirection tab, set the Match Method to HTTP Match,
click Ok. The HTTP Match window appears. In the HTTP Header
field type: content-type.
Click Ok.
16. From the Traffic Redirection window, select Redirection and
Token Match window appears:
Farm IP: 1.1.1.1
Mode: Direct
CID User Guide 5-37

17. From the Traffic Redirection window click Farms , select the
Anti_Virus farm (1.1.1.1) and click Farm Policies. The Farm
18. In the Farm Policies window click Classes and then Networks.
The Network Table appears.
19. In the Network Table select the Modify tab and then click Add.
The Network Table appears.
20. In the Network Table set the following parameters according to
IP Address: (according to this example)
192.168.1.0
21. From the Classes window, right click Grouped and select New
Service, then set the following parameters according to the
Basic Services: Select the protocols supported by the
anti-virus: HTTP; SMTP; FTP
Click Add Service and then Ok.
a. From the Farm Policies window right click on Modify Farm
Policies and click Add and set the following parameters
Index: 1
Service: Virus_Scan
Direction: Oneway
5-38 CID User Guide


b. Click Add Policy and then click Update Active Classes. Now
click Ok.
CID User Guide 5-39

Example - Single Interface Servers in Proxy Mode

with MIME Type Support
The example in Figure 5-9 illustrates a configuration where the anti-
virus servers are also proxy servers and the clients are configured to
use these servers. In this example, the clients are not configured. CID
intercepts the clients’ requests and transforms them to a proxy form.

192.168.1.254
192.168.1.253
Server 1 Server 2
192.168.1.100 192.168.1.101
Figure 5-9 Single Interface Proxy Servers with MIME Type Support
Configuration:
1. Connect the device.
a. Double click on the CID device icon. The CID Connect to
device window appears.
b. Type the device‘s IP address (for this example 192.168.1.253)
and click Ok.
2. Add ports to the VLAN:
a. Double click on the CID icon again.The Set-Up window
appears.
5-40 CID User Guide

b. From the Networking menu, select VLAN. The Virtual LAN

window appears.
c. Select VLAN 10001. Add ports 1- 4 to the VLAN. Click Update
and Ok.
d. From the Set-Up window, select the existing interface
(192.168.1.253) and click Edit. The Interface window appears.
e. Set the IF Num value to 100001 and then click Ok.
a. In the Set-Up window, select Networking > Routing Table.
according to the explanation provided.:
Next Hop: 192.168.1.254
d. Click Ok.
4. Add two servers:
add a local server by defining the following parameters
IP Address: 192.168.1.100
following parameters according to the explanations provided
IP Address: 192.168.1.101
5. Create a farm:
a. In the main window, select APSolute OS > Traffic
b. In the Traffic Redirection window, select the Farms tab and
click Add. The Farm window appears.
CID User Guide 5-41


window appears.
b. In the CID Farm Servers window, set the following parameters
c. In the same manner, add the second server and click Ok.
7. Define the content based rules:
a. From the Farm window, select Traffic Settings then set the
Server Keeps Client Selected
IP:
b. Click Ok.
c. In the Traffic Redirection window, select Redirection. The
d. In the Redirection pane ensure that the Match Method is set to
URL Match and click Add. The URL Match window appears.
e. From the URL Match window, set the following parameters
Farm IP: 1.1.1.1
5-42 CID User Guide


URL Description: Type the relevant URL Description.
f. In theTraffic Redirection window, click Redirection . Set the
Match Method to HTTP Match and click Ok. The HTTP Match
window appears.
g. In the HTTP Header field, type: content-type and click Ok.
h. In the Traffic Redirection window, select Redirection, set the
Match Method to Token Match.
i. Click Add. The Token Match window appears.
j. In the Token Match window, set the following parameters
Farm IP: 1.1.1.1
Mode: Direct
8. Define Classes:
a. In the Traffic Redirection window, select the Farms tab, and
select the Anti_Virus farm (1.1.1.1) and click Farm Policies.
The Farm Policies window appears.
b. Click Classes > Networks. The Network Table window
appears.
c. Select the Modify tab and then click Add. The Network Table
window appears.
d. In the Network Table window, set the following parameters
IP Address: (for this example) 192.168.1.0
e. In the CID Classes window Services list, right click Grouped
and select New Service, then set the following parameters
CID User Guide 5-43

Basic Services: Check the protocols supported by

the anti-virus:
Values: HTTP; SMTP; FTP; POP3
f. Click Add Service and then Ok.
a. In the Farm Policies window, right click on Modify Farm
Policies and click Add, then set the following parameters
Index: 1
Service: Virus_Scan
Direction: Oneway
b. Click Add Policy and then click Update Active Classes. Click
Ok.
5-44 CID User Guide

Section 5-3 Special Protocol Treatment

Section 5-3 Special Protocol Treatment, explains some advanced
features of CID and how these features work in conjunction with CID.
• FTP Content Management, page 5-46
• POP3 Support, page 5-53
• RADIUS Based Classification, page 5-58
• HTTP Advanced Features, page 5-62
CID User Guide 5-45

FTP Content Management
FTP Proxy Support

When deploying an FTP (File Transfer Protocol) proxy server for FTP
caching or FTP content inspection, CID provides special treatment for
these servers. CID intercepts FTP sessions of non-configured client
and load balances it to the FTP proxy server farm. CID transforms the
client “username: password” command to
"username:password@domain". This transformation allows the FTP
proxy server to extract the original destination FTP host and then to
open the FTP session to that host, on behalf of the client. This process
is transparent for the client. By default, CID supports both passive FTP
sessions and active FTP sessions.
5-46 CID User Guide

Figure 5-10 shows a typical FTP Proxy Content Management setup.
Internet FTP Content Servers

100.1.1.1
100.1.1.2
Access Router
100.1.120
Network Side Port 2

100.1.1.10
CID
Virtual IP Address
10.1.1.100
Port 1
Client 1 Client 2
10.1.1.1 10.1.1.2
Figure 5-10 FTP Proxy Content Management Configuration
Properties:
• Network side and users side are on different IP subnets.
• Users are not configured to the CID.
• Content servers work in FTP Proxy mode.
• The delimiter ('@') is proxy dependent, and may vary.
• Configuring ftp-session service supports both passive and active
FTP sessions.
CID User Guide 5-47

Configuration:
a. Double click on the CID icon and from the CID Connect to
device window that now appears, type the device‘s IP address:
10.1.1.10 and click Ok.
b. Add the second IP address: Double click on the CID icon. The
Set-Up window appears.
c. Click Add. The Interface window appears.
d. In the Interface window set the following parameters according
IF Num: F-2
Click Ok to exit all windows.
2. Add the default router and a default gateway:
b. In the Set-Up window, select Networking > Routing Table.
c. From the Routing Table, click Add. The Edit Physical Route
window appears.
d. In the Edit Physical Route Table window, set the following
Address:
Next Hop: 100.1.1.20
IF Number: F-2
Metric: 1
Type: Remote
e. Click Ok to exit all windows:
3. Add the servers:
5-48 CID User Guide

a. From the main toolbar, click the Add (+ ) and from the
dropdown menu add a local server by defining the following
4. Add a farm:
a. From the Traffic Redirection window, select Farms. The Farm
pane appears.
b. In the Farm pane click Add. The Farm window appears.
Transform Request: Selected
d. Ensure that the Transparent Mode is enabled.
a. In the Traffic Redirection window list of farms, select the farm
and click Add. The Farm window appears.
b. In the Farm window, click Add. The CID Farm Servers window
appears.
c. In the CID Farm Servers, set the following parameters
CID User Guide 5-49


Server Delimiter: @
a. From the main toolbar, click Traffic Redirection. The Traffic
b. In the Traffic Redirection window list of farms, select the farm,
then click the Farm Policies button. The Farm Policies window
appears.
c. In the Farm Policies window, click the Classes button. The
d. In the CID Classes window, click Networks. The Network
Table window appears.
e. Click the Modify tab and from the Modify pane, click Add and
provided:
Network Name: Local
f. Click Ok and then Ok to return to the Farm Policies window.
a. In the Farm Policies window, right click Modify Farm Policy
and select Add. From the pane that appears, set the following
Policy Name: http
Index: 1
Service: ftp session
Direction: oneway
5-50 CID User Guide

Description: FTP Proxy Configuration

CID User Guide 5-51

FTP Address Multiplexing Support

Traditional load balancing of FTP sessions supports only cases where
the same FTP server controls both the Control Session and Data
Session of the File Transfer Protocol.
CID supports load balancing of FTP sessions where the FTP server,
which hosts the Control Session, refers the FTP client to use a different
FTP server for the Data Session using the PASV command.
Configuration
No special configuration is needed by the user in order for CID to
support the FTP Address Multiplexing.
Transparent FTP Support

The Transparent FTP feature supports FTP content servers that
intercept FTP sessions transparently and open a session on behalf of
the client. CID redirects FTP clients to proxy servers that support fully
transparent FTP. This mode is in addition to the proxy FTP.
5-52 CID User Guide

POP3 Support
CID supports interception and redirection of POP3 (Post Office
Protocol) traffic destined to an anti-virus server. POP3 sessions are
transparently intercepted and redirected to the servers. The sessions
are intercepted and sent to the IP address of the server, opening a
POP3 session with the proxy agent of the server. Because the client is
unaware of the server's existence, the client believes that it is directly
connected to the POP3 host on the Internet.
To provide POP3 support, CID transforms the client's “USER”
command from USER[username] to:
USER[user_name#destination_IP]. This transformation allows
the anti -virus to extract the destination POP3 host and then to open
the POP3 session to that host, on behalf of the client. This is done
transparently to the client.
POP3 Support Configuration Guidelines:

• Because redirection is done to the mail server's IP address, return
traffic from the server to the client must traverse through the CID.
This is necessary, so proper IP address translation can be
performed.
• To intercept POP3, configure port 110 (POP3 assigned port) as a
port to be intercepted.
• Server Delimiter (#) is a configurable parameter that can be set in
the Application Servers window.
CID User Guide 5-53

Figure 5-11 illustrates a typical configuration for POP3 Interception

where CID intercepts and redirects POP3 sessions to a proxy mail
server. The users are unaware of the proxy server existence, and
assume that they are directly connected to the POP3 server on the
Internet. This configuration is used for the load balancing of TrendMicro
InterScan e-mail antivirus servers.
Internet Anti Virus Servers

100.1.1.1
Router
100.1.120
Network Side Port 2

100.1.1.10
CID
Virtual IP Address
10.1.1.100
Port 1
Client 1 Client 2
10.1.1.1 10.1.1.2
Figure 5-11 POP3 Interception Configuration
5-54 CID User Guide

To configure POP3 Support:

a. Double click on the CID device icon. The CID Connect to
Device window appears.
b. From the CID Connect to device window, type the device‘s IP
address: 10.1.1.10. Click Ok.
c. Add the second IP address: Double click on the CID icon. The
d. In the Set-Up window, click Add. The Interface window
appears.
e. In the Interface window, set the following parameters according
IF Num: F-2
f. Click Ok to exit all windows.
2. Add the default router and a default gateway.
a. Double click on the CID device icon. The Set-Up window
appears.
b. In he Set-Up window, click on Networking and select Routing
Table. The Routing Table appears.
c. In the Routing Table window, click Add. The Edit Physical
Route window appersa.
d. In the Edit Physical Route window, set the following parameters
according to the explanaitons provided:
Address:
Next Hop: 100.1.1.20
IF Number: F-2
Metric: 1
Type: Remote
e. Click Ok to exit all windows.
CID User Guide 5-55

3. Add the servers to the map:

a. From the CID toolbar, select the Add menu and from the
dropdown menu add a local servers by defining the following
a. Click Add and then click Ok.
4. Add a farm:
a. In the Traffic Redirection window, click Farm > Add. The
Farm window appears.
b. In the Farm window, set the following parameters according to
Tip: Ensure that Transparent Mode is enabled.
c. Click Ok.
a. In the Traffic Redirection window, select the farm and then click
Add. The Farm window appears.
b. In the Farm window, click Add. The CID Farm Servers window
appears.
c. In the CID Farm Servers window, set the following parameters
5-56 CID User Guide


Server Delimiter: @
d. Click Add to apply your changes and then Ok.
a. From the main toolbar, select APSOlute OS > Traffic
b. From the Traffic Redirection window, select the farm and then
click the Farm Policies. The Farm Policies window appears.
c. From the Farm Policies window, select > Classes >Networks
> Modify > Add, then set the following parameters according to
the explanations provided
Network Name: Local
d. Click Ok and then Ok to return to the Farm Policies window.
a. In the Farm Policies window, right click Modify Farm Policy >
Add. The Modify Farm Policy pane appears.
b. In the Modify Farm Policy pane, set the following parameters
Policy Name: POP3
Index: 1
Service: POP session
Direction: Oneway
c. Click Add Policy and then Ok to exit the window.
CID User Guide 5-57

RADIUS Based Classification

The RADIUS service for ISPs allows authentication and storage of the
accounting information for dial-in users. For general information about
this protocol, Chapter D, Glossary.
CID enables you to set Flow Cluster policies according to the RADIUS
attributes. CID monitors the traffic and checks the user privileges in the
RADIUS messages. According to this information, CID assigns clients
to networks that are added to the Network Table. These networks can
then be used for defining farm policies, flow clusters, BWM policies and
so on.
RADIUS Based Classification enables CID to provide service to clients,
whose source IP addresses are dynamically changed each time they
dial. In this case, the CID listens to the communication between the
NAS and the RADIUS, and based on the Username and Password, the
RADIUS sends to the NAS a predefined value in one of the attributes.
When same attribute is configured on CID and when CID detects this
attribute, it automatically adds the client's IP to a dynamic network that
can be classified.
CID performs RADIUS Based Classification when working in these
modes:
• Transparent Mode: The device transparently intercepts RADIUS
traffic between the Client and the RADIUS Server. This mode does
not require any configuration, but the network topology requires
placing CID between the NAS and the RADIUS server, as shown in
Figure 5-12.
• Proxy Mode: The device acts as a proxy RADIUS between the
NAS and the RADIUS server. This mode enables CID to trace the
data while forwarding the packets between the servers. This mode
requires configuration of the NAS to use CID as the RADIUS
server.
After intercepting the RADIUS messages, CID parses the messages to
extract user allocated services and user IP address. CID then imposes
the allocated services according to user IP.
Note: RADIUS tracking mechanism is transparent to the user.
5-58 CID User Guide

Figure 5-12 illustrates a typical RADIUS configuration.
Farm 1 Farm 2
Clients NAS CID Router Internet
RADIUS Server
Figure 5-12 RADIUS Configuration
NAS Secret
NAS and RADIUS server share a “secret” that uses a combination of
password encryption and response authentication. A RADIUS server
can be configured to use different secrets, according to the source IP of
the received packet (NAS IP). When CID is used as the RADIUS proxy,
the source IP is always the CID IP, so the RADIUS can use only one
secret.
For this reason, the Proxy RADIUS needs to use another table with the
following record structure:
NAS IP NAS Secret
CID User Guide 5-59

When a message arrives from a NAS IP that exists in the NAS/Secret

Table, the proxy RADIUS decrypts the password using the NAS secret,
and decrypts it using its secret before sending it to the RADIUS server.
If the NAS IP does not exists in the NAS/Secret Table, the password
field remains untouched. The same applies to a message from a
RADIUS to a NAS, regarding the Authenticator field.
In the Transparent mode (Sniffing) CID does not alter passwords or
Authenticators.
To configure RADIUS Based Classification:

1. From the main window, select Device > Device Permissions. The
2. In the Device Permissions window, select the Proxy RADIUS tab,
provided:
Main RADIUS IP Address: The IP address of the primary
radius server for authentication.
Main RADIUS The access port number of the
Authentication Port No: primary radius server.
Values: 1645; 1812.
Main RADIUS Accounting The access port number of the
Port No: primary radius server for
accounting.
Main RADIUS Secret: The authentication password for
the primary radius server.
Note: These four parameters are mandatory in order to define a
RADIUS Proxy server. You can also define a Backup RADIUS
Proxy Server.
3. In the Device Permissions window, click Rules. The Proxy
RADIUS Rules window appears.
4. In the Proxy RADIUS Rules window, set the following parameters
Attribute ID: The relevant Attribute ID.
Attribute Value: The values for the radius packet.
5-60 CID User Guide

Network: The name of the network the user

belongs to.
5. Click Add and then Ok.
6. Configure the NAS Secrets table:
a. Inthe Device Permissions window, click NAS Secret.
The Proxy RADIUS NAS Secrets window appears.
b. In the Proxy RADIUS NAS Secrets window, set the following
NAS IP: The IP address of the NAS.
NAS Secret: The NAS Secret.
c. Click Add > Ok.
CID User Guide 5-61

HTTP Advanced Features
Enhanced URL Retrieval

An HTTP request consists of several headers containing additional
information about the session. In a delayed-binding mode, the CID
makes load-balancing decisions based on the URL in the Host: header.
When the Enhanced URL Retrieval feature is enabled, the CID makes
decisions based on the information contained in other headers of the
URL from the origin of its request. This feature can improve caching on
certain types of cache servers.
To enable Enhanced URL Retrieval:

1. Double click the CID device icon. The Set-Up window appears.
2. In the Set-Up window, select Global. The Global pane appears.
3. In the Global pane, select URL Handling Settings (radio button).
4. Click Edit Settings. The URL Handling Settings window appears.
5. From the URL Handling Settings window, check the Enhanced

URL Retrieval check box.
5-62 CID User Guide

CID User Guide 5-63

Forbidden Request Override Support

An HTTP 403 status code (Forbidden) reply, returned to the client,
indicates that the source IP is denied access to the requested site. CID
transparently traps the client's requests and routes them to a selected
server, therefore as the client may be allowed access to the requested
site, the server may be denied. CID 403 Override support feature
negates this problem by automatically routing the client directly to the
Internet upon receiving a “403 forbidden” reply from the requested site.
The 403 code is returned to the client, but future requests to that site
from any client will be forwarded directly to the Internet.
Note: CID supports this feature only for non-configured clients in the
Address Mode.
HTTPS
Before CID forwards HTTPS traffic to the cache server it first tries to
send the HTTPS GET request to the server to check if the server is
capable to treat HTTPS traffic. IF the server replies with the HTTP code
200 Ok, the CID forwards all the HTTPS traffic to the servers.
Otherwise, the CID redirects all HTTPS traffic directly to the Internet.
Proxy SSL
CID supports SSL tunneling for intercepted clients. CID traps HTTPS
sessions (port 443), encapsulates the session with a HTTP header and
opens a session to the server on behalf of the client, using the
CONNECT command. To the server this appears as if the client is a
configured client, and is therefore supported by all server vendors that
support configured clients.
5-64 CID User Guide

Section 5-4 SSL Content Check

Section 5-4 SSL Content Check, describes the advanced CID feature
which allows the CID to inspect the content of SSL traffic.
A configuration of CID in conjunction with one or more CT100 units
provides the ability to scan and redirect the decrypted SSL client traffic
to the anti-virus gateways.
• What is an SSL Content Check?, page 5-66
• Spoofed AV Gateway Configuration, page 5-68
• Proxy AV Gateway Configuration, page 5-71
CID User Guide 5-65

SSL Content Check
What is an SSL Content Check?

Hackers take advantage of the fact that encrypted traffic is not usually
decrypted/inspected on its way to the destination, and use the SSL
channels for their attacks. A configuration of CID in conjunction with
one or more CT100 units provides the ability to scan and redirect the
decrypted SSL client traffic to the anti-virus gateways.
Figure 5-13 illustrates a generalized network configuration for SSL
Content Check.
AV Gateway CT100
192.168.1.200 192.168.1.150
Router Content Inspection Users

192.168.1.254 Director 192.168.1.10-100
192.168.1.253
HTTPS
HTTP
Figure 5-13 SSL Content Check General Scheme
There are two types of SSL Content Check configuration, which are:
• Spoofed AV Gateway
• Proxy AV Gateway
The following sections describe how to configure each type.
5-66 CID User Guide

When a client initiates an SSL session with a server on the Internet,

CID performs this sequence of actions:
1. CID redirects the client HTTPS traffic to a selected CT100 unit,
which terminates the client HTTPS handshake.
2. CT100 opens a new HTTP session, with the client’s decrypted
HTTP traffic.
3. CID redirects the clear HTTP session to a selected AV (anti-virus)
gateway for content inspection.
4. CID redirects the HTTP session that arrives from the AV gateway,
back to the CT100 unit.
5. The CT100 unit encrypts the client HTTP traffic and sends it as an
HTTPS session.
6. CID redirects the HTTPS session to the Internet.
Setting up a configuration to enable an SSL Content Check involves
the following general steps:
1. Configuring the network and port group for the users’ side
2. Adding and configuring farms
3. Adding and configuring farm clusters
4. Configuring content check policies for farms, traffic protocols and
gateways.
Notes:
• Configuring CID in the VLAN mode requires setting the network
default gateway also in CID.
• When configuring farm servers, the Traffic Settings > Transform
Request option must be disabled for all Farms which handle
HTTPS traffic.
• The farm’s content based rule must be set to IP Address mode.
• If the scanning of clients’ HTTP traffic needs to be accelerated,
Radware recommends configuring a separate Farm for the AV
Gateway and setting the farm to operate in MIME-type mode.
• Each client session generates N+1 entries in the Client Table, were
N is the number of farms in the CID configuration.
CID User Guide 5-67

SSL Content Check
Spoofed AV Gateway Configuration

A spoofed AV Gateway retains the client’s IP address, while CID
redirects traffic to and from the server based on MAC addresses only.
To configure a client SSL Content check in conjunction with the AV
gateway that operates in the Spoofed mode, CID is configured with 4
farms and 3 policies.
Figure 5-14 displays the logical topology of the network in a CID
configuration with a Spoofed AV gateway.
CT100 AV Gateway CT100

Director
HTTPS
HTTP
Figure 5-14 Traffic Flow in Spoofed AV Gateway
As Figure 5-14 shows, the CT-100 server farm is duplicated as a logical

element, because CID redirects the original HTTPS traffic twice to the
same physical CT100 server.
5-68 CID User Guide

Spoofed AV gateway SSL Content Check - Confiuration

Guidelines:
1. Configure a Network and a Port Group to represent the users’
segment.
2. Configure 4 farms.
a. Farm1 for the CT-100 units.
b. Farm2 for the AV gateways.
c. Farm3 for the CT-100 units.
d. Farm4 for the Router - the default gateway of the users.
Note: Configure Farm4 only if it is required to perform NAT on the
traffic accessing the Internet.
3. Configure the farm clusters:
a. Cluster HTTPS-CT to include Farm1 and Farm4.
b. Cluster HTTP-Client to include Farm2 and Farm4.
c. Cluster HTTP-AV-CT to include Farm2 and Farm3.
4. Configure the policies for the farm cluster.
a. To configure a policy for client’s regular HTTP traffic, :
Index: 1
Service Type: Filter
Service: HTTP
Direction: OneWay
Cluster Farm: HTTP-Client
Inbound Physical Port Clients’ segment port group
Group:
b. Click Ok to apply.
c. To configure a policy for the HTTPS traffic, set the following
Index: 2
CID User Guide 5-69

SSL Content Check
Service: HTTPS
Direction: OneWay
Cluster Farm: HTTPS-CT
Inbound Physical Port N/A
Group:
d. To configure a policy for the AV Gateway, set the following
Index: 3
Service: HTTP
Direction: OneWay
Cluster Farm: HTTP-AV-CT
Group:
5-70 CID User Guide

Proxy AV Gateway Configuration

A proxy AV gateway uses its own IP address when forwarding the
clients’ traffic to the Internet. CID redirects traffic to and from the server,
based on the IP addressing scheme. To operate in the Proxy Mode, the
AV gateway should be configured with different IP addresses for the
SSL decrypted traffic and for the client’s regular traffic; hence the two
AV gateway segments as shown in Figure 5-15.
Figure 5-15 illustrates the HTTPS traffic flow when the AV gateway
works in the Proxy Mode.
3 2
1’ 1

Director
AV Gateway
192.168.1.201
HTTPS
HTTP
Figure 5-15 HTTPS Traffic Flow in Proxy AV Gateway
CID User Guide 5-71

SSL Content Check
Figure 5-16 illustrates the HTTP traffic flow when the AV Gateway
works in the Proxy Mode.

Director
HTTPS
HTTP
Figure 5-16 HTTP Traffic Flow in Proxy AV Gateway
Properties:
• Using a Proxy AV gateway requires different farm clusters to be set
up for the traffic: one farm for the HTTP traffic and another farm for
the HTTPS traffic.
• Clients must have two configured proxy IP addresses: one for the
HTTPS traffic and one for the HTTP traffic.
• A direct farm/cluster policy cannot be configured to the proxy
server.
• NAT can be included in the farm properties. However, NAT must
always be configured at the last Farm in the traffic chain to access
the Internet.
5-72 CID User Guide

To set up a client SSL Content Check in conjunction with an AV
Gateway operating in the Proxy Mode, CID is configured with the
following policies:
• Client’s regular HTTP traffic
• Client’s HTTPS traffic
• CT100 to AV Gateway traffic
• AV Gateway to CT100 traffic
To configure an AV gateway proxy SSL Content Check:

1. Configure a Network and Port Group to represent the users’
segment.
2. Configure a Network to represent the AV Gateway segment.
3. Configure 4 farms:
a. Farm1 for CT-100 units.
b. Farm2 for AV gateways, decrypted HTTPS traffic.
c. Farm3 for CT-100 units.
d. Farm4 for AV gateways, HTTP traffic.
Note: When configuring farm servers, the Traffic Settings >
Transform Request option must be disabled for all Farms which
handle HTTPS traffic.
4. Configure the farm clusters:
a. Cluster HTTPS-CT to include Farm1.
b. Cluster HTTP-Client to include Farm2.
c. Cluster HTTP-AV-CT to include Farm2 and Farm3.
d. Cluster HTTP-AV to include Farm4.
5. Configure the policies for client’s HTTPS traffic.
a. Configure policy 1 (and 1’) for the HTTPS to CT100 traffic:
Index: 2
Service: HTTPS
CID User Guide 5-73

SSL Content Check
Source Address: Users; AV Gateway

(can also be set to: Any)
Direction: OneWay
Cluster Farm: HTTPS-CT
Group:
b. Click Ok
c. Configure policy 2 for the CT100 to AV Gateway traffic:
Index: 3
Service: HTTP
Direction: OneWay
Group:
d. Click Ok
e. Configure policy 3 for the AV Gateway to CT100 traffic:
Index: 4
Service: HTTP
Source Address: AV Gateway
Direction: OneWay
Group:
f. Click Ok
5-74 CID User Guide

6. Configure the policy for the client’s regular HTTP traffic:.

Index: 1
Service: HTTP
Direction: OneWay
Cluster Farm: HTTP-AV
Inbound Physical Port Clients’ segment port group
Group:
7. Create a new Network for CID:
a. From the main window select the CID device icon and select
APSolute OS >Bandwidth Management. The Bandwidth
Management window appears.
b. In the Bandwidth Management widow select Classes. The
c. In the Classes window select Networks. The Network Table
appears. Click on the Modify tab and then click Add. The Edit
Network Table appears.
d. In the Edit Network Table set the following parameters
Network Name: Users
IP Address: (according to this example) 192.1.1.0
e. Click Ok.
8. Add a new Port Group to CID:
a. In the Classes window select Port Groups. The Port Groups
window appears.
b. In the Port Groups window select the Physical Ports Group
option button.
c. Select Modify Table and click Add. The Edit Physical Port
Group window appears.
CID User Guide 5-75

SSL Content Check
d. In the Edit Physical Port Group window, set the following

Group: CT100 Port
Assigned Port: F-2 (CT100 port)
e. Click Ok.
f. In the Port Groups window click Update Modifications and
click Ok.
9. Create a new Farm Cluster Policy for the HTTP Traffic:
a. From the main window select the CID icon and then select
APSolute OS > Traffic Redirection. The Traffic Redirection
window appears.
b. In the Traffic Redirection window select Cluster. From the
Cluster pane select a cluster entry and then click Policies. The
Farm Cluster Policies window appears.
c. In the Farm Cluster Policies window select Modify and click
Add. The Edit Policy window appears.
d. In the Edit Policy window, set the following parameters
Policy Name: HTTP
Index: 1
Service: HTTP
Direction: Oneway
Cluster Farm: HTTP-AV-CT100
Inbound Physical Port CT100 Port
Group:
e. Click Ok.
f. In the Farm Cluster Policies window click Update Active
Policies.
10. Add a Farm Cluster Policy for the HTTPS traffic.
5-76 CID User Guide

a. In the Farm Cluster Policies window select Modify and In the

Edit Policy window, set the following parameters according to
Policy Name: HTTPS
Index: 2
Service: HTTPS
Direction: Oneway
Cluster Farm: HTTPS-CT100
b. Click Ok.
11. From the Farm Cluster Policies window click Update Active
Policies.
Notes:
• Using a Proxy AV gateway requires different farm clusters to be set
up for the traffic: one farm for the HTTP traffic and another farm for
the HTTPS traffic.
• Clients must have two configured proxy IP addresses: one for the
HTTPS traffic and one for the HTTP traffic.
• A direct farm / cluster policy cannot be configured to the proxy
server.
• Users can include NAT in the farm properties. However, NAT must
always be configured at the last Farm in the traffic chain to access
the Internet.
CID User Guide 5-77

DNS and NTP Services
Section 5-5 DNS and NTP Services

Section 5-5 DNS and NTP Services, provides an explantion of DNS
and NTP services and how to configure them. This section includes the
following topics:
• DNS Services, page 5-79
5-78 CID User Guide

DNS Services
DNS Services comprises of the client and the server.
DNS Client
Each CID has a DNS Client that allows to identify the destination IP
address of a specific URL. When CID needs to forward requests
directly to the Internet without sending them to a content server, the
device also needs to identify the content server’s IP address. CID can
be configured with the addresses of two DNS servers to use for
resolution. The DNS Client has to be enabled when using the following:
• URL policies (CID has to resolve the IP address of the URL)
• Preferred sites
• HTTP Page connectivity check
• NSLOOKUP from the CLI
DNS Client also supports the use of hostnames for the following
services: NTP, RADIUS, Ping, Trace-route and Mail-Traps. In addition,
the DNS Client support feature enables directing the configured client
to the Internet.
You can configure CID to operate as DNS client. When the DNS client
is disabled, IP addresses cannot be resolved. When the DNS client is
enabled, IP addresses can be resolved in the following ways:
• Using the configured DNS servers to which DNS client sends
queries about IP addresses of a hostname.
• Using the pre-defined static table that includes hostnames and IP
addresses.
To display the DNS table:

2. In the Traffic Redirection window, select DNS. The DNS window
appears.
CID User Guide 5-79

4. In the DNS Primary Address text box, type the address of the
primary DNS server that is used to query IP addresses of
hostnames.
5. In the DNS Alternate Address text box, type the address of the
backup DNS server that is used to query IP addresses of
hostnames in case the primary server is not in service.
6. To display the dynamic DNS table in the CLI, type the following
command:
services dns nslookup <hostname>
The DNS table is displayed.
To define the static DNS table:

1. From the main window, click Traffic Redirection. The Traffic
window appears.
4. From the DNS window, select the Static DNS option. The Static
DNS Table window appears.
5. From the Static DNS Table window, set the following parameters
Host Name: The URL name for which you want to
set the IP address.
IP Address: The IP address of the URL.
6. Click Add to apply. The new client is listed in the Static DNS
Table.
7. Click Ok to apply the setup and exit.
To configure a DNS Client:

1. In the Traffic Redirection window, select DNS. The DNS pane
appears.
2. In the DNS pane, select the Client service.
3. Type the Host Name and IP Address and click Add. The new
client is listed in the Traffic Redirection table.
5-80 CID User Guide

4. In the Traffic Redirection window, click DNS Settings. The DNS

Configuration window appears.
5. In the DNS Configuration window, set the following parameters
DNS Primary Type the primary IP address for the DNS
Address: Client.
DNS Alternate Type the alternative IP address.
Address:
6. Check the Client DNS checkbox.
7. Click Apply and then Ok.
CID User Guide 5-81

DNS Server
CID supports DNS Server functionality, resolving an IP address of a
Farm URL address. The DNS Server enables the user to configure a
static DNS table, by assigning pairs of URL and IP addresses.
To configure the DNS Server

1. In the Traffic Redirection window, select DNS .
2. Select the Server service.
3. Type the Farm URL and Farm Address in the textboxes and click
Add. The new server is listed in the Traffic Redirection table.
4. Check the Status checkbox.
5. In the Traffic Redirection window, click DNS Settings.The DNS
6. In the DNS Configuration window, set the following parameters
DNS Primary Address: Type the primary IP address for the
DNS server.
DNS Alternate Address: Type the alternative IP address.
7. Check the Server DNS checkbox.
8. Click Apply and then Ok.
5-82 CID User Guide

CHAPTER 6
Chapter 6 - Redundancy
Chapter 6, Redundancy, introduces the redundancy concept of CID,
which allows you to configure a backup device in the event of main
device failure. This chapter also provides example configurations of
redundancy.
• Section 6-1: CID Redundancy, page 6-2
• Section 6-2: Proprietary ARP Redundancy, page 6-10
• Section 6-3: VRRP Redundancy, page 6-24
CID User Guide 6-1

CID Redundancy
Section 6-1 CID Redundancy

Section 6-1 CID Redundancy introduces types of redundancy
configurations implemented in CID and describes capabilities as well
as providing configuration examples.
This chapter contains the following topics:
• Introducing CID Redundancy, page 6-3
• Active / Backup Setup, page 6-5
• Interface Grouping, page 6-6
• Mirroring, page 6-8
6-2 CID User Guide

Introducing CID Redundancy

Radware recommends to install CID devices in pairs, to provide fault
tolerance in the case of a single device's failure. Two processes are
involved in the redundancy scheme: polling and teaching.
The two CIDs have a mechanism that allows them to poll each other:
• The polling mechanism allows the Backup device to constantly
mirror the Main device and to ensure the Main device is alive.
• The teaching mechanism is used by the Backup device when the
Main device is down. This is how the takeover takes place.
This way, one CID can always know whether another CID is up or
down. In CID, physical IP addresses are configured to poll other CID
physical IP addresses. In Figure 6-1, the interface addresses of CID 2
are configured to poll the addresses of CID 1 and the interface
addresses of CID 1 are configured to poll the addresses of CID 2.
The teaching process is performed in the following way: once CID
interface considers the other CID interface to be down, it must assume
responsibility for the failed IP address. For example, in Figure 6-1, if
CID 1 fails and CID 2 decides to pick up for it, CID 2 must assume
responsibility for IP addresses of CID 1.
Each pair of CIDs can function in an Active / Backup setup.
To achieve redundancy between pairs of CID devices, the following
methods are supported:
• Proprietary ARP: Address Resolution Protocol is used to monitor
the other device in pair and to check its availability. Using
proprietary ARP redundancy, at the fail-over time, the IP Addresses
of the Main device are managed by the Backup device and are
associated with the Backup device’s MAC Address.
• VRRP: Virtual Router Redundancy Protocol enables maintaining
the dynamic redundancy using a virtual router. With VRRP, IP
Addresses are associated with the Virtual MAC Addresses that are
owned by the Main device, and are taken over by the Backup
device at fail-over time.
CID User Guide 6-3

CID Redundancy
Figure 6-1 illustrates a general redundancy scheme for CID.
Internet
Router Users
Network A
Port 1 Port 1
MAC A MAC C
CID 1 CID 2
Port 2 Port 2
MAC B MAC D
Network B
Server 2 Server 2
Figure 6-1 CID Redundancy Scheme
6-4 CID User Guide

Active / Backup Setup

In the case of an Active / Backup configuration, the main CID device is
configured with main Virtual Addresses. This device performs regular
CID operation, handling all the inbound sessions to the Virtual
Addresses and distributing traffic among the servers in the farm.
The Backup CID device is configured with identical Virtual Addresses
containing the exact same servers and farm settings. This device acts
as a hot standby and does not perform load balancing as long as the
Main device is active.
The Backup CID periodically verifies that the Main device is available.
When Backup CID detects that the Main CID fails, the Backup device
resumes control for the IP address of its main partner, letting all devices
on the network know that the Backup device is now responsible for the
services of the Main device.
When the Backup device takes control over the services, it continues to
monitor the Main device. As soon as the Main device is back online, the
Backup device releases the services.
CID User Guide 6-5

CID Redundancy
Interface Grouping
To provide a complete solution for redundancy against all failures, CID
employs a mechanism called Interface Grouping. If CID notices that
one of its physical ports is down, it intentionally brings all other active
ports down.
When a physical port on CID goes down, because of a cable failure,
switch port failure, hub failure, or other problems, CID performs the
following tasks:
• CID examines the configuration to see if any IP addresses were
configured on the port that just went down.
• If there were IP addresses configured on the port that went down,
CID deactivates all other active ports.
• If there were no IP addresses configured on the port that went
down, nothing happens and normal operation continues.
Notes:
• Using Regular VLAN, when any of the ports associated with a
VLAN is down, Interface Grouping is triggered.
• Using Switched IP VLAN, Interface Grouping is triggered only when
all ports on a Switched IP VLAN are down.
Backup Interface Grouping

The Backup device takes control only if *all* the interfaces of the Main
device are out of service. This solves the following problem: if an active
and a backup device, each connected to a switch, and the switches are
cross-connected. When the cable cross-connecting the switches fails,
this is communicated to the main device and so the interface grouping
is not triggered, but the Backup device cannot communicate to the
Main and so the Backup takes over. This causes downtime in the
service.
When the Backup Interface Grouping parameter is enabled, the
Backup device takes over only when all IP interfaces defined in its
Redundancy Table fail. Respectively, the Backup device releases those
interfaces only when all the Main device's interfaces are up.When
Backup Interface Grouping is not activated, the Backup device takes
6-6 CID User Guide

control once one interface of the Main device (defined in the

Redundancy Table) is out of service. Respectively, the Backup device
releases the interface once all the interfaces of the Main device are
available.
To enable Interface Grouping and Backup Interface Grouping:

1. From the main window, select the main device icon, then hold the
Shift (or Ctrl) key, and select the backup device icon, click Link.
The Redundancies window appears.
2. In the Redundancies window, click Add. The Advanced
Redundancy dialog box appears.
3. In the Device Name dropdown list, select the device for which you
want to define the advanced parameters.
4. To enable Interface Grouping, select the Interface Grouping
checkbox and click Ok.
5. To enable Backup Interface Grouping, select the Backup
Interface Grouping checkbox and click Ok.
CID User Guide 6-7

CID Redundancy
Mirroring
Mirroring enables a redundant Backup device to maintain a copy of the
dynamic tables of the Main device, by sending a snapshot of the Client
Table information contained on the Main device to the Backup device. If
the Main device fails, the Backup device seamlessly resumes the
sessions, ensuring that the request for service is forwarded to the same
server in the farm which handled the session before the Main device
failure. Mirroring is recommended for use with very state sensitive and
long term sessions, such as Telnet or FTP. However, this feature
should not be activated with HTTP applications where sessions are
short and a reload mechanism is built-in or transparent. Mirroring
should not be used in conjunction with the Dynamic Session ID Tacking
feature. When enabling Mirroring on a Backup CID, the device must be
reset. Setting up Mirroring affects the general CID performance.
Notes:
• When setting up mirroring, it is recommended to use the same CID
software version for the main and for the backup devices.
• Server NAT and Outbound NAT sessions are not mirrored. This
implies that such sessions have to be re-established after a
redundancy take over.
• It is not recommended to use mirroring in conjunction with Layer 7
features that requires Delayed Bind. This includes Dynamic
session ID Persistency, Layer 7 Policies, SSL ID tracking so on.
Mirroring Configuration Guidelines:

Mirroring parameters must be configured both on the main device and
on the backup device.
1. From the device map, select the two devices by holding down the
shift button and click Link. The Redundancies window appears.
2. In the Redundancies window, click Mirroring. The Mirroring
window appears
3. In the Mirroring window, set the following parameters according to
Client Table Enables or disables the Client Table mirroring.
Mirroring:
Default: Disabled.
6-8 CID User Guide

Proximity Enables or disables the mirroring of the

Table Proximity Table (Available in CID-NP only).
Mirroring:
Default: Disabled.
In each of the above parameters, set the following sub parameters
% of Table to The percentage of Client Table / Proximity Table
Backup: to send to the Backup device. The newest
percentage is always sent to the backup device.
Default: 100%.
Mirror Update How often the Main device sends information to
Time: the Backup device.
Default: 10 seconds.
4. Click Ok to apply the setup and close the dialog box.
CID User Guide 6-9

Proprietary ARP Redundancy
Section 6-2 Proprietary ARP Redundancy

Section 6-2 Proprietary ARP Redundancy presents the redundancy
methods which use the Address Resolution Protocol.
• Proprietary ARP, page 6-11
• Backup Fake ARP, page 6-12
6-10 CID User Guide

Proprietary ARP
The proprietary method, the CID platform employs the Address
Resolution Protocol (ARP) to check the availability of the partner. The
ARP method ensures that the Radware device is available and that the
network connections between the devices are up.
If the Main device fails, the Backup device takes control and continues
seamlessly operating between clients and servers that had been
established on the primary device.
With Proprietary ARP redundancy, the Backup device manages the
polling process by continuously polling the Main device, using the ARP
protocol, see Table 6-1. When the Main device fails, the teaching
process is realized when the Backup device sends broadcast ARPs
informing its network neighbors that the IP Addresses of the Main
device are now associated with its own MAC Addresses. This ensures
that all traffic destined to the IP Addresses of the Main device arrives to
the Backup device.
Table 6-1 ARP Polling Parameters
Polling Interval How often the Backup device polls the Main
device (in seconds).
Default: 3.
Timeout The number of polling attempts that are made

before the Backup device takes over.
Default: 12.
CID User Guide 6-11

Backup Fake ARP

When two CID devices are working in the redundant mode, the Backup
device constantly monitors the health of the Main device. Once the
Backup device detects that the Main device fails, the Backup device
takes control, which means that the Backup device now owns the IP
addresses of the Main device. The Backup device sends gratuitous
ARP to all local stations informing that the main device IP addresses
now correspond to the MAC addresses of the Backup device. This
process ensures smooth redundancy from the main device to the
backup.
When the Main device is operational again, it uses the same technique.
The main sends gratuitous ARP to all local stations informing them that
the main device IP addresses now correspond to the MAC addresses
of the Main device. In order to speed up this process, the Backup
device also publishes that the IP addresses of the main correspond to
the MAC addresses of the Main device. This is a fake ARP, as one
device (the backup) publishes the other device (the main). The fake
ARP might confuse some Layer 3 switches, as they update their ARP
Tables by the source MAC of the packet, rather than by the MAC in the
information part of the packet.
The Backup Fake ARP option is enabled by default and can be
disabled if needed.
Backup Device in VLAN

Using Redundancy with Bridging, the backup device must remain
completely silent on the network in order to avoid broadcast storms. In
such case, this behavior must be set using the Backup device in VLAN
parameter.
To enable Backup Fake ARP and Backup Device in VLAN:

1. From the main window, select the Main device (icon), then hold
the Shift (or Ctrl) key, and select the Backup device, click Link.
2. In the Redundancies window, click Add. The Advanced
Redundancy window appears.
6-12 CID User Guide

3. From the Device Name dropdown list, select the device for which
you want to set the advanced parameters.
4. To enable Backup Fake ARP, select the Backup Fake ARP
checkbox and click Ok.
5. To enable Backup device in VLAN, select the Backup device in
VLAN checkbox and click Ok.
CID User Guide 6-13

Example - Proprietary Redundancy with Routing

Figure 6-2 illustrates the scheme for a proprietary redundancy
configuration with routing.
Internet
Router
100.1.1.20 Users
Port 1 Port 1
100.1.1.10 100.1.1.11
CID 1 CID 2
Virtual IP Address
Regular 100.1.1.100
Port 1 Port 2
100.1.1.11 100.1.1.11
Server 1 Server 2
10.1.1.1 10.1.1.2
Figure 6-2 Proprietary Redundancy with Routing
6-14 CID User Guide

Properties:
• Network Side and server side are different on different subnets.
• Virtual IP addresses served by the CIDs: the 100.1.1.100
addresses are usually handled by CID 1.
• Servers 10.1.1.1 and 10.1.1.2 are assigned to the farm that is
managed by CID.
Proprietary Redundancy with Routing - Configuration

Guidelines:
1. Set the default gateway of the servers to the IP address of Main
CID using 10.1.1.10.
2. Add Main device and backup device to the APSolute Insite map
Insite map, set IP addresses and routing as needed.
3. Add Server 1 and Server 2 to the map, set Farm 1 with Server 1
and Server 2 on CID 1 and on CID 2.
To set Redundancy Mode, click APSolute OS >Traffic
Redirection > select the farm> Edit > Traffic Settings and set the
Redundancy Mode parameter of the farm to Primary on Main CID,
and to Backup on backup CID.
4. From the main window, select the Main device icon, then hold the
Shift (or Ctrl) key, and select the Backup device icon, click Link.
5. From the Relation Type dropdown list, select IP Active-Backup.
In the Main Device area you can view the name and IP address of
the main device. These are read-only fields.
In the Backup Device area you can view the name and IP address
of the backup device. These are read-only fields.
6. In the Redundancies window, click Add to define which IP
addresses of the Backup device corresponds to IP addresses of
the Main device.
Insert as many entries as needed, for each IP Interface where
redundancy is provided. In the network design of this example,
add:
Main Device Backup Device
10.1.1.10 10.1.1.11
CID User Guide 6-15

100.1.1.10 100.1.1.11
7. In the Redundancies window, click Add and set Polling Interval
and Timeout for each entry.
8. In the Redundancies window, click Advanced Settings and set
for each device:
For the Main device: Select Interface Grouping, see page
6-7.
For the Backup device: When needed, select Backup
Interface Grouping, see page 6-7.
Select the Backup Fake ARP
checkbox, see page 6-12.
9. Set up mirroring, see page 6-8.
Note: Make sure that CID settings on the Main and Backup
devices are corresponding. For example, every farm which is
active on the main device is set as backup on the backup device,
similarly for Virtual DNS Addressees, and so on.
10. To trigger an automatic configuration update of the secondary
device in a redundant configuration, from the Redundancies
window, click Copy Configuration.
The configuration file of the Main device is used, and is modified as
needed. Then the file is sent to the backup device. The old
configuration in the backup device is deleted.
Note: The Copy Configuration button is enabled only when at
least one IP Interface is set for redundancy.
11. Click Ok to accept your preferences and exit the window. The
redundancy relation is visually displayed on the map.
6-16 CID User Guide

Example - Proprietary Redundancy with Bridging

The example in Figure 6-3 illustrates the scheme for proprietary
redundancy with bridging.
Internet
Router Users
100.1.1.20 100.1.1.x
Network Side
Port 1 Virtual IP Address Port 1

100.1.1.100
CID 1 CID 2
IP VLAN IP VLAN
Interface Interface
Port 2 Port 2
100.1.1.10 100.1.1.11
Server Side
Server 1 Server 2
100.1.1.1 100.1.1.2
Figure 6-3 Proprietary Redundancy with Bridging
CID User Guide 6-17

Properties:
• Network side and server side are on the same IP subnet.
Proprietary Redundancy with Bridging - Configuration

Guidelines:
1. Set the default gateway of the servers to the IP address of Main
CID using 100.1.1.10.
2. Add Main device and backup device to the APSolute Insite map,
set IP addresses and routing as needed.
To set Redundancy Mode, click APSolute OS >Traffic
Redirection > Edit CID Farm > Traffic Settings and set the
Redundancy Mode parameter of the farm to Primary on Main CID,
and to Backup on backup CID.
4. From the main window, select the Main device, then hold the Shift
(or Ctrl) key, and select the Backup device, click Link. The
Redundancies window appears.
5. From the Relation Type dropdown list, select IP Active-Backup.
In the Main Device area you can view the name and IP address of
the main device. These are read-only fields.
In the Backup Device area you can view the name and IP address
of the backup device. These are read-only fields.
addresses of the Backup device corresponds to IP addresses of
the Main device.
redundancy is provided. In the network design for this example,
add:
Main Device Backup Device
100.1.1.10 100.1.1.11
7. In the Redundancies window, click Add and set Polling Interval
and Timeout for each entry.
6-18 CID User Guide

8. In the Redundancies window, click Advanced Settings and set

for each device:
For the Main device: Select Interface Grouping, see page
6-7.
For the Backup device: When needed, select Backup
Interface Grouping, see page 6-7.
Select the Backup Device in VLAN
checkbox and the Backup Fake ARP
Note: Make sure that CID settings on the Main and Backup
devices are corresponding. For example, every farm which is
active on the main device is set as backup on the backup device,
similarly for Virtual DNS Addressees, and so on.
10. To trigger an automatic configuration update of the secondary
device in a redundant configuration, from the Redundancies
window, click Copy Configuration.
The configuration file of the Main device is used, and is modified as
needed. Then the file is sent to the backup device. The old
configuration in the backup device is deleted.
Note: The Copy Configuration button is enabled only when at
least one IP Interface is set for redundancy.
CID User Guide 6-19

Example - Proprietary Parallel Redundancy with

Routing
The example in Figure 6-4 illustrates a scheme for proprietary parallel
redundancy with routing.
Internet
Router Users
100.1.1.20
Port 1 Port 1
100.1.1.10 100.1.1.11
CID 1 CID 2
Virtual Addresses
Regular 100.1.1.100 Backup
Backup 100.1.1.101 Regular
Port 2 Port 2
10.1.1.10 10.1.1.11
Server 1 Server 2 Server 3 Server 4

10.1.1.1 10.1.1.2 10.1.1.3 10.1.1.4
Figure 6-4 Proprietary Parallel Redundancy with Routing
6-20 CID User Guide

Properties:
• Network side and server side are on different subsets.
• Virtual IP Addresses served by the CIDs: the 100.1.1.100 address
is usually handled by CID 1, while the 100.1.1.101 address is
handled by CID 2.
• Servers 10.1.1.1 and 10.1.1.2 are assigned to the farms that are
managed by CID 1. Servers 10.1.1.3 and 10.1.1.4 are assigned to
the farms managed by CID 2. Each CID has its own group of
servers.
Note: If a server is configured in an active farm on CID 1, it cannot
be configured as a server in an active farm on CID 2. This is
because the server can have only one of the CIDs configured as its
default router.
For example, CID 1 does not hold the information of the sessions
that are sent to the farms of CID 2, and therefore is unable to send
it back to the client correctly.
If CID 1 fails and its farm is configured as a backup farm on CID 2,
the traffic to the farm is managed by CID 2. The server still sends
the traffic to its default router, but CID 2 takes over the failing CID 1
and handles the traffic correctly.
Proprietay Parallel Redundancy with Routing - Configuration

Guidelines:
1. Set the default gateway of the servers that belong to active farms of
CID 1 (Server 1 and Server 2) to the IP address of CID 1 using
10.1.1.10.
Set the default gateway of the servers that belong to active farms of
10.1.1.11.
To set Redundancy Mode, click APSolute OS > Traffic
Redirection > Edit > Traffic Settings and set the Redundancy
CID User Guide 6-21

Mode parameter of the farm to Primary on Main CID, and to

Backup on backup CID.
4. Add Server 3 and Server 4 to the map, set Farm 2 with Server3
Set the Redundancy Mode of the farm to Primary on CID 2, and to
Backup on the CID 1.
5. From the main window, select the Main device icon, then hold the
Shift (or Ctrl) key, and select the Backup device icon click Link.
6. From the Relation Type dropdown list, select IP Active-Active.
In the Active 1 Device and Active 2 Device areas you can view the
name and IP address of the redundant devices. These are read-
only fields.
addresses of CID 1 corresponds to IP addresses of CID 2.
redundancy is provided. In the network design of this example,
add:
CID 1 CID 2
10.1.1.10 10.1.1.11
100.1.1.10 100.1.1.11
8. In the Redundancies window, click Add and set the Polling
Interval and Timeout for each entry.
9. For each entry, set the Backup Direction as required (Device 1
Backs Up Device 2, Device 2 Backs Up Device 1, or Both). For a
symmetric configuration set Both.
6-22 CID User Guide

10. From the Redundancies window, click Advanced Settings and

set for each device (Now both devices act as a main device for
some of the farms, and as a backup device for other farms):
For CID 1 & CID 2: Select Interface Grouping, see page 6-
7.
When needed, select Backup Interface
Grouping, see page 6-7.
Select the Backup Fake ARP
Note: Make sure that CID settings on the devices are
corresponding. For example, every farm that is active on CID 1 is
set as backup on CID 2 and vice versa, similarly for Virtual DNS
Addressees, and so on.
CID User Guide 6-23

VRRP Redundancy
Section 6-3 VRRP Redundancy

Section 6-3 VRRP Redundancy describes the CID method of
redundancy using the Virtual Router Redundancy Protocol.
• Introducing VRRP, page 6-25
• VRRP Redundancy Notes, page 6-30
• Direct Server Connection with VRRP, page 6-41
6-24 CID User Guide

Introducing VRRP
VRRP (Virtual Router Redundancy Protocol) is a standard protocol that
enables dynamic router redundancy. This means that if the Main device
fails, VRRP ensures that the Backup device takes over, and traffic is
forwarded to it.
VRRP is based on the Virtual Router (VR) concept. A VR has a Virtual
Router Identifier (VRID) and one or more IP addresses associated with
it. Each VR has a VRMAC, which is a MAC address associated with the
VR. This saves the need for a MAC address update in case of a fail-
over. The VRMAC address is determined by the VRID, and does not
need to be configured manually.
Typically, the same VR is configured on multiple devices to achieve
redundancy between them for the VR. Each device has a priority for a
VR, the main device for the VR is the device with the highest priority.
Using VRRP, the main device constantly sends advertisements to other
VRRP routers, to indicate that it is online. When the advertisements
stop, the main device is assumed to be inactive. A new Main device is
then selected for this VR, that is the device with the next highest priority
for that VR.
For a typical Main-Backup scenario, a VR is required for each interface
of CID. In a standard CID setup, 2 VRs are required:
VR-I For the Internet side of CID, is associated to the IP
address of the main CID and to the farm IP Address.
VR-S For the server side of CID.
You need to configure all VRs on each CID device, and associate the
appropriate IP addresses with each VR.
Typically, the physical address of the external side of CID and the farm
address are associated with VR-I. The physical address of the server
side of the CID is associated with VR-S.
You need to set a priority for each VR on each CID. The priorities for all
VRs on the main CID may be 255, to indicate it is the Main device, and
a lower value on the backup device.
Using VRRP, it is possible to set up more than one redundant CID to
backup a main CID with hierarchy.
CID User Guide 6-25

VRRP Redundancy
To configure VRRP Redundancy:

1. From the device map, select the two device icons by holding down
the Shift button and click Link. The Multiple Device Links window
appears.
2. In the Multiple Device Links window select from the tree which
device is going to be the main device backed up by -
3. Click Ok. The Redundancies window appears.

4. In the Redundancies window appears, select VRRP from the
Mode drop downlist. The Redundancies window now displays the
VRRP settings.
5. To assign virtual routers to both the Master and Backup devices,
click Add. The Edit VRRP Table window appears.
6-26 CID User Guide

6. In the Edit VRRP Table window, set the following parameters

Interface: The Interface Number.
Default: F-1.
VR ID: The virtual router’s identification number.
Value range:1-255.
Enable Virtual Enables or disables the administrative
Router: status of this VR.
(checkbox)
Default: Disabled.
Priority: Assign priority.
Note: The highest priority must be assigned
to the primary VR.
Value range:1-255. Default: 100.
Primary IP: The primary IP address. The device adds a
default value unless the user defines one.
Authentication Select the required authentication.
Type:
Value range: No Authentication; Text
Authentication.
Authentication Password up to 8 characters in length.
Key:
Advertisement Define the frequency for packet checks.
Interval: Default: 1 second.
CID User Guide 6-27

VRRP Redundancy
Preemption Define the mode, that is the takeover

Mode: procedure for the VR when a device fails
and then resumes functioning.
When a device with a certain priority fails,
the device with the next highest priority
takes control of the VR. When the device
with the higher priority resumes functioning,
the Preemption Mode parameter defines
whether this device must retake control of
the VR from the device with the lower
priority.
Values: True (higher priority device takes
over); False (device with lower priority
retains control of the VR).
Default: True.
Note: The router that owns the IP address
associated with the VR is an exception to
this definition, as it always preempts
independently of this flag’s setting.
The False mode is only applicable when
more than two devices share a VR.
Protocol: Name of the IP protocol for CID (not
configurable),
7. Click Ok to save your settings and return to the Redundancies
window.
8. In the Redundancies window define which IP Addresses are
backed-up with VRRP, click Associated IP, the Associated IP
Address window appears.
9. In the Associated IP Addresses window, insert an entry for each
IP address that you want to associate with each configured VR.
Typically, CID and farm IP addresses are associated with the VR
used for the external side of the device, as well as Virtual DNS
Addresses. CID addresses must be associated with the VR used
for the internal side of the device. Client NAT Addresses must be
6-28 CID User Guide

associated either with the VR for the external side of the CID or
with the internal one, depending on the configuration.
Note: Up to 255 IP Addresses can be associated with a single
VRID.
10. Click Ok to apply the setup and exit the window.
CID User Guide 6-29

VRRP Redundancy
VRRP Redundancy Notes

The following notes are provided to assist you with initial use of VRRP.
• VRRP is not supported in a VLAN network design, using Regular
VLANs, excluding designs with server Direct Connection.
• Zero cannot be configured as a VRID number.
• Each VRID must be a unique ID number. This is true even for
VRIDs on different interfaces.
• If two Radware devices belong in the same subnet, and each
device is backed up by a VRRP router, the VRID numbers for both
devices must also be different.
When using interface grouping:
• If a certain VRID’s Admin Status is Disabled, then either all VRIDs
in that device are disabled too, or all copies of that VRID in other
devices are disabled as well.
• If on a certain interface, a Radware device has IP Addresses which
belong to a subnet that the Backup device does not have on the
same interface, then it is the users’ responsibility to configure the
Radware device with a primary IP Address that belongs to a subnet
which the Backup device has.
• Upon creating a VR on a port, there must be at least one IP
interface configured on that physical port.
• Ensure that the same parameters are configured in both devices
for each VRID.
6-30 CID User Guide

Example - Redundant CIDs with VRRP

The example in Figure 6-5 illustrates the scheme for redundant CID
configuration with VRRP.
Internet
Router
100.1.1.20
Port 1 Port 1
100.1.1.10 100.1.1.11
CID 1 CID 2
Virtual Address
Port 2 Port 2
10.1.1.10 10.1.1.11
Server Server
10.1.1.1 10.1.1.2
Figure 6-5 Redundant CID Configuration with VRRP
CID User Guide 6-31

VRRP Redundancy
Properties:
• Network side and server side are on different subnets.
• Virtual IP addresses served by the CIDs are 100.1.1.100, usually
handled by CID 1.
• Servers 10.1.1.1 and 10.1.1.2 are assigned to the farm that is
managed by CID 1.
• Redundancy is performed using VRRP protocol.
Redundant CIDs with VRRP - Configuration Guidelines:

1. Set the default gateway of the server to the IP address of
CID 1using 10.1.1.10.
2. Add CID 1 and CID 2 to the APSolute Insite map, set IP
addresses and routing as appears in Figure 6-5.
To set Redundancy Mode, click Traffic Redirection > (select the
farm) Edit > Traffic Settings and set the Redundancy Mode
parameter of the farm to Primary on CID 1, and to Backup on
CID 2.
4. Set the VRRP for CID 1(Master Device).
a. Double click on CID 1. The Set-Up window appears.
b. In the Set-Up window, select Redundancies. The
c. From the Mode dropdown list, select VRRP.
d. Click Add on the left side to add VRs to the master device
configuration and set the following parameters according to the
Interface: F-1
VRID: 100
Enable Virtual Router: Selected
Priority: 255
Primary IP: 100.1.1.10
Interface: F-2
6-32 CID User Guide

VRID: 10
Priority: 255
e. Access the Associated IP Addresses Table by clicking on
Associated IP. The Associated IP Address window appears.
f. In the Associated IP Address window, set the following
Interface: F-1
VRID: 100
IP Address: 100.1.1.100 (Farm IP Address)
Interface: F-2
VRID: 10
IP Address IP Address 10.1.1.10 (CID IP
Address)
g. Click Add.
5. Set the VRRP for CID 2 (Backup Device).
a. In the same window, set the backup device VRRP. In the Edit
VRRP table, set the following parameters according to the
Interface: F-1
VRID: 100
Priority: 100
Interface: F-2
VRID: 10
Priority: 100
CID User Guide 6-33

VRRP Redundancy

b. Access the Associated IP Addresses Table by clicking on
c. From the Associated IP Address window, set the following
parameters according to the explanations provided
Interface: F-1
VRID: 100
IP Address IP Address 100.1.1.10 (Farm IP Address)
Interface: F-2
VRID: 10
IP Address IP Address 10.1.1.10 (CID IP Address)
d. Click Add.
6. In the Redundancies window, click Advanced Redundancy. The
Advanced Redundancy window appears.
7. In the Advanced Redundancy window, select the Interface
Grouping checkbox for the main device.
8. From the Advanced Redundancy dialog box, select the Backup
Interface Grouping checkbox for the backup device if required.
6-34 CID User Guide

Example - Parallel Redundant CIDs with VRRP

The example in Figure 6-6 illustrates the scheme for a parallel
redundant CID configuration with VRRP.
Internet
Router
100.1.1.20
Port 1 Port 1
100.1.1.10 100.1.1.11
CID 1 CID 2
Virtual Addresses
Backup 100.1.1.101 Regular
Port 2 Port 2
10.1.1.10 10.1.1.11
Server 1 Server 2 Server 3 Server 4

10.1.1.1 10.1.1.2 10.1.1.3 10.1.1.4
Figure 6-6 Parallel Redundant CIDs with VRRP
CID User Guide 6-35

VRRP Redundancy
Properties:
• Virtual IP Addresses served by the CIDs: the 100.1.1.100 address
is usually handled by CID 1, while the 100.1.1.101 address is
handled by CID 2.
• Servers 10.1.1.1 and 10.1.1.2 are assigned to the farms that
managed by CID 1. Servers 10.1.1.3 and 10.1.1.4 are assigned to
the farms managed by CID 2. Each CID has its own group of
servers.
Note: If a server is configured in an active farm on CID 1, it cannot
be configured as a server in an active farm on CID 2.
This is because the server can have only one of the CIDs
configured as its default router, for example, CID 1. Traffic coming
from CID 2 is not returned through it but through CID 1. CID 1 does
not hold the information of the sessions that are sent to the farms of
CID 2 and therefore is unable to send the information back to the
client correctly.
If CID 1 whose farm was configured as a backup farm on CID 2
fails, the traffic to the farm is managed by CID 2. The server still
sends the traffic to the default router, but CID 2 takes over the
failing CID 1 and handles the traffic correctly.
Configuration:
This configuration is the same as in Example on page 6-31, however in
this example, each device is both active and backup.
1. Set the default gateway of the servers that belong to active farms of
10.1.1.10.
Set the default gateway of the servers that belong to active farms of
10.1.1.11.
To set Redundancy Mode, click Traffic Redirection > (select the
Farm) Edit > Traffic Settings and set the Redundancy Mode
6-36 CID User Guide

parameter of the farm to Primary on Main CID, and to Backup on

backup CID.
4. Add Server 3 and Server 4 to the map, set Farm 2 with Server3
Set the Redundancy Mode of the farm to Primary on CID 2, and to
Backup on the CID 1.
1. From the main window, select CID 1, then hold the Shift (or Ctrl)
key, and select CID 2, click Link. The Multiple Device Links
window appears.
2. In the Multiple Device Links window select from the tree which
device is going to be the main device backed up by.
3. Click Ok. The Redundancies window appears.
4. In the Redundancies window appears, select VRRP from the
Mode drop downlist, select VRRP. The VRRP parameters appear
in the Redundancies window in two panes, presenting CID 1 VRRP
parameters and CID 2 VRRP parameters.
5. In the Redundancies window CID 1 pane, click Add. The Edit
VRRP Table window appears, set the following parameters for CID
1 according to the explanations provided:
Interface: F-1
VRID: 100
Priority: 255
Interface: F-1
VRID: 101
Priority: 100
Interface: F-2
VRID: 10
CID User Guide 6-37

VRRP Redundancy

Priority: 255
Interface: F-2
VRID: 11
Priority: 100
6. Click Ok. The Edit VRRP Table window closes.
7. Perform the same procedure for CID 2 by setting the following
Interface: F-1
VRID: 100
Priority: 255
Interface: F-1
VRID: 101
Priority: 100
Interface: F-2
VRID: 10
Priority: 255
6-38 CID User Guide

Interface: F-2
VRID: 11
Priority: 100
8. Click Ok. The Edit VRRP Table window closes.
9. Access the Associated IP Addresses Table by clicking on
10. From the Associated IP Address window, set the following
Interface: F-1
VRID: 100
Interface: F-1
VRID: 101
Interface: F-1
VRID: 100
Interface: F-1
VRID: 101
Interface: F-2
VRID: 10
CID User Guide 6-39

VRRP Redundancy
Interface: F-2
VRID: 11
11. Click Add.
12. Define Interface Grouping.
a. From the Redundancies window, click Advanced
Redundancy. The Advanced Redundancy window appears.
b. Select the Interface Grouping checkbox.
13. Click Ok and Ok again. The redundancy configuration is
complete.
6-40 CID User Guide

Direct Server Connection with VRRP

VRRP with Switched IP VLAN allows direct connection of servers to
CID in conjunction with routing and bridging.
In this configuration, servers with dual Network Interface Card are
directly connected to CID devices. CID uses routing (Figure 6-7) or
bridging (Figure 6-8) between the external network connected to
routers or switches, and the internal network connected to servers.
Servers are connected directly to the interfaces of CID. A cross cable is
required in order to connect the two CID devices together (using the
Giga, or Fast Ethernet ports).
Using bridging, you need to configure a Regular VLAN including the
switch IP VLAN and the CID interface to the external side. This creates
a bridge between the Switched VLAN and the interface to the external
side. When needed, multiple CID interfaces can be added to this
Regular VLAN.
Using routing with Layer 2 or Layer 3 switches, either connecting CID
and servers or connecting CID to the external subnet, you must avoid
configuration that contains a loop. For example, having a cross cable
between the switches as well as between CID devices, or connecting
each CID to 2 cross-connected switches where the 2 connections are
on the same Switched IP VLAN on CID, must be avoided.
CID User Guide 6-41

VRRP Redundancy
Figure 6-7 illustrates the scheme for a direct server connection with
VRRP and Routing.
Routers or switches
External
Side
CID CID
Switch IP Switch IP
VLAN on VLAN on Internal
CID-L CID-R Side
Server Server
Figure 6-7 Direct Server Connection with VRRP and Routing
Configuration Notes:
• This configuration is supported with VRRP and Switched IP VLAN
only.
• Servers are connected directly to the interfaces of CID. A cross
cable is required in order to connect two CID devices (using Giga,
or Fast Ethernet ports).
• The interfaces to which the servers are connected and the interface
used for connecting the CID devices, are associated to a Switched
IP VLAN. This puts all the servers on a single switch. An IP address
should be associated with the Switched IP VLAN in each device.
• The CID farm and redundancy configurations remain as usual.
6-42 CID User Guide

• The default gateway for the servers is the IP address of the

Switched IP VLAN of the active CID. For example, the default
gateway of a server that belongs to an active farm on CID1, is the
IP address of the Switched IP VLAN of CID1.
Note: When using dual NIC, where the active NIC is determined by
ping to the default gateway, set a virtual DNS with IP 10.1.1.20 on
CID. This IP should be the default gateway of the servers.
In the Associated IP Addresses Table window configure the
following entries: Interface=100002, VRID=10, Associated
IP=10.1.1.20.
• CID uses routing between the subnet of the servers and the
external subnet. This is essential in order to avoid loops in the
network.
• When adding or removing ports to a Switch IP VLAN that is already
associated to a VRID, the user must set the VRID Admin Status to
Down, make the change and then set the VRID Admin Status to Up
again.
CID User Guide 6-43

VRRP Redundancy
Figure 6-8 illustrates the scheme for a direct server connection with
VRRP and Bridging.
Routers or
Switches
External
Side
CID CID
Switch IP Switch IP
VLAN on VLAN on
CID-L CID-R
Internal
Side
Server Server
Figure 6-8 Direct Server Connection with VRRP and Bridging
Configuration Notes:
• Only a single Switched IP VLAN can be part of a Regular VLAN.
The number of physical interfaces that can participate in a Regular
VLAN (with or without a Switched IP VLAN) is not limited.
• Associate an IP address with the Regular VLAN in each device.
• Both the CID farm configuration and the CID redundancy
configuration function as usual.
• The default gateway of servers must be also used as the default
gateway of CID.
• CID sends VRRP advertisements only on ports that participate in
the Regular VLAN but do not participate in the Switched VLAN.
Ensure that the CID devices have an active connection between
such ports.
6-44 CID User Guide

• Direct server connection with VRRP and Routing is supported with

VRRP and Switched VLAN type only.
• Servers are connected directly to the interfaces of CID. A cross
cable is required in order to connect the CID devices (using Giga,
or Fast Ethernet ports).
• The interfaces to which the servers are connected and the interface
used for connecting the CIDs, are associated to a Switched IP
VLAN. This puts all the servers on a single switch.
• Configure a Regular VLAN including the switch IP VLAN and the
CID interface towards the external side. This creates a bridge
between the Switched VLAN and the interface, with the external
side. When needed, multiple CID interfaces can be added to this
Regular VLAN.
• Only a single Switched IP VLAN can be part of a Regular VLAN.
However, the number of physical interfaces that can participate in a
Regular VLAN (with or without a Switched IP VLAN) is not limited.
• An IP address should be associated with the Regular VLAN in each
device.
• CID farm and redundancy configurations remain as usual.
• The servers’ default gateway must also be used as the default
gateway of CID.
• CID sends VRRP advertisements only on ports that participate in
the Regular VLAN but do not participate in the Switched VLAN.
Ensure that the CID devices have an active connection between
such ports.
• Before adding or removing ports to a Switch IP VLAN that is
associated to a VRID, the VRID Admin Status must first be set to
Down. Following the configuration change, the VRID Admin Status
should be reset to Up again.
CID User Guide 6-45

VRRP Redundancy
Interface Grouping Used with Direct Connection

To support redundant configuration with direct server connectivity, the
interface grouping operation is modified. Interface grouping is always
part of the CID redundancy mechanism. Enabling the Interface
Grouping function on the Main device ensures that if one of the
interfaces of the device fails, the device closes all its other interfaces
and becomes invisible to the network.
Using switched VLAN, the grouping takes place only when all
interfaces that were configured in a switched VLAN are down. Interface
grouping is released when the all interfaces in a switched VLAN are up.
Using Switched VLAN as part of a Regular VLAN, grouping takes place
only when all interfaces in a Switched VLAN are down, or when any
other port in the Regular VLAN is down. Interface grouping is released
when all interfaces in a switched VLAN are up and when all other ports
in the Regular VLAN are up.
6-46 CID User Guide

Example - Redundant CIDs with VRRP and Direct

Connection
The example in Figure 6-9 illustrates the scheme for a redundant CID
configuration with VRRP and direct connection. VRRP with Switched IP
VLAN allows direct connection of servers to CID.
Internet
Router
100.1.1.20
Port 1 Port 1
100.1.1.10 100.1.1.11
CID 1 CID 2

Port 2 Port 2
Port 3
Port 4 Port 4 Switched
Switched
IP VLAN IP VLAN
10.1.1.10 Dual NO 10.1.1.11
Server Users
10.1.1.1 10.1.1.2
Figure 6-9 Redundant CIDs with VRRP and Direct Connection
CID User Guide 6-47

VRRP Redundancy
Properties:
• Servers are directly connected to CID, possibly with dual NIC.
• The virtual IP address served by the CIDs is 100.1.1.100, usually
handled by CID 1.
• Servers 10.1.1.1 and 10.1.1.2 are assigned to the farm managed
by CID 1.
• Redundancy is performed using the VRRP protocol.
To configure Redundant CIDs with VRRP and Direct

Connection:
Active CID Configuration (CID 1):

1. Define CID 1: From the main window, double click the CID device
icon. The CID Connect to Device window appears. Type the
device‘s IP address: 100.1.1.10 and click Ok.
2. Define VLAN on CID 1.
a. From the main window, double click the CID device icon, the
b. In the Set-Up window, click Networking > VLAN. The Virtual
VLAN window appears.
c. In the Virtual VLAN window, select the IP VLAN Interface
100002 and assign ports 2 and 4.
d. In the Type dropdown list, select Switch, ensure the Protocol is
set to IP. Click Ok.
e. In the Set-Up window, click Add. The Interface window
appears.
f. In the Interface window, set the following parameters according
IF Num: 100002
g. Click Ok.
3. Add 2 servers:
6-48 CID User Guide

add a local server. The Server icon appears in the map area.
b. Double click on the Server icon. The Server window appears.
c. In the Server window, set the following parameters for each
server: For the first server, set:
Add the second server by setting the following parameters
d. Click Ok.
4. Add farm to CID 1.
a. Select the CID device icon, and the Server 1 and Server 2
icons.
b. From the CID toolbar, click Link. The Farm window appears.
Device: CID 1
Farm Name: Farm 1
Active Farm: Enabled
d. In the Farm window, click the Traffic Settings tab and set the
Redundancy Mode parameter to Primary.
e. Click Ok.
5. Add servers to Farm 1.
a. In the Farm window, click Farm Servers > Add. The Farm
b. In the Farm Servers window, set the following parameters for
each server: For the first server, set:
CID User Guide 6-49

VRRP Redundancy

c. Click Ok.
6. Define the Redundancy for CID1:
a. Double click the CID icon. The CID window appears.
b. In the Set-Up window, select Redundancies. The CID
c. From the Redundancies window, click Advanced
Redundancy. The Advanced Redundancy window appears.
d. Select the Interface Grouping checkbox and click Ok.
7. From the Mode dropdown list, select VRRP.
8. In the Redundancies window, click Add. The Edit VRRP Table
dialog box appears, set the following parameters for CID 1:
Interface: 1
VRID: 100
Enable Virtual Selected
Router:
Priority: 255
Interface: 100002
VRID: 10
Enable Virtual Selected
Router:
Priority: 255
6-50 CID User Guide

9. In the Redundancies window, click Associated IP. The Associated

IP Address window appears.
10. In the Associated IP Address window, set the following parameters
Interface: 1
VRID: 100
Associated IP: 100.1.1.100 (Farm IP Address)
Interface: 1
VRID: 100
Associated IP: 100.1.1.10 (CID IP Address)
Interface: 100002
VRID: 10
Associated IP: 10.1.1.10 (CID IP Address)
11. Click Ok.
Note: When using dual NIC, where the active NIC is determined by
ping to the default gateway, set a virtual DNS with IP 10.1.1.20 on
CID. This IP should be the default gateway of the servers.
In the Associated IP Addresses Table window configure the
following entries: Interface=100002, VRID=10, Associated
IP=10.1.1.20.
Backup CID Configuration (CID 2):

1. Define CID 2.
a. From the main window, double click the CID device icon. The
CID Connect to Device window appears.
b. Type the device‘s IP address: 100.1.1.11 and click Ok.
2. Define VLAN on CID 1.
a. From the main window, double click the CID icon, the Set-Up
window appears.
b. In the Set-Up window, click Networking > VLAN. The Virtual
VLAN window appears.
CID User Guide 6-51

VRRP Redundancy
c. From the CID Virtual VLAN window, select the IP VLAN

Interface 100002 and assign ports 3 and 4.
d. From the Type dropdown list, select Switch, ensure the
Protocol is set to IP. Click Ok.
e. From the CID window, click Add. The Edit CID Interface
window appears.
f. From the Edit CID Interface window, set the following
IF Num: 100002
g. Click Ok.
3. Add farm to CID 2.
a. Select the CID icon, and the Server 1 and Server 2 icons.
b. From the main toolbar, click Link. The Farm window appears.
Device: CID 2
Farm Name: Farm 2
Active Farm: Enabled
d. In the Edit CID Farm window, click Traffic Settings and set the
Redundancy Mode parameter to Backup.
e. Click Ok.
4. Add servers to Farm 2.
a. in the Farm window, click Farm Servers > Add. The Farm
b. In the Farm Servers window, set the following parameters for
each server. For the first server, set:
6-52 CID User Guide


Note: The default router of the servers 10.1.1.1 and 10.1.1.2 is the
10.1.1.10 address of CID 1, or when using dual NIC, the default
gateway of servers is the Virtual DNS address 10.1.1.20.
5. Define the Redundancy for CID 2:
a. Double click the CID icon. The CID window appears.
b. In the CID window, select Redundancies. The CID
c. From the Mode dropdown list, select VRRP.
d. In the Redundancies window, click Add. The Edit VRRP Table
window appears, set the following parameters for CID 1
Interface: 1
VRID: 100
Priority: 100
Interface: 100002
VRID: 10
Priority: 100
e. Click Ok.
f. In the Redundancies window, click Associated IP. The
Associated IP Address window appears.
CID User Guide 6-53

VRRP Redundancy
g. In the Associated IP Address window, set the following

Interface: 1
VRID: 100
Associated IP: 100.1.1.100 (Farm IP Address)
Interface: 1
VRID: 100
Associated IP: 100.1.1.10 (Main CID IP Address)
Interface: 100002
VRID: 10
Associated IP: 10.1.1.10 (Main CID IP Address)
h. Click Ok.
i. When using servers with dual NIC, where active NIC is
determined using ping to default gateway, configure a virtual
DNS with IP address 10.1.1.20, with Redundancy Mode on the
Backup. In the Associated IP Address pane, set the following
Interface: 100002
VRID: 10
Associated IP: 10.1.1.120
6-54 CID User Guide

CHAPTER 7
Chapter 7 - Health Monitoring
Chapter 7, Health Monitoring, describes the Health Monitoring module
included in the Radware APSolute OS 10.21.02.
• Introducing Health Monitoring, page 7-2
• Configuring Health Checks, page 7-5
• Health Check Methods, page 7-25
CID User Guide 7-1

Introducing Health Monitoring
Section 7-1 Introducing Health Monitoring

Section 7-1 Introducing Health Monitoring describes the general
function of the Health Monitoring module and the basic health
monitoring concepts. This section includes the following topics:
• Module, page 7-3
• Checked Element, page 7-3
• Health Check, page 7-3
• Method, page 7-4
• Binding and Groups, page 7-16
7-2 CID User Guide

Module
The Health Monitoring module, implemented on all Radware IAS
(Intelligent Application Switching) products, is responsible for checking
the health of the network elements such as servers, firewalls, and Next
Hop Routers (NHRs) that are managed by the IAS device.
The Health Monitoring module determines which network elements are
available for service, to enable the IAS device to load balance traffic
among the available resources.
Traffic management decisions are based mainly on the availability of
the load balanced elements and on other resources on the data path.
The module provides flexible configuration for health monitoring of the
load balanced elements. The module supports various pre-defined and
user defined checks, and enables you to create dependencies between
health checks of different elements.
Checked Element
A Checked Element is a network element that is managed and load
balanced by the Radware device. For example, CID-checked elements
are the Farm Servers and NHRs. The health of a checked element may
depend on a network element that the IAS device does not load
balance. For example, the health of a server managed by CID may
depend on the health of a database server or other application servers,
which are not load balanced by the CID.
Health Check
A Health Check defines how to test the health of any network element
(not necessarily a Checked Element). A check configuration includes
such parameters as: the check method, the TCP/UDP port to which the
test should be sent, time interval for the test, its timeout, the number of
retries, and more. These parameters are explained in detail in the
Regular Health Check section.
A network element can be tested using one or several Health Checks.
CID User Guide 7-3

Introducing Health Monitoring
Method
Health check methods are applications or protocols that the IAS device
uses to check the health of network elements. For example, a method
can be Ping, HTTP or other. Although the Health Monitoring module
provides a wide array of predefined methods, user defined methods
are also supported. In addition, method-specific arguments can be
configured for each method.
For a complete list of supported health check methods, refer to Health
Check Methods, page 7-25.
7-4 CID User Guide

Section 7-2 Configuring Health Checks

Section 7-2 Configuring Health Checks describes how to configure
health monitoring according to health check types.
• Global Configuration, page 7-6
• Health Checks Database, page 7-9
• Binding and Groups, page 7-16
• Regular Health Check, page 7-19
• Group Health Check, page 7-22
• Farm Health Check, page 7-23
CID User Guide 7-5

Configuring Health Checks
Global Configuration
The Health Monitoring module is configured in several ways; using the
Health Monitoring feature in APSolute Insite, from Web Based
Management or via CLI.
Setting up the Health Monitoring module on an IAS device involves the
following steps:
1. To enable the Health Monitoring Module; in the Health Monitoring
Settings window, set the Health Monitoring parameter to Monitoring
Enabled.
2. Set the Connectivity Method of each farm to Disabled. This allows
the device to use the results of the Health Monitoring Module to
determine the status of the servers in this farm.
Note: APSolute Insite supports both farm-oriented and server-oriented
Health Monitoring configurations. The farm-oriented configuration
automates and simplifies the Health Monitoring configuration process
for large configurations containing farms with multiple servers.
7-6 CID User Guide

Global Parameters Setup

In APSolute Insite, Global parameters setup is done through the Health
Monitoring Settings window.
To configure Global Health Monitoring:

1. Double click on the CID device icon. The Set-up window appears.
2. In the Setup window select Global. The Global pane appears.
3. In the Global pane check Health Monitoring Settings and then
click Edit Settings. The Health Monitoring Settings window
appears.
4. In the Health Monitoring Settings window, set the following
Health Enable the module.
Monitoring:
Default: Disabled.
Response Level Define the Response Level for each check.
Samples: This is the average ratio between the actual
response time to the configured Timeout.
The Health Monitoring Module enables users
to track the round trip time of health checks.
The average is calculated over a number of
samples as defined in the Response Level
Samples parameter (Floating average). A
value of 0 in the Response Level Samples
parameter disables the feature; any other
value between 1-9 defines the number of
samples to be used. Response Time Load
Balancing is achieved through the use of the
Response Time dispatch method. The device
load balances the traffic to the “fastest”
element until the Load Factors are equal.
For more information, see Dispatch Methods,
page 4-7.
CID User Guide 7-7

SSL Certificate This file is used by the device when the Web
File: server requires a Client Certificate during the
SSL handshake.
Default: Client Certificate generated by the
device.
SSL Private Key This file is used by the device when the Web
File: server requires a key during the SSL
handshake.
Default: Private Key generated by the device.
5. Click Ok to apply the setup. The window closes.
7-8 CID User Guide

Health Checks Database

APSolute Insite enables you to configure and view the currently defined
health checks in a database, prior to attaching them to a network
element.
To configure the Health Check database:

1. From main window, select a device and select APSolute OS
>Health Monitoring. The Health Checks window appears.
2. In the Health Checks window, click Health Checks DB. The
Device Health Check DB window appears.
3. In the Health Check DB window, click Add. The Device Edit Health
Check window appears. In this window you can create a new
entry for the Health Check DB.
4. Set up the Regular check parameters for the device according to
the explanations provided:.
Health Check Type the name of the new check.
Name:
CID User Guide 7-9

Method: From the dropdown list, select the check method.

The method can be any of the pre-defined
checks, or a TCP User Defined check. For the full
description of methods, see Table 7-1 on page 7-
26.
Note: When updating a check, the method
cannot be changed.
Destination Specify the IP address or the host name of the
Host: checked element.
Notes:
• You can specify any IP address other than
0.0.0.0, to enable the testing of any network
element (not only checked element)
• DNS Client must be enabled when host
names are defined by the user.
Next Hop IP Type the IP address of the Next Hop Router that
Router: should be used for the Health Check.
This means that the Health check is sent to the
destination MAC address of the IP address
configured in this field. You can use this
parameter to check the accessibility of a Content
Server or a cache server to the Internet
(Destination IP Address is somewhere on the
Internet, Next Hop IP Address is the Cache
Server’s address).
The Next Hop IP Address should be on the same
network segment as one of the device interfaces.
When this field is left blank and the Destination IP
Address does not reside on the same subnet, the
Health Monitoring module uses the device’s
Routing Table to forward the packet.
Note: The Next Hop IP Address is not used for
ARP checks since ARP checks are performed
only on the same broadcast domain.
7-10 CID User Guide

Destination The destination TCP/UDP port number to which

Port: the health check is sent. In the case that this
parameter is not configured the device uses the
default port number based on the method. For
example: Port 80 for HTTP
Interval: Define the time interval between checks.This
interval defines the health check’s execution
interval in seconds. This field accepts only
integers, and its value must be greater than the
timeout value. Maximum value is 2^32-1
seconds. Values: Default: 10.
Retries: Define the number of times that a health check
must fail before the Health Monitoring module
reevaluates the element’s availability status.
Note: This field accepts only integers.
Timeout: Define the maximum number of seconds that the
device waits for a response to the Health Check.
Maximum value is 2^32-2 seconds.
Note: This field accepts only integers.
No New The amount of time to pass, since initiating a
Session check, untill CID recognizes this element as
Timeout: heavily loaded and does not send any new
sessions to it.
Response Define the response level of the checked
Level: element, see page 7-7.
Measure If applicable, check to enable this option.
Response
Using the Response Time Dispatch Method, this
Time:
parameter indicates whether the response time of
this check participates in measuring response
time. Note that average response time is
calculated over a number of checks as defined in
the Response Level Parameter, see Global
Parameters Setup, page 7-7. For more
information on this dispatch method, see also.
CID User Guide 7-11

5. Click Ok to apply the setup. The Regular health checks you

defined are listed in the CID Health Checks table.
6. For each selected method, you can edit the arguments. Click
Method Arguments. The Edit Method Arguments window
appears with additional configurable parameters for the selected
method, see Table 7-1 on page 7-26.
Note: Arguments are method-specific. For full list, see Table 7-2 on
page 7-35
7. Select or type the relevant values for the arguments and click Ok.
The Edit Method Arguments window closes. The information you
added appears in the Specific Check Parameters pane in the Edit
Health Check window.
8. From the Edit Health Check window, click Ok. The health check is
configured and the Edit Health Check window closes. The new
health check now appears in the Health Check DB window table.
7-12 CID User Guide

9. From the Health Check DB window, repeat the steps 2-5 to

configure each Health Check.
CID User Guide 7-13

Action Macro
Radware devices support a wide range of health monitoring checks,
allowing for highly granular checks and monitoring capabilities. The
results of these checks is always a status, either “Active” or “Down”.
The Action Macro feature complements this capability and allows
performing an action based on the status of a health check. The action
is performed by running a predefined macro file, which is bound to the
health check.
Configuration of the feature involves the following stages:
1. Define the relevant health checks in the Health Checks DB window.
2. Record the macro files you wish to execute upon receiving a trap
from the device.
3. Through the Health Check Actions window, available by clicking
the Action button in the CID Health Check DB window, bind the
health checks and the macro files.
To configure an Action macro:

1. From the Health Checks DB window, choose the required health
check in the Check Name field and set the Condition (Success or
Fail) for that check.
2. Click Action Arguments and in the Macro Action window choose
the relevant device and the relevant Macro File (using the Browse
button).
3. Set the Action:
a. To configure a macro based on the health check result (status),
click Action from the Health Check DB window. The Health
Check Actions window opens.
b. Click Add. The Edit Heath Check Action window opens.
c. In the Edit Health Check Action window, set the following
Check Name: Select from the checks you defined.
7-14 CID User Guide

Condition: Select the health check status to activate

the Action macro.
Value range: Success; Fail. Default:
Success.
Action: Select the type of action.
Value: Macro.
d. To edit the arguments for the selected action, click Action
Arguments. The Action window appears.
e. In the Action window, set the following parameters according
Device: Select the relevant device.
File Name: Select the relevant Macro File.
f. Click Ok and then Ok twice more to exit all the Action windows.
The test you configured is updated in the Health Check DB
window.
4. Click Ok to apply the setup and exit. The Health Check DB
window closes.
Note: This feature is an APSolute Iniste feature and is not
supported by WBM or CLI.
CID User Guide 7-15

Binding and Groups

Binding
The Health Check defines only how to check elements, so you still
need to define which of the Checked Elements are affected by the
results of these checks and how the results are to affect them. This is
done by the means of Health Check Binding.
Health Check Binding describes the relation between the Checked
Elements (the load balanced elements) and Health Checks and defines
how the Health Checks affect the health of the Checked Elements. For
example, when a Health Check is bound to a Checked Element” and
the check fails, the status of the Checked Element is changed to “Not in
Service”
A Health Check is performed even when it is not bound to any Checked
Element. If it fails, the device sends notification messages, as
configured (SNMP Traps, Syslog messages or mail messages),
indicating the failure of the check.
A Checked Element may be bound with more than one Health Check.
For example, a cache server can be bound to an HTTP check, which
verifies that the cache server is functioning, and to another Health
Check that makes sure that the database server used by this cache
server is also functioning.
In addition, a Health Check can be associated with more than one
Checked Element, meaning that a single resource affects the status of
multiple Checked Elements. For example, a single DB server may
influence the health of multiple cache servers. The shared resource
(DB server) is tested only once, and the test results affect multiple
Checked Elements. When a Health Check fails, the Health Monitoring
module reevaluates the status of all Checked Elements bound to the
check.
Groups
You must associate a Health Check to a Checked Element. You can
also define whether the check is Mandatory or not, and set the Group
Number.
7-16 CID User Guide

Non-Mandatory checks in a group are evaluated with a logical OR

between them so if there is more than a single Non-Mandatory check in
a group, a failure of one check does not fail the server.
When several groups are associated with a single Checked Element,
they are evaluated with a logical AND between them.
Note: When a Group consists of a single check which is defined as
Non-Mandatory, then technically it is Mandatory.
The Group Number is unique per Checked Element. This means that,
for example, Group Number 2 for Server1 and Group Number 2 for
Server2 are two separate groups.
Using groups enables the creation of complex health conditions for the
Checked Elements. For instance, consider a Web server that
communicates with one of two database servers and must use one of
two routers in order to provide service. This Web server will be bound
using three different binding groups: one group contains Health Checks
for the two routers (each check is Non-Mandatory), one group contains
Health Checks to the database servers (each check is Non-Mandatory)
and the third group contains the Health Checks on the Web server. As
long as one of the database servers and one of the routers is active,
and the Web server health check passes, the Web server is considered
active. Otherwise, the Health Monitoring module determines that the
Web server cannot provide the required service.
Up to 20 binding groups can be defined per Checked Element.
Using APSolute Insite, binding is performed by setting regular checks
and Group Checks.
The Binding Table contains the following parameters:
Check Name: The Health Check to be bound to a Checked
Element.
Possible values: All checks as defined in the
Check DB.
Checked Element The Checked Element to which the Health
Name: Check is bound.
Possible values: All defined servers in the
Application Server/Firewall/ NHR Table.
CID User Guide 7-17

Group: The group number to which the check belongs.

The group number is unique per server.
Mandatory: Defines if the Health Check is mandatory for
the Checked Element’s health. The Non-
Mandatory status for checks within a group is
equal to an OR relationship between the Health
Checks, while the Mandatory status is equal to
an AND condition.
Possible values: Mandatory, Non-Mandatory.
A Health Check is still performed even if it is not bound to any of the
Checked Elements. If the check fails, the device sends notification
messages (SNMP Traps, Syslog messages or mail messages, as
configured) indicating the failure of the check.
Health Check Binding can also be grouped for complex conditioning of

tests, using logical AND/OR.
For example - Server 1 has the following bindings:
Group 0 Check 1 Check 2 Check 3
Non Non Non
Mandatory Mandatory Mandatory
Group 1 Check 4 Check 5 Check 6

Non Non Non
Mandatory Mandatory Mandatory
Group 2 Check 7 Check 8
Mandatory Mandatory
This equals to: [check1 OR Check 2 OR Check 3] AND [check4 OR

Check5 OR Check 6] AND [Check 7 AND Check 8]. This means that in
order for Server1 to consider available at least one check of the
following must pass – Check1, Check2 or Check3 and at least one
check of the following must pass – Check4, Check5 or Check6. Check
8 and check 9 MUST pass.
7-18 CID User Guide

Regular Health Check

A Regular type Health Check is a check of an individual network
element. You can add or edit health check parameters through the
Check Table. The Checks Table lists the configured health checks.
If a check is not bound to any of the Checked Elements, it is still
performed. If it fails, the device sends notification messages, as
configured (SNMP Traps, Syslog messages or mail messages),
indicating the failure of the check.
To configure a Regular health check:

1. From the main window, select APSolute OS > Health Monitoring.
The Health Checks window appears.
2. To define a single health check, select Regular and click Add.

The device Edit Active Health Check window appears.
CID User Guide 7-19

Using this window, you can associate Health Checks to Checked

Elements, and define the way the results of the Health Check affect
the checked Element.
3. From Edit Active Health Check window, set the following

parameters for the Regular check according to the explanations
7-20 CID User Guide

provided (The remaining parameters of the selected Health Check

are displayed as read-only):
Check Select the network element to be checked. This
Element: list displays all elements managed by CID that a
Health Check can be associated with. The IP
address shows next to the selected element.
Health The name of the health check that you define.
Check Select the name from the dropdown list which
Name: contains all the checks previously defined in the
Health Checks Database.
Note: To create a new health check, you can use
the Health Checks DB configuration described on
page 7-9, or click the New Health Check button
to open the Edit Health Check window.
Mandatory: Define if the health check is mandatory to
determine the checked element’s health.
Definition of non-mandatory checks within a
check group implies an OR relation between the
health checks, while a mandatory status dictates
an AND condition.
Possible values: Mandatory; Non-Mandatory.
4. To view and edit the arguments defined for the Health Check, click
Method Arguments. For more information, refer to Method
Arguments, page 7-35.
Note: Setting the Method Arguments affects the Health Check
configuration in the Health Check DB.
5. Click Ok to apply the setup. The window closes. The new Regular
health check you defined is listed in the Health Checks table.
6. Click Ok. The Edit Method Arguments window closes. The
Specific Check Parameters field in the Edit Health Check window
shows the edited method arguments information.
CID User Guide 7-21

Group Health Check

In addition to individual or Regular checks, you can configure groups of
regular checks.
To configure a Group health check:

1. From the CID Health Checks window, click the Group option and
click Add. The device Edit Health Check Group window appears.
2. From the Group Check Name dropdown list, select the name of
the required Health Check Group.
Note: You can set up to 20 groups for a Checked Element.
3. From the Element Name dropdown list, select the name of the
network element to check. The Regular checks you defined for
this Checked Element appear in the Edit Health Check Group
table.
4. From the Enable column, select the checks required for this group
for this Checked Element.
5. Click Apply. The health check Group is configured.
6. Continue to configure new groups or click Ok to exit the window.
7-22 CID User Guide

Farm Health Check

Used in large configurations with farms containing multiple servers, the
Farm oriented Health Check automates and simplifies the Health
Monitoring configuration process by replicating a defined check for all
servers in a farm.
To configure a Farm oriented health check:

2. From the CID Traffic Redirection window, select the Farms tab and
from the Farms table that appears select a farm that you want to
check and click the Health Monitoring Settings button. The
Health Checks Per Farm window appears.
3. From the Health Checks Per Farm window, click Add. The Edit
Active Health Check window appears.
4. From the Edit Active Health Check window, select from the
following options:
CID User Guide 7-23

• Duplicate this Health Check for all Farm’s servers

If you select this option, the health check you define will be
replicated and associated to all the servers of the selected
farm.
• Set Health Check attribute for each Server in Farm
If you select this option, you can manually configure a custom
health check for each server of the selected farm.
5. From the Health check name dropdown list, select the name of
the check. For the remaining parameters and settings from the
Edit Active Health Check window, see Regular Health Check,
page 7-19.
6. Click Ok to apply the setup. The new farm check appears in the
Health Checks per Farm table.
Note: This feature is an APSolute Insite feature and is not
supported by WBM or CLI.
7-24 CID User Guide

Section 7-3 Health Check Methods

Section 7-3 Health Check Methods describes the methods or protocols
that are used in Health Check configuration.
• Predefined Methods, page 7-26
• User Defined Methods, page 7-39
CID User Guide 7-25

Health Check Methods
Predefined Methods
Table 7-1 describes the predefined Health Check Methods and their
configurable arguments.
Table 7-1 Health Check Methods
Method
Description
Name
ARP Module sends an ARP request to the destination address, and

waits for a reply.
Arguments: N/A
Citrix APP Using the Citrix Application Browsing check, the Health
Browsing Monitoring Module sends a "Hello" request to the Citrix server.
The Citrix server in reply, sends the list of applications running
on the server. The Health Monitoring Module, compares the
application available on the server based on the Citrix's reply
with a list of up to four applications, configured by the user. In
case all the users' configured applications are running on the
Citrix server, the check passes. In case there are no configured
applications, the Health Monitoring Module completed the
handshake. This check uses UDP port 1604 by default.
Configurable Arguments: The user can configure up to four
applications running on the server at any given time.
Citrix ICA Using the Citrix ICA check, the Health Monitoring Module
initiates a connection to the Citrix server, using TCP port 1494
and performs a Citrix handshake. This check passes when the
Health Monitoring Module identifies the Citrix's reply within the
first reply packet.
7-26 CID User Guide

Table 7-1 Health Check Methods (cont.)
Method
Description
Name
Diameter To check Diameter application availability the Diameter

health check initiates a connection to the Diameter server.
The module performs a Diameter handshake (CER/CEA)
and sends an LIR message or another application
message. Then the Diameter connection is disconnected
using the DPR or the DPA message.The check passes
when the accepted result codes are received from the
Diameter server. The Diameter server defines various
Attribute Value Pairs (AVP) and expected attribute values in
the response received from the Diameter server.
DNS Module submits a DNS query to the configured destination

address and host. The module verifies that the reply is received
with no errors, and that it matches the specified address. If the
IP address parameter is not defined, only the return code of the
reply is validated (not the IP address it contains).
Arguments: Hostname to Query; Address to match
CID User Guide 7-27

Method
Description
Name
Fix When the module performs the FIX health check, it creates a
FIX packet and sends it to the FIX server (after the TCP
handshake). A successful check is a check where in the reply
packet, the "TestReqID" value is the same as the one that the
user configured; the "SenderCompID" is the configured value
of the "TargetCompID" field and vice versa and the FIX version
is the same as the configured value.
Arguments:
• TestReqID - Test Request identification - This text is
appended to tag TestReqID (112) that is sent as the
message Note: The TestReqID field is a non-mandatory
field; The device sends the number of seconds passed
since 01/01/1970 in case the user did not configure that
field.
• SenderCompID - Used as a standard header field by
the FIX protocol. This field is mandatory.
• TargetCompID - Used as a standard header field by the
FIX protocol. This field is mandatory.
• FIX Version - The FIX version which will be used by the
check. This field is mandatory.
FTP Module executes USER and PASS commands on the FTP

server. When the login process is successfully completed, the
module executes a SYST command. It verifies the existence of
the file on the FTP server, but it does not download the file or
check its size. If all commands were successfully executed, the
module terminates the connection.
The module uses a control session only, not a data session.
Arguments: Username; Password; Filename
7-28 CID User Guide

Method
Description
Name
HTTP Module submits an HTTP request to the destination IP

address.You can also test a specific URL. The request is GET,
POST, or HEAD; proxy or Web format, and may include a no-
cache directive. The module verifies that the returned status is
200. If the checked server is password protected, the module
sends an authorized name and user password. The HTTP
requests are in HTTP 1.0 format.
Arguments: Hostname; path; HTTP method; HTTP format;
use of no-cache; text for search within HTTP header and body;
indication whether the text should appear or not, Username;
Password; HTTP return codes (up to 4); return code of 200.
IMAP4 Module executes a LOGIN command to the IMAP server, and

verifies that the returned code is Ok.
Arguments: Username; Password
LDAP Module performs a Bind and Unbind session with the LDAP
server, using an anonymous username. The Bind operation
initiates a session between a client and a server and allows the
authentication of the client to the server. The Unbind operation
terminates a protocol session. Default port for the LDAP health
check is the well-known LDAP UDP port 389. When needed,
the user can set another value in the Destination Port field.
LDAPS The module performs the above LDAP health check using
secured SSL channel.
NNTP Module executes a LIST command and verifies that the

returned status is valid.
CID User Guide 7-29

Method
Description
Name
Ping The module sends an ICMP echo request to the destination

address and waits for an echo reply. The module checks that
the reply was received from the same destination address that
the request was sent to, and that the sequence number is
correct.
Arguments:
• Should Ping Fail: whether the reply is received or not,
the default is that the check fails when the server does
not reply.
• Ping Data Size: the size of the ICMP echo request (1
byte to 1024 bytes). When not configured, the default is
64 bytes.
Physical Module checks the status of the physical interface. When the
Port link is up, the check passes.
Arguments: Physical port number
POP3 Module executes USER and PASS commands on the POP3

server, and checks that the returned code is OK.
Arguments: Username; Password
RADIUS The module sends RADIUS Accounting request with a User

Accountin Name, Password and Secret string, and verifies that the
g request was accepted by the server, which then expects an
Access Accept reply.
Arguments: Username; Password; Secret.
Notes:
• Ensure that the RADIUS server is configured to accept
RADIUS requests from the Radware device.
• If the "Destination Port Number" parameter is not
configured then the device uses UDP port 1813.
7-30 CID User Guide

Method
Description
Name
Radius The module sends an Access Request with a User Name,

Authentic Password and Secret string, and verifies that the request was
ation accepted by the server, which then expects an Access Accept
reply.
Arguments: Username; Password; Secret.
Note: Ensure that the RADIUS server is configured to accept
RADIUS requests from the Radware device.
SIP TCP The Session Initiation Protocol (SIP) is an IETF standard for
initiating an interactive user session that involves multimedia
elements such as video, voice, chat, gaming etc. SIP works in
the application layer of the OSI model (Layer 7). SIP can
establish multimedia sessions or Internet telephony calls, and
modify or terminate them.
Health Monitoring Module allows now to perform Health
Monitoring checks on SIP servers. The SIP health check is
done using the OPTIONS method. This method is used to
query SIP proxies and end-points as to their capabilities. The
capabilities themselves are not relevant to the health check,
what is relevant, is the "200 OK" response from the server. The
module uses port 5060 by default.
Arguments:
Request URI: The request's destination. (mandatory)
• From: The user should specify what the "logical name"
of the device is. (mandatory)
• Max Forwards: The default is 1
• Acceptable Response Codes: 200 is the default.
When an unacceptable response code is received - the
check fails.
• Content Match: a content that must be matched in the
response for it to be considered successful.
• Match Mode: defines whether the content must appear
in the reply or must not appear in the reply.
CID User Guide 7-31

Method
Description
Name
SIP UDP Same as SIP TCP, but running over the UDP protocol
RTSP Module executes a DESCRIBE command and expects a return

status of 200.
Arguments: Path on the server; Hostname
SMTP Module executes a HELO command to the SMTP server and

checks that the returned code is 250.
Arguments: Server name for the command.
Default: RADWARE.
SNMP The module sends an SNMP GET request, and validates the
value in the reply. When the returned value is lower than the
Min. Value or higher than the Max. Value, the check fails. When
the returned value is higher than the No New Sessions Value,
the bound element is set to No New Sessions. The results of
the SNMP check can be used for a load balancing decision, as
in Private Parameters Load Balancing Algorithms.
Note: For a device to consider the outcome of the check in the
load balancing decisions, the farm’s Dispatch Method should
be set to Response Time.
Arguments: SNMP Object ID to be checked; Community; Min.
Value; Max. Value; No New Sessions Value; Use Results For
Load Balancing
7-32 CID User Guide

Method
Description
Name
SSL The module performs an SSL handshake towards the server

and, after the session starts, the device performs a GET
request from the checked element.
Arguments: Hostname; Path; HTTP Method; Authorized
Username and Password; Match Search String; Match Mode;
HTTP Return Codes (similar to HTTP Check). Users can also
set:
• SSL Certificate File - Used by the device when the Web
server requires a Client Certificate during the SSL
handshake. Default: Client Certificate, generated by the
device.
• SSL Private Key File - Used by the device when the
Web server requires a key during the SSL handshake.
Default: Private Key, generated by the device.
SSL Hello Module sends an SSL Hello packet to the server (using SSL3),
and waits for an SSL Hello reply. The session is then closed
(using a RESET command).
Note: Since generating SSL keys on the server is a time
consuming process, it is recommended to use a timeout of 3 to
5 seconds.
Arguments: SSL Versions: V23 or V30. SSL v30 means that
pure SSLv3 is used, SSLv23 means that the client sends an
SSLv2 request to open an SSLv3 session (in Explorer, for
example)
CID User Guide 7-33

Method
Description
Name
SSL Module performs an SSL handshake towards the server and

after the session starts, the device performs a GET request
from the checked element. Users can set:
SSL Certificate File: When the Web server requires a Client
Certificate during the SSL handshake.
Default: Client Certificate generated by the device.
SSL Private Key File: Used by the device when the Web
server requires a key during the SSL handshake.
Default: Private Key generated by the device.
Arguments: Similar to HTTP Check (Hostname, Path, HTTP
Method, Authorized Username and Password, Match Search
String, Match Mode, HTTP Return Codes)
TCP Port Module checks the availability of the specified TCP port.
Arguments: Complete TCP Handshake.
Sets whether the check sends an ACK packet before the RST
packet or not. Setting this parameter to Yes results in the TCP
handshake flow: SYN, SYN_ACK, ACK, RST. Setting this
parameter to No results in the TCP handshake flow: SYN,
SYN_ACK, RST.
TCP User Module uses a User Defined TCP Health Check.

Defined Arguments: Packet Sequence ID
UDP Port Module checks the availability of the specified UDP port. This
check does not test the server's availability, but the
application's availability within the server. This is due to the
nature of UDP: when the UDP application is operational, no
reply is received; when the UDP application is not operational,
an ICMP message UDP Port Unreachable is sent, so that the
absence of a reply indicates the application’s availability. This
means that when the server is down, the application might still
be considered as running. Therefore, the UDP Port check
should always be used in combination with another server
availability check, for example Ping or ARP.
7-34 CID User Guide

Method Arguments
You can configure arguments specific to each Health Check Method.
In APSolute Insite Health Check configuration window, you can use the
Method Arguments button to view and edit arguments for the selected
Method.
When using Web Based Management, CLI, Telnet or SSH, you can
configure the additional arguments using a string with this format:
ARG=VAL|ARG=VAL|
Following each argument, the equation sign should appear, then the
required value. A “|” sign is used as a delimiter between the arguments.
No extra spaces are allowed.
Table 7-2 lists the additional configurable method arguments for each
Check Method, and details mandatory arguments, default values, and
more.
Table 7-2 Health Check Method Arguments
Method Argument Argument Mandatory Additional Default

Name Name Description Info
(and ID)
ARP (11) No args
DNS (10) HOST Hostname to Yes

query
ADDR Address to be No Validate only

received the DNS
return code
FTP (6) USER Username Yes
PASS Password Yes
HTTP (2) PATH Path of file on No Any /

Web server to configured
be requested value must
begin with a/.
HOST Hostname No Server IP

address
CID User Guide 7-35

Table 7-2 Health Check Method Arguments (cont.)

(and ID)
HTTP (2) MTD HTTP method No G=GET, G
continued to submit P=POST,
H=HEAD
PRX Use proxy No Y=Use proxy N

HTTP HTTP, N=Use
Web server
HTTP
NOCACHE Use pragma: No Y= Use N

no-cache pragma: no-
cache, N=Do
not use
pragma: no-
cache
MTCH Pattern for No Wildcards not

content match supported
MEXIST Content match No Y=Fail check if Y

pattern should pattern not
be present or found, N=Fail
absent check if
pattern is
found
USER Username for No

basic
authentication
PASS Password for No

basic
authentication
C1 Valid http code No

1

2

3
7-36 CID User Guide


(and ID)
HTTP (2) C4 Valid http code No
continued 4
IMAP (7) USER Username Yes
PASS password Yes
PING (0) FAIL Check fails No Y= Fail when N

when reply is server replies,
received or not N=Fail when
received server does
not reply
DSIZE Data size No =1 - 1024 64

bytes
POP(3) USER Username Yes
RADIUS USER Username Yes

(12)
PASS Password Yes
SECRET Radius secret Yes
RTSP (13) PATH Path of file on Yes

RTSP server
to be
requested
HOST Hostname to No IP address of

use in request server
SMTP (4) HELO Argument for No RADWARE

SMTP HELO
SSL (14) SSLV SSL Version No V23 or V30 V23
CID User Guide 7-37


(and ID)
TCP Port no args No

(1)
TCP User SEQID Packet Yes

Defined sequence to
(8) submit
UDP Port no args
7-38 CID User Guide

User Defined Methods

if you require a specific Health Check Method that is not provided by
the module, you can configure the health check protocol manually. This
is done by defining for every packet sequence a stream of send and
receive packets, each with a string to send or receive. The module then
sends the packets, and verifies that the received packets contain the
matching predefined string. Packet sequences are defined in the User
Defined Methods Table. Then the user-defined check can be used in
Health Checks configuration.
Note: User Defined Checks are available for TCP checks only.
To configure a user defined method for health check:

1. From the Health Checks window, click User Defined Methods.
The User Defined Methods window appears.
2. In the User Defined Methods window, click Add. The Edit User
Defined Methods window appears.
3. In the Edit User Defined Methods window, set the following
Sequence ID: The Sequence ID is a sequence of packets,
used later on as an argument in the TCP User
Defined health check. All packets with the same
Sequence ID belong to the same sequence.
The same sequence ID can be used in multiple
checks. The maximum value for Sequence ID
is: 429496729.
Note: The Sequence ID is used as the
arguement in the health check.
Type the ID number of the entire packet
sequence.
CID User Guide 7-39

Packet ID: This field identifies the order of sending and

receiving the packets within this packet
sequence. Several packets carrying information
can be defined to a user-defined check of the
same Sequence ID. This identifier is unique
within a packet sequence.
Type the ID number that identifies the packet
within this packet sequence.
Note: The first Packet ID of each sequence
must always be 0 and Packet IDs of a sequence
must always be consecutive.
Sequence This parameter enables you to define whether

Type: this packet is a Send of Recieve packet.
Compare This parameter defines how the Health
Method: Monitoring module checks the received packets
for a required string. If the value of the field is
set to Regular Expression, then the search will
take into account the regular expression signs
when searching for the configured string. If the
value of the field is set to Binary, the search
compares each character found to the ASCII
value of the character defined in the String field.
For example, if the String field is defined as
"^blue" and the Compare Method value is
defined as Regular Expression, the Health
Monitoring module matches the first expression
which starts with the word "blue". If the value of
the Compare Method is set to Binary, the Health
Monitoring module searches for the string ^blue,
taking into account the character ^.
7-40 CID User Guide

Sequence This string is either sent within the packet or

String: expected when the packet is received. For
‘Receive’ type packets, the string can include a
regular expression, which is a very effective
method of describing a pattern of characters.
The Health Monitoring module supports Posix
1002.3 regular expressions. The string can be
up to 80 characters.
The Health Monitoring method of "TCP user
defined" allows for definition of binary packet
sequences, which are being sent within TCP
segments, or being matched against the content
of the received TCP segments. The content of
the packet sequence is denoted as an ASCII
string with certain escape sequences used to
denote characters which are not considered
"printable".
CID User Guide 7-41

The Health Monitoring method of "TCP user

defined" allows for definition of binary packet
sequences, which are being sent within TCP
segments, or being matched against the content
of the received TCP segments. The content of
the packet sequence is denoted as an ASCII
string with certain escape sequences used to
denote characters which are not considered
"printable".
The escape sequences always start with the
backslash character ('\'), followed by one of the
following characters:
- a - the ASCII '7' character will be printed (Bell)
- b - the ASCII '10' character will be printed
(New Line feed)
- e - the ASCII '33' character will be printed
(Space)
- f - the ASCII '14' character will be printed (Shift
Out)
- n - the ASCII '12' character will be printed
(Form Feed)
- r - the ASCII '15' character will be printed (Shift
In)
- t - the ASCII '11' character will be printed
(Vertical Tab)
- v - the ASCII '13' character will be printed
(Carriage Return)
- {0,7} - if the backslash is followed by 3 octal
digits, then the character represented by an
octal number, consisting of these digits, will be
printed.
- x - the character represented by a 2 digit
hexadecimal number, inscribed right after the
'x', will be printed. Special cases:
7-42 CID User Guide

• If the backslash character is the last character

of the string, it will be discarded.
• If the backslash character is followed by any
character other than the ones listed above, it
will be printed verbatim. Hence, for example, if
you wish to have a backslash character in a
binary string ('\'), it must be escaped: '\\'.
Sequence The textual description of the specific packet in

Description: the sequence.
Note: Once a sequence is configured it is not
possible to change the Sequence Type from send
to receive or vice-versa.
4. Click Ok to apply the parameters. The Edit User Defined Methods
window closes. The new method is listed in the User Defined
Methods window.
5. To configure all the user defined methods, repeat steps 2-3.
6. Click Ok. The User Defined Methods window closes.
CID User Guide 7-43

Configuration Examples
Section 7-4 Configuration Examples

Section 7-3 Health Check Methods provides several examples
illustrating the variety of Health check configurations.
The following examples are included in this section:
• Health Check for Multiple Logical Servers, page 7-45
• Group Health Check, page 7-49
• User Defined TCP Check, page 7-52
• User-Defined TCP Check- Send SMTP Message, page 7-54
7-44 CID User Guide

Example - Health Check for Multiple Logical Servers

The example in Figure 7-1 illustrates a configuration where a single
physical server check determines the status of multiple logical servers.
Internet
Server
10.1.1.1
CID
VIP-H 100.1.1.101
VIP-F 100.1.1.102
VIP-R 100.1.1.103
Server
10.1.1.2
Figure 7-1 Health Monitoring of Multiple Logical Servers
Properties:
• There are 2 servers in this configuration, each server providing
these services: HTTP, FTP and RTP.
• CID checks the servers using HTTP Page, FTP and RTSP.
• In order to minimize load on the servers, CID pings each physical
server every 5 seconds, and issues each application check every
20 seconds.
Configuration:
1. From the main window, select APSolute OS >Traffic Redirection
> Farm Parameters. The Farm Table window appears.
2. From the Farm Table window, define 3 farms:
• VIP-H for HTTP
• VIP-F for FTP
• VIP-R for RTSP
For each farm, add two servers: 10.1.1.1 and 10.1.1.2.
CID User Guide 7-45

3. In Health Monitoring > Global Parameters, verify that the

Health Monitoring parameter is set to Monitoring Module.
4. In Traffic Redirection > Farm Parameters, ensure that the
relevant farm's Connectivity Method is set to Disabled.
5. Define the first set of check parameters for the servers:
a. In the Health Monitoring Health Check DB window, open the
Check Table window and click Insert. For the first server, set
the following parameters according to the explanations
provided:
Check Name: Server1 - FTP
Method Name: FTP
Interval: 20
Username: User1
Password: secret
b. For the second server set the following parameters according
Check Name: Server2 - FTP
6. Set the second set of check parameters for the servers:
provided:
Check Name: Server1 - HTTP
Method Name: HTTP
Interval: 20
Hostname: www.radware.com
Path: /
Insert more parameters as required.
7-46 CID User Guide

b. In the same manner for the second server, set the following
Check Name: Server2 - HTTP
7. Define the third set of check parameters for the servers:
provided:
Check Name: Server1 - RTSP
Method Name: RTSP
Interval: 20
Hostname: /movies/disney.asf
Path: /
Check Name: Server2 - RTSP
8. Define the third set of check parameters for the servers:
a. From Health Monitoring > Check Table, open the Check
Table window and click Insert. For the first server, set the
Check Name: Server1 - Physical
Method Name: Ping
Interval: 5
CID User Guide 7-47

Check Name: Server2 - Physical
Note: The Interval for this check is shorter than for the previous
checks.
9. From the Regular Checks Table, configure the following:
Server Name Check Name Mandatory
VIP-F – server1 Server1 – FTP Mandatory
VIP-F – server1 Server1– Physical Mandatory
VIP-F – server2 Server2 – FTP Mandatory
VIP-F – server2 Server2 – Physical Mandatory
VIP-H – server1 Server1 – HTTP Mandatory
VIP-H – server1 Server1– Physical Mandatory
VIP-H – server2 Server2 –HTTP Mandatory
VIP-H – server2 Server2 – Physical Mandatory
VIP-R – server1 Server1 – RTSP Mandatory
VIP-R – server1 Server1– Physical Mandatory
VIP-R – server2 Server2 – RTSP Mandatory
VIP-R – server2 Server2 – Physical Mandatory
Using this configuration, a single ping is sent to each server every 5

seconds, and each of the application tests is sent for each server
every 20 seconds.
7-48 CID User Guide

Example - Group Health Check

The example in Figure 7-2 illustrates a health check configuration with
the use of groups.
DB Server
10.1.1.50
Web
Server Internet
10.1.1.1
CID
Web VIP 100.1.1.100
Server
10.1.1.2
DB Server
10.1.1.51
Figure 7-2 Group Health Check
Properties:
• CID checks the Web servers using the HTTP Check Method, with a
search string.
• For each Web server, at least one database server should function.
If both database servers are down, each of the Web servers is
considered to be out of service.
Note: Unrelated or default value parameters are omitted.
CID User Guide 7-49

Configuration:
1. From the main window select, APSolute OS > Traffic Redirection
> Farm Parameters. The Farm Table window appears.
2. From the Farm Table window, set the following parameters
Server Farm: 100.1.1.100
Web Server 1: 10.1.1.1
Web Server 2: 10.1.1.2
3. From Health Monitoring > Global Parameters, verify that Health
Monitoring is set to Monitoring Module (page 7-7).
4. From Traffic Redirection > Farm Parameters, ensure that the
relevant farm's Connectivity Method is set to Disabled.
5. From Health Monitoring >Health Check DB Table, click Insert.
6. Configure 2 Web servers:
a. For the first Web server, set the following parameters according
Check Name: Web Server 1 – HTTP
Method Name: HTTP
Destination Port: 80
Host Name: www.radware.com
Path: /index.html
Match String: Enter Username:
Match Mode: String Exists
b. For the second Web server, set the following parameters
Check Name: Web Server 2 – HTTP
7. Configure 2 Database servers:
7-50 CID User Guide

a. For the first Database server, set the following parameters

Check Name: Database Server 1 – Ping
a. For the second Database server, set the following parameters
Check Name: Database Server 2 – Ping
8. From the Regular Check Table, set:
Server Name Check Name Mandatory
Farm1 – Web Server 1 Web Server 1 - HTTP Mandatory
Farm1 – Web Server 1 Database Server 1 - Ping Non-Mandatory
Farm1 – Web Server 2 Web Server 2 - HTTP Mandatory
9. From the Group Check Table, set:
Element Name Selected Checks Group
Farm1 – Web Server 1 Web Server 1 - HTTP 1
Database Server 1 - Ping 2
Database Server 2 - Ping
Farm1 – Web Server 2 Web Server 2 - HTTP 1
Database Server 1 - Ping 2
Database Server 2 - Ping
CID User Guide 7-51

Example - User Defined TCP Check

This example describes a Packet Sequence configuration and use.
This packet sequence checks an SMTP Server by sending an E-mail
message.
Configuration:
1. From the User Defined Methods, define the following sequence:
Seq Pkt Type String Description

0 0 Receive ^220 +.* Receive mail server welcome
message
0 1 Send HELO radware\r\n Send HELO to mail server
0 2 Receive ^250 +.* Receive OK status from mail

server
0 3 Send MAIL FROM: Send the sender's address to

<sender@a.com>\r server
\n
0 4 Receive ^250 +.* Receive OK for sender address
0 5 Send RCPT TO: Send recipient’s address to

<user@company.c server
om>\r\n
0 6 Receive 250 +.* Receive OK on recipient
0 7 Send DATA\r\n Send DATA statement to server
0 8 Receive ^354 +.* Receive OK on DATA

statement
0 9 Send From: Send mail message

<sender@a.com>\r
\nSubject: test
message\r\text\r\n.\r
\n
0 10 Receive ^250 +.* Receive OK for the mail

message
0 11 Send SendQUIT\r\n Send QUIT to server
0 12 Receive ^221 +.* Receive OK for QUIT
7-52 CID User Guide

Note that on Receive type packets, it is recommended to look for

the return code as required, followed by “.*” indicating that the rest
of the packet is irrelevant.
2. From the Health Check DB window, click Insert, then set the
Check Name: Send Email
Method Name: TCP User Defined
Destination IP Address: Mail-server-IP
Destination Port: 25
Sequence ID: 0
3. Use the Regular Check Table to associate the check to the
appropriate server.
This is an advanced example, describing a Packet Sequence

configuration and use. This Packet Sequence checks an SMTP Server
by sending an email message.
CID User Guide 7-53

Example - User-Defined TCP Check- Send SMTP

Message
Configuration:
Note: Compare Method is set to Regular Expression in all the
sequences.
1. Use the Packet Sequence Table to define the following sequence:
Table 7-3 Packet Sequence Table
Seq PKT Type String Description
0 0 Receive ^220 +.* Receive mail

server welcome
message.
0 1 Send HELO Send HELO to

radware\r\n mail server.
0 2 Receive ^220 +.* Receive OK

status from mail
server.
0 3 Send MAIL FROM: Send the

<sender@a.com sender‘s
>\r\n address to the
server.
0 4 Receive ^220 +.* Receive OK for

sender address.
0 5 Send RCPT TO: Send recipients

<user@compan address to
y.com>\r\n server.
0 6 Receive ^220 +.* Receive OK on

recipient
0 7 Send DATA\r\n Send DATA

statement to
server.
7-54 CID User Guide

Table 7-3 Packet Sequence Table
Seq PKT Type String Description
0 8 Receive ^354 +.* Receive Ok on

Data statement
0 9 Send From: Send mail

<sender@a.com message
>\r\nSubject:
test
message\r\text\r
\n.\r\n

mail message.
0 11 Send QUIT\r\n Send QUIT to

server

Quit
Note: that on Receive type packets, it is recommended to look for the

return code as required, followed by ".*" indicating that the rest of the
packet is irrelevant
2. In the Check Table window (Health Monitoring/Check Table),
click Insert to define the following check parameters (unrelated or
default value parameters are omitted):
Check Name Send Email
Method Name TCP User Defined
Destination IP Mail-server-IP
Address
Destination Port 25
Sequence ID 0
CID User Guide 7-55

7-56 CID User Guide

CHAPTER 8
Chapter 8 - Bandwidth Management
• Section 8-1: Introduction to Bandwidth Management, page 8-2
• Section 8-2: Bandwidth Management Policies, page 8-7
• Section 8-3: Bandwidth Management Classes, page 8-18
• Section 8-4: Protocol Discovery, page 8-33
• Section 8-5: Interface Classification, page 8-37
CID User Guide 8-1

Introduction to Bandwidth Management
Section 8-1 Introduction to Bandwidth

Management
Section 8-1, Introduction to Bandwidth Management, describes the
Bandwidth Management module and explains how you can gain full
control over the available bandwidth.
• What is Bandwidth Management, page 8-3
8-2 CID User Guide

What is Bandwidth Management

The Bandwidth Management module includes a feature set that allows
you to have full control over the available bandwidth. Using these
features, applications can be prioritized according to a wide array of
criteria, while taking the bandwidth used by each application into
account. For example, Bandwidth Management allows you to assign
HTTP traffic a higher priority than SMTP traffic, which in turn may have
higher priority than FTP traffic. At the same time, a Bandwidth
Management solution can track the actual bandwidth used by each
application and either ensure a guaranteed bandwidth for a certain
application and/or set limits as to how much each classified traffic
pattern can utilize.
DefensePro‘s Bandwidth Management capability allows you to define
policies that restrict or maintain the bandwidth that can be sent or
received by each application, user, or segment. Controlling the
maximal bandwidth of corporate resources that can be consumed by
DoS attacks limits the attack spread, ensuring that other mission critical
operations are not affected and continue to enjoy the bandwidth and
service level required to guarantee smooth business operation.
Carriers can also ensure that a customer's Service License Agreement
(SLA) is not compromised due to a DoS attack launched on another
customer.
Using the Bandwidth Management module, Radware devices can
classify traffic according to predefined criteria and enforce a set of
actions on that traffic. A comprehensive set of user-configurable
policies controls how the device identifies and acts upon each packet.
When a packet is matched, the device can do one of three things:
• Discard the packet:This allows the Bandwidth Management
module to provide a very robust and granular packet filtering
mechanism.
• Forward the packet in “real time”: This means that the packet
bypasses the entire bandwidth management system and is
immediately forwarded by the device. The end result is effectively
the same as if bandwidth management was not enabled at all.
• Prioritize the packet: This allows the mechanism to prioritize
services.
CID User Guide 8-3

If the packet is to be prioritized, it is placed into a queue. The queue is

then assigned a priority from 0-7, with 0 being the highest priority and 7
the lowest. Each policy gets its own queue. The number of queues is
equal to the number of policies in the policy database, but each queue
is labeled with one of the 8 priorities 0-7. This means that there could
be 100 queues (if there are 100 policies), with each queue having a
label from 0-7.
Scheduler Algorithm
The scheduler takes packets from the many queues and forwards
them. The scheduler operates through one of two algorithms: Cyclic
and CBQ (Class-Based Queuing).
With the Cyclic algorithm, the scheduler gives each priority a
preference ratio of 2:1 over the immediately adjacent lower priority. In
other words, a 0 queue has twice the priority of a 1 queue, which has
twice the priority of a 2 queue, and so on. The scheduler systematically
goes through queues of the same priority when it is time to forward a
packet with this priority.
The CBQ algorithm has the same packet-forwarding pattern as the
WFQ algorithm, with one significant difference. The CBQ algorithm is
aware of a predefined bandwidth configured per policy. As policies are
configured, they can be given a minimum (guaranteed) allotted
bandwidth number, in Kbps (see Guaranteed Bandwidth, page 8-12).
Note: Unless CBQ is used, policies cannot be configured with an
associated bandwidth.
Application Classification
Application Classification is defined as Per Packet or Per Session. If
Application Classification is defined as Per Packet, the device classifies
every packet that flows through it. In this mode, every single packet
must be individually classified.
If Application Classification is defined as Per Session, all packets are
classified by session. An intricate algorithm is used to classify all
packets in a session until a “best fit” policy is found, fully classifying the
8-4 CID User Guide

session. Once the session is fully classified, all packets belonging to

the same session are classified accordingly. This not only allows for
traffic classification according to application, but also saves some
overhead for the classifier, as it only needs to classify sessions, and not
every single packet.
Notes:
• When the direction of the policy is set to Session, see page 8-9, it is
not possible to change the Application Classification from Per
Session to Per Packet.
• In case the Application Classification is set to Per Packet, it is not
possible to configure policies’ direction to Session, see page 8-9.
Classification Modes
The following classification modes are available:
• Policies: The device classifies each packet or session by matching
it to policies configured by the user.
• Diffserv: The device classifies packets only by the DSCP
(Differentiated Services Code Point) value.
• ToS: The device classifies packets only by the ToS (Type of
Service) bit value.
Random Early Detection

The Random Early Detection (RED) algorithm can be used to protect
queues from overflowing that may cause serious session disruption.
The algorithm draws from the inherent retransmission and flow control
characteristics of TCP.
If the RED algorithm is deployed, the status of the queues is monitored.
If the queues are approaching full capacity, random TCP packets are
intercepted and dropped. Only TCP packets are dropped, and the
packet selection is entirely random. This protects the queues from
becoming completely full, which causes less disruption across all TCP
sessions and also protects UDP packets.
Radware's bandwidth management mechanism can deploy RED in two
forms:
CID User Guide 8-5

• Global RED: Global RED monitors the capacity of all the queues
(i.e., the global set of queues) and randomly discards TCP packets
before the classifier sees them.
• Weighted RED (WRED): The RED algorithm is deployed per
queue (instead of for all the packets in all the queues) and the
priority of the queue has an effect on whether or not a packet gets
dropped.
8-6 CID User Guide

Section 8-2 Bandwidth Management Policies

Section 8-2, Bandwidth Management Policies, describes how to define
Bandwidth Management policies.
• What is Bandwidth Management Policy, page 8-8
• Bandwidth Management Classification Criteria, page 8-9
• Bandwidth Management Rules, page 8-12
• Policy Index, page 8-15
CID User Guide 8-7

Bandwidth Management Policies
What is Bandwidth Management Policy

The policy mechanism enables you to classify traffic passing through
the Radware device and enforce on it bandwidth management.
The policy database is made up of two sections, active and inactive.
The temporary or inactive policy database contains policies that can be
altered and configured without affecting the current operation of the
device. As these policies are adjusted, the changes do not take effect
unless the inactive database is activated. The activation basically
updates the active policy database, which is what the device uses to
sort the packets that flow through it.
A policy consists of a set of conditions (classification criteria) and a set
of actions that are applied when the conditions are met.
8-8 CID User Guide

Bandwidth Management Classification Criteria

A policy includes the following traffic classification criteria:
• Source: Defines the source of the traffic. The source can be a
specific IP address or a network. A network is a collection of ranges
and/or subnets. You should first configure the networks. The default
value is any, which covers traffic from any source.
• Destination: Defines the destination of the traffic. Can be specific
IPs, a range of IP addresses, or IP subnet addresses. The default
value is any, which covers traffic to any destination.
Note: To limit or block access to the device's interface, type the IP
address of the interface in the Destination box.
• Direction: Defines the direction of the traffic and has the following
values:
OneWay Setting the direction to OneWay enables
asymmetric Bandwidth Management. When a
policy is set to OneWay, the classifier searches
for traffic in one direction only and the device
classifies only one direction of the traffic; the
return traffic is not classified.
TwoWay When a policy is set to TwoWay, the classifier
searches for traffic in both directions and the
device replaces the source and destination IP
addresses and ports (in case the policy is a Layer
4 or Layer 7 Policy) of the return traffic.
CID User Guide 8-9

Session TCP/UDP traffic - Any session opened by user A

(with source IP AIP and source port Aport) to user
B (with destination IP BIP and destination port
Bport) is allowed, as well as the reply traffic with
source IP BIP, source port Bport to destination IP
AIP, destination port Aport User B is not permitted
to establish a new session with A.
Non TCP/UDP traffic - Any session opened by
user A (with source IP AIP) to user B (with
destination IP BIP) using a specific IP protocol is
allowed, as well as the reply traffic with source IP
BIP to destination IP AIP, as long as it uses the
same IP protocol as the packet that opened the
session from A to B. User B is not permitted to
establish a new session with A.
Examples:
If you have the following rule:
• Source: IP_A
• Destination: IP_B
• Service: HTTP
• Direction: One Way
Only traffic with a source IP, IP_A, and a destination IP, IP_B, with
source port X and destination port 80 is classified. The return
packet, with source IP IP_B and destination IP IP_A, with source
port x and destination port 80 would not be classified.
If you have the following rule:
• Source: NET_A
• Destination: Bet_B
• Service: HTTP
• Direction: Two ways
A packet with a Source IP belonging to NET_A and a destination IP
belonging to NET_B requesting an HTTP request are matched.
However, a packet with a Source IP belonging to NET_B and a
destination IP belonging to NET_A requesting an HTTP request are
not matched, even if the policy is set to "two way".
8-10 CID User Guide

• Service: Defines the traffic type. The Service configured per policy
can allow the policy to consider other aspects of the packet, such
as the protocol (IP/TCP/UDP), TCP/UDP port numbers, bit patterns
at any offset in the packet, and actual content (such as URLs or
Cookies) deep in the upper layers of the packet. Available Services
are very granular. The default value is none, which covers all
protocols.
• Inbound Physical Port Group: Classifies only traffic received on
physical interfaces of the device. Enables you to set different
policies for identical traffic classes that are received on different
interfaces of the device.
• VLAN Tag Group: Defines VLAN traffic classification according to
VLAN ID tags.
• Traffic Flow Identification: Defines what type of traffic flow is to
be limited via this policy. The available options are:
• None
• Client (source IP)
• Session (source IP and port)
• Connection (source IP and destination IP)
• FullL4Session (source and destination IP and port)
• SessionCookie (must configure cookie identifier)
• Cookie Field Identifier: A string that identifies the cookie field
whose value must be used to determine the different traffic flows.
• Max Number of HTTP Requests per Second: This parameter
limits the number of HTTP requests per second per traffic flow.
Using the field, you can limit the number of HTTP GET/POST and
HEAD requests, arriving from the same user per second. The
Bandwidth Management module keeps track of new requests per
second per traffic flow, whether the traffic flow identification is
SessionCookie or any other parameter.
Note: This is required only when Traffic Flow Identification is set to
SessionCookie. In such a case, the Bandwidth Management
classifier searches for the Cookie Field Identifier followed by “=”
and classifies flows according to the value.
CID User Guide 8-11

Bandwidth Management Rules

Once the traffic is classified and matched to a policy, the Bandwidth
Management rules can be applied to the policy.
Action
The action determines the access given to traffic. Possible values
include:
• Forward: The connection is accepted and traffic is forwarded to its
destination. This is the default value.
• Block: All packets are dropped.
• Block and Reset: All packets are dropped. In TCP traffic, an RST
packet is sent to the client.
• Block and Bi-directional Reset: All packets are dropped. In TCP
traffic, an RST packet is sent to both client and server.
Priority
If the action associated with the policy is “forward”, then the packet is
classified according to the configured priority. There are nine available
options: Real-time forwarding and priorities 0 through 7.
Guaranteed Bandwidth
If the scheduler is configured to use the CBQ algorithm, the policy can
be assigned a minimum (guaranteed) bandwidth. The scheduler will
not allow packets that were classified through this policy to exceed this
allotted bandwidth, unless borrowing is enabled. The maximum
bandwidth configured for the entire device, as described above,
overrides per-policy bandwidth configurations. In other words, the sum
of the guaranteed bandwidth for all the policies cannot be higher than
the total device bandwidth.
8-12 CID User Guide

Borrowing Limit
Borrowing can be enabled when the scheduler operates through the
CBQ algorithm. If enabled, the scheduler can borrow bandwidth from
queues that can spare it, to forward packets from queues that have
exceeded (or are about to exceed) their allotted amount of bandwidth.
The combination of Guaranteed Bandwidth and Borrowing Limit fields
value causes the bandwidth allotted to a policy to behave as follows:
Guaranteed Borrowing Limit Policy Bandwidth
Bandwidth
0 0 Burstable with no limit, no
minimum guaranteed.
X 0 Burstable with no limit, minimum
of X guaranteed.
0 Y Burstable to Y, no minimum
guaranteed.
X Y (Y>X) Burstable to Y, minimum of X
guaranteed.
X X Non-burstable, X guaranteed.
Policy Groups
You can define several bandwidth borrowing domains on a device by
organizing policies in groups. Bandwidth that is not utilized by a specific
policy in a group is allocated proportionally to the other policies.
Allowing policies to borrow from each other prevents starvation and
utilizes the bandwidth more efficiently. Only policies that participate in a
specific group can share bandwidth.
The total bandwidth available for a policy group is the sum of the
Guaranteed Bandwidth values of all policies in the group.
Policy Group Configuration Guidelines:

1. Set the Global Bandwidth Management parameter Dynamic
Borrowing to Enable.
2. Define policy groups.
CID User Guide 8-13

3. Define the device policies. Configure Guaranteed Bandwidth with

the desired value and Borrowing Limit as 0. The bandwidth
limitation is ignored as the policy is able to borrow unused
bandwidth from other policies in the group. For each policy, select
the policy group to which it belongs.
4. Perform Update policies command.
Notes:
• Whenever bandwidth borrowing and/or prioritization is applied, the
maximum bandwidth available for allocation per each physical port
must be configured (for example, if a device’s Fast Ethernet port is
connected to a router that supports up to 2 Mbps, the bandwidth for
this port must be set to 2 Mbps. The default setting is according to
physical size 100 Mbps).
• The Borrowing Limit parameter must be set to 0 for all the policies
in the group, and the Dynamic Borrowing global parameter must be
enabled.
Traffic Flow Max BW

The maximum bandwidth allowed per traffic flow.
Max Concurrent Sessions

The maximum number of concurrent sessions allowed for a client IP.
Note: This option is not available if the Traffic Flow Identifier is set to
Session or FullL4Session.
MAX Requests Per Second

When the Traffic Flow Max BW parameter is configured, and the Traffic
Flow Identification parameter is set to Session Cookie, the device can
track and limit the number of requests, such as HTTP GET, Post, or
HEAD per Cookie.
8-14 CID User Guide

Packet Marking
Packet Marking refers to Differentiated Services Code Point (DSCP) or
Diffserv. It enables the device to mark the matched packet with a range
of bits.
Report Blocked Packets

Report Blocked Packets enables you to define whether blocked traffic
is reported. The following configuration options are available:
• Disable: Disables the capability.
• Report Blocked Packets: The device sends reports about the
blocked packets via Syslog / emails and traps.
• Security Event: Enables reporting of blocked packets to the
Application Security logs.
Policy Index
The Policy Index or order is a number that determines the order of the
policy in the entire policy database. When the classifier receives a
packet, it tries to find a policy that matches the packet. The classifier
searches the policy database starting with policy #1, in descending
order. Once a policy is matched, the process is stopped. Using this
logic, the very last policy configured should be the policy that is
enforced on all packets that do not match any other policies. In other
words, the last configured policy is the “default” policy.
Note: It is recommended to configure the most frequently used policies
first.
Activation/Inactivation Schedule
Sometimes it is required in the networks that specific policies in a
network must remain inactive during certain hours of the day, or a
certain policy is activated in the middle of the night. For example, a
school library may want to block instant messaging during school
hours, but allow it after school hours, or an enterprise may assign high
priority to mail traffic between 08:00-10:00.
CID User Guide 8-15

You can schedule the activation and inactivation of specific Bandwidth

Management policies. Using the Event Scheduler, you can create
events which can then be attached to a policy's configurations. Events
define the date and time in which an action must be performed.
To define events in the Event Scheduler:

1. In the main window, select APSolute OS > BWManagement. The
Bandwidth Management window appears.
2. In the Bandwidth Management window, click Policy Scheduler.
The Event Scheduler window appears.
3. In the Event Scheduler window, set the following parameters
Name: The name of the event.
Frequency: How often the event occurs: once,
daily or weekly.
Days: If the Frequency selected is weekly,
you must configure on which day the
event occurs.
Time (HHMM): The time on the designated day.
Note: In case multiple days are
selected, then the Time value is the
same for all the configured days in
which the event occurs.
Default value: 12:00 am (0000).
Date (DDMMYYYY): If the Frequency selected is once,
then you must configure the date on
which the event occurs.
4. Click Add. The new event appears in the Events table.
To apply an event to a policy:

2. In the Bandwidth Management window, click Modify > Add. The
Edit Policy window appears.
8-16 CID User Guide

3. In the Edit Policy window, click Advanced. The Advanced pane

appears.
4. To create a new event, click Schedule Table and define a new
event (see page 8-16).
5. To activate a specific event for this policy, from the Activation
Schedule dropdown list, select the event that you want to apply to
this policy and click Ok.
6. To inactivate a specific event for this policy, from the Activation
Schedule dropdown list, select the event that you want to
inactivate and click Ok.
CID User Guide 8-17

Bandwidth Management Classes
Section 8-3 Bandwidth Management Classes

Section 8-3, Bandwidth Management Classes, explains how to define a
service. A service enables flexibility for the classifier as it provides the
system with a large number of possibilities for packet identification.
• Services, page 8-19
• Networks, page 8-25
• Port Groups, page 8-26
• VLAN Tag Groups, page 8-27
8-18 CID User Guide

Services
A very advanced and granular set of services can be configured within
the Bandwidth Management system. Services are configured
separately from policies. As each policy is configured, it can be
associated with a configured Service.
The Service associated with a policy in the policy database can be a
basic filter, an advanced filter, or a filter group. This provides
tremendous flexibility for the classifier as it essentially gives the system
a large number of possibilities for packet identification.
Basic Filters
The basic building block of a Service is a basic filter. A basic filter is
made up of the following components:
• Protocol: The specific protocol that the packet should carry. The
possible choices are IP, TCP, UDP and ICMP. If the protocol is
configured as “IP”, all IP packets (including TCP and UDP) are
considered. When configuring TCP or UDP protocol, some
additional parameters are also available:
• Destination Port (From-To): Destination port number for the
selected protocol. For example, for HTTP, the protocol would
be configured as TCP and the destination port as 80. The port
configuration can also allow for a range of ports to be
configured.
• Source Port (From-To): Similar to the destination port, the
source port that a packet should carry to match the filter.
• Offset Mask Pattern Condition (OMPC): The OMPC is a means
by which any bit pattern can be located for a match at any offset in
the packet. This can help in locating specific bits in the IP header,
for example. TOS and Diff-serv bits are perfect examples of where
OMPCs can be useful. It is not mandatory to configure an OMPC
per filter. However, if an OMPC is configured, the packet needs to
match the configured protocol (and ports) AND the OMPC.
CID User Guide 8-19

Content
When the configured protocol is TCP or UDP, it is possible to search for
any text string in the packet. Like OMPCs, a text pattern can be
searched for at any offset in the packet. HTTP URLs are perfect
examples of how a text search can aid in classifying a session.
The service editor allows you to choose between multiple types of
configurable content: URL, hostname, HTTP header field, cookie, mail
domain, mail to, mail from, mail subject, file type, regular expression,
and text. If the content type is “URL”, for example, then the session is
assumed to be HTTP with a GET, HEAD, or POST method. The
classifier searches the URL following the GET/HEAD/POST to find a
match for the configured text. In this case, the configured offset is
meaningless, since the GET/HEAD/POST is in a fixed location in the
HTTP header. If the content type is “text”, then the entire packet is
searched for the content text, starting at the configured offset.
By allowing a filter to take the actual content of a packet/session into
account, the classifier gains a powerful way to recognize and classify
an even wider array of packets and sessions.
Like Impacts, the configuration of content rules is not mandatory.
However, if a content rule exists in the filter, then the packet needs to
match the configured protocol (and ports), the configured OMPC (if one
exists), AND the configured content rule.
Advanced Filters and Filter Groups

An Advanced Filter is a combination of basic filters with a logical AND
between them. Let's assume filters F1, F2, and F3 have been
individually configured. Advanced filter AF1 can be defined as:
AF1= {F1 AND F2 AND F3}
In order for AF1 to be a match, all three filters (F1, F2, and F3) must
match the packet being classified.
A Filter Group is a combination of basic filters and advanced filters,
with a logical OR between them. To continue the example above, filter
group FG1 can be defined as:
FG1 = {AF1 OR F4 OR F6}
8-20 CID User Guide

In order for filter group FG1 to be a match, either advanced filter AF1,
basic filter F4, or basic filter F6 have to match the packet being
classified.
Radware devices are preconfigured with a set of basic filters and group
filters that represent applications commonly found in most networks.
Predefined Services for Bandwidth Management

Table 8-1 lists the predefined Bandwidth Management filters for each
service.
Table 8-1 Predefined Bandwidth Management Filters
Service
Description Filter Name
Name
ERP/CRM
sap Basic
Database
mssql Microsoft SQL service group Group
mssql- SQL monitoring traffic Basic

monitor
mssql-server SQL server traffic Basic
oracle Oracle database application service Group

group
oracle-v1 Oracle sql* Net v1-based traffic (v6, Basic

Oracle7)
oracle-v2 Oracle SQL*Net v2/Net 8-based traffic Basic

(Oracle7,8,8i,9i)
oracle-server Oracle Server (e-business solutions) Basic

1 on port 1525
oracle- Oracle Server (e-business solutions) Basic

server2 ON PORT 1527
CID User Guide 8-21

Service
Name
oracle- Oracle Server (e-business solutions) Basic

server3 on port 1529
Thin Client or Server Based
citrix Citrix connectivity application service Group

group.
Enables any type of client to access
applications across any type of
network connection.
citrix-ica Citrix Independent Computer Basic

Architecture (ICA)
citrix-rtmp Citrix RTMP Basic
citrix-rtmp Citrix RTMP Basic
citrix-ima Citrix Integrated Management Basic

Architecture
citrix-ma- Citrix MA Client Basic

client
citrix-admin Citrix Admin Basic
Peer-to-Peer
p2p Peer-2-Peer applications Group
edonkey File sharing application Basic
gnutella File sharing and distribution network Basic
fasttrack User-to-User Media Exchange Basic
Kaaza Kaaza File Sharing Application (Note: Basic

Music City Morpheous and Grokster
also classify as Kazza)
8-22 CID User Guide

Service
Name
Internet
dns Domain Name Server protocol
ftp-session File Transfer Protocol service - both Basic

FTP commands and data
http Web traffic Basic
http-alt Web traffic on port 8080 Basic
https Secure Web traffic Basic
icmp Internet Control Message Protocol Basic
ip IP traffic
nntp Usenet NetNews Transfer Protocol Basic
telnet
tftp Basic
udp Basic
Instant Messaging
aol-msg AOL Instant Messenger Basic
icq ICQ Basic
msn-msg MSN Messenger Chat Service Basic
yahoo-msg Yahoo Messenger Group
yahoo-msg1 Yahoo Messenger on port 5000 Basic
Email
CID User Guide 8-23

Service
Name
mail Group
smtp Basic
imap Basic
pop3 Basic
8-24 CID User Guide

Networks
What is a Network?
A Network a logical entity that consists of a group of IP addresses
linked together by a network IP and subnet or a range of IP addresses
(from-to), and is identified by a name. A Network can be configured
separately and individual elements of the Network list can then be used
in the individual policy. An entry in the Network list is known as a
configured “name” and can be either an IP/Mask combination or an IP
range. For example, network “net1” can be 10.0.0.0/255.0.0.0 and
network “net2” can be from 10.1.1.1 to 10.1.1.7. The Network list allows
either configuration.
The Bandwidth Management module allows multiple Networks to have
the same configured “name”. This allows a Network with the name
“net1” to actually encompass multiple disjointed IP address ranges.
Essentially, this makes the Network “name” a logical pointer to all
ranges configured with that name. This further facilitates the
configuration and management of the system.
Configuration Guidelines
To configure a Network:
• In the main window, select
APSolute OS > Classes > Networks > Modify > Add.
CID User Guide 8-25

Port Groups
Port Groups enable you to set different policies for identical traffic
classes that are received on different interfaces of the device. For
example, you can allow HTTP access to the main server only to traffic
entering the device via physical interface 3. This provides greater
flexibility in configuration. You should first configure Port Groups.
To configure Port Groups:

• In the main window, select APSolute OS > Classes >
Port Groups > Physical Port Groups.
8-26 CID User Guide

VLAN Tag Groups

VLAN Tag Groups allow you to set different policies for identical traffic
classes that are received with different values of 802.1q VLAN Tags.
For example, you can allow SMTP access to the internet only to traffic
tagged with a VLAN Tag with a specific value. This provides greater
flexibility in configuration. You must first configure VLAN Tag Groups.
To configure VLAN Groups:

1. In the main window, select APSolute OS > Classes
> Port Groups > VLAN Tag Groups.
CID User Guide 8-27

Example - Bandwidth Management Configuration

The example configuration for Bandwidth Management addresses the
following tasks:
• Limit FTP traffic to servers (20.10.1.3, 20.10.1.7, and 20.10.3.17)
incoming via physical port 5 or 7 to 300 Kbps.
• Guarantee 2 Mbps to Citrix traffic running on VLAN 2 and VLAN 7.
• Limit HTTP traffic to and from internal network 10.x.x.x to 1 Mbps.
• Prevent the infection of an e-mail virus on the network named
“Love Letter”.
Configuration
2. In the Bandwidth Management window, click Access Control &
BWM Parameters. The BWM Global Parameters window
appears.
3. In the BWM Global Parameters window, set the following
Classification Mode: Policies
Application Classification: Per Session
Scheduling Algorithm: CBQ
4. Click Ok to apply the setup and close the window.
5. Configure the required Physical Port Group:
a. In the Bandwidth Management window, click Port Groups. The
Port Groups window appears.
b. In the Port Groups window, click Physical Port Groups.
c. Select the Modify Table tab and click Add. The Edit Physical
Port Group window appears.
d. In the Groups text box, enter a new group: FTP ports.
e. Select the port 5 and port 7 checkboxes.
f. Click Ok.
6. Configure the required VLAN Tag Groups:
a. In the Port Groups window, click VLAN Tag Groups.
8-28 CID User Guide

b. Select the Modify Table tab and click Add. The Edit VLAN Tag
Groups window appears.
c. In the Edit VLAN Tag Groups window, create two separate
entries for the Citrix VLAN by setting the following parameters
Group Name: Citrix VLAN
Group Mode: Discrete
VLAN Tag: 2 (first)
7 (second)
d. Click Ok and then click Update Modifications.
7. Add two networks:
a. In the Bandwidth Management window, click Classes. The
b. In the Classes window, click Networks. The Network Table
window appears.
c. Select the Modify tab and click Add. The Edit Network Table
window appears.
d. In the Edit Network Table window, set the following parameters
Network Name: FTP Servers
From Address: Create three separate entries for
the FTP Servers with the following
IP addresses:
20.10.1.3
20.10.1.7
20.10.3.17
To Address: The same as the From Address.
e. In the same manner, add the second network by setting the
Network Name: Internal
CID User Guide 8-29


f. Click Ok to apply the setup and close the window.
8. Configure the Basic Filter to identify the e-mail virus:
a. In the Bandwidth Management window, click Classes.
The Classes window appears.
b. Click Add Regular. The New Service pane appears.
c. In the New Service pane, set the following parameters
Service Name: Love Letter
Protocol: TCP
Content Type: Mail Subject
Content: Love Letter
d. Click Add Service and then click Update Active Classes.
9. Configure the Policies:
a. In the Bandwidth Management window, click Modify and then
click Add. The Edit Policy window appears.
b. In the Edit Policy window, add the following four policies
To limit FTP traffic to FTP servers via ports 5 and 7 to 300
Kbps:
Policy Name: FTP
Service Type: Regular
Service: FTP
Source: Any
Destination: FTP Servers
Direction: Oneway
Action: Forward
Priority: 4
8-30 CID User Guide

Inbound Physical FTP Ports

Group:
Borrowing Limit: 300
To guarantee 2 Mbps to Citrix traffic running on VLAN 2 and 7:

Policy Name: Citrix
Service Type: Group
Service: Citrix
Source: Any
Destination: FTP Servers
Direction: Twoway
Action: Forward
Priority: 2
Generated Bandwidth: 2000
To limit HTTP traffic to the local network to 1 Mbps:

Policy Name: HTTP
Service: HTTP
Source: Any
Destination: Internal
Direction: Twoway
Action: Forward
Priority: 3
Inbound Physical FTP Ports
Group:
Borrowing Limit: 1000
To block the “Love-Letter” e-mail virus:
CID User Guide 8-31

Policy Name: Virus Love Letter

Service: Love Letter
Source: Any
Destination: Any
Direction: Twoway
Action: Block
10. Click Ok to apply the setup and close the window.
8-32 CID User Guide

Section 8-4 Protocol Discovery

Section 8-4, Protocol Discovery, describes the Protocol Discovery
feature that allows you to recognize the different applications running
on your network by creating Protocol Discovery Policies.
• What is Protocol Discovery, page 8-34
• Protocol Discovery Policies, page 8-35
CID User Guide 8-33

Protocol Discovery
What is Protocol Discovery

To use the Bandwidth Management module in an optimal way, network
administrators must be aware of the different applications running on
their network and the amount of bandwidth they consume. The
Protocol Discovery feature provides a full view of the different protocols
running on the network.
This feature can be activated on the entire network or on separate sub-
networks by defining Protocol Discovery policies.
8-34 CID User Guide

Protocol Discovery Policies

A Protocol Discovery policy consists of a set of traffic classification
criteria which includes:
• Source: Defines the source of the traffic. It can be a specific IP
address or a network. A network is a collection of ranges and/or
subnets. You should first configure the Networks. The default value
is any, which covers traffic from any source.
• Destination: Defines the destination of the traffic. It can be specific
IPs, a range of IP addresses, or an IP subnet address. The default
value is any, which covers traffic to any destination.
• Source MAC Address Group: Enables you to discover
applications and protocols present in the traffic sent by a
transparent network device (firewall, router).
• Destination MAC Group: Enables to discover applications and
protocols present in the traffic sent to a transparent network device
(firewall, router).
• Inbound Physical Port Group: Classifies only traffic received on
certain interfaces of the device. Enables you to set different policies
for identical traffic classes that are received on different device
interfaces.
• VLAN Tag Group: Defines VLAN traffic classification according to
VLAN ID tags.
• Direction: Defines the direction of the traffic. It can be One Way
(from Source to Destination) or Two Way.
Protocol Discovery Configuration Guidelines

To configure the Protocol Discovery:
1. In the main window, select APSolute OS > Bandwidth
Management. The Bandwidth Management window appears.
2. In the Bandwidth Management window, click Protocol Policies.
The Protocol Discovery Policies window appears.
3. In the Protocol Discovery Policies window, click Add. The Edit
Protocol Policy window appears.
4. In the Edit Protocol Policy window, set the parameters according
the traffic classification criteria explained above.
CID User Guide 8-35

Protocol Discovery
5. Click Ok to accept your changes and close the window.
To view the results:

1. Configure the Protocol Discovery as explained above in steps 1-2.
2. In the Protocol Discovery Policies window, click View Protocol
Statistics. The Protocol Statistics window appears.
8-36 CID User Guide

Section 8-5 Interface Classification

Section 8-5, Interface Classification, describes the process of interface
classification which is designed to enhance Bandwidth performance.
• Port Bandwidth, page 8-38
• Interface Classification, page 8-39
CID User Guide 8-37

Interface Classification
Port Bandwidth
In order to optimize the queuing algorithm, it is essential for the
Bandwidth Management module to be aware of the maximum available
ports’ bandwidth. This can be configured via the BWM Port Bandwidth
table. By default, the maximum available throughput is determined by
the port type - 100 Mbps for FE ports and 1Gbps for Giga ports. The
queuing mechanism only starts functioning upon link saturation.
Configuring the maximum throughput is the only way of determining if
the link is saturated.
To define a port’s maximum available bandwidth:

1. In the main window, select the CID device icon and click the Panel
View icon from the main toolbar. The panel view appears.
2. Right-click the required port (F1, F2, and so on) and select
Interface Parameters. The Interface Parameters window
appears.
3. In the Interface Parameters window, set the Available Bandwidth
parameter for the selected port in Kbps and click Ok.
8-38 CID User Guide

To increase performance, the Bandwidth Management module can be
configured to exclude traffic running through certain physical ports and/
or VLANs from the classification effort. In this way, valuable processing
time can be saved while enabling a simpler method of configuring the
device.
You may cancel classification according to Port or according to VLAN.
To cancel Interface Classification by port:

2. In the Bandwidth Management window, click Interface
Classification.The Interface Classification window appears.
3. In the Interface Classification window, select Cancel
Classification by Port and set the following parameters
Inbound Port: The number of the required port for
inbound traffic.
Outbound Port: The number of the required port for
outbound traffic.
Direction: The direction of the flow through
each port. Values can be Oneway -
the traffic flows in through the
Inbound Port and out through the
Outbound Port, or Twoway - the
traffic flows both ways through both
ports.
4. Click Add to add your parameter settings to the table.
5. Click Ok to record your changes and close the window.
To cancel Interface Classification by VLAN:

CID User Guide 8-39

2. In the Bandwidth Management window, click Interface

Classification. The Interface Classification window appears.
3. In the Interface Classification window, select Cancel
Classification per VLAN.
4. Select the checkboxes for the VLANs for which you want to cancel
classification.
5. Click Ok to record your changes and close the window.
8-40 CID User Guide

CHAPTER 9
Chapter 9 - Security
Chapter 9, Security provides a general overview of the APSolute OS
Security modules and sub-modules, as well as an explanation of the
signatures database and Radware Security Update Service (SUS).
This chapter contains the following sections:
• Section 9-1: Security Overview, page 9-2
• Section 9-2: Managing the Signatures Database, page 9-25
• Section 9-3: Intrusions, page 9-43
• Section 9-4: DoS/DDoS, page 9-72
• Section 9-5: Behavioral DoS, page 9-106
• Section 9-7: SYN Flood Protection, page 9-123
• Section 9-8: Protocol Anomalies, page 9-142
• Section 9-9: Anti-Scanning, page 9-156
• Section 9-10: Session Table, page 9-171
• Section 9-11: Evasion Techniques, page 9-176
• Section 9-12: Security Events and Reports, page 9-184
CID User Guide 9-1

Security Overview
Section 9-1 Security Overview

Section 10-1 introduces CID security and presents an overview of the
security modules.
• Security Introduction, page 9-3
• Security Modules, page 9-6
• Setting Up Security Policies in the Connect and Protect Table, page
9-10
• Enabling Protection and Setting Up General Security Parameters,
page 9-12
• Defining Connectivity, page 9-19
• Suspend Table, page 9-23
9-2 CID User Guide

Security Introduction
Radware’s CID isolates, detects, and blocks application attacks at
multi-Gigabit speed, protecting against viruses, worms, DoS attacks
and intrusions, and anomalies. CID provides secure Internet
connectivity with high performance, maintaining the legitimate traffic of
end users and customers.
CID performs deep packet inspection at multi-Gigabit speed to provide
security from the network layer up to the application layer. The system
implements a multi-layer approach to security that combines several
mechanisms for attack detection, with advanced mitigation tools that
focus on:
• Intrusions
• DoS
• Anomalies
• SYN Flood
• Anti-Scanning
Detecting
The security modules detect known and unknown attacks. Known
attacks are detected by searching for attack signatures within the
scanned packets. The security modules use a constantly updated
signatures database for attack detection. Known attack detection is
applied by defining Protection Policies. A profile binds together network
addresses and physical ports with a profile of attack protection.
Unknown attacks are detected using protocol anomaly inspection. The
security modules detect IP and UPI protocol anomalies using the
Anomaly module/tool. The protocol anomaly inspection can detect
anomalies on layer 3, 4, and 7 protocols.
Protecting
The security modules protect network and application level resources
against attacks destined for the internal IP addresses of the network
elements or attacks destined for the device. Protection is provided for
CID User Guide 9-3

Security Overview
applications, operating systems, network equipment, and resources

behind the device.
Preventing
The security modules enable real-time prevention of attacks within the
defined network. The attack attempts are blocked by terminating the
sessions as they are recognized, either by dropping the malicious
packets or by resetting the connection. Both source and destination
reset options are supported.
The security modules also protect against network port scanning using
the Anti-Scanning module/tool. Hackers perform scanning prior to
launching an attack, looking for open TCP or UDP ports on the target
machine. Blocking this scanning prevents attacks from being launched.
Reporting
When a security module detects an attack, it reports the security event.
An event consists of complete traffic information, including source and
destination IP addresses, TCP/UDP port numbers, physical interface,
date and time of attack, and so on. Event information is registered
internally via the device log file and alerts table, or externally via the
Syslog channel, SNMP Traps, or e-mails.
Using Configware Insite, you can produce advanced statistic reports,
for example, top attacks, total attack traffic, attacks per IP address, and
more.
Radware Security Update Service on the Web

Radware's Security Update Service delivers immediate and ongoing
security filter updates, protecting against the latest security exploits
including viruses, worms and malicious attack signatures to safeguard
your applications, network and users.
Radware Security Update Service is available on a one-year or multi-
year subscription basis for all CID and APSolute OS Security
customers.
9-4 CID User Guide

Note: For up-to-date security information, see the Radware Security

Zone on the Radware website: http://www.radware.com/content/
support/securityzone/serviceinfo/default.asp
CID User Guide 9-5

Security Overview
Security Modules
CID Security comprises the following modules:
• Intrusions
• DoS/DDoS
• SYN Floods
• Anomalies
• Anti-Scanning
Intrusions
Intrusion prevention is a security technology that attempts to identify
potential intrusions into computer systems and prevent their damage
by blocking attacks.
Application level attacks are aimed at mission critical applications.
These attacks threaten application integrity and bring networks and
applications down. Most attacks target web applications, and therefore
cannot be blocked by access control devices.
The CID Intrusions module provides protection against application
specific attacks, which are targeted to damage various network
resources and disable the attacked system. These attacks include the
following categories:
• Web Server attacks aiming to damage or exploit web servers.
• E-mail attacks, for example, sending worms via E-mail.
• Attacks on services, such as FTP or RPC.
DoS/DDoS
When hackers send mass volumes of traffic, they overload networks or
servers, thus causing denied access for real users. This is known as
Denial of Service (DoS) or Distributed Denial of Service (DDoS)
attacks. DoS Shield samples traffic flowing through the device and
limits the bandwidth of traffic that was recognized as DoS attack using
predefined action.
9-6 CID User Guide

The Denial of Service (DoS) attacks are intended to compromise the

availability of a computing resource. Usually DoS attacks include ICMP
floods, UDP floods and TCP-SYN floods that consume network
bandwidth and prevent normal transport of the legitimate traffic.
DoS Shield, describes the process of protection against Denial of
Service attacks provided by the CID DoS Shield module. This module
provides protection against flooding of UDP, TCP and ICMP.
Radware's security scheme, implemented by the DoS Shield module
which is part of the APSolute OS architecture, provides organizations
with extensive Denial of Service (DoS) detection and protection
capabilities while maintaining high network throughput.
CID DoS protection module provides real time DoS protection through
the use of an advanced sampling mechanism. This mechanism
compares sampled traffic with a list of attacks signatures (attacks in
Dormant state), which are part of the CID attack database. The attacks’
signatures are looking for known flood tools by recognizing unique bit
patterns within the sample traffic. Once the activation threshold of an
attack in the Dormant state is met, its status changes to Currently
Active, which means that each and every packet is matched with the
signature file of this Currently Active attack. If a match is found, the
packet is dropped. In case there is no match the packet is forwarded to
the network.
This unique mechanism facilitates DoS and DDoS protection for high
capacity networks.
SYN Floods
A SYN flood attack is a denial of service attack where the attacker
sends a huge amount of please-start-a-connection packets and no
follow up packets.
CID provides protection against any type of SYN flood attack,
irrespective of the tools that are used to launch the attack. This
protection service utilizes a mechanism called SYN Cookies that
performs delayed binding (terminates TCP sessions) and inserts a
certain signature into the TCP sequence field.
CID User Guide 9-7

Security Overview
SYN Flood Protection is a service intended to protect the hosts located

behind the device and the device itself from SYN flood attacks by
performing delayed binding.
The SYN Flood attack is performed by sending a SYN packet without
completing the TCP three-way handshake. Another type of SYN Flood
attack is done by completing the TCP three-way handshake, but no
data packets are sent afterwords. Radware provides complete
protection against both types of SYN Flood attacks.
After the completion of the three-way handshake, CID only processes
requests that include the signature that was inserted previously. This
mechanism guarantees that only legitimate requests are sent to the
servers, while half open TCP connections, aimed to consume servers’
resources, are terminated by the CID and do not flood the servers, as
well as the CID itself.
The attacks are detected and blocked by means of SYN Flood
Protection Policies. The reports regarding the current attacks appear in
the Active Triggers table.
Anomalies
To avoid detection, hackers may use evasion techniques, such as
splitting packets and sending attacks in fragments. An attack that
contains fragmented packets is called Protocol Anomaly attack. The
Protocol Anomaly attacks are detected and blocked using the Protocol
Anomaly Protection mechanism.
The Anomalies module provides protection using two sub-groups:
• Protocol Anomaly Protection
• HTTP Anomaly Protection
Protection against Protocol Anomaly attacks is achieved by dropping
the malicious packets.
9-8 CID User Guide

Anti-Scanning
Prior to launching an attack, a hacker normally tries to identify which
TCP and UDP ports are open. An open port represents a service,
application, or backdoor. Ports that are unintentionally left open can
create a serious security problem.
The Anti-Scanning module provides a mechanism aimed at preventing
hackers from gaining this information by blocking and altering server
replies sent to the hacker.
This module provides protection against network and port scanning by
protecting against known scanning tools and scanning tools awaiting
the positive reply (SYN-ACK for TCP or UDP reply). The filters in this
group block all traffic returned from the scanned server.
CID User Guide 9-9

Security Overview
Setting Up Security Policies in the Connect and Protect

Table
Radware Security works with protection policies that are defined in the
Connect and Protect Table. Each row in the Connect and Protect Table
represents a policy.
A security policy contains security profiles that are activated within
predefined ranges of ports/VLANs or within a predefined network. First,
you create a security policy and assign protection profiles to the policy.
You may add protection profiles to the policy from any or all of the
security modules.
Security profiles aggregate attack groups and attacks. You can set one
or more profiles for each security module and associate the protection
profile with a policy.
Figure 9-1 shows the Connect and Protect Table. You can define the
Action mode for each policy, which is a definition of the actions that CID
performs when an attack is recognized.
Figure 9-1 Connect and Protect Table
Configuring a security policy may be divided into three stages: enabling

security, connecting, and protecting.
9-10 CID User Guide

Security Policies Configuration Guidelines:

1. From the main APSolute Insite window, open the APSolute OS
menu and select Security. The Connect & Protect Table window
appears.
2. Enable security by configuring the security modules and defining
the general security parameters (see page 9-12).
3. Configure connectivity by defining either port groups/VLANs or IP
address ranges per row in the Connect and Protect Table (see
page 9-19).
4. Define the Protection according to the protection module. For
each connectivity row, you can set security services according to
the module breakdown:
• Set up the Intrusion module parameters, see page 9-47
• Set the DoS/DDoS module parameters, see page 9-72
• Set up the SYN Flood module parameters, see page 9-123
• Set up the Anomaly module parameters, see page 9-142
• Set up the Anti-Scanning module parameters, see page 9-156
5. Define the Action parameter for this policy in case an attack is
detected:
Block: The packet is identified as an attack.
The action taken to prevent the
attack is the one that was defined in
the Block Action parameter of each
security module.
Forward: The packet is forwarded to the
defined destination.
Mixed: When you change the Action
parameter of a security module using
Web Based Management, the Action
mode may appear as Mixed.
Note: The Action mode settings do not apply to SYN Protection
(see page 9-123), as the delayed binding mechanism with
embedded SYN Cookies cannot be bypassed.
CID User Guide 9-11

Security Overview
Enabling Protection and Setting Up General Security

Parameters
The Radware security solution takes a multi-layer approach to security
that combines several mechanisms for attack detection with advanced
security modules, including Intrusions, DoS/DDoS, Anomalies, SYN
Flood Protection, and Anti-Scanning. The security modules are
configured in the Connect and Protect Table, and the mechanisms for
attack detection are configured in the Security Settings window (Figure 9-
2).
Figure 9-2 Security Settings Window
You can set the following general security settings in the Security
Parameters window:
• Application Security
• DoS Shield
• Protocol Anomaly Protection
9-12 CID User Guide

Application Security Parameters

Application Security is a mechanism that provides advanced attack
detection and prevention capabilities, checking the traffic on a packet-
by-packet basis. This mechanism is used by the following security
modules to provide maximum protection for network elements, hosts,
and applications: Intrusions, Anomalies, Anti-Scanning, and
Application Security for DoS/DDoS.
Note: Before using Intrusions, DoS/DDoS, Anomalies, and Anti-
Scanning, you must enable the Application Security mechanism and
set its parameters.
To start Application Security protection:

1. To open the Security Settings window:
a. From the main APSolute Insite window, open the APSolute OS
menu and select Security. The Connect & Protect Table
window appears.
b. In the top right-hand corner of the Connect & Protect Table
window, click the Settings button. The Security Settings
window appears.
Or:
a. From the main APSolute Insite window, right-click the CID icon
and select SetUp. The SetUp window appears.
b. In the SetUp window, click the Global tab. The Global pane
appears.
c. In the Global pane, select Security Settings and click Edit
Settings. The Security Settings window appears.
d. The Modules pane contains the following parameters:
Start Protection Select Enable to start protection.
Default: Enable.
Encoding
The language encoding (the language
and character set) to use for detecting
security events.
Attacks DB Version The version number of the current
attack loaded on the device.
CID User Guide 9-13

Security Overview
Session-Drop
Mechanism Status When enabled, terminates the whole
session when a single malicious
packet is recognized.
Minimum Risk Level The device will scan traffic only for
attacks with a risk level equal or higher
than the value of this parameter. This
parameter is valid only for signature-
based attacks (Application Security
and DoS Shield).
• High
• Medium
• Low
• Info - An IPS attack for which the
Risk parameter is set to Info is an
IDS signature.
2. Select the Start Protection checkbox.
3. To terminate the whole session if a single malicious packet is
recognized, check Session-Drop Mechanism Status.
4. Click Ok. You will be prompted to reboot the device.
5. Click Ok to reboot CID. You can start using the Intrusions, DoS/
DDoS, Anomalies, and Anti-Scanning security modules.
DoS Shield Parameters

The DoS Shield mechanism implements the sampling algorithm and
accommodates traffic flooding targeted to create denial of network
services. This mechanism is included in the DoS/DDoS security
module.
Note: Prior to configuring the DoS/DDoS security module, you must
enable DoS Shield and set its general parameters.
To enable DoS Shield and set its general parameters:

9-14 CID User Guide


window appears.
window appears.
Or:
appears.
2. In the Modules pane of Security Settings window, check Start DoS
Shield Protection.
3. Click Ok. You will be prompted to reboot the device.
4. Click Ok to reboot CID.
5. Reopen the Security Settings window (as explained in step 1).
6. In the Modules pane of the Security Settings window, set the
Packet Sampling Rate: The rate at which packets are sampled
and compared to the Dormant Attacks.
You can configure the number of
packets for which sampling is
performed.
The default value is 101, meaning 1
out of 101 packets is checked.
CID User Guide 9-15

Security Overview
Sampling Time Defines how often DoS Shield

(seconds): compares the predefined thresholds
for each Dormant Attack to the current
value of counters of packets matching
the attack. The default value is 5
seconds.
Note: If the Sampling Time is very
short, meaning that there are frequent
comparisons of counters to thresholds,
regular traffic bursts might trigger
attacks. If the Sampling Time is too
long, it is impossible to detect attacks
in a timely manner.
7. Click Ok. You can start using the DoS/DDoS security module.
Behavioral DoS
The B-DoS security policy contains security profiles that are activated
within predefined ranges of ports/VLANs, or within a predefined
network.
Note: Prior to configuring the Behavioral DoS shield module you
must enable it .
To enable Behavioral DoS:

1. In the main window, click Security. The Connect and Protect Table
appears.
2. In the Connect and Protect Table, double click on Settings. OR
from the main window double-click the device icon and then select
Global > Security Settings > Edit Settings. The Security
Settings window appears.
3. From the Security Settings window, in the Behavioral DoS field,
enable Start Protection.
4. Restart the device. Behavioral DoS is now enabled.
9-16 CID User Guide

Protocol Anomaly Protection Parameters

The Protocol Anomaly Protection parameters are the general
parameters of the Anomalies security module.
Note: Before using Anomalies, you must enable the Application
Security mechanism and set its parameters (see page 9-13).
To set Protocol Anomaly Protection parameters:

window appears.
window appears.
Or:
appears.
2. In the Modules pane of the Security Settings, set the following
Max URI Length: The maximum URI length permitted.
If the URI is longer than the
configured value, it is considered
illegitimate and is dropped. The
default value is 500 characters.
Min Fragment Size: The minimum size of a fragmented
IP packet permitted. A shorter packet
length is treated as an IP protocol
anomaly and is dropped. The default
value is 512 Bytes.
CID User Guide 9-17

Security Overview
Min Fragmented URI The minimum permitted size of an

Packet Size: incomplete URI in an HTTP request.
A shorter packet length is treated as
a URI protocol anomaly and is
dropped. The default value is 50
characters.
3. Click Ok. The Security Settings window closes.
9-18 CID User Guide

Defining Connectivity
When creating a security policy, you must initially define connectivity.
This is performed by defining either port groups/VLANs or IP address
ranges for each policy in the Connect & Protect Table.
Policies are represented by rows in the Connect & Protect Table. For
each row, you can set connectivity and security services according to
the module breakdown (Intrusions, DoS/DDoS, Anomalies, SYN Flood,
Anti-Scanning).
Configuring Port Groups

Port groups allow you to define which ports are to be scanned.
To create a new port group:

1. From the main APSolute Insite window, right-click the CID device
icon and select APSolute OS > Security. The Connect & Protect
2. In the Connect and Protect Table window, double-click inside the
Port/VLAN column. The Settings pane appears.
3. In the Settings pane, click Add Port Group. The Edit Physical
Port Group window appears.
4. In the Group box, enter a name for the new group.
5. Check the ports to be associated with the new group.
6. Click Ok. The new port group is created.
To add ports to an existing Port Groups:

2. In the Connect & Protect Table window, double-click inside the
Port/VLAN column. The Settings pane appears.
3. In the Settings pane, select the port group name from the Port
Group drop-down list.
4. Click Port Group Table. The Port Groups window appears.
CID User Guide 9-19

Security Overview
5. Click the Modify Table tab. The Modify Table pane appears.
6. Select the table entry for the group that you would like to modify.
7. Click Edit. The Edit Physical Port Group window appears.
8. Check the ports that you would like to add to the group.
9. Click Ok. The port group is updated.
Configuring VLANs
You can define which VLANs are to be scanned.
To define which VLANs are to be scanned:

2. In the Connect and Protect Table, double-click inside the Port/
VLAN column. The Settings pane appears.
3. In the Settings pane, click Add VLAN Tag Group. The Edit VLAN
Tag Group window appears.
4. In the Edit VLAN Tag Groups window, set the following
Group Name A user-defined name for the VLAN group.
Group Mode The VLAN mode may be one of the
following:
• discrete: An individual VLAN tag, as
defined in the interface parameters of
the device.
• range: A group of sequential VLAN tag
numbers, as defined in the interface
parameters of the device.
VLAN Tag The VLAN tag number. Set VLAN Tag if
Group Mode is set to discrete.
VLAN Tag From The first VLAN tag in the range. Set VLAN
Tag From if Group Mode is set to range.
9-20 CID User Guide

VLAN Tag To: The last VLAN tag in the range. Set VLAN
Tag To if Group Mode is set to range.
5. Click Ok. The Edit VLAN Tag Groups window closes.
Configuring Networks
You can set the network IP address range that is to be scanned.
To configure a new network:

Networks column. The Settings pane appears.
3. In the Settings pane, click Add Network. The Edit Network Table
window appears.
4. In the Edit Network Table window, set the following parameters
Network Name: A user-defined name for the network.
Network Mode: The network mode may be one of the
following:
• IP Mask
• IP Range
From Address: The first address in the range.
To Address: The last address in the range.
5. Click Ok. Your preferences are recorded.
To define a network from the predefined list:

Networks column. The Settings pane appears.
CID User Guide 9-21

Security Overview
3. In the Settings pane, set the following parameters according to the

From: The first address in the range.
To: The last address in the range.
Check Packets: The profile inspection direction,
which may be oneway or two-way.
4. Click Apply. Your preferences are recorded.
9-22 CID User Guide

Suspend Table
The Suspend Table allows you in addition to defining the action to be
taken for attacks also to set the device to suspend traffic from the IP
address that was the source of the attack for a defined period of time.
The Suspend Action is available as an option for the attack types:
• Intrusions
• Anomalies
• Anti-Scanning
• DoS/DDoS
To view the Suspend Table:

1. From the main window, select APSolute OS > Suspend Table.
The Suspend Table window appears.
2. In the Suspend Table window, the following parameters are
displayed:
Minimal Aging The length of time the source IPs are
Timeout suspended.
Maximal Aging The maximum length of time a source
Timeout IP can be suspended.
Maximum Entries with The maximum amount of entries
Same Source IP allowed from the source IP.
To configure suspend action for an attack:

1. From the main window, select APSolute OS > Security. The
Connect & Protect Table window appears.
2. In the Connect and Protect Table, click on an Intrusions box. The
Settings pane appears.
3. In the All Intrusions Attacks list select an Attack and click Edit.
The Attack Configuration window appears.
CID User Guide 9-23

Security Overview
4. In the Attack Configuration window select the Suspend Action

dropdown list, which contains the following options:
None: Suspend action is disabled for this
attack.
SrcIP: All traffic from the IP address identified
as source of this attack will be
suspended.
SrcIP, DestIP: Traffic from the IP address identified as
source of this attack to the destination
IP under attack will be suspended
SrcIP, DestPort: Traffic from the IP address identified as
source of this attack to the application
(destination port) under attack will be
suspended.
SrcIP, DestIP, Traffic from the IP address identified as
DestPort: source of this attack to the destination
IP and port under attack will be
suspended
SrcIP, DestIP, SrcPort, Traffic from the IP address and port
DestPort: identified as source of this attack to the
destination IP and port under attack
will be suspended
9-24 CID User Guide

Section 9-2 Managing the Signatures Database

Section 9-2, Managing the Signatures Database, explains the
signature database feature and how to configure it.
• Protection Profiles and Groups Supplied by Radware, page 9-26
• Security Signatures File Update, page 9-36
CID User Guide 9-25

Managing the Signatures Database
Protection Profiles and Groups Supplied by Radware

Radware provides you with the Signatures database that contains
signatures of the predefined attacks. These attacks are included in the
predefined groups and profiles that are also supplied by Radware.
Using the predefined groups and profiles, you can easily create new
protection policies in the Connect and Protect Table.
Each attack group includes a number of attack signatures that are
grouped together according to their common characteristics. The
groups are included in the protection profiles that are applied to the
protection policies in the Connect and Protect Table. Protection profiles
can contain various groups or attacks, providing maximum protection
for specific types of networks.
Table 9-1 presents profiles supplied by Radware.
Table 9-1 Radware Supplied Protection Profiles
Profile Description
Corporate Gateway This profile is designed to protect the

corporate network gateway. The specific aim
is to block all possible intrusions that pass
through the firewall, intrusions that affect the
firewall, attacks that affect network stability,
and attacks that aid intruders in collecting
information.
Corporate DMZ This profile is designed to protect the

corporate DMZ network. The specific aim is to
protect the generic network services provided
to the Internet and to the local area network.
Corporate DMZ Mail This profile is designed to protect the

corporate DMZ network mail servers.
Corporate DMZ Web This profile is designed to protect the

corporate DMZ network web servers. The
specific aim is to protect against web server
and web application vulnerabilities.
9-26 CID User Guide

Table 9-1 Radware Supplied Protection Profiles
Profile Description
Corporate LAN This profile is designed to protect the

corporate LAN network. The specific aim is to
protect against spreading worms among the
clients of a local area network and to protect
against the vulnerabilities that could affect
workstations in such a network.
Carrier / POP This profile is designed to protect carrier

networks, backbone networks, and ISP dial-in
networks. The specific aim is to protect only
against the really malicious attacks that affect
the Internet in general and to reduce the
interruption of Internet freedom provided to
Internet users.
University LAN This profile is designed to protect the LAN in

university-type networks. In this type of
network, the workstations are not very
trustworthy. Therefore, attacks are likely to
originate from the workstations in the local
area network. Filter groups are defined to
inspect the traffic in any direction and to
prevent the information gathering that can be
the basis for the intrusion itself.
Table 9-2 provides descriptions of the Radware attack groups.
Table 9-2 Radware Supplied Attack Groups
Attack Group Description
Top-N The "Top-N" group contains signatures of

attacks that have the highest activity in the
wild. This group is updated whenever
Radware's SOC finds it necessary. The
signature subset in "Top-N" can be compiled
of various services and can later be moved to
(or from) an appropriate group.
CID User Guide 9-27

Table 9-2 Radware Supplied Attack Groups (cont.)
Worms The "Worms" group contains signatures of

attacks classified as Internet worms. The
types of worms in this group include: mass-
mailing worms, vulnerability exploiting worms,
and network-aware worms. Signatures in the
"Worms" group stop the propagation of the
worms listed in the group.
IIS The "IIS" group contains signatures of attacks

that exploit the vulnerabilities found in the
Microsoft IIS Web Service. Signatures in this
group protect against HTTP implementation
attacks, default web page attacks, ISAPI
extension attacks, and SSL attacks.
Apache The "HTTP-Apache" group contains

signatures of attacks that exploit the
vulnerabilities found in Apache HTTP and
other modules. Signatures in this group
protect against HTTP implementation attacks,
default server attacks, and vulnerabilities
found in Apache modules.
HTTP-MISC The "HTTP-MISC" group contains signatures

of attacks that exploit vulnerabilities found in
miscellaneous web services. Signatures in
this group protect against HTTP
implementation attacks, exploitation of various
web applications, and information disclosure
attacks.
Web The "Web" group contains signatures of

attacks that perform command injection into
web services. Signatures in this group prevent
the command's injection into web
applications. Command injection allows
command execution on the affected host with
the privileges of the web server.
9-28 CID User Guide

CGI The "CGI" group contains signatures of

attacks that exploit CGI vulnerabilities in web
applications. Signatures in this group prevent
the exploitation of vulnerabilities found in CGI
scripts that could allow an attacker to
compromise the affected host.
XSS The "XSS" group contains signatures of

attacks that perform cross-site scripting in
web applications. In cross-site scripting, a
script is injected into a dynamic HTML page.
When viewed by other users, the page is
redirected to malicious sites, using the users'
local environment credentials without them
being aware of it. Signatures in this group
prevent the cross-site scripting on the affected
host that can lead to information theft and web
session hijacking.
SQLInjection The "SQLInjection" group contains signatures

of attacks that perform SQL database
modifications. Signatures in this group
prevent the SQL queries' injection via web
applications. A successful SQL query injection
may lead to information disclosure, data
modification, and data corruption.
ColdFusion The "ColdFusion" group contains signatures

of attacks that exploit vulnerabilities in the
ColdFusion web service. Signatures in this
group prevent the exploitation of
vulnerabilities found in ColdFusion web
service, which may compromise the affected
host.
CID User Guide 9-29

FrontPage The "FrontPage" group contains signatures of

attacks that exploit vulnerabilities in the
FrontPage Web Service. Signatures in this
group prevent the successful exploitation of
vulnerabilities found in FrontPage web
service, which may compromise the affected
host.
SMTP_AS The "SMTP_AS" group contains signatures of

attacks that exploit vulnerabilities in
miscellaneous SMTP servers. Signatures in
this group prevent the exploitation of
vulnerabilities found in SMTP implementation
from miscellaneous vendors and prevent the
propagation of Internet worms.
Telnet_AS The "Telnet_AS" group contains signatures of

miscellaneous Telnet servers. Signatures in
vulnerabilities found in Telnet implementations
from miscellaneous vendors.
FTP_AS The "FTP_AS" group contains signatures of

miscellaneous FTP servers. Signatures in this
vulnerabilities found in FTP implementations
SQL_AS The "SQL_AS" group contains signatures of

miscellaneous SQL servers. Signatures in this
vulnerabilities found in SQL implementations
9-30 CID User Guide

NetBIOS The "NetBIOS" group contains signatures of

attacks that exploit vulnerabilities in NetBIOS
service. Signatures in this group prevent the
exploitation of vulnerabilities found in
NetBIOS implementations.
DNS_AS The "DNS_AS" group contains signatures of

miscellaneous DNS servers. Signatures in
vulnerabilities found in DNS implementations
POP3_AS The "POP3_AS" group contains signatures of

miscellaneous POP3 servers. Signatures in
vulnerabilities found in POP3 implementations
IMAP_AS The "IMAP_AS" group contains signatures of

miscellaneous IMAP servers. Signatures in
vulnerabilities found in IMAP implementations
RPC-Unix The "RPC-Unix" group contains signatures of

attacks that exploit vulnerabilities in the Sun
RPC service. Signatures in this group prevent
the exploitation of vulnerabilities found in Sun
RPC implementations from miscellaneous
vendors.
ICMP_AS The "ICMP_AS" group contains signatures of

attacks that exploit vulnerabilities in ICMP
services. Signatures in this group prevent the
exploitation of vulnerabilities found in ICMP
implementations from miscellaneous vendors.
CID User Guide 9-31

Finger The "Finger" group contains signatures of

attacks that exploit vulnerabilities in Finger
exploitation of vulnerabilities found in Finger
implementations from miscellaneous vendors
and prevent information gathering attempts.
Buffer_Overflow The "Buffer_Overflow" group contains

signatures of attacks that exploit various
services by overflowing the declared buffer.
Signatures in this group prevent attempted
buffer overflow exploitation in those services
that do not fit the other service groups.
Exploitation of vulnerabilities found in those
services compromise the affected host.
SNMP_AS The "SNMP_AS" group contains signatures of

attacks that exploit vulnerabilities or bad
configuration in SNMP service. Signatures in
this group prevent access to SNMP services
with public community strings and protect
from exploitation of vulnerabilities found in
SNMP implementations.
Brute-Force The "Brute-Force" group contains signatures

of password brute force attacks in
miscellaneous services. Signatures in this
group prevent the password-guessing attacks
(brute force) in miscellaneous services.
DoS The "DoS" group contains signatures of

denial-of-service attacks on miscellaneous
services and protocol implementations.
Signatures in this group prevent the DoS
attacks against miscellaneous services and
protocols.
9-32 CID User Guide

Backdoors_Inbound The "Backdoors_ Inbound" group contains

signatures of backdoor communication that
enters the infected host. Signatures in this
group prevent inbound backdoor
communication and prevent the backdoor
from being controlled remotely.
Backdoors_Out- The "Backdoors_ Outbound" group contains

bound signatures of backdoor communication that
exits the infected host. Signatures in this
group prevent outbound backdoor
communication and prevent the backdoor
from being controlled remotely.
Protocol_Anomalies The "Protocol_Anomalies" group contains

signatures of miscellaneous protocol
misbehaviors. Signatures in this group
prevent the usage of miscellaneous protocol
anomalies that could indicate a new
exploitation of protocol vulnerability or a DoS
attack.
Archive The "Archive" group contains signatures of

miscellaneous outdated attacks. Signatures in
this group prevent the outdated attacks that
are no longer valid. The group may include
various types of attacks and attacks from
miscellaneous groups.
SIP The “SIP” group contains filters for protection

against SIP threats. SIP (Simple Initiation
Protocol) is a protocol used to stream live
video and audio data, for example, VoIP. The
filters in this group protect SIP-based
application vulnerabilities, as well as
vulnerabilities and generic protections of the
SIP protocol itself.
CID User Guide 9-33

Oracle The “Oracle” group contains filters for

protection against Oracle server related
threats. Oracle is a common database server
software. Threats against Oracle servers can
cause data manipulation, data loss, theft of
sensitive of data, and other serious
consequences. The filters that are found in
this group protect against known DCE-RPC
threats.
NetBIOS The "NetBIOS" group contains signatures of

attacks that exploit vulnerabilities in NetBIOS
exploitation of vulnerabilities found in
NetBIOS implementations.
Command Execution The “Command Execution” group contains

filters for various vulnerabilities that allow a
remote attacker to execute commands on a
target system. By executing these commands
with higher than normal permissions, the
attacker can disrupt network services, modify
important files, and completely compromise
the target system. The vulnerabilities that
allow command execution cover various
services and operating systems, and
generally constitute an extremely high risk to
system and network integrity.
Routers The “Router” group contains filters to protect

against known vulnerabilities in network
routing devices. The vulnerabilities can allow
a remote attacker to disrupt network services
and create a denial of service condition. In
some cases, successful exploitation may give
an attacker access to sensitive parts of the
network by modifying security settings or
changing routing rules.
9-34 CID User Guide

MS-RPC The “MS-RPC” group contains filters for

protection against threats traveling over
Microsoft’s DCE-RPC protocol. DCE-RPC is a
common Internet protocol, which can be
exploited in different ways, thereby causing
various types of damage. The filters in this
group protect against known DCE-RPC
threats.
Note: Groups can change according to the Signatures File version.
CID User Guide 9-35

Security Signatures File Update

For constant updates of the signatures database, CID Security uses
the Signatures File Update feature. All devices are updated using the
latest signatures file, which is a database that contains a list of updated
attacks.
To guarantee maximum protection for your network, you must update
the signatures file per device.
During the update process, APSolute Insite connects to the Radware
website to check if you can get the file for the specified device.
Note: To get the Security Update Service, you must purchase it
separately.
An updated signatures file can be found every Monday on the Radware
Security Zone (http://www.radware.com/content/security/attack/
weeklyupdates.asp). In addition to weekly updates, the website is
updated on an ongoing basis and an emergency update can be
performed, when required.
Updating the Signatures file can be performed in the following ways:
• Manual updating: If you have an updated file that was downloaded
manually from the Radware website, you can upload the signatures
file to CID manually.
• Manual downloading and updating: You can download the
update file from the Radware website and perform the manual
update using this file.
• Automatic downloading and updating: You can schedule
automatic downloads and updates of the signatures file.
Tip: To provide the best protection for your network, it is recommended
to set automatic daily updates.
Manual Update
If you have an updated file that was downloaded manually from the
Radware website, you can upload the signatures file to CID manually.
9-36 CID User Guide

To update the signatures file manually:

menu and select Security Updates > Upload Attacks File. The
Upload Attacks window appears, displaying a list of devices that
have a Service Agreement.
2. In the Upload Attacks table, check the devices to which you want
to send the signatures database update.
Note: You must choose only the devices that have an Application
Security Signature File Update Service Agreement with Radware
Support.
3. Click Browse and navigate to the signature file that you
downloaded from the Radware Security Zone (http://
www.radware.com/content/security/attack/weeklyupdates.asp).
4. Click Send Attacks File To Selected Devices. An upload
progress bar and progress message are displayed for each
selected device.
5. Click Ok. The selected devices are updated.
Downloading and Updating

You can download the update file from the Radware website and
upload the file to CID.
CID User Guide 9-37

To download a signature file update from the Radware website

and upload it to your CID:
menu and select Security Updates > Upload Attacks File. The
Upload Attacks window appears, displaying a list of devices that
have a Service Agreement.
2. In the Upload Attacks table, check the device for which you want
to update the signatures file.
3. Click Check Now to check if a signature update file is available on
the Radware website. If the file is available, you will be prompted
to download it.
downloaded.
5. Click Send Attacks File To Selected Devices. An upload
selected device.
Scheduled Downloading and Updating

You can schedule automatic signature file downloads. Once the
upgrade files are downloaded, you can update the signatures file. You
can edit or remove the signatures file update settings from the
Scheduler window. To access the Scheduler window, open APSolute
Insite’s Tools menu and select Scheduler.
In addition, you can send an email notification as part of the Automatic
Signature File Update procedure. The email notification mechanism
automatically sends an email in the following cases:
• The Signatures file has been downloaded to the APSolute Insite
station.
• The Signatures file has been downloaded to the APSolute Insite
station and installed on the device.
A single email is sent per device informing the System Administrator of
the action performed by APSolute Insite.
9-38 CID User Guide

To schedule automatic signature file downloads and updates:

menu and select Security Updates > Attacks Update Settings.
The Edit Task window appears.
2. In the Time Settings area, specify the Start Hour.
Note: The End Hour option must not be enabled for this task.
3. In the Frequency Settings area, select the Daily, Weekly, or

Minutes.
4. If you selected Weekly, check the day on which the update is to be
performed.
5. If you selected Minutes, type the number of minutes in the
Minutes text box.
6. Click Next. A second Edit Task window appears, displaying a
table of all devices in the network site.
CID User Guide 9-39

7. For each device, select the attacks update procedure according to

Download and Install: The Application Security Signature
file is automatically downloaded and
installed on the device according to
the predefined schedule.
Download: The Application Security Signature
file is automatically downloaded
according to the predefined
schedule. You need to install the file
in order to use it.
Ignore: No files are automatically
downloaded for this device.
Note: Select only devices that have an Application Security
Signature File Update Service Agreement with Radware Support.
8. To receive email notifications about the attack update procedures:
a. Check Signature File Update Email Notification.
b. Click Email Recipients. The Email Recipients window
appears.
c. For each email notification recipient, enter the email address in
the Recipients Email field and click Add. Click Ok to return to
the Edit Task window.
d. If APSolute Insite is installed behind the proxy in your network,
select Behind the Proxy, and set the IP address and port of
the proxy server.
e. Click Finish. The Edit Task window closes. The task appears
in the Scheduler window (Tools > Scheduler).
f. From the main menu, open the Options menu and select
Preferences. The Management Preferences window appears.
g. In the Management Preferences window, click the Traps and
SMTP tab. The Traps and SMTP pane appears.
h. In the Traps and SMTP pane, set the following parameters
User Email Enter the mail address of the APSolute Insite
Address: station.
9-40 CID User Guide

SMTP Server Enter the address of the SMTP server to which

Address: the APSolute Insite station sends the notification
emails.
Traps Check this box to allow logging of SNMP traps in
Automatic a dedicated log file.
Save:
Traps Auto Enter the complete path and file name of the log
Save File: file.
The format of the email messages is as follows:
• When the Download and Install procedure is configured:
Email Attacks File Update Status
subject:
Email body: "Attacks Signature File downloaded
and installed for device: <Device
Type:Device IP:MAC Address>"
• When the Download procedure is configured:
Email Attacks File Update Status
subject:
Email body: "Attacks Signature File downloaded
for device: <Device Type:Device
IP:MAC Address>"
9. If you selected Download in step 7 above, from the main window
open the APSolute OS menu and select Security > Upload
Attacks File. The Upload Attacks window appears.
Or:
If you selected Download and Install in step 7 above, you are done.
Signature file updates will be downloaded and installed
automatically.
10. Select the Updates button. The Upload Attacks window appears,
displaying the list of devices that have Service Agreement.
CID User Guide 9-41

11. In the Upload Attacks table, check the devices to which you want
to send the signatures database update.
Note: Select only devices that have an Application Security
Signature File Update Service Agreement with Radware Support.
downloaded from the Radware Security Zone (http://
www.radware.com/content/security/attack/weeklyupdates.asp).
13. Click Send Attacks File to Selected Devices. An upload
selected device.
9-42 CID User Guide

Section 9-3 Intrusions

Section 10-3 explains how to protect against intrusions into your
network.
• Introduction to Intrusions, page 9-44
• Intrusion Prevention Profiles, page 9-46
• Setting Up Intrusion Prevention Using Profiles and Groups, page 9-
47
• Defining Intrusion Prevention with User-Defined Settings, page 9-
48
• Setting Up Attacks and Filters, page 9-49
• Custom Attack Groups, page 9-64
• Creating a New User-Defined Intrusion Prevention Profile, page 9-
66
CID User Guide 9-43

Intrusions
Introduction to Intrusions
The Intrusions Prevention module provides advanced intrusion
detection and prevention capabilities. The Intrusions module provides
maximum protection for network elements, hosts, and applications by
preventing various intrusion attempts including worms, Trojan horses,
buffer overflow, and other application oriented attacks.
Types of Attacks
Attack recognition is performed by comparing each packet to the set of
signatures stored in the Signatures database.
The attacks handled by the Intrusions module can be divided into the
following types:
• Network-Oriented Attacks
• Operating-System Oriented Attacks
• Application-Oriented Attacks
Network-Oriented Attacks
Network-based attacks use network layer packets, such as IP, TCP,
UDP, or ICMP packets to either learn about or damage a destination
host.
Examples include malformed packets that can cause a server to crash,
such as Ping of Death, or a ping packet in which the source address is
the same as the destination address, like in Land Attack.
Operating System Oriented Attacks

Operating System (OS)-oriented attacks are designed to break into the
server by exploiting vulnerabilities in the server’s operating system.
The target of the OS-oriented attack is usually to disable application
server functionality by damaging its flow or one of its resources. The
Application Security module protects against the following OS-oriented
attacks:
9-44 CID User Guide

• Simple server attacks attempt to exploit the known vulnerabilities of

a server's operating system, for example, by utilizing the
vulnerabilities of the default installations of known software
applications. Enabling the web-related protection policies in the
Intrusion Prevention module protects your web servers from such
attacks. For example, the Welchia worm uses TCP port 135 to
infect a host, exploiting vulnerabilities in the Microsoft Remote
Procedure Call (RPC) Interface, which is an MS Windows
vulnerability.
• Advanced attacks attempt to gain access via backdoors left open in
the system for the administrators' use or via Trojan horses, which
are hidden parts of the code, providing the attacker access to
restricted areas. Intrusion Prevention protects against these
attacks by enabling backdoor-related protection policies (for
example, Back Orifice).
• A Buffer Overflow occurs when a program or process tries to store
in a buffer (temporary data storage area) more data than it was
designed to hold. Buffers are designed to contain a finite amount of
data, and the extra information might overflow into adjacent buffers,
corrupting or overwriting the valid data held in them.
Application-Oriented Attacks
Application-oriented attacks are designed to break into application
servers. Such attacks can be recognized by searching for known
signatures of each application in the packets, for example, a specific
path or a particular command that appears in a packet.
Attacks of the application-oriented type attempt to exploit vulnerabilities
in the applications. Intrusion Prevention protects against these attacks
by enabling web-related protection policies.
For example:
• SQL Injection Attacks
• Cross-Site Scripting Attacks
CID User Guide 9-45

Intrusions
Intrusion Prevention Profiles

An Intrusion Prevention Profile is a mechanism that scans the traffic of
a particular network and physical port. The traffic classification is
performed within the predefined network range with preconfigured
traffic direction. All packets that pass through this range are examined
by means of various protectors called Attacks.
Intrusion prevention profiles are applied to attack groups. An attack
group uses attacks as building blocks. Attacks contain filters. Each filter
represents a signature for blocking a single attack. Intrusion prevention
profiles can only use attacks that are organized in attack groups. An
attack group represents a logical OR relation between its attacks.
Radware provides a comprehensive signatures database with attack
signatures divided into attack groups according to types of protection.
For example, all attack signatures designed to harm IIS web servers
are grouped under the IIS Attack Group.
An intrusion prevention profile is built over a single attack group and
defines the network conditions on which the attack is scanned. Each
intrusion prevention profile can be assigned to a policy. The policy
specifies network, physical inbound port parameters, and direction.
Radware provides a list of predefined protection profiles that are
designed to meet the requirements of various network conditions.
9-46 CID User Guide

Setting Up Intrusion Prevention Using Profiles and Groups

Radware supplies a set of predefined attack profiles and attack groups
that provide constant protection against all recent attacks (see
Protection Profiles and Groups Supplied by Radware, page 9-26). You
can use these prevention profiles to define protection policies.
Most of the existing intrusions can be prevented using Radware
profiles.
Intrusion Prevention Configuration Guidelines using Radware

Defined Profiles:
1. Enable the Intrusion Prevention security module and define the
general parameters (see page 9-12).
appears.
3. In the Connect & Protect Table, double-click inside the Intrusions
column. The Settings pane appears.
4. From the Intrusion Prevention Profiles list, select the predefined
intrusion prevention profiles and apply them to the policy in the
Connect & Protect Table.
CID User Guide 9-47

Intrusions
Defining Intrusion Prevention with User-Defined Settings

In addition to the Radware defined profiles and groups, you can create
custom prevention profiles, custom attack groups, and custom attacks
that are based on custom filters. For new users, it is recommended to
define intrusion prevention profiles using Radware-defined attack
groups only.
Intrusion Prevention Configuration Guidelines using User-

Defined Profiles:
1. Enable Intrusion Prevention and define the general parameters
(page 9-12).
2. Define custom attacks (see page 9-49).
3. Define custom attack groups (see page 9-64).
4. Define Intrusion prevention profile and apply it to the policy in the
Connect and Protect Table (see page 9-66).
9-48 CID User Guide

Setting Up Attacks and Filters

An attack (Figure 9-3) is a building block of the intrusion prevention
profile. Each attack contains one or more protection filters and a
mechanism that determines which packets are malicious and how CID
treats those packets.
Figure 9-3 Custom Attack Configuration
Each filter (Figure 9-4) contains one specific signature. Filters are
detectors that scan and classify the predefined traffic. The filter’s main
purpose is to match the specific packet within the traffic scanned by this
filter and the attack signature from the Radware Attack Signatures
database (see Managing the Signatures Database, page 9-25).
CID User Guide 9-49

Intrusions
Figure 9-4 Filter Configuration Window
An attack can employ one or more filters. When more than one filter is
used, the scanning process represents a logical AND relation between
the filters involved. This means that the classification mechanisms of all
filters applied to the same attack are involved in the scanning process,
or in other words, the traffic is checked for all the signatures defined in
the attack’s filters.
Note: For each custom attack, you must define custom filters. You
cannot use filters from other attacks when you define a custom attack.
An attack’s settings parameters define how the malicious packet is
tracked and treated once its signature is recognized. Each attack is
bound to a “Tracking” function that defines how the packet is handled
when it is matched with the signature. The main purpose of these
functions is to determine whether the packet is harmful and to take an
appropriate action. There are two types of match functions:
9-50 CID User Guide

• The “Immediate” type that makes decisions based on a single

packet. The signature’s match to the packet is considered an
indicator for the attack, and the packet is dropped (“Drop All”), for
example, MS Blast.
• The “Threshold” or “Counter” functions, which assume that the
signature match alone is not enough for detecting a packet as
offensive. This is because the packet may be legitimate unless the
number of packets over a period of time exceeds a threshold that
defines “reasonable” behavior for such traffic. Only packets that
exceed the threshold within a predefined time slot are dropped, for
example, ICMP flood attacks and DoS attacks.
Table 9-3 presents attack configuration parameters.
Table 9-3 Attack Configuration Parameters
Attack Name A user-defined name for this attack, maximum

30 characters.
Tracking Time Sets the amount of time (in milliseconds) in

which the Threshold is measured. When a
number of packets that is greater than the
Threshold value passes through the device,
during this defined time period, the device
recognizes it as an attack.
Default value: 1000
Threshold Sets the maximum number of attack packets

that are allowed in each Tracking Time unit.
The attack packets are recognized as
legitimate traffic when they are transmitted
within the Tracking Time period.
Default value: 10.
CID User Guide 9-51

Intrusions
Table 9-3 Attack Configuration Parameters (cont.)
Tracking Type Defines how the device decides which traffic

to block or drop, when under an attack of this
type. Values can be:
• Drop All: Once the first packet is
identified as harmful, the packet is
dropped. Select this option when each
packet of the defined attack is harmful.
For example: Code Red and Nimda
attacks.
• Sampling: A DoS shield attack.
• Source & Target Count: Sessions are
counted per source IP and destination IP
combination. Select this option when the
defined attack is destination-based, and is
not characterized by a single packet but
rather by repeated packets.
• Source Count: Sessions are counted per
source IP. Select this option when the
• Target Count: Sessions are counted per
destination IP. Select this option when the
Default: Drop All
9-52 CID User Guide

Action Mode When an attack is detected, one of the

following actions can be taken:
•Report Only: The packet is forwarded to the
•Drop: The packet is discarded.
•Reset Source: Sends a TCP-Reset packet
to the packet Source IP.
•Reset Destination: Sends a TCP-Reset
packet to the destination address.
•Reset Bi-directional: Sends a TCP-Reset
packet to both, the packet source IP and the
packet destination IP.
Default: Drop
Risk The severity of the damage that the attack can

cause to your system.
• High
• Medium
• Low
• Info - An IPS attack for which the Risk
parameter is set to Info is in fact an IDS
signature.
Default value: Medium
Direction This parameter sets the attacks inspection

direction. Inspection can be of incoming
traffic, outgoing traffic, or both.
CID User Guide 9-53

Intrusions
Suspend Action This parameter sets the action to take in

response to an attack:
attack.
as the source of the attack will be suspended.
SrcIP, DestIP: Traffic from the IP address
identified as the source of the attack to the
destination IP under attack will be suspended.
SrcIP, DestPort: Traffic from the IP address
application (destination port) under attack will
be suspended.
SrcIP, DestIP, DestPort: Traffic from the IP
address identified as the source of the attack
to the destination IP and port under attack will
be suspended.
SrcIP, DestIP, SrcPort, DestPort: Traffic from
the IP address and port identified as the
source of the attack to the destination IP and
port under attack will be suspended
Drop Threshold The number of packets matching the attack

(Kbps) that can be forwarded in each second when
the attack is Active.
A value of Drop All (or 0) means that all
packets must be blocked. Any value other
than Drop All is used for attacks that match a
pattern of legitimate traffic, for example, UDP
Flood attacks.
9-54 CID User Guide

Termination If, for the duration of the Attack Aging Period,

Threshold (Kbps) this threshold is not exceeded, a notification
message is sent indicating that the attack may
be over. Typically, this threshold is higher than
the Termination Alert Threshold and lower
than the Activation Threshold. You can also
select "Do Not Alert" (or 0).
State Select Enable to activate the policy.

Default: Enable.
Filters A list of user-defined filters (see page 9-81).
To create a new attack:

Intrusions column. The Settings pane appears.
3. In the Settings pane, click Custom Attack. The Attack
4. In the Attack Name text box, enter the name of the new attack.
5. Set the attack parameters, as explained in Table 9-3 on page 51.
6. Click Add New. The Filter Configuration window appears.
7. In the Filter Name text box, enter the name of the filter.
8. Set the protocol parameters, as explained in Table 9-5 on
page 56.
9. Set the OMPC parameters. as explained in Table 9-6 on page 58.
10. Define the content parameters, as explained in Table 9-7 on
page 59.
11. In the Filter Description text box, enter a description of the filter.
12. Click Ok three times to return to the main window.
CID User Guide 9-55

Intrusions
Filter Parameters
The parameters of each filter are divided into the following categories:
• Description Parameters
• Protocol Definition Parameters
• OMPC (Bit pattern) Definition Parameters
• Content Definition Parameters
Description Parameters
Description parameters (Table 9-4) are the user-defined descriptions of
the custom attack.
Table 9-4 Description Parameters
Attack Name The name of the attack as you define it.
Description A description of the attack.
Protocol Definition Parameters

Protocol definition parameters (Table 9-5) define transmission protocol.
Table 9-5 Protocol Parameters
Protocol The protocol used: IP, UDP, TCP, or ICMP.

Default value: IP.
Application Port The group of Layer 4 ports for UDP and TCP
Groups traffic only. Each group is identified by its
unique name. Each group name can be
associated with a number of entries in the
Application Port Groups table.
The values can be: 0 - 65535.
9-56 CID User Guide

Table 9-5 Protocol Parameters (cont.)
Destination Port Intended for UDP and TCP traffic only.

Group
Select from the list of groups configured in the
Source Port Group Intended for UDP and TCP traffic only.
Select from the list of groups configured in the
To define a new application port group:

1. In the Filter Configuration window, click App. Port Group. The
Application Port Groups window appears.
2. In the Application Port Groups window, click Modify. The Modify
pane appears.
3. In the Modify pane, click Add and set the following parameters
Name: A user-defined group name.
From Port: Define the first port in the range.
To Port: Define the last port in the range.
Notes:
• To define a group with a single port, set the same value for the
From Port and To Port parameters.
• To associate a number of ranges with the same port group, use the
same group name for all the ranges that you want to include in one
group.
4. Click Ok. A new row appears in the Application Port Groups table.
OMPC (Bit pattern) Definition Parameters

Offset Mask Pattern Condition (OMPC) parameters are a set of attack
parameters that define a rule for pattern lookups. The OMPC rule looks
for a fixed size pattern of up to four bytes that uses fixed offset
masking. This is useful only for attack recognition where the attack
CID User Guide 9-57

Intrusions
signature is a TCP/IP header field or a pattern in the data/payload in a

fixed offset. The OMPC parameters are presented in Table 9-6.
Table 9-6 OMPC Definition Parameters
OMPC Length The length of the OMPC data can be N/A,

OneByte, TwoBytes, ThreeBytes, or
FourBytes.
Default value: N/A.
OMPC Pattern The fixed size pattern within the packet that
the OMPC rule attempts to find.
Possible values: a combination of
hexadecimal numbers (0-9, a-f).
The value must be defined according to the
OMPC Length parameter. The OMPC Pattern
parameter definition must contain eight
symbols. If the OMPC Length value is lower
than fourBytes, you need complete it with
zeros. For example, if OMPC Length is
twoBytes, OMPC Pattern can be: abcd0000.
Default value: 00000000.
Offset The location in the packet from which the

checking of data is started in order to find
specific bits in the IP/TCP header. The value
can be: 0 - 1513.
Default value: 0.
OMPC Condition The OMPC condition can be either N/A,

equal, notEqual, greaterThan, or lessThan.
Default value: N/A.
9-58 CID User Guide

Table 9-6 OMPC Definition Parameters (cont.)
OMPC Mask The mask for the OMPC data.

Possible values: a combination of
hexadecimal numbers (0-9, a-f).
The value must be defined according to the
OMPC Length parameter. The OMPC Mask
parameter definition must contain 8 symbols.
If the OMPC Length value is lower than
fourBytes, you need complete it with zeros.
For example, if OMPC Length is twoBytes,
OMPC Mask can be: abcd0000.
OMPC Offset Indicates to which OMPC offset the selected

Relative to offset is relative to. You can set the following
parameters: None, IP Header, IP Data,
L4 Data, L4 Header, Ethernet.
Default value: None.
Content Definition Parameters

The Content parameters (Table 9-7) define the rule for a text/content
string lookup. This rule is intended for attack recognition where the
attack signature is a text/content string within the packet payload.
Table 9-7 Content Definition Parameters
Content Type Enables the user to search for one of the

following specific content types:
N/A: Not available.
Host Name: In the HTTP header.
CID User Guide 9-59

Intrusions
Table 9-7 Content Definition Parameters (cont.)
Content Type Header Type: HTTP header field. The

(cont.) Content field includes the header field name,
and the Content data field includes the field
value.
Regular Expression: Anywhere in the

packet.
Cookie Data: HTTP Cookie field. The content

field includes the Cookie name, and the
content data field includes the Cookie value.
URL: In the HTTP request URI. No

normalization procedures are taken.
Normalized URL: To avoid evasion

techniques when classifying HTTP-GET
requests, the URL content is transformed into
its canonical representation to interpret the
URL in the same way the server would. The
normalization procedure supports the
following cases:
• Directory referencing by reducing '/./' into
'/' or "A/B/./" to "A/".
• Changing backslash ('\') to slash ('/').
• Changing HEX encoding to ASCII
characters, for example, the hex
value%20 is changed to " " (space).
• Unicode support, UTF-8, and IIS encoding.
Mail Domain: In the SMTP header.
Mail To: In the SMTP header.
Mail From: In the SMTP header.
Mail Subject: In the SMTP header.
9-60 CID User Guide

Content Type File Type: The type of the requested file in the
(cont.) http GET command (jpg, exe, and so on).
POP3 User: User field in the POP3 header.
FTP Content: Scans the data transmitted

using FTP, performing normalization of the
FTP packets and stripping of Telnet opcodes.
FTP Command: Performs parsing of FTP

commands to commands and arguments,
while performing normalization of the FTP
packets and stripping of Telnet opcodes.
RPC: Reassembles RPC requests over

several packets.
RPC RFC 1831 standard provides a feature
called Record Marking Standard (RM). This
feature is used to delimit several RPC
requests sent on top of the transport protocol.
In case of the stream-oriented protocol (like
TCP), RPC uses a kind of fragmentation to
delimit between the records. In spite of its
original purpose, fragmentation may also
divide records in the middle and not only at
their boundaries. In some cases, this
functionality may be used to evade IPS
systems.
Text: Anywhere in the packet.
Default value: N/A.
CID User Guide 9-61

Intrusions
Content Data The type of content to be searched within the

packet:
• N/A: Not available.
• URL: HTTP Get packets are scanned for
their URL data.
• Text: For text in all packets.
Content Offset The location in the packet from which the

content is checked. The offset location is
measured from the beginning of the UDP or
TCP header. The value can be: 0 - 1513.
Default value: 0.
Content Encoding Application Security can search for content in

languages other than English, for case
sensitive or case insensitive text, as well as
hexadecimal strings. Values for this parameter
include:
• None
• Case Insensitive
• Case Sensitive
• HEX
• International
Note: The value of this field corresponds to
the Content Type parameter.
Content The actual value of the content search.

Possible values: < space >! " # $ % & ' ( ) * + ,
-. / 0 1 2 3 4 5 6 7 8 9 : ; < = > ? @ A B C D E
FGHIJKLMNOPQRSTUVWXYZ[
\]^_àbcdefghijklmnopqrstuvw
xyz{|}~.
9-62 CID User Guide

Content Language Contains the language (characters set) in

which the content is written.
Default language: English.
Content Max Length The maximum length to be searched within

the selected Content Type. The value can be:
0 - 1513.
Note: The Content Max Length value must be
equal to or greater than the Offset value.
Default value: 0.
Content Data Application Security can search for data in

Encoding languages other than English, for case
sensitive or case insensitive data, as well as
hexadecimal strings. Values for this parameter
include:
• None
• Case Insensitive
• Case Sensitive
• HEX
• International
Note: The value of this field corresponds to
the Content Type parameter.
Distance Range A range that defines the allowed distance

between two content characters. If the
distance is beyond the specified range, it is
recognized as an attack.
CID User Guide 9-63

Intrusions
Custom Attack Groups

The custom attack group represents a logical OR relation between two
or more attacks. The right panel of the Attack Group Configuration
window (Figure 9-5) contains a list of all existing groups.
Figure 9-5 Attack Group Configuration Window
Radware provides you with a set of predefined custom attack groups

as part of the Signatures file. You can also add user-defined attack
groups using predefined attacks or user-defined attacks. The
predefined attack groups are divided according to types of protection.
Groups can be activated within a protection profile, except for the
Unassigned group. The attacks that affect performance or are probable
to false positive are gathered in the Unassigned group and can be
activated either by adding an attack to an existing group or to a
user-defined group.
To add a new custom attack group:

appears.
9-64 CID User Guide

2. In the Connect and Protect Table window, double-click inside the

3. In the Settings pane, click Custom Group. The Attack Group
4. In the Group Name text box, enter the new user-defined name for
the attack group.
5. Select the attacks you want to include in this group and move
them to the Selected Attacks pane by clicking the Add button.
CID User Guide 9-65

Intrusions
Creating a New User-Defined Intrusion Prevention Profile

You can either select from the Radware predefined intrusion prevention
profiles or create your own custom profiles.
To create a new user-defined intrusion prevention profile:

2. In the Connect & Protect Table window, double-click in the
3. In the Settings pane, click New Profile. The New Intrusion
Prevention Profile window appears.
4. In the New Intrusion Prevention Profile window, enter a name for
your new profile.
5. Click Ok. The new profile appears in the Intrusion Prevention
Profile pane.
6. In the All Intrusion Attacks pane, select attack groups and move
them to the new profile by clicking the Add button.
7. In the Connect & Protect Table, select the policy to which you
want to apply the new intrusion prevention profile and click Apply.
The name of the new profile appears in the selected cell.
Editing Attack Groups
To edit an attack group:

2. In the Connect & Protect Table window, double-click in the
3. From the All Intrusion Attacks list, select the attack group you
want to edit and click Edit. The Attack Group Configuration
window appears.
4. Edit the parameters of the group (see Custom Attack Groups,
page 9-64).
9-66 CID User Guide

CID User Guide 9-67

Intrusions
Example - Configuring an Intrusion Prevention

Profile for Protection Against MSBlast Worm
The MSBlast (W32/Blaster) worm was first detected on August 11th
2003. This worm exploits known vulnerabilities in the Microsoft DCom
Remote Procedure Call (RPC) Interface.
Upon successful execution, the worm attempts to retrieve a copy of the
file msblast.exe from the compromised host. Once this file is retrieved,
the compromised system then runs it and begins scanning for other
vulnerable systems to compromise in the same manner. In the course
of propagation, a TCP session to port 135 is used to execute the
attack. Access to TCP ports 139 and 445 may also provide attack
vectors and should be considered when applying mitigation strategies.
Lab testing has confirmed that the worm includes the ability to launch a
TCP SYN flood DoS attack against windowsupdate.com.
Affected Products
The MSBlast worm affects the following Microsoft products:
• Microsoft Windows NT® 4.0
• Microsoft Windows NT 4.0 Terminal Services Edition
• Microsoft Windows 2000
• Microsoft Windows XP
• Microsoft Windows Server™ 2003
Impact
A remote attacker could exploit these vulnerabilities to execute
arbitrary code with Local System privileges or to cause a
denial-of-service condition.
Protection is obtained by adding two custom attacks and grouping them
together.
9-68 CID User Guide

To create the MSBlast Worm Protection Policy:

2. Create the first basic attack:
a. In the Connect & Protect Table window, double-click inside the
b. In the Settings pane, click Custom Attack. The Attack
c. In the Attack Name field, enter blast_shell.
d. Click Add New. The Filter Configuration window appears.
e. In the Filter Configuration window, enter the following values:
Filter Name: blast_shell
Protocol: TCP
Destination Port http
Group:
Source Port Group: http
OMPC Length: Not Applicable
OMPC Condition: Not Applicable
OMPC Pattern: 0000000
Mask: 0000000
OMPC Offset: 0
OMPC Offset Relative None
to:
Content Type: Text
Content Encoding: Case Sensitive
Content: msblast.exe
Content Offset: 0
Content Max Length: 0
Content Data Not Applicable
Encoding:
f. Click Ok twice to return to the Connect & Protect Table window.
CID User Guide 9-69

Intrusions
3. Create the second custom attack:

a. In the Connect & Protect Table window, double-click inside the
b. In the Settings pane, click Custom Attack. The Attack
c. In the Attack Name field, enter blast_shell.
d. Click Add New. The Filter Configuration window appears.
e. In the Filter Configuration window, enter the following values:.
Filter Name: blast_rpc
Protocol: TCP
Destination Port http
Group:
Source Port Group: http
OMPC Length: Not Applicable
OMPC Condition: Not Applicable
OMPC Pattern: 0000000
Mask: 0000000
OMPC Offset: 0
OMPC Offset Relative None
to:
Content Type: Text
Content Encoding: Hex
Content: 1F7457759580BFBB927F895A1
ACEB1DE
Content Offset: 0
Content Max. Length: 0
Content Encoding: HEX
Content Data Not Applicable
Encoding:
f. Click Ok twice to return to the Connect & Protect Table window.
4. Create a new custom attack group:
9-70 CID User Guide

a. In the Connect & Protect Table window, click Custom Group.

The Attack Group Configuration window appears.
b. In the Group Name text box, enter virus_custom.
c. From the All Attacks lists, select the custom attacks that you
created and click the Add button to move them to the Selected
Attacks list.
d. Click Ok. Virus_custom appears in the All Intrusions Attack list.
CID User Guide 9-71

DoS/DDoS
Section 9-4 DoS/DDoS

Section 9-4, DoS/DDoS, introduces the mechanism of DoS/DDoS
protection profiles and explains how to configure them.
• Introducing DoS/DDoS, page 9-73
• DoS/DDoS Protection Services, page 9-74
• Introduction to DoS Shield, page 9-75
• Setting Up DoS Shield Using Radware Profiles, page 9-80
• Defining DoS Shield with User-Defined Settings, page 9-81
• Introduction to Application Security, page 9-92
• Setting Up Application Security for DoS/DDoS Using Profiles and
Groups, page 9-93
• Defining Application Security Profiles with User-Defined Settings,
page 9-94
9-72 CID User Guide

Introducing DoS/DDoS
Radware’s security scheme provides organizations with extensive
Denial of Service (DoS) detection and protection capabilities while
maintaining high network throughput.
When hackers send mass volumes of traffic, they overload networks or
servers, thus causing denied access for real users. This is known as
Denial of Service (DoS) or Distributed Denial of Service (DDoS)
attacks.
DoS occurs as a result of various types of flooding caused by hackers,
such as UDP, TCP, and ICMP. The DoS/DDoS module provides
protection against packet flooding, thereby preventing denial of service.
Another challenge when mitigating DoS attacks is to deal with hackers,
who are becoming increasingly sophisticated. A basic DoS attack
floods the network with TCP, UDP, or ICMP packets that are generated
by common tools available on the Internet. Basic SYN attacks can be
accommodated by detecting incomplete TCP requests. However,
hackers may also use new techniques and tools, such as Naphta,
which creates a Connection Attack by completing a TCP handshake
without any data traffic.
Another type of DoS attack can be caused by one or few packet
attacks. These attacks exploit a server or network vulnerability, such as
buffer overflows, Ping of Death, Land Attack, and so on.
CID User Guide 9-73

DoS/DDoS
DoS/DDoS Protection Services

To provide protection against denial of service, the DoS/DDoS module
incorporates two different services that mitigate DoS attacks:
• DoS Shield Profiles: Sampling-based service that provides
protection against packet flooding, which causes a denial of service
effect. This protection is provided for TCP, UDP, and ICMP floods.
This service utilizes an advanced sampling mechanism, which
significantly reduces the device CPU load compared to packet-by-
packet scanning.
• Application Security Profiles: Packet-by-packet scanning service
that provides protection against DoS attacks, using signature-
based packet-by-packet scanning.
The sampling-based service provides optimized performance in high
throughput networks. Once an attack is detected, the DoS Shield
module sets the relevant attack filter for packet-by-packet inspection.
The packet-by-packet scanning service is based on the DoS protection
group, named DOS.
Using DoS/DDoS Profiles

The two types of profiles used in the DoS/DDoS security module are
Application Security Profiles and DoS Shield Profiles.
DoS/DDoS Configuration Guidelines:

DoS/DDoS column. The Settings pane appears.
3. Select Application Security Profiles, the settings pane appears
(see Defining Application Security Profiles with User-Defined
Settings, page 9-94).
9-74 CID User Guide

Introduction to DoS Shield

To prevent denial of service, DoS Shield samples traffic flowing through
the device and limits the bandwidth of traffic that was recognized as a
DoS attack using predefined action.
This concept is based on the fact that sporadic attacks that consume
negligible amounts of bandwidth can be tolerated by most of the
networks and do not require any counter action. An attack becomes a
threat to the network when it starts to consume large amounts of the
network's bandwidth. The DoS Shield module detects the occurrence
of such events with an advanced sampling algorithm and takes
automatic action to solve the problem. The combination of a unique
sampling scheme with the strong computing power of the Application
Switch platform provides maximum security at maximum speed.
How the DoS Shield Module Works

The DoS Shield mechanism is based on working with two attack states:
Dormant and Active.
Dormant state indicates that the sampling mechanism is used for
recognition prior to action activation. An attack in Dormant state can
become active only if the number of packets that enter your network
exceeds the predefined limit.
Active state indicates that the action must be implemented on each
packet that matches the attack signature without sampling.
The DoS Shield counts packets matching the Dormant and Active
states. Samples of the traffic are compared with the list of attacks in
Dormant state. When a pre-configured number of packets is reached,
the status of the attack changes to Active.
The DoS Shield mechanism involves two mechanisms working in
parallel. One statistically monitors the traffic to check if any of the
attacks in Dormant state is active. When an attack is detected as
active, this attack is handled by the second mechanism. Each packet
passing through the device is compared to the list of currently active
attacks. If no match is found, a portion of the packets is sent to be
compared with Dormant attacks and the rest of the packets are simply
CID User Guide 9-75

DoS/DDoS
forwarded to the network, without being inspected against the list of

Dormant attacks.
DoS Shield Traffic Flow

When traffic arrives at the device, samples of the traffic are copied and
inspected against each entry in the list of Dormant attacks to detect
possible attacks.
You can control the sampling rate by setting the number of packets that
pass through the device before a packet is examined against the list of
attacks in Dormant state (see Packet Sampling Rate in Figure 9-6).
You can also configure the duration of the sampling period during
which the different thresholds are checked (see Sampling Time in
Figure 9-6). Whenever traffic matches an Attack filter, a counter is
incremented. At the end of each Sampling Time, the counter value is
normalized and compared to the thresholds configured for the attack.
You can configure a Warning Threshold and an Activation Threshold
for each attack. When the Warning Threshold is met, a warning
message is sent notifying about the attack. When the Activation
Threshold is met, the attack state changes to Active. At that point, each
packet passing through the device is inspected against the attack and
the forwarding limit is executed.
9-76 CID User Guide

Incoming Packet
Copy of Compare to Match

Sampling
Sampled Dormant Attacks
Packets
All packets No
Match
Activation
No Threshold
Operation No Match Passed
Match
Activate
Compare to Match Attacks
Currently Active Attacks List
No
Match Pre-Configured Action
Forward the Packet to the Destination Port
Figure 9-6 DoS Shield Traffic Flow Diagram

When an attack is activated, the following actions are possible:
• Bandwidth of traffic (kbps) that match a Currently Active Attack is
limited when forwarding packets to the network.
• When the forwarding limit is 0, all packets that match the Currently
Active Attack are blocked.
The status of a Currently Active Attack reverts to Dormant when the
amount of traffic matching the attack filter is smaller than the Attack
CID User Guide 9-77

DoS/DDoS
Termination Threshold for a duration of the Aging Period for that attack.
The Aging Period allows you to set a number of Sampling Time
periods. In order for the attack to be considered over, the counters for
the attack must not cross the Termination Threshold during the
configured Sampling Time periods. The attacks’ status then reverts to
Dormant and, its termination is reported to the management station.
You can also preconfigure an attack as Currently Active. In that case,
every packet passing through the device is always matched against
that attack filter, regardless of the Attack Termination Threshold.
DoS Overload Mechanism

The Overload Mechanism is designed to protect the device from
becoming a network bottleneck, enabling to cascade two or more
devices so that each device removes excessive traffic according to its
capacity. When the traffic load approaches the device's maximum
processing capacity, the device behavior is affected by the Overload
Mechanism.
The Overload Mechanism is designed as an integral part of the DoS
Shield module, and therefore must be used in case DoS Shield is the
only active module. It is not recommended to use the Overload
Mechanism when other modules are also activated (IPS, SYN
Protection, BWM, and so on).
For possible configuration options, see page 9-14.
Notes:
• The Overload Mechanism is enabled when it is set to Forward
Excess Traffic.
• Only the excess traffic is affected by the operation of the Overload
Mechanism.
• The Overload Mechanism is activated when the device CPU
utilization reaches 80%.
• CPU utilization is measured every second.
9-78 CID User Guide

Overload Mechanism in Application Switch 1 and 2

CID 200/202 are based on AS1 platform. Both platforms share similar
architecture, where all traffic is processed and forwarded by the master
CPU.
When the master CPU reaches 80% utilization, it starts forwarding the
excess packets without the DoS Shield module inspection. All the other
security modules continue to operCIDate and filter traffic according to
their policies' settings. CID 1000 is based on AS2 platform.
Overload Mechanism in Application Switch 4

CID 3020 is based on AS-4 platform, where traffic is first classified by
the network processors (NPs). The overload is measured per master
CPU and NP load. Once the master CPU load reaches 80% or the NPs
are overloaded, the mechanism is activated. The device starts to
forward all traffic through the NPs without sending it to the master CPU
for inspection by DoS Shield. This means that all modules are
bypassed and no policies can be enforced on the excessive traffic.
CID User Guide 9-79

DoS/DDoS
Setting Up DoS Shield Using Radware Profiles

Protection Profiles and Groups Supplied by Radware, page 9-26).
You can use these prevention profiles to define protection policies (see
Setting Up Security Policies in the Connect and Protect Table, page 9-
10).
Most of the existing DoS attacks can be prevented using Radware
profiles.
DoS Shield Configuration Guidelines using Radware defined

profiles:
1. Enable DoS Shield protection and set the general parameters (see
page 9-14).
4. In the Settings pane, select DoS Shield Profiles.
5. In the DoS Prevention Profiles pane, select the predefined profiles
and apply them to the policy in the Connect & Protect Table
window.
Note: You can view all the information about an attack in the Attack
Dynamic Information table, see page 9-84.
9-80 CID User Guide

Defining DoS Shield with User-Defined Settings

The Dormant Attacks database consists of attacks supplied by
Radware. These attacks provide constant protection against all recent
DoS attacks. Each attack includes protection filters that are configured
to detect and block malicious packets. You can use these attacks to
define prevention profiles. Most of the existing DoS attacks can be
prevented using Radware attacks.
In addition to the Radware-defined attacks, you can add user-defined
attacks to the database. The parameters that are part of the Sampling
(Figure 9-6) process can be configured using the DoS Shield
mechanism. For new users, it is recommended to define DoS Shield
prevention profiles using Radware-defined attacks only.
DoS Shield Configuration Guidelines using user-defined

profiles:
1. Enable DoS Shield protection and set the general parameters (see
page 9-14).
2. Define the DoS Shield attacks (see page 9-81).
3. Create a new DoS Shield profile and apply the new profile to the
policy in the Connect and Protect Table (see page 9-90).
Defining DoS Shield Attacks and Filters

An Attack is a building block of the DoS Shield profile. Each attack
contains one or more protection filters and a mechanism that
determines which packets are malicious and how CID treats those
packets.
CID User Guide 9-81

DoS/DDoS
Figure 9-7 Filter Configuration
The Signatures database contains attacks provided by Radware. You

can add user-defined attacks to reflect the specific needs of your
network or edit the existing attacks.
bound to a "Tracking" function that defines how the packet is handled
9-82 CID User Guide

functions is to determine whether the packet is harmful and to apply an

indicator for the attack, and the packet is dropped (“Drop All”), for
example, MS Blast.
• The “Threshold” or “Counter” functions, which assume that the
defines “reasonable” behavior for such traffic. Only packets that
CID User Guide 9-83

DoS/DDoS
Table 9-8 describes the attack’s parameters.

30 characters.

Default value: 1000

Default value: 10.
9-84 CID User Guide


attacks.
Default: Drop All
CID User Guide 9-85

DoS/DDoS

Default: Drop

• High
• Medium
• Low
signature.

9-86 CID User Guide


attack.
be suspended.
be suspended.

Flood attacks.
CID User Guide 9-87

DoS/DDoS


Default: Enable.
To add a new attack:

4. Click Custom Attack. The Attack Configuration window appears.
5. In the Attack Configuration window, set the parameters as
explained in Table 9-8.
6. To add new user-defined filters to this attack, click Add New. The
Filter Configuration window appears.
cannot use filters from other attacks when you define a custom
attack.
7. In the Filter Name text box, type the name of the filter.
8. In the Protocol parameters pane, define the protocol parameters,
as explained in Table 9-5 on page 56.
9. In the OMPC parameters pane, define the OMPC parameters, as
explained in Table 9-6 on page 58.
9-88 CID User Guide

10. In the Content parameters pane, define the content parameters,

11. In the Filter Description text box, type the description of the filter.
12. The Custom DoS Filter window closes, and the new filter appears
in the Filters box of the Custom DoS Attack window.
13. Click Ok. The Edit Attacks Table window closes, and the new
attack appears in the All DoS Attacks List.
Filter Parameters
the custom attack.


1. In the Filter Configuration window, click Application Port Group.
The Application Port Groups window appears.
pane appears.
CID User Guide 9-89

DoS/DDoS
3. In the Modify pane, click Add and define the following parameters
Notes:
group.

for a fixed size pattern of up to four bytes, that uses fixed offset

Creating a New DoS Shield Profile

You can create a new profile using attacks provided by Radware or
using custom attacks.
9-90 CID User Guide

To define a new DoS Shield profile:

4. In the Settings pane, click New Profile. The New Profile window
appears.
5. In the Profile Name text box, type the name of the new profile and
click Ok. The New Profile window closes, and the new profile
appears in the DoS Prevention Profiles pane.
6. In the All DoS Attacks List pane, select the attack(s) that you want
to add to the new profile and click Add. The selected attack
7. In the Connect & Protect Table window, select the policy to which
you want to apply the new DoS Shield profile and click Apply. The
name of the new profile appears in the selected cell.
CID User Guide 9-91

DoS/DDoS
Introduction to Application Security

Application Security profiles are incorporated in the mechanism of
protection and prevention against the denial of service attacks. These
profiles deliver advanced detection and prevention capabilities,
providing maximum protection for network elements, hosts, and
applications.
Application Security provides protection against one-packet or
multiple-packet attacks that cause denial of service. Examples of such
attacks include the Cisco vulnerabilities and exploits, in which a single
packet may cause routers to stop forwarding traffic until reset occurs.
Another example is the Land attack, where a packet is sent with the
same source and destination ports, which can cause certain servers to
crash.
Application Security profiles are predefined traffic detectors that scan
the incoming traffic in order to identify known attack signatures. The
profiles use various attacks that find the malicious packets and make
decisions in accordance with the predefined settings.
9-92 CID User Guide

Setting Up Application Security for DoS/DDoS Using

Profiles and Groups
Protection Profiles and Groups Supplied by Radware, page 9-26).
You can use these prevention profiles to define protection policies (see
10). Most of the existing attacks can be prevented using Radware
profiles.
Application Security Profiles Configuration Guidelines using

Radware-Defined Profiles:
1. Enable Application Security and define the general parameters
(see page 9-12).
2. Select the predefined profiles and apply them to the policy in the
Connect & Protect Table.
3. In the main window, click Security. The Connect & Protect Table
window appears.
6. From the DoS Prevention Profiles list, select the predefined
profiles and apply them to the policy in the Connect & Protect
Table window.
CID User Guide 9-93

DoS/DDoS
Defining Application Security Profiles with User-Defined

Settings
In addition to the Radware-defined profiles and groups, you can create
define profiles using Radware defined attack groups only.
Application Security Configuration Guidelines Using User-

Defined Settings:
1. Enable Application Security and define the general parameters
(see page 9-12).
2. Define custom attacks (see page 9-49).
3. Define custom attack groups (see page 9-64).
4. Define the Application Security profile and apply it to the policy in
the Connect & Protect Table window (see page 9-66).
9-94 CID User Guide


An attack (Figure 9-3) is a building block of the Application Security
profile. Each attack contains one or more protection filters and a
mechanism that determines which packets are malicious and how CID
treats those packets.
Note: For each custom attack you must define custom filters. You
bound to a “Tracking” function that defines how the packet is handled
indicator for the attack, and the packet is dropped ("Drop All") for
example, MS Blast.
• The “Threshold” or “Counter” functions. These functions assume
that the signature match alone is not enough for detecting a packet
as offensive. This is because the packet may be legitimate unless
the number of packets over a period of time exceeds a threshold
that defines "reasonable" behavior for such traffic. Only packets
that exceed the threshold within a predefined time slot are dropped,
for example, ICMP flood attacks and DoS attacks.
CID User Guide 9-95

DoS/DDoS
Table 9-10 presents attack’s configuration parameters.

30 characters.

Default value: 1000

Default value: 10.
9-96 CID User Guide


attacks.
Default: Drop All
CID User Guide 9-97

DoS/DDoS

Default: Drop

• High
• Medium
• Low
signature.

9-98 CID User Guide


attack.
be suspended.
be suspended.

Flood attacks.
CID User Guide 9-99

DoS/DDoS


Default: Enable.

appears.
5. In the Attack Name text box, enter the name of the new attack.
6. Set the attack parameters, as explained in Table 9-10 on page 9-
96.
7. In the Attack Configuration window, click Add New. The Filter


13. Click Ok. The Attack Configuration window closes. The new attack
now appears in the Custom Group window.
Filter Parameters
the custom attack.


appears.
Dos/DDos column. The Settings pane appears.

DoS/DDoS
6. In the Application Port Group window, click Modify. The Modify

pane appears.
7. In the Modify pane, click Add. The Edit Application Port Groups
window appears.
8. In the Edit Application Port Groups window, set the following
From Port: The first port in the range.
To Port: The last port in the range.
Notes:
• To define a group with a single port, assign the same value to From
Port and To Port.
same group name for all the ranges that you want to include in the
group.

fixed offset. The OMPC parameters are described in Table 9-6.




to false positive are gathered in the unassigned group and can be
user-defined group.

appears.
4. In the Settings pane, click Custom Group. The Attack

DoS/DDoS
5. In the Attack Name field, enter the new user-defined name for the
attack group.
6. Click Ok to return to the Connect & Protect Table window.
7. From the All Dos Attacks list, select the attacks you want to
include in the group and move them to the Selected Attacks pane
by clicking the Add button.
Creating a User-Defined Application Security Profile

You can either select from the Radware predefined Application Security
To create a user-defined application security profile:

appears.
3. In the Settings pane, click New Profile. The New DoS Profile
window appears.
4. In the New DoS Profile window, enter a name for your new profile
and click Ok. The new profile appears in the DoS Prevention
Profiles pane of the Connect & Protect Table window.
5. In the All DoS Attacks pane, select the attack group(s) that you
want to add to the new profile and click Add. The selected group
6. In the Connect and Protect Table window, select the policy to
which you want to apply the new DoS profile and click Apply. The
name of the new profile appears in the selected cell.

Editing Attacks
To edit an attack:
appears.
3. From the All DoS Attacks list, select the attack group that you
want to edit and click Edit Attack. The Attack Configuration
window appears.
page 9-64).

Behavioral DoS
Section 9-5 Behavioral DoS

Section 9-5, Behavioral DoS, presents the B-DoS (Behavioral DoS)
module, which is designed to detect and prevent network flood attacks.
• Introduction to Behavioral DoS, page 9-107
• Behavioral DoS Global Parameters, page 9-109
• Behavioral DoS Advanced Settings, page 9-112
• Bypass Footprints, page 9-115
• Bypass Footprints, page 9-115

Introduction to Behavioral DoS

The Behavioral DoS (B-DoS) module is designed to provide traffic
anomaly detection and on-the-fly signature creation for immediate DoS
attack protection.
The B-DoS module detects and prevents network attacks from the
public network by detecting traffic anomalies and prevents unknown
flood attacks by identifying the footprint of the anomalous traffic. The B-
DoS module is designed to protect against Network Flood Attacks,
which cause a great deal of irrelevant traffic to fill available network
bandwidth, denying use of network resources to legitimate users.
Network Flood protection types include:
• SYN Flood
• TCP Flood
• UDP Flood
• ICMP Flood
• IGMP Flood
The Behavioral DoS Module

The B-DoS module learns the network traffic base lines for each
protocol type (i.e., TCP, UDP,ICMP and IGMP), and then detects the
attack by alerting traffic anomalies compared to the learned baselines.
The next step is identifying the attack footprint, which is translated into
an attack signature. The B-DoS module then configures a filter to
protect the network according to the policy settings, and activates the
feedback module in order to optimize the signature and reduce false
positives. In the case the attack is over, the feedback mechanism is
also responsible for removing the attack signature.
The Behavioral DoS module detects statistical traffic anomalies and
creates an accurate attack footprint (signature) which are based on
heuristic protocol information analysis. This ensures very accurate
attack filtering with very low false-positives.
The SYN flood protection provided by the B-DoS module is non-
intrusive and detects attacks on the fly, resulting in cleaning the links
from excessive traffic efficiently.

Behavioral DoS
Notes:
• Note that the B-DoS module is based on anomalous traffic
detection and signature creation on the fly. The average time for a
new signature creation may vary between 10 and 30 seconds.
Flood attacks usually take place for minutes or hours.
• For more information about the B-DoS module underlying
technology, please click on the following link: http://
www.radware.com/content/document.asp?_v=about&document=6560

Behavioral DoS Global Parameters

Each row in the Connect & Protect Table represents a policy. A B-DoS
security policy contains security profiles that are activated within
predefined ranges of ports/VLANs, or within a predefined network. The
Connect and Protect Table is divided into sections including the section
for B-DoS. B-DoS can be enabled globally or per profile.
Enable Behavioral DoS

In order to start protection, B-DoS must first be enabled.
To enable Behavioral DoS:

1. In the main window, click APSolute OS > Security. The Connect
and Protect Table appears.
2. In the Connect and Protect Table, double-click on Settings. The
Security Settings window appears.
3. In the Behavioral DoS field select the Start Protection checkbox.
4. Restart the device. Behavioral DoS is now enabled.
Behavioral Dos Global Configuration Guidelines:

1. Defining Bandwidth Settings, page 9-109
2. Behavioral DoS Profiles Policies, page 9-110
Note: Behavioral DoS also includes advanced user settings, however
these settings are recommended for expert users only. Radware
recommends that you maintain the Advanced parameters with their
default values.
Defining Bandwidth Settings

In order to create a B-DoS security policy you must first define the
Bandwidth settings for Behavioral DoS inbound and outbound traffic.

Behavioral DoS
To define Bandwidth Settings:

1. In the main window, click APSolute OS > Security. The Connect
and Protect Table appears.
2. Click inside the Behavioral DoS column, the Behavioral DoS
Profiles pane appears.
3. Select a profile and click Behavioral DoS Settings. The
Behavioral DoS Settings window appears. Set the following
Bandwidth Settings: • In: Available bandwidth for
inbound traffic. The value should
be the lower of the bandwidth of
the circuit or the assigned inbound
bandwidth from your Internet
Service Provider. Default value:
50,000 Kbit/s
• Out: Available bandwidth for
outbound traffic. The value should
be the lower of the bandwidth of
the circuit or the assigned
outbound bandwidth from your
Internet Service Provider. Default
value: 50,000 Kbit/s
Behavioral DoS Profiles Policies

A Behavioral DoS security policy contains security profiles that are
activated within predefined ranges of ports/VLANs, or within a
predefined network. First, you create a security policy and then you can
assign protection profiles to the policy.
To create a basic Behavioral DoS Policy:

1. Define the Bandwidth Settings, page 9-109
2. Create a new profile:

a. In the main window, select APSolute OS > Security. The

Connect and Protect Table appears.
b. Click anywhere in the Behavioral DoS column. The Behavioral
DoS Profiles Settings pane appears.
c. Click New Profile. The New Behavioral DoS Profile window
appears.
d. in the New Behavioral DoS window enter the profile name.
Click Ok.
3. In the Settings pane, select Behavioral DoS from the All
Behavioral DoS Attacks tree and click the Add mover arrow. The
Behavioral DoS attack is added to your profile.
4. In the Behavioral DoS profiles, select Behavioral DoS and then
click Edit. The Edit Behavioral DoS Profile window appears,
which includes the following checkboxes:
• TCP
• TCP SYN
• UDP
• ICMP
• IGMP
5. Select the type of attacks to protect against for this policy and click
Ok.
Note: Radware recommends that you include all attacks in your
policy.
6. Click Apply > Update Policies. Click Ok. The new policy now
appears in the Connect and Protect Table.

Behavioral DoS
Behavioral DoS Advanced Settings

The B-DoS Advanced Settings allow you to set the Learning Response
Period upon which baselines are primary weighed, and enable the
sampling status and define the strictness level of the Footprint.
Note: The advanced user settings are recommended for expert users
only. Radware recommends that you maintain the advanced
parameters with their default values.
Advanced Behavioral DoS Settings Configuration Guidelines:

1. Define the Learning Response Period, page 9-112.
2. Set Quota Settings, page 9-113.
3. Set the Sample level, page 9-113.
4. Set the Footprint Strictness level, page 9-114.
Learning Response Period

Network Flood protection learns traffic parameters from the transport
layer of incoming and outgoing packets and generates normative
baselines for traffic.
The Learning Period setting defines the period based upon which
baselines are primarily weighed.
When the baseline for the policy is reset, the baseline traffic statistics
are cleared, default normal baselines are set and then CID immediately
initiates a new learning period. Generally, this is done when the
characteristics of the protected network have changed entirely and
bandwidth quotas need to be changed to accommodate the network
changes.
To set the Learning Response Period and Reset the Baseline:

1. In the Behavioral DoS settings pane, Click Behavioral DoS
Settings. The Behavioral DoS Settings window appears.
2. In the Behavioral DoS Settings window select either: Day, Week or
Month from the dropdown list.
3. Click Reset Baseline Learned Statistics.

Quota Settings
The B-DoS quota limits are the percentage of total inbound and
outbound bandwidth that a specific protocol is permitted to use.
To define the Quotas Settings:

1. In the Behavioral DoS Settings pane, Click Behavioral DoS
2. In the Behavioral DoS Settings window, set the incoming and
outgoing values for each protocol.
Note: It is recommended to use default quotas initially and adjust quota
values based on experience with your network’s performance.
Sampling Status
The Sampling status allows you to aggregate Traffic Statistics in order
to improve performance levels.
When down sampling is enabled the system screens only part of the
traffic. The down sampling mechanism dynamically selects the most
appropriate portion of traffic that need to be examined in order to
preserve the system’s resources while maintaining minimal sampling
error. High sampling errors increase the chances for false positive
detections.
To set the Sampling Status:

1. In the Behavioral DoS Settings pane, click Behavioral DoS

Behavioral DoS
2. In the Behavioral DoS Settings window from the Samplings

dropdown list select one of the following accordingly:
Enabled Traffic statistics are aggregated
through sampling algorithm which
improves overall performance of the
CID protection system.
Note: The risk for false postives is
increased when the decision engine is
tuned according to the sampling error.
Disabled Traffic statistics are aggregated
without sampling.
3. Click Apply and Ok.
Footprint Strictness Level

Using the footprint strictness level, when a new attack is detected the
B-DoS module generates an attack signature to block the traffic
anomaly created by the attack.
To set Footprint Strictness Levels:

1. In the Behavioral DoS Settings pane, click Behavioral DoS
2. In the Behavioral DoS Settings window click on the Footprint
Strictness Level dropdown box and define the strictness level:
High By setting the strictness to High the
false-positive ratio is reduced to
minimum, however there may be a
higher chance that attacks will not be
blocked.
Medium Default level.
Low By setting the strictness to Low the
device will perform best attacks
blocking, however the false positive
ratio is increased.

3. Click Ok > Apply.
Bypass Footprints
Flood attacks commonly disrupt networks by using all or most available
network bandwidth.
You can configure CID to detect and block network flood attacks by
defining attack footprints. Attack Footprints are selected fields in the
packet header or payload. CID automatically detects the footprints and
generates filters to protect against the attack.
For an explanation of the bypass types and values for each attack
group, See Footprint Bypass Fields, page 9-117.
To set Bypass FootPrints:

1. In the Behavioral DoS Settings pane, select the attack from the All
Behavioral DoS Attacks column.
2. Click Edit. The Edit (Attack Type) Flood Attack window appears.
3. In the Edit Flood Attack window, select the bypass type and click
Edit. The Edit Field Parameters window appears.

Behavioral DoS
4. In the Edit Field Parameters window, set the following parameters

Bypass Type The footprint type being bypassed.
B-DoS module bypasses all possible
values of the selected filter type
when creating filters.
Status Accept: Allows footprint types.
Bypass: Bypasses certain footprint
types, which prevents traffic from
being blocked based on the value of
the bypassed footprint.
Value B-DoS module bypasses selected
values only of a selected footprint,
while blocking all other values.
These values vary according to the
footprint selected.
Enter the value for the Bypass type.
See Table 9-10: Footprint Bypass
Values, page 9-117.

Footprint Bypass Fields

Table 9-10, Footprint Bypass Values, presents the Footprint bypass
types and values for each attack group
Table 9-10 Footprint Bypass Values
Default
Footprint ICM IGM
UDP TCP Bypass Range
Type P P
Values
Transport + + NR + Values cannot No values

layer be configured.
checksum
TCP NR NR + NR 0 - (2^32-1)
Sequence
Number
IP ID Number + + + + 0 - (2^16-1)
DNS ID + NR NR NR 0 - (2^16-1)
DNS Qname + NR NR NR Values cannot No Values

checksum be configured
DNS Qcount + NR NR NR 1 0 - (2^16-1)
Source Port + NR + NR 0 - (2^16-1)
Source IP + + + + 0.0.0.0.
255.255.255.
255
ToS + + + + 1 - 255

Behavioral DoS
Table 9-10 Footprint Bypass Values
Default
Footprint ICM IGM
UDP TCP Bypass Range
Type P P
Values
Packet Size + + + + ICMP: 74 (60 0 - (2^16-1)

L3)
TCP Syn: 60,
62, 66,
74,(46, 48,
52, 60 L3)
TCP ACK: 60
(46 L3)
TCP ACK +
FIN: 60 (46
L3)
TCP RST: 60
(46 L3)
Fragment + + + + Values cannot No Values

be configured
Destination + NR + nr 0 - (2^16-1)
Port
Destination IP + + + + 0.0.0.0 -
255.255.255.
255
ICMP/IGMP NR + NR + 0-255
Message
Type
TTL + + + + 0-255

Section 9-6 Connection Limit

The Dos-Shield module provides protection against known DOS
attacks. To protect against unknown flooding attacks, CID implements
the connection limit capability. This capability mitigates any kind of TCP
or UDP flood attack whether it is half-open attack (SYN-attack),
connection attack or request attack.
To implement this functionality, the device allows configuration of
connection limiting policies, profiles and attacks. Connection limiting
attacks are defined for groups of TCP or UDP application ports. For
traffic that matches a connection limiting policy, the device counts the
number of TCP sessions or UDP connections opened per client, per
server or per client and server combination (according to attack
definition). Once the number of sessions/connections per second
reaches the threshold set for an attack belonging to this policy, it is
identified as an attack and any session/connection that is over the
threshold is dropped (unless the action for this attack is Report Only).
The source IP address can be suspended if traffic from this source is
dropped for a number of seconds according to Suspend Table
definitions.

Connection Limit
Creating Connection Limiting Policies
To create a new connection limiting policy using a predefined

attack:
2. In the Connect and Protect Table, double click anywhere in the
DoS/DDoS column. The DoS/DDoS Settings pane appears.
3. In the DoS/DDoS Settings pane, select Connection Limit
Profiles.The Connection Limiting Profiles pane appears.
4. In the Connection Limiting Profiles pane, click New Profile and
enter a user defined name for your new profile. Click Ok.
5. Select an attack from the All Connection Limiting Attacks tree and
click Add. The attack is now added to the profile.
6. Click Apply > Update Policies.
To create a user defined custom attack:

2. In the Connect and Protect Table, double-click anywhere in the
DoS/DDoS column. The DoS/DDoS Settings pane appears.
3. In the DoS/DDoS Settings pane, select Connection Limiting
Profiles.The Connection Limit Profiles pane appears.
4. In the Connection Limit Profiles pane, click Custom Attack. The
Connection Limiting Attack Configuration window appears, which
contains the following parameters:
Attack Name: Enter a user defined name for easy
identification of the attack in
configuration and reporting.
Application Port: A group of Layer 4 ports that
represent the application to protect.
Protocol: Layer 4 protocol of the application to
protect - TCP or UDP.

Packet Report: Enable or disables packet reporting

for this attack.
The following reports are generated
for connection limit:
• When the activation threshold of
a connection limit attack is
reached an alert with status =
started is sent.
• Alerts with status = on-going are
sent periodically while the attack
is On. The number of sessions
per second is higher than the
threshold.
• An alert with status = terminated
is sent when the attack stops.
The number of sessions per
second goes under the
threshold.
Risk: Define the risk level for this attack.

Connection Limit
Suspend Action: The suspended status of source IP

addresses identified as the source of
the flooding attack. The options are:
• None: No suspend action is to
be taken.
• SrcIP: All traffic from the source
IP identified as source of this
attack is suspended (available if
Tracking Type is Source count or
Source & Target count).
• SrcIP-DstIP: All traffic between
the source and destination IP
combination for which the attack
was identified is suspended
(available if Tracking Type is
Source & Target count only).
Note: When tracking type is target
count, Suspend Action can only be
None.
5. Set the parameters according to the explanations provided and
click Ok. The new user defined custom attack appears in the All
Connection Limiting Attacks tree. A profile can now be added to
the attack.

Section 9-7 SYN Flood Protection

Section 9-7, SYN Flood Protection, describes how the mechanism of
SYN Flood Protection works and how to configure it.
• Introduction to SYN Flood Protection, page 9-124
• Before Setting Up SYN Flood Protection, page 9-129
• SYN Flood Protection General Settings, page 9-130
• Creating Custom SYN Attacks, page 9-134
• Configuring SYN Flood Protection Policies, page 9-136
• SYN Flood Reporting, page 9-140

SYN Flood Protection
Introduction to SYN Flood Protection

SYN Flood Protection is a service intended to protect the hosts located
behind the device and the device itself from SYN flood attacks by
performing delayed binding.
A SYN Flood attack is a DoS attack where the attacker sends a huge
amount of please-start-a-connection packets and then does not send
any follow-up packets.
The SYN Flood attack is performed by sending a SYN packet without
completing the TCP three-way handshake. Another type of SYN Flood
attack is done by completing the TCP three-way handshake, but
without sending data packets thereafter. Radware provides complete
protection against both types of SYN Flood attacks.
These attacks are detected and blocked by means of SYN Flood
Protection Policies. The reports regarding the current attacks appear in
the Active Triggers table.
How Delayed Binding Works

Delayed Binding is a process in which the device alters fields, such as
the sequence number of the TCP stream from the client to the
destination server. See Figure 9-9. The subsequent session fetches
the information that was requested in the original session, and only
when that information is gathered, is it returned to the client via the
original session.

Client CID Server
1 SYN
2 SYN-ACK
3 ACK
4 HTTP-GET
New Client Entry
SYN
SYN-ACK
ACK
HTTP-GET
Figure 9-9 Delayed Binding Process
Once a SYN Flood attack is identified, the device activates a protection

mechanism known as SYN Cookies. Figure 9-9 illustrates the delayed
binding process, including the following steps:
1. A client initiates a request by sending a SYN packet. The SYN
packet includes the destination port number and a TCP sequence
number, which represents the connection with the first segment
from the client’s side.
2. The device sends a SYN-ACK packet back to the client. The
device creates a special initial TCP sequence number. The
sequence number is created in such a manner that it encodes a
timestamp and relevant SYN packet data in the SYN-ACK packet
sent to the client.

3. The client sends an ACK packet to the device. When a client

responds with an ACK packet, the device uses the SYN Cookie to
verify legitimate client responses.
4. Once the TCP handshake is completed, the client sends a data
packet, in this example: HTTP-GET. When the GET request is
sent to the device with the SYN Cookie, the device verifies the
SYN Cookie. If the client response found in the SYN Cookie is
legitimate, the device creates a new client entry. If required, the
device makes a load-balancing decision. Then, the device selects
the destination server and initiates the three-way TCP handshake
with it.
The core of delayed binding is the ability to handle two sessions and
pass the information between them. The device has to alter information
such as the sequence number and the source address from one
session to another.
SYN Cookies can be used for any TCP port or application where
"usual" delayed bind is typically used for HTTP sessions. The benefit of
SYN Cookies over "usual" delayed bind is that when SYN Cookies are
used, no memory resources on the device (for example, Session Table
entries) are allocated for sessions before the three-way handshake is
complete. This assures that device memory resources are not
overloaded due to the SYN attack.
SYN-ACK Reflection Attacks Prevention

SYN-ACK Reflection Attacks Prevention is intended to prevent
reflection of SYN attacks and reduce SYN-ACK packet storms that are
created as a response to DoS attacks.
When a device is under SYN attack, it sends a SYN-ACK packet with
an embedded Cookie, in order to prompt the client to continue the
session. In case of DoS SYN attacks, two problems may arise:
• Third parties can use the SYN-ACK replies to launch attacks on
selected sites by adopting the selected site's address as the
Source IP address of the attack.
• The SYN-ACK packets create a storm of reflected traffic that
consumes bandwidth and may block legitimate traffic.

SYN-ACK Reflection Attacks Prevention responds to the challenge of

the DoS SYN reflection attack by limiting the amount of SYN-ACK
packets sent to a specific IP address. This mechanism works in the
following way:
1. The limiting action is applied when the amount of SYN-ACK
packets exceeds the defined threshold.
2. The threshold represents the number of incomplete TCP sessions
and is calculated by comparing each source IP address and the
total number of SYN packets that arrived to the device with the
number of completed TCP sessions. The time interval for this
threshold is set per second.
3. The threshold is user-defined (recommended values are
preconfigured as defaults) (see Table 9-11).
4. The limitation of SYN-ACK packets does not affect the SYN attack
detection (start/stop) mechanism.
5. Once the limiting action is applied, the device ignores any
additional SYN packets arriving from the specific IP address that
is the source of the attack.
Note: Device behavior in the case of a Distributed SYN attack remains
unchanged.

SYN Flood Protection Configuration Guidelines:

1. Enable the Session Table (see page 9-129).
2. Set the Session Table Lookup mode to Layer 4 (see page 9-129).
3. Enable SYN Flood Protection and set SYN Flood General
parameters (see page 9-130).
4. Create a new custom SYN Attack Profile (see page 9-134).
5. View the SYN Flood Order (see page 9-132).

Before Setting Up SYN Flood Protection

Before activating the SYN Flood Protection module, you need to
configure the Session Table to operate at Layer 4, as SYN attack
detection can take effect only when the device operates at Layer 4.
To enable Layer 4:
1. From the main APSolute Insite window, right-click the CID icon and
select SetUp. The SetUp window appears.
2. In the SetUp window, click Global. The Global pane appears.
3. In the Global pane, select Session Table Settings and click Edit
Settings. The Session Table Settings window appears.
4. In the Session Table Settings window, enter the following values:
Session Table Status: Enabled
Session Table Lookup Mode: Full Layer 4
Note: When using the SYN Flood Protection Filters (that are part of
the Security module), you must set the inbound and outbound
traffic to operate in the Process mode.

SYN Flood Protection General Settings

Once you configure the Session Table to operate in the Layer 4 mode,
you can enable SYN Flood protection and configure its general
parameters.
Table 9-11 SYN Flood Protection General Parameters
SYN Flood Enables/disables SYN Flood protection.

Protection Status
Standby means that you can activate the SYN
Flood Protection module without rebooting the
device.
Default value: Enabled.
SYN Protection Timeout to complete the TCP three-way

Timeout handshake.
Range: 0-10 (0 means no timeout).
Default value: 5 seconds.
Attack Periodic If the percentage of incomplete sessions for a

Report Threshold destination protected by a policy is above this
threshold, the attack is reported periodically. A
value of 0 means no report is available.
Range: 1-100%.
Default value: 30%.
SYN Protection The number of seconds in which the number

Tracking Time of SYN packets directed to the same
destination must be below the value of the
Deactivation Threshold (see page 9-136) that
stops the protection of the destination.
Range: 1-10.
Default value: 5.

Table 9-11 SYN Flood Protection General Parameters (cont.)
SYN-ACK Reflection Activate the SYN-ACK Reflection Attack

Protection Mode Prevention mechanism using the following
modes:
• Enable: The Prevention mode.
• Report Only: The Report-only mode (no
prevention).
• Disable: The mechanism is disabled.
Default value: Disable.
SYN-ACK Reflection The number of SYN packets per second that

SrcIP Sampling per are sampled and their Source IP is monitored.
second
Range: 0-10000.
Default value: 100.
SYN-ACK Reflection The limiting threshold that represents the

Maximum SYN maximum number of incompleted TCP
Cookies per Source sessions per Source IP per second that are
answered. Any session exceeding this
frequency is ignored.
Range: 1 - 100,000.
Default value: 1,000.
Statistics Max For each policy, the maximum number of

Destinations per destinations that can be reflected in the
Policy statistics report. The destinations are defined
during the Connectivity setting of the Connect
and Protect Table (see Defining Connectivity,
page 9-19).
Note: Only destinations defined using IP
addresses and Layer 4 ports are relevant for
SYN Flood protection policies.
Range: 1-100.
Default value: 5.

Table 9-11 SYN Flood Protection General Parameters (cont.)
Statistics Time The number of seconds used to calculate

Period average values for SYN protection statistics.
Range: 1-1000.
Default value: 60.
Displaying Statistics A list of all the SYN Flood protection policies

of Policy defined on the device.
To enable SYN Flood protection and configure the general

parameters:
3. In the Global pane, select SYN Flood Protection Settings and
click Edit Settings. The SYN Flood Protection Settings window
appears.
4. Set the parameters as explained in Table 9-11 and click Apply
and Ok.
Viewing SYN Flood Order

Clicking View SYN Order allows you to view the index order in which
the device processes the SYN Flood profiles.
To view the SYN Flood order:

3. In the Global pane, select SYN Flood Protection Settings and
click Edit Settings. The SYN Flood Protection Settings window
appears.

4. In the SYN Flood Settings pane, click View SYN Order. The SYN
Protection Policies window appears, as shown below:
Figure 9-10 SYN Protection Policies

Creating Custom SYN Attacks

Radware provides you with a set of predefined SYN attacks. In
addition, you can create user-defined attacks.
Figure 9-11 SYN Attack Configuration Window
To create a custom SYN attack:

1. From the main APSolute Insite window, open the APSolute Insite
appears.
SYN Floods column. The Settings pane appears.
3. In the Settings pane, click Custom Attack. The SYN Attack
4. In the Application Name field, enter the name of the custom SYN
attack.
5. Click App. Port Group. The Application Port Group window
appears, displaying the group of Layer 4 ports for UDP and TCP
traffic. Each group is identified by its unique name. Each group
name can be associated with a number of entries in the
Application Port Group table. The values can be: 0 - 65535.
pane appears.

Name: A user-defined group name for the
application port.
Notes:
Port and To Port.
• To associate a number of ranges with the same group, use the
group.
8. Click Ok. A new row appears in the Application Port Group table.
9. Click Ok. The Application Port Group window closes.
10. From the Destination App. Port Group drop-down list, select a
group that was defined in the Application Port Groups table.
11. In the Attack Description field, enter a description of the attack.
12. Click Ok. The SYN Attack Configuration window closes, and a
new user-defined attack appears in the All Regular Filters pane of
the Connect & Protect Table window.

Configuring SYN Flood Protection Policies

Once you have created a custom attack, you can create a new SYN
policy. This is done by adding the custom attack to the list of the
Selected SYN Flood attacks and configuring policy parameters. The list
contains attacks that have been selected to participate in the policy.
To add a predefined SYN Attack to the Selected SYN Attacks:

appears.
3. From the All Regular Filters list, select the attack you wish to add.
4. Click Add. The SYN Policy Details window appears.
5. In the SYN Policy Details window, set the following parameters
according to the explanations provided:,
Policy Index: Enter the Index number. This defines
the order in which the device
processes the SYN Attack Profiles.
Verification Type: Define the process of completing the
TCP session:
• Ack: session is completed when
the Ack packet arrives (following
a SYN/SYN-ACK packet
exchange).
• Request: session is completed
when the first data request
packet arrives (following a SYN/
SYN-ACK/ACK packet
exchange).

Protection Mode: Select either:

• Enabled: Activates full SYN
Flood protection.
• Triggered: Activates SYN Flood
protection only when an attack is
identified.
Note: When the Session Table is
80% full, triggered policies act as
Enabled and reply to all new
sessions with Cookies.
• Disabled: SYN Flood protection
is disabled.
Activation Threshold: The maximum number of SYN
packets that are allowed to arrive at
the same destination per second. If
the Activation Threshold goes
beyond the predefined number, the
traffic is recognized as an attack and
the packets are terminated.
Deactivation Threshold: The minimum number of SYN
packets per second that can arrive at
the same destination. If the number
of packets that arrive at the same
destination is below the Deactivation
Threshold, the SYN Flood protection
policy is deactivated and the traffic is
no longer protected.
Count Statistics Enable or disable counting of the
(checkbox): statistics for the destinations defined
in this policy.
6. Click Ok. The selected attack appears in the Selected SYN
Application Ports list.

Viewing the SYN Statistics

To make the process of defining policy thresholds easier, you can view
SYN Statistics prior to configuring the thresholds. The SYN Statistics
table provides information on the number of SYNs, complete sessions,
and other data, thus helping you to define reliable thresholds in custom
policies.
To view the statistics of SYN policies:

window and select Security. The Connect & Protect Table window
appears.
3. In the Settings pane, click SYN Floods Statistics. The SYN
Floods Statistics window appears.
4. In the SYN Floods Statistics window, set the following parameters
Policy Name: The name of the policy which traffic
data is collected and analyzed.
Dest IP: A specific destination IP included in
the policy.
Dest Port: A specific destination port included in
the policy.
RX Port: A specific RX port included in the
policy.
Attack Status: The current status of the attack.
Possible values: Protected (Under
Attack), Protected (No Attack),
Monitoring (No Attack), Not
Protected.
Active Time (Secs): Activity time of this entry in the table.
SYNs Last Sec: The number of SYNs within the last
second.

Valid Sess Last Sec: The number of valid sessions within

the last second.
SYNs/Sec Avg: The average number of SYNs per
second.
Valid Sess/Sec Avg: The average number of valid
sessions per second.
SYNs/Sec Peak: The highest value of SYNs per
second during the statistical analysis
period.
Valid Sess/Sec Peak: The highest value of valid sessions
per second during the statistical
analysis period.
Attack Start: Last attack detection time and date.
Attack Term: Last attack termination time and
date.

SYN Flood Reporting

You can view active SYN Flood attacks via the Active Triggers table.
Table 9-12 presents the parameters of the Active Triggers table.
Table 9-12 Active Triggers Table Parameters
Type The type of the identified attack:

• SYN Flood Trigger: The identified attack
belongs to one of the policies with the
Protection mode of Trigger.
• SYN Enabled Policies: This attack entry
will include the sum of all attacks that
match the policies with the Protection
mode enabled.
• SYN Protection Total: Displays in each
field the sum of all other attacks (triggers
and enabled.)
• SYN ACK Reflection: The identified
attack is a SYN ACK Reflection attack.
IP Address The Source IP for SYN ACK Reflection:

attacks and destination IP for all other attacks.
L4 Port The destination L 4 port (relevant only for

SYN Flood Trigger attacks).
RX Port The physical port on the device through which

the attack enters.
Active Time The number of seconds from the moment the

attack was recognized.
Last Sec SYN The number of SYNs that were recognized in

counter the last second.
Last Sec Verified The number of ACKs that were recognized in

counter the last second.

Table 9-12 Active Triggers Table Parameters
Average SYN counter The average of the SYNs that were

recognized from the moment the attack
began.
Average Verified The average of the ACKs that were

counter recognized from the moment the attack
began.
Total SYN The total number of SYN packets for this

trigger.
Total Dropped The total number of unverified sessions for

sessions this trigger.
To view the Active Triggers Table:

appears.
3. In the Settings pane, click Active Triggers. The Active Triggers
Table appears.
Note: If Application Security or DoS modules are enabled, SYN Flood
Protection events are created.

Protocol Anomalies
Section 9-8 Protocol Anomalies

Section 9-8, Protocol Anomalies, provides information about protection
against the protocol Anomalies.
• Anomalies Introduction, page 9-143.
• Setting Up the Anomalies Module Using Predefined Profiles, page
9-144.
• Defining Anomalies with User-Defined Settings, page 9-145.
• Anti-Scanning, page 9-156.

Anomalies Introduction
To avoid IDS, hackers may use evasion techniques, such as splitting
packets and sending attacks in fragments. An attack that contains
fragmented packets is called a Protocol Anomaly attack. Protocol
Anomaly attacks are detected and blocked using the Protocol Anomaly
Protection mechanism.
Protocol Anomaly attacks are recognized by the packet’s size. In a
Protocol Anomaly attack, the size of the fragmented packets exceeds
the boundaries of the predefined length. Protection against Protocol
Anomaly attacks is achieved by dropping the suspect packets.
HTTP Anomalies
Hackers split the URL across multiple packets. This attack enables
hackers to insert malicious data into the web server.
When the size of the URI packet exceeds the lower boundary of the
predefined length, the packet may contain fragmented URI. When the
size of the URI packet exceeds the higher boundary of the predefined
length, the buffer overflow is indicated.
Protocol Anomalies
The Protocol Anomalies group contains signatures of miscellaneous
protocol misbehaviors. Signatures in this group prevent the usage of
miscellaneous Protocol Anomalies that could indicate a new
exploitation of a protocol vulnerability or a DoS attack.
The Anomalies Module

The Anomalies module provides protection using the following
sub-groups:
• Protocol Anomaly protection
• HTTP Anomaly protection
• MIN fragmented URI packet size parameters
• MAX URI Length parameter

Protocol Anomalies
Setting Up the Anomalies Module Using Predefined Profiles

can use these prevention profiles to define protection policies. Most of
the existing anomalies can be prevented using Radware groups.
Anomalies Configuration Guidelines using Radware-Defined

Attacks:
1. Enable Anomalies (see page 9-145).
2. Configure Protocol Anomaly Protection parameters (see page 9-
16).
3. From the main window, open the APSolute OS menu and select
Security. The Connect & Protect Table window appears.
Anomalies column. The Settings pane appears.
5. In the Anomaly Flood Profiles pane, select the predefined profiles
and apply them to the policy in the Connect & Protect Table.

Defining Anomalies with User-Defined Settings

define prevention profiles using Radware-defined attack groups only.
Anomalies Configuration Guidelines using User-Defined

Attacks:
1. Enable Anomalies (see page 9-145).
2. Configure Protocol Anomaly Protection parameters (see page 9-
16).
3. Define attacks (see page 9-145).
4. Define Attack Groups (see page 9-64).
5. Define Anomaly Flood Prevention Profile and apply it to the
Connect and Protect Table (see page 9-154).

An Attack (Figure 9-3) is a building block of the prevention profile. Each
attack contains one or more protection filters and a mechanism that
determines which packets are malicious and how CID treats those
packets.
the filters. This means that the classification mechanisms of all filters
applied to the same attack are involved in the scanning process, or in
other words, the traffic is checked for all the signatures defined in the
attack’s filters.

Protocol Anomalies

• The "Immediate" type that makes decisions based on a single
indicator for the attack, and the packet is dropped ("Drop All"), for
example, MS Blast.
• The "Threshold" or "Counter" functions, which assume that the
defines a "reasonable" behavior for such traffic. Only packets that
Table 9-13 presents the attack configuration parameters.

30 characters.

Default value: 1000


Default value: 10.

attacks.
Default: Drop All

Protocol Anomalies

Default: Drop

• High
• Medium
• Low
signature.



attack.
be suspended.
be suspended.

Flood attacks.

Protocol Anomalies


Default: Enable.

appears.
4. In the Attack Name field, enter the name of the new attack.
5. Set the attack parameters, as explained in Table 9-13 on
page 146.
7. In the Filter Name field, enter the name of the filter.


11. In the Filter Description field, enter the description of the filter.
12. Click Ok. The Attack Configuration window closes.
Filter Parameters
the custom attack.


Application Port Group window appears.
pane appears.

Protocol Anomalies
Notes:
group.





to false positive are gathered in the unassigned group and can be
user-defined group.

appears.

Protocol Anomalies

4. In the Group Name field, enter the new user-defined name for the
attack group.
5. Select the attacks you want to include in the group and move
them to the Selected Attacks pane by clicking the Add button.
6. Click Ok.
Creating User-Defined Profiles

You can either select from the Radware predefined anomaly prevention
To create a new user-defined anomaly profile:

appears.
3. In the Settings pane, click New Profile. The New Anomaly Profile
window appears.
4. In the Profile Name field, enter a name for your new anomaly
profile and click Ok. The new profile appears in the Anomaly
Flood Profiles pane.
5. In the All Anomaly Attacks pane, select the anomaly attacks that
you want to include in your anomaly profile and move them to the
profile by clicking the Add button.
6. In the Connect & Protect Table, select the policy to which you
want to apply the new anomaly profile and click Apply. The name
of the new profile appears in the selected cell.

Editing Attack Groups
To edit an attack group:

appears.
3. From the All Anomaly Attacks list, select the attack group you
window appears.
page 9-64).

Anti-Scanning
Section 9-9 Anti-Scanning

Section 9-9, Anti-Scanning, provides information on how hackers
perform scanning prior to an attack and how to prevent it.
• Introduction to Anti-Scanning, page 9-157
• Setting Up Anti-Scanning Using Profiles and Groups, page 9-158
• Defining Anti-Scanning with User-Defined Settings, page 9-159

Introduction to Anti-Scanning
Prior to launching an attack, hackers usually try to identify what TCP
and UDP ports are open. An open port represents a service,
application, or backdoor. Open ports that were left open unintentionally
can create a serious security problem. Application Security provides a
mechanism intended to prevent hackers from gaining this information
by blocking and altering server replies sent to the hacker.
Network Scanning
Legitimate traffic is sent to a recipient in order to learn about the system
and the applications, intending to perpetrate future attacks. As the
packets sent by the attacker are legitimate, analyzing the whole flow of
traffic is the only way to detect the scanning.
Anti-Scanning Module
The Anti-Scanning module provides protection against network and
port scanning. The Scanning Tool contains signatures of miscellaneous
network scanning tools. These signatures protect the network from the
scanning tools that attempt to scan your network.

Anti-Scanning
Setting Up Anti-Scanning Using Profiles and Groups

can use these prevention profiles to define protection policies (see
10). In most cases, Radware profiles provide protection against
network and port scanning.
Anti-Scanning Configuration Guidelines using Radware-

Defined Attacks:
1. Enable Anti-Scanning and set the general parameters (see page 9-
13).
appears.
3. In the Connect & Protect Table window, click inside the Anti-
Scanning column. The Settings pane appears.
4. In the Anti-Scanning Profiles pane, select the predefined anti-
scanning profiles and apply them to the policy in the Connect &
Protect Table.

Defining Anti-Scanning with User-Defined Settings

define anti-scanning profiles using Radware-defined attack groups
only.
Anti-Scanning Configuration Guidelines using User-Defined

Attacks:
1. Enable Anti-Scanning and set the general parameters (see page 9-
13).
2. Define attacks (see page 9-49).
3. Define Attack Groups (see page 9-64).
4. Define the Anti-Scanning profile and apply it to the Connect and
Protect Table (see page 9-169).

Anti-Scanning

An Attack (Figure 9-3) is a building block of the anti-scanning profile.
Each attack contains one or more protection filters and a mechanism
that determines which packets are malicious and how CID treats those
packets.
the filters. This means that the classification mechanisms of all filters
applied to the same attack are involved in the scanning process; or in
other words, the traffic is checked for all the signatures defined in the
attack’s filters.
• The "Immediate" type that makes decisions based on a single
indicator for the attack, and the packet is dropped ("Drop All"), for
example, MS Blast.
• The "Threshold" or "Counter" functions, which assume that the
defines "reasonable" behavior for such traffic. Only packets that

Table 9-14 presents attack’s configuration parameters. .

30 characters.

Default value: 1000

Default value: 10.

Anti-Scanning

attacks.
Default: Drop All


Default: Drop

• High
• Medium
• Low
signature.


Anti-Scanning

attack.
be suspended.
be suspended.

Flood attacks.



Default: Enable.

appears.
Anti-Scanning column. The Settings pane appears.
4. In the Attack Name field, enter the name of the new attack.
5. Set the attack parameters, as explained in Table 9-13 on
page 146.

Anti-Scanning

12. Click Ok. The Attack Configuration window closes. The new attack
now appears in the Custom Attack Group window (see page 9-64.
Filter Parameters
the custom attack.


appears.
pane appears.

7. In the Modify pane, click Add. The Edit Application Port Groups
window appears.
8. In the Edit Application Port Groups window, set the following
Notes:
Port and To Port.
group.
9. Click Ok. A new row appears in the Application Port Group table.



Anti-Scanning


to false positive are gathered in the Unassigned group and can be
user-defined group.

appears.


4. In the Group Name field, enter the new user-defined name for the
attack group.
5. From the All Attacks list, select the attacks that you want to
include in the group and move them to the Selected Attacks pane
by clicking Add button.
Creating User-Defined Profiles

You can either select from the Radware predefined anti-scanning
To create a new user-defined anti-scanning profile:

appears.
3. In the Settings pane, click New Profile. The New Anti-Scanning
Profile window appears.
4. In the Profile Name field, enter a name for your new anti-
scanning profile. The new profile appears in the Anti-Scanning
Profiles pane.
5. In the All Anti-Scanning Attacks pane, select the attack groups that
you would like to include in your anti-scanning profile and move
them to the new profile by clicking the Add button.
6. In the Connect & Protect Table window, select the policy to which
you want to apply the new anti-scanning profile and click Apply.
The name of the new profile appears in the selected cell.

Anti-Scanning
Editing Attacks
To edit an attack:
appears.
3. In the All Anti-Scanning Attacks list, select the attack that you
window appears.
page 9-64).

Section 9-10 Session Table

Section 9-10, Session Table, explains how the device’s Session Table
records session information.
• What is the Session Table, page 9-172
• Session Table Lookup Mode, page 9-173
• Configuring the Session Table, page 9-174

Session Table
What is the Session Table

The Session Table records session information and is used in the
following situations:
• To achieve full CID AS4 performance. The Session Table is
required in these cases because of the Application Switch 4
distributed processing architecture. This architecture is based on a
master CPU that takes one decision in each session and a
dedicated network processor for Layer 4-7 acceleration. If the
session is not recorded in the Session Table, the network
processors cannot be activated for this session and the master
CPU has to process all the packets in the session.
• To support stateful features for traffic, such as SYN Protection.
• When bandwidth management Layer 7 policies are applied to traffic
running through the device.

Session Table Lookup Mode

The Session Table Lookup mode indicates what layer of address
information is used to categorize packets in the Session Table.
Note: The Session Table is disabled by default. When SYN Flood
Protection is used, the Session Table must be enabled.
The following modes are supported:
• Full Layer 3: An entry exists in the Session Table for each Source
IP and destination IP combination of packets passing through the
device.
This mode is recommended for higher performance, unless traffic
classification on Layer 4 or 7 is required.
• Full Layer 4: An entry exists in the Session Table for each Source
IP, source port, destination IP, and destination port combination of
packets passing through the device.
This mode is the default mode for the Session Table and is
recommended when traffic classification on Layer 4 or 7 is
required.
Note: Packets must be categorized with the Full Layer 4 Session
Table Lookup mode when SYN Protection is used.
• Layer 4 Dest Port: Enables traffic to be recorded based only on
the TCP/UDP destination port. This mode can be used for CID in
Static Forwarding mode with Application Security and/or DoS
Shield activated. This mode uses minimal Session Table resources
(only one entry for each port that is secured).
Note: To achieve accelerated CID performance, it is recommended
to categorize packets with the Layer 4 Dest Port mode only.

Session Table
Configuring the Session Table

Table 9-15 presents the Session Table parameters.
Table 9-15 Session Table Parameters
Session The amount of time a non-active session is kept in the

Table Aging Session Table (in seconds).
Time
Default value: 100 seconds.
Session On Application Switch 4, the Session Table is enabled

Table Status by default. If the device does not need to provide high
performance for routed or bridged traffic, the Session
Table may be disabled.
Session Indicates what layer of address information is used to

Table categorize packets in the Session Table. The following
Lookup modes are supported:
Mode • Full Layer3: An entry exists in the Session Table
for each Source IP and destination IP combination
of packets passing through the device. This mode is
recommended for higher performance, unless traffic
classification on Layer 4 or 7 is required.
• Full Layer4: An entry exists in the Session Table
for each Source IP, source port, destination IP, and
destination port combination of packets passing
through the device. This mode is the default mode
for the Session Table and is recommended when
traffic classification on Layer 4 or 7 is required.
• L4 Dest Port: Enables traffic to be recorded based
only on the TCP/UDP destination port. This mode
can be used for CID in Static Forwarding mode with
Application Security and/or DoS Shield activated.
This mode uses minimal Session Table resources
(only one entry for each port that is secured).

Table 9-15 Session Table Parameters (cont.)
Remove Removes sessions from the Session Table when the

Session session ends (only valid for Full Layer 4 Lookup mode).
Table Entry Recommended to free resources when the Aging Time
at Session of the Session Table is set at a high value; however, it
End can cause slight performance degradation.
Send Reset Checks whether the Session Table sends a reset

To Server packet to the server if no data is transmitted through the
Status session because it can be a SYN attack.
To configure the Session Table parameters:

2. In the SetUp window, click the Global tab. The Global pane
appears.
3. In the Global pane, select Session Table Settings and click Edit
Settings. The Session Table Settings window appears.
4. In the Session Table Settings window, set the parameters as
explained in Table 9-15 and click Ok.

Evasion Techniques
Section 9-11 Evasion Techniques

Section 9-11, Evasion Techniques, describes how the device provides
protection against evasion techniques in the SSL secured traffic, IP
traffic, and TCP traffic.
• Introduction to Evasion Techniques, page 9-177
• IP Reassembly and Min IP Fragmentation, page 9-178
• TCP Reassembly, page 9-182

Introduction to Evasion Techniques

An Evasion Technique is an attempt to hide the attack that is aimed at
harming your servers or operating system. The hacker that sends
malicious attacks is aware of the protection used in your organization
for specific types of traffic. Therefore, the hacker makes an effort to
bypass your Intrusion Protection System (IPS) or Intrusion Detection
System (IDS). The methods that the hacker uses to avoid the
preventing of attacks with IPS/IDS are called Evasion Techniques.

Evasion Techniques
IP Reassembly and Min IP Fragmentation

CID provides protection against IP traffic evasion techniques.
CID performs signature-based recognition of IP attacks. Signature
lookup is performed on a packet-by-packet basis. Hackers (or a host
operating system) may split an attack over two or more IP fragments
that belong to the same IP packet. The result of this action is the
bypassing of the signature-based detection engine.
Fragmenting of a packet may happen either intentionally by a hacker or
by an application due to Layer 2 MTU constraints. As a result, the IP
signature-based detection engine is bypassed. When used by a
hacker, this technique is called Evasion.
CID enables assembling IP fragments into a complete IP packet and
searching for attack signatures split among two or more IP fragments.
Fragments of an IP packet are assembled until the packet is complete.
The device continues to forward the fragment and only if an attack is
detected, the predefined action is taken. The action is based on the last
fragment received.
IP Reassembly is effective for attack signatures in Intrusions,
Anomalies, Anti-Scanning, and Application Security for DoS.
To provide protection for the fragmented IP traffic, CID uses the
following mechanisms:
• IP Reassembly: CID assembles the IP fragments into a complete
IP packet and looks for attack signatures split among two or more
IP fragments.
• Min IP Fragmentation: CID detects abnormally small IP fragments
and applies a predefined Action mode to them.
There is no report of a specific attack. It is mentioned in the event
that a fragment has been identified as an attack.
Configured
To configure IP fragments:
appears.
2. In the Connect & Protect Table window, click Settings. The

3. In the Security Settings window, click IP Fragments. The IP

Fragments window appears.
4. In the IP Fragments window, set the following parameters
IP Reassembly Status: Enables/Disables the IP Reassembly
feature.
Default value: Disabled.
IP Reassembly aging The maximum period of time, in
time [sec]: seconds, during which CID keeps
fragments of the same IP packet in
case not all the fragments of this
packet have been received yet. After
this period, CID drops the fragments.
Default value: 3.
IP Reassembly Overlap Sets the data overlapping status
status: within IP fragments. Overlapping
may also indicate an attack evasion
technique. The values are:
• Allow: The overlapping is not
identified as an attack, and the IP
packet fragment is forwarded to
its destination.
• Deny: The overlapping is defined
as an attack, and the predefined
IP Reassembly Overlap Action
mode is used to prevent it.
Default value: Allow.

Evasion Techniques
IP Reassembly Overlap The Action mode settings when IP

Action Mode: Reassembly Overlap status is set to
‘Deny’:
• Report Only: The fragment is
forwarded to the defined
destination.
• Drop: The fragment is discarded.
• Reset Source: A TCP-Reset
packet is sent to the packet
source IP.
• Reset Destination: A TCP-
Reset packet is sent to the
destination address.
• Reset Bi-directional: TCP-
Reset packets are sent to both
the packet Source IP and the
Default value: Report Only.
IP Reassembly no The device action when the device
memory Action Mode: lacks memory resources to perform
IP reassembly. Possible values:
• Drop: The packet is discarded.
• Forward: The packet is
destination.
Default value: Forward.

Min IP Fragment Enables/Disables the Min IP

protection status: Fragment protection feature.
Note: There is no dependency
between the IP Reassembly feature
and the Min IP Fragment protection
feature. Min IP Fragment protection
can be enabled when the IP
Reassembly feature is Enabled or
Disabled.
Default value: Disable.
Min IP Fragment Action Action mode settings when Min IP
Mode: Fragment Protection is set to Enable:
• Report Only: The fragment is
destination.
• Drop: The fragment is discarded.
• Reset Source: A TCP-Reset
packet is sent to the packet
source IP.
• Reset Destination: A TCP-
Reset packet is sent to the
destination address.
• Reset Bi-directional: TCP-
Reset packets are sent to both
the packet Source IP and the
Default value: Drop.
MIN Fragment Size: The minimum permitted size of a
fragmented IP packet. A shorter packet
length is treated as an IP protocol
anomaly and is dropped.
Possible values: 1-65535 Bytes.
Default value: 512.

Evasion Techniques
TCP Reassembly
CID detects and prevents TCP traffic evasion techniques. Application
level attacks, such as worms, viruses, Trojans, and buffer overflow,
require deep packet inspection capability in order to be detected while
being transferred over network protocol. As the detection engine is
signature-based, there may be cases where the attack signature is split
among two or more packets within a TCP application flow. In such
cases, the signature detection engine may be bypassed.
To prevent the appearance of application level attacks, CID inspects
Level 7 attack signatures within a TCP stream regardless of the actual
location of the signature in the data stream.
To support Content Type (Level 7) filters, the TCP Reassembly feature
performs protocol parsing according to the content field. For example,
when applying an HTTP URL filter on the traffic, the device extracts the
URI field from each HTTP-GET packet within a TCP session, and
reassembles the specific field over several packets.
TCP Reassembly is effective for attack signatures in Intrusions,
Anomalies, Anti-Scanning, and Application Security for DoS.
TCP Reassembly is applied on TCP data portions and on application
data according to the Content Type in the filter.
Notes:
• The TCP Reassembly feature is supported on SME platforms only.
• TCP Reassembly is performed for consecutive packets only.
When an attack is located, it is reported by name. No indication is
provided whether the attack was detected on a reassembled stream.
The device sends the reassembled datagram as evidence of the attack.
To enable TCP Reassembly:

appears.

3. From the Application Security Parameters area, select TCP

Reassembly Status. The TCP Reassembly feature is enabled.

Security Events and Reports
Section 9-12 Security Events and Reports

Section 9-12, Security Events and Reports, describes security events
and how to configure devices to use reporting channels. In addition,
this section provides information about security reports.
• Events and Event Reporting, page 9-185
• Reporting Channels, page 9-190
• Security Reports, page 9-197

Events and Event Reporting

A security event is an attack or a protocol anomaly. You can configure
each device to alert you whenever a security event takes place.
When an attack is detected, the device creates a security event that
includes the information relevant to this specific attack. Once an event
has been created, the device reports it using several optional channels:
• Security Logs, which are saved in a flash.
• SNMP traps can be sent to APSolute Insite and a management
station.
• Syslog messages can be sent to a Syslog station.
• E-mail messages can be sent to specific users.
• Security Terminal Echo.
Note: You need to enable and configure each reporting channel before
using it.
Enabling Reporting Channels

You can enable the reporting channels used by Radware devices to
receive information about security events. In addition, you can set the
device to report detected attacks according to the various risk levels.
You can get the source/destination IP address information for each
event up to the Reporting Aggregation level. This level is defined by the
Report Aggregation Threshold parameter. The events including source/
destination IP values are indicated with Status field value set to
"Sample."
Note: Counter-based attacks and DoS attacks may have more
occurrences, and the reported IP addresses provide partial information
of the overall picture.
To enable the reporting channels for security reports:

icon and select SetUp. The SetUp window appears.
2. In the SetUp window, click the Global tab. The Global pane
appears.

3. In the Global pane, select Security Settings and click Edit

4. In the Reporting pane, enable the reporting channels that you
want to use by selecting the appropriate checkboxes.
5. In the Reporting Interval text box, type the number of seconds that
defines the frequency at which reports are sent through the
reporting channels.
6. In the Report Aggregation Threshold text box, type the number of
events for a specific attack that are gathered during a Reporting
Interval before the events are aggregated to a report.
Note: When the number of generated events exceeds the Report
Aggregation Threshold value, the IP value of the event appears as
0.0.0.0, which indicates "Any."
7. In the Max Alerts Per Report text box, type the number of alerts
that defines the maximum number of security events that can
appear in each report (sent within the Reporting Interval).
8. To generate reports using risk levels, from the drop-down menus
of the reporting channels, select the levels according to the
High: Report all attacks with risk value set
to High.
Medium: Report all attacks with risk value set
to High or Medium.
Low: Report all attacks with risk value set
to High, Medium, or Low.
Event Parameters
Devices send various types of information about a security event
(attack).

Table 9-16 summarizes the parameters of an event.
Table 9-16 Event Parameters
Risk The attack severity level: high, medium, or

low.
Date/Time The date and time when the report was

generated.
Attack Name The name of the detected attack.
Physical Port The actual port on the device from which the
attack arrived.
Action The reported action can be:

• Forward: The packet is forwarded to its
destination.
• Drop: The packet is discarded.
• Reset Source: Sends a TCP-Reset
packet to the packet source IP.
• Reset Destination: Sends a TCP-Reset
Category The category of the attack: Anomalies, Anti-

Scanning, DOS, Intrusion.
Protocol The transmission protocol used to send the

attack: TCP/UDP/ICMP/IP.
Source Address The IP address from which the attack arrived.
Source Port TCP/UDP source port.
Destination Address The IP address to which the attack is

destined.
Destination Port TCP/UDP destination port.
Radware Attack ID Radware’s unique identifier of the attack.
Packet Count The number of packets in the attack.

Table 9-16 Event Parameters (cont.)
Packet Bandwidth The bandwidth of the attack since the latest

trap was sent (KByte).
Status The current status of the event.

For Intrusions, Anomalies, Anti-Scanning,
SYN Flood attacks, and Application Security
for DoS/DDoS attacks, the following statuses
can appear:
• Occurred: Each packet matched with
signatures is reported as an attack and
must be dropped.
• Started/Terminated: When the number
of packets that match the signatures
exceeds the predefined threshold within
the Tracking Time, the reported Attack
Status is Started. When the number of
packets that match the signatures is
below the predefined threshold, the
reported Attack Status becomes
Terminated.
• Ongoing: The status that reports on the
counterattack within the period of time
when the attack takes place, which is
between Started and Terminated.

Table 9-16 Event Parameters (cont.)
For DoS Shield attacks, the following statuses

can appear:
• Alert: When the number of packets that
match the signatures goes beyond the
predefined Warning Threshold.
• Active: When the number of packets that
predefined Activation Threshold.
• Block: When the number of packets that
predefined Drop Threshold.
• De-al: The Deactivation Alert status is
reported when the attack is about to be
terminated.
• De-ac: The Deactivation status is
reported when the attack is terminated.
Device IP The IP of the device with which the attack is

associated.
VLAN Tag VLAN Tag information, according to which you

can generate reports for each customer by
using the customer's VLAN Tag value. A value
of "0" in this field indicates that the VLAN Tag
is not available.
Note: CID on Application Switch 4 does not
support VLAN Tagging, and a value of "0" is
always set.

Reporting Channels
CID supports the following reporting channels:
• Traps
• Email Traps
• Logs
• Syslog Messages
Sending Traps
Traps can be sent from the device to any computer that you choose.
You must enable the device to send SNMP traps to other computers,
for example to the management station, by defining the computers as
targets.
Trap Notification is set up through the device’s Target Address table.
For example, to ensure that the management station receives traps,
configure its IP address into the Target Address table. You can specify
SNMP parameters and select which type of notification it receives. In
the Community Table, you can designate that specific users are
allowed access to the traps.
Note: After configuring the device to send SNMP traps, enable the
device to start sending traps.
Security Traps Configuration Guidelines:

1. Enable the management station to receive traps:
a. Define access parameters, see page 2-35.
b. Define target addresses, see page 2-42.
c. Specify the type of SNMP notification a target receives, see
page 2-44.
d. Define the target parameters, such as message processing
security level and model, see page 2-41.
e. Optionally, map user names to communities and vice versa
using the SNMP Community Table. This table restricts the
range of addresses from which SNMP requests are accepted
and to which traps may be sent, see page 2-42

2. Enable the device to start sending traps, see page 9-191.

3. View traps at the management station, see page 9-192.
4. Record security traps on the management station, see page 9-
191.
5. Enable traps reporting, see page 9-185.
6. Define the graphical representation of the security reports in
APSolute Insite, refer to the APSolute Insite Guide.
Start Sending Traps

Once you define all the notification and target parameters, enable the
device to start sending traps.
To enable the device to send one trap per event:

1. From the main APSolute Insite window, open the Options menu
and select Preferences. The Management Preferences window
appears.
2. In the Management Preferences window, select the Trap and
SMTP pane. Ensure that you provide the IP address for your
SMTP server.
3. Select One Trap to generate only one trap per event.
To enable the device to send traps:

Security Reporting window appears.
3. In the Application Security Parameters area (at top), ensure that
Traps Sending is enabled. Click Apply to enable.
Recording Security Traps

Once you have configured the device to send traps, Radware Traps
Service records them automatically.

Security traps are recorded in a local database. The information from

the database is used to create Security Reports. Radware Traps
Service continues to record traps until instructed to stop.
To stop recording security traps:

1. Open your computer’s Control Panel (Start > Settings > Control
Panel).
2. Open the Administrative Tools directory.
3. Double-click Services. The Services window appears.
4. In the Services window, right-click Radware Traps Service and
select Stop.
To view traps received by the management station:

1. From the main APSolute Insite window, open the Options menu
and select Events & Traps. The Traps and Events window
appears, displaying the following information:
Trap number: The chronological order number of the trap.
Traps are numbered in the order that they are
generated.
Severity: The trap’s severity level. Trap severity ratings
include, in increasing order of severity:
Informational, Warning, Error, and Fatal.
Date: The date that the trap was generated.
Time: The time that the trap was generated.
Source: The IP address that triggered the trap, for
example, the CID’s IP address.
Information: Description of the trap.
Notes:
• Traps from multiple devices can be viewed simultaneously in the
Events and Traps window.
• You can access trap data related to security events via Security
Reports. Refer to the APSolute Insite User Guide for more on
Security Reports.

Email Traps
E-mail traps can be sent to specific users in a similar manner to the
way in which SNMP traps are sent.
To enable the device to send email traps:

1. From the main window, select Device > Traps and SMTP. The
Traps and SMTP window appears.
2. In the Traps and SMTP window, set the following parameters
Send Emails on Select if you want to send an e-mail alert
Errors: when an operational error occurs at the
device.
One Trap: Generate only one trap per event.
3. In the main window, select APSolute OS > Security. The
5. In the Security Settings window, click the Reporting tab. The
Reporting pane appears.
6. In the Reporting pane, check Email Sending.
7. Click Ok to enable.
Logging
When the device recognizes security events, they are logged in an
all-purpose cyclic Log File. The device’s Log File can be accessed at
any time, but it is limited in size. When the number of entries is beyond
the permitted limit, the oldest entries are overwritten. You are notified
regarding the status of the Log File utilization. The notifications appear
when the file is 80% utilized and 100% utilized.
To start the logging process, configure one or more devices to perform
logging.

To configure a device to perform event logging:

Connect & Protect Table window appears
2. In the Connect and Protect Table window, click Settings. The
Security Parameters windows appears.
3. In the main window, open the APSolute OS menu and select
Security. The Connect & Protect Table window appears.
5. In the Security Settings window, click the Reporting tab. The
Reporting pane appears.
6. In the Reporting pane, check Logging.
7. Click Ok.
Note: Information in the log file can be viewed by downloading it at the
management station into a file.
To download the Log File at the management station:

appears.
2. In the Connect & Protect Table window, click TFTP Log. The
Download Log File window appears.
3. In the File Name field, enter the name you wish to assign to the
file.
4. Click Browse to select the directory where you want to save the
file.
5. Select the External TFTP Server IP Address box to specify the IP
address for an external TFTP server. To use the default TFTP
server, clear the checkbox.
6. Optionally, enable Clear Log File After Receive to clear the log
file once the download is completed.

7. Select one of the options, HTML, Excel, or Advanced, to set the

format for exporting the Log File. If you select Advanced, click
Advanced Settings. The Attack Reports window appears.
8. In the Attack Reports window, select categories by which the
report is filtered:
Attack: The attack that you want to appear in
the report. You can select the attack
from the drop-down list that contains
all the attacks that were recognized
by the device. If the Attack checkbox
is not selected, the report includes all
the attacks.
Source IP: The range of Source IPs from which
the attacks arrived that you want to
appear in the report.
Destination IP: The range of Destination IPs to
which the attacks are targeted that
you want to appear in the report.
Attack Date: The range of dates in which the
attacks were recognized by the
device.
9. From the Select Fields section, select the checkboxes to define
fields displayed in the report.
10. Click Create Top 10 Graph and choose an item from the drop-
down list to create a graph of the 10 most frequently mentioned
items in the report.
11. Click Ok to close the Attacks Reports window.
12. Click Receive. The Log File is downloaded, and the status of the
download is displayed.
Tip: You can access logged security events via Security Reports (see
Security Reports, page 9-197).

Syslog Messages
Syslog messages can be sent to a syslog station in a similar manner to
the way SNMP traps are sent.
To configure the device to send syslog messages:

1. From the main APSolute Insite window, open the Device menu and
select Traps and SMTP. The Traps and SMTP window appears.
2. In the Syslog Reporting area, enter the IP address of the device
running the syslog service (syslog) in the Syslog Station Address
field.
3. Select the Syslog Operation checkbox to enable syslog
reporting.
4. Click Ok.

Security Reports
Security Reports enable reporting capabilities, such as user-defined
Reports, Geographical Security Map, Multi Device Dashboard,
enhanced data management in the Attack Log, as well as data
correlation capabilities between the Security Reports and Attacks Log.
The reports are presented by graphs, views, and tools, which enable
you to understand attack activity and its impact on your network. You
can view attack activity over time, types of attacks, the attack risk level,
attack bandwidth, and attack sources and destinations.
The Security Reporting module allows you to view filters and create
predefined/user-defined reports, as well as a unified filtering and
reporting mechanism. Each view filter can be defined by the user and
can be used for both the Events Log and Reports view. In addition, the
predefined reports list is used for both the Events Log and Reports
view. For example, you can display a Top 10 Attacks report in the
Events Log, and switch to the Reports view to see the relevant
information in a graphical view. The same information is displayed in
two different views. You can also choose to apply a viewing filter in the
Reports view and then switch to Attacks Log to display the information
after the filtering process.
The Security Reporting module allows you to view information in eight
different views, including:
• Dashboard View: Displays the Security Radar and dashboard pie
charts.
• Attacks Log View: Displays the Attacks Event log, including all
trap parameters.
• Reports View: Displays the different Security Reports in a
graphical view (bar, plot, and so on).
• Geographical Map: Displays a geographical map of the world with
indications of the sources of attacks.
• Attacks Log and Reports Split View: Displays both the Attacks
Log and Reports in a split screen view. The applied view filters
affect both simultaneously.
• Attacks Log and Packet Data View: Displays both the Attacks
Log and Packet Capture Data in a split screen view.

• Attacks Log and Attack Description View: Displays both the

Attacks Log and Attack Description in a split screen view.
• Attacks Log and Attack Information View: Displays the Attacks
Log, Attack Description, and Packet Data in a split screen view.
For detailed information on Security Reports, refer to the APSolute
Insite User Guide.
How Data Is Gathered

You must initially select a device, or group of devices, in order to
generate data for the reports. The devices monitor attack activity. When
the device detects an attack, the security model logs data about a
“security event.” A security event fits predefined attack profiles.
Once reporting channels are configured, the device starts sending
information about security events to the management station via SNMP
Traps. The management station (running APSolute Insite) stores the
security event data and packet information in a local database. This
information is then used to create Security Reports that provide the
information about the security events.
Security Monitoring Tools

Each of the monitoring tools focuses on different types of analysis
requirements. Each view filter can be used for both the Attacks Log and
Attack Reports views. In addition, the predefined reports list is used for
both the Attacks Log and Attack Reports views. For example, you can
display a Top 10 Attacks report in the Attacks Log, and switch to the
Attack Reports view to see the same information in a graphical view.

CHAPTER 10
Application Switching
Platforms
Chapter 10 - provides an explanation of Radwares Application
Swithching Platforms, Device Interfaces, list of specifications, Serial
Cable Pin Assignment and a trouble shooting section.
• Section 10-1: Introduction to Intelligent Application Switches, page
10-2.
• Section 10-2: Physical Description, page 10-11
• Section 10-3: Device Installation, page 10-26
• Section 10-4: Device Interfaces, page 10-31
• Section 10-5: Specifications, page 10-37
• Section 10-6: Serial Cable Pin Assignment, page 10-44
• Section 10-7: Trouble Shooting., page 10-46
CID User Guide 10-1

Introduction to Intelligent Application Switches
Section 10-1 Introduction to Intelligent

Application Switches
Each Radware device is built on top of Radware’s Intelligent
Application Switching Architecture combining high speed hardware
processing power with SynApps Application Aware Services for total IP
Application performance across layers 4-7.
Radware’s Application Switching Platforms consist of the following
Application Switches:
• Application Switch 1, page 10-3
10-2 CID User Guide

Chapter 10 - Application Switching Platforms
Application Switch 1
Figure 10-1 Application Switch 1
Application Switch 1 (Figure 10-1) combines ASIC-based switching,

CPU processing power and APSolute OS 'Application Aware' Services
to deliver performance and service to address all IP application
requirements across network layers 4-7. Designed to guarantee
application availability, security and performance, Application Switch 1
is the first platform to bridge the gap between your IT infrastructure and
IP Applications for comprehensive control of all critical operations
across the enterprise.
Wire Speed Forwarding and Central Processing Power

With switching ASICs on the port levels, Application Switch 1, ensures
wire speed forwarding speeds across the 2 Gigabit and/or 8 Fast
Ethernet ports available in the 1U device. Layer 3 -7 operations are
powered by the Motorola PowerPC 755 central processing unit,
powering APSolute OS application services for optimized resource
utilization and maximum application performance.
CID User Guide 10-3

Application Switch 2 (Figure 10-2) enables wire speed forwarding

across 5 GBIC ports and 16 Fast Ethernet Ports or 7 GBIC ports, non-
blocking traffic throughputs across a 19.2 GB backplane and strong
central processing, based on a Motorola PowerPC 7410 CPU. Fusing
accelerated processing speeds with the ability to optimize routing
decisions based on specific applications, web requests and content,
Application Switch 2 guarantees complete reliability, performance and
security across all IP applications, for complete control over enterprise
operations.
Application Switch 2 is powered by a multi-layered switching
architecture combined with comprehensive APSolute OS 'Application
Aware' services, to address the widest set of protocols and service
requirements across network layers 4-7, boosting IP application
performance to Gigabit Speeds.
10-4 CID User Guide

Application Switch 3 (Figure 10-3) provides an innovative three-tiered

architecture that couples enhanced performance and power with 10Gb
connectivity, providing for the first time businesses with a
comprehensive solution for ensuring the integrity of applications carried
over high-bandwidth networks. Application Switch 3 delivers APSolute
OS security, availability and reliability of services at multi-gigabit
speeds, bullet-proofing any IP or Web Service application running on
the network.
Multi-Gigabit Switching Architecture

Driving Intelligent Application Switching performance to up to 3-Gigabit
speeds, AS3 affords complete control over mission critical applications
and explosive transactions across the most demanding networking
environments.
Application Switch 3 features 44Gb connectivity and multi-Gigabit
network processors.
CID User Guide 10-5

Application Switch 4 (Figure 10-4) provides 44 Gbps Switching Fabric

and High Port Density. Application Switch 4 non-blocking 44 Gigabit
switching is based on a multi-layered distributed switching architecture
using switching ASICs that ensures wire speed switching for the 8 -
1Gigabit ports (GBICs) and 12 copper 1Gigabit ports.
Main CPU – RISC Processor

Application Switch 4 RISC processor Motorola PPC 7457 1.3GHz, is
the fastest processor in the market. It allows execution of health checks
at short intervals, performance of complex layer 7 switching algorithms
10-6 CID User Guide

and to conduct management tasks without any degradation of the

device performance.
In Application Switch 4, 3-tier processing architecture, all layer 4-7
packet processing is performed by the network processors. This
parallel processing allows the RISC processor to perform complex
layer 7 algorithms without affecting or being affected by the volumes of
traffic forwarded by the network processors. This revolutionary
architecture provides Application Switch 4 with the strongest
processing power for layer 7 switching.
State of the Art Network Processors

The two network processors designed specifically to handle sessions/
packets, work in parallel and are capable of processing multiple
packets simultaneously to provide accelerated layer 4-7 switching
speed, handling all tasks related to packet processing and traffic
forwarding.
Radware StringMatch Engine - Dedicated ASIC Based

Security Hardware Accelerator
Radware StringMatch Engine is a dedicated hardware card designed
specifically to provide accelerated deep packet inspection and attack's
signature matching. The StringMatch Engine consists of up to 8 ASICs
enabling 256,000 parallel string searches and a high end Power PC
RISC processor for scheduling and running the parallel search
algorithms. The StringMatch engine provides 9 Gigabit of free-range
searches and 16 Gigabit of fixed offset searches for unmatched
performance.
Dual Power Supplies

Application Switch 4 can be ordered with hot swappable dual active-
active AC or DC power supplies, which provide higher level of
redundancy which is often required by high end enterprises, carriers
and data centers.
Application Switch 4 software constantly checks the status of each
CID User Guide 10-7

power supply and sends a trap to APSolute Insight management

application if any type of failure is detected.
Note: In order to add an additional PS simply plug the additional power
supply to its correct location and it will begin to work immedeatly. In
order for the application to recognise the secondary supply (so that the
application is able to check the status of the power supply and notify in
cases of failures) DIP Switch number 8 should be toggled. When DIP
Switch 8 is up, this means there is a single PS. When DIP Switch 8 is
down, this means that there are two PS.
10-8 CID User Guide

Application Switch 5 (Figure 10-5) provides 74 Gbps switching with

high port density. Application Switch 5 non-blocking switch is based on
a multi-layered distributed switching architecture using switching ASICs
that ensures wire speed switching for the 2 10G ports, 9 Gigabit ports
(SFP) and 8 copper 1Gigabit ports.
Main CPU Processor

Application Switch 5 RISC processor Motorola PPC 7457 1.7GHz, is
the fastest processor in the market. It allows execution of health checks
at short intervals, performance of complex layer 7 switching algorithms
and to conduct management tasks without any degradation of the
device performance.
In Application Switch 5, 3-tier processing architecture, all layer 4-7
packet processing is performed by the four network processors. This
parallel processing allows the RISC processor to perform complex
layer 7 algorithms without affecting or being affected by the volumes of
traffic forwarded by the network processors. This revolutionary
architecture provides Application Switch 5 with the strongest
processing power for layer 7 switching.
CID User Guide 10-9

State of the Art Network Processors

Four network processors are designed specifically to handle sessions /
packets, work in parallel and are capable of processing multiple
packets simultaneously to provide accelerated layer 4-7 switching
speed, handling all tasks related to packet processing and traffic
forwarding. Employing the Network processors allows fast forwarding
of packets and reducing the load from the master CPU processors and
by that, allowing the master CPU to process only the L4-7 decisions.
Dual Power Supplies

Application Switch 5 can be ordered with hot swappable dual active-
active AC or DC power supplies, which provide higher level of
redundancy which is often required by high end enterprises, carriers
and data centers.
Application Switch 5 software constantly checks the status of each
power supply and sends a trap to Configware Insight management
application if any type of failure is detected.
Note: In order to add an additional PS simply plug the additional power
supply to its correct location and it will begin to work immedeatly. In
order for the application to recognise the secondary supply (so that the
application is able to check the status of the power supply and notify in
cases of failures) DIP Switch number 8 should be toggled. When DIP
Switch 8 is up, this means there is a single PS. When DIP Switch 8 is
down, this means that there are two PS.

Section 10-2 Physical Description

Section 10-2, Physical Description, is designed to get the user familiar
with the devices and provides instructions on the installation procedure
as well as offering an explanation of how to configure the device IP
Host Parameters.
• Application Switches Physical Description, page 10-12

Physical Description
Application Switches Physical Description

The Application Switches Physical Description, includes a diagram of
each device including a description of the devices features.

Figure 10-6 Application Switch 1 - Front Panel View
Table 1: AS 1 Front Panel Description
Feature Description
Reset: Allows you to reset the device
Mode: Allows you to change the display

mode of the Port LEDs.
Upper The upper LED indicates that the

LED: device is powered.
Lower The lower LED indicates that the
LED: application is currently running.
This LED is off when the application
is still loading or has failed.

Feature Description
This display indicates the display mode of the
Port LEDs as follows: From top line, left to right:
Mode Indication
LNK: LNK - Link Status
FE: Ethernet Mode (for fast ethernet
ports only)
COL: Collisions
ERR: Errors
ACT: ACTIVITY
FD: Duplex Mode
TX: Transmission Activity
RX: Receiving Activity
RS-232C Console Port
Gigabit Ethernet Port and LED. The LED indi-

cates the following information according to dis-
play mode.
Mode Indication
LNK On - Physical connection detected
Off - No physical connection
detected.
ACT Flashing indicates that data is being
transferred via the port.

Feature Description
Mode Indication
FD: On - Indicates Full Duplex mode.
Off - Indicates half Duplex mode.
COL: On - Indicates collisions are occur-
ring
ERR On - indicates errors are occurring.
TX Flashing indicates that the port is
transmitting data
RX Flashing indicates that the port is
receiving data.
The status LEDs for the 8 fast Ethernet Ports
Table 2: AS 1 - Back Panel Description
Feature Description
Power Socket The socket to which the power cable is connected
Power Switch On / Off power

Act Boot DipSwitch 1 (First left) this switch determines the
active boot on the device.
Switch “Down” Boot 1 is active.
Switch “Up” means Boot 2 is active

Figure 10-7 Application Switch 2 - Front Panel
Feature Description
These LEDs indicate the status of the following:
PWR: The device is powered.
SYS: The application is currently running. This
LED is off when the application is still loading or
has failed.
FAN: When lit, indicates that the fans are not
operational.
RST: Reset button.
Gigabit Ethernet Port (1-5) and LED. The LED
indicates the following information:
Upper LED:
On - Physical connection detected.
Off - No physical connection detected.
Middle LED:
Lit Green - Port is receiving data.
Lit Red - Receive loss or no physical connection
Lower LED:
Lit Green - Port is transmitting data
Lit Red - Transmission faults

Feature Description
Mode: Allows you to change the display mode of
the Fast Ethernet Port LEDs.
The LEDs indicate the display mode of the Fast

Ethernet Ports.
LNK - Link Status
ACT - Activity
FE - Ethernet Mode
FD - Duplex Mode
The Status LEDs for the Fast Ethernet Ports.
Each Port LED indicates the following information
according to display mode.
Mode Indication
LNK On - Physical connection detected.
ACT Flashing indicates that data is being
transferred via the port.
FE On - Indicates 100BaseT mode.
Off - Indicates 10BaseT mode.
FD On - Indicates Full Duplex mode.
Off - Indicates half Duplex mode.
Fast Ethernet Ports F1-F16
Reset: Resets the device.

Table 4: AS 2 Back Panel Description
Feature Description
Act Boot DipSwitch 1 (First left) this switch determines the
active boot on the device.
Switch “Down” Boot 1 is active.
Switch “Up” Boot 2 is active
RS-232C RS-232C Console Port for out-of-band manage-
ment
Compact Flash Insertion point for Compact Flash Card

Figure 10-8 Application Switch 3 - Front Panel View
Feature Description
These LEDs indicate the status of the following:
PWR: The device is powered.
SYS: The application is currently running. This
LED is off when the application is still loading or
has failed.
FAN: When lit, indicates that the fans are not
operational.
RST: Reset button
The 10 Gigabit Ethernet Port and LEDs. The
LED indicates the following information:
Upper LED:
On - Physical connection detected.
Middle LED:
Lit Green - Port is receiving data.
Lower LED:

Feature Description
Gigabit Ethernet Ports (G1-G8) and LEDs. The
Upper LED:
On - Physical connection detected
Off - No physical connection detected
Middle LED:
Lit Green - Port is receiving data
Lower LED:
Fast Ethernet Ports (F1-F16) and LEDs
Left LED:
Lit green - Indicates 100BaseT mode.
Flashing green - Indicates that data is being
transferred via the port in 100BaseT mode
Lit Yellow - Indicates 10BaseT mode
Flashing yellow - Indicates that data is being
Off indicates no link.
Feature Description

Feature Description
Act Boot DipSwitch 1 (First left) this switch forces the
device to use the internal flash application version
after a reboot has occurred.
Switch “Down” device reboots from compact flash
(default).
Switch “Up” device reboots from internal flash.
ment.
Compact Flash Insertion point for Compact Flash Card.

Figure 10-9 Application Switch 4 Front Panel View
Feature Description
When the LED is illuminated this indicates that
the port is connected.
When the LED is flashing this indicates that there
is activity on this port.
Fast Ethernet Ports (F1-F16) and LEDs
Left LED:
Lit green - Indicates 100BaseT mode.
Flashing green - Indicates that data is being
Lit Yellow - Indicates 10BaseT mode
Flashing yellow - Indicates that data is being
Off indicates no link.

Feature Description
On the Copper ports – G1 to G12 you have two
LEDs on each port. The left LED indicated Link/
Activity or No Link and the right LED indicated the
speed on the port.
Feature Description
(default).
ment.
Ethernet Port Ethernet Port (for debugging purposes only -
Radware R&D only).

Figure 10-10 Application Switch 5 Front Panel View
Feature Description
Gigabit Ethernet Ports (XG-1 / XG-2) and LEDs.
The LED indicates the following information:

On the Copper ports – G1 to G12 you have two

LEDs on each port. The left LED indicated Link/
Activity or No Link and the right LED indicated the
speed on the port.

Feature Description
Feature Description
(default).
ment.
Ethernet Port Ethernet Port (for debugging purposes only -
Radware R&D only).

Device Installation
Section 10-3 Device Installation

Section 10-3, Device Installation, explains the process of Installation
including checking the contents, mounting the device and connecting
the device to your network.
• Checking the Contents, page 10-27
• Mounting the Device, page 10-28
• Connecting the Device to Your Network, page 10-29

Checking the Contents

Before beginning the hardware installation, open the box and check
that the following components are included:
• Radware device.
• APSolute Insite Software CD ROM.
• One power cable (only for countries using 110v power supply).
• One serial cable.
• Two cross cables (Application Switching I and Application Switch 2
platforms only).
• A set of monitoring brackets.
Note: If any of the above items are missing please consult your
Radware agent.

Device Installation
Mounting the Device

Radware’s devices can be either rack-mounted or mounted on a
tabletop. The package includes brackets to enable rack-mounting of
the device. Rubber feet are attached to the bottom of the device to
enable tabletop mounting.
Note: After mounting the device, ensure that there is sufficient airflow
surrounding the device
To rack-mount the device:

1. Attach one bracket to each side of the device, using the screws
provided.
2. Attach the device to the rack with the mounting screws.
Note: For Compact Application Switch a separate rack mountable
tray must be ordered from Radware,

Connecting the Device to Your Network

After you have mounted the device, connect the cables.
To connect the device the following connections must be completed in
the following order:
1. AC Power Connection
2. ASCII Terminal (Serial) Connection
3. LAN Connections
To connect the AC power connection:

1. Connect the power cable to the main socket, located on the rear
panel of the device.
2. Connect the power cable to the grounded AC outlet.
To make the ASCII terminal connection:

1. Connect the serial port connector the front panel.
2. Connect the other end of the serial port connector cable to your
computer.
3. Access Hyper Terminal.
4. From the Hyper Terminal opening window, select the File menu,
then Properties
Or
Click the Properties icon from the toolbar. The New Connection
Properties dialog box is displayed.
5. Click Configure. The Properties dialog box containing the Port
Settings tab is displayed.
6. Verify that the parameters are set as follows:
Bits per second: 19200
Data bits: 8
Parity: None
Stop bits: 1
Flow Control: None

Device Installation
7. Turn on the power to the unit. When the device is connected and
operating properly, the PWR and System Ok indicators on the front
panel are lit continuously.
LAN Connections
The cables used for LAN Connections differ as follows:
Fast Ethernet Port: Standard UTP or STP Ethernet
cable, RJ45 connector.
Gigabit Ethernet Port: 1000BaseSX fiber optic cable - SC
connector.
10 Gigabit Ethernet 10 GBaseLR fiber optic cable.
Port:
Note: ASl version 2 and ASll can use both cross and straight cables
when Auto Negotiation is enabled.
To connect a device port to a LAN:

1. Connect the cable to the port interface, located on the front panel.
2. Connect the other end of the cable to the LAN switch.

Section 10-4 Device Interfaces

Section 10-4, Device Interfaces, provides an explanation of the device
interfaces and how to configure them.
• Interfaces - Introduction, page 10-32

Device Interfaces
Interfaces - Introduction
Radware Application Switch platforms may have as few as 8 network
interfaces and as many as 24. It is helpful to understand interface-
indexing conventions before you perform configuration tasks such as
displaying interface status and setting physical parameters (such as
speed, duplex mode or auto-negotiation) via the command line
interface (in web-based management and Insite interface description
makes it easier to understand interface-index convention).
Note: On the back of the device there is an ethernet port. This port is
for R&D debugging purposes only. It has no other use.
Interface Numbering Conventions

By convention, the numbering of the Ethernet interfaces on each
platform starts with the Fast Ethernet ports, then Gigabit Ethernet ports
and last the 10 Gigabit Ethernet port, if present. Within the different port
types, numbering is left-to-right. If there are no Fast Ethernet ports,
numbering starts with the Gigabit Ethernet ports, for Example:
• On an Application Switch 2 platform with 16FE and 5GE ports,
interface index for the FE ports is 1 to 16, for the GE ports is 17 to
21.
• On an Application Switch 2 platform with 7GE ports, interface index
for the GE ports is 1 to 7.
Displaying Interface Status and Properties

The status and settings for interfaces can be viewed via all
management tools:
To display the interfaces:

• From the CLI use the command:
net l2-interface
• From Web-Based Management click on Device menu and choose
L2 Interface option.

• From APSolute Insite right-click on device and select the Zoom In

option. A graphic representation of the device front panel will be
displayed. Operational status of the interfaces is displayed
graphically (green for up and red for down). To view more
information about each interface right-click on desired interface and
choose Interface Parameters.
To display current settings for the interfaces:

• From the CLI use the following command
net physical-interface
• From Web-Based Management click on the Device menu and
choose the Physical Interface option.
• From APSolute Insite right-click on Device and select the Zoom In
option. A graphic representation of the device front panel will be
displayed. To view the settings of each interface right-click on
desired interface and choose Physical Settings.
Setting Interface Properties

Properties that are configurable on the interfaces include:
• Auto-negotiation mode.
• Port Speed (available only when Auto negotiation mode is off).
• Duplex mode (available only when Auto negotiation mode is off).
To set interface properties:

• From the Command Line Interface use the following command:
net physical-interface set <port index> <-switch
value>
where switch can have the following values:
• -a for auto negotiation (1=On, 2=Off)
• -s for speed (1=10Mbps, 2=100Mbps, 3=1000Gbps) -
(this parameter cannot be changed for Gigabit Ethernet ports).
• -d for duplex mode (1=Half, 2=Full)

Device Interfaces
• From Web-Based Management click on Device menu and select

the Physical Interface option. Click on the interface whose
properties you wish to change. Perform changes and click Set.
• From APSolute Insite right-click on the device and select the Zoom
In option. A graphic representation of the device front panel will be
displayed. To change the settings of an interface right-click on
desired interface and choose Physical Settings. Change
parameters and click Ok.
Boot Version Update

As Radware's product line develops, it may become necessary to
upgrade a device's Boot Code to support new firmware. Check Boot
Prom matrix: http://www.radware.com/content/support/software/
bootprom/default.asp for more information regarding boot code
compatibility with older firmware versions and configurations.
Radware application switch units are supplied with two boot PROMs,
only one of which is used for the active boot process. The second
PROM can be flash upgraded through the CLI only to a newer version.
Once the process is completed, you can configure the device to boot
from the secondary PROM (the one with the new boot code) using a
DIP switch. The information below provides the steps for upgrading
and switching a device's boot code.
On Application Switch 1, whenever a new boot version is required you
must update it manually prior to downloading the new software version.
On Application Switch 2 and Application Switch 3 new boot version are
updated automatically during the software download process - if the
new software version includes new boot version. For Application
Switch 2 you will be prompted to change the position of the dip-switch
that defines which boot is used.
To upgrade the Boot version manually:
1. Obtain the file with the new boot version from Radware Technical
Support.
2. Reboot the device, press any key to stop the auto boot. Type "u"
to download new boot version. The following message appears:

>u
port ( "com1", "com2" or Enter to choose the default ("com1")):
com1
baud rate (valid baudrate) or Enter to choose the current: 19200
Please download program using XMODEM.

For port use: "com1".
3. Send the new boot file to the device using the Xmodem protocol.
The new boot version is written into the non-active boot.
4. In order to boot the device with the existing boot, type "@" when
prompted with
"Download completed
boot flash address 0x1c000000
boot flash number 0 update done.
>"
5. In order to start using the non-active boot, the position of the Dip-
switch needs to be changed (Application Switches I and II only).
Before changing the position of the dip-switch turn the power off.
Locating the active boot selection switch:
• Devices with an external Dip-switch at the rear of the device:
Looking at the rear panel of the device, the boot selection
switch is the first switch from the left and is labeled "Act. Boot"
and with the number "1."
• Devices with internal DIP switch: The device has to be powered
off and opened up to access the Dip-switch. Looking at the rear
of the open device, the switch for the boot selection is located
above the right corner of the power supply. The active boot
selection switch is the first switch from the left of the eight
switches, labeled with the number "1."
The Application Switch platform has two boot EPROMs,
labeled "Boot1" and "Boot2". With the switch in the down
position, which is the default position, the device uses Boot1.
Changing the switch to the up position, sets the device to use
Boot2.

Device Interfaces
6. After the dip-switch position is changed, turn the power on.

Note: On Compact Application Switch, whenever a new boot
version is required you must replace the boot EPROM prior to
downloading the new software version - see CAS Boot EPROM
Replacement document (http://www.radware.com/content/
document.asp?_v=about&document=3961).

Section 10-5 Specifications

Section 10-5, Specifications, includes a table which provides the
specifications for Application Switching Platforms.
• Specification Table, page 10-38
• Gigabit Ethernet Specifications, page 10-42

Specifications
Specification Table
AS4
Feature AS1 AS2 AS3 A5
System
Architecture Two - Tier Two - Tier Three - Three - Tier Three -

Tier Tier
Backplane 9.6Gbps 19.2Gbps 44Gbps
Memory
Flash 16MB 8MB 8MB 8MB internal + 64MB 8MB

Internal internal + internal + compact flash internal +
16MB 32MB 64MB
compact compact compact
flash flash flash
RAM 128- 128- 256- Master NP

256MB 256MB 512MB +
512 or 512 512 or 512
512-
or 1024 or or 1024 or
1024MB
1024 1024
1024 mb
2048 mb
for
network
processor
s
Network Interfaces
Fast Ethernet 8 or none 16 or 16 12 (10/100/100) copper 8x10/100/

(10/ none ports 1000
100BaseT)

AS4
Gigabit 2 or none 5 or 7 7 (SFP - 8 (SFP - fiber optic or 9 SFP

Ethernet (SFP - (GBIC - fiber optic copper)
fiber optic fiber optic or
or or copper)
copper) copper)
10 Gigabit none none 1 (optical None 2 XFP

Ethernet module)
Out of Band 9-pin 9-pin 9-pin 9-pin female RS-232 9-pin

Management female female female connector female RS-
RS-232 RS-232 RS-232 232
DCE Setup: 19200 bps, 8
connector connector connector connector
bits, one stop bit, no parity.
DCE DCE DCE DCE
Setup: Setup: Setup: Setup:
19200 19200 19200 19200 bps,
bps, 8 bps, 8 bps, 8 8 bits, one
bits, one bits, one bits, one stop bit, no
stop bit, stop bit, stop bit, parity.
no parity. no parity. no parity.
Power
Power Supply Auto- Auto- Auto- Auto-range Auto-range
range range range
100v- 240v 100v- 240v
90v - 90v - 90v -
50-60Hz single or dual 50-60Hz
264v 264v 264v
power supply single or
50-60Hz 50-60Hz 50-60Hz dual power
Or
single or single or supply
Or
dual dual 38-72VDC
Or
38- power power
supply supply single / double
72VDC 38-72VDC
Or single /
double
38-
72VDC
single /
double

Specifications
AS4
Power 35Watt 44Watt 60Watt 78 Watt without SME 110.8 Watt

consumption
59Watt 105Watt 108 Watt with SME
(with (with
String String
Match) Match)
Heat 157.08 150.27 204.86 45 BTU/h 378.32

dissipation BTU/h BTU/h BTU/h BTU\h
201.45 358.51
BTU/h BTU/h
(with (with
String String
Match) Match)
Dimensions
Width 432 mm 432 mm 432 mm 432 mm 440 mm
Depth 475 mm 455 mm 485 mm 485 mm 486 mm
Height 44 mm 44 mm 44 mm 88 mm 88 mm
(1U) (1U) (1U)
88 mm 88 mm
(2U) for (2U) for
dual dual
power power
supply supply
Weigh 3.85 kg 5.3 kg 7 kg 0.5 kg 6.6 kg (with

dual power
supply)
Environmental

AS4
Operating 0-40C 0-40C 0-40C 0-40C 0-40C

Temperature
Humidity 20% to 20% to 20% to 20% to 80% 20% to

(non- 80% 80% 80% 80%
condensing)
Certifications
Safety EN 60950 EN 60950 EN 60950 EN 60950 EN 60950

UL 1950 UL 1950 UL 1950 UL 1950 UL 1950
CSA 22.2 CSA 22.2 CSA 22.2 CSA 22.2 No. 950 CSA 22.2
No. 950 No. 950 No. 950 No. 950
Electromagne EN EN EN EN 55022, class A EN 55022,

tic Emission 55022, 55022, 55022, class B
EN 55024
class A class B class A
EN 55024
FCC, part 15B, class A
EN 55024 EN 55024 EN 55024
FCC, part
FCC, part FCC, part FCC, part 15B, class
15B, 15B, 15B, B
class A class B class A

Specifications
Gigabit Ethernet Specifications
GBICs supported in AS1

1000Base-LX (Single-Mode)
Finisar
• FTRJ-1319P1BNL
1000Base-SX (Multi-Mode)
Agilent
• HFBR-5710LP
Finisar
• FTRJ-8519P1BNL

Finisar
• FTR-1319-3D
Stratos Lightwave
• MGBC-20-4-1-SV
Finisar
• FTR-8519-3D
1000BaseT
3.3V
DLink
• DGS-711

5V
Finisar
• FCM-8520-3
Note: There are two revisions of Application Switch 2. Revision 4
requires 5v Gbics and revision 3 requires 3.3v Gbics. Revision 4 can
be identified by the title “CN2” on the label on the back panel of the
device, and revision 3 has the title “CN1”.

Finisar
• FTRJ-1319P1BNL
Agilent
• HFBR-5710LP
Finisar
• FTRJ-8519P1BNL
1000BaseT
dataMate
• DM7041-L

Serial Cable Pin Assignment
Section 10-6 Serial Cable Pin Assignment

Section 10-6, Serial Cable Pin Assignment, provides a PC Serial Port
to Radware Device Pinout table.

Table 10-1 PC Serial Port to Radware Device Pinout
Standard PC DB9 DB9F to DB9M Straight Cable Radware Device

Serial Port (DTE) ASCII Port (DCE)
Signal DB9M DB9F Directio DB9M DB9F Signal

Pin Pin n Pin Pin
CD 1 1 - 1 - -
RxD 2 2 2 2 RxD
TxD 3 3 3 3 TxD
DTR 4 4 - 4 - -
GND 5 5 - 5 5 GND
DSR 6 6 - 6 - -
RTS 7 7 - 7 - -
CTS 8 8 - 8 - -
RI 9 9 - 9 - -

Trouble Shooting.
Section 10-7 Trouble Shooting.

Section 10-7, Trouble Shooting.,provides Hardware Troubleshooting .
Note: Most cases of suspected hardware problems are usually
incorrectly identified and may be software related.
Table 10-2 Trouble Shooting
Problem Possible Solution Outcome
After powering up the Check the following:· If all the previously

device the power LED described requirements
• Verify that the
remains unlit. are met and the device
power lead is
power LED remains
correctly connected
unlit, please contact
to the mains supply
Radware Technical
and to the device.·
Support.
• Ensure that the On/
Off switch located
on the back panel
of the device is in
the On position.
The device Power LED • Check that the If the problem persists,
is lit, however the there serial cable is please contact Radware
is no console response. properly connected Technical Support.
to the device.
• Check that the
serial port
parameters,
including speed,
are correctly
configured.

The Device LEDs are lit Connect to device serial If the problem persists,
however the device port and open terminal please contact Radware
does not communicate connection. If fatal error Technical Support.
via the LAN ports. messages appear on
the terminal and no
product prompt appears
this indicates an
incomplete boot
process.The following
process should be
implemented to
eliminate possible
causes:
1. Stop during boot
countdown and
erase configuration
(q1 command)
2. Reboot ("@") and
fill in connectivity
data (IP address) in
Startup
Configuration
window.Should the
problem persist,
check in the
release notes if the
product matches
the running boot
version. If not,
update boot .
AS2 Flash This indicates a Contact Radware

Management.If during possible problem with Technical Support.
the boot process the Flash Management
following message
appears in the console
window: FATAL
ERROR: tRootTask:
RSFLEG_write: is failed

Trouble Shooting.
Boot upgrade failure· In this event implement In the event a “Write

• If after the boot the following steps: Protection Error”
upload is complete 1. Change the appears again, contact
(via XModem) a position of dip- Radware Technical
write protection switch #1 ) Support.
error message 2. Upload the boot
appears on the image again.
ASCII terminal.
• If after a successful Verify that dip-switch # 1 If the correct dip-switch

boot image upload was moved (not # 8 by was moved, this
and change of the mistake) indicates dip-switch
dip-switch # 1 failure. Please contact
position, followed Radware Technical
by reboot, the Support.
device still boots up
with the older
version
Device Port In this event check the If the problem still

Communication failure.If following: occurs please contact
the device fails to 1. Check that correct Radware Technical
communicate through cable was used. support.
one or more of its LAN 2. Verify that the
ports. correct speed and
duplex mode is
configured on both
Radware device
and the device
connected to its
ports.
3. Change the
configuration of the
ports on Radware
device or
connected device,
or both.To change
port settings.


Trouble Shooting.

APPENDIX A
Chapter A - Troubleshooting
Troubleshooting, provides advice regarding some commonly
encountered problems, as well as a list of CID limitations.
This Appendix contains the following sections:
• Section A-1: Troubleshooting Topics, page A-2
• Section A-2: CID Limitations, page A-5
CID User Guide A-1

Troubleshooting Topics
Section A-1 Troubleshooting Topics

• Client Table Size: If the Client Table overflow messages are
encountered with the ASCII terminal or Configware, the client table
size is too small for the application. This table size can be
increased in the Device Tuning window of the CID.
By default, the Client Table size is 20,000 entries. However, this
size can be increased to higher numbers to accommodate specific
applications:
• For a CID with 64 MB memory, the Client Table size can
reach 200,000 entries.
• For a CID with 64, 128 or 256 MB memory, the Client Table
size can reach 500,000 entries.
• Default Router: To ensure that the CID can access the Internet,
the default router of the CID must always be set.
You can set the default router by adding an entry to the CID
Routing Table and defining the destination IP network, mask set to
0.0.0.0. and the next hop as the IP address of one of the next hop
routers. You can also set the default router using the ASCII
terminal, during the initial IP Address configuration.
• VLAN Type: CID transparent VLAN works only in the Regular type
VLAN.
• VLAN Mode: When using the device in VLAN mode, users are
sometimes unable access the Internet. This problem is caused by
missing entries in the Routing Table window and a Default Gateway
entry that needs to be configured properly.
• Redundancy: When operating two redundant CID units, ensure
that:
• Redundancy is enabled for the backup CID (under CID >
Redundancy > Global Configuration),
• Redundant interfaces are configured in the Redundancy Table
(under CID > Redundancy > IP Redundancy Table).
• For the main device ensure that:
• Interface Grouping is enabled (under CID > Global
Configuration).
A-2 CID User Guide

Appendix A - Troubleshooting
• Redundancy and VLAN: When operating two redundant CID units

in VLAN mode, ensure that the Main (not backup) device is
configured first.
• Caching: While working with standard cache servers it is required
the traffic from the server to the client passes through the CID.
• Trapping: When CID servers do no trap non-configured clients,
ensure that:
• The Networks Table is set.
• The CID farm is enabled.
• At least one server in the farm is active.
Unless all these conditions are met, the CID will not trap the non-
configured clients.
In order to trap traffic other than HTTP, you must add an
intercepted port, for example RTSP port = 554, and MMS port =
1774.
• Non-configured Clients: The CID device does not intercept non-
configured clients, although the device was configured to a farm of
cache servers. In order to intercept a transparent client, it is
required to first set a policy.
• Session Tracking: While serving configured clients and a session
tracking is necessary, it is recommended to use the Source
Hashing Dispatch Method. Using this mode the device handles the
clients as 'sticky' clients.
• NAT: While using NAT, ensure that the NAT addresses cover the
Client Table entries. Each NAT IP handles up to 64K sessions.
Hence, when tuning the Client Table to more than 64K entries it is
necessary to use more than one NAT IP.
• Multiple Farms: When using more than one farm, it is required to
update the Farm Tuning prior to the farm configuration. Note that
any device tuning requires you to reset the device.
• URL Re-balancing: When using the URL entry connection limit,
the CID URL re-balancing does not work properly, because of the
logic conflics.
CID User Guide A-3

Troubleshooting Topics
• Pinging: If, when pinging the farm, the CID device does not reply,
the reason may be that the device does not have access to an
available cache server in the farm. The device requires at least one
available cache server in the farm in order to reply. If the farm does
not respond to the ping, you can ping the physical interface,
• If the interface replies and the device receives the ping request,
there is a problem with the content inspection server and not
the device.
• If there is no reply from the device, the problem is between the
device and the workstation, or the pinging to the physical
interface was disabled.
A-4 CID User Guide

Appendix A - Troubleshooting
Section A-2 CID Limitations

• The URL Match and HTTP Match modes are valid only per server
and not per farm and only function for non-configured clients.
• For Telnet, only a single connection can be opened.
Table Size Limitations

Table A-1 lists the maximum allowed sizes for each CID table.
Table A-1 Table Size Limitations
Table Size
URL Table 65K
Client Table (128 MB platform) 500K
Client Table (64 MB platform) 200K
Farm Table 10K
Alias Table 60K
Farm Policies Table 20K
Networks Table 128K
CID User Guide A-5

CID Limitations
A-6 CID User Guide

APPENDIX B
Chapter B - Loopback Interfaces
Appendix B, Loopback Interfaces, describes the setup of loopback
interfaces on the popularly used operating systems, and instructs how
to configure the alias IP addresses for each loopback interface.
Loopback addresses are required on servers when using CID network
configuration with local triangulation.
Definitions are provided for loopback configuration on these operating
systems:
• AIX, page B-4
• HP-UX, page B-5
• Linux, page B-6
• Solaris, page B-8
• Windows NT, page B-9
CID User Guide B-1

Example - Loopback Interface
Figure B-1 illustrates the loopback configuration example.
CID
Farm IP: 10.1.1.100
IP: 10.1.1.10
Server 1
IP: 10.1.1.1
Loopback:
10.1.1.100 Def
router: 10.1.1.20
Server 2
IP: 10.1.1.2
Router Loopback: 10.1.1.100
IP: 10.1.1.20 Def router: 10.1.1.20
Server 3
IP: 10.1.1.3
Loopback: 10.1.1.100
Def router: 10.1.1.20
Figure B-1 Loopback Interface Example

In the Figure B-1 example, the CID load balances among the servers:
• Server 1: 10.1.1.1
• Server 2: 10.1.1.2
• Server 3: 10.1.1.3
Each server has a loopback alias of 10.1.1.100, which is the same as
the CID Farm IP address (virtual IP address).
Each server has the network router (10.1.1.20) configured as the
default router, so traffic from the server to the client can go directly back
to the client through the router, without passing through the CID.
B-2 CID User Guide

Appendix B - Loopback Interfaces
Servers are defined in the CID, along with their IP addresses, and are
configured as Local Triangulation participants. For more information,
see Local Triangulation, page 4-80.
When Internet traffic from clients arrives at a CID farm, CID selects the
least busy server as its destination and forwards the request to it, using
the predefined loopback IP (farm IP). The server then sends the reply
directly to the default gateway, saving the need to go through CID.
CID User Guide B-3

AIX
Section B-1 AIX

For loopback on the AIX operating system, the command syntax is:
ifconfig lo0 alias <CID virtual IP> netmask
<netmask>
This command sets the first alias of the loopback interface “lo0” to have
the same IP address as the IP address of the CID Virtual IP (VIP).
For the example network as shown in Figure B-1, the command is:
Ifconfig lo0 alias 10.1.1.100 netmask 255.0.0.0
This command should be executed on all servers.
Note: Resetting the server erases the configuration. Therefore, the
command should be inserted in a boot-up script, so that each time the
server is reset, the loopback alias will be automatically configured.
B-4 CID User Guide

Section B-2 HP-UX

For loopback on the HP-UX operating system, the command syntax is:
Ifconfig lo0 <CID virtual IP>
This command sets the alias of the loopback interface “lo0” to have the
same IP address as the IP address of the CID Virtual IP (VIP).
Ifconfig lo0 10.1.1.100
CID User Guide B-5

Linux
Section B-3 Linux

For loopback on the Linux operating system, the command syntax is:
Ifconfig lo:1 <CID virtual IP> netmask <netmask> up
This command sets the first alias of the loopback interface "lo" to have
the same IP address as the IP address of the CID Virtual IP (VIP). Also
included in the command is the proper network mask.
For the example network as shown in Figure B-1, (assuming standard
class A masks), the command is:
Ifconfig lo:1 10.1.1.100 netmask 255.0.0.0 up
Various Linux operating systems, for example RedHat Linux Enterprise
3.0, may require that the netmask be 255.255.255.255.
This command should be executed on all servers.The loopback
configuration is activated by the server reset.
To configure loopback in RedHat Linux Enterprise 3.0 (kernel

2.1 and above):
1. To gain administrative access, the command is:
su to root
2. Edit /etc/rc.d/rc.local and add the following lines to the
end of the file:
/sbin/sysctl -w net.ipv4.conf.all.hidden=1
This runs the kernel commands across reboots and enables the
kernel configuration of all hidden network devices needed to
configure the loopback interface properties.
/sbin/sysctl -w net.ipv4.conf.lo.hidden=1
This hides the loopback device, to stop the loopback from
answering to ARP queries.
3. To access startup scripts, the command is:
cd /etc/sysconfig/network-scripts
This is where the network startup scripts are stored.
B-6 CID User Guide

4. To copy the generic loopback interface configuration template to a

loopback interface instance lo:1, the command is:
cp ifcfg-lo ifcfg-lo:1
5. Edit the file: ifcfg-lo:1 and make necessary changes to the IP
address, netmask, network and broadcast addresses.
Note: Netmask must be set to: /32 (255.255.255.255). The
device must be set to lo:1 (lo:1 is used as an example, it could
lo:x, x=1...n)
6. To activate the changes to the kernel without rebooting, the
command is:
sysctl -p
A patch has to be installed on the Linux server to disable the loopback

interface from replying to ARP requests. For more information, see
http://www.ssi.bg/~ja/#hidden.
CID User Guide B-7

Solaris
Section B-4 Solaris

For loopback on the Sun’s Solaris operating system, the command
syntax is:
Ifconfig lo0:1 <CID virtual IP> 127.0.0.1 up
This command sets the alias of the loopback interface “lo0” to have the
same IP address as the IP address of the CID Virtual IP (VIP).
Ifconfig lo0:1 10.1.1.100 127.0.0.1 up
B-8 CID User Guide

Section B-5 Windows NT

Setting up the loopback interface in Windows NT is not straightforward
and can sometimes create unpredictable behavior.
Loopback in Windows NT Configuration Guidelines

7. Add a new a loopback adapter.
8. Configure the loopback adapter with the appropriate IP address.
9. Reset the server.
10. Check the server’s routing table and make adjustments if
necessary.
11. Create a batch file or service to ensure that the necessary
adjustments are made after every server reset.
These steps are detailed in the procedure below:
To add and configure a loopback adapter in Windows NT:

1. Right click Network Neighborhood and select Properties.
Alternatively, you can get to network properties by choosing
Network from the Control Panel.
2. From the Network window, click the Adapters tab.
3. From the Adapters tab, click Add. The list of available adapters
appears.
4. From the Adapters list, select MS Loopback Adapter.
5. Click Ok. The MS Loopback Adapter Setup dialog box appears.
6. In the Frame Type field, select 802.3. You are prompted to provide
the NT disk or the NT source files.
7. Choose the location and continue.
Note: Your NT server may automatically know where the source
files are and skip this section.
8. After the loopback adapter has been properly installed, click
Close. The Network Properties window closes. NT will prompt
you to configure the loopback adapter with an IP address by
displaying the Microsoft TCP/IP Properties dialog box.
CID User Guide B-9

Windows NT
9. In the Microsoft TCP/IP Properties dialog box, choose the

loopback adapter.
10. Configure the Loopback IP. This should be the same as the CID
Farm IP. Configure an appropriate mask, but do NOT configure a
default gateway.
11. Click Ok. NT completes the configuration, then prompts to be
reset.
Note: The loopback configuration is activated by the server reset.
12. Reset the server. Once it has rebooted, login and go to a

command prompt (DOS prompt).
13. Adjust the IP Routing Table, as described on page B-11.
Deleting Unnecessary Routes

After you add and configure the loopback adapter, it is likely that the
server’s IP Routing Table contains one or more unnecessary routes
which you must delete. These are the non-multicast/broadcast routes
which have the same gateway address as the IP address of the
loopback interface.
You can identify extraneous routes in the server’s IP Routing Table
which you can access using the route print command. These
routes usually appear in pairs (for the same destination network,
usually the server’s local network). One route points to the server’s
physical IP address, while the other route points to the loopback IP
address. These duplicate entries pointing to the loopback IP address
as the gateway must be removed, otherwise the Local Triangulation
mode may not function properly.
B-10 CID User Guide

To adjust the Routing Table following loopback configuration:

To remove the table entry for extraneous route, use this command:
route delete <network address> mask <net mask>
<gateway address>
where <gateway address> is the same as the loopback interface.
If the above command is unsuccessful, use this command:
Route delete <network address>
This will remove both table entries. The appropriate entry must be re-
added using the following command:
route add <network address> mask <net mask> <gateway
address>
Note: Resetting the server erases the Routing Table changes.
Therefore, a batch file or service should be installed to ensure these
changes are re-applied after a reset. To operate the batch file as a
service, use the NT resource kit.
For further assistance, please contact the Radware Technical Support.
CID User Guide B-11

Windows NT
B-12 CID User Guide

APPENDIX C
Chapter C - Regular Expressions
Appendix C, Regular Expressions, provides an overview of the basic
syntax of regular expressions used in CID modules, for example in the
DNS Regexp Hostame table, in the Health Monitoring Module.
'^' and '$'. These symbols indicate the beginning and end of a string,
respectively, as follows:
• "^The": Matches any string that starts with "The"
• "of despair$": Matches a string that ends in the substring "of
despair"
• "âbc$": A string that starts and ends with "abc" – this can only
be "abc"
• "notice": A string that has the text "notice" within it.
If neither of the two characters is used (as in the last example), this
means that the pattern may occur anywhere within the string – and is
not "hooked" to any of the edges.
Symbols '*', '+', and '?' indicate the number of times a character
or a sequence of characters may occur. These symbols mean "zero or
more", "one or more", and "zero or one" respectively.
CID User Guide C-1

Appendix C - Regular Expressions
For example:
• "ab*": Matches a string that has an a followed by zero or more
b's ("a", "ab", "abbb", etc.)
• "ab+": Same, but there is at least one ”b” ("ab", "abbb", etc.)
• "ab?": There might be one or no ”b”
• "a?b+$": A possible ”a” followed by one or more ”b”'s ending a
string
Bounds can also be used. Bounds are defined inside the brace
brackets and indicate ranges in the number of occurrences:
• "ab{2}": Matches a string that has an ”a” followed by exactly two
”b”'s ("abb");
• "ab{2,}": Matches a string that has at least two ”b”'s ("abb",
"abbbb", etc.);
• "ab{3,5}": Matches a string that has from three to five ”b”'s
("abbb", "abbbb", or "abbbbb").
The first number of a range must always be specified, for example:
"{0,2}", not "{,2}").
Symbols '*', '+', and '?' denote the same as bounds "{0,}",
"{1,}" and "{0,1}", respectively.
To quantify a sequence of characters, they must be defined within
parentheses:
• "a(bc)*": Matches a string that has an ”a” followed by zero or
more copies of the sequence "bc";
• "a(bc){1,5}": Matches a string that has one to five copies of
”bc”.
The '|' symbol is an OR operator:
• "hi|hello": Matches a string that includes either "hi" or "hello".
• "(b|cd)ef" is a string that includes either "bef" or "cdef".
• "(a|b)*c" is a string that has a sequence of alternating ”a”’s and
”b”'s ending with ”c”.
A period ('.') stands for any single character:
• "a.[0-9]": Matches a string that has an a followed by a single
character and a digit.
C-2 CID User Guide

• "^.{3}$": A string with exactly 3 characters

Bracket expressions specify which characters are allowed in a single
position of a string:
• "[ab]": Matches a string that has either an ”a” or a ”b” (identical
to "a|b")
• "[a-d]": A string that has lowercase letters 'a' through 'd'
(identical to "a|b|c|d" and "[abcd]");
• "^[a-zA-Z]": A string that starts with a letter
• "[0-9]%": A string that has a single digit before a percent sign
• ",[a-zA-Z0-9]$": A string that ends in a comma, followed by
an alphanumeric character
You can also list the characters which you do not want to appear in the
string. Use a '^' as the first symbol in a bracket expression. For
example:
"%[â-zA-Z]%" matches a string with a character that is not a
letter, between two percent signs.
To take the characters "^.[$()|*+?{\" literally, they must follow a
backslash ('\'), to denote they have a special meaning. This includes
the backslash character itself.
Remember that bracket expressions are an exception to the above
rule. Within brackets, all special characters, including the backslash
('\'), lose their special meanings. For example, "[*\+?{}.]"
matches precisely any of the characters within the brackets.
CID User Guide C-3

C-4 CID User Guide

APPENDIX D
Chapter D - Glossary
Appendix D, Glossary, provides the descriptions of the terms that are
frequently used in this guide, and the list of common abbreviations.
The Glossary contains the following sections
• Commonly Used Terms, page D-2
• List of Abbreviations, page D-6
CID User Guide D-1

Commonly Used Terms
Section D-1 Commonly Used Terms

Advanced Monitoring and Statistics
CID provides a range of statistics, such as Current Server Load,
Current Attached Clients per Server, and numerous URL based
statistics. Through analysis and diagnostics, these statistics enhance
the monitoring and utilization of the network. The Client Table and URL
Table that contain information regarding clients and URLs, are
dynamically learned. Traps are initiated in case of special events.
Content Inspection Server Farm

A set of content inspection servers, which have a single IP address,
that is the Farm Address, defined on the CID.
IP Interface
An IP interface on CID is comprised of two components: an IP address
and an associated interface. The associated interface is either a
physical interface or a virtual interface (VLAN). IP Routing is performed
between CID IP interfaces, while Bridging is performed within an IP
interface that contains an IP address associated with a VLAN.
CID was designed to intercept HTTP requests and to redirect them to a
content inspection server farm. The first assumption in designing a CID
network is that the CID resides on the path between the clients and the
Internet and content inspection servers. This placement is required by
the role of CID in the network - CID needs to intercept the outgoing
client requests and to manipulate the packets returning from the
content inspection servers to the clients.
Except for the setup that involves local triangulation or transparent
proxy, all traffic must travel physically through the CID. This includes
traffic from the users to the Internet and from the content inspection
server farm back to the users.
Users who are statically configured to use a content inspection server,
should be configured to the CID virtual address. This address is the
access IP address for the content inspection servers.
Note: This address is used only for statically configured users.
D-2 CID User Guide

Appendix D - Glossary
NAS
Network-attached storage (NAS) is hard disk storage that is set up with
its own network address rather than being attached to the department
computer that is serving applications to a network's workstation users.
NNTP
NNTP (Network News Transfer Protocol) is the predominant protocol
used by computer clients and servers for managing the notes posted
on Usenet news groups. NNTP replaced the original Usenet protocol,
UNIX-to-UNIX Copy Protocol (UUCP). NNTP servers manage the
global network of collected Usenet news groups and include IAS
(Internet Access Provider) servers. An NNTP client is included as part
of any Web browser.
Physical Interface
One of the Fast Ethernet or Application Switch ports of the CID. In the
Fast Ethernet platform, a CID can have either 2 or 4 physical
interfaces, depending on the hardware configuration. In the Application
Switch platform, the CID can have up to 10 physical interfaces.
Physical IP Address
An IP address assigned to a CID interface. This address belongs to the
CID and is used for SNMP management and for routing purposes.
RADIUS Protocol
Remote Authentication Dial-In User Service, or RADIUS, is a standard
in [RFCs 2865 and 2866] used for centralizing network authentication
of remote access users.
RADIUS is a client-server authentication and authorization access
protocol used to authenticate users attempting to connect to a network
device. The Access Server (BAS) functions as a client, passing user
information to one or more RADIUS servers. User access is either
granted or denied to the device based on the response received from
the RADIUS servers.
The RADIUS clients send UDP authentication requests, typically over
port 1812, with MD5 encrypted passwords to the RADIUS
authentication server and act on responses sent back by the server.
CID User Guide D-3

Commonly Used Terms
The authentication process begins when a user initiates a connection

with the server. The RADIUS checks its authentication database and
issues a “reject”, “challenge”, or “accept” message along with any
attributes and values it has been configured to return. In response to an
“accept” message, the BAS grants the user access according to the
returned RADIUS attributes with its local authorization information. A
reject message causes the router to query its own authentication
database if configured to do so. Finally, when the user terminates the
connection, the router may send session accounting data back to the
RADIUS server for accounting.
RTSP, MMS (Streaming) Request Interception

In addition to HTTP ports, the CID intercepts and redirects common
streaming protocol ports transparently and redirects them to the cache
farm.
Virtual Interface (VLAN)

A collection of physical interfaces. A VLAN is defined according to
protocol. Bridging for the defined protocol is performed between the
ports that belong to a VLAN. In the case of IP, bridging is performed
within a VLAN depending on the IP address assigned to that VLAN. For
example, if an IP VLAN contains physical interfaces 1, 2, and 4 and is
given an IP address of 192.1.1.1 (with subnet mask 255.255.255.0).
Bridging is performed for IP network 192.1.1.0 between CID ports 1, 2,
and 4.
Virtual IP Address (Farm address)

An IP address assigned to the CID that represents a content inspection
server farm. Packets destined to this address are load balanced
between the servers of the farm. The CID can hold a single farm.
VLAN types
Two types of IP VLANs are commonly encountered when configuring a
CID. Either VLAN can be used depending on the CID configuration
requirements.
Regular: A Regular VLAN provides transparent bridging within the
VLAN. This means that when two stations communicate within the
VLAN, they are aware of each other's MAC addresses. For example, if
D-4 CID User Guide

stations A and B are on two different CID ports that belong to the same
VLAN, during communication A knows B's MAC address and B knows
A's address. In addition, Regular VLAN also supports redundancy and
transparent proxy features.
Broadcast And Unicast: This is a special VLAN which allows bridging
using standard proxy ARP techniques. For example, stations on one
VLAN port of the CID believe that all stations on other CID ports
belonging to this VLAN have the same MAC address. This one MAC
address is actually the MAC of the CID. It may be necessary to use this
VLAN type in CID configurations to ensure that packets are destined to
the MAC address of the CID during end station to server
communications.1
CID User Guide D-5

List of Abbreviations
Section D-2 List of Abbreviations
Acronym Meaning
ARP Address Resolution Protocol
AS Autonomous System
AS Application Switch
AV Anti Virus
BGP Border Gateway Protocol
CID Content Inspection Director
CIDR Classless Interdomain Routing
CSD Cache Server Director
CW ConfigWare
CWIS Configware Insite
DGW Default Gateway
DHCP Dynamic Host Configuration Protocol
DMZ Demilitarized Zone
DNS Domain Name System
DSL Digital Subscriber Loop
EGP Exterior Gateway Protocol
EIGRP Enhanced Interior Gateway Protocol
FDDI Fiber Distributed Digital Interface
FE Fast Ethernet
FP Fire Proof
FTP File Transfer Protocol
FW Firewall
GARP Gracious Address Resolution Protocol
GTLD GenericTop Level Domain
GUI Graphic User Interface
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocols Secure
D-6 CID User Guide

HW Hardware
ICMP Internet Control Message Protocol
IDS Intrusion Detection System
IGP Interior Gateway Protocol
IGRP Interior Gateway Routing Protocol
IP Internet Protocol
ISDN Intergrated Services Digital Network
ISO International Standards Organization
ISP Internet Services Provider
ITM Internet or Intelligent Traffic Management
LAN Local Area Network
LB Load Balancer/Balancing
LLC Logical Link Control
LP LinkProof
LRP Load Reporting Protocol
MAC Media Access Control
MAN Metropolitan Area Network
MED Multi-Exit Discriminator
MIME Multi-Purpose Internet Mail Extension
NAP Network Access Point
NAS Network Attached Storage
NAT Network Address Translation
NetBEUI NetBIOS Extended User Interface
NetBIOS Network Basic Input/Output System
NHR Next Hop Router
NIC Network Interface Card
NP Network Proximity
NTP Network Time Protocol
NNTP Network News Transfer Protocol
OSI Open Systems Interconnect
OSPF Open Shortest Path First
CID User Guide D-7

List of Abbreviations
OUI Organizational Unique Identifier

PD Peer Director
POP3 Post Office Protocol 3
PRP Proximity Reporting Protocol
QoS Quality of Service
RED Random Early Detection
RFC Request for Comment
RIP Route Information Protocol
RND Rad Network Devices
SmartNat Smart Network Address Translation
SMTP Simple Message Transfer Protocol
SNMP Simple Network Management Protocol
SONET Synchronous Optical Network
SSH Secure Shell
SSL Secure Socket Layer
SW Software
TCP Transmission Control Protocol
TFTP Trivial File Transfer Protocol
TLD Top Level Domain
UDP User Datagram Protocol
URL Uniform Resource Locator
VACM View-based Access Control Model
VLAN Virtual Local Area Network
VLSM Variable Length Subnet Masking
VRRP Virtual Router Redundancy Protocol
WAN Wide Area Network
WBM Web Based Management
WINS Windows Internet Naming Service
CID Web Server Director
WWW World Wide Web
D-8 CID User Guide

Index
Index
A Port Groups 8-26
Action 8-12 Predefined Filters 8-21
Action Macro 7-14 Rules 8-12
Activation/Inactivation Schedule 8-15 Services 8-19
Active 9-75 VLAN Tag Groups 8-27
Admin Status 4-28 Bandwidth Management Module 8-2
Advanced CID Features Bandwidth Management Policies 8-8
Chapter 5-1 Basic Filters 8-19
Advanced Filters 8-20, 9-81 Borrowing Limit 8-13
Alternate Default Gateway 3-28 Bridging, in VLAN 3-23
Application Classification 8-4
Application Security 9-1 C
Attacks Dynamic Information 9-196 Cache Load Balancing 4-57
Cache Server Types 4-58
B CID Limitations (Appendix A) A-5
Backup Device in VLAN 6-12 Classification 8-37
Backup Fake ARP 6-12 Classification Modes 8-5
Backup Interface Grouping 2-70 Client NAT 4-28
Backup Interface Grouping, Redundancy Client Table 4-37
6-6 Client Types 4-57
Bandwidth Limit 4-28 Configured Clients 4-57
Bandwidth Management 8-3 Connection Limit 4-27
Borrowing Limit 8-13 Content 8-20
Classes 8-18 Content Parameters 9-59, 9-90, 9-102,
Classification Criteria 8-9 9-152, 9-167
Guaranteed Bandwidth 8-12
Networks 8-25 D
Policy Groups 8-13 Daylight Saving Time Support 2-78
Default Gateway, setup 3-27
CID User Guide 1

Index
Destination 8-9 Groups 9-64, 9-102, 9-153, 9-168

Destination Hashing 4-9 Guaranteed Bandwidth 8-12
Detecting 9-3
Device Management CLI 2-27 H
Device Management in CWIS 2-26 Hardware Licenses, Upgrading 2-21
Device Notifications 2-75–2-86 Health Check 3-28
Device Security 2-61 Health Check Binding 7-16
Device Tuning 2-72–2-74 Health Check Methods
Device Upgrading 2-10 Arguments 7-35
Direction 8-9 Predefined 7-26
DNS Services User Defined 7-39
DNS Client 5-79 Health Check, Advanced 4-52
DNS Server 5-82 Health Check, Basic 4-52
Dormant 9-75 Health Check, Farm 7-23
DoS Shield 9-75, 9-76 Health Check, Multiple Servers 7-45
Health Checks DB 7-9
E Health Monitoring 3-28
E-mail Traps 9-193 Checked Element 7-3
Events Scheduler 8-16 Global 7-6
Global Configuration 7-8
F Health Check Binding 7-16
Farm Health Check 7-23 Method 7-4
Farm Management 5-2 Module 7-3
Farm Servers 4-27 Health Monitoring TCP Check 7-52
Filter Groups 8-20 HTTP Advanced Features
Flow Management 5-2 Forbidden Request Override 5-64
Configuration 5-7–5-18 HTTPS 5-64
Scheme 5-6 Proxy SSL 5-64
For C-3 URL Retrieval 5-62
FTP Address Multiplexing 2-59, 5-52 HTTP Match Policy 5-23
FTP Support 2-54, 5-46
FTP Support, Transparent 2-59, 5-52 I
Important Notice 1-I
G Inbound Physical Port Group 8-11
Global Server 4-32 Intercepted Clients 4-57
Group Health Check 7-22 Interface
2 CID User Guide

Index
Loopback B-1–B-11 Policies 8-5, 8-15, 8-35

Interface Classification 8-39 Policy Groups 8-13
Interface Grouping, Redundancy 6-6 Policy Index 8-15
Introducing CID 1-VII, 1-1 POP3 Support, Configuration 5-53
IP Addressing 3-25 Port Bandwidth 8-38
Port Groups 8-26
L Port Mirroring 3-3
Log File 9-196 Port Trunking 3-6
Loopback Preventing 9-4
Loopback Configuration Proprietary ARP 6-11
AIX B-4 Protocol Discovery 8-33, 8-34
HP-UX B-5 Protocol Discovery Policies 8-35
Linux B-6 Proxy AV Gateway, Configuration 5-71
Solaris B-8 Proxy SSL 5-64
Windows NT B-9
Loopback Interfaces 10-46 R
RADIUS Authentication 2-60
M RADIUS Based Classification
Management Interfaces 2-70 Configuration 5-60
Mirroring 6-8 General 5-58
Multiplexed Server Port 4-34 Random Early Detection 8-5
Multiplexing, FTP Address 2-59, 5-52 Redundancy Methods
Backup Fake ARP 6-12
N Proprietary ARP 6-11
NAT in VLAN mode 4-89 VRRP 6-24
NAT to Remote Servers 4-101 Redundancy with Bridging 6-12, 6-17
Networks 8-25 Redundancy with Routing 6-14
Redundancy, General 6-3
O Regular Expressions C-1
OMPC 9-57, 9-90, 9-102, 9-152, 9-167
Regular Health Check 7-19–7-21
Operation Mode 4-29
Reporting 9-4
Resetting Devices 2-9
P
Response Threshold 4-28
Packet Marking 8-15
Restoring Configuration Files 2-18
Parallel Redundancy with Routing 6-20
RIP Configuration 3-29
Ping Physical Port 2-70
CID User Guide 3

Index
Routing 3-26 Types of Attacks 9-6

Routing Information Protocol (RIP) 3-29
Routing Table, Setup 3-27 U
Upgrading Boot Versions 2-24
S Upgrading devices in WBM 2-21
Safety Instructions 1-II URL Match Policy 5-22
Scheduler Algorithm 8-4 URL Policies
Secret, NAS and RADIUS 5-59 Configuration 5-20
Server Weight 4-27 HTTP Match 5-23
Service 8-11 URL Match 5-22
Services 8-19 URL Retrieval 5-62
Basic Filters 8-19
Signature File Update 9-36 V
Signatures Database 9-25 Virtual LAN, General 3-9
SNMP Configuration 2-69 VLAN Tag Group 8-11
SSL Content Check 5-66 VLAN Tag Groups 8-27
Switched VLAN 3-10 VLAN Tagging 3-23
SynApps Models 8-1 VLAN Types
Syslog Messages 9-196 Regular 3-10
Switched 3-10
T VRRP, General 6-25
Telnet and SSH Configuration 2-51
Transparent FTP 2-59, 5-52 W
Traps 9-196 Warm-up Time 4-32
Troubleshooting A-1–A-5 WBM Device Management 2-48
Weighted Cyclic 4-10
4 CID User Guide

Cid 2.41 Ug

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Cid 2.41 Ug

Hochgeladen von

Copyright:

Verfügbare Formate

Content Inspection Director

Software Version: 2.41

Chapter 2 - Device Management..................................... 2-1

CID User Guide III

Configuring SNMP ...................................................................... 2-34

Chapter 3 - Basic Switching & Routing.......................... 3-1

IV CID User Guide

VLAN Tagging Support ............................................................... 3-18

Chapter 4 - Basic Application Switching ....................... 4-1

CID User Guide V

Client-Server Combinations ........................................................ 4-60

Chapter 5 - Advanced Features ...................................... 5-1

VI CID User Guide

SSL Content Check .............................................................. 5-65

Chapter 6 - Redundancy.................................................. 6-1

Chapter 7 - Health Monitoring......................................... 7-1

CID User Guide VII

Predefined Methods .................................................................... 7-26

Chapter 8 - Bandwidth Management .............................. 8-1

Chapter 9 - Security ......................................................... 9-1

VIII CID User Guide

Protection Profiles and Groups Supplied by Radware ................ 9-26

CID User Guide IX

Protocol Anomalies ............................................................. 9-142

Chapter 10 - Application Switching Platforms ............ 10-1

X CID User Guide

Mounting the Device ................................................................. 10-28

Chapter A - Troubleshooting .......................................... A-1

Chapter B - Loopback Interfaces.................................... B-1

Chapter C - Regular Expressions ................................... C-1

Chapter D - Glossary ....................................................... D-1

CID User Guide XI

XII CID User Guide

CID User Guide XIII

Figure 5-3 Network B Client Redirection.............................................. 5-5

XIV CID User Guide

Figure 9-3 Custom Attack Configuration ............................................ 9-49

CID User Guide XV

XVI CID User Guide

CID User Guide I

II CID User Guide

CID User Guide III

RESTRICT AREA ACCESS

IV CID User Guide

)Caution - To Reduce the Risk of Electrical Shock and Fire

)Attention: Pour Reduire Les Risques d'Electrocution et d'Incendie

CID User Guide V

)Manahmen zum Schutz vor elektrischem Schock und Feuer

VI CID User Guide

About This Guide

CID User Guide VII

VIII CID User Guide

Note: Important information that requires additional attention.

Tip: A recommendation, or an optimum way to perform an

Configuration Guidelines: General description of the con-

To Statement: Detailed operating instructions that explain

Example: An example configuration of an actual scenario.

CID User Guide IX

X CID User Guide

CID User Guide 1-1

Section 1-1 Introduction

1-2 CID User Guide