LinkProof

Release Notes
Version 4.37
October 10, 2009

North America
Radware Inc.
575 Corporate Dr., Lobby 1
Mahwah, NJ 07430
Tel: (888) 234-5763
International
Radware Ltd.
22 Raoul Wallenberg St.
Tel Aviv 69710, Israel
Tel: 972 3 766 8666
www.radware.com

LinkProof version 4.37 Release Notes

Date: October 10, 2009
Page - 2 -

Radware announces the release of LinkProof version 4.37. These release notes describe new features
since the last released version of LinkProof, 4.30. LinkProof 4.30 includes all bug fixes from
maintenance version 4.21.04.
Table of Contents
Retired Versions............................................................................................................................... 2
Supported Platforms and Modules ................................................................................................. 3
Whats New ....................................................................................................................................... 4
Dynamic NAT tuning up to 128 Entries (Introduced in 4.35.09DL)................................................. 4
Proximity using Trace Route (Introduced in 4.35.10DL)................................................................. 5
IP Fragments Out of Order (Introduced in 4.35.09DL) ................................................................... 5
VRRP Error Suppression................................................................................................................ 6
VRID Information messages....................................................................................................... 6
VRRP Error suppression ............................................................................................................ 6
Force Port Down (introduced in 4.35.07)........................................................................................ 7
Configuration .............................................................................................................................. 7
VRRP Configuration Notes......................................................................................................... 7
Limitations .................................................................................................................................. 7
Cluster Support (introduced in 4.35.07DL) ..................................................................................... 7
Configuration .............................................................................................................................. 9
New Dispatch Methods................................................................................................................... 9
Hashing Dispatch Method .......................................................................................................... 9
Configuration ............................................................................................................................ 10
Transparent IDS Load Balancing ................................................................................................. 11
Transparent IDS Load-Balancing Configuration ....................................................................... 11
Configuration ............................................................................................................................ 12
Subnet Persistency Mask Mode ................................................................................................... 12
Configuration ............................................................................................................................ 12
Example.................................................................................................................................... 12
Client Table Views........................................................................................................................ 12
Configuration ............................................................................................................................ 13
Example.................................................................................................................................... 14
Passive FTP support .................................................................................................................... 14
Whats Changed ............................................................................................................................. 14
MIB change .................................................................................................................................. 14
Upgrade Path .................................................................................................................................. 14
Upgrade Procedure ...................................................................................................................... 15
Upgrading from versions lower than 4.21 ................................................................................. 15
Upgrading from 4.21.x or 4.30.................................................................................................. 15
Related Documentation ................................................................................................................. 16
Known Limitations ......................................................................................................................... 16

Retired Versions
With the release of version 4.37.12 as LA, major version 4.37.10 is retired.
When version 4.37.12 is promoted to Shipping GA status, the following versions are retired:
Major version 4.35.07 and platforms AS1, AS2, AS3 and CAS
Page 2

LinkProof version 4.37 Release Notes

Date: October 10, 2009
Page - 3 -

For details on the support policy for retired versions, see the Certainty Support Guide.

Supported Platforms and Modules

This version is supported by the following platforms:
Note: This version allows the application software to support multiple boot versions. The config.ini
file defines the lowest boot version supported (BootRomVersion) and the highest boot version
supported (BootRomVersionInPackage). If the current boot version on the device is within these
parameters, no boot upgrade is required.
Platform

Application Switch 1
Application Switch 2

Lowest
Boot
Version
4.53
4.33

Highest Boot Notes and Exceptions

Version
6.01
6.07

For Application Switches 1 and 2 with a

SynApps license, it is recommended to use
256MB with this version. Large BWM
and/or Application Security configurations
that fit in 128MB in previous versions might
require 256MB with this version.
When upgrading Application Switch 1 from
version 4.21.02, boot upgrade is required.
Use the following procedure:
1. Reboot the device, stop at the
countdown and download the new boot
version via CLI.
2. After the new boot is uploaded to the
device, type ' @ ' (do not reboot the
device or change any dip-switch).
3. The device loads the old boot file
4.5x and the old software version
4.21.02. Using CLI or Web Based
Management, upgrade the device by
sending the .tar file.
4. Once the process ends, the following
message is displayed in CLI :
Please toggle DPSW 1 to
select another boot bank.
Reboot will be performed.

5. Change dip-switch number 1, without

turning off the device.
Page 3

LinkProof version 4.37 Release Notes

