Академический Документы
Профессиональный Документы
Культура Документы
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
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
For details on the support policy for retired versions, see the Certainty Support Guide.
Application Switch 1
Application Switch 2
Lowest
Boot
Version
4.53
4.33
Platform
Lowest
Boot
Version
Application Switch 3
Compact Application
Switch
6.04
1.3*, 1.4**
6.04
6.012
Supported Version
3.402
10.03-01.08DL
11.05.03
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
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)
Page 5
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
This feature can be configured via WBM (Redundancy -> Global Configuration) or CLI (the
redundancy force-down-ports-mode command). The available parameters are:
The following is important for proper functionality of VRRP capability in general and with VLAN
in particular:
Limitations
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
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
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
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
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
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
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
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
regular
dynamicNat
basicNat
virtualIP
staticNAT
noNat
vpn
remoteNatStaticNat
remoteNatNoNat
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
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
-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:
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
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
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
N/A
N/A
N/A
N/A
6. New dispatch methods (L3 Hashing, SrcIP Hashing & Customized Hash)
supported only in WBM and CLI
N/A
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