Date: October 10, 2009
Page - 4 -

Platform

Lowest
Boot
Version

Highest Boot Notes and Exceptions

Version
The device reboots itself automatically and
uploads with the new boot and the new
version.

Application Switch 3
Compact Application
Switch

6.04
1.3*, 1.4**

6.04
6.012

* Only when upgrading from 4.30.

** Before starting the upgrade procedure
from version 3.81.0x, the boot EPROM must
be replaced with boot EPROM version 1.4
or higher (it is recommended to ask for the
highest boot version supported by the exact
bug fix version you are upgrading to).
Contact the Radware ordering department
for this. If you are upgrading from version
4.30, no boot change is required.
For upgrade from version 3.81.x the lowest
boot version to be used is 1.43.

For instructions on the upgrade path, see

Upgrade Path.
For more information on platform specifications, refer to the Installation and Maintenance
Guide.
This version includes the following modules:
Module
Application Security
(IPS, DoS and
BDoS)
APSolute OS
Other

Supported Version
3.402

Notes and Exceptions

10.03-01.08DL
11.05.03

This version is supported by APSolute Insite version 2.73 and later.

Whats New
This section describes the new features and components introduced in this version.
Dynamic NAT tuning up to 128 Entries (Introduced in 4.35.09DL)
Dynamic NAT can be tuned up to 128 entries.
Page 4

LinkProof version 4.37 Release Notes

Date: October 10, 2009
Page - 5 -

This can be done via the WBM or CLI Device -> Tuning Parameters
Proximity using Trace Route (Introduced in 4.35.10DL)
Before the feature LinkProof Proximity checks had 4 checks
Basic Proximity - PING
Advanced Proximity - UDP
Server Side Proximity TCP - Destination port 80
Client Side Proximity - TCP (same port)
If any of the following checks passes the routers / Firewalls we use it (or all) to calculate the
Proximity.
This feature can be configured via WBM (LinkProof -> Proximity -> Proximity Parameters ->
Proximity Checks) or CLI (the lp proximity checks)
Following the addition to the Proximity feature Trace Route option (ICMP) has been added
Trace Route Proximity (Port 37853) when enabled we check proximity using Trace Route to
the destination while increasing TTL to 1 (2 to highest 50)

IP Fragments Out of Order (Introduced in 4.35.09DL)

IP Fragments might arrive to the LinkProof Device in an incorrect order (for example the 3rd
fragment before the 1st)
IP Fragments out of order enables building a queue in order to wait for fragments even if they arrive
in a out of order state
This feature can be configured via WBM (LinkProof -> Global Configuration -> General) or CLI
(the lp global fragmentation-aging-time) or lp global fragmented-packets-toretain).
The available parameters are:
Fragmentation Table Ageing time this is the timer that is counting from the appearance of the 1st
fragment till the final fragments arrives and the packet is reconstructed
When the timer exceed pre configured value and the final packet has not arrived the packet is
discarded
0 to 1500 Seconds (default is 5 seconds)
Number of Fragmented Packets to Retain
Number of fragments that are retained (requires memory allocation)
1 2048 (default is 0 fragments)

Page 5

LinkProof version 4.37 Release Notes

Date: October 10, 2009
Page - 6 -

When a packet arrives and we collect only 10 fragments but it is constructed of 11 fragments the
timer eventually will discard the packet.
VRRP Error Suppression
When LinkProof is configured in VRRP mode (for redundancy purposes) there are 2 parameters that
influence the messages between VRRP nodes (Primary & Secondary).
VRRP can be explained in terms of a Virtual Router (VR). 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 lessens the need for a MAC address update in case of a failover.
Associated IP the Virtual IPs (VIPs) that the VRRP pair receives, are assigned to its VRID.
A VRID can have more than one Associated IP and each VRRP pair can have more than one VRID.
VRID Information messages

When a VRRP status update occurs (i.e. Backup becomes Master and vice versa), the process is
accompanied by messages notifying that the associated IPs have switched nodes on a VRID (i.e.
from Primary to Backup).
If there are numerous associated IPs defined on a specific VRID, messages appear that notify a
backup / master configuration has changed (or that one node is restarting for maintenance purposes).
For example, if there are 3 VRIDs with 10 Associated IPs assigned to each VRID, a change of
backup / master occurs and produces 3x10 = 30 messages in the console of the LinkProof device.
This may cause the VRRP node to respond slowly and appear as if it is flapping (going up and
down). This behavior continues until all messages have cleared.
VRRP Error suppression

In order to resolve the VRID messages issue a new feature was introduced. The feature is called
VRRP Error suppression and has the following 3 message levels to present information / error
messages:
1) ON - All messages from all VRIDs and Associated IPs appear (Verbose) [Default]
2) OFF - No messages (excluding the VRID message itself)
3) Summary - A summary of the VRIDs & Associated IP address change in a short list format
To Configure VRRP Error suppression using WBM
1) Select LinkProof > Redundancy - Global Configuration. The Global Redundancy
Configuration window appears.
2) From the Trap VRRP Association Addresses drop-down list select one of the following:
On
Off
Summary
3) Click Set.
Page 6

LinkProof version 4.37 Release Notes

Date: October 10, 2009
Page - 7 -

To Configure VRRP Error suppression using CLI

Enter (redundancy vrrp trap-associated-id set <on (default),off or Summary>
Force Port Down (introduced in 4.35.07)
When operating in VRRP configuration this feature allows you to force down physical ports
belonging to a VLAN for a short period when the VLAN is disabled due to Interface Grouping
activation. This allows the switches to which these ports are connected to clear their MAC tables and
prevent them from continuing to send traffic to the wrong LP device.
Note that this feature will not function (even if its status is Enable) when VRRP is not enabled and
there is no VLAN configured as part of the VRRP interfaces.
Configuration

This feature can be configured via WBM (Redundancy -> Global Configuration) or CLI (the
redundancy force-down-ports-mode command). The available parameters are:

Force Down Ports Status: Enable/Disable (default)

Force Down Ports Time: The period of time for which the port must be down. The values can be
between 5 (default) and 60 seconds it depends on how long it takes the switch to clear its MAC
tables.

VRRP Configuration Notes

The following is important for proper functionality of VRRP capability in general and with VLAN
in particular:

Interface grouping must be enabled in both main and backup devices.

Backup interface grouping must be enabled in the backup device.
Backup in VLAN parameter must be set to Backup in the backup device.
All the interfaces of the device must be either defined in VRRP or as Excluded in the Selective
Interface Grouping table.

Limitations

This capability is supported only for one VLAN per device

Mirroring is not supported for this configuration
This capability is not yet supported on Application Switch 3.
On Application Switch 1 equipped with Gigabit ports, when the Gigabit ports are forced down
the link LED remains ON.

Cluster Support (introduced in 4.35.07DL)

There are a number of configurations in which LinkProof is required to load balance servers (routers
or firewalls), where each server is in fact a cluster of servers.
The problem in such cases is that while traffic to a LinkProof server that represents a cluster is
forwarded to the MAC address received as a result of ARP to that servers IP address, traffic coming
Page 7

LinkProof version 4.37 Release Notes

Date: October 10, 2009
Page - 8 -

from the cluster usually has as its source MAC the MAC address of the physical server in the cluster
that forwarded the packet.
In the example in Figure 1, two NHRs are defined on the LinkProof device: NHRA, which is in fact
a cluster, and NHRB. LinkProof recognizes MAC A as the MAC address of NHRA (it was
discovered via ARP messages to IP A), but when traffic comes from NHRA it comes with source
MAC MAC11, MAC 22, or MAC 33, depending on which physical router processed this traffic.
Currently LinkProof does not recognize such traffic as coming from one of its own servers (NHRA
or NHRB) and for that reason it does not process it correctly.
Figure 1
NHRA IP A; MAC A
Router 1 MAC 11
Router 2 MAC 22
Router 3 MAC 33

NHRB IP B; MAC B

Examples of such configurations can be:

VRRP or HSRP router or firewall clusters
Private firewall clusters (Checkpoint)
WOC devices between LinkProof and the NHR (it is not a cluster, but the behavior of the MAC
addresses is the same)
Note: In many cases we might not actually be required to load balance traffic to the cluster, but
rather to perform NAT on traffic to/from the cluster. In this case the cluster needs to be configured
as a LinkProof server (NHR/Firewall) and the same behavior applies.
In order to allow LinkProof to recognize traffic that arrives from a physical server that is part of a
cluster as arriving from an NHR or Firewall server defined on LinkProof, the device now allows
configuring for each NHR or Firewall server additional MAC addresses or IP addresses belonging to
the cluster servers.
For the example in Figure 1, the user is able to configure MAC 11, MAC 22, and MAC 33 as
belonging to server NHRA, and thus LinkProof will be able to recognize traffic coming with these
MAC addresses as traffic from server NHRA.
Page 8

LinkProof version 4.37 Release Notes

Date: October 10, 2009
Page - 9 -

Note that the LinkProof server IP should be the Virtual IP of the cluster or, in the case of WOC
devices, the IP of the router beyond the WOC device.
Configuration options:
For HSRP clusters, where the virtual IP cannot be the IP of any of the cluster servers, the user is
able to configure the IPs of the cluster servers and their MAC address will be discovered via
ARP. This allows replacing a server in a cluster, without changes to the LinkProof configuration
(if the new server has the same IP as the old one).
For VRRP clusters where the Virtual IP can, and usually is, the IP of one of the cluster servers,
the user will be able to configure statically the MAC addresses of the cluster servers.
For WOC devices the user will need to statically configure the MAC address of the WOC
device.
When LinkProof forwards traffic to the LinkProof server, it will always use as destination MAC the
MAC address discovered via ARP to the logical server IP address (MAC A in the example above).
However traffic coming from the cluster will be allocated to a LinkProof server if the source MAC
(or its IP) was statically configured as belonging to this server.
Configuration

Configuration is currently available via WBM and CLI only.

WBM: A new option, called Cluster Servers has been added to the LinkProof->Next Hop
Routers -> Cluster Server Table menu. In this web page for each NHR IP multiple cluster
servers can be added.
For each cluster server either an IP address or a MAC address must be configured (not both).
CLI: A new CLI command lp next-hop-router cluster-servers was added. To configure a cluster
server using IP address, the MAC address must be set to 000000000000. To configure a cluster
server using MAC address, the IP address must be set to 0.0.0.0.
Note:
1) When configuring a cluster server using IP address, the MAC address must be set to
000000000000.
2) When configuring a cluster server using MAC address, the IP address must be set to 0.0.0.0.
New Dispatch Methods
A dispatch method defines the criteria for selecting the best available NHR. Dispatch methods are
defined only for new sessions. Existing sessions are handled by the Client Table.
The selection 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 is more important for an FTP farm.
Hashing Dispatch Method

When the Hashing dispatch method is applied, LinkProof selects an NHR for a session using a Hash
function. This is a static method where the firewall is chosen for a session purely according to the L4
Page 9

LinkProof version 4.37 Release Notes

Date: October 10, 2009
Page - 10 -

data of the session. Hashing methods provide persistency when choosing an NHR based on various
parameters.
LinkProof 4.37 introduces the following three Hashing dispatch methods:

Layer 3 Hashing - In Layer 3 hashing, the hash function is performed on the source and
destination IP.
This ensures that when a connection passes through the device, as long as it uses the same source
and destination IP, the connection will remain persistent (that is, pass through the same NHR).
This Hashing method is symmetric, meaning that when replacing the source with the destination
IP and vice versa, the selected NHR will be identical.

Source IP Hashing - In Source IP Hashing, the hash function is performed on the source IP
only.
This ensures that when a connection passes through the device, as long as it uses the same source
IP, the connection will remain persistent (that is, pass through the same NHR)

Customized Hash - Sometimes a regular Hash function does not adequately provide an equal
distribution of sessions across all load balanced elements. This is because the part of the IP
address that changes the least often affects the Hash functions.
Customized Hash is a variant of the hashing dispatch method that offers different server
distribution. It allows you to define the bits in the source and destination IP to be considered for
the hash function, allowing for only the part of the IP that changes the most to be included in
Hash calculations (a part is a continuous sequence of bits)
Example:
The mask used for the customized Hash is 0.0.0.255, where all source IPs coming from
X.X.X.200 would pass through the same NHR.
Source IPs using the mask X.X.X.201 may choose a different NHR.
This maybe useful in cases where the original Hash function ignored the last octet and sent both
X.X.X.200 and X.X.X.201 to the same NHR

Note: Since Layer 3, Source and Customized Hashing are separated from the client table hashing so
you can use Layer 4 client table mode with port hashing but still maintain Layer 3 persistency.
Configuration

Configuring the Hashing Dispatch Method is currently available via WBM and CLI only
WBM: LinkProof->Global Configuration -> General -> Dispatch Method
Page 10

LinkProof version 4.37 Release Notes

Date: October 10, 2009
Page - 11 -

In this web page the Dispatch method for the LP can be chosen
CLI: lp global dispatch-method set "Layer3 Hashing" [or 11]
CLI: lp global dispatch-method set "Source IP Hashing" [or 12]
CLI: lp global dispatch-method set "Customized Hash" [or 13]
The mask configuration for the customized Hash method can be configured using
WBM :LinkProof >Global Configuration > Tweaks
CLI: lp global customized-hash-mask
The default mask is 0.0.0.255.
Transparent IDS Load Balancing
Transparent IDS Load-Balancing Configuration

Transparent IDS load balancing is a network design where LinkProof is not located in the traffic
flow path, but instead receives copied traffic from a core switch. This implies that the traffic is not
destined to the MAC address of the LinkProof device.
Figure 2 - Transparent Load-Balancing Configuration

IDS Farm

LinkProof

Local
Network

Firewall

Switch

Page 11

Users

LinkProof version 4.37 Release Notes

Date: October 10, 2009
Page - 12 -

To install LinkProof using the Transparent Load-Balancing configuration, the operation mode of the
device must be set to Transparent Forwarding. When operating within this configuration,
LinkProof can load balance the following types of farms only:

Remote IDS
IDS

The Servers configured in the IDS farms are "MACless" servers .

Configuration

Configuration is currently available via WBM and CLI only

WBM: Device -> Forwarding -> Device Operation Mode
Select the operation mode "Transparent Forwarding"
CLI: device operation-mode set 3
Default value is Traffic Redirection
Subnet Persistency Mask Mode
This persistency mask mode should be used when there is a need to reduce the number of Client
Table entries. All of the source IPs with the same subnet mask go through the same NHR.
Configuration

Configuration is currently available via WBM and CLI only

WBM: LinkProof->Global Configuration -> Client Table -> Subnet Persistency Mask
Select the Subnet Persistency Mask
CLI: lp global client-table subnet-persistency-mask
Default value is 255.255.255.255
Example

If the value is changed to 255.255.255.0, all entries with class C subnets will create a single entry in
the client table.
Note: Subnet persistency mask mode will only work when Client Table is in Layer 3 mode, please

refer to the LinkProof User Guide for how to change the Client Table mode.
Client Table Views
On all Radware devices, the Client Table maintains Client to Server Persistency. The Client Table is
accessible mainly using the CLI, but can also be accessed using Web Based Management.
The Client Table stores a vast amount of information about a clients source and destination IP and
ports, selected server, server port, NAT addresses and other product specific information. This
information is for thousands of users. This makes the task of viewing the Client Table entries via the

Page 12

LinkProof version 4.37 Release Notes

Date: October 10, 2009
Page - 13 -

Web Based Management almost impossible, causing the device to not be able to complete the
viewing task (BugID 47093).
A new option is now available via all management interfaces to filter the Client Table entries
according to the following criteria of client type:
Notes:
1) These client types are unique to LinkProof
2) The CT (client type) flag is casesensitive, and must use the exact phrases as they appear in this
list

any

- Any Client Type

regular

- Any client of the type Regular

dynamicNat

- Any Client receiving an dynamic NAT address

basicNat

- Any Client receiving a NAT address from Basic NAT

virtualIP

- Any client destined for a Virtual IP on the device

staticNAT

- Any Client receiving a NAT address from Basic NAT

noNat

- Any Client Matching the configured NoNAT addresses.

vpn

- Any Client matching VPN policy

remoteNatStaticNat

remoteNatNoNat

- Any Client matching Virtual Tunneling Policy with static

NAT Address policy
- Any Client matching Virtual Tunneling Policy with no
NAT Address policy

You can now set up to five different filters in order to filter the output of the Client Table, where the
logical condition between the filters is an OR condition (while the condition between the different
parameters within a filter is an AND condition). It is also possible to activate and deactivate each of
the filters (by default the filters are inactive.
Configuration

Configuration is currently available via WBM and CLI only.

WBM: To view the filtered Client Table, select the LinkProof >Clients-> Client Table
To configure the filters via WBM, select LinkProof-> Clients ->View Filters, and click the
filter you wish to edit.
CLI:
To view the filtered table, use the command lp client filtered-table
To configure the filters via CLI use the command lp client view-filters set
<index> followed by one or more of the following options:
-saf : Source IP From
Page 13

LinkProof version 4.37 Release Notes

Date: October 10, 2009
Page - 14 -

-sat : Source IP To
-daf : Destination IP From
-dat : Destination IP To
-spf : Source Port From
-spt : Source Port To
-dpf : Destination Port From
-dpt : Destination Port To
-sa : Server IP
-ct : Client Type
-st : Status

Example:

The command lp client view-filters set 1 saf 10.0.0.0 sat 10.255.255.25

dpf 80 -dpt 80 st 1 ct noNat creates and activates a filter which displays all clients with
source IP 10.x.x.x and destination port 80 on clients that match the configured noNAT addresses.
Passive FTP support
As of LinkProof 4.37 all passive FTP limitations have been removed and the protocol now is fully
supported.

Whats Changed
MIB change
The following changes have been made to this feature in this version:
MIB rsMLBServerClustersTable ID has been changed from 127 to 146 rendering the 127 number
unusable.

Upgrade Path
Boot versions required for LinkProof 4.37.00 are:
Application Switch 1 platform 4.53 to 6.01
Application Switch 2 platform 4.33 to 6.07
Application Switch 3 platform 6.04
Compact Application Switch platform 1.3 (only when upgrading from 4.30) or 1.4 to 6.012
Note: For Application Switches I & II with a SynApps license, it is recommended to use 256MB
with this version. Large BWM and/or Application Security configurations that fit in 128MB in
previous versions might require 256MB with this version.
Note: For LinkProof Branch before starting the upgrade procedure from version 3.81.0x, the boot
EPROM must be replaced with boot EPROM version 1.4 or higher (it is recommended to ask for the
highest boot version supported by the exact bug fix version you are upgrading to). Contact the
Page 14

LinkProof version 4.37 Release Notes

Date: October 10, 2009
Page - 15 -

Radware ordering department for this. If you are upgrading from version 4.30, no boot change is
required.
Upgrade Procedure
General upgrade instructions are found in the Installation and Maintenance Guide.
This version is available as a .zip file that includes, in addition to the software version, the utility for
upgrade from non-File System versions. For upgrade to version 4.37.xx, proceed as follows:
Upgrading from versions lower than 4.21

Read the Release Notes of version 4.21 for upgrade instructions and the Upgrade Procedure
to File System versions document.
Upgrading from 4.21.x or 4.30

Download the upgrade pack for your product from the Radware web site on to the computer to
be used for the upgrade.
Open the .zip file. The .zip file includes the new application software in .tar format.
For Compact Application Switch, Application Switch 2 and Application Switch 3, use the .tar
file to upgrade the device in the classic way (using WBM or CLI).
For Application Switch 1 please perform the following procedure:
1. Connect to the device via the serial port. Install on your computer the necessary files for
upgrade (boot, software version, config.ini).
2. Burn boot. To upgrade the boot perform the following steps:
a. Reboot the device; press any key to stop the auto boot. Type " u " to download the new
boot version. The following message appears:
>u
port ("com1", "com2" or ""): com1
baud rate (valid baudrate or "") 115200
For port use: "com1".
b. Send the new boot file to the device using the XMODEM protocol. The new boot version
is written into the non-active boot.
3. Enter @ to continue and run the old version. Since the dip-switch was not changed the old
boot is still active.
4. Download the software version (.tar file) via the Web-Based Management interface or CLI.
5. When the process ends, the following message appears in the CLI: Please toggle DPSW 1 to
select another boot bank. Reboot will be performed.
Toggle DIP switch 1 to select the newly burned boot and the device will reboot with the new
application.

Page 15

LinkProof version 4.37 Release Notes

Date: October 10, 2009
Page - 16 -

Related Documentation
The following documentation is related to this version:
Radware Installation and Maintenance Guide
LinkProof version 4.37 User Guide
Download the latest Radware product documentation from
http://www.radware.com/Customer/Portal/default.asp.

Known Limitations
The following are known limitations for this version:
Item Description
1. Cluster support is available in CLI and WBM only.

Bug ID
N/A

2. Force Port Down Feature supported only in WBM and CLI

N/A

3. Client Views supported only in WBM and CLI

N/A

4. Transparent Load Balancing supported only in WBM and CLI

N/A

5. Subnet Persistency Mask Mode supported only in WBM and CLI

N/A

6. New dispatch methods (L3 Hashing, SrcIP Hashing & Customized Hash)
supported only in WBM and CLI

N/A

7. Mirroring is not supported.

N/A

2009 Radware, Ltd. All Rights Reserved. Radware and all other Radware product and service names are registered trademarks of
Radware in the U.S. and other countries. All other trademarks and names are the property of their respective owners.

Page 16