2.
Certificate Fields Only the fields listed in the table are ed.
Notes: >> Since the match is substring-based, it is not necessary to provide values in full format. Therefore, if a configured value is a substring of the value given in a certificate, there will be a match. >> The matching of certificate fields content is exact, partial strings matches will fail. This means that to match an issuer or subject, for example, the full DN should be specified and not CN only. i.e. “CompanyCA” will fail because it is CN value only, and full DN such as “C=US, O=MyCompany, CN=CompanyCA” will match.
212
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration
Table 1: Certificate Validation Policies Values Formats per Field/Extension.
Field Name
Format
Example
Version
Number (decimal)
3
Serial number
Hex String
0x5057
Issuer
ORGANIZATION common format
C=US, ST=NY, L=NA, O=Radware, OU=CT100, CN=client_1/ [email protected]
Subject
ORGANIZATION common format
C=DE, O=gematik LTU, CN=brk002as3.gematik.net/ serialNumber=rel234 BROKER SSL-C 515.00
Public key: g Algorithm
One of the following values: • rsaEncryption • dsaEncryption
Public key: Length
Number (decimal)
1024
Signature Algorithm
One of the following values:
sha1WithRSAEncryption
• md2WithRSAEncryption • md4WithRSAEncryption • md5WithRSAEncryption • sha1WithRSAEncryption • dsaWithSHA • dsaWithSHA1 • dsaWithSHA1-old • ecdsa-with-SHA1 • mdc2WithRSA • ripemd160WithRSA • sha224WithRSAEncryption • sha256WithRSAEncryption • sha384WithRSAEncryption • sha512WithRSAEncryption 3. Known certificate extensions
Document ID: RDWR-AD-V021403-UG0211
213
AppDirector Guide Traffic Management and Application Acceleration The list below shows extensions that are known and explicitly formatted by openssl.
Extension Name
Format
Example
Subject Key Identifier
Hex String
19:71:D3:07:AD:60:88:5C:C3:A0:3F :AE:B2:52:08:EC:47:CC:11:1B
Key Usage
One or more of the following values, comma separated
Digital Signature, Non Repudiation
• Digital Signature • Non Repudiation • Key Encipherment • Data Encipherment • Key Agreement • Certificate Sign • CRL Sign, Encipher Only • Decipher Only Subject Alternative Name
One or more of GENERIC NAME formats, comma separated (same type may appear more than once)
email: [email protected], URI:http:// my.url.org
Issuer Alternative Name See Subject Alternative Name Basic Constraints
CA:FALSE
CA:FALSE
Since client certificate can never be CA, other possible formats are irrelevant Certificate Policies
Policy:
Authority Key Identifier
Hex string
CRL Distribution Points
One or more of the GENERIC NAME formats, comma separated.
URI:http://my.com/my.crl,URI:http:// oth.com/my.crl
(reasons and crlIssuer extension sub-fields are not ed) Authority Information Access
214
[OCSP]/[CA Issuers] -
OCSP - URI:http://ocsp.my.org/
Where
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration
Extension Name Extended Key Usage
Format One or more of the following values or OIDs (dot notation), comma separated:
Example Netscape Server Gated Crypto, Microsoft Server Gated Crypto, 2.3.4.5
• Code g • E-mail Protection • Time Stamping • Microsoft Individual Code g • Microsoft Commercial Code g • Microsoft Trust List g • Microsoft Server Gated Crypto • Microsoft Encrypted File System • Netscape Server Gated Crypto • TLS Web Server Authentication • TLS Web Client Authentication Netscape Certificate Type
One or more of the following values, comma separated
SSL Client
• SSL Client • SSL Server • S/MIME • Object g • Unused • SSL CA • S/MIME CA • Object g CA Netscape Base URL
String
Netscape Revocation URL
String
Netscape CA Revocation String URL Netscape Renewal URL
String
Netscape CA Policy URL
String
Netscape SSL Server Name
String
Netscape Comment
String
Thawte Strong Extranet
Version:
Document ID: RDWR-AD-V021403-UG0211
Version: 2 (0x3); Zone: zone1
215
AppDirector Guide Traffic Management and Application Acceleration
Extension Name
Format
Subject Information Access
See Authority Information Access
Proxy Certificate Information
Path Length Constraint: [
Inhibit Any Policy
Number (decimal)
Name Constraints
Permitted:<list of permitted entities GENERIC NAME format, separated by semicolon>;
Example
Excluded: <list of permitted entities in GENERIC NAME format, separated by semicolon> 4.
-Defined Certificate Extensions Unknown certificate extensions formatting is done as follows: —
Extension Name format can only be specified as OID
—
Extension Value format is list of parsed as ASN1 types separated by colon.
Example Extension Name: 1.3.36.8.3.3 Extension Value: countryName:DE:organizationName:gematik:Broker:1.2.276.0.76.4.88
216
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration
Application Acceleration
Enhanced Acceleration This section refers to when Application Acceleration features are enabled and includes these topics: •
Benefits of Application Acceleration, page 217
•
Enabling Application Acceleration, page 218
•
Acceleration Policies, page 219
Benefits of Application Acceleration The proliferation of new web enabled applications coupled with the trend of data center consolidation put great strain on web application servers that need to cope with ever increasing transactions volume. Growing portion of these applications use SSL (Secure Socket Layer) encryption as mean to secure and protect the privacy of sensitive information, common examples are e-commerce shopping carts, e-banking, and more. However, servers are very inefficient in processing encrypted transactions. Processing encrypted transactions require a much higher allocation of U resources than do simple Web page serving, in some cases, as seen in figure 3 performing SSL encryption/ decryption is 100 times more demanding than handling the same request as clear text. Performing these SSL calculations slow Web server performances, leading to inconsistent experience, and even downtime. AppDirector’s application acceleration features relieve Web servers from performing U intensive SSL calculations by handling all the associated encryption, decryption, session and certificate management tasks. Unlike Web servers, AppDirector is optimized to perform SSL calculations, using dedicated ASIC-based hardware and software. Offloading these SSL calculations relieves Web server Us allowing it to serve the application in a greater efficiency.
Compression Today’s Web-based applications which are richer in their textual and visual content still run over non-optimized HTTP protocol, which was originally designed for dial-up speed applications and one way transfers of data between two machines, and is therefore less efficient at dealing with the new types of multi sequence and high bandwidth web traffic. This “chatty” nature of HTTP and the growing volume of each transaction, due to the richer content, slow response time considerably and consume expensive bandwidth. A Radware hardware-based compression solution can ensure optimal application delivery and bandwidth savings, as can be seen in figure 4, through compression of web pages such as HTML and JavaScript in real-time before transmission on the network. This is important especially for small remote offices and home offices s where bandwidth may be limited. This dynamic HTML compression accelerates traffic by reducing the payload using an open compression standard (gzip and Deflate), providing a powerful performance boost since HTML is an ASCII text, which is highly compressible. The of industry-standard gzip algorithm (as well the Deflate algorithm) ensures compatibility with virtually all popular web browsers without requiring any special software installation on the end- machine. AppDirector offers options to control compression behavior. These capabilities include the ability to define whether objects should be compressed for Browser, Content-Type or URL specific behavior, and view and use Predefined exceptions of the default compression behavior based on known Browsers limitations.
Document ID: RDWR-AD-V021403-UG0211
217
AppDirector Guide Traffic Management and Application Acceleration
Caching Web pages are composed of a series of objects. Many of these objects are static objects that are the same from page to page. Radware AFE can automatically recognize requests for such objects and retrieve them directly from the device’s local cache without fetching them from the web server. This capability offloads the server from dealing with unnecessary requests and as the same time accelerates objects delivery to the end-. Caching can also save transformed objects at the cache such as different versions of a given image that has been compressed and optimized differently for various end s and end s' devices (as it was explained in the Image optimization section). Radware’s caching is fully compliant with RFC 2616 of HTTP 1.1. It respects all relevant HTTP Headers (such as: Cache-control, Expires, Authorization, and Pragma), which are the Web Application means of dictating which content is to be cached and when it should be refreshed. AppDirector has options to determine its Cache behavior, both in of which content to cache, and in of which content to serve to clients from Cache or from Servers. AppDirector Cache policy includes the option to define per URL caching behavior and cache maximum time, and the option to better leverage client Browser's cache to improve response times and QoE.
Enabling Application Acceleration To access these AppDirector features you need the Application Acceleration Engine set to Enabled.
Enhanced Acceleration
To enable Acceleration and Compression 1.
From the AppDirector menu, select Global > Tweaks. The Tweaks window appears.
2.
Within the Tweaks window, ensure that you select the Acceleration Engine parameter and mark as Enabled.
3.
This process will require a device reboot.
Standard Acceleration
To disable Acceleration and Compression 1.
From the AppDirector menu, select Global > Tweaks. The Tweaks window appears.
2.
Within the Tweaks window, ensure that you select the Acceleration Engine parameter and mark as Disabled.
3.
This process will require a device reboot.
Caution: You will not be able to a configuration file with Application Acceleration Enabled when the device is in Application Acceleration Disabled mode
218
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration
Acceleration Policies
Enhanced Acceleration AppDirector provides end-to-end performance acceleration of Web-based applications for all ends types such as desktops, PDAs and smart-phones. AppDirector also uses advanced and granular application intelligence (Layer 7 load balancing) for end-to-end business-smart networking. This section describes the configuration necessary to activate acceleration mechanisms and to finetune HTTP content-based load balancing. It includes the following: •
Copy Rule Lists, page 219
•
Caching Policies, page 220
•
Caching URL Rule Lists, page 222
•
Compression Policies, page 224
•
Compression Browsers Exception Rule Lists, page 226
•
Compression URL Rule-Lists, page 227
Rule Lists To assist configurable compression and caching, Radware has developed Rule - Lists (lists of rules) that match defined patterns on a set of HTTP headers ( Agent, MIME Type) or URI and determine whether to perform an action (compress or cache). Rule-Lists are scanned for a match until the first match is found. Therefore, rules priorities that determine rule order are important.
Leveraging Rule List Behavior Rule-Lists behavior is where rules are scanned from top to bottom according to their set priority, and once a match is found, the action designated in this rule is performed, and the Rule-List will not be scanned for further matches. This allows you to create exceptions for exceptions within the same Rule-List. For Example, if you have a folder containing cacheable objects (e.g. Images folder) and within a folder containing non-cacheable objects (e.g. content updating, reports, graph images), you can set a rule of priority 1 that will match the Non-Cacheable objects folder (Graphs folder), followed by a more general rule with priority 2 to cache all father-folder objects (images folder). When the Rule-List is scanned for a match, the more specific exception is matched first, without continuing to match again on the more general expectation, thus receiving the required behavior.
Copy Rule Lists Since Rule-Lists may contain many rules, and often the same list can be required but with only minor changes, AppDirector allows you to copy Rule-Lists into a new Rule-List. To duplicate an entire rule list, you need: •
to define name of source rule list (source for Copy)
•
to define name of target rule list from list of existing Rule-lists or new (Destination of Copy)
When Set is pressed, all rules are copied from Source to Destination.
Notes: >> If rules already exist in the Destination policy, you will receive the following message: "The target Rule List already contain rules. To avoid accidental
overwrite, please delete rules or entire Rule-List and retry." >> Overwrite of existing Rule-List using Copy Rule List is not allowed.
Document ID: RDWR-AD-V021403-UG0211
219
AppDirector Guide Traffic Management and Application Acceleration
To use the AppDirector Copy Rule Lists 1.
From the AppDirector menu, select Layer 4 Traffic Redirection > Copy Rule Lists. The AppDirector Copy Rule List window appears.
2.
Set the parameters.
Parameter
Description
Rule-List Type
Type of Rule-List to be copied. • None (default) • Compression Browser Exception List • Compression URL Exception List • Cache URL Policy List
Source Rule List Name
Select from already defined rule lists of defined type above.
Destination Rule List Name
Define name of new Rule-List to which all rules in Source Rule-List are copied.
Default: none
Default: none 3.
Click Set. Your configuration is set.
Caching Policies AppDirector s caching of HTTP traffic. Caching improves the overall network performance. Using caching, backend servers are required to serve less content, which can save on fetching data and creating dynamic HTML pages. Caching can also decrease the number of required T connections to the backend servers. It allows a more efficient use of compression features, as AppDirector can cache compressed objects, and save the need to re-compress the same object for each client request. Caching is memory based. Once Caching is enabled for one Layer 4 Policy or more, up to 50% of available Acceleration Engine memory is used for cache. The amount of memory used depends on traffic and the cached objects and is configurable from 1 % - 50% (default 20%) in the Tuning Table.
Note: If a Caching policy is defined, by default the action is cache all the content.
Using Leverage Browser Cache parameter When cached content is served by AppDirector to a clients browser, the client experiences better Quality of Service (QoS) than if it was served from the server. Further enhancement to client QoS is achieved when the clients Browser caches the content for reusing on the next request that will need it. However, not all content is optimally cached by browsers thus failing to provide the best possible QoS. AppDirector can optimize the browser caching by updating the Cache-Control directives on every cache-served object. The object headers are updated to reflect the future time it can be cached for by the browser according to the AppDirector cache time (whether from server headers or AppDirector Cache URL Exceptions Rule-List). AppDirector will also ensure that the content will not be served from the browser cache after it is considered stale. AppDirector will provide the browser with the time that already exists in the AppDirector Cache, so that the browser can calculate the remaining time correctly.
220
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration
To configure AppDirector Caching Policy 1. From the AppDirector menu, select Layer 4 Traffic Redirection > Caching Policies. The AppDirector Caching Policy window appears. 2. Set the parameters.
Parameter
Description
Policy Name (Mandatory)
Name of the Policy.
Minimum Object Size [Bytes]
Minimum size of object in bytes to be stored.
Maximum Object Size [Bytes]
Maximum size of objects in bytes to stored.
Default: Empty Default: 1024 bytes Default: 102,400 bytes
Expiration [seconds] Maximum time that an object is kept, even if the object header is specified longer. If the object header or configuration via Cache URL RuleList is specified less, it is purged according to its header / configuration. Default: 86,400 (24 hours) Leverage Browser Cache
You can modify caching headers to leverage client side (browser) cache: For objects marked for caching: Add/modify objects' HTTP headers to include Cache-control: public, maxage=X. X is derived from general cache settings or from the URI rule responsible for caching the specific object. Values: Enabled/Disabled (default).
Respect Server Headers
Specifies how Server Response cache headers are treated. • Respect-All (e.g.RFC behavior) - If no header is sent by the server specifying the cacheability of the object, AppDirector caches the object. • Cache-All - caches everything regardless of headers. In both modes, Cache URI rules override and allow for Exception. Values: Respect All (default), Cache All . Note: If a Caching policy is defined by default, the action is cache all the content.
Respect Client Headers
Specifies how Client request cache headers are treated: • Respect-All (i.e. RFC behavior) - in this mode must-validate, ifmodified, etc. headers are enforced as "get fresh from Server" and request is forwarded to server. • Respect Refresh headers only - causes only the following headers in client requests to be respected: "max-age=0", "no-cache", "pragma:no-cache". All other content is served from cache if it exists there. • Serve All from Cache - ignores all client side headers serving from cache anything that exists there. Values: Respect All (default), Respect Refresh headers only, Serve All from Cache.
Document ID: RDWR-AD-V021403-UG0211
221
AppDirector Guide Traffic Management and Application Acceleration
Parameter
Description
URL Exceptions Rule Disable or select from list of Cache URL Rule lists. List Default: Disable Note: You can define Domain without anything in the URL field to use-cases of different behavior per domain. However, if Domain is not defined (Domain_type=none) then the URL field is mandatory. Ignore Query Parameters
Specifies whether query parameters added to object URL should be ignored when saving/serving object from cache. Values: Enabled (default)/disabled
3.
Click Set. Your configuration is set.
4.
In the required Layer4 policy, select the Cache policy that you configured.
To purge cache 1.
From the AppDirector menu, select Layer 4 Traffic Redirection > Caching Policies. The AppDirector Caching Policy window appears.
2.
Select any Layer 4 policy or All.
3.
Click Set. Cache is purged.
Caching URL Rule Lists AppDirector allows you to define Cache behavior in of caching responses and serving requests from cache. You can define rules that determine whether to cache on top of the RFC headers decision. If rules specify caching, you can then configure the time (in seconds) of the object to be cached. The Cache URL Exception Rule-List is used to create exceptions to the set responses caching behavior and can be used alternatively as in a positive model or negative model.
Using Cache URL Rule-List in Negative model When Cache Policy “Respect Server Headers” parameter is set to “Cache All”, AppDirector does not inspect HTTP responses Headers for “Cache-Control” directives. Whenever a received object is within the size limits (Minimum size-Maximum Size) set in the Cache Policy, it is Cached. This mode assumes that the Web Server was not configured to send correct Cache-Control directives. Here, you need to provide, in the URL Exception Rule-List, a list of all objects URIs that should not be cached.
Using Cache URL Rule-List in Positive model When Cache Policy “Respect Server Headers” parameter is set to “Respect All” AppDirector inspects every response HTTP headers and caches them according to “Cache-Control” headers directives. This mode assumes that the Web Server was configured correctly to provide the right Cache-Control directives for every object. However, you may want to make exceptions to caching behavior and configure using the server headers, where you can use the URL exceptions Rule-List. In this model the Rule-List will include mainly positive (Cache) expectations to server received behavior per URI.
222
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration
To configure the AppDirector Caching URL Rule List 1. From the AppDirector menu, select Layer 4 Traffic Redirection > Caching URL Rule Lists. The AppDirector Caching URL Rule List window appears. 2. Set the parameters.
Parameter
Description
Rule-List Name
There are multiple rule-lists. Each is a policy that contains multiple rules. Default: none
Rule Priority
Location of the rule in the Rule-List. Since Rule-Lists are scanned for a match from top (priority 1) to bottom (priority ~65000) this enables you to set the location of the rule in the rule-list. See Leveraging Rule List Behavior, page 219.
Rule Name
Name of each rule in the Rule-List used to identify it. Default: Empty
Domain Comparison Defines whether should be evaluated as a String or Regular Expression Method Values: None (default)/Text Match/Regular-Expression Domain
Defines the Virtual Host for which this rules applies Note: When the Domain Comparison Method is defined as "None" this field cannot be used. If Domain Comparison Method is defined as Text Match or RegEx, it must be defined.
URL Comparison Method
Defines whether URL field should be evaluated as String or Regular Expression Values: Text Match (default)/Regular-Expression
URL
Define URL of specific object (file/folder) to be matched by this rule. Default: empty
Cache
Values: Enable/Disable (Default)
Expiration Time
Values: 0 - 86400 (24hr)- default. Note: Time is accepted only if Cache is enabled. If Value is set to 0 then cache time is set according to the minimum between time from server header (Expires or Max-Age headers) and the Cache policy Max-time-to-cache parameter. This allows you to create rules that force caching without affecting the time set by the servers. This is useful when you create a general rule for No-Cache and want to create an exception within it. For more information on these exceptions see Leveraging Rule List Behavior, page 219.
3. Click Set. Your configuration is set.
Document ID: RDWR-AD-V021403-UG0211
223
AppDirector Guide Traffic Management and Application Acceleration
Compression Policies HTTP Compression is a publicly defined way to compress content (mostly textual) transferred from Web servers across the world wide Web to browsers. The impact of compression is that the number of transmitted bytes is reduced and thus a higher performance is gained. HTTP Compression uses public domain compression algorithms to encode HTML, XML, JavaScript, CSS and other file formats at the server-side. AppDirector Compression policy includes 3 levels of optional exceptions. The First level is a list of known problems (bugs) in commonly used browsers that cause them to mishandle specific types of compressed content and thus predefined expectations exists to avoid these problems. This list can be viewed as the in the Browsers Exceptions Rule-List screen as the “Predefined Browser Limitation Rule-List”. The “Predefined Browser Limitation Rule-List” can be customized by copying it using the Copy Rule-Lists into a new Browser Exceptions rule list. The second level of exceptions provided in the form a customized Browser exceptions Rule-List that can define compression behavior in term of browser type (-Agent) and Content-Type (File type as it appears in Object headers). The third level of exceptions allows defining very specific compression behavior per URI, similarly to Cache URL exception Rule-List. Exceptions are evaluated from most granular (URL Exceptions) through to more gross ones (Browser Exceptions) to the most general ones (Predefined Browser Limitations) to allow to use them a narrowing series of filters. You can configure compression of HTTP content from AppDirector to the client. AppDirector s either Gzip or Deflate algorithms. AppDirector has a default compression by software service. The compression level indicates how much the file is compressed. It does not indicate the compressed file size, this depends on the file content itself.
To configure the AppDirector Compression Policy 1.
From the AppDirector menu, select Layer 4 Traffic Redirection > Compression Policies. The AppDirector Compression Policy window appears.
2.
Set the parameters.
Parameter
Description
Policy Name (Mandatory)
Name of Policy.
Algorithm
Used for defining the preferred compression algorithm which is used by AppDirector if client can receive both Gzip and Deflate compressed content.
Default: Empty
Values: Gzip (default), Deflate Engine
Defines the type of compression engine used and enables you to choose software compression or hardware compression. Default: Software (if Hardware card is installed, default becomes Hardware. If not installed Hardware is not allowed).
Minimum Content Length (Bytes)
Minimum file size to be compressed to avoid wasting resource on files that are already small. Default: 10240 Bytes Note: If content length header is not specified, limit does not apply
224
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration
Parameter
Description
Maximum Content Length (Bytes)
Maximum value of Content Length header in K-bytes of the object to be compressed. Values: From size configured in Minimum Content Length to 104857600 Bytes Default: 104857600 Bytes Notes: • If content length header is not specified, then limit does not apply. • Value is 0 (unlimited) following upgraded Compression policies.
Compression Level
Used for setting the Gzip compression level. Values: Low <1 (default) > 9 High. ( Gzip software compression only). Note: Changing the compression level to > 1 has a severe impact on throughput and only a minor reduction in compressed file size.
Allow Compression By Server
This deletes the Accept Encoding Header from requests sent to the server to prevent it from performing compression. Values: Disabled (default)/enabled
Use Predefined Browser Exceptions
Enable or Disable workarounds for browser limitations for compression according to their type. Values: • Predefined Browser Limitations List (default) • None Note: Predefined Browser Exceptions are defined in the Predefined Browser Limitations Rule-List that can be found in the Compression Browsers Exception Rule Lists, page 226.
Browser Exceptions Rule List
Helps to skip compression of certain objects that create a problem when uncompressed or require too much resource with little benefit (e.g. PDFs & PPT folder). Values: None (default)/Specific URL
URL Exceptions Rule List
Define specific URLs (files/folders) for which all other settings should be overridden and compression or no-compression should be done. Values: None (default)/Specific URL Notes: • You can define Domain without anything in the URL field to use-cases of different behavior per domain. • However, if the Domain is not defined (Domain_type=none), then the URL field is mandatory.
3. Click Set. Your configuration is set. 4. In the required Layer 4 policy, select the compression policy that you configured
Document ID: RDWR-AD-V021403-UG0211
225
AppDirector Guide Traffic Management and Application Acceleration
Compression Browsers Exception Rule Lists This enables you to define Rule-Lists of Compression exceptions based on -Agent (Browser type) or Content-type (file type). These exceptions are evaluated after the Compression URL exceptions, so they can be overrided by them, if needed.
To configure the AppDirector Compression Browser Exceptions Rule List 1.
From the AppDirector menu, select Layer 4 Traffic Redirection > Compression Browsers Exceptions Rule Lists. The AppDirector Compression Browser Rule List window appears.
2.
Set the parameters.
Parameter
Description
Rule List Name
Rule-List name. There are multiple rule-lists. Each Rule-List is a policy that contains multiple rules. Default: Empty
Rule Priority
Location of the rule in the Rule-List. Since Rule-Lists are scanned for a match from top (priority 1) to bottom (priority ~65000). Default: 200 This enables you to set the location of the rule in the rule-list. See Leveraging Rule List Behavior, page 219.
Rule Name
Name of each rule in the Rule-List used to identify it. Default: Empty
Agent Comparison Method
Defines whether UA field should be evaluated as String or Regular Expression. Values: Text Match (default), Regular Expression
Agent
Client program used to access servers on a network. Values: Empty (default), Regular, Regex
Content Type Comparison Method
Defines whether this should be evaluated as String or Regular Expression. Values: Text Match, Regular Expression
Content Type
Define Content Type string to match for this rule. Default: text/html
Compress 3.
Values: Enabled (Default),Disabled
Click Set. Your configuration is set.
Note: To manage Rule-Lists efficiently, use the filter boxes at the top of the Rules table.
226
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration
Compression URL Rule-Lists This enables you to define Rule-Lists of Compression exceptions based on object URL (file/folder). These exceptions are first evaluated making them the most granular means of defining compress/ don't-compress behavior.
To configure the AppDirector Compression URL Rule List 1. From the AppDirector menu, select Layer 4 Traffic Redirection > Compression URL RuleLists. The AppDirector Compression URL Rule List window appears. 2. Set the parameters.
Parameter
Description
Rule-List Name
Rule-List name. There are multiple rule-lists. Each Rule-List is a policy that contains multiple rules. Default: Empty
Rule Priority
Location of the rule in the Rule-List. Since Rule-Lists are scanned for a match from top (priority 1) to bottom (priority ~65000) this enables to set the location of the rule in the rule-list. See Leveraging Rule List Behavior, page 219. Default: 1
Rule Name
Name of each rule in the Rule-List used to identify it. Default: Empty
Domain Comparison Allows defining different behavior for specific URLs within different virtual Method hosts on the same server. Defines whether used at all (None), or to be evaluated as a String or Regular Expression Values: None (default)/Text Match/Regular-Expression Domain
Defines the Virtual Host for which this rules applies Notes: • When Domain Comparison Method is defined as "None" this field cannot be used. • If Domain Comparison Method is defined as Text Match or RegEx it must be defined.
URL Comparison Method
Defines whether URL field is to be evaluated as String or Regular Expression Values: Text Match (default)/Regular-Expression
URL
Define URL of specific object (file/folder) to be matched by this rule. Default: Empty
Compress
Values: Enable/Disable (Default)
3. Click Set. Your configuration is set.
Note: To manage Rule-Lists efficiently, use the filter boxes at the top of the Rules table.
Document ID: RDWR-AD-V021403-UG0211
227
AppDirector Guide Traffic Management and Application Acceleration
Layer 7 Traffic Management This section describes the different capabilities available for application-aware traffic management and includes these topics: •
Layer 7 Methods, page 228
•
Layer 7 Farm Selection, page 234
•
Layer 7 Statistics, page 237
•
Layer 7 Modification, page 238
•
Layer 7 Server Persistency, page 252
Layer 7 Methods A Layer 7 Method defines a specific criteria (namely the existence or non existence of certain specific content within the message), evaluated on a specific part of each handled message. Layer 7 Methods are used in load balancing and modification decisions. A condition will evaluate to TRUE only if all values specified in the method match values appearing in the specified part of the message. In addition, Layer 7 Methods are used to define the modification required on the traffic (different Layer 7 method is used to identify the traffic where modification is necessary). The following table shows the available Layer 7 methods and where they can be used:
Table 2: Layer 7 Methods
Method Type Identifies
Available for Layer 7 Farm selection
Available for Layer 7 modifications Identify traffic (Match)
Modify traffic (Action) Insert*, Replace
URL
Hostname and/or path in Host header x or in URL for proxy requests
Insert, Remove*, Replace
File Type
File type in URL
x
Insert, Replace, Replace Remove
Header Field
Header field
x
Insert, Remove, Insert, Replace Replace
Cookie
Cookie header in request message
x
Insert, Remove, Insert, Replace Replace
Regular Expression
String anywhere in message (for Layer 7 modifications only in header area)
x
Insert, Remove, Replace
Text
String anywhere in message (for Layer 7 modifications only in header area)
x
Insert (Header Insert (Header Only), Remove, Only) Replace Replace (Header and Body)
Status Line
Status Line
Insert, Replace
Set Cookie
Set Cookie Header
Insert, Remove, Insert, Replace Replace
Advanced URL in request message or HREF in URL Condition response body
228
Replace
Replace
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration
Method Type Identifies
Available for Layer 7 Farm selection
Advanced URL Modification
URL in request message or HREF in response body
RADIUS Attribute
Specified RADIUS attribute value
Available for Layer 7 modifications Identify traffic (Match)
Modify traffic (Action) Insert, Replace
x
Note: >> All content settings of the Methods are case sensitive. >> * - Only URL methods that have Path argument but no Host argument can be used.
To configure Layer 7 methods 1. From the AppDirector menu, select Layer 7 Farm Selection > Methods. The Method Table window appears. 2. Click Create. The Method Table Create window appears. 3. Set the parameters.
Parameter
Description
Method Name
Name that you want the method to be recognized as. Example: Method Name = Test 1
Method Type
Select one of the method types as shown above. Example: Method type = Header Field
Arguments
Appropriate argument type will appear when clicking the file selection icon. Select according to Hostname and Path.
4. To define the arguments relevant to the selected method, click the option The arguments window for the selected Method type appears.
button alongside.
Note: In the case of “Advance URL Condition” and “Advance URL Modification”, arguments appear as fields in the Method Create/Edit window and not as separate windows.
Document ID: RDWR-AD-V021403-UG0211
229
AppDirector Guide Traffic Management and Application Acceleration This table describes the various arguments for available Method Types.
Table 3: Layer 7 Method Arguments
Method Type
Method Specific Parameters
Description
Example
URL
Host Name
Host name part of URL in the header.
Host Name = www.a.com
Values: None (default), define string. String should be according to hostname limitations. Path
Path part of URL in the header indicates matching/action on path
Path = cgi-bin
Values: None (default), string up to 256 characters. String can contain only characters allowed in path. File Type
File Type
Type of file in the URL
TYP=html
Header Field
Header Field
Specific header field (mandatory)
HDR=AcceptLanguage|TKN=en -us
Note: If the value of header field is null (no value) then it acts as a wildcard so that there is a match for any packet with such a header with any value. Token
Value inside the specific header field
TKN=en-us
Cookie
Cookie Key
Available only if you have Cookie Persistency License.
Specific Cookie Key in the request Cookie header (mandatory)
KEY= server|VAL=red
Cookie Value
Specific Cookie value
VAL=red
Regular Expression
Regular Expression (string pattern matching)
EXP=.abc
Regular Expression
230
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration
Table 3: Layer 7 Method Arguments
Method Type
Method Specific Parameters
Description
Example
Set Cookie
Key
A specific Cookie Key in the reply Set Cookie header (mandatory)
KEY=server
Value
Specific Cookie value
VAL=red
Path
Path part of URL
P=cgi-bin
Domain
Domain to be added to the cookie
DMN=service.com
Expire After
This determines for how long the client EA=3H. can use this Cookie. This value is added to the system time at the moment of insertion and included in the cookie, to determine the exact time when this cookie expires. The value is followed by a letter that determines the time unit used as follows: S = seconds M = no letter for minutes H = hours D = days For example: 24H for 24 hours 60M for 60 minutes 1440S for 1440 seconds 1D for 1 day.
Status Line
Status Code
Reply Status Code
SCD=404
Status Text
Text accompanying status code.
SPHS=Not Found
Text
Text
String
TXT=abcdefg
Radius Attribute
Attribute Number
RADIUS attribute number (AN)
AN=1
Vendor ID
Vendor ID for Vendor Specific attribute VI=311 (VSA). Only relevant when Attribute Number is 26.
Vendor Vendor specific attribute type allows to VT=6 Specific search for a specific sub-attribute Attribute Type inside a vendor specific attribute. Relevant only when Attribute Number is 26. Attribute Value Values of type string (ASCII), integer or IP address only are ed. For Vendor Specific attributes only values of type string are ed.
Document ID: RDWR-AD-V021403-UG0211
AV=domain.com
231
AppDirector Guide Traffic Management and Application Acceleration
Table 3: Layer 7 Method Arguments
Method Type
Method Specific Parameters
Description
Example
Match Type
Defines how requested attribute value M=S is searched within the packet attribute value. Applies to “string” values, only. Values: • Equal (EQ) • Contain (CT) • Prefix (P) • Suffix (S)
Enhanced Acceleration Advanced URL Condition
Protocol
Type of protocol selected:
e.g. HTTP.
Values: None (default)/HTTP /HTTPS Host Name
Host name part of URL in HTTP header. Host Name = Values: Empty (default), define string. www.a.com String according to hostname limitations.
Hostname Match Type
Indicates how hostname matching of sting is performed. Values: None (default), Equal, Contain, Prefix, Suffix
Port
Indicates matching/action on Port. Values: 0 (default), Port number
Path
Path part of URL in HTTP header indicates matching/action on path
Path = cgi-bin
Values: Empty (default), string up to 256 characters. String can contain only characters allowed in path. Note: if there is no dot in the last element of a path, the entire string, until the end of URL or first non-alphanumeric char is called a Path and there is no page element there. Therefore in these examples: http://abc.com/XXXX/ YYY?param http://abc.com/XXXX/YYY Radware refers to the path as “XXXX/YYY” .
232
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration
Table 3: Layer 7 Method Arguments
Method Type
Method Specific Parameters
Description
Page Name
Indicates matching/action on Page name.
Example
Values: Empty (default), define string Page Type
Indicates matching/action on page type Values: Empty (default), define string of file extension
Path Match Type
Indicates how path matching of sting is done Values: None (default), Equal Contain, Prefix, Suffix
Advanced URL Modification
Protocol
Type of protocol selected:
e.g. HTTP.
Values: None (default)/HTTP /HTTPS Host Name
Host name part of URL in HTTP header. HN= Values: Empty (default), define string. www.a.com or String should be according to HN=www.a.com|P hostname limitations. =cgi-bin
Port
Indicates matching/action on Port. Values: 0 (default), Port number
Hostname ActionType
Indicates action to be taken on hostname Values: None (default), insert before, insert after, remove, replace
Path
Path part of URL in HTTP header indicates matching/action on path
P=cgi-bin
Values: Empty (default), string up to 256 characters. String can contain only characters allowed in path Path Action Type
Indicates matching/action on page type Values: None (default) or define string of file extension.
Page Type
Indicates matching/action on page type Values: Empty (default), define string of file extension
Page Name
Indicates matching/action on Page name. Values: Empty (default), define string
5. Select the options as shown in the table above and click Set. You are returned to the main Method Table window. 6. Click Set. Your configuration is set.
Document ID: RDWR-AD-V021403-UG0211
233
AppDirector Guide Traffic Management and Application Acceleration
Dynamic Values for Method Parameters (Tokens) When Layer 7 methods are used to modify HTTP, AppDirector can define the value to be used to insert or update a Layer 7 header (Layer 7 method argument) as dynamic information taken from the traffic. The following values can be used:. The variables can be used in conjunction with static text; for example, 'External-IP-port: $VIP:$VIP_Port'. To indicate a $ in the text, use $$.
Layer 7 Farm Selection The Layer 7 content aware decision making mechanism allows providing multiple services via a single entry point (IP and application port). For example: •
Providing content to end s based on language and/or type of browser (PC or mobile).
•
Providing differentiated service to e-commerce customers based on what they want to buy (URL).
Layer 7 farm selection is available for: •
HTTP or other HTTP-like (has HTTP-like header) T protocols.
•
UDP protocols.
Notes: >> When performing Layer 7 farm selection for UDP traffic, AppDirector inspects each packet separately and selects the appropriate farm and server. >> Layer 7 farm selection is NOT available for dynamic protocols, such as FTP and TFTP.
Layer 7 Farm Selection Flow 1.
When AppDirector receives the first packet of a session destined to a Virtual IP address, it searches for a Layer 4 Policy that matches the Layer 4 Protocol, Destination Port, Source IP, etc. (see Layer 4 Policies Lookup Mechanism, page 186).
2.
If the matched Layer 4 Policy is for T traffic and is linked to a Layer 7 Policy, Delayed Binding is activated.
3.
AppDirector performs a T handshake with the client to receive the application request.
4.
When AppDirector receives enough information, it matches the data in the request with each one of the entries of the Layer 7 Policy attached to that specific Layer 4 Policy. If traffic is UDP, the matching process is performed for each packet.
5.
Once a match is found, AppDirector load balances the traffic to the farm defined in the matched entry. For HTTP, HTTPS and SIP, the action of a Layer 7 policy can be to redirect the traffic, instead of load balancing it to a farm.
6.
AppDirector selects the best server for the task from the farm providing the requested service.
7.
When traffic is T AppDirector initiates a T handshake with the server and forwards traffic, once T connection is established. For UDP, AppDirector just forwards the traffic to the selected server.
Configuring Layer 7 Farm Selection Layer 7 farm selection is configured by defining Layer 7 policies and attaching each Layer 7 policy to a Layer 4 policy. Each Layer 7 policy can include a number of entries. Each entry defines Layer 7 condition and the action - load balancing to a specific farm or redirection to a specific destination (host name or IP). For example, a Layer 7 Policy can send an English request for www.a.com to one farm, and a German request to a .gif file to another farm.
234
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration When AppDirector matches new session data to a Layer 7 policy, the entries are matched according to their index (from lower to higher index) and first matching entry is used. For this reason when there are overlapping conditions, the most specific condition should have the lowest index.
Note: If no matching Layer 7 Policy entry is found, the session is discarded - if it is T, a RST is sent to client. Each Layer 7 Policy entry can use up to two Layer 7 criteria, (Layer 7 Methods) such as URL or HTTP Header, and the criteria is combined with AND logic. Each entry specifies the farm to be used if the Layer 7 criteria in it matches the request.
To configure Layer 7 policies 1. From the AppDirector menu, select Layer 7 Farm Selection > Policies. The Layer 7 Policy Table window appears. 2. Click Create. The Layer 7 Policy Table Create window appears. 3. Set the parameters.
Parameter
Description
Policy Name
Name of the policy.
Policy Index
Order in which policy entries are matched. You cannot update the Index once it is defined.
First Method
First method used to select a specific farm. Also see Layer 7 Methods, page 228.
Second Method
Second method used to select a specific farm. Also see Layer 7 Methods, page 228.
Farm Name
Farm to which the traffic must be load balanced when this entry’s criteria is matched. Note: You can define an empty string as the farm name. When such rules are matched, AppDirector resets the T connection, effectively blocking access.
4. A policy can have a number of arguments (optional). To select an Argument, click the option button alongside. The Arguments for Policy window appears. 5. Select the options as shown in the table below and click Set. You are returned to the main Layer7 Policy Table window. In the Arguments field, you can view all configured arguments in string format. Each argument has its own code displayed in string format.
Document ID: RDWR-AD-V021403-UG0211
235
AppDirector Guide Traffic Management and Application Acceleration
Parameter
Description
Arguments
Retain HTTP Persistency (PRSST): If the argument is ON, AppDirector maintains HTTP 1.1 persistency. If the argument is OFF (or undefined), AppDirector breaks HTTP 1.1 persistency. HTTP Redirect To (RDR): Performs HTTP redirection to the specified name or IP. • When using this argument, leave the Farm Name field empty. Values are case sensitive. • All arguments in Layer 7 Policy can use up to 255 characters, including parameter names and segment markers. Note: To avoid appending the URI requested by the client at the end of the Redirect-To string, you can set @ as the first character of the Redirect-To parameter. For example, when the requests www.site.com/index.htm and the Redirect-To of the selected server is @www.a1.com, the is redirected to www.a1.com rather than to www.a1.com/index.htm. HTTPS Redirect To (RDRS): AppDirector redirects the HTTP request to the specified name or IP and modifies the request to a HTTPS request. Redirection Code (RDRC): Defines the code to be used for redirection. Options are: • 302 Moved Temporarily ( uses 302 code irrespective of HTTP version) • RFC Moved Temporarily (the redirection code is according to the RFC, for HTTP1.0- 302 and for HTTP1.1 - 307) • Moved Permanently (code 301) SIP Redirect To (RDRSIP): Performs SIP redirection to the specified name or IP.
Note: The arguments are case sensitive, meaning that when you configure the Arguments string directly, the arguments keys must be defined in upper case. 6.
236
Click Set. Your configuration is set.
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration
Layer 7 Statistics You can view statistics for Layer 7 Policies. For each policy, you can view the total number of matched HTTP GET requests and the number of HTTP GET requests per second.
To view statistics for farms 1. From the AppDirector menu, select Layer 7 Farm Selection > Statistics. The Layer 7 Policy Statistics Table window appears, which contains the following read-only parameters:
Parameter
Description
Policy Name
Name of the policy.
Policy Index
Search order of your policy, e.g. one will make the policy appear first.
Total Matches
Total number of matched requests.
2. Click on a Policy Name. Statistics on that policy appear.
To reset Layer 7 statistics Click Set. The Layer 7 statistics counters have been reset.
To view statistics for farms via CLI Use the command ad l7 farm-selection statistics.
Layer 7 Farm Selection for DNS When load balancing DNS traffic, AppDirector can select farms based on a requested domain name. The DNS Layer 7 farm selection uses the same mechanism used for DNS resolution (see Host Names, page 311) instead of the Layer 7 policies mechanism.
To perform DNS Layer 7 farm selection 1. Set your Layer 4 policy with the Application parameter to DNS. 2. Set your default farm for DNS traffic selected in the farm parameter (no Layer 7 policy allowed).
Note: If the domain name requested in the DNS query received is not known, traffic will be forwarded (load balanced) to the default farm.
Document ID: RDWR-AD-V021403-UG0211
237
AppDirector Guide Traffic Management and Application Acceleration 3.
For each domain name for which DNS farm selection is required, entries for Host Names must be configured with the following parameters: —
Host Name = required domain name
—
Farm = name of required farm
—
Layer 4 Policy = DNS Layer 4 policy name
—
DNS Action = Forward
Similarly an entry can be configured for a group of domain names using the Regexp Host Names table. When traffic arrives matching the DNS Layer 4 policy, the domain is extracted from the DNS request for lookup in the Host Names/Regexp Host Names. If a domain is found and the DNS Action is set to Forward and the query is A, AAAA or PTR, the request is load balanced to the farm specified in the Host Names entry If a domain is found but the DNS Action is set to Resolve and the query is A, AAAA or PTR, AppDirector resolves the DNS query and sends a response, without load balancing it to any backend server.
Note: For an AAAA query the device replies with an empty answer, communicating to the DNS client that the domain name is known, but the query type is not ed. If a domain is not found or a record type is not ed by AppDirector, a request is load balanced to the default farm, (the farm specified in the DNS Layer 4 policy). When traffic reaches an AppDirector IP interface or Virtual IP Interface (VIPI), DNS load balancing cannot be performed. Resolution can only performed by the device. If the requested domain appears in the Host Names table with the DNS Action set to Forward, a No such name response is sent.
Layer 7 Modification You may often need to change the headers or body of a HTTP session, for a variety of reasons. Some of the examples are: •
Inserting a HTTP Header X-Forwarded-For when redirecting traffic, to convey to the Destination server who was the originator of the communication.
•
Removing a HTTP Header from server replies to clients to hide server identity.
•
Inserting cookies for persistency purposes.
AppDirector provides the following Layer 7 modification capabilities: •
extensive Layer 7 modifications capabilities including, inserting, removing and updating Layer 7 headers, such as URL, cookie, header fields and status line as well as any Layer 7 header that can be identified by a specific text or regular expression.
•
URL rewrite in HTTP headers and body.
•
text modifications in HTTP body.
Layer 7 header modifications HTTP or other HTTP-like (has HTTP-like header) T traffic only.
238
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration
Layer 7 Modification Rules Layer 7 Modifications rules are attached to farms, indicating modifications to requests and responses that are being forwarded by AppDirector. A number of different rules can be performed on traffic to the same farm, where the order of execution is given by the rule index. Each rule defines the traffic that needs to be modified, the modification type that is performed and the modification itself. To define traffic modification criteria and the modification itself, Layer 7 Methods are used.
Note: When multiple rules are configured for the same farm, they should not define modifications on the same section. If such modification rules are configured, only the first one, (with the lowest index), will be performed.
To create a Layer 7 Modification Rule 1. From the AppDirector menu select Layer 7 Modification > Rules. The Layer 7 Modification Table window appears. 2. Select Create. The Layer 7 Modification Table Create window appears. 3. Set the parameters..
Parameter
Description
Name
Key name.
Index
Sets order in which AppDirector matches traffic to the modification rules and performs the modification. Default: 1
Farm
Unique identifier. The farm where this rule is applied.
Modification Scope
Indicates the part of the message where modifications are performed. Values: • Header Only (default): Modification is performed on the message header only. • Header And Body: URL Rewrite Modification is performed on the HTTP message header and body. In addition this mode enables you to perform text changes (replace or remove by replacing with null string) in HTTP body. Also see Content Types that Layer 7 Header and Body Modification can process, page 243. Note: When SSL Policy Protocol Redirection and L7 Header & Body Modifications are enabled on the same service, and the server sends a 302 Redirect response, the protocol of the new location is always set to HTTPS to enable the redirect location to work for the clients. This is regardless of the setting in the L7 Modification method.
Document ID: RDWR-AD-V021403-UG0211
239
AppDirector Guide Traffic Management and Application Acceleration
Parameter
Description
Direction
Indicates if modification is done only on s' requests, only on server responses or on both s' requests and servers' response. Values: • Request (default), Reply, Bidirectional (Header and Body) • Request (default), Reply (Header Only) Note: Bidirectional means AppDirector allows modification to the header and body on responses as part of URL obfuscation.
Status
Allows disabling a rule without removing it. • Enabled (default) • Disabled
4.
The rest of the parameters depend on the value of the Modification Scope. a.
When Modification Scope is set to Header only:
Parameter
Description
Modification Type
Defines the Layer 7 modification: • Insert (Default): Inserts a Layer 7 parameter • Replace: Replaces a Layer 7 parameter • Remove: Removes a Layer 7 parameter
b.
Match Condition
Layer 7 method that defines the sessions for which a modification is made.
Modification
Layer 7 method that defines the modification that is made.
When Modification Scope is set to Header and Body:
Parameter
Description
Enhanced Acceleration Header and Body Condition
This allows you to select from defined Layer 7 Methods of type “Advanced URL condition” or Text. This defines the condition upon which modification is performed and what is modified.
Header and Body Modification
This allows you to select from defined Layer 7 Methods of type “Advance URL Modification” or Text. This defines the condition upon which modification is performed and and the modification action and data.
5.
240
Click Set. Your configuration is set.
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration
Header Only Modification Type Behavior Action
Configuration
Behavior
Insert
Match Condition:
The Match Condition, when present, defines the traffic where the Insert action must be performed.
Methods that can be used are: • URL • File Type • Header Field • Cookie • Set Cookie • Regular Expression • Text Modification (Mandatory): Methods that can be used are (with no restriction to the method used for Match Condition): • URL - with Path argument only • Header Field • Cookie • Set Cookie
The result of the Insert action depends on the method used as Modification: URL: Appends the text configured in the path argument at the end of the original requested path in the Host header or, in case of proxy requests, from URL. Header Field: Inserts the header field at the beginning of the header area Cookie: Inserts cookie header at the beginning of the header area, after the request line. Relevant to Request direction only. Text: Inserts text at the beginning of the header area Set Cookie: Inserts Set Cookie header at the beginning of the header area. Relevant to Reply direction only.
• Text Remove
Match Condition (Mandatory): Methods that can be used are: • URL (with Path argument only) • File Type • Header Field • Cookie • Set Cookie
The result of the Remove action depends on the method used as Modification: URL: Removes path from Host header or, in case of proxy requests, from URL. In case that the match is on part of the path, then only the matched part is removed. File Type: Removes file type in the URL. Relevant to Request direction only.
• Text
Header Field: The entire matching header field is removed, not only the argument specified in Match Condition.
Note: Modification cannot be defined for Remove action.
Only the first encountered matching header field in the message is removed.
• Regular Expression
To remove part of a header field value, the Text method can be used, but it requires that the removed value is quite unique in the packet. Cookie: The entire key=value pair is removed form the Cookie header, not only the argument specified in Match Condition. Relevant to Request direction only. Regular Expression: Any string matching the condition is removed. Text: The string matching the condition is removed. Set Cookie: The entire Set Cookie header is removed, not only the arguments specified in Match Condition. Relevant to Reply direction only.
Document ID: RDWR-AD-V021403-UG0211
241
AppDirector Guide Traffic Management and Application Acceleration
Action
Configuration
Behavior
Replace
Match Condition (Optional):
The Match Condition, when present, defines the traffic and the object where the Replace action must be performed.
When Match Condition is not defined the only Modification methods allowed are URL and Status Line. When Match Condition is defined the Match Condition and Modification methods must be of the same type. The only exceptions are: • When using Text as Modification method either a Text or Regular Expression can be used as Match Condition. • When using Advanced URL Modification as Modification method, Advanced URL Condition must be the Match Condition.
Action performed by Replace action can be: • Update of arguments specified in the Modification method • Removal of arguments - when the update value in the Modification method is set to $Blank • Insert of arguments (only for Set Cookie and Status Line methods) when the argument defined in the Modification method, does not appear in the original message. The whole argument is being updated and not only the match area. To replace only part of an argument use text or Regular Expression as Match Condition and Text as Modification. The result of the Replace action depends on the method used as Modification: URL: Replaces hostname and/or path in Host header or, for proxy requests, in URL. File Type: Replaces file type specified by Match Condition with the one specified in Modification method. Header Field: Replaces values defined in Modification method in header field specified by Match Condition. Replaces only the first encountered matching header field in the message. Cookie: Replaces values defined in Modification method in cookie pair specified by Match Condition. Relevant to Request direction only. Text: Replaces the string specified by Match Condition with the one specified in Modification method. Status Line: Replaces values defined in Modification method for Status Line arguments specified by Match Condition. If arguments specified in Modification method are not present in message, they are added. Relevant to Reply direction only. Set Cookie: Replaces values defined in Modification method for Set Cookie arguments specified by Match Condition. If arguments specified in Modification method are not present in message, they are added. Relevant to Reply direction only.
242
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration
Note: * Only methods ed for each Action type are mentioned.
Common Layer 7 Modifications This table shows configuration examples of common Layer 7 modifications:
Example
Modific Direction ation Type
Inserting X-Forwarded-For HTTP Insert Header with client IP
Client Requests
Match Condition
Modification
Empty
Method= Header Field Header Field = XForwarded-For Token=$Client_IP
Inserting a cookie with key of MyKey and a value of MyFarm
Insert
Server Replies
Method=Set-Cookie Cookie Key=MyKey Cookie Value= MyFarm
Updating a cookie with key of Update MyKey and value of MyFarm to the value of the selected server and port
Server Replies
Inserting a cookie with key of Insert MyKey and a value of MyFarm at the end of the URL
Client Requests
Method = Set- Method = Set-Cookie Cookie Cookie Key = MyKey Method=URL Path=?MyKey=MyFar m
Content Types that Layer 7 Header and Body Modification can process The following content types expressed as content-type text/......can be processed by Layer 7 Header and Body Modification: asp
vnd.wap.wml
x-script.csh
x-server-parsed-html
css
vnd.wap.wmlscript
x-script.elisp
x-setext
html
webviewhtml
x-script.guile
x-sgml
mcf
x-asm
x-script.ksh
x-speech
pascal
x-audiosoft-intra
x-script.lisp
x-uil
plain
x-c
x-script.perl
x-vcalendar
richtext
x-component
x-script.perl-module
xml
scriplet
x-fortran
x-script.phyton
javascript
sgml
x-h
x-script.rexx
x-javascript
tab-separated-values
x-java-source
x-script.scheme
application/x-javascript
uri-list
x-la-asf
x-script.sh
vnd.abc
x-m
x-script.tcl
vnd.fmi.flexstor
x-pascal
x-script.tcsh
vnd.rn-realtext
x-script
x-script.zsh
Document ID: RDWR-AD-V021403-UG0211
243
AppDirector Guide Traffic Management and Application Acceleration
Layer 7 Modification Rules Automatic Configuration There are two cases where AppDirector automatically generates Layer 7 modification rules. 1.
When the Add X-Forwarded-For to HTTP request parameter is enabled in a farm, AppDirector automatically generates a Layer 7 modification rule that inserts the X-Forwarded-For header with the value of the original client IP in packets sent to the server. This capability is useful when AppDirector performs Client NAT on traffic sent to servers - it allows server visibility of the original clients.
2.
When the Insert Cookie for HTTP Persistency parameter is enabled in a farm, if the value of this parameter is set to Enabled, AppDirector automatically generates the necessary configuration to insert a cookie that contains the server identifier in the reply and keep persistency for subsequent requests from the same client according to inserted value. A different value is created for each client. The value is encoded using base64 encoding. The device generates the following automatic configuration:
The following entry in Layer 7 methods: •
Name Auto-G
•
Method Set-cookie
•
Key
•
Value $Dyn_Cookie_Value (Minimum length is 1 character)
A Layer 7 modification rule for the farm: •
Index (The lowest available character)
•
Action Insert
•
Direction Server Replies
•
Layer 7 Method for Match Empty
•
Layer 7 Method for Action Auto-G
AppDirector also creates the appropriate Text Match Session ID Persistency entry from the server, before forwarding it to the client. If Insert Cookie for HTTP Persistency is set to “Enable and remove on return path" AppDirector automatically generates two Layer 7 modification rules, one that inserts a cookie that contains the server identifier and one that removes this identifier from subsequent requests before forwarding them to the server. The Layer 7 methods and modification rules that are automatically generated are read-only. If a deactivates the capability in the farm configuration, the Layer 7 Modification rule and Layer 7 method automatically generated for this capability are removed. The following scenarios show the configurations for rewriting different parts of a URL. Configuring URL rewriting policies is performed in the Edit URL Rewrite Policy window. For all scenario examples, configuration that is not specified means default values are used. In general, it is recommended to be as specific as possible in the Rewrite configuration. For example, always specify the Domain Name, even when it is not changed.
Layer 7 Modification Examples Insert X-Forwarded-For The following scenario displays the modification rule for inserting X-Forwarded-For header with Client IP value in all requests. This is useful for providing servers with the identity of the original client when Client NAT is performed.
Match Condition
Modification
Modification Type Direction
Optional
Header Field method:
Insert
Request
• Name=X-Forwarded-For • Token=$Client_IP
244
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration
Cookie Insert/Rewrite The following scenarios display the modification rule for inserting or rewriting cookie for persistency purposes. AppDirector can insert a cookie in server reply, if the application does not do it, to ensure subsequent requests from same client are forwarded to the same server. In certain cases the application inserts a cookie in reply, but with the same value for all servers - in such cases AppDirector can rewrite the value with a value that will identify the server.
To insert a Set Cookie header in server reply, with key MyKey and value representing the replying server
Match Condition
Modification
Modification Type Direction
Optional
Set Cookie method:
Insert
Reply
• Key=MyKey • Value= $Server_SID_Cookie or $Dyn_Cookie_Value
To change in server reply the cookie value in a Set Cookie header (Rewrite) with value representing the replying server
Match Condition
Modification
Modification Type Direction
Set CookieKey=AppKeyl
Set Cookie method:
Replace
Reply
• Value=$Server_SID_Cookie or $Dyn_Cookie_Value
Append cookie to URL
Match Condition
Modification
Modification Type Direction
Optional
URL method:
Insert
Request
• Path=?Mykey=MyCookie
Protocol Rewrite The following scenarios display the URL Rewriting policy for rewriting the URL protocol in all requests and replies, and in requests and replies of a specific domain:
To change all front-end HTTPS requests to back-end HTTP requests and all HTTP links to HTTPS links:
Parameter
Match Method for URL
URL Modification Method
Protocol
HTTPS
HTTP
Document ID: RDWR-AD-V021403-UG0211
Additional Parameters
245
AppDirector Guide Traffic Management and Application Acceleration
To change HTTPS://www.site.com to HTTP://www.site.com and back:
Parameter
Match Method for URL
URL Modification Method
Protocol
HTTPS
HTTP
Domain Name
www.site.com
www.site.com
Additional Parameters
Comparison- n Type: Equal Operation: Replace
Examples Domain Name Rewrite The following examples display the URL Rewriting policy for rewriting the URL domain name:
To change HTTPS://www.front-site.com to HTTP://www.back-server.com:
Parameter
Match Method for URL URL Modification Method
Additional Parameters
Protocol
HTTPS
HTTP
Domain Name
www.front-site.com
www.back-server.com
• Comparison Type: Equal • Operation: Replace
To change HTTPS://www.front-site.com to HTTP://www.back-server.com:
Parameter
Match Method for URL URL Modification Method
Additional Parameters
Protocol
HTTPS
HTTP
Domain Name
www.front-site.com
www.back-server.com
• Comparison Type: Equal • Operation: Replace
246
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration
To change HTTPS://site.com to HTTP://my.site.com:
Parameter
Match Method for URL URL Modification Method
Protocol
HTTPS
HTTP
Domain Name
site.com
my.site.com
Additional Parameters
• Comparison Type: Equal • Operation: Replace
Or, alternatively
Parameter
Match Method for URL URL Modification Method
Protocol
HTTPS
HTTP
Domain Name
site.com
my.
Additional Parameters
• Comparison Type: Equal • Operation: Add Before
Note: Setting the back-end Domain Name to "my" instead of "my." results in changing site.com to mysite.com.
To change HTTPS://*.front-site.com/*.* to HTTP://*.back-server.com/*.*:
Parameter
Match Method for URL URL Modification Method
Additional Parameters
Protocol
HTTPS
HTTP
•
Domain Name
front-site.com
back-server.com
• Comparison Type: Ends With • Operation: Replace
Note: With Operation Replace, the exact text that appears in the Front-end Domain Name is replaced with the text that appears in Back-end Domain Name. For example, the URL www.front-site.com/path/page.type with the above configuration is rewritten to www.back-server/path/page.type, and the URL www1.front-site.com/path/page.type is rewritten to www1.back-server.com/path/page.type.
Document ID: RDWR-AD-V021403-UG0211
247
AppDirector Guide Traffic Management and Application Acceleration
Port Rewrite When the client sends a request to destination port 80 for the URL HTTP://www.site.com, or to HTTP://www.site.com:80 AppDirector rewrites the request to HTTP://www.site.com:8080. For the reply, AppDirector rewrites URLs of HTTP://www.site.com:8080 to HTTP://www.site.com:80.
Note: When the back-end server is listening on port 8080 and there is no port number specified explicitly in the URL, then there is no need for AppDirector to change the port and both Front-End and Back-end Ports must be set to 80. When the Front-End Port is the same as the Back-end Port, the device does not change the port specified in the request. If no port is specified in the client's request or in server's reply, then the device treats it as port 443 for encrypted traffic, and as port 80 for clear text traffic.
Path Rewrite The following scenarios display the URL Rewriting policy for rewriting the URL path:
To change HTTPS://www.site.com/aaa/*.* to HTTP://www.site.com/mypath/aaa/ *.*:
Parameter
Match Method for URL URL Modification Method
Protocol
HTTPS
HTTP
Domain Name
www.site.com
www.site.com
Additional Parameters
• Comparison Type: Equal • Operation: Replace
Path
aaa
mypath/
• Comparison
Type: Equal
• Operation: Add Before
Note: Setting the back-end Path to "/mypath" instead of "mypath/" as above, where the operation is "Add Before", results in changing the URL HTTPS://www.site.com/aaa/ to HTTPS://www.site.com//mypathaaa/.
248
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration
To change HTTPS://www.front-site.com/aaa/*.* to HTTP://www.back-server.com/ aaa/mypath/*.*:
Parameter
Match Method for URL URL Modification Method
Protocol
HTTPS
HTTP
Domain Name
www.front-site.com
www.back-server.com
Additional Parameters
• Comparison Type: Equal • Operation: Replace
Path
aaa
/mypath
• Comparison Type: Equal • Operation: Append After
To change HTTP://www.front-site.com/*aaa*/*.* to HTTP://www.front-site.com/ mypath/*aaa*/*.*:
Parameter
Match Method for URL URL Modification Method
Protocol
HTTP
HTTP
Domain Name
www.front-site.com
www.front-site.com
Additional Parameters
• Comparison Type: Equal • Operation: Replace
Path
aaa
mypath/
• Comparison Type:Contain • Operation: Add Before
To change HTTP://www.front-site.com/*aaa*/*.* to HTTP://www.front-site.com/ mypath/*aaa*/*.*:
Parameter
Match Method for URL URL Modification Method
Protocol
HTTP
HTTP
Domain Name
www.front-site.com
www.front-site.com
Additional Parameters
• Comparison Type: Equal • Operation: Replace
Path
aaa
mypath/
• Comparison Type:Contain • Operation: Add Before
Note: When Comparison Type is set to ‘Contain’, then Operation ‘Add Before’ implies the additional text is added at the beginning of the path. Similarly, when Operation is set to ‘Append After’, the additional text is added at the end of the path.
Document ID: RDWR-AD-V021403-UG0211
249
AppDirector Guide Traffic Management and Application Acceleration
Page Rewrite The following scenarios display the URL Rewriting policy for rewriting the URL page:
To change HTTPS://www.site.com/aaa/page.type to HTTP://www.site.com/ mypath/newpage.type:
Parameter
Match Method for URL URL Modification Method
Protocol
HTTPS
HTTP
Domain Name
www.site.com
www.site.com
Additional Parameters
• Comparison Type: Equal • Operation: Replace
Path
aaa
mypath
• Comparison Type: Equal • Operation: Replace
Page
page
newpage
Note: The Path is defined as the part of the URL between the first slash to the last slash. For a URL like www.site.com/aaa/page.type/ (with a slash at the end) all directories are used as the path, and not as page and page type.
Real Life Examples The following scenarios of URL rewriting policies combine the rewriting of different parts of a URL in a single policy.
To rewrite the URL HTTPS://www.front-site.com/mypath/*.* to HTTP://www.backserver.com/*.* use the following configuration:
Parameter
Match Method for URL
URL Modification Method
Protocol
HTTPS
HTTP
Domain Name
www.front-site.com
www.back-server.com
Additional Parameters
• Comparison Type: Equal • Operation: Replace
Path
mypath
• Comparison Type: Starts With • Operation: Remove
250
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration
To rewrite the URL HTTPS://www.front-site.com/*.* to HTTP://www.backserver.com/mypath/*.* use the following configuration:
Parameter
Match Method for URL
URL Modification Method
Protocol
HTTPS
HTTP
Domain Name
www.front-site.com
www.back-server.com
Additional Parameters
• Comparison Type: Equal • Operation: Replace
Path
mypath
• Comparison Type: Contain • Operation: Add Before
To rewrite the URL HTTPS://www.front-site.com/front-path/*.* to HTTP:// www.back-server.com/mypath/front-path/*.* use the following configuration:
Parameter
Match Method for URL
URL Modification Method
Protocol
HTTPS
HTTP
Domain Name
www.front-site.com
www.back-server.com
Additional Parameters
• Comparison Type: Equal • Operation: Replace
Path
front-path
mypath/
• Comparison Type: Contain • Operation: Add Before
Layer 7 Modification Statistics Layer 7 modification rules are configured at the farm level. Multiple rules can be configured for each farm. From the Layer 7 Modification Statistics window the Layer 7 modification statistics are viewed.
To create a Layer 7 Modification Table From the AppDirector menu select Layer 7 Modification > Statistics. The Layer 7 Modification Statistics window appears which contains the following read-only parameters:
Parameter
Description
Modification Name
Key name.
Hits since Reset
Number of rules matched/changed per rule since the last reset.
Document ID: RDWR-AD-V021403-UG0211
251
AppDirector Guide Traffic Management and Application Acceleration
Layer 7 Modification Reset Statistics You can reset Layer 7 modification statistics from the Layer 7 Modification Reset Statistics window.
To Reset the Layer 7 Modification Statistics 1.
From the AppDirector menu, select Layer 7 Server Modification > Reset Statistics. The Modification Reset Statistics window appears.
2.
Press Set. The global statistics of Layer 7 modification rules are reset.
Layer 7 Server Persistency This describes persistency from the IP level up to Layer 7, providing application aware server persistency.
Session ID Persistency When it is necessary to establish multiple connections from the same to the same server in a farm, these sessions can be identified by application layer information found in the client's requests. AppDirector is able to detect / inspect the Session ID information in the traffic and use it for server selection in further connections, providing application aware server persistency. You can configure different persistency schemes for different applications and for different farms. The Layer 7 server persistency mechanism consists of two major blocks: 1.
2.
The packet parser: used to identify the persistency parameter in the traffic.AppDirector allows searching for any Persistency Parameter within a packet in a text or binary format. AppDirector searches for Session ID using the following: —
Text Match Session ID Persistency: AppDirector searches for text strings within the packet. The search can be for any Persistency Parameter anywhere in the packet.
—
Pattern Match Session ID Persistency: AppDirector matches binary patterns within packets. Binary Session ID Matching is done using pattern matching. You can configure the offset where the pattern begins and a mask to apply to the pattern, before checking if it is in the Session ID Table.
Session IDs Management - manages the link between the persistency parameter values and servers to which they apply. There are 2 options: —
Static Session IDs. The configures persistency parameter values attached to each server farm and also has to configure a Text Match or Pattern Match entry that defines where in the message to search for the statically configured persistency parameter.
—
Dynamically learned values. AppDirector learns persistency parameter values for farm servers from the traffic ing through it and ensures future transactions with the same persistency parameter value are sent to the same farm server. In this case, an aging mechanism is employed to manage the lifetime of each persistency parameter value.
—
Hashing. Persistency is ensured by performing hash using the persistency parameter value as input. No values are recorded. This method is especially useful in ensuring URL based persistency for reverse proxy applications.
Session ID persistency is available for the following types of traffic: •
HTTP or other HTTP-like (has HTTP-like header) T protocols.
•
UDP protocols.
•
IP traffic in general (using pattern match).
Session ID persistency is NOT available for dynamic protocols, e.g; FTP, TFTP.
252
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration
Notes: >> When using Session ID Persistency for UDP traffic, AppDirector inspects each packet separately and selects the appropriate server. >> The Cookie Persistency License allows AppDirector to search the HTTP headers for Session ID Persistency. Without it, AppDirector inspects only the URI and no other HTTP headers. >> When DSID and Layer 7 Modifications are configured together (when applied to the same request/response) , DISD parsing is performed first, then Layer 7 Modifications. This means that when the modification changes the part in the header to which DISD is referred, the DISD server selection and learning is performed according to the original data, prior to the modifications.
General Flow The general flow is as follows: Parse Layer 7 data and find the session ID value in request. 1. If found, search the value in the internal session ID table (the internal table includes both statically configured and dynamically learned values). a. b.
If found, traffic is forwarded to the server indicated in the table. If not found select a server according to farm Dispatch Method if learning is enabled for this farm , learn the new value, either from request or from reply, depending on persistency parameter configuration.
2. If not found, select a server and forward packet normally.
Parameters for All Farms Persistency method is configured per farm, however the following parameters apply to all farms: 1. Session ID Sharing. With Session ID Sharing, you can share Session ID information among multiple farms, when the same Persistency Parameter is used for the farms. When a specific Session ID is configured or learned through one farm, the same Session ID may also be used for server selection in other farms that use the same Persistency Parameter and the same servers. 2. DSID reply Learning in "First" mode. When using dynamically learned session IDs, this option defines whether the device should inspect each reply of each transaction, on the same T session, even if Layer 7 Persistent Switching Mode is set to FIRST for the Layer 4 policy the traffic matched. The default and recommended value is Inspect First Reply. Inspect All Server Replies should only be used if required for compatibility with previous version.
Configuring Text Match Session ID Persistency Text Match Session ID persistency mechanism allows identifying persistency parameter by parsing the message and looking for specified text anywhere in the message.
To search for Session ID according to Text Match Session ID Persistency 1. From the AppDirector menu, select Layer 7 Server Persistency > Text Match. The Text Match Session ID Persistency window appears. 2. Click Create. The Text Match Session ID Persistency Create window appears.
Document ID: RDWR-AD-V021403-UG0211
253
AppDirector Guide Traffic Management and Application Acceleration 3.
Set the parameters.
Parameter
Description
Farm Name
Name of farm for which session ID persistency is used.
Layer 4 Protocol
Layer 4 Protocol for which traffic is intercepted for Session IDs. Values: T (Default), UDP or other
Application Port
Port for which traffic is intercepted for Session IDs. Default: 0 (indicates that all ports must be inspected).
Lookup Mode
Defines location within the request where Session ID appears. Values: • Cookie: The device looks within the Cookie header for the value following "Persistency Parameter=". The Persistency Parameter is case sensitive. Note: Using Cookie Persistency License allows AppDirector to search the HTTP headers for Session ID Persistency. Without the License, AppDirector inspects only the URI and not further HTTP headers. • Header: The device looks for the value following "Header Name:", if Persistency Parameter is not defined, or within the Header Name for the value following "Persistency Parameter=" when Persistency Parameter is defined. The Header Name and Persistency Parameter are case insensitive. • RegExp: The device looks anywhere in the packet for the value following "Persistency Parameter=". The identifier is caseinsensitive (unless indicated specifically in the expression). • URL cookie: The device looks within request-URI for value following "Persistency Parameter=". The Persistency Parameter is case sensitive. Note: URL cookie cannot be set with a Learning Direction of Server Reply. • Text: The device looks anywhere in the packet for the value following "Persistency Parameter=". The identifier is casesensitive. • RADIUS Attribute: Stores the RADIUS Attribute and server, to ensure persistency for traffic sessions. The Persistency Parameter can only be a number (RADIUS attribute), not a string and the value of the attribute must be searched not until a stop character, but according to the attribute length mentioned in the configured RADIUS attribute. The Persistency Parameter can only be a number (RADIUS attribute number) between 0 and 255 and the attribute value must be searched not until a stop character, but according to the Value Max Length field. • XML Tag: The device looks for the specified XML tag value or tag attribute. This enables you to maintain persistency based on a XML request tag/attribute and/or XML response tag/attribute. Note: Tag names are defined without the opening and closing characters (< >) and are NOT case sensitive.
254
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration
Parameter
Description
Lookup Mode (continued)
In order to define a specific tag, you can concatenate tag names with slash characters like writing a path (like using XPath). Notes: • The Parameter Match value will only be allowed to be defined as "prefix" because in XML the value is not the name itself. • Value offset can remain 0 and AppDirector will know to look for the value after the closing ">" of the XML tag name.
Persistency Parameter Key of the persistency parameter, up to 64 characters. For example, persistency parameter can be "Call-ID" in SIP, or “AcceptLanguage” in HTTP. Note: This parameter represents the persistency parameter found in XML requests when XML Tag Lookup Mode is selected. Persistency Parameter ID to look for during dynamic session ID search on the server reply . for Reply Notes: (used only when • Case sensitive. Lookup Mode is set to • You need to specify the XML tag and the XML path (partial or XML Tag) absolute) to the XML tag by which persistency should be maintained. • For XML tag attribute add @
Defines whether the persistency parameter defined in this entry should be used to ensure persistency based on the Session ID table mechanism (learning) or via hashing. Values: • Use Table (default): Use this persistency parameter via the Dynamic Session ID table to ensure server persistency. • Hash: Use this persistency parameter as input for the hash function to select a server. If a server is not available, AppDirector selects another server and stores the persistency value and selected server in the Session ID table, to ensure persistency for further traffic in this session. The farm Dispatch Method must be set to hashing.
Header Name (when HTTP Header Lookup Mode is selected)
Name of the header where the persistency parameter appears. Relevant only when Lookup Mode is Header Field.
Parameter Match
This defines if we learn the value that starts immediately after the end of the Parameter Identifier (when the value is set to Exact) or after the value that starts after the separator/s ( when the value is set to Prefix). The separators can be white spaces and "=".
Note: This parameter does not appear when XML Tag Lookup Mode is selected.
Values: • Exact (Default): Indicates that the configured Persistency Parameter value must exactly match the received Persistency Parameter value. • Prefix: Indicates that the configured value appears as a prefix with possible additional characters following. When using this mode, a separator can appear between the identifier and the value in the packet. The separator can be: white space, ‘=’, ‘:’.
Document ID: RDWR-AD-V021403-UG0211
255
AppDirector Guide Traffic Management and Application Acceleration
Parameter
Description
Value Max Length
Maximum length of the Session ID value if there is no stop character. Values: 1 - 256 (default)
Value Offset
The offset where the Session ID value resides, within the value following the Persistency Parameter name. Default is 0, meaning value location is right after the Persistency Parameter name and value separator. Value Offset is used when the value of the Persistency Parameter is composed of a dynamic value that changes during the session, followed by a static value that identifies the session, so that AppDirector ignores the dynamic prefix of the value for server persistency. For example, the value is a timestamp followed by client ID, where persistency is based on client ID only. Default: 0
Stop Chars
Characters that indicate the end of the Session ID value. Up to 10 characters can be defined. No delimiters are required in this field. Tab, CR (carriage return), LF (line feed), and so on, are considered as Stop Characters. Default: ";"
Learning Direction
Indicates which traffic is inspected by AppDirector to gather persistency information and to use that information for a specific session: • Server Reply (Default): AppDirector dynamically learns which session IDs are to be associated with each server, according to information in replies from servers. AppDirector inspects also client requests, to find if they contain a session ID that was already learned by AppDirector, to forward them to the correct server accordingly. • Client Request: Can be used when Session IDs appear only in requests from clients, and means that AppDirector does not inspect replies from servers. This can be used, for example, when persistency is based on client IP that appears in X-Forwarded-For HTTP header, or when only static values of Session IDs are used, as manually configured in the Static Session ID Persistency Table. • Both Directions: AppDirector inspects both client requests and servers replies to learn about persistency identifiers. • No Learning: Persistency information is not gathered. You should define this value when Static Session ID Persistency is used.
Inactivity Timeout [sec]
Defines how long the association of Session ID values to servers should be kept when no traffic with this Session ID value is ing through AppDirector. This is similar to Aging Time in the Client Table. Values: 1 - 86,400 seconds (24 hours) Default: 60 seconds
256
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration
Parameter
Description
Ignore Server Reply
Used to enhance AppDirector performance when Session ID values can be learned from server reply, when Learning Direction is set to Server Reply or to Both Directions. Values: • Never (Default): AppDirector searches even if it has already found a Session ID for this session. Here, AppDirector updates the Session ID Persistency table according to data in the server’s reply. • When ID is in Request: AppDirector performs this way when the Learning Direction parameter is set to Server Reply or to Both Directions. When AppDirector has found a Session ID in a client's request, it does not further inspect the server reply. When a Session ID already exists in the client's request, and it can be guaranteed that the server does not change that Session ID, you can set this field to When ID is in Request.
Tip: Use this option when Static Session IDs are used. Ignore Source IP
When this is set, only the Session ID info is used for persistency. Sessions with the same session ID are always forwarded to the same server. Disabling this parameter, forces AppDirector to also use the source IP where there is a session ID match. Two sessions with the same session ID, but with a different source IP address can be forwarded to different servers. This mode is relevant only for dynamic entries. Default: Enabled.
4. Click Set. Your configuration is set.
Configuring Session ID Hash Persistency
To ensure persistency based on hash of a Layer 7 Session ID 1. Set Dispatch Method to Hashing in the farm configuration (link to farm parameters). 2. Configure the desired persistency parameter as Text Match Session ID, with the Persistency Method set to Hash.
Configuring Pattern Match Session ID Persistency When the Pattern Match Session ID Persistency mechanism is used, AppDirector matches binary patterns within the packets.
To search for Session ID according to Pattern Match Session ID Persistency 1. From the AppDirector menu, select Layer 7 Server Persistency >Pattern Match. The Pattern Match Session ID Persistency window appears. 2. Click Create. The Pattern Match Session ID Persistency Create window appears.
Document ID: RDWR-AD-V021403-UG0211
257
AppDirector Guide Traffic Management and Application Acceleration 3.
Set the parameters.
Parameter
Description
Farm Name
Name of farm for which session ID persistency is used.
Application Port
Port for which traffic is intercepted for Session IDs. A value of 0 indicates that all ports are inspected. For example, to inspect HTTP Traffic, set Layer 4 Protocol to T and Application Port to 80. Values: Any (default), DNS, FTP, HTTP, HTTPS, NNTP, SMTP.
Layer 4 Protocol
Layer 4 protocol for which traffic is intercepted for Session IDs. Can be Values: T (Default), UDP or other.
Pattern Mask
Mask for the search pattern, also defines length of the pattern matched. This is a hexadecimal field. Default: 0xffffffff, meaning a 4 bytes long pattern is used for an exact match. Maximum pattern length is 128 bits (16 octets).
Inactivity Timeout
Defines how long the association of Session ID values to servers should be kept when no traffic with this Session ID value is ing through AppDirector . The mechanism is similar to Aging Time in the Client Table. Values: 1 to 86,400 seconds (24 hours). Default: 60 seconds
Pattern Offset
Offset in the packet, where the search starts. Default: 0
Offset Relative To
s can specify from which part of the packet the offset is referring to. The size of the Offset Relative To parameter, must be greater or equal to the value of the Pattern Offset parameter plus the length (determined by the Pattern Mask parameter). Values: IP header (Default); IP data, Layer 4 header or Layer 4 data.
Ignore Source IP
• Enabled (Default): When enabled, only the Session ID information is used for persistency. Sessions with the same Session ID are always forwarded to the same server. • Disabled: AppDirector also uses the Source IP when there is a Session ID match. Two sessions with the same Session ID but a different Source IP address can be forwarded to different servers.
Learning Direction
Indicates which traffic is inspected by AppDirector to gather persistency information and to use that information for a specific session: • Client Request (Default): Used when Session IDs appear only in requests from clients, so that AppDirector does not inspect replies from servers. This can be used, when persistency is based on client IP that appears in X-Forwarded-For HTTP header, or when only static values of Session IDs are used, as manually configured in the Static Session ID Persistency Table. • No Learning: Persistency information is not gathered. Define this value when Static Session ID Persistency is used.
258
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration
Parameter
Description
Persistency Method
Defines whether the persistency parameter defined in this entry should be used to ensure persistency based on the Session ID table mechanism (learning) or via hashing. Values: • Use Table (default): Use this persistency parameter via the Dynamic Session ID table to ensure server persistency. • Hash: Use this persistency parameter as input for the hash function to select a server. If a server is not available, AppDirector selects another server and stores the persistency value and selected server in the Session ID table, to ensure persistency for further traffic of this session. The farm Dispatch Method must be set to hashing.
Data Format
If the parameter is set to IP String, the octets extracted according to the configured pattern represent the IP address in string format. Values: Binary (default), IP String
4. Click Set. Your configuration is set.
Configuring Static Session ID Persistency Static Session ID Persistency allows AppDirector to send traffic with specified Session IDs to specified servers.
To configure Session ID tracking 1. From the AppDirector menu, select Layer 7 Server Persistency> Static Session ID Persistency. The Static Session ID Persistency Table window appears. 2. Click Create. The Static Session ID Persistency Create window appears. 3. Set the parameters:
Parameter
Description
Farm Name
Name of the server farm.
Session ID Value
Session ID value identifying a specific server in a farm.
Server Address
The server within the farm that is identified by the Session ID Value. When AppDirector detects traffic that contains this Session ID Value, it directs the traffic to the server specified in this parameter.
Server Port
Default is Zero (0) if no application port has been specified.
Value Type
• Text (default): Find the session ID value in the processed traffic using the text match mechanism. • Pattern: Find the session ID value in the processed traffic using the pattern match mechanism.
4. Click Set. The Static Session ID Persistency Create window closes and a new entry is created.
Document ID: RDWR-AD-V021403-UG0211
259
AppDirector Guide Traffic Management and Application Acceleration
HTTP Persistency AppDirector can HTTP persistency according to any parameter by using the Session ID mechanism. However the most popular persistency mechanism for HTTP is cookie persistency server inserts cookie that identifies it in the reply to client, and the client uses the cookie in all its subsequent requests. AppDirector several mechanisms for HTTP cookie persistency:
Cookie Learning By learning the cookie from server initial reply, AppDirector can ensure that all subsequent requests from that client reach the same server. For this purpose a Text Match Session ID entry that looks for cookie key inserted by the server needs to be configured for the farm in question.
Cookie Insert When servers do not insert cookies, AppDirector can insert a cookie that identifies the server used in the server reply, before forwarding the reply to the client. To insert a cookie, AppDirector uses its Layer 7 modification capabilities. When you set the Insert Cookie for HTTP Persistency to Enable for the farm in question, AppDirector automatically generates the required configuration - see Layer 7 Modification Rules Automatic Configuration, page 244. This can also be manually defined.
Cookie Insert & Remove Some application servers utilize cookies to associate server or application instances, and their default behavior involves searching their Database/Datastore for any application/instance associated with cookies. When unknown cookies appear, it attempts a lengthy search delaying the response. This can be solved by inserting the cookie on Reply, but removing it in subsequent Requests (on the way to server). When you set the Insert Cookie for HTTP Persistency to "Enable and remove on return path" for the farm in question, AppDirector automatically generates the required configuration - see Layer 7 Modification Rules Automatic Configuration.
Cookie Rewrite When all servers insert the same cookie value, AppDirector can replace the cookie value that arrives from the server with a value that enables identification of that server, (the Layer 7 modification capability called Replace). The required configuration includes: •
Set Cookie Layer 7 method that identifies the cookie inserted by server
•
Set Cookie Layer 7 method that defines the cookie cookie value that should replace the server inserted value on the reply
•
Replace Layer 7 modification rule
•
Text Match Session ID entry that searches for cookie values inserted by server in subsequent requests
•
Static Session ID entries that map the cookie value inserted for each server to that server.
Note: For Cookie / Insert Rewrite, you need the Cookie Persistency License.
URL Hash When load balancing reverse proxies it is required to maintain persistency for the URL, and particularly include the object, so that objects are not duplicated between the reverse cache servers. In cases were huge numbers of objects exist persistency can be ensured by hashing mechanism.
260
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration
To achieve URL Hash Persistency 1. Set Dispatch Method to Hashing in the farm configuration, (see Farm Parameters, page 159). 2. Configure URL persistency parameter as Text Match Session ID, with the Persistency Method set to Hash.
Note: This mechanism can be used to ensure persistency via hashing mechanism using any HTTP persistency parameter, not only URL.
SSL Persistency SSL ID Tracking ensures that all T sessions of a SSL session are forwarded to the same server. When SSL ID Tracking is enabled, AppDirector uses Delayed Binding, and waits to receive the packet with the SSL ID before choosing a server. If the SSL ID is found in the internal Session IDs table, traffic is forwarded to the specified server, if not the SSL ID value is learned (added to the internal Session IDs table). The SSL ID Session ID entries are aged according to the aging of corresponding entries in the Client Table. The Client Table is used to maintain the session data. SSL ID tracking can only be enabled on a farm whose Sessions Mode is set to Server Per Session. By default, SSL Tracking is disabled. For farms that use the Server Per Sessions Mode where the SSL ID Tracking parameter is disabled, AppDirector automatically uses the Entry Per Sessions Mode for the SSL traffic (port 443). Other traffic is shown in the Client Table using the Server Per Sessions Mode.
Notes: >> SSL ID cannot be learnt for servers of type Local Triangulation. >> SSL Session IDs are mirrored as they are kept in the Session ID table.
SIP Persistency AppDirector also enables you to load balance and maintain client-server persistency for SIP servers. Persistency of SIP over UDP sessions is maintained by searching for Layer 7 information, like CallID, within SIP headers. s can use one or both of the following methods to maintain client - server persistency: 1. Using Hashing as a dispatch method: AppDirector searches either the Call-ID header or the Request-URL header in the SIP (Hash Parameter for SIP) and selects one available server based on a hashing algorithm performed on the specified parameter. By using Dispatch Method hashing on Request-URI, while simultaneously tracking Call-ID via dynamic leaning mechanism, AppDirector provides persistency for multi-party calls and conference calls. 2. Using Dynamic Session IDs: AppDirector maintains persistency based on any field within the SIP header (for example, branch tag). When using the Dynamic Session ID for persistency, it is recommended to use an inactivity timeout longer than the call's expected duration. To provide easy SIP persistency configuration when a Layer 4 policy is defined with Application set to SIP (Layer 4 protocol must be UDP), AppDirector automatically creates a Layer 7 Server Persistency Text Match entry looking for SIP Call-ID for all the farms connected to this Layer 4 policy.
Document ID: RDWR-AD-V021403-UG0211
261
AppDirector Guide Traffic Management and Application Acceleration Radware recommends setting farms Sessions Mode to RemoveOnSessionEnd. AppDirector will age the Dynamic Session ID entry and the Client Table entry when a SIP BYE or CANCEL message is received for that Call-ID.
RADIUS Persistency AppDirector s server persistency for RADIUS traffic using the RADIUS attribute values to maintain persistency in other application sessions (e.g. HTTP) using the following mechanisms:
RADIUS Attribute The RADIUS attribute is required to maintain persistency for either RADIUS sessions as well as other application sessions (e.g. HTTP). Remote Authentication Dial-In Server (RADIUS) attributes are used to define specific authentication, authorization, and ing (AAA) elements in a profile, which is stored on the RADIUS daemon. s can use one of the following methods to maintain client server persistency for RADIUS using RADIUS Attribute value. •
Hashing - AppDirector selects an available server based on a hashing algorithm performed on the value of the specified RADIUS Attribute. You can configure hash persistency via the Text Match Session ID mechanism or for a simplified configuration
•
Dynamic Session ID learning mechanism (Text Match) - if no RADIUS Attribute persistency rule is configured, persistency will be kept using a RADIUS Identifier.
You can configure the RADIUS Attribute parameter at the farm configuration with the required RADIUS Attribute value. A Text Match Session ID persistency with Hash Persistency Method rule will be automatically generated. RADIUS attributes are used to define specific authentication, authorization, and ing (AAA) elements in a profile, which is stored on the RADIUS daemon. You can configure the RADIUS Attribute parameter at the farm configuration with the required RADIUS Attribute value. The default is 0, indicating that AppDirector will not look for RADIUS attributes in order to maintain persistency. In order to maintain persistency for RADIUS traffic (UDP ports 1812, 1813, 1645, 1646 or Layer 4 Policy Application parameter set to RADIUS), AppDirector searches the attribute within the RADIUS packets & learns its value for the following requests. The learnt values may be used in order to maintain persistency for other applications (e.g. HTTP). Persistency can be maintained on any Dispatch Method, but when using Hashing, (page 178), the behavior is different although persistency is still preserved: •
the hash function will be used in order to select a server.
•
in case the hash function selects a server which is not available, another server will be selected and the selection will be recorded in the Layer 7 Server Persistency Table (the reason for this is the natural server selection has to be overridden) You should set the Session ID Table size as necessary.
Values range from 0 (default - no RADIUS attribute will be learnt) to 255. The Sessions Mode must be Server Per Session. No additional configuration is required. The same mechanism is used for sessions originating from AppDirector managed servers to a remote RADIUS server that are NATed using Server NAT. The RADIUS Attribute is used for any RADIUS message types (Authentication, ing, Authorization). If a server is not available, AppDirector selects another server and stores the RADIUS Attribute and selected server in the Layer 7 Server Persistency Table, to ensure persistency for the following sessions.
RADIUS Proxy With RADIUS Proxy . When AppDirector manages RADIUS proxy servers that forward access/ing requests from clients to another RADIUS server, it is required to ensure that the request and reply are sent via the same RADIUS server.
262
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration For this purpose you need a RADIUS proxy server that can add a special attribute that includes its IP address in decimal format to the request. When this is present, AppDirector extracts the first 4 bytes of its value, ensures that this is an IP address of an available server and forwards the reply to it.
Notes: >> Configuring the RADIUS Proxy parameter overrides persistency according to the defined RADIUS Attribute in the farm. >> To work with RADIUS, you must first enable UDP tracking. This behavior can be defined per farm using the RADIUS Proxy parameter. When set to 0, the capability is disabled. To enable the capability, define the number of the RADIUS attribute that contains the persistency value.
Layer 7 Server Persistency Statistics
To view the Statistics window From the AppDirector window, select Layer 7 Server Persistency > Statistics. The Dynamic SID Statistics window appears with the following read-only parameters:
Parameter
Description
Persistency Identifier matches
Number of times a packet (both requests and responses) matched a Persistency Parameter configured in the Dynamic Session ID table. Default: 0
Successfully parsed Dynamic SID values
Number of times a Dynamic SID value found following the configured Persistency Identifier Default: 0
Dynamic SID Value Learned from Server
Number of times that Session ID value was learned from the Server’s request. Default: 0
Dynamic SID Value Learned from Client
Number of times that Session ID value was learned from the client's request. Default: 0
Reset Dynamic SID Statistics
Resets the Dynamic SID Statistics.
Document ID: RDWR-AD-V021403-UG0211
263
AppDirector Guide Traffic Management and Application Acceleration
Client Table Management This section discusses the Client Table, which stores data about sessions managed by AppDirector and also describes how to manage and present the Client Table. It includes the following topics: •
Types of Client Table Entries, page 264
•
Static Client Table, page 265
•
View Filtered Clients, page 266
•
Client Table Views, page 266
To maintain client-server persistency in an AppDirector farm, AppDirector uses the Client Table. This monitors which clients are connected to which servers for each Local Farm. When a client first approaches a farm, AppDirector checks whether there is an existing client entry in the Client Table: •
If the appropriate entry is found, the client is directed to the server that appears in the Client Table. In that case, there is no need to make a load balancing decision.
•
If an entry does not exist, a farm is selected according to the service requested. A server is then selected according to load balancing considerations defined by the Dispatch Method or according to the Layer 7 Persistency information, where applicable. An entry is then added to the Client Table, indicating which server was selected.
Once an entry is created in the Client Table, all subsequent packets that arrive from the client to a farm are forwarded to the server indicated in the Client Table entry. The traffic in the opposite direction, from the server to the client, is sent using the Virtual IP address with which the requested service is associated. This VIP address is used as the Source IP address of the outgoing traffic, which is also reflected in the Client Table entry. The Client Table also provides information about the way a client is sent to the server; for example, whether the selected server is a local server, whether the server is on a separate site, or if Port Multiplexing is used. Here is an example of a Client Table:
Source Address
Source Port
Requested Address
Requested Port
Farm Name
Server Address
Server Port
100.1.1.1
1062
100.1.1.100
80
Farm A
10.1.1.2
8080
100.1.1.2
1011
100.1.1.100
80
Farm B
10.1.1.2
8080
100.1.1.3
1079
100.1.1.100
80
Farm C
10.1.1.1
8080
Client Table Configuration Guidelines: The configuration of the Client Table involves the following steps: 1.
Set up the Sessions Modes
2.
Set up the Client Table Global Parameters
Now you can view the Client Table information using various view options.
Types of Client Table Entries There are different types of entries in the Client Table. Each depends on the conditions in which the session occurs, such as: who initiated the session, the structure of the network, the needs of the specific clients, etc. Entries include: •
Static Client: clients that are always assigned to the same server within the farm.
•
Dynamic Client: Dynamic clients are forwarded to a server that is available during the connection establishment process. AppDirector selects the best available server according to the load balancing definitions, as configured in the Dispatch Method or according to persistency.
264
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration •
NAT: NAT entries in the Client Table are created for sessions initiated by the servers when Server Network Address Translation (NAT) is used. NAT is used in this case to translate the server’s IP address to the Virtual IP address that is used to access the farm.
Note: When the server is disabled, the Client Table entries belonging to that server remain active to allow NAT for outgoing sessions originating from the server. Only when the server is removed are its sessions deleted from the Client Table. •
Client NAT: Client NAT entries are created for sessions in which Client NAT is used. Using the Client NAT capability, AppDirector hides the IP addresses of the clients from the servers. The original Source IP of a request is replaced by AppDirector with the configured NAT IP and port before forwarding the request to the server. The Client NAT feature is used when, for example, the client and the server are on the same subnet, so that the client IP address must be hidden. If not, servers may send replies directly to clients, instead of sending them through AppDirector.
•
Outbound NAT: Outbound NAT client entries are created for sessions in which the Outbound NAT capability is used. The Outbound NAT capability allows AppDirector to hide servers or other local hosts when sending traffic through AppDirector. Using the Outbound NAT capability, AppDirector replaces the original Source IP of a packet that is routed or bridged by AppDirector with the configured NAT IP before forwarding the request. It also replaces the Source port.
Static Client Table You may need to ensure that certain clients always access a specific server on the server farm, regardless of load balancing; for example, if you always need to access a specific server for management purposes by an . Static clients are clients that are always assigned to the same server within the farm.
Note: If a client is configured to statically use a specific server in a farm and the server is down, AppDirector does not select a new server. Also see Application/Farm Servers, page 172.
To add static clients to the Client Table 1. From the AppDirector menu, select Clients > Static Client Table. The Static Client Table window appears. 2. Click Create. The Client Table Create window appears 3. Set the parameters.
Parameter
Description
Client Address
IP address of the client. (Address from which the request is sent).
Farm Name
Name of farm providing the requested service.
Status
Status of client. This variable indicates the istrative status of this entry. Values: Active/Inactive
Document ID: RDWR-AD-V021403-UG0211
265
AppDirector Guide Traffic Management and Application Acceleration
Parameter
Description
Client Type
Type of Client Table entry: Values: Static (Default), Dynamic, ClientNAT, ServerNat and OutboundNat.
Server Address
IP address of server to which client is connected.
Server Port
The port of the server currently serving this client. Default: Zero (0) if no application port specified.
4.
Click Set. The client is added to the list as a static client.
View Filtered Clients The Client Table stores information about every client request handled by AppDirector. The size of the table makes it difficult to view. To generate reliable and useful reports and to prevent system failures, use Client Table filters to present information from the table.
To view filtered Clients From the AppDirector menu, select Clients > Filtered Client Table. The Filtered Client Table window appears, displaying these read only parameters:
Parameter
Description
Client Address
The IP source address of the client.
Client Port
The source port of the client. Default: 0
Requested Address
VIP of the farm that contains the required server.
Requested Port
Port of the requested T/UDP server. Default: 0
Server Address
IP address of server to which client is connected.
Client Table Views Since the Client Table stores information about every client request handled by AppDirector, it is too large to view without filtering the data. Use Client Table filters to retrieve and view a subset of table entries. To generate reliable and useful reports and to prevent system failures, use Client Table filters to present information from the table. You can define up to five different filters, where the logical condition between the filters is an OR condition. The condition between the different parameters within a filter is an AND condition. Each of the filters can be active or inactive. By default, all filters are inactive and when all filters are inactive, an empty table is displayed. The View Filters Create window allows you to set up to 5 different filters, where the logical condition between the filters is an OR condition. 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, which means that the whole Client Table is presented.
266
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration
To configure the View Filters window 1. From the AppDirector menu, select Clients > View Filters. The View Filters window appears. 2. Select the relevant filter from the table or Select Create. The View Filters Create window appears. 3. Set the parameters.
Parameter
Description
Index
Shows Filter Index number currently selected. Values: 1 - 5 Default: 1
Status
istrative status of the view entry Values: • Active: enables the view • Inactive: disables the view
Source IP From/To
Range of clients’ addresses. Default: 0
Requested IP From/ Range of addresses of servers providing requested service. To Default: 0 Source Port From/To Similar to destination port, the source port that a packet should carry to match the filter can be configured. Default: 0 Requested Port From/To
Destination port number for that protocol. For example, for HTTP, the protocol can be configured as T and the destination port as 80. The port configuration can also allow for a range of ports to be configured. Default: 0
Farm Name
Name of the client’s farm on the Remote AppDirector.
Server IP
IP address of server where Remote AppDirector is located, and reports its load to distributing AppDirector.
Client Type
This variable indicates the istrative type of this entry. Values: • Any (Default) • Client NAT • Dynamic • Server NAT • Static • Outbound NAT
Document ID: RDWR-AD-V021403-UG0211
267
AppDirector Guide Traffic Management and Application Acceleration
Parameter
Description
Action
The type of action to be performed on entries matching this filter. Values: • No Action (default) • Delete All Matching (Selected Filters) • Count All Matching (Selected Filters)
VLANTag
VLAN Tag information is used to generate reports for each customer by using the customer's VLAN Tag value. This parameter represents the 802.1q VLAN tag associated with the client entry. Default: A value of "0" in this field indicates that the VLAN Tag is not available.
4.
Click Set. Your configuration is set.
Reset Client on Server Failure When a server goes down, AppDirector redirects client requests to another available server. To provide quicker server failover, AppDirector can close the connection with the client as soon as the server is detected to be down. This will cause the client to immediately establish a new session to another server, ready to deliver data. This functionality can be activated per farm using the Reset Client on Server Failure feature. The Reset Client on Server Failure parameter is disabled by default. When Reset Client on Server Failure is enabled and the farm server is detected as not in service, AppDirector evaluates the client entries associated with the server and closes all the open T connections and clears the Client Table entry from the Client Table.
Note: The Reset Client on Server Failure cannot be activated for farms with the Sessions Mode set to Regular.
Close Session At Aging When the Client Aging on the device expires for a specific session, the device removes the Client Table entry for this session. AppDirector can also send a RESET to the server to close the associated port on the server, so the server can release the resources that were allocated for this session. This behavior is applicable for T sessions. This behavior is configurable with the Close Session at Aging farm parameter.
Client Table Sessions Modes To achieve maximum flexibility, AppDirector allows the Client Table to work in several modes. These modes are configured per AppDirector farm, during the farm configuration process. The AppDirector farm configuration example shown here is used in the following explanation of the Sessions Modes.
268
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration
Figure 11: Typical AppDirector Application AppDirector
Client
Server 1
VIP Address 100.1.1.100
100.1.1.
Server 2
Note: Definitions of Sessions Modes per farm can be overwritten using global parameters.
Entry Per Sessions Mode When Entry Per Sessions is used as the Sessions mode, AppDirector maintains Layer 3 persistency. In the Entry Per Sessions Mode, a new entry is added to the Client Table for each new session, allowing you to define one server to be part of multiple farms. In the Entry Per Sessions Mode, clients can send requests directly to a server’s IP address and to a farm’s VIP address simultaneously. Before sending a reply, AppDirector searches the Client Table for an entry with the appropriate Source port. If such an entry is found, AppDirector sends the response through the VIP address indicated in the Client Table. If no entry is found, the response is sent directly from the server’s IP address to the client’s IP address.
Note: When a client sends HTTPS requests, it will work in Entry Per Sessions Mode regardless of the Sessions Mode selected by the . The Entry Per Sessions Mode identifies an entry by the following parameters: •
Farm Name
•
VIP Address
•
Client IP Address
•
Server IP Address
•
Source Port Used from the Client to the Server
•
Destination Port Used from the Client to the Server
If, the client approaches the AppDirector Virtual IP address through HTTP, then for this client AppDirector selects Server 1 with a 10.1.1.1 IP address. In this case, the Client Table entry looks as follows:
Source IP Source Port Address 100.1.1.1
1234
Requested Address 100.1.1.100
Requested Port 80
Farm Name Farm 1
Server IP Address 10.1.1.1
Source Port 1234
While active, this entry instructs AppDirector to perform the following tasks: •
Request for service: All packets from client 100.1.1.1 go to port 1234 VIP address 100.1.1.100 and Destination port 80 and are forwarded to Server 10.1.1.1.
•
Response: All packets from Server 10.1.1.1 to client 100.1.1.1 with Source port 80 and Destination port 1234 are sent from AppDirector using Source address 100.1.1.100.
Document ID: RDWR-AD-V021403-UG0211
269
AppDirector Guide Traffic Management and Application Acceleration In this mode, a new entry is added to the Client Table for every session established between the client and the server. For example, in a simple Web page retrieval, a client may open a few T sessions with the server, using each session to transfer different parts of the page, such as text, GIF files, etc. Each of these sessions, identified by Destination port 80 and a unique Source port, such as 1234, 1235, 1236, etc., constitute a new entry in the Client Table.
Note: An entry’s age is reset only when AppDirector receives a new packet from the specific session, which is already reflected in the Client Table. Once a Client Table entry is established between the client and the server, all subsequent packets that match this entry are forwarded to the same server. Moreover, as long as there is an open session between the client IP and the VIP, all subsequent sessions from that client IP to that VIP and Destination Port are sent to the same server, even when different sessions (different Source ports) use different Client Table entries.
Note: Once an entry is made from a client to a server within a farm, the client continues to approach the same server, regardless of application (provided the same farm is used). Since a new table entry is made into the Client Table for every new session, the Client Table has many entries. You can increase the Client Table to accept more entries based on the amount of RAM available on the AppDirector unit (see Client Table Settings Tuning, page 65).
Layer 3 Client Table AppDirector finds entries in the Client Table by running the Hash function. The input for this function is the client’s IP address, where AppDirector performs calculations for finding the index number of the required entry. The Layer 3 Client Table is always used when Entry Per Session is used. AppDirector uses the Layer 3 Client Table to ensure Layer 3 persistency. This table contains information about the server selected for each client (Source IP address) in each farm, and allows AppDirector to select a server for a new session.
Note: The size of the Layer 3 Client Table can be configured and is defined as a percentage of the Client Table size (see Client Table Settings Tuning, page 65).
270
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration
Regular Mode In Regular mode, AppDirector maintains Layer 3 persistency. In this mode, each entry is identified by the following parameters: •
Layer 4 Policy VIP Address
•
Client IP Address
•
Destination T/UDP Port Used from the Client to the Server
If, the client approaches the AppDirector Virtual IP address through HTTP, then for this client AppDirector selects Server 1 with 10.1.1.1 IP address. Here, the Client Table entry looks as follows:
Source IP Address
Source Port
Requested Address
Requested Port
Farm Name
Server IP Address
100.1.1.1
–
100.1.1.100
80
Farm 1
10.1.1.1
While active, this entry instructs AppDirector to perform the following tasks: •
Request for service: All packets from client 100.1.1.1 to farm associated with VIP 100.1.1.100 and with Destination port 80 are forwarded to server 10.1.1.1.
•
Response: All packets from server 10.1.1.1 to client 100.1.1.1 with Source port 80 are sent from AppDirector using Source address 100.1.1.100.
Global (Per Device) Session Mode
To configure AppDirector Global Parameters 1. From the AppDirector menu, select Global > Global Parameters. The Global Parameters window appears. 2. Set the parameters.
Parameter
Description
Open New Entry When Source Port Different
• Enable: Each session that a client opens, is recorded in the Client Table separately.
Select New Server When Source Port Different
• Enable: Different sessions opened by a client's application are served by different servers, according to the load balancing algorithms.
• Disable (default): All client sessions are considered a single session, providing better performance.
• Disable (default) Note: This option provides a more accurate minimum- load balancing, but may hinder some applications that depend on the same server. It also may overload AppDirector`s internal tables. This option overrides the New Entry On Source Port option.
Document ID: RDWR-AD-V021403-UG0211
271
AppDirector Guide Traffic Management and Application Acceleration
Note: Open New Entry When Source Port Different and Select New Server When Source Port Different can override the per farm configuration if set to Enable. You can also configure both under each farm. However, if you enable them in the global configuration it will override what has been configured in a farm.
3.
Parameter
Description
Load Report Interval
Interval (in seconds) for sending dynamic updates of the local load to other AppDirector's devices that are served by this AppDirector. Also see Configuring Local Report Protocol, page 303.
Click Set. Your configuration is set.
Changing Sessions Modes Using Global Parameters Using Global Parameters, you can set AppDirector farms to operate in Entry Per Sessions Mode or Server Per Sessions Mode. The equivalents of a farm’s Session modes in Global Parameters are: •
Entry Per Session - the Open New Entry When Source Port Different parameter.
•
Server Per Session - the Select New Server When Source Port Different parameter.
The difference between individual farm and global configuration is that global configuration applies to all the farms on AppDirector, and can override the configuration of the individual farm. By default, global parameters are disabled, meaning that all the farms are in the Entry Per Sessions Mode, unless a different mode was defined during the farm configuration process. Enabling the Open New Entry When Source Port Different parameter automatically sets all AppDirector farms to Entry Per Sessions Mode, except for the farms where Server Per Sessions Mode is already defined. Enabling the Select New Server When Source Port Different parameter automatically sets all AppDirector farms to Server Per Sessions Mode.
Tip: Radware recommends disabling the Open New Entry When Source Port Different parameter and the Select New Server When Source Port Different parameter before setting Sessions modes for individual farms. The table below shows the relationship between farm settings and global settings. The top row shows Farm Modes and the left column shows Global Parameters. The value within each table cell represents the effective AppDirector behavior when the global setting is the value on the left and the farm level setting is as above.
Global Parameters
Farm Parameters Regular
Entry Per Session
Server Per Session
Regular
Entry Per Session
Server Per Session
Open New Entry When Source Entry Per Session Port Different
Entry Per Session
Server Per Session
Select New Server When Source Port Different
Server Per Session
Server Per Session
Regular
272
Server Per Session
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration
Server Per Session In the Server Per Sessions Mode, multiple sessions from the same client are load balanced separately. This mode is recommended when an application represents a large number of s by a single IP address as a client to AppDirector; for example, if many clients trying to reach AppDirector are located behind a proxy server. The Server Per Sessions Mode identifies an entry as follows: •
By VIP Address
•
By Client IP Address
•
By Source Port used from the Client to the Server
•
By Destination Port used from the Client to the Server
In Figure 11 - Typical AppDirector Application, page 269, the client opens six sessions to the AppDirector virtual address of 100.1.1.100 to retrieve a Web page, with all sessions destined to port 80. As the table shows, both servers 10.1.1.1 and 10.1.1.2 are being used for client 100.1.1.1.
Source IP Address
Source Port
Requested Address
Requested Port
Farm Name
Server IP Address
100.1.1.1
1234
100.1.1.100
80
Farm 1
10.1.1.1
100.1.1.1
1235
100.1.1.100
80
Farm 1
10.1.1.2
100.1.1.1
1236
100.1.1.100
80
Farm 1
10.1.1.1
100.1.1.1
1237
100.1.1.100
80
Farm 1
10.1.1.2
100.1.1.1
1238
100.1.1.100
80
Farm 1
10.1.1.1
100.1.1.1
1239
100.1.1.100
80
Farm 1
10.1.1.2
Note: The Server Per Sessions Mode is similar to the Entry Per Sessions Mode, as new entries are added in the Client Table for new sessions. The difference is that the sessions from the same client can be forwarded to different servers. As in the Entry Per Sessions Mode, the considerations of the Client Table size should be taken into .
UDP Session Tracking When traffic is transmitted using the UDP protocol, each UDP request is represented by a single packet. Here, all packets from the same client IP have the same Source IP, Source port, Destination IP, and Destination port numbers. It is therefore impossible to create a new entry in the Client Table for each request. Using the UDP Session Tracking parameter, AppDirector load balances requests for service of that type. By default, the UDP Session Tracking parameter is enabled and AppDirector tracks all the T/UDP sessions using the Client Table. If you disable tracking, only T sessions are included in the Client Table. Persistency is not maintained and each packet of the session can be forwarded to a different server. When the UDP Session Tracking parameter is disabled, individual UDP packets are load balanced packet by packet. and client NAT cannot be used for UDP sessions, since UDP sessions are not inserted into the Client Table.
Note: If UDP Session Tracking is disabled, each UDP server can participate in only one farm.
Remove on Session End The Remove on Session End mode allows AppDirector to remove entries from the Client Table before Aging Time expires. This mode is used to clear entries representing the T sessions closed before the end of the Aging Time.
Document ID: RDWR-AD-V021403-UG0211
273
AppDirector Guide Traffic Management and Application Acceleration AppDirector keeps track of the number of s attached to each server using the Client Table. This information is important when using the “least amount of s” dispatch method. AppDirector enhances server statistics by decreasing the number of s once a FIN is detected. The Remove on Session End mode operates like the Entry Per Sessions Mode, except: •
AppDirector marks the entry for deletion from the Client Table when it detects a RST or FIN packet between server and client, as the RST/FIN packets indicate that the session is closed.
•
The entry is aged in five seconds and subsequently removed.
•
For SIP/UDP traffic, AppDirector checks the SIP messages for the BYE command and applies the rapid Client Table entry aging mechanism when such a command is detected.
Remove Entry in Select Server When used in conjunction with the Server Per Sessions Mode, the Remove Entry in Select Server mode allows AppDirector to remove entries from the Client Table before Aging Time expires. This mode is used to clear entries representing T sessions that were closed before the end of the Aging Time. This mode operates like the Server Per Sessions Mode except for the following: •
AppDirector marks the entry for deletion from the Client Table when it detects a RST or FIN packet between server and client, as the RST/FIN packets indicate that the session is closed.
•
The entry is aged in five seconds and subsequently removed.
Network Address Translation (NAT) This section discusses Network Address Translation (NAT) features and contains these topics: •
Client NAT, page 275
•
Server NAT, page 279
•
Outbound NAT, page 284
Network Address Translation (NAT) is the translation of an IP address used within one network to a different IP address known within another network. One network is usually the inside network and the other is the outside. NAT hides the Source IP address. AppDirector uses these NATs..
Parameter
Description
Client NAT
Hides the IP addresses of clients approaching AppDirector farms, to solve routing issues. Both client IP and port are changed during Client NAT.
Server NAT
Server NAT allows AppDirector to hide the server’s IP address for outbound traffic in sessions initiated by servers. Server NAT uses StaticNAT, which means that only the IP address is changed without port translation. Server NAT is used for servers positioned behind AppDirector.
Outbound NAT
Hides IP addresses of hosts behind AppDirector and sends traffic through AppDirector. The IP address and the port are translated.
274
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration
Client NAT Using the Client NAT parameter, you can enable the Client NAT capability for the given farm server. Using Client NAT for a server means that AppDirector hides the Source IP addresses of clients that access the server in the farm. For more information on Client NAT capability,.
Note: Client NAT cannot be used for UDP sessions when UDP Session Tracking is disabled, as UDP sessions are not inserted into the Client Table. Client NAT enables AppDirector to hide client IP addresses when forwarding traffic to servers in farms. During this process, AppDirector uses Dynamic NAT to replace the original Source IP of a request with a predefined NAT IP address and dynamically selected ports, before forwarding the request to the server.
Configuring Client NAT The process of Client NAT configuration has several stages. Before configuring the Client NAT parameters, you need to: •
enable the Client NAT capability
•
set the Client NAT Tuning parameters globally on AppDirector.
Once the Client NAT feature is enabled on AppDirector, you can start configuring the Client NAT parameters. •
First, you need to specify the ranges of the Source IP addresses in the incoming traffic that you want to NAT. This is done in the Client NAT Intercept Addresses table. This table defines clients whose source addresses are NATed.
•
Next, you need to configure the IP addresses that AppDirector uses to translate the Source IP addresses of clients' requests. These are configured in the Client NAT Address table. This table defines the addresses that are used to perform NAT. The NAT addresses are also configured in ranges. The maximum number of configurable NAT addresses depends on the tuning value of the NAT Addresses table parameters, (see NAT Settings Tuning, page 65). For each farm, you can select a single NAT address range and for each server in the farm, you need to enable the Client NAT capability and optionally, select NAT addresses.
AppDirector allows you to configure different NAT address ranges for different servers in the farm. When no NAT address range is configured for the server, AppDirector uses the NAT address range configured for the farm. When a client with an IP address within one of the Client NAT Intercepted address ranges approaches a farm, a server is selected. If the Client NAT parameter is Enabled in the selected server’s configuration, AppDirector NATs the client's IP address and port using the configured NAT address range for the server or for the farm. When the reply from the server reaches AppDirector, it replaces the NAT address and port with the original client address and port, before forwarding the reply to the client.
Document ID: RDWR-AD-V021403-UG0211
275
AppDirector Guide Traffic Management and Application Acceleration
Notes: >> When no NAT addresses are configured, no Client NAT is performed. >> You can use the Client NAT capability only for Regular Servers, and not for Remote Servers, Distributed AppDirectors, Local Farm, or Loopback Servers. If Client NAT is required for a Remote Server, you need to configure this server as a Local Server in the farm, with Client NAT enabled. This ensures that traffic is forwarded to that server rather than redirected. >> When Client NAT is used in a farm where the Sessions mode is set to Regular, AppDirector uses the Entry Per Sessions Mode for the Client NAT sessions. >> In a redundant AppDirector scenario, the same NAT Addresses and Client NAT intercept addresses must be configured on both AppDirector devices.
Client NAT Global Parameters Client NAT conceals various network elements located behind AppDirector . When sending traffic through AppDirector with Client NAT, AppDirector replaces the original source IP of a packet that is routed or bridged by AppDirector with the configured NAT IP before forwarding the request, and replacing the source port.
Note: Client NAT is ed for T/UDP/ICMP traffic
To enable Client NAT 1.
From the AppDirector menu, select NAT > Client NAT > Global Parameters. The Client NAT Global Parameters window appears,.
Parameter
Description
Client NAT
Enable/ Disable. Client NAT hides client IP addresses approaching AppDirector farms, to solve routing issues. Both client IP and port are changed using Client NAT.
2.
Set the Client NAT to Enable. Client NAT is now enabled.
3.
Click Set. Your configuration is set.
Client NAT Addresses The Client NAT Addresses option for the farm specifies the NAT Addresses that are used to hide IP addresses of clients accessing this farm. For each farm you can select a single NAT Addresses range.
Note: When no Client NAT Address Range is selected for a farm, AppDirector uses one of the farms configured Client NAT Address Range when performing Client NAT for servers in this farm.
276
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration
To create a NAT Address Range 1. From the AppDirector menu, select NAT > Client NAT > NAT Addresses. The Client NAT Address Table window appears. 2. Click Create. The NAT Addresses Ranges Create window appears. 3. Set the parameters.
Parameter
Description
From IP Address
The first NAT address in the required range.
To IP Address
The last NAT address in the required range.
4. Click Set. Your configuration is set.
Client NAT Intercept Addresses The Client NAT Intercept Addresses window allows you to specify ranges of the source IP addresses in the incoming traffic that you want to NAT. This defines clients whose source addresses are NATed.
Note: To set the parameters of the Client NAT Intercept Addresses Table window, you must initially enable Client NAT.
To set the parameters of the Client NAT Intercepted Addresses Table 1. From the AppDirector menu select NAT > Client NAT > Intercept Addresses. The Client NAT Intercept Table window appears. 2. Click Create. The Client NAT Intercept Table Create window appears. 3. Set the parameters.
Parameter
Description
From Client IP
The first NAT address in the required range.
To Client IP
The last NAT address in the required range.
4. Click Set. Your configuration is set.
Client NAT Quick Setup The Client NAT Address Range defines a specific NAT range to use to hide client IP addresses when forwarding traffic to this server As part of HTTP policy there is a link to the Client NAT Quick Setup. This lists all defined Client NAT ranges and Farms and enables you to set a client NAT range on multiple farms. It also includes the option to define a new Client NAT range and to set X-Forwarded-For header automatically on a farm with the client NAT. You can run the Wizard while selecting client NAT range 0.0.0.0 to reverse the setting on all farms to No Client NAT and/or No X-Forwarded for.
Document ID: RDWR-AD-V021403-UG0211
277
AppDirector Guide Traffic Management and Application Acceleration
To configure Client NAT Address Range 1.
From the AppDirector menu select NAT. The NAT Settings window appears.
2.
Click the Client NAT Quick Setup button below. The Client NAT Quick Setup window appears.
3.
Set the parameters.
Parameter
Description
Client NAT Range
Select from list of defined Client NAT ranges.
New Client NAT Range From IP Address
Defines new client NAT range: from IP address.
To IP Address
Defines new client NAT range: to IP address.
Select All Farms
This changes all Farms check-boxes state to "selected".
Enable X-ForwardedMark the checkbox. For Header on Selected Farms Apply for all client source IP addresses
For all client source IP addresses, mark the checkbox. Note: When no client NAT address range is selected for a farm, AppDirector uses any of the configured client NAT address ranges when performing Client NAT forservers in the farm.
4.
List all farms defined in the system. Each farm should have an accompanying check-box marked to select it.
5.
Click OK. Your configuration is set.
Notes: >> Once you have set the paramaters and at least one NAT range was allocated, AppDirector will check that there is at least one Intercept range configured, if not, it will automatically configure a 0.0.0.0 to 255.255.255.255 range >> If you want to fine tune the ranges, you can do this through Client NAT Addresses, page 276.
Insert X-Forwarded-For In many cases it is important for the server that provides a service to know the identity of the client; for example, for billing. When using Client NAT, the source IP address is replaced by the NAT address, so that the server cannot know the identity of the original client. To solve this problem AppDirector can insert an X-Forwarded-For header with the identity of the original client in the traffic forwarded to server. To activate this capability in AppDirector, enable the Add X-Forwarded-For in HTTP request parameters in the farm configuration. Once activated, the following Layer 7 modification rule is automatically generated for the farm:
Parameter
Description
Index
The lowest available
Name
Auto-G
Action
Insert
278
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration
Parameter
Description
Direction
Client Requests
Layer 7 Method for Match
(empty)
Layer 7 Method for Action
Auto-G
AppDirector also generates the following entry in Layer 7 methods:
Parameter
Description
Name
Auto-G
Method
Header Field
Header Field
X-Forwarded-For
Token
$Client_IP
Server NAT Server NAT allows AppDirector to hide the server’s IP address for outbound traffic in sessions initiated by servers. Server NAT uses StaticNAT, which means that only the IP address is changed without port translation. Server NAT is used for servers positioned behind AppDirector. When a session is initiated by a server, the server’s request for service is sent using its IP address as the source address. If the server’s IP address is a private IP address, the server’s address must be translated to a public IP address. This ensures proper routing of the reply back across the Internet to the NATing device and back to the server. To enable servers with private IP addresses to initiate sessions out of their private network, you can use the Server NAT feature. When enabled, the server’s IP is translated to the Layer 4 Policy’s VIP and a new entry is added to the Client Table. Sessions originating from servers are tracked in the Client Table and tagged with a “NAT” tag to differentiate this traffic from other regular inbound client traffic.
Notes: >> Server NAT sessions always use the Entry Per Sessions Mode. >> When Server NAT is disabled, AppDirector forwards traffic with the server’s original source address. No address translation is done, and no entries are added to the Client Table. >> When Server NAT is enabled, you can define the Use Specific NAT Address parameters for all server NAT sessions. When the default of the Use Specific NAT Address parameters is 0.0.0.0, AppDirector selects the address according to the VIP of the Layer 4 Policy that is associated with the farm in which the server is included. >> If no servers are defined, you can define an "empty" farm, associate this farm with a Layer 4 Policy, and use its VIP address as the specific NAT address. >> If the traffic is received from a server with ‘Not In Service’ status, the traffic is handled according to the definitions of the When Server Is Not-In-Service parameters. >> When a server participates in multiple farms, outgoing server sessions are translated to the VIP address of the first found Layer 4 Policy associated with the farm in which this server is included. >> Use of a specific server NAT address impacts the NAT address used for all servers. >> When mirroring is used, server NAT entries are not mirrored. This figure shows how the server’s Source IP is replaced with the Layer 4 Policy’s VIP.
Document ID: RDWR-AD-V021403-UG0211
279
AppDirector Guide Traffic Management and Application Acceleration
Figure 12: Replacing the Server Source IP with Layer 4 Policy VIP Internet
Router
Source IP
100.1.1.20
10.1.1.100
AppDirector VIP 10.1.1.100 Source IP 10.1.1.1
10.1.1.1
10.1.1.2
10.1.1.3
Servers
Server NAT Global Parameters This enables you to configure the Server NAT. Server NAT replaces original IP addresses of AppDirector servers with AppDirector farm VIP addresses for outgoing traffic. Only the IP addresses are translated, without a change of ports. When using Server NAT with the regular VLAN, you can disable Server NAT for traffic on the regular VLAN. This is configurable using the Server in Regular VLAN flag. When set to Bridge Only, AppDirector does not create Server NAT entries in the Client Table for traffic between VLAN ports, but bridges such traffic. The default is NAT and Bridge, which maintains the previous behavior where all traffic from servers uses Server NAT.
Note: Mirroring cannot be used in Server NAT.
To configure the Global NAT parameters 1.
From the AppDirector menu, select NAT > Server NAT > Global Parameters. The Server NAT window appears.
2.
Set the parameters.
Parameter
Description
Server NAT
Enable or Disable (Default) the Server NAT feature. Server NAT hides IP addresses of messages sent from the server.
Use Specific NAT Addresses
You can choose a farm address to be used as a NAT address for all servers in all the farms, when required.
Remove at Session End
Whether to delete session entry from the session table at the session end. if not - the entries will be deleted by aging. Values: Disabled (default),enabled
3.
280
Click Set. Your configuration is set.
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration
Server NAT Parameters This allows you to configure how traffic received from a server with status Not In Service should be handled when Server NAT is Enabled. When using Server NAT in conjunction with the regular VLAN, you can disable Server NAT for traffic on the regular VLAN. This is configurable using the Server in Regular VLAN flag. When set to Bridge Only, AppDirector does not create Server NAT entries in the Client Table for traffic between VLAN ports, but bridges such traffic.
To set the Server NAT parameters 1. From the AppDirector menu select NAT > Server NAT > NAT Parameters. The Server NAT Parameters window appears. 2. Set the parameters.
Parameter
Description
When Server is Not- • NAT (default): Use Server NAT. In Service • Forward: Forward packets using routing, without Server NAT and without adding entries to Client Table. • Discard: Drop packets received from a server in Not In Service status. Server in Regular VLAN
Disables Server NAT for traffic on regular VLAN: • NAT and Bridge (Default): Keeps the previous behavior, where all traffic from servers uses Server NAT. • Bridge Only: AppDirector bridges traffic and does not perform NAT. No Server NAT entries are created in the Client Table for traffic between VLAN ports.
3. Click Set. Your configuration is set.
Server NAT VIP Selection per Server This feature provides static NAT for servers outbound traffic while being able to configure the VIP to be used as NAT address per server. AppDirector already enables you to perform dynamic NAT for outbound traffic from servers using VIP as well as for any outbound traffic using regular NAT addresses (non-VIP) as well as static NAT using non-VIP addresses (for SCTP).
Example Using the Outbound NAT configuration we want to static and dynamic NAT using VIP and non-VIP addresses per intercept range. You can work with dynamic NAT only using VIP and non-VIP addresses. For this you need the following: 1. Add NAT type to your Outbound NAT Intercept configuration. The values are Dynamic (default) and Static. 2. When the Outbound NAT address is VIP a. b.
NAT is not performed for intercept addresses that are not servers managed by AppDirector. When NAT type is Static - perform static NAT (server NAT). In this case the Server NAT global settings (for VIP not in service and VLAN) are relevant.
Document ID: RDWR-AD-V021403-UG0211
281
AppDirector Guide Traffic Management and Application Acceleration 3.
When Outbound NAT address is not VIP a. b.
When NAT type is Dynamic - perform regular Outbound NAT When NAT type is Static - perform static NAT like was implemented for SCTP, but for T and UDP. In this case the Intercept Range and NAT range must be equal.
4.
First configure an Outbound NAT address that represents "regular" Server NAT behavior (the first VIP configured attached to the transmitting server is used) - for example 255.255.255.255 or 0.0.0.0.
5.
Upon upgrading, translate the configuration as follows: a. b.
If your Server NAT is enabled and the specific VIP is 0.0.0.0 then for all servers you need to configure the special IP as an Outbound NAT If your Server NAT is enabled and a specific VIP is configured then for all the servers that you need to configure, set this IP as an Outbound NAT.
Configurations for a Server NAT VIP Solution 1.
Non-VIP Dynamic NAT - like traditional Outbound NAT, the NAT Type field is set to Dynamic (default). appdirector nat outbound address-range From IP Address
192.10.10.1
To IP Address (-t )
192.10.10.2
appdirector nat outbound range-to-nat Intercept From IP
2.2.2.1
To IP (-t )
2.2.2.254
Outbound NAT Addresses (-nf) 192.10.10.1 NAT Type (-nt)
Dynamic
Note: In AppDirector 2.x versions, the NAT Type parameter will be in the Outbound NAT range and not in the intercepted range.
282
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration 2. Non-VIP Static NAT appdirector nat outbound address-range From IP Address
192.10.10.1
To IP Address (-t )
192.10.10.10
appdirector nat outbound range-to-nat Intercept From IP
2.2.2.1
To IP (-t )
2.2.2.10
Outbound NAT Addresses (-nf)
192.10.10.1
NAT Type (-nt)
Static
Notes: >> The intercept range and NAT address range must be equal in size - otherwise error: "The NAT addresses range must be equal in size to the intercepted addresses range" will be displayed. >> In AppDirector 2.x versions, the NAT Type parameter will be in the Outbound NAT range and not in the intercepted range 3. VIP Dynamic NAT appdirector nat outbound address-range From IP Address
192.10.10.1
To IP Address (-t )
192.10.10.1
appdirector nat outbound range-to-nat Intercept From IP
2.2.2.1
To IP (-t )
2.2.2.10
Outbound NAT Addresses (-nf)
192.10.10.1
NAT Type (-nt)
Dynamic
Notes: >> If the NAT address range includes VIP, the range size must be 1. >> In AppDirector 2.x versions, the NAT Type parameter will be in the Outbound NAT range and not in the intercepted range.
Document ID: RDWR-AD-V021403-UG0211
283
AppDirector Guide Traffic Management and Application Acceleration 4.
VIP Static NAT appdirector nat outbound address-range From IP Address
192.10.10.1
To IP Address (-t )
192.10.10.1
appdirector nat outbound range-to-nat Intercept From IP
2.2.2.1
To IP (-t )
2.2.2.10
Outbound NAT Addresses (-nf)
192.10.10.1
NAT Type (-nt)
Static
Notes: >> In AppDirector 2.x versions, the NAT Type parameter will be in the Outbound NAT range and not in the intercepted range. >> Traffic from server X will always be NATted using the same VIP (configured in the Outbound Intercept NAT entry that includes server X in the intercept range), regardless of the protocol/port used. >> You cannot configure more than one VIP to the same range of servers. The Outbound NAT Ports per Address tuning parameter must be set to at least 15,000 because this requires that NAT ports over 10,000 will be used to minimize the possibility of conflict with inbound sessions. The availability of each port will be checked before it is used for Outbound NAT.
Outbound NAT Outbound NAT enables AppDirector to hide various network elements located behind AppDirector. Using this feature, AppDirector implements Dynamic NAT, which replaces the original Source IP and source port of a packet that is routed or bridged with the configured NAT IP, before forwarding the request.
Note: Outbound NAT is ed for T/UDP/ICMP/SCTP traffic. Using Outbound NAT, AppDirector can NAT not only traffic from IP addresses of servers managed by AppDirector, but also from any IP address behind AppDirector. The network elements whose addresses are NATed can be servers or other local hosts. You can set different NAT addresses for different ranges of Intercepted Addresses. Outbound NAT applies only to traffic routed or bridged by AppDirector. Traffic destined for a Layer 4 Policy VIP address is not NATed using Outbound NAT, even if the element’s IP appears in the Outbound NAT Intercept Addresses table. For NAT traffic to Layer 4 Policy VIPs, use Client NAT (see page 275).
Note: Outbound NAT entries in the Client Table always use the Entry Per Sessions Mode.
284
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration
Figure 13: Outbound NAT Operation
Dest. Address 100.1.1.100
AppDirector
2 Return
1 Request
Source Port 7777
Destination Port 7777
Outbound NAT Address 100.1.1.100 Source Address 10.1.1.11
Destination Address 10.1.1.11
Port 8888
Src Address 100.1.1.100
Port 8888
Internet
Network Elements 10.1.1.11
10.1.1.12
10.1.1.1
The AppDirector Outbound NAT operation (as shown here) proceeds as follows: 1. A network element located behind AppDirector sends a request for service to an IP. The request is intercepted by AppDirector, which replaces the intercepted source address 10.1.1.11 and port 7777 with the Outbound NAT address 100.1.1.100 and port 8888. 2. AppDirector receives the reply packet, replaces the destination address 100.1.1.100 and port 8888 with the element’s original address 10.1.1.11 and port 7777, and returns it to the originating network element.
Next Hop Routers Each host or router that handles a packet examines the Destination Address in the IP header, computes the next hop that will bring the packet one step closer to its destination, and delivers the packet to the next hop, where the process is repeated. A Next Hop Router (NHR) is a network element and is used for outbound traffic in Multi Homing configurations. NAT addresses can be associated with Next Hop Routers (NHRs), similar to the way VIPs are associated with NHRs. This provides a backup NHR for NAT Addresses, or for the simultaneous use of two NHRs with Hashing for the outbound traffic.
Setting Up Outbound NAT This process has several stages. Before configuring Outbound NAT, you need to: 1. Set the Outbound NAT Tuning parameters (see NAT Settings Tuning, page 65). 2. Globally enable the Outbound NAT feature on AppDirector.
Document ID: RDWR-AD-V021403-UG0211
285
AppDirector Guide Traffic Management and Application Acceleration
Outbound NAT Global Parameters When sending traffic through AppDirector with Outbound NAT, AppDirector replaces the original source IP of a packet that is routed or bridged by AppDirector with the configured NAT IP before forwarding the request, and replacing the source port.
Note: Outbound NAT is ed for T/UDP/ICMP/SCTP traffic.
To enable Outbound NAT 1.
From the AppDirector menu, select NAT > Outbound NAT > Global Parameters. The Outbound NAT Global Parameters window appears
2.
Set the parameters.
Parameter
Description
Outbound NAT
Enable/ Disable(Default): Outbound NAT hides the IP addresses of clients approaching AppDirector farms, to solve routing issues. Both client IP and port are changed in the process of Client NAT.
3.
Set the Outbound NAT to Enable.
4.
Click Set. Outbound NAT is now enabled.
Outbound NAT Addresses Outbound NAT Addresses are the IP addresses that must be used to translate source IP of outbound traffic. To define which source IPs are to be translated and to what Outbound NAT address configure Outbound NAT Intercept Addresses..
To tune the Outbound NAT settings 1.
From the Services menu select Tuning > Device. The Device Tuning window appears.
2.
Set the Outbound NAT Addresses After Reset and Outbound NAT Intercept Ranges After Reset parameters to the required number of entries.
3.
Click Set.
To set the parameters of the Outbound NAT Address Table 1.
From the AppDirector menu, select NAT > Outbound NAT > NAT Addresses. The Outbound NAT Address Table window appears.
2.
Click Create. The Outbound NAT Address Table Create window appears.
3.
Set the parameters.
286
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration
Parameter
Description
From IP Address
The first address in the NAT Addresses range.
To IP Address
The last address in the NAT Addresses range. Note: The maximum number of IP addresses that can be defined in the Outbound NAT IP Addresses table must not be higher than the value of Outbound NAT Addresses Table specified in Tuning Table.
Redundancy Mode
For redundancy operation: Active (Default): Farm is operating regularly on AppDirector. Backup: Farm is not operational, and it backs up another farm on another AppDirector device. When other AppDirector fails, this farm takes over and becomes operational.
Segment Name
Segment providing the traffic that arrives from the configured segment.
NAT Mode
Defines whether this NAT address range is used to perform regular dynamic NAT on outbound traffic (source IP and port translation) or static NAT using VIP (N to 1 source IP translation only) or static NAT for SCTP NAT for SCTP (N to N source IP translation only). Values: Dynamic (default), SCTP NAT, Static
4. Click Set. Your configuration is set.
Outbound Intercept Addresses You can associate Outbound NAT Intercept Addresses with Outbound NAT Addresses, to indicate which NAT addresses are to be used for different Intercept addresses. When no Outbound NAT Addresses are associated with an Outbound NAT Intercept Range, then AppDirector selects any of the configured Outbound NAT Addresses when NATing traffic from that range.
Note: When an Outbound NAT Intercept Range includes servers managed by AppDirector, Outbound NAT is performed for traffic from the servers even if Server NAT is enabled.
To set the parameters of Outbound NAT Intercept Addresses 1. From the AppDirector menu select NAT > Outbound NAT > Intercept Addresses. The Outbound NAT Intercept Table window appears. 2. Click Create. The Outbound NAT Intercept Table Create window appears 3. Set the parameters.
Parameter
Description
Intercept From IP
First address in the Outbound NAT Intercept addresses range.
To IP
Last address in the Outbound NAT Intercept addresses range.
Aging Time
Period of idle time after which the Client Table entries associated with this range are removed. Aging Time for Outbound NAT entries is determined according to the aging time set by the in the Outbound NAT Intercept table. Default: 60 seconds.
Document ID: RDWR-AD-V021403-UG0211
287
AppDirector Guide Traffic Management and Application Acceleration
Parameter
Description
Outbound NAT Addresses
Associates a specific NAT address with selected intercepted range of addresses. Default: 0.0.0.0.
Remove Entry at Session End
Whether to delete session entry from the session table at the session end. If not - the entries will be deleted by aging. Values: Disabled (default)/Enabled
4.
Click Set. Your configuration is set.
Outbound NAT using VIP This feature enables you to use a VIP address as a NAT address in outbound NAT. You need to configure the outbound parameters as follows: appdirector nat outbound address-range From IP Address
2.10.10.10
To IP Address (-t )
2.10.10.10
appdirector nat outbound range-to-nat Intercept From IP
2.2.2.1
To IP (-t )
2.2.2.10
Outbound NAT Addresses (-nf)
2.10.10.10
NAT Type (-nt)
Static
Notes: >> 2.2.2.1-2.2.2.10 is the range of the servers needs to use NAT. >> 2.10.10.10 is a VIP on the device. >> When a server from this range sends outbound traffic, NAT will be used, regardless of the port\protocol of the server. >> You cannot configure more than one VIP for the same range of servers. >> Since we use high ports, you must configure more than 15,000 ports for the tuning of outbound NAT.
288
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration
Configuring AppDirector Advanced Global Parameters The AppDirector Global Parameters window allows you to configure advanced system level settings.
To configure global information 1. From the AppDirector menu, select Global > Global Parameters. The Global Parameters window appears. 2. Set the parameters.
Parameter
Description
Open New Entry When Source Port Different
When enabled, different sessions from the same client to the same destination are counted separately, but all use the same firewall. Enabling this option can produce finer load balancing and ensure that all sessions from the same client to the same server use the same firewall. When disabled, all the sessions of one application are considered a single session, to enable better performance.
Select New Server When Source Port Different
When enabled, different sessions opened by a client's application are served by different servers, according to the load balancing algorithms. This option provides a more accurate minimum- load balancing, but may hinder some applications that depend on being served by the same server. It also may overload the device's internal tables. This option overrides the New Entry On Source Port option. Values: Enable/disable
Load Report Interval
Interval (in seconds) for sending dynamic updates of local load to other AppDirectors served by this AppDirector.
Load Report Timeout
The time (in seconds) this device will wait to receive load reports from a remote device. After this timeout, the remote device is not considered to be responding. According to the number of retries configured in the farm, the remote AppDirector becomes inactive, similar to the connectivity checks of regular servers.
3. Click Set. Your configuration is set.
Document ID: RDWR-AD-V021403-UG0211
289
AppDirector Guide Traffic Management and Application Acceleration
Tweaks The AppDirector Global Parameters Tweaks window allows you to further refine your advanced system level settings including the enabling and disabling of the Acceleration Engine.
To refine global information 1.
From the AppDirector menu, select Global > Tweaks. The Tweaks window appears.
2.
Set the parameters.
Parameter
Description
Client Grouping Mask
Sets the grouping mask for clients. This IP mask defines a group of clients for which the same farm server should be selected. E.g. 255.255.255.255
UDP Sessions Tracking Whether UDP sessions are recorded in the Client Table. Values: Enable (default)/ Disable. One Trap
Determines how traps are issued when a server fails. Values: Enable (default)/ Disable.
Configured Timeout After T Failure
If this option is enabled, AppDirector will wait the amount of time specified in the connectivity interval of the farm before rechecking the server after a T connectivity check is not responded to. When enabled, the default period is 3.5 seconds. Default: Disable
No Slash After GET in Extended HTTP Check
In the extended HTTP check, AppDirector issues the request to the server in the format GET /
Extended Check Host Mode
By default, AppDirector uses the server's IP address in the HTTP request of the extended HTTP check. This allows the use of the farm name instead. Default: Server IP.
Extended LRP Security When the Triangulation redirection method is used (see Global Triangulation Redirection, page 324), the Triangulation VIP address must be on the same subnet as the Virtual IP address, for security reasons. To ensure that the Triangulation VIP address configured for a farm is on the same subnet as that farm, the Extended LRP Security option must be enabled. Session ID Sharing
Enables or disables sharing of the Session ID information among multiple farms using the same Session ID. When a specific Session ID value is learned through one farm, the same Session ID value can be used also for server selection in other farms. Default: Disable When a Session ID value is learned through a client's session with one farm (farm1) and then is seen in a client request for another farm (farm2), AppDirector checks that the server indicated by the Session ID value (a server in farm1) is also in farm2. If not, then AppDirector uses load balancing to select a server in farm2.
290
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Traffic Management and Application Acceleration
Parameter
Description
DSID reply Learning in When using a DSID policy, this option causes the device to inspect each 'First' mode reply of each transaction, on the same session, even if Layer 7 Persistent Switching Mode is set to FIRST. AppDirector inspects the first request in each T connection, selects a server, and forwards the request. During the rest of the T connection, AppDirector forwards all further requests to that server. If you need to learn from each response, you should configure one of the 'complete' Persistent Layer 7 Switching modes (Overwrite or Maintain). • Inspect first reply – disabled (default) • Inspect all server replies – provides backwards compatibility with previous AppDirector versions. Note: DSID is HTTP dependent and cannot be used with GenericSSL offloading selected in the Layer 4 Policy Application, therefore Inspect First (disabled) is used. See Layer 4 Policies, page 183. Outbound SIP Session Outbound SIP sessions must use Server NAT to hide the server IP address behind the service IP (VIP). To return the session reply to the initiating server, AppDirector must use a Call-ID persistency mechanism. Values: Disabled (default), Enabled Note: for Outbound SIP sessions has a performance impact. Therefore, this feature is activated by flagging the Outbound SIP only when required (disabled by default). Also see Outbound SIP Sessions, page 406 When Outbound SIP traffic must be ed: • Servers from the sent outbound traffic can only belong to farms attached to a SIP Layer 4 policy. This ensures that a SIP service VIP is used as Server NAT. • If Layer 7 load balancing is used (for inbound SIP Layer 4 policies), DSID must be enabled for all farms belonging to this Layer 7 policy. SIP Aging on Session End
Aging time for SIP dynamic SID entries and SIP client entries as a result of the SIP session end, measured in seconds.
Document ID: RDWR-AD-V021403-UG0211
291
AppDirector Guide Traffic Management and Application Acceleration
Parameter
Description
Acceleration Engine (requires reboot)
Controls the Application Acceleration Engine. Values: • Enable (default)
Enhanced Acceleration • Disable
Standard Acceleration Outbound Inquiries Time-Out
Generic parameter for any AppDirector originated request timeout (e.g. DNS, OCSP, TSL file fetch). Note: Not applicable to NTP inquiries performed by AppDirector.
3.
Click Set. Your configuration is set.
Note: Status changes including enabling/disabling the acceleration engine are not exported to the configuration file when the device configuration is saved. When copying configurations between AppDirector devices, ensure that their statuses are aligned before importing a configuration.
292
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Configuring Global Load Balancing
Chapter 4 – Configuring Global Load Balancing This chapter describes the methods used in the global application switching schemes for global traffic management. This chapter includes the following sections: •
Global Traffic Management, page 293
•
Proximity, page 297
•
Configuring Local Report Protocol, page 303
•
Domain Name System (DNS), page 311
•
Redirection, page 319
Global Traffic Management This section introduces global traffic management methods and devices and includes these topics: •
IP Traffic Management, page 293
•
Global Solution Configuration Guidelines, page 296
IP Traffic Management The global IP traffic management solution is intended for companies with server sites in multiple locations. Distribution of server sites at different locations ensures high availability while maintaining multiple level redundancy. If there is damage to a single server, farm, or site, business continuity is maintained since switching from one server site to another is transparent to the s. Globalization of business requires global server sites that ensure availability and efficiency over great geographical distances. Organizations can increase productivity through resource sharing among different branches placed in various locations. For example, in a company, that has multiple data centers located all over the world, each data center may act as an independent business unit. Global traffic management leads to better istration and provides all employees, business partners and customers with critical resources, 24/7 availability, and optimal content delivery. This figure illustrates an example of a global load balancing scheme. New York
London
AppDirector provides site optimization and availability over geographic distances in a way that is entirely transparent to the . Various corporate resources are treated as a single entity. The entire corporate data resource can be represented by a single logical address that corresponds to entities at multiple physical locations.
Document ID: RDWR-AD-V021403-UG0211
293
AppDirector Guide Configuring Global Load Balancing
Transactional Flow Before considering a global solution it is essential to understand the flow of transactions over the web and the challenges posed when multiple sites are used. •
DNS resolution. To access Internet services the first basic step regardless of the application is host name resolution; finding the IP address for the service name, using the DNS (Domain Name System) protocol.
•
Application Transaction. Once the client receives the IP address of the target host name the application transaction starts. A common client transaction involves multiple steps and often multiple T connections. During the transaction a client may perform name resolution a few times, work behind proxies or experience disconnections and resets. Therefore, the IP address of the client may not be consistent.
AppDirector Global solution follows the transaction flow to provide availability and continuity throughout the entire transaction life: •
DNS Redirection - AppDirector functions as authoritative domain name server for the services it load balances. When an AppDirector device receives a DNS A record query it selects the best site for the service and answers with that site VIP.
•
Application Redirection - is required in the following cases: —
During the transaction life, the site selected by the DNS redirection mechanism becomes unavailable or overloaded.
—
During an HTTP transaction life, a new T connection arrives at a different site than the one where the transaction started.
—
Protocols that do not use DNS as a first step.
AppDirector s specific protocol redirection mechanisms (HTTP/S, RTSP and SIP) and generic mechanisms (Proxy and Radware patented Global Triangulation).
Site Selection AppDirector selects the best site based on availability, load and network proximity. •
Load & Availability. Any AppDirector with site selection privileges must know the condition of every other site to make the appropriate decisions, based on the real-time dynamic load. This is achieved via Radware proprietary protocol called LRP (Load Report Protocol).
•
Proximity. Network proximity indicates the network distance or time distance between a and a data resource. For example, if a is geographically closer to the New York site than to the Chicago site, yet can access the Chicago site faster when the network path to the New York site is overloaded. To measure network proximity AppDirector devices perform proximity checks to the client subnet. In addition any AppDirector with site selection privileges must know the network proximity of the client to every other site to make the appropriate decisions. This is achieved via Radware proprietary protocol called PRP (Proximity Report Protocol).
Caution: All devices in a Global configuration must run the same software version to ensure that LRP and PRP algorithms can run between the sites.•
Load Balancing Scheme AppDirector-Global balances traffic between multiple distributed sites according to the load present at each site. However the AppDirector Global device selects itself as the best site as long as the load on its local servers is lower than the Distribution Threshold configured for the specific farm and local servers are available. An AppDirector Global device starts distributing immediately in the following cases: •
All local servers are inactive, either operationally or istratively (disabled or in backup mode).
•
The Distribution Threshold is set to 0.
294
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Configuring Global Load Balancing The maximum number of s that an AppDirector device can receive from other AppDirectors is determined by the configured Farm Capacity Threshold. Once reached, the AppDirector device uses LRP to inform all other AppDirectors sending traffic to this farm that it can no longer handle directed traffic. You can define the Distribution Threshold parameters and the Capacity Threshold parameters per farm within AppDirector-Global. These parameters are measured in number of Client Table entries for this farm. You can also define the Capacity Threshold for the farms of AppDirector devices.
Radware Devices Used in Global Solution To implement the global traffic management solution, you need to work with an AppDirector-Global device - an AppDirector device where a Global Traffic Management license is installed. An AppDirector Global device s both local traffic management and global traffic management best site selection. A distributed site can be a remote server or another AppDirector site. The table below describes the differences between AppDirector and AppDirector global solutions for functionality.
Table 4: AppDirector: Regular versus Global Functionality
Functionality
AppDirector
AppDirector Global
Server types ed
Regular
Regular
Local Triangulation
Local Triangulation
Local Farm
Local Farm Remote Server Local AppDirector Distributed AppDirector
LRP
Send
Send and Receive
PRP
Answer PRP queries
Answer and Initiate PRP queries
Redirects traffic to other locations
No
Yes
Redirection Type ed
DNS, HTTP & RTSP for Local Redirection
DNS, HTTP & RTSP & Global Triangulation.
DNS Server Functionality (DNS Resolution)
Yes
Yes
VIP Anycast ment
Yes
Yes
BWM & IPS and DoS functionality
With proper license
With proper license
Cookie Persistency
Yes*
Yes*
(Requires Special License)
Document ID: RDWR-AD-V021403-UG0211
295
AppDirector Guide Configuring Global Load Balancing Server
Server
Server
Distributed devices: AppDirector/AppDirector-Global
Remote Server Main device: AppDirector-Global
Server
Server
Server
Global Solution Configuration Guidelines To achieve a globally distributed solution, the following steps should be performed: On a device without site selection privileges (AppDirector or AppDirector Global) you need to perform the following actions: •
Configure provided services as for local load balancing (farms including local servers, Layer 4 policies, host names, etc.)
•
In order to preserve global persistency for HTTP traffic under any circumstance, it is recommended to activate Insert cookie for HTTP Persistency. See HTTP Persistency in Global Environments for more details.
•
Configure an LRP entry for each combination of a farm that is part of a distributed service and a site with distribution privileges.
•
Configure the proximity checks that you want the device to perform.
On a device with site selection privileges (must be AppDirector Global) you need to: •
Define a farm for each distributed service. Each farm includes local servers plus Distributed AppDirector servers for all distributed sites (the server address is the VIP address of the service on the distributed AppDirector or a public NAT address of that VIP) and/or remote servers.
Note: If a distributed site is connected via multiple WAN links (multi-homing), it appears in the distributing site farm as multiple servers - one for each WAN link (each server address is the public NAT address for the distributed site VIP via a different WAN link). •
For each farm the redirection methods must be configured.
•
In order to preserve global persistency for HTTP traffic under any circumstance, it is recommended to activate Insert cookie for HTTP Persistency. See HTTP Persistency in Global Environments for more details.
•
Configure the rest of the service configuration as for local load balancing (Layer 4 policies, host names, etc.)
•
Configure proximity, including static proximity if required.
•
Configure DNS persistency, if required.
296
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Configuring Global Load Balancing When the solution includes multiple sites with distribution privileges, LRP entries must be configured to report local load to the other distributing sites.
Note: To ensure that the inter-site proprietary data exchange protocols work properly, the devices in all sites must run the same version.
Caution: All devices in a Global configuration must run the same software version to ensure that LRP and PRP algorithms can run between the sites.
Proximity This section provides information about the methods AppDirector uses to measure proximity to redirect traffic and includes the following topics: •
Proximity Parameters, page 298
•
Proximity Checks, page 299
•
Proximity Report Protocol (PRP), page 300
•
Static Proximity Database, page 301
AppDirector-Global maintains two proximity databases that hold information about a specific subnet of IP addresses and lists the best three servers for this range. The servers are presented in the list according to proximity considerations, the closest server appearing first. The server is either a Virtual IP address on a Distributed AppDirector device (bound to a cluster of physical servers) or a standalone remote server. If the top priority server is unavailable or loaded, AppDirector-Global sends clients to the next best server/site. If multiple application instances (farm servers) are defined on the top priority server, AppDirector-Global distributes the clients between the instances in a weighted cyclic manner. The following databases are kept: •
Static database, -defined
•
Dynamic database, built dynamically by AppDirector-Global
Document ID: RDWR-AD-V021403-UG0211
297
AppDirector Guide Configuring Global Load Balancing
Proximity Parameters Before you configure proximity checks, you need to set up the Proximity Parameters.
To configure Proximity Parameters 1.
From the AppDirector menu, select Proximity > Parameters > General. The Proximity Parameters window appears.
2.
Set the parameters.
Parameter
Description
Proximity Mode
The can determine the proximity mode as either: • No Proximity (default): No proximity is operated. • Static Proximity: AppDirector will only use redirections according to static proximity table. Dynamic auto learning mechanism is off. • Full Proximity: AppDirector will redirect according to the static redirections, and will use auto learning for subnets which are not defined as static entries.
Main DNS Address
IP address of the local primary DNS server. AppDirector avoids unnecessary proximity calculations in case the DNS server is located near AppDirector. DNS requests that are received from this DNS server are replied using load considerations only.
Backup DNS Address
IP address of the local secondary DNS server. AppDirector avoids unnecessary proximity calculations in case the DNS server is located near AppDirector. DNS requests that are received from this DNS server are replied using load considerations only.
Proximity Aging Period
Period of time, in minutes, in which a dynamic entry is kept in the database. When this time is about to expire and a new request is received from a client IP within this range, AppDirector -Global refreshes the information of that entry by re-executing the proximity checks. Values: 0 - 10080 minutes (a week) Default: 2880 minutes (2 days).
Hops Weight
Emphasis to put on the number of hops between client and farms when determining proximity. The number of hops affects the load balancing decision based on proximity considerations. Values: 1 (default) - 100
Latency Weight
Emphasis to put on the time between client and farms when determining proximity. The number effects the load balancing decision based on proximity considerations. Values: 1 (default) - 100
298
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Configuring Global Load Balancing
Parameter
Description
Load Weight
Emphasis to put on the load of remote server farm between client and farms when determining proximity. The number effects the load balancing decision based on proximity considerations. Values: 1 (default) - 100
Proximity Table Cleanup
The frequency of the Proximity Table cleanup. Default: 0
3. Click Set. The proximity parameters are recorded.
Proximity Checks AppDirector has a sophisticated mechanism to detect network proximity using a dynamic database of clients and their proximate sites. This is constantly updated by an auto-learning mechanism. To get accurate network proximity results, the checking method should be configured to cross all obstacles en route to the client. AppDirector uses several methods to detect the number of hops and the latency from the client to each of the sites. These methods ensure that the proximity check will go through any router and firewall with maximum accuracy. When a client approaches AppDirector, a proximity check is performed by each site and the results are communicated using the Proximity Report Protocol (PRP). Now AppDirector can redirect the client to the closest site. When another client from the same network approaches AppDirector, later, the nearest site is now known, and the client is immediately redirected there.
To configure Proximity checks 1. From the AppDirector menu, select Proximity > Parameters > Proximity Checks. The Proximity Checks window appears. 2. Set the parameters.
Parameter
Description
Proximity Checks
Sets whether the AppDirector device is allowed to perform proximity checks for AppDirector-Global. The proximity probes themselves are a combination of IP,T and application layer probes (Including T ACKs and ICMP Echo requests) to ensure accurate measurements. Values: Enable (Default): AppDirector/AppDirector-Global can serve as a Distributed server for other AppDirector-Global devices and can perform proximity checks for them. These AppDirector devices appear in the Distributed Sites definitions. Disable: No proximity checks are done for other AppDirector devices.
Basic Check
A simple ping test unrelated to the application used by the who triggered the proximity check. Default: Enabled
Advanced Check
Test that simulates standard applications (using UDP traffic). Sometimes IDS devices may consider such proximity check packets as an attack. Default: Enabled.
Document ID: RDWR-AD-V021403-UG0211
299
AppDirector Guide Configuring Global Load Balancing
Parameter
Description
Application Independent Check
Test that uses application information in packet received from the remote client to simulate a response.
Application UDP Traceroute Check
Using the traceroute tool for the proximity check in the example above, AppDirector can measure latency and the number of hops to the last router. The traceroute proximity check is implemented using the UDP protocol to port 37853.
Default: Enabled.
Default: Enabled. Application Aware Check
Test that simulates a generic response, unrelated to client's request.
Failure Notification
Controls whether is notified when proximity checks fail.
Check Retries
If another AppDirector does not answer consecutive PRP requests, AppDirector-Global assumes that it cannot answer and ignores that particular AppDirector for this client.
Default: Enabled.
Default: 2 Check Interval
An interval in seconds during which AppDirector -Global sends a PRP request packet to another AppDirector. If no answer is received within this period, AppDirector-Global resends the PRP request packet. Default: 5
3.
Click Set. The proximity checks are recorded.
Proximity Report Protocol (PRP) AppDirector-Global can redirect traffic to distributed locations over the Internet, if the distributed site provides better service to the client (in of availability, load and proximity). These distributed sites can have a standalone server or a server farm managed by another AppDirector. Information on the proximity of these distributed sites to the client enables AppDirector-Global to make such decisions. When a distributed site is equipped with an AppDirector that manages a server farm, a proprietary inter-AppDirector protocol, called PRP (Proximity Reporting Protocol), is used by AppDirector-Global to query other remote AppDirectors about their proximity to a client (can be client or DNS server). PRP is a simple UDP-based protocol that uses port UDP port 2091. To select the closest site for a specific client, AppDirector-Global finds out how “far” this client is from all the AppDirectors in the system. To do this, AppDirector-Global calculates the number of router hops and latency between itself and the client. Then, AppDirector-Global requests all other AppDirectors to do the same and receives a report from each indicating router hops and latency between each of them and the client. To “ask” other AppDirectors about the proximity information, AppDirector-Global uses the Proximity Report Protocol (PRP), which is a UDP-based protocol. When AppDirector-Global needs to gather proximity information about a client, it sends PRP requests to all AppDirectors in the system. Each AppDirector then calculates router hops and latency between itself and the client and reports back to AppDirector-Global, using a PRP response packet. PRP uses UDP port 2091.
Notes: >> AppDirector can also send PRP reports. Only AppDirector-Global can send PRP requests for proximity information. In addition, AppDirector-Global receives and uses the PRP responses to distribute traffic globally according to proximity considerations.
300
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Configuring Global Load Balancing >> An AppDirector which receives the request from the client and is initiating the PRP queries must always be an AppDirector-Global. >> An AppDirector device that receives PRP queries and responds can be either AppDirector or AppDirector-Global and proximity checks must be configured. When a client request arrives from a class C network for which there is no proximity data, AppDirector gathers proximity information for the class C network of the client. To gather this data the Initiator AppDirector performs the following: •
Sends proximity checks to this new class C network.
•
Sends PRP queries to all distributed servers (Distributed AppDirector type servers) in the farm servicing this client request, asking them to perform proximity checks to this class C network.
•
An AppDirector that initiates PRP queries saves both its own proximity results and those received from AppDirectors receiving PRP queries in its Dynamic Proximity table for future requests from this class C network.
PRP in a Multi-Homed Environment When an AppDirector is installed behind a NAT device that load balances inbound and outbound traffic between multiple WAN links it is operating in a multi-homed environment. Here, an AppDirector service (VIP) is accessible via a number of public IP addresses - one for each WAN link load balanced by the multi-homing device.
Static Proximity Database The Static Proximity Table is -defined. Each row in the table defines the farm that it applies to and a range of IP addresses. This range can include only one IP address or an entire IP address range. For the predefined range, you can list up to three IP addresses in order of priority. The priority defines which IP should server the client request. This is used when redirecting client in a Global solution, either in the DNS stage or later (HTTP, RTSP, etc.). Each server can be: •
IP of a Distributed AppDirector type server in the relevant farm
•
IP of a Remote Server type server in the relevant farm
•
VIP of a Layer 4 policy which is associated with the relevant farm
Notes: >> You need to enter the VIP that is associated with the farm in the static proximity so that the VIP is always associated with the farm. >> The number of proximity subnets is configurable per farm. The default number of entries is 500, but you can select any value between 1-5000. If you configure more entries than the available memory allows, AppDirector prints a message to the terminal and writes it to the log file. >> After setting the new values, the device must be rebooted. >> You can configure for a known range of clients, the three nearest sites that will provide the service. Only if all the configured sites are down or overloaded will the next most convenient site be selected to provide the service. You use the Static Proximity Table window to configure this feature. This window manages the ranges of static proximity redirections. You can configure ranges of IP addresses of clients for each farm address with a list of the three preferred sites for this range. If the range should be handled in the local site, the local site farm name should be entered.
Document ID: RDWR-AD-V021403-UG0211
301
AppDirector Guide Configuring Global Load Balancing For the predefined range, you can list up to three IP addresses in order of priority. The priority defines which IP should server the client request. This is used when redirecting client in a Global solution, either in the DNS stage or later (HTTP, RTSP, etc.). The Static Proximity window allows you to insert a new static client.
To define the static proximity parameters 1.
From the AppDirector menu, select Proximity > Static Proximity. The Static Proximity window appears.
2.
Click Create/Update. The Static Proximity Create/Update window appears.
3.
Set the parameters.
Parameter Farm Name
Description Name of the farm to which the entry is applied. Default: None
From Address
IP address of the first client IP in the range.
To Address
IP address of the last client IP in the range.
Server 1
• IP of a Distributed AppDirector type server in the relevant farm OR • IP of a Remote Server type server in the relevant farm OR • VIP of a Layer 4 policy which is associated with the relevant farm • Local Service: The first priority server that this range of clients will be redirected to.
Server 2
• IP of a Distributed AppDirector type server in the relevant farm OR • IP of a Remote Server type server in the relevant farm OR • VIP of a Layer 4 policy which is associated with the relevant farm • Local Service: The second priority server that this range of clients will be redirected to.
Server 3
• IP of a Distributed AppDirector type server in the relevant farm OR • IP of a Remote Server type server in the relevant farm OR • VIP of a Layer 4 policy which is associated with the relevant farm • Local Service: The third priority server that this range of clients will be redirected to.
4.
Click Set. The client is added to the list.
Default Redirection Default Redirection is applicable only for remote or distributed servers. When proximity is used and a client for whom no proximity settings are defined approaches AppDirector, a server is selected for that client based on load considerations only. When no proximity information is available for a client, Default Redirection enables you to define which servers to use and in which order of priority. The table below presents the parameters you need to set for each farm in which you want to employ Default Redirection.
302
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Configuring Global Load Balancing
To configure Default Redirection 1. From the AppDirector menu, select Distributed System > Default Redirection. The Default Redirection window appears. 2. Click Create. The Default Redirection Create window appears. 3. Set the parameters.
Parameter
Description
Farm Name
Name of farm to use Default Redirection.
Priority
Priority order in which servers are used, where 0 indicates the highest priority. Default: 0
Server Address
Default server IP address used when no proximity information available for client approaching this farm. Values: Remote or distributed servers configured for this farm. No default.
Server Port
Zero (0) if no application port has been specified.
Status
Enables or disables Default Redirection for the farm. Default: Enabled.
4. Click Set. Your configuration is set.
Configuring Local Report Protocol This section describes methods used to provide an AppDirector-Global device with load and availability information for other AppDirector sites to redirect traffic according to load and availability. The following topics are included: •
Introducing the Load Report Protocol (LRP), page 303
•
Local Load Report Protocol (Local LRP), page 309
Introducing the Load Report Protocol (LRP) AppDirector-Global can redirect traffic to distributed locations over the Internet, if the distributed site provides better service to the client (in of availability, load and proximity). These distributed sites can have a standalone server or a server farm managed by another AppDirector. AppDirector-Global needs information on the load and availability of these distributed sites to be able to make such decisions. When a distributed site is equipped with an AppDirector that manages a server farm, a proprietary inter-AppDirector protocol, called LRP (Load Report Protocol), is used by distributed AppDirectors to report the availability and load of their farms to other AppDirectors. LRP is a simple UDP-based protocol using UDP port 2090.
Note: An AppDirector running this version will be able to communicate via LRP only with AppDirector devices running version 2.14 or higher or devices running AppDirector 1.07 versions from 1.07.15 and higher.
Document ID: RDWR-AD-V021403-UG0211
303
AppDirector Guide Configuring Global Load Balancing For better clarity we are going to call the device which sends load reports for its farms the "Local AppDirector" and the device that receives the reports, the "Remote AppDirector”. A Local AppDirector can be either an AppDirector or an AppDirector-Global. A Remote AppDirector must always be an AppDirector-Global. If more then one global site is a primary site and makes redirection decisions, an AppDirector-Global device can function as both a Local and as a Remote device - it will send load reports to other primary sites and receive load reports from all other sites. The Local AppDirector reports the load of all of its farms that appear as distributed servers (Distributed AppDirector server type) in Remote AppDirectors. The frequency (in seconds) with which LRP reports are sent is configurable via the Load Report Interval parameter on a Local AppDirector. A Remote AppDirector can receive reports only for servers that appear in any of its farms as Distributed AppDirector servers. The time (in seconds) a Remote AppDirector waits to receive load reports from the Local AppDirector is configured via the Load Report Timeout parameter in the Remote AppDirector. After this timeout, the Remote AppDirector considers the Local AppDirector as non-responding and the status of the Distributed Server that represents this Local AppDirector farm in the Remote AppDirector farm is changed to Not In Service. The Local AppDirector must be configured with all the reports it needs to send to Remote AppDirectors. The Report Table is used for this purpose. A Load Report entry must be configured for each combination of a local farm that appears as a distributed server in other sites and a Remote AppDirector to which its load must be reported. For example, if the Local AppDirector has 3 farms that appear as distributed servers in 2 remote AppDirectors, 6 entries are to be configured in the Report Table. The configuration of a Report Table entry depends on the environment at the Local AppDirector site. The factors that influence it are: •
Whether the Global Triangulation method can be used to redirect traffic to this Local AppDirector farm.
•
Whether any NAT device is installed in front of the Local AppDirector device and/or Remote AppDirector device.
•
Whether any multi-homing NAT device (such as LinkProof) is installed in front of the Local AppDirector device
The following figure describes a configuration in which SF-Farm from San Francisco (Local AppDirector) appears as a distributed server in NY-Farm from New York (Remote AppDirector) meaning that the AppDirector in San Francisco (Local) must send reports to the AppDirector-Global in New York (Remote).
304
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Configuring Global Load Balancing
Figure 14: Load Reporting
To configure Load Report for Local AppDirector 1. From the AppDirector menu, select Distributed System > Report Configuration. The Load Report window appears. 2. Click Create. The Load Report Create window appears. 3. Set the parameters.
Document ID: RDWR-AD-V021403-UG0211
305
AppDirector Guide Configuring Global Load Balancing
Parameter
Description
Distributed Farm Name
Name of farm in the Remote device that includes the Local AppDirector farm as a distributed server - in the example above, NYFarm.
Distributed Server
Server address for the distributed server in the Remote AppDirector the value of this parameter depends on whether a NAT device is installed before the Local AppDirector. • No NAT device: Local AppDirector Layer 4 policy VIP that is connected to the farm whose load we are reporting - in the example above, 200.1.1.200. • NAT device: NAT address of the Local AppDirector Layer 4 policy VIP that is connected to the farm whose load we are reporting - in the example above, 250.1.1.200.
Farm Name
Name of the local farm whose load we are reporting - in the example above, SF-Farm. This is required if the Layer 4 policy configured for this entry points to a Layer 7 policy (otherwise it s automatically set to the farm name used in the Layer 4 policy). Note: If no farm name configured, no report is sent.
L4 Policy Name
Layer 4 policy configured in the Local device, that points to the farm whose load we are reporting - in the example above, SF-Policy.
Triangulation VIP
Virtual IP address for global triangulation on the Local AppDirector in the example above, 200.1.1.220. This parameter is relevant only when Global Triangulation is used.
Triangulation VIP NAT
Public IP address for Triangulation VIP, required only when Global Triangulation with NAT is used - in the example above 250.1.1.220.
Destination Address
IP interface of the Remote AppDirector device, or NAT IP for this interface, to which load and availability reports for local farms are sent - in the example above 100.1.1.10, or 163.1.1.10 if NAT device is present.
Redundant Destination IP interface of a backup Remote AppDirector device, or NAT IP for Address this interface. Health Monitoring ID
An identifier for this report that allows it to be associated with health monitoring checks, required only when a multi-homing device is installed in front of Local AppDirector. For more details see LRP in multi-homed environments.
Operation Status
Values: Active /Inactive. (Read Only) in Update mode.
Original VIP
Original VIP (on the Remote AppDirector) to which the client sent the request, required when Global Triangulation is used- in the example above 100.1.1.100, or 163.1.1.100 if NAT device is present. This is the address that the Local AppDirector device uses as source IP for triangulated traffic.
4.
Click Set. Your configuration is set.
5.
Adjust Load Report Interval and Load Report Timeout fields in the Global Configuration window, as described in the Global Configuration section.
306
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Configuring Global Load Balancing
LRP in Multi-Homed Environments When an AppDirector is installed behind a NAT device that load balances inbound and outbound traffic between multiple WAN links it means it operates in a multi-homed environment. The most obvious example of such a NAT device is Radware's LinkProof. In such an environment an AppDirector service (VIP) is accessible via a number of public IP addresses - one for each WAN link load balanced by the multi-homing device. When a Local AppDirector site is multi-homed, it affects the LRP in the following way: 1. The Local AppDirector must send multiple reports for each "local farm-Remote AppDirector" combination - one report for each WAN link managed by the multi-homing device. For example, if the site has 3 WAN links, 3 Report Table entries are configured for each "local farm-Remote AppDirector" combination. 2. The Remote AppDirector farm must also have multiple distributed servers representing the same Local AppDirector farm. In the above example, 3 distributed servers that represent Local AppDirector must be configured in the Remote AppDirector farm. 3. The Local AppDirector needs to split the actual load of the local farm between the multiple reports it sends to the same Remote AppDirector. In the above example, if the current load is 1500 s, each of the three reports Local AppDirector is sending will report 500 s. 4. The reports Local AppDirector is sending must also take into consideration the availability of the WAN links - if one of the WAN links is unavailable, Local AppDirector cannot send the relevant report for this entry. For the example in figure 2, if link A is down, Local AppDirector should not send a report for distributed server 250.1.1.200 - the Remote AppDirector will understand that this server is unavailable. To allow Local AppDirector to check WAN links availability and send LRP messages accordingly, health checks must be configured for each WAN link on Local AppDirector. The health check of each link must be bound to the respective Load Report entry. In the Health Monitoring Bind table (page ….) the Load Report entry is identified by its Health Monitoring ID field (a string identifier must be configured in this field when the Load Report entry is defined). To ensure that each health check configured on Local AppDirector will indeed check the required link there are two options: •
The destination IP of the health check is the internal interface of the access router for that link in this case LinkProof routes the health check request to the proper router.
•
The destination IP of the health check is an external address from the respective link provider (DNS server, etc). The address used for each health check must be different. The LinkProof must be configured to send each health check through the appropriate link by using traffic routing policies (grouping or flow policies according to LinkProof version) to ensure the correct WAN link is checked - for details please see LinkProof guide.
Example The following is an example of the configuration required on a Local AppDirector that is installed behind a LinkProof (Figure 2). Step 1. Configure the appropriate entries in the Report Table.
Parameter
Entry 1
Entry 2
Entry 3
Distributed Farm
NY-Farm
NY-Farm
NY-Farm
Distributed Server
250.1.1.200
192.1.1.200
176.1.1.200
L4 Policy
SF-Policy
SF-Policy
SF-Policy
Farm Name
SF-Farm
SF-Farm
SF-Farm
Document ID: RDWR-AD-V021403-UG0211
307
AppDirector Guide Configuring Global Load Balancing
Parameter
Entry 1
Entry 2
Entry 3
Triangulation VIP
200.1.1.220
200.1.1.220
200.1.1.220
Triangulation VIP NAT
250.1.1.220
192.1.1.220
176.1.1.220
Report Destination Address
100.1.1.10
100.1.1.10
100.1.1.10
Health Monitoring ID
SF-link1
SF-link2
SF-link3
Origin IP Address
100.1.1.100
100.1.1.100
100.1.1.100
Backup Report Destination Address
Step 2. Configure health checks for each WAN link. This example shows configuration of simple health checks, but a health check group can also be bound to a Load Report entry.
Health Check Name
WAN1
WAN2
WAN3
Method/Arguments
As required
As required
As required
Destination Host
250.1.1.11
192.1.1.31
176.1.1.53
Next Hop Router
200.1.1.10
200.1.1.10
200.1.1.10
Step 3. Bind each health check with the corresponding Load Report entry.
Health Check Name
WAN1
WAN2
WAN3
Server/NHR/Report
Report-SF-link1
Report-SF-link2
Report-SF-link3
308
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Configuring Global Load Balancing
Figure 15: LRP Multi-Homing example - Local AppDirector installed behind a LinkProof
Local Load Report Protocol (Local LRP) Large companies may have large networks, including multiple sites and broad internal networks. Handling these networks might require a layer of devices, consisting of global, local, or centralized AppDirectors. This is emphasized when security devices such as firewalls are connected in front of the internal LAN. Since firewalls usually perform NAT and policy management on internal clients, connecting one AppDirector on the external side of the firewall entails complicated IP management. Connecting one AppDirector on the internal side of the firewall does not solve the problem if there are global sites to be handled; the solution is a two-tiered AppDirector setup. Global AppDirectors handle traffic redirection between two sites, while Local AppDirectors handle local servers. From the Global AppDirector view, the farm of the Local AppDirector is a local server handling all traffic to the internal network.
Document ID: RDWR-AD-V021403-UG0211
309
AppDirector Guide Configuring Global Load Balancing The solution is to use LRP messages between the two AppDirector devices using the Local AppDirector server type. Traffic is forwarded to the Local AppDirector devices and not redirected, as in the global solution with Distributed AppDirectors. In a Global Triangulation scheme, the local AppDirector is configured as a farm of the Global AppDirector, causing the Global AppDirector to load balance traffic to the local AppDirector as if it was a regular server.
To configure Local LRP 1.
On the global AppDirector, define the local AppDirector as a local AppDirector server in the relevant farm's Remote Server Table.
2.
On the local AppDirector, define the relevant LRP reporting entries to accommodate the relationship between the global and local AppDirectors.
To configure AppDirector Local LRP 1.
From the AppDirector menu, select Global > Global Parameters. The Global Parameters window appears.
2.
Set the parameters.
Parameter
Description
Open New Entry When • Enable: Each session that a client opens, is recorded in the Client Source Port Different Table separately. • Disable (default): All client sessions are considered a single session, providing better performance. Select New Server When Source Port Different
• Enable: Different sessions opened by a client's application are served by different servers, according to the load balancing algorithms. • Disable (default) Note: This option provides a more accurate minimum- load balancing, but may hinder some applications that depend on the same server. It also may overload AppDirector`s internal tables. This option overrides the New Entry On Source Port option.
3.
310
Load Report Interval
Interval (in seconds) for sending dynamic updates of the local load to other AppDirector's devices that are served by this AppDirector. Also see Configuring Local Report Protocol, page 303.
Load Report Timeout
The time (in seconds) a Remote AppDirector waits to receive load reports from the Local AppDirector is configured via the Load Report Timeout parameter in the Remote AppDirector. Also see Configuring Local Report Protocol, page 303.
Click Set. Your configuration is set.
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Configuring Global Load Balancing
Domain Name System (DNS) This section discusses host names and persistency and contains the following topics: •
Host Names, page 311
•
DNS Server Parameters, page 315
•
Static DNS Persistency, page 317
•
DNS Statistics, page 319
The Domain Name System (DNS) allows Internet hosts to use names rather than IP addresses when accessing an Internet resource. DNS translates easy-to- names, such as www.radware.com, to IP addresses. When a instructs a Web browser to go to a URL such as www.radware.com, DNS equates that name with an IP address allowing the ’s machine to communicate through IP with the machine that hosts the website of www.radware.com. The DNS server consists of two main components: •
The resolver: Component responsible for asking a DNS question about the IP address, associated with the URL representing this address.
•
The name server: Component responsible for answering a DNS query. This is the agent present in DNS servers. When asked "What is the IP address of www.company.com?", the name server answers to the best of its ability.
All basic Internet hosts and T/IP stacks contain the resolver, while DNS servers contain both components: resolver and name server. The resolver is necessary if there is a question that the DNS server cannot answer. There are two kinds of DNS questions, or DNS "queries," that can be asked: •
Iterative: An iterative query CAN be answered with an absolute answer (IP address) or a referral.
•
Recursive: A recursive query MUST be answered with an absolute answer (IP address).
Client resolvers cannot handle referrals and therefore, can only ask recursive questions. Server resolvers, on the other hand, can handle referrals and can ask recursive or iterative questions. Although it is more common for server resolvers to make iterative queries, they may at times make recursive queries. When a name server is asked a recursive question, it must answer the question. If it does not know the answer, it finds it. When a name server is asked an iterative question, it answers the question to the best of its ability. If a name server knows the answer, the response is the requested IP address; if a name server does not know the answer, the response is a referral answer that includes the DNS and IP address of one or more name server(s) that may know the answer.In the DNS, the IP world is divided into domains. Each domain contains hosts. For example, a host known as www.radware.com is a host in the radware.com domain. Radware.com is a subdomain of the.com domain. Each domain in the Internet community has one or more “authoritative” name servers. An authoritative name server for a domain is responsible for all sub-domains and hosts within the domain or any of the sub-domains.
Host Names This DNS table is used to define the relationships between hostnames and farms. You configure the Host Names Table by defining the IP of the farm which handles the URL. You can define wildcard host names using the RegExp Host Name Table in addition to the definition of explicit URLs in the Host Names Table. This allows you to set a single definition for many similar URLs that are hosted on the same farm. When a DNS request arrives AppDirector first looks for an exact match in the Host Name Table. If such a match is not found, AppDirector looks for a match in the RegExp Host Name Table according to the configured order of entries. When no match is found, AppDirector discards the DNS request.
Document ID: RDWR-AD-V021403-UG0211
311
AppDirector Guide Configuring Global Load Balancing
To set/update the parameters of the Host Names Table 1.
From the AppDirector menu, select DNS > Host Names. The Host Names Table window appears.
Parameter
Description
Host Name
Verifies that the farm name is bound to a Layer 7 policy. (Read-Only Parameter for Update mode)
Farm Name
Farm that you want to include in this policy, for example, Main Farm. Default: None Notes: • When a host name entry is created, if the Layer 4 Policy defined for this host name entry has the Farm Name field configured (does not include a Layer 7 policy), that farm name is displayed in the host name entry Farm Name field by default. • System s need to configure the appropriate farm, whose availability the decision for host name DNS resolution is made. (Read-Only Parameter for Update mode)
Layer 4 Policy Name
Layer 4 Policy Name associated with Host Name entry provides information about the relevant farm, and Virtual IP to be used in reply. The farm is used to consider the servers’ load and can optionally use Remote Servers or Distributed AppDirector in the farm for the DNS resolution process. If the Layer 4 policy selected for host name entry is connected to a Layer 7 policy, then you need to select the appropriate farm in the Farm Name field. If no farm is selected, DNS queries to this host name will not be answered and the Farm Name from the Layer 4 Policy is automatically selected. Note: System s need to configure the appropriate farm, on whose availability the decision for DNS resolution of this host name is made.
External NAT Address Required when AppDirector is located behind a NAT device that NATs the VIP address for the host name. AppDirector must use External NAT Address in its DNS reply for DNS queries for host names.
312
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Configuring Global Load Balancing
Parameter Preferred Resolve IP
Description Chooses how to resolve for the best available IP. • 0.0.0.0 (default): Here the host name is resolved to the best available IP without taking Operation Mode into . • The VIP of the Layer 4 policy defined for this host name (default): Here the host name is resolved to the best available IP while taking Operation Mode into . If a local server in Regular Operation Mode is available and the Farm distribution threshold was not reached, the device answers with the Layer 4 policy VIP, if not it selects the IP of one of the remote and distributed server's IPs according to availability, load and proximity. • The IP of a Distributed AppDirector server or a Remote server in the farm attached to the Layer 4 policy defined for this host name. While the specified server is available, the host name is resolved to its IP.
DNS Action
This defines whether the DNS query for a host name should be resolved by AppDirector for globally load balancing applications or forwarded to the configured farm for DNS traffic load balancing. When set to Forward, this parameter enables AppDirector to provide Layer 7 farm selection for DNS traffic. (See Layer 7 Farm Selection for DNS, page 237). Values: Resolve, Forward.
2. When creating, in the Host Names Table window, click Create. The Host Names Table Create window appears, which contains the above parameters: 3. When updating, in the Host Names Table window, select the desired Host Name. The Host Names Table Update window appears. 4. Set the parameters. 5. Click Set. Your configuration is set.
To update the parameters of the RegExp Host Name Table 1. From the AppDirector menu select DNS > Host Names. The Host Names window appears. 2. Select the desired Host Name. The RegExp Host Names Update window appears. 3. Set the parameters.
Parameter
Description
RegExp Host Name
Displays the Regexp Host Name for the Farm table. Enter in the URL type. For example any URL that begins with the string “www.abc.”, followed by any text using letters and then followed by “.com” is resolved to the IP of the related farm or to the Layer 4 policy, when defined.
Index
Regular expression evaluation order. Default: 0
Document ID: RDWR-AD-V021403-UG0211
313
AppDirector Guide Configuring Global Load Balancing
Parameter
Description
Layer 4 Policy Name Layer 4 Policy Name associated with a Host Name entry provides information about the relevant farm, and Virtual IP to be used in reply. The farm is used to consider the servers’ load and can optionally use Remote Servers or Distributed AppDirector in the farm for the DNS resolution process. If the Layer 4 policy selected is connected to a Layer 7 policy, then you need to select the appropriate farm in the Farm Name field. If no farm is selected, DNS queries to this host name will not be answered and the Farm Name from the Layer 4 Policy is automatically selected. Note: System s need to configure the appropriate farm, whose availability the decision for host name DNS resolution is made. Farm Name
Farm that you want to include in this policy, for example, Main Farm. Default: None Notes: • When a host name entry is created, if the Layer 4 Policy defined for this has the Farm Name field configured (without a Layer 7 policy), that farm name is displayed in the host name entry Farm Name field by default. • System s need to configure the appropriate farm, whose availability is decided for host name DNS resolution. (Read-Only Parameter for Update mode)
External NAT Address
Required when AppDirector is located behind a NAT device that NATs the Virtual IP address for the host name. Here, AppDirector must use the External NAT Address in DNS reply for DNS queries for host names.
Preferred Resolve IP Chooses how to resolve for the best available IP. • 0.0.0.0 (default): The host name is resolved to the best available IP (either local VIP or VIP of a distributed site as part of local farm). The device selects a Non-Backup server local or distributed (if the farm reach the threshold), if there is no Non-Backup it will choose a Backup server but it will treat the Backup Distributed server as regular distributed server. • The Local VIP - The VIP of the Layer 4 policy defined for this host name. If a local server is available, the device answers with the Layer 4 policy VIP. If not, it selects the IP of one of the remote and distributed server's IPs according to availability, load and proximity. The device selects a Non-Backup server local or distributed (if the farm reach the threshold), if there is no Non-Backup it will choose a Backup server. • Remote VIP - IP of a Distributed AppDirector server or a Remote server (not recommended, but possible) in the farm attached to the Layer 4 policy defined for this host name. If the distributed server is active it will ALWAYS be chosen regardless of the other servers. DNS Action
This defines whether the DNS query for a host name should be resolved by AppDirector or forwarded to another DNS server. Values: Resolve, Forward.
4.
314
Click Set. Your configuration is set.
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Configuring Global Load Balancing
Notes: >> Host Name field in both tables (Host Name and RegExp Host Name Table) is case insensitive. >> Total number of entries in Host Name Table and RegExp Host Name Table is determined by the value of Host Names parameter in Tuning settings. >> A “.” In a regular expression means any single character, to indicate a “.”, a“\” must be used before the “.”.
DNS Server Parameters You can provide multiple a Virtual IP Interface address that can be backed up by the redundant device. If the main device fails, DNS requests are handled seamlessly and transparently by the redundant device.
To configure a Virtual IP Interface address to be backed up 1. From the AppDirector menu, select DNS > Server. The DNS Server Parameters window appears. 2. Set the parameters.
Parameter
Description
DNS Service
Enable or Disable (Default) the DNS service.
Two Records in DNS Enable or Disable (Default) return of two A records in the DNS response. Reply Enable returns two A records, disable returns one. 3. Click Set. Your configuration is set.
DNS Persistency AppDirector maintains persistency for consecutive DNS queries received from the same DNS client IP address. For example, if a DNS server honors the low TTL that the AppDirector assigned to DNS replies, it sends queries for the same farm every few seconds. If the client does not cache the replies, or caches them for a short period, consecutive connections for the same session may end up on two different sites. When AppDirector receives a DNS request for a host name, for example www.a.com, it first searches for the host name in the Host Name Table; and if the host name is not found, AppDirector searches the RegExp Host Name Table. Once an entry is matched, the relevant Layer 4 Policy that serves this host name is determined. If DNS Persistency is configured for this Layer 4 Policy, AppDirector searches the static and dynamic tables to determine the IP address used in the DNS reply. When AppDirector devices are used in multiple sites to provide a global solution, Hashing can be used to provide consistent DNS replies from different AppDirector devices to the same DNS client IP. DNS Persistency can be configured for each farm using: •
DNS Persistency: When AppDirector answers a DNS request, it creates an entry in the DNS Persistency Table, indicating the requester's IP address and the VIP that was sent as a response. AppDirector provides the same reply to that requester as long as there is a record in the table.
•
Static DNS Persistency: You can statically set VIPs to be used for a range of DNS IP addresses.
Document ID: RDWR-AD-V021403-UG0211
315
AppDirector Guide Configuring Global Load Balancing You can tune the DNS Persistency and Static DNS Persistency Tables.
Note: When using redundant AppDirector devices, mirroring can be used for the DNS Persistency Table. Similar to other mirrored tables, you can enable or disable DNS Persistency Table Mirroring, and set the Update Time and Mirroring Percentage (see Stateful Failover (Mirroring), page 140).
Working with DNS Persistency DNS Persistency can be maintained using load balancing or Hashing. When DNS Persistency is maintained using load balancing, AppDirector dynamically selects the VIP to be used for the DNS reply based on load and proximity information. Subsequent requests from the same IP are replied to using the same VIP. You can also set Static DNS Persistency. Each range of DNS client IPs can be associated with a predefined VIP (see Static DNS Persistency, page 317).
Use of Hashing in the Global DNS Persistency Solution In the global DNS Persistency solution, ensure that multiple AppDirector devices located at different sites use the same DNS reply for the same client IP. Then, DNS Persistency is maintained using the Hash function. To select the VIP for the DNS reply, AppDirector uses Hash on the DNS client IP address. You need to consider the following when using Hash for Global DNS Persistency: •
AppDirector devices must be configured so that the same VIPs are available for DNS replies.
•
When Hash is used for DNS Persistency, server weights are taken into . To ensure that different AppDirectors choose the same server, you must set servers with the same respective weights.
•
If the VIP selected by Hashing is not available, AppDirector selects the next available VIP. This behavior is consistent among different AppDirectors.
•
Entries in the DNS table should be created ONLY if the selected by the hash VIP option is NOT available at the moment and because of that a different VIP must be selected.
•
When Hashing is used for DNS Persistency, load and proximity information are not used in the DNS reply process.
•
When Hashing is used for DNS Persistency, Capacity Threshold and Distribution Threshold are ignored.
DNS Grouping Mask DNS Persistency can be maintained for groups of DNS client IP addresses, both when using Load Balancing or Hash. For example, when the DNS Grouping Mask is set to 255.255.255.0, the same DNS replies are sent to IP address 1.1.1.1 and 1.1.1.66.
To define DNS persistency 1.
From the AppDirector menu, select Farms > DNS Persistency Parameters. The DNS Persistency Parameters Table window appears.
2.
Select the farm where you want to define DNS persistency. The DNS Persistency Parameters Table Update window appears.
316
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Configuring Global Load Balancing 3. Set the parameters.
Parameter
Description
Farm Name
Name of the farm for which DNS persistency is used. (Read Only)
Status
• Disabled (Default): Disables DNS Persistency. • Enabled: Enables DNS Persistency.
Mode
AppDirector selects VIP used in DNS replies for the farm using these modes: • Load Balancing (Default): Load Balancing algorithms are used, considering load and proximity information. • Hash: Hash on client IP address. This can be used when AppDirector devices are in a multiple site and global DNS persistency is required.
Static Mode
• Disabled (Default): Disables Static DNS Persistency. • Enabled: Enables Static DNS Persistency.
Aging Mode
Entries in DNS Persistency Table can be aged based on these modes: • Fixed: Entry is removed from the table after the period of time defined by the Aging Time parameter. • Inactivity (Default): Entry is removed from table if during the period defined by the Aging Time parameter no additional DNS queries are received from the same DNS client IP address.
Aging Time
Defines how many seconds an entry remains in DNS Persistency Table. Values: 1 - 4,234,967,295 seconds (136 years). Default: 60 seconds
Grouping Mask
Defines mask for a group of DNS client IP addresses. Default: 255.255.255.255 (persistency is maintained for single client IP addresses).
4. Click Set. The DNS Persistency Parameters Table Update window closes.
Aging Mode Entries in the DNS Persistency Table can be aged by the Fixed or Inactivity modes. When Fixed mode is used, the entry is removed from the table after the period of time defined by the Aging Time parameter. When Inactivity mode is used, the entry is removed from the table if no additional DNS queries are received from the same DNS client IP address during the period defined by the Aging Time parameter.
Static DNS Persistency Static DNS Persistency operates at the farm level based on Client IP Range. This means that requests from client IP addresses in the same range to different hostnames that are mapped to the same farm are replied using the same VIP. This VIP is called Preferred VIP and can be defined using the Static DNS Persistency table. You can also set an Alternate VIP to be used when the Preferred VIP is not available or overloaded. When the Preferred VIP is not available and the Alternate VIP is set to Any, then AppDirector dynamically selects the VIP for the DNS reply.
Note: To use static DNS, you need to first set the tuning on the device.
Document ID: RDWR-AD-V021403-UG0211
317
AppDirector Guide Configuring Global Load Balancing
To define static DNS persistency 1.
From the AppDirector menu, select DNS > Persistency Table. The Static DNS Persistency Table window appears.
2.
Click Create. The Static DNS Persistency Table Create window appears.
Note: Before adding entries to the Static DNS Persistency table, you must enable DNS Persistency and Static DNS Persistency. 3.
Set the parameters.
Parameter
Description
Farm Name
Select the name to describe the AppDirector farm.
From Client IP Address First IP address in client IP range for static DNS resolution. To Client IP Address
Last IP address in client IP range for static DNS resolution.
Preferred VIP
IP address to be used for DNS replies for host names managed by this farm. This address is usually set to the Virtual IP address associated to Layer 4 Policy, or one of that farm's servers, of type Remote Server, Distributed Server, or Local Farm. Note: AppDirector uses this IP address only if the corresponding farm server is available.
Alternate VIP
Alternate VIP can be set to one of the following values: • None (default): AppDirector does not reply to DNS query if the preferred server is not available. • Any: When the preferred server is not available, AppDirector selects a VIP according to the configuration of the DNS Persistency Mode parameter using Load Balancing algorithm or using Hash. Note: AppDirector uses the IP address configured as Alternate VIP for DNS replies only when the corresponding farm or server is available.
4.
318
Click Set. The DNS Persistency Parameters Table Update window closes and the new parameters appear in the DNS Persistency Parameters Table window.
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Configuring Global Load Balancing
DNS Statistics You can generate statistics regarding DNS requests.
To view the DNS Statistics From the AppDirector menu, select DNS > Statistics. The DNS Statistics window appears, which contains the following read-only statistics:
Parameter
Description
DNS Requests Last Second
Number of DNS requests in the last second. Default: 0
DNS Replies Last Second
Number of DNS replies in the last second. Default: 0
Failed DNS Requests Last Second
Number of DNS failed requests in the last second. Default: 0
Redirection This section describes methods used to redirect traffic in the global traffic management solution and includes the following topics: •
DNS Redirection, page 320
•
HTTP Redirection, page 320
•
HTTP to HTTPS Protocol Redirection, page 321
•
RTSP Redirection, page 323
•
SIP Redirection, page 323
•
Proxy Redirection, page 323
•
Global Triangulation Redirection, page 324
•
Setting Redirection Parameters, page 326
•
Anycast , page 328
When using the global traffic management solution, several Redirection methods can help to define how service requests are redirected. When a client sends a new request for service, AppDirector selects the best available server. If the required server is at the local site, AppDirector forwards the service request to that server. If the required server is at a remote site, AppDirector redirects the service request using one of the methods. Multiple redirection modes can be enabled per farm. Exceptions include Global Triangulation and Proxy (Client NAT) which cannot be enabled simultaneously. When an application-specific redirection process (HTTP, RTSP, SIP) and a Global Triangulation or Proxy mode are enabled in a farm, traffic belonging to an application for which a specific redirection mode is enabled (HTTP, RTSP or SIP) is redirected accordingly, while other applications are redirected using the Triangulation or Proxy methods.
Document ID: RDWR-AD-V021403-UG0211
319
AppDirector Guide Configuring Global Load Balancing
DNS Redirection The DNS Redirection method is based on the DNS process (see DNS Persistency, page 315). When a client sends a DNS query to find the IP address of the host name of the requested service, AppDirector operates as a DNS server. When a DNS query is made, AppDirector responds with the IP address of the best site for the client. If the local AppDirector decides that the current site is best suited for handling the client, it sends the query to its own VIP address. Otherwise, AppDirector resolves the DNS query using the IP address of a remote farm or server. Redirection is only performed during the DNS query/answer stage. Therefore, if DNS Redirection is enabled on a farm, any packet destined to the Virtual IP address is handled by the local servers of this farm. The DNS Redirection process involves the following steps: 1.
The DNS request reaches the AppDirector-Global physical IP Interface or Virtual IP Interface from a DNS server. The request is to resolve a host name to an IP address.
2.
No search of the Client Table is made. AppDirector-Global searches the Static Proximity Table for a range fitting the asking DNS server. If a match is made, the top priority server from the active AND not overloaded servers is selected. AppDirector-Global resolves the name to the IP address of the chosen server, which can be a local Layer 4 VIP or a VIP configured on a remote AppDirector.
3.
If there is no match in the Static Proximity Table, the Dynamic Proximity Table is searched. If there is a match, AppDirector-Global resolves the request to the Layer 4 VIP address of the highest priority site (currently active and not overloaded), ing for the hops weight, latency weight, and the load weight variables.
4.
If there is no match, AppDirector-Global resolves the request to the IP address of the least loaded site, while calculating proximity information for the querying DNS server (if proximity is enabled). Then AppDirector-Global sends PRP requests to other AppDirectors to do the same.
5.
AppDirector-Global resolves the query to the IP address of the least loaded site.
Notes: >> DNS answers are made with a DNS TTL of 0,(default) to reduce Internet caching and to keep the system dynamic. >> You can set DNS TTL to a higher value and you can set different DNS TTL values for different farms. Using AppDirector-Global, DNS Redirection works best if DNS servers from all over the Internet make queries to AppDirector-Global. If the DNS servers local to AppDirector-Global or responsible for the “super-domain” make queries to AppDirector-Global, their proximity calculations result in inaccurate data. AppDirector-Global allows you to configure up to two DNS servers with requests that are resolved to the least loaded site; no proximity calculations are made if a request comes from either of these two DNS servers.
HTTP Redirection The HTTP redirection method is used to redirect the HTTP traffic as follows: 1.
The client sends the GET request using the HTTP protocol to a VIP address of AppDirector.
2.
AppDirector receives the request and selects the best server for the task.
3.
If AppDirector decides that a distributed site or remote server is the most appropriate, then it issues an HTTP redirect to the indicating that the has been redirected. Here, AppDirector replies to the HTTP request using an HTTP code redirection code (Moved Temporarily or Moved Permanently) and redirects the client to the relevant server.
320
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Configuring Global Load Balancing HTTP redirection can be done by IP address or by name. HTTP redirection by IP redirects the request for service to the IP of the remote server or the VIP of the Distributed AppDirector. When using HTTP redirection by name, AppDirector redirects the client to another URL. The URL used for redirection is configured using the Redirect To URL parameter in the server to which redirection is performed.
Note: When redirect by name is enabled and the redirect to URL field is empty, AppDirector uses server name for redirection.
HTTP to HTTPS Protocol Redirection HTTP to HTTPS protocol redirection is based on the location field in HTTP headers where AppDirector handles SSL for backend servers, and the backend server performs a redirect using HTTP headers specifying URL with HTTP:// instead of HTTPS://. AppDirector can redirect HTTP traffic to HTTPS. Using this method, you can configure AppDirector to redirect clients to secure access to the site. You can set AppDirector to indicate to a client to access the site using HTTPS rather than HTTP when redirecting a client using HTTP redirection.
HTTP Persistency in Global Environment In order to ensure transaction stickiness at all times in a global environment it is recommended to use the Insert cookie capability, together with HTTP Redirection, for all farms involved. AppDirector can identify the cookie used by client belongs to a different site (was inserted at the beginning of the transaction by an AppDirector at that site) and employ HTTP redirection to transfer the new request to the original site. To maintain site and server persistency in a global environment: •
HTTP redirection must be by name
•
Hostnames for all sites must belong to the same domain (for example www.a.com for the main service, www.site1.a.com for site 1 and www.site2.a.com for site 2)
•
Ensure that the automatically generated Set-Cookie method uses the same cookie key in all sites. This can be achieved either by using the same Farm Name in all sites, or by editing the automatically generated cookie key.
•
Set the domain value of the automatically generated Set-Cookie method to the service domain (in the example above a.com)
When AppDirector performs SSL for Back End servers the servers receives the requests in HTTP (clear), therefore, when servers perform redirect to another page/site (using HTTP headers in response with location field), it can now also use HTTP. If the clients receive this header they will initiate the new connection over HTTP instead of over HTTPS and is dropped. Therefore the AppDirector, that sends the response back to the clients must change the server's redirection location URL appearing in the HTTP header from HTTP:// to HTTPS://. This modifies the location header of any HTTP header in server's responses from HTTP:// to HTTPS:/ /, and the target port. The modification is performed where the host name in the client's request matches the host name in the server's response, or where matching criteria are met. Matching criteria can consist of one Regex that represent hostnames.
Document ID: RDWR-AD-V021403-UG0211
321
AppDirector Guide Configuring Global Load Balancing
Notes: >> For HTTPS redirection - if the Layer 4 policy port is different than port 443, the Layer 4 policy port is appended after a colon to the URL. >> For HTTP redirection - If the Layer 4 policy port is different than port 80, the Layer 4 policy port is appended after a colon to the URL >> When Backend SSL is working, you do not need to use HTTP to HTTPS protocol redirection and you cannot configure them together.
Protocol Redirection If a requests the www.ab.com/base_redirect.html page, the page is redirected to www.bb.com/ Redirect/Path/redirect_page.html. If the redirect was from ab.com to ab.com/some-other-path, no regular expression is needed since this is the same host. In this example, the redirect was from ab.com to bb.com and this works only when the regular expression matches the host (the new host). Thus, when the regular expression is www.ab.com, it does not match bb.com (which is the real location of the page). The redirection works as follows: •
AppDirector changes http to https for the following regular expressions:
"www.bb.com" "www.b*.com" "/*" "bb.com" "bb" "www" ".com" "." ".c" "bb.com/Redirect/" "www.bb.com/Redirect/Path/redirect_page.html" "/" •
AppDirector does not change to https for the following regular expressions:
"www.ab.com" "www.bb.com/blabla" "" " " "ab.com"
322
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Configuring Global Load Balancing
RTSP Redirection Real Time Streaming Protocol (RTSP) is used for audio/video streaming applications such as news broadcasts, radio stations and live shows over the Internet. Using RTSP redirection, AppDirector can redirect RTSP sessions to a remote site. AppDirector forwards a RTSP request to a remote server or AppDirector. During the redirection, AppDirector responds with a standard RTSP redirection message causing the client sending the request to establish a new connection to a remote site to view/hear the streaming information. RTSP redirection is used for requests to T port 554 and is enabled by the RTSP Redirection. The RTSP redirection and the HTTP redirection methods work similarly. The RTSP redirection process involves the following steps: 1. The client uses the RTSP protocol to send the Options, Describe, or Setup (request for a file) commands to the VIP address of AppDirector. 2. AppDirector receives the request for service and selects the best server. 3. If AppDirector decides that a distributed site, rather than a local server, is the most appropriate, then AppDirector issues a RTSP redirect to the , redirecting the to one of the distributed sites. RTSP redirection can be done by an IP address or by name. The name is taken from the Redirect To URL parameter of the server. If the Redirect To URL parameter is not configured, the Server Name is used instead (see HTTP Redirection, page 320). RTSP redirection can be used globally, redirecting clients to remote farms or servers, or locally, using Redirect to Self (see Using Redirect to Self in Multi-Homed Environments, page 396).
Note: RTSP redirection preserves the client-server persistency of RTSP sessions when the Client Table mode Select Server When Source Port is Different is used.
SIP Redirection The Session Initiation Protocol (SIP) is an IETF standard for a signaling protocol used for establishing sessions between two or more end s. The SIP redirection method is used to redirect SIP session invitations to external domains, such as a distributed or remote server. The SIP redirection process involves the following steps: 1. The client sends the SIP request to an AppDirector’s VIP address. 2. AppDirector receives the request and selects the best server for the task. 3. AppDirector chooses the distributed site or remote server, replies to the SIP request using the SIP code 302 (Moved Temporarily) and redirects the client to the relevant server. 4. SIP redirection can be done by an IP address or by name. SIP redirection by an IP address redirects the request for service to the IP of the remote server or the Distributed AppDirector’s VIP. When using SIP redirection by name, AppDirector redirects the client to another URL. 5. SIP redirection by name is configured using the Redirect To URL parameter for the server.
Proxy Redirection This method uses Client NAT to redirect traffic. AppDirector acts as a proxy at the IP level, retrieving content and then responding to the . Before selecting this method, the Client NAT must be enabled on the device and the Client NAT range must be configured for the farm. When traffic is forwarded to another site, AppDirector replaces the original Source IP of the request with a predefined NAT IP address and dynamically selected ports. Client NAT enables AppDirector to hide the IP addresses of clients when forwarding traffic to servers in farms. Using Proxy redirection, the
Document ID: RDWR-AD-V021403-UG0211
323
AppDirector Guide Configuring Global Load Balancing server does not see the original client IP address. In certain applications, the application server needs to know the client’s identity and therefore AppDirector has a service entry point where the client can insert the X-Forwarded-For Header in the traffic it redirects.
Global Triangulation Redirection To handle the distribution of IP protocols (e.g.T or UDP), and when other redirection methods cannot be used, use Global Triangulation redirection. The following figure illustrates an example where a needs to receive FTP services from ftp.company.com and approaches the main AppDirector’s VIP. If the main AppDirector has reached its Distribution Threshold and decides to send this to a Remote AppDirector, a simple delivery of the ’s packets to the Remote AppDirector’s VIP will not succeed. Since the attempted to open the FTP session with main AppDirector, if the reply comes from Remote AppDirector, the session fails. For a successful FTP session, the reply to the must be sent using the main AppDirector VIP as the Source IP address.
Notes: >> You cannot use Global Triangulation when any Acceleration Engine related capability (i.e. SSL, Cache, Compression, and Authentication) is used. >> The Triangulation redirection method is not applicable in a global solution configuration that uses remote servers.
main AppDirector main VIP
Triangulation VIP Address
Remote AppDirector Remote VIP
To overcome this issue, AppDirector utilizes a process called VIP Mapping, which is used at the receiving AppDirector’s end (in this example, Remote AppDirector). The process consists of the mapping of three parameters:
Parameter
Description
Distributed Server
VIP address of the Remote AppDirector. The Remote VIP address is configured as a distributed server in the farm on the main AppDirector.
Triangulation VIP Address
Virtual address on the Remote AppDirector associated with the main AppDirector farm. This indicates that Remote AppDirector must send the reply to the using the main AppDirector VIP as the source address.
Origin VIP Address
VIP address of the main AppDirector farm that directed the to this AppDirector. The Origin VIP Address in the example is the virtual address of the main VIP.
324
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Configuring Global Load Balancing This mapping is achieved via the LRP mechanism. When Remote AppDirector receives packets destined for the Triangulation VIP address, it selects a server in the relevant farm and forwards the request to it. The difference is that for the reply from the server to the , Remote AppDirector replaces the source address of the packet with the Origin VIP Address, in this example, the main VIP. This way, the receives replies from the same address with which it tried to open the IP session.
Notes: >> Global Triangulation does not work with persistent Layer 7 switching. >> Layer 7 with Global Triangulation assumes all sites have the same configuration. >> In Layer 7 with Global Triangulation, the main device sends the request to the distributed site with no T handshake, just the GET. The Global Triangulation redirection process involves the following stages: 1. sends a new service request to VIP of main AppDirector (main VIP). 2. Main AppDirector receives the request for service and selects the best server for the task in the relevant farm. 3. Main AppDirector decides to send the to a distributed site. The request for service is sent using the Triangulation VIP address associated with the Remote AppDirector VIP. 4. Remote AppDirector sends the packet to one of its local servers. The reply to the is sent using the Origin VIP Address as the source address.
Main VIP
Triangulation VIP Address
IP
IP
Main VIP
AppDirector uses Layer 4 Policies internally to manage Triangulation VIP addresses for Global Triangulation. The Triangulation VIP addresses are defined in the Distributed Sites table. AppDirector automatically creates, updates, and deletes the corresponding Layer 4 entries. These entries appear in Layer 4 Policies. They are: •
Layer 4 Policy Name parameters is Auto_Triangulation.
•
Policy Defined By parameter is System, for internally managed Layer 4 Policies.
Document ID: RDWR-AD-V021403-UG0211
325
AppDirector Guide Configuring Global Load Balancing
Extended LRP Security When the Triangulation redirection method is used (see Global Triangulation Redirection, page 324), the Triangulation VIP address must be on the same subnet as the Virtual IP address, for security reasons. To ensure that the Triangulation VIP address configured for a farm is on the same subnet as that farm, the Extended LRP Security option must be enabled.
Note: The Triangulation VIP address and the Layer 4 Virtual IP address cannot be configured on different subnets when Extended LRP Security is enabled. Extended LRP Security is defined globally for each AppDirector and enabled by default. To place them on different subnets, you must disable this option.
Setting Redirection Parameters When using the global traffic management solution, several Redirection methods are available to define how service requests are redirected to their required destinations. When a client sends a new request for service, AppDirector selects the best available server for the task. If the required server is placed at the local site, AppDirector forwards the request for service to that server. If the required server is located at the remote site, AppDirector redirects the request for service using one of the redirection methods. The redirection methods are configured at farm level. Multiple redirection methods can be configured for each farm.
To set Redirection Parameters 1.
From the AppDirector menu, select Farms > Redirection. The Redirection Table window appears.
2.
Select the farm where you want to define redirection. The Redirection Table Update window appears
3.
Set the parameters.
Parameter
Description
Farm Name
Name of farm for which redirection is configured. Read-only parameter.
DNS Redirection
Enables the DNS redirection method. Based on the DNS mechanism. When a client sends a DNS query to find an IP address of requested service host name, AppDirector operates as a DNS server.
DNS Response TLL
Number of seconds in which DNS responses are cached. Default: 0
HTTP Redirection
Enables HTTP redirection method and is used to redirect HTTP traffic. Values: • 302 Moved Temporarily • Disabled (default) • Moved Permanently • RFC Moved Temporarily
326
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Configuring Global Load Balancing
Parameter Redirect To HTTPS
Description Enables the HTTPS redirection method. Values: • Disabled • Enabled (default)- both HTTP and HTTPS traffic that arrives at this farm will be redirected to HTTPS, in case redirection is necessary. • HTTPS only - only HTTPS is redirected (HTTP is not redirected to HTTPS).
RTSP Redirection
Enables the RTSP redirection method where AppDirector can redirect RTSP sessions to a remote site. Default: Disabled
SIP Redirection
Enables the SIP redirection method. Default: Disabled AppDirector can redirect Session Initiation Protocol (SIP) sessions (UDP) using the redirection option (302) within the SIP protocol.
Global Triangulation
Enables the Global Triangulation method. Default: Disabled Global Triangulation uses a Radware proprietary scheme to redirect traffic to a remote AppDirector.
Proxy Redirection (Client NAT)
Enables the Proxy redirection method. Default: Disabled This method uses Client NAT to redirect traffic to another server or site. When selected, the Client NAT ranges must also be configured.
Redirect By Name
Server's Redirect To parameter is used as the host name to which redirect is performed (for HTTP/HTTPS/RTSP/SIP). Or you can use the server IP.
Farm Distribution Threshold
Local load balancing is performed between local servers until the farm reaches the Distribution Threshold limit. Then the distribution algorithm allows AppDirector to redirect s to other servers. Default: 2,500
Farm Capacity Threshold
Maximum number of connections that farm's local servers may accept. When this threshold is reached, LRP reports from the farm inform you that no more redirects can be accepted from distributed AppDirectors. Default: 5,000
Static Proximity Entries
Number of entries in Static Proximity Table. If you configure more entries than memory allows, AppDirector prints a message to the terminal and writes it to the log file. defined Static Proximity table displays proximity subnets per farm. Each table row displays the accompanying farm and a range of IP addresses. Values: 1 - 5000 Default: 500
Document ID: RDWR-AD-V021403-UG0211
327
AppDirector Guide Configuring Global Load Balancing
Parameter
Description
Application Redirection Mode
Defines whether DNS redirection is: • only redirection method for this farm • primary method: backup redirection methods can be configured where the application request (after DNS resolution) reaches a site where there are no servers available • one of the farm redirection methods. The following values are available: • Disabled (Default): Farm can only use DNS redirection. • Enabled: Application redirection is performed using redirection methods enabled for this farm. • DNS Fallback Redirection: Application redirection is used only if DNS Redirection is enabled and availability problems exist. The method used depends on methods enabled for this farm.
4.
Click Set. The Redirection Table Update window closes and the new parameters appear in the Redirection Table window.
Anycast Anycast is the process that allows a single IP address to be announced from multiple locations. It’s a simulation of a situation where a routing domain may have multiple routes that lead to a certain destination. Such an application is useful if a service is required globally, and there are multiple service points that should be totally transparent to the . Once a packet has the Anycast address as a destination, the routing domain will control the flow of that packet towards one of the destinations. A global system may use the Anycast to announce multiple service points. There are two types of Anycast service: •
Global Anycast: The global Anycast addresses are equally announced from multiple locations allowing s to connect to these points concurrently. The routing logic creates the load distribution between the different service points. This type of Anycast is suitable for stateless applications only, such as DNS. This type of Anycast can be used to select the DNS resolver in a global solution.
•
Local Anycast: The local Anycast addresses are not concurrently active in more than a single primary site. Secondary sites use these addresses only to provide a transparent backup to the primary site. For the routing logic there should be a single location that serves each IP address. This type of Anycast is suitable for all protocols – as long as the primary site is active persistency is maintained.
To create an entry in the Anycast Table 1.
From the AppDirector menu, select Distributed System > Anycast Table. The Anycast Table window appears.
2.
Click Create. The Anycast Table Create window appears.
328
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Configuring Global Load Balancing 3. Set the parameters
Parameter
Description
Layer 4 Policy Name
Name that provides AppDirector with information on the IP that must be d (Layer 4 Policy VIP). The value that appears in this field depends on the type of the Layer 4 policy, whether this is a Virtual IP Interface (VIPI) or not and if not what is the farm on whose status the ment depends: Note: The ment does not depend on farm status (it depends on device status up/down)
Host Route Metric
VIP ment via Dynamic Routing is used to a Farm's VIP or any other configured IP address via RIP or OSPF. You can configure the route metric to be used when adding the route to the routing table. This can be used when two devices are used on different sites for site redundancy. When the main site is available, the device adds the VIP to the routing table with the configured metric, then removes the entry from the routing table when the servers are unavailable. When the farms in both sites are available, clients are routed to the selected device based on the route metric. Enter the required metric value. Default: 1
d VIP Farm Name
Name of farm on whose availability this ment is made. Layer 4 Policy VIP is only d if this farm is available. If Layer 4 policy Application is set to Virtual IP Interface, this field is obsolete. Default: None
External NAT IP
If AppDirector is installed behind a NAT device, the d IP must be not the VIP, but rather its public (NAT) address. When a NAT address is defined in the relevant entry, AppDirector responds with the External NAT IP Address.
4. Click Set. Your configuration is set.
Document ID: RDWR-AD-V021403-UG0211
329
AppDirector Guide Configuring Global Load Balancing
330
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Configuring Health Monitoring
Chapter 5 – Configuring Health Monitoring This chapter describes the Health Monitoring module, a component of the Radware APSolute OS architecture and includes the following sections: •
Health Checks, page 332
•
AppDirector Farm Connectivity Checks, page 353
The Health Monitoring module implemented on Radware IAS (Intelligent Application Switching) products is responsible for checking the health of network elements like servers, firewalls, and Next Hop Routers (NHRs) that are managed by the IAS device. It determines which network elements are available for service, enabling 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 other resources on the data path. The module provides flexible configuration for health monitoring of the load-balanced elements. The module s various predefined and defined checks, and enables the creation of dependencies between Health Checks of different elements. The Health Monitoring module enables s to track the round-trip time of Health Checks. The device keeps a Response Level indicator for each check. The Response Level is the average ratio between the response time and the configured Timeout. The average is calculated based on the number of samples defined in the Response Level Samples parameters in the Global window. Setting the Response Level Samples to 0 disables the parameters; any other value between 1-9 defines the number of samples.
Checked Element A Checked Element is a network element that is managed and load balanced by the Radware device. For example, AppDirector-checked elements include the Farm Servers, NHRs, and LRP and PRP reports. 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 AppDirector may depend on the health of a database server, or other application servers, which are not load balanced by the AppDirector, or the health of a Next Hop Router managed by LinkProof may depend on the availability of the service provider.
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 T/UDP port to which the test is sent, the time interval for the test, its timeout, the number of retries, and more. These parameters are explained in detail in the Health Checks section. A network element can be tested using one or more Health Checks.
Health Monitoring Global Parameters The Health Monitoring module enables extensive health monitoring of all network devices, for example, server farms. The module enables the device to optimize load balancing by making sure which network elements are available and active. The Health Monitoring menu's Global Parameters window allows you to configure the Health Monitoring mode.
Document ID: RDWR-AD-V021403-UG0211
331
AppDirector Guide Configuring Health Monitoring
To configure Health Monitoring Global Parameters 1.
From the Health Monitoring menu select Global Parameters. The Health Monitoring Global Parameters window appears.
2.
Set the parameters.
Parameter
Description
Health Monitoring
Determines whether to use the Health Monitoring module or the device's connectivity checks. Default: Disabled
Response Level Samples
Number of Response Level samples serving as basis for calculating average Response Level. The device keeps a Response Level indicator for each check. This is the average ratio between response time and configured Timeout. Default: 0 Notes: • A value of 0 disables this parameter and no sample is taken. • Any other value between 1 - 9 defines the number of samples.
SSL Certificate Entry Name
This is used by the device when the Web server requires a client certificate during the SSL handshake. Default: Client certificate generated by the device.
3.
Click Set. Your configuration is set.
Note: SSL certificate file and SSL private keys are not exported as part of the device configuration export.
Health Checks This section discusses Health Checks and contains the following topics: •
Group Health Checks, page 333
•
Single Health Checks, page 333
•
Health Checks Per Farm, page 333
•
Binding, page 347
•
Packet Sequence Table, page 348
•
Server Table, page 349
•
Diameter Argument List and Additional Method Arguments, page 350
•
ing, ing and Deleting the Diameter File using Binary File Transfer, page 352
•
Defined Methods, page 352
You can add or edit health check parameters in the Check Table. The Check 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 (SNMP Traps, Syslog messages or mail messages), indicating the failure of the check.
332
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Configuring Health Monitoring
Quantity of Health Checks There is no radware recommended number of heath checks as this depends on many variables. For example: •
Frequency of checks (interval)
•
Timeout for each check
•
Load on the device (without Health Monitoring running)
•
Other generic applications configured to run
For example, having 5000 checks with a large interval of two days could perform better than 200 checks with in interval of 2 seconds.
Group Health Checks Using group health checks 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 uses one of two routers to provide service. This Web server is bound using three different binding groups: one group contains Health Checks for the two routers (each check is NonMandatory), another group contains Health Checks for the database servers (each check is NonMandatory), and the third group contains the Health Checks for the Web server. As long as one of the database servers and one of the routers is active, and the Web server Health Check es, the Web server is considered active. Otherwise, the Health Monitoring module determines that the Web server is unable to provide the required service. You can also configure groups of health checks. Health Check Binding can also be grouped for complex conditioning of tests, using the logical conditions AND/OR.
Single Health Checks You can add or edit health check parameters in the Check Table. The Check Table lists the configured Health Checks.
Health Checks Per Farm 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. Health Check Binding can also be grouped for complex conditioning of tests, using the logical conditions AND/OR.
Health Monitoring Check Table The Checks Table window contains -configurable checks, based on the Health Check Methods.
To create/update an entry in the Checks Table: 1. From the Health Monitoring menu select Checks Table. The Health Monitoring Check Table window appears. 2. Click Create/Update. The Checks Table Create/Update window appears. 3. Set the parameters.
Parameter
Description
Check Name
defined name of health check.
Check Method (pre-defined methods used to configure a health check)
Document ID: RDWR-AD-V021403-UG0211
333
AppDirector Guide Configuring Health Monitoring
Parameter
Description
ARP
A reading of the unit ARP cache for the 2 most recently acquired entries. One at a time, the device sends ARP requests to these machines, attempting to stimulate network traffic. After each request, the device counts all received traffic for up to 5 seconds. If traffic is received, the interface is considered operational. If no traffic is received, an ARP request is sent to the next machine. If at the end of the list, no traffic has been received, the ping test begins.
Citrix Application Browsing
The module sends a "Hello" request to the Citrix server which responds by sending the list of applications running on it. Based on this reply, the module compares the applications available on the server with a list of up to four applications configured by the . If all configured applications are running on the Citrix server, the check es. If none are running, the module completes the handshake. This check uses UDP port 1604 by default. Arguments: e.g. application names.
Citrix ICA
The module initiates a connection to the Citrix server, using T port 1494 and performs a Citrix handshake. This check es when the Health Monitoring module identifies the Citrix's reply within the first reply packet.
DH
The Dynamic Host Configuration Protocol allows the automatic configuration of individual hosts in a network. When a new client connects to the network for the first time, the DH servers assign the client its IP address, Subnet Mask, Default Gateway and other parameters. Using the DH health check, the device sends a DHDISCOVER to the DH server.
No Arguments
The DHDISCOVER is sent to the MAC address of the configured server, based on the Destination Host field. After sending the DHDISCOVER, the device sends a DHREQUEST to the server. Once the server replies, the device sends a DHCERELEASE command to the DH server. Arguments: • IP Address: Non-mandatory parameters. When configured, it can either accept an individual IP Address or a Network Address. When the DH server replies to the health check, AppDirector compares the server's reply with the configured value. If the server replies with a different IP address or a different address range than the configured value, the check fails. • Subnet Mask: This is mandatory only if the IP Address field is configured. The Subnet Mask refers to the IP Address and allows configuring either to an individual client (using 255.255.255.255) or any other subnet mask. • Default Gateway: Non-mandatory parameters. When configured, the device compares the server's reply with the configured value. If the server replies with a different IP address, the check fails. • DNS Server: Non-mandatory parameters. When this is configured, the device compares the server's reply with the configured value. If the server replies with a different IP address, the check fails. • WINS Server: Non-mandatory parameters. When configured, the device compares the server's reply with the configured value. If the server replies with a different IP address than the configured value, the check fails.
334
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Configuring Health Monitoring
Parameter
Description
DH (continued)
• Domain: Non-mandatory parameters. When configured, the device compares the server's reply with the configured value. When the server replies with a different value, the check fails. • MAC Address: Non-mandatory parameters. When configured, the device uses the configured MAC address as the MAC address within the DH packet (and not as the Source MAC address in the packet's header). By default, the device uses its base MAC address. When this is configured, the device uses the configured MAC address in the DH data and not in the DH headers. • Relay Agent: Non-mandatory parameters. When this is configured, the device uses the configured address as the GIADDR field in the DH data. This field can accept only IP addresses which are IP interfaces of the device and virtual interfaces. When no field is configured, the device sends the DH request to the server and es the check when the server replies with any IP address.
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 es 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. Arguments: Diameter Argument List Name For details on the Diameter Argument list, see Diameter Argument List and Additional Method Arguments, page 350.
DNS
The 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 the reply matches a specific address (if specified). 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; Host Address
FIX
The module creates a FIX packet and sends it to the FIX server (after the T handshake). A successful check is where the value of TestReqID in the reply packet is the same as the one 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; SenderCompID; TargetCompID; FIX Version. Note: Since the TestReqID parameter is non-mandatory, the default is the number of seconds since 01/01/1970.
FTP
The module executes and commands on the FTP server. When the process is successfully completed, the module executes a SYST command. It can the existence of the file on the FTP server, but it does not the file or check its size. The module verifies that all the commands are executed successfully, then terminates the connection. Arguments: name; ; Filename. Note: The module uses a control session only, not a data session, unless it is necessary to the existence of a file.
Document ID: RDWR-AD-V021403-UG0211
335
AppDirector Guide Configuring Health Monitoring
Parameter
Description
HTTP
The module submits an HTTP request to the Destination IP address. In addition, you can define a specific URL to test. The request can be a GET, POST, or HEAD request. Requests can be in a proxy format or a Web format, and can include a no-cache directive. By default, the module verifies that the returned status is 200. If the checked server is protected, the module may send an authorized name and . The module sends the HTTP request in HTTP 1.0 format. Arguments: Host name; path; HTTP Header, HTTP method; HTTP format (proxy/Web); use of no-cache; text for search within a HTTP header and body, and an indication whether the text appears or not; name and for basic authentication; NTLM authentication option; and up to four valid HTTP return codes.
HTTPS
The module performs an SSL handshake opposite the server. After the session starts, the device sends a GET request from the Checked Element. Arguments: HTTP Header, HTTPS Method; name; ; Match Search String; Match Mode; HTTPS Return Codes. Note: Radware recommends to use interval values > 15 seconds and timeout values > 10 seconds.
IMAP4
The module executes a command to the IMAP server, and verifies that the returned code is OK. Arguments: name; .
LDAP
The Health Monitoring module enhances the Health Checks for LDAP servers by allowing performing searches in the LDAP server. Before Health Monitoring performs the search, it issues a Bind request command to the LDAP server. After performing the search, it closes the connection with the Unbind command. A successful search receives an answer from the server that includes a "searchResultEntry" message. An unsuccessful search receives an answer that only includes only a "searchResultDone" message. Arguments: • name: A with privileges to search the LDAP server. • : The of the . • Base Object: The location in the directory from which the LDAP search begins. • Attribute Name: The attribute to look for. For example, CN Common Name. • Search Value: The value to search for. • Search scope: baseObject, singleLevel, wholeSubtree • Search Deref Aliases: neverDerefAliases, dereflnSearching, derefFindingBaseObj, derefAlways
336
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Configuring Health Monitoring
Parameter
Description
LDAPS
The Health Monitoring module enables LDAP Health Checks to be performed over the SSL transport layer. When using the LDAPS checks, it is recommended to set values greater than 15 seconds for the time interval and 10 seconds for the timeout. Arguments: • : A with privileges to search the LDAPS server. • : The of the . • Base Object: The location in the directory from which the LDAP search begins. • Attribute Name: The attribute to look for. For example CN - Common Name. • Search Value: The value to search for. • Search scope: baseObject, singleLevel, wholeSubtree • Search Deref Aliases: neverDerefAliases, dereflnSearching, derefFindingBaseObj, derefAlways.
NNTP
The module executes a LIST command and verifies that the returned status is valid. No Arguments
Physical Port
The module checks the physical interface status. When the link is up, the check es. Arguments: Physical port number.
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 Destination address to which that the request was sent, and that the sequence number is correct. Arguments: Fail; Ping Data Size. • Fail: Whether the reply is received or not, by default, the check fails when the server does not reply. • Ping Data Size: The size of the ICMP echo request (1 byte to 1024 bytes). The default is 64 bytes.
POP3
The module executes and commands on POP3 server, and checks that the returned code is OK. Arguments: name; .
RADIUS Authentication
The module sends an Access Request with a Name, and a Secret string, and verifies that the request was accepted by the server, which then expects an Access Accept reply. Arguments: name; ; Secret. Note: Ensure that the RADIUS server is configured to accept RADIUS requests from the Radware device.
Document ID: RDWR-AD-V021403-UG0211
337
AppDirector Guide Configuring Health Monitoring
Parameter
Description
RADIUS ing
The module sends a Radius ing Request with a Name, and Secret string, and verifies that the request was accepted by the server which then expects an Access Accept reply. Arguments: name; ; Secret. Notes: • Ensure that the RADIUS server is configured to accept RADIUS requests from the Radware device. • If the “Destination Port Number” is not configured then the device uses UDP port 1813.
RTSP
The module executes a DESCRIBE command and expects a return status of 200. Arguments: Hostname; Path (on the server)
SIP UDP/ SIP T
The Health Monitoring module allows s 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, but what is relevant, is the "200 OK" response from the server. Arguments: • Request URI: The request‘s destination. • From: The “logical name” of the device. • Peer From:Can be configured on the slave device where there is a CDE setup. • Max Forward: The default is 1. • Match search string. • Match mode. • SIP Return code.
SMTP
The module executes a HELLO command to the SMTP server and checks that the returned code is 250. Arguments: HELO
SNMP
The module sends an SNMP GET request, and validates the value in the reply. When the returned value is lower than the minimum range expected or higher than the maximum range expected, 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, similar to Private Load Balancing Algorithms. Arguments: SNMP Object ID to be checked; Community; Min. Value; Max. Value; No New Sessions Value; Use Results For Load Balancing. Notes: • For a device to consider the outcome of the check in the load balancing decisions, set the farm’s Dispatch Method to Response Time. • The SNMP health check s Integer, Counter and Gauge values. While Integer can be a negative value, Counter and Gauge must always be greater than 0.
338
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Configuring Health Monitoring
Parameter
Description
SSL Hello
The 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 Version, can be either V2.3 or V3.0. SSL v3.0 means that pure SSL v3 is used. SSL v2.3 means that the client sends an SSL v2 request to open a SSL v3 session (Internet Explorer operates this way). Default: SSL v2.3
T Port
The module checks the availability of the specified T port. Arguments: • Complete T Handshake: Sets whether an ACK packet is sent before the RST packet. Setting this parameter to Yes results in the following T handshake flow: SYN, SYN_ACK, ACK, RST. Setting this parameter to “No” results in the following T handshake flow: SYN, SYN_ACK, RST. • Complete with Fin.
T -Defined
The module uses a -defined T Health Check. Arguments: Sequence ID (the -defined check).
TFTP
The module checks the availability of TFTP servers. The check opens TFTP connection to the tested server and starts ing the configured file. Once the first block is received, the check is considered successful and connection is disconnected. Arguments: File Full Path
UDP Defined
The module uses a -defined UDP Health Check. Arguments: Sequence ID (the -defined check).
UDP Port
This checks availability of the specified UDP port. It 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. No reply indicates the application’s availability, so when the server is down, the application might still be considered as running. Therefore, the UDP Port check is always used with another server availability check like Ping or ARP. No Arguments
Destination Host (Mandatory)
Destination IP address or hostname of network server to be checked. The destination host can also accept hostnames and not only ip addresses.
Next Hop
IP address of the next hop on the network for this check. This is needed to direct the health check session to a network element's MAC address.
Destination Port
The destination's T\UDP port number. Arguments: The additional argument for the relevant health check method. Possible arguments are based on the Method, and may be one, or a combination of, the following: The arguments are entered in the following format: Argument1=value1| Argument2=Value2. For example, the following is an argument for a FTP check: =JohnSmith| =ABC
Document ID: RDWR-AD-V021403-UG0211
339
AppDirector Guide Configuring Health Monitoring
Parameter
Description
Arguments
Depending on the Check Method that you select, a separate Arguments window appears listing the associated arguments for this method. Enter name of your argument and click Set. The argument is set for the Health Check Method and you are returned to the Health Monitoring Check Table window.
Interval
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: 2^32-1 seconds.
Retries
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
Maximum number of seconds that the device waits for response to the Health Check. This field accepts only integers. Maximum value: 2^32-2 seconds.
No New Session Timeout
Amount of time to , since initiating a check, until AppDirector recognizes this element as heavily loaded and does not send any new sessions to it.
Measure Response Time
Determines whether the response time of the check is being used for load balancing decisions. Applicable only when Dispatch Method is set to Response Time LB. The Response Time is measured in milliseconds. Default: Disabled Also see Dispatch Methods, page 177. Note: There are several parameters that must be configured in health monitoring, for the Response Time Dispatch method or all traffic will be directed only to first server. 1. Configure Health monitoring -->Global Parameters -->Health Monitoring Status - to Enable 2. Configure Health monitoring -->Global Parameters --> Response Level Samples - to non zero value 3. Create Health Monitoring --> Check Table and configure Measure Response Time - to Enable for All servers in the farm 4. Create Health Monitoring --> Binding Table for All servers in the farm
Reverse Check Result
Indicates whether the check fails when reply is received according to the check arguments or the check es when no reply received. Default: Disable (the check fails when the server does not reply).
Table 5 - Predefined Health Check Methods, page 341 describes the predefined Health Check Methods with the configurable parameters. 4.
340
Click Set. Your configuration is set.
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Configuring Health Monitoring This table lists the additional configurable method arguments for each Check Method, and details mandatory arguments, default values, and more.
Table 5: Predefined Health Check Methods
Method Name (and ID)
Argument Name
ARP
No arguments
Citrix
Application 1 Application 2
Argument Description Mandatory
for Application browsing
Additional Info
Default
No
Application 3 Application 4 Citrix ICA
No arguments
DH
IP Address Subnet Mask
255.255.255.255
Default Gateway DNS Server WINS Server Domain MAC Address Relay Agent Diameter
Diameter Argument List Name
DNS
Hostname
Host name to query.
Yes
Host Address
Address to be received.
No
name
name.
Yes
.
Yes
Filename
The file to search on the FTP server.
No
FIX
Validate only the DNS return code.
TESTREQID SENDERCOMP ID TARGETCOMPI D FIX Version
FTP
Document ID: RDWR-AD-V021403-UG0211
341
AppDirector Guide Configuring Health Monitoring
Table 5: Predefined Health Check Methods
Method Name (and ID) HTTP
Argument Name
Argument Description Mandatory
Path
Path of file on Web server to be requested.
No
Hostname
Host name.
No
HTTP Method
HTTP method to submit.
No
Additional Info
Default
Any configured value must begin with a/.
/
• GET,
GET
• POST • HEAD
Proxy HTTP
Use proxy HTTP.
No
• Yes = Use proxy HTTP,
No
• No = Use Web server HTTP. Pragma Nocache
Use pragma: nocache.
No
• Yes= Use pragma: nocache,
No
• N0=Do not use pragma: no-cache. Authentication Authentication Type Type
No
name
name for basic authentication.
No
for basic authentication.
No
Match Search string
Content match pattern No is either present or absent.
Basic, NTLM
BASIC
• Yes =Fail check if pattern not found
Yes
• No =Fail check if pattern is found. Match Mode
Pattern for content match.
No
• String exists • String is absent Wildcards not ed.
342
HTTP Return Code
Valid http code 1
No
HTTP Return Code
Valid http code 2
No
HTTP Return Code
Valid http code 3
No
HTTP Return Code
Valid http code 4
No
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Configuring Health Monitoring
Table 5: Predefined Health Check Methods
Method Name (and ID)
Argument Name
Argument Description Mandatory
Additional Info
Default
HTTP Header Name HTTP Header Value HTTPS
HTTPS Method HTTPS method to submit.
No
• GET,
GET
• POST • HEAD
name
name for basic authentication.
No
for basic authentication.
No
Match Search string
Content match pattern No is either present or absent.
• Yes =Fail check if pattern not found
Yes
• No =Fail check if pattern is found. Match Mode
Pattern for content match.
No
• String exists • String is absent Wildcards not ed.
IMAP4
HTTPS Return Valid https code 1 Code
No
HTTPS Return Valid https code 2 Code
No
HTTPS Return Valid https code 3 Code
No
HTTPS Return Valid https code 4 Code
No
name
name
Yes
Yes
Document ID: RDWR-AD-V021403-UG0211
343
AppDirector Guide Configuring Health Monitoring
Table 5: Predefined Health Check Methods
Method Name (and ID) LDAP
Argument Name
Argument Description Mandatory
name
name
Base Object
Location in directory from which the search starts.
Attribute name
The attribute to look for. For example, CN Common Name.
Search value
The value to search
Search Scope
• baseObject
No
Additional Info
Default
If you configure Base, then Attribute is mandatory.
No
• singleLevel • wholeSubtree Search Deref Aliases
• neverDerefAliases • dereflnSearching • derefFindingBaseOb j • derefAlways
LDAPS
name
name
Base Object
Location in directory from which the search starts.
Attribute name
The attribute to look for. For example, CN Common Name.
Search value
The value to search
Search Scope
• baseObject
No
If you configure Base, then Attribute is mandatory.
No
• singleLevel • wholeSubtree Search Deref Aliases
• neverDerefAliases • dereflnSearching • derefFindingBaseOb j • derefAlways
NNTP
No arguments
Physical Port
Port Number
344
Physical port number.
Yes
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Configuring Health Monitoring
Table 5: Predefined Health Check Methods
Method Name (and ID) PING
Argument Name Fail
Argument Description Mandatory
Check fails when reply No is received or not received.
Ping Data Size Packet size
No
name
name
Yes
No
name
name
Yes
Yes
Secret
Radius Secret
No
Radius name Authenticatio n Secret
name
Yes
Yes
Radius Secret
No
RTSP
Hostname
Host name to use in request.
No
Path
Path of file on RTSP server to be requested.
Yes
POP Radius ing
SIP T
Additional Info
Yes = Fail when server replies,
Default
No
No =Fail when server does not reply. =1 - 1024 bytes
IP address of server.
Request URI From Peer From Max Forward Match search string Match mode SIP return code SIP return code SIP return code SIP return code
Document ID: RDWR-AD-V021403-UG0211
345
AppDirector Guide Configuring Health Monitoring
Table 5: Predefined Health Check Methods
Method Name (and ID) SIP UDP
Argument Name
Argument Description Mandatory
Additional Info
Default
Request URI From Peer From Max Forward Match search string Match mode SIP return code SIP return code SIP return code SIP return code
SMTP
HELO
At the start of all SMTP transactions, the calling machine identifies itself, literally by saying "HELO" with its computer name.
SNMP
OID
Object ID to be used by the check.
Yes
Community
The community used by the device.
Yes
Min. value
Minimum value for Yes check to . If the minimum is lower than the configured value, the check fails.
Max value
Maximum value for check to . If the maximum is higher than the configured value, the check fails.
No New Sessions value
The value between the Yes NNS and the max. If the value falls between these two numbers, then the Checked Element is in “No New Session” mode.
Use Results For Load Balancing
The measured response time for the check.
346
Yes
Yes
No
No
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Configuring Health Monitoring
Table 5: Predefined Health Check Methods
Method Name (and ID) SSL Hello
Argument Name SSL Version
Argument Description Mandatory
v2.3 or v3.0.
Yes
Additional Info
V2.3 or V3.0
Default
v2.3
SSL v3.0 means pure SSLv3 is used. SSLv2.3 means that the client sends an SSLv2 request to open an SSLv3 session (this is how Internet Explorer works, for example). T Port (1)
Complete T Sets whether check No Handshake sends ACK packet before the RST packet.
Yes
Complete with When enabled, the FIN device ends the T check with a FIN Packet.
Yes
T Defined (8)
Sequence ID
TFTP
File Full Path
UDP Port (9)
No arguments
UDP Defined
Sequence ID
Packet sequence to submit.
Yes
Packet sequence to submit.
Yes
Binding Using the health checks, you can associate, or bind, a health check with a checked element. You can also define whether the check is mandatory and set the group number. When several groups are associated with a single Checked Element, they are evaluated with a logical AND between them. Non-Mandatory checks in a group are evaluated with a logical OR between them, so that when there is more than one Non-Mandatory check in a group, a failure of one check does not fail the server.
To bind a health check to a network element 1. From the Health Monitoring menu, select Binding Table. The Health Monitoring Binding Table window appears. 2. Click Create. The Health Monitoring Binding Table Create window appears. 3. Set the parameters.
Parameter
Description
Check
The name of the health check as defined by the in the Checks Table.
Server/NHR/Report The Health Monitoring module binds health checks to NHRs/Servers/LRP and PRP reports, which determine the availability of those elements. Select type of report/server/NHR to perform health monitoring checks.
Document ID: RDWR-AD-V021403-UG0211
347
AppDirector Guide Configuring Health Monitoring
Parameter Group
Description Group number to which check belongs. • allows you to combine different health checks with the same checked element. • uses logical AND/OR depending on the Mandatory field. • Group number is only relevant for a given specific checked element.
Mandatory
Defines if Health Check is mandatory for 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. Values: Mandatory (Default), Non-Mandatory. When mixing Mandatory and Non-mandatory health check bindings, there is a logical AND between the Mandatory & Non-Mandatory groups. This means that if a Non-Mandatory health check binding fails a certain element, even if all Mandatory bindings , the element will be reported as Unavailable (Not In Service).
4.
Click Set. The specified health check is bound to the selected element.
Packet Sequence Table The Packet Sequence Table window enables the to define a packet sequence for a specific, T\UDP, health check. The defines a sequence of Send and Receive packets, containing a configurable string. AppDirector then transmits the Send packets and verifies that the string in the reply matches the string configured for the Receive packets.
Notes: >> In order to define a packet, you need to add 0x before the packet itself; for example: 0x00016e69722e747874006f6374657400 >> In a regular expression, a hex string cannot be used.
To create a packet sequence 1.
From the Health Monitoring menu, select Packet Sequence Table. The Health Monitoring Packet Sequence Table window appears.
2.
Click Create. The Health Monitoring Packet Sequence Table Create window appears.
348
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Configuring Health Monitoring 3. Set the parameters.
Parameter
Description
Seq ID (Sequence ID) ID number of entire packet sequence. Each sequence defines a new -defined check. All packets with same Sequence ID belong to same check. Default: 0 PKT ID (Packet ID)
ID number of the specific packet within the sequence. Default: 0 Note: The first Packet ID of each sequence must always be 0. Packet ID numbers of a sequence must be consecutive.
Type
Type of packet. Values: Send/Transmit (Default), or Receive.
String
Content of packet for verification process. This is the string that is either sent within the packet or the string to match when the packet is received. For Receive type packets, it can include a regular expression.
Description
Description of the specific packet in the sequence.
Compare Method
Used for comparing between content of received packet and content configured in the String parameter. The following possibilities are available: • Regular Expression (Default): String that matches a regular expression rule. • Binary: The exact String that is matched when the packet is received.
4. Click Set. Your configuration is set.
Server Table This table is a read-only table and displays each server configured for the device, in the Application Server Table, and its status.
To access the Server Table 1. From the Health Monitoring menu, select Server Table. The Health Monitoring Server Table window appears. 2. Select the desired server, and the HM Server Table View Details window appears. 3. View these read-only parameters:
Parameter
Description
Server
Index number of the element attached by the AppDirector in the Application Server Table
Description
Description of the network server, for example, Cache.
Farm Name
The name of the farm in which the server is included.
Availability Status
Availability status of the element, Available or Unavailable.
IP Address
IP address of the network server.
Document ID: RDWR-AD-V021403-UG0211
349
AppDirector Guide Configuring Health Monitoring
Parameter
Description
Response Level
Response Level is a normalized grade, given to the check, based on the response times of each successful check over the configured Response Level Sample rate and the configured timeout.
Uptime%
Ratio (in presents) of the number of the success checks and the total number of checks (successful and failures).
Success Counter
The total number of successful checks.
Failure Counter
The total number of unsuccessful checks.
Diameter Argument List and Additional Method Arguments You can configure additional arguments specific to each Health Check 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 equal sign appears, then the required value. A “|” sign is used as a delimiter between the arguments. No extra spaces are allowed. The Diameter Argument Lists Configuration window allows you to configure additional arguments specific to each Health Check Method.
To set the parameters of the Diameter Argument List 1.
From the Health Monitoring window, select Diameter > Arguments List. The Diameter Argument Lists Configuration window appears.
2.
Click Create. The Diameter Argument Lists Configuration Create window appears.
3.
Set the parameters.
Parameter
Description
Argument List Name
The name that you define for this Argument List.
Description
The defined description of this argument list.
Binary File Provided
Defines whether a -defined message has been provided. Values: Yes/No/Not Applicable
Origin-Host
Host name FQDN that identifies the end point that created the Diameter message and is present in all Diameter messages. Note: The Origin-Host AVP may resolve to more than one address.
Origin-Realm
Contains the realm of the originator of the Diameter message and is present in all Diameter messages.
Vendor ID
Value assigned to vendor of Diameter application by IANA. Default is the value identifying 3GPP. Default: 0
Product-Name
350
The vendor assigned name for the product.
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Configuring Health Monitoring
Parameter
Description
Application Message Type
Defines the application message that is sent after the Diameter connection is established. Values: LIR (default): AppDirector generates an LIR (Location Info Request) message. Binary File: Associate a binary file as the Diameter data for the health check packet. The maximum size for the binary file is 1K. None: No application message is sent.
Auth-Application-Id
The Auth-Application-Id AVP (AVP Code 258) is used to of the Authentication and Authorization portion of an application. Default: 0
Auth-Session-State
Specifies which state is maintained for a particular session. The following values are ed: • State Maintained (0) (default): Used to specify that a session state is being maintained, and the access device must issue a session termination message when service to the is terminated. • No State Maintained (1): Used to specify that no session termination messages is sent by the access device upon expiration of the Authorization-Lifetime.
Destination-Realm
Contains realm (FQDN) to which message is routed.
Destination-Host
Host name of the destination Diameter server. Absence of the Destination-Host AVP causes a message to be sent to any Diameter server ing the application within the realm specified in Destination- Realm AVP. When no value is specified, this AVP is not used. When set to 0.0.0.0 the value is taken from the Checked Element IP.
Public Identity
Public identity of referred to in LIR request.
Disconnect Cause
A Diameter node must include this AVP in the Disconnect-Peer-Request message to inform the peer of the reason for its intention to shutdown the transport connection. The following values are ed: • Rebooting (default): A scheduled reboot is imminent. • Busy: The peers internal resources are constrained, and it has determined that the transport connection needs to be closed. • Do Not Want to Talk to You: The peer has decided to terminate the transport connection since it does not expect any messages to be exchanged in the near future.
Accepted Result Codes List of acceptable codes that can be received in a CEA, DPA and LIA messages. These codes are separated by commas (,)or semi colons (;). The default is 2001, 2002, 2003, 2004, 2005. • Diameter First Registration (2001) • Diameter Subsequent Registration (2002) • Diameter Uned Service (2003) • Diameter Success Server Name Not Served (2004) • Diameter Server Selection (2005) 4. Click Set. Your configuration is set.
Document ID: RDWR-AD-V021403-UG0211
351
AppDirector Guide Configuring Health Monitoring
ing, ing and Deleting the Diameter File using Binary File Transfer Binary File Transfer involves sending a file from one location to another in which all eight bits of the byte are transmitted either intact or via some encoding scheme. The Diameter Binary File Transfer window allows you to or the diameter file to the device.
To the diameter file 1.
From the Health Monitoring menu, select Diameter > Binary File Transfer. The Diameter Binary File Transfer window appears.
2.
To from the Diameter File option, select the Diameter Argument List Name from a drop-down list.
3.
Click Set. The file is ed.
To the diameter file 1.
From the Health Monitoring menu, select Diameter > Binary File Transfer. The Diameter Binary File Transfer window appears.
2.
To from the Diameter File option, select the Diameter Argument List Name from a drop-down list.
3.
Click Set. The file is ed.
Deleting the Diameter File The Diameter Binary File Transfer window also allows you to delete the diameter file.
To delete the diameter file 1.
From the Health Monitoring menu, select Diameter > Binary File Transfer. The Diameter Binary File Transfer window appears.
2.
To delete from the Delete Diameter File option, select the Diameter Argument List Name from a drop-down list.
3.
Click Set. The file is deleted.
Defined Methods If you require a specific Health Check Method not provided by the module, you can configure the Health Check protocol manually by defining a stream of send and receive packets for every packet sequence, each with a string to send or receive. The module sends the packets, and verifies that the received packets contain the predefined string. Packet sequences are defined in the Packet Sequence Table. Once defined, the check can be used in Health Check configurations. -defined Checks are available for T checks only.
352
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Configuring Health Monitoring
AppDirector Farm Connectivity Checks This section describes additional options for server monitoring included in the Farm configuration process and includes the following topics: •
Ping Connectivity Method, page 353
•
T Port Connectivity Method, page 354
•
UDP Port Connectivity Method, page 354
•
HTTP Page Connectivity Method, page 354
•
Disabled Connectivity Method, page 355
To load balance traffic reaching an AppDirector farm, the farm servers must be checked. AppDirector periodically checks server health. A successful check shows that the service is available on the server. Failure to connect causes AppDirector to term the server unavailable although AppDirector continues to check its availability and generates a Syslog, E-mail, SNMP or CLI trap to indicate that the server is "Not In Service." AppDirector also monitors the server status in its farms ensuring that they are available and can handle the request. You can perform a Health Check of the servers using these methods: •
Basic: Farm Connectivity Check.
•
Advanced: Health Monitoring module.
Notes: >> You can use either Connectivity Checks or Health Monitoring Checks with Farms regardless of the Health Monitoring Status. However, when both are used, one will override the other, which means that if a Connectivity Check is set, it will override a Health Monitoring Report. >> If there is a need for a large number of concurrent checks, Radware recommends using Health Monitoring instead of Connectivity checks. This table describes parameters to configure the Connectivity Methods.
Parameter
Description
Connectivity Check Port Specific port where to conduct connectivity check. It can be T or UDP, depending on Connectivity Method selected. Note: When the Connectivity Method is HTTP Page, a T port is checked. Values: FTP, HTTP (default), SMTP, DNS, NNTP, HTTPS, RTSP, RADIUS, or any port number you enter manually. For example, HTTP automatically checks port 80. Connectivity Interval
How often AppDirector polls the servers (secs). Default: 10
Connectivity Retries
Number of polling attempts made before server is deemed inactive. Default: 5
Ping Connectivity Method AppDirector pings servers to valid communication. AppDirector performs this by sending an ICMP echo request to the server. If a server is available, it sends an ICMP echo reply. When a Ping fails, the server is down.
Document ID: RDWR-AD-V021403-UG0211
353
AppDirector Guide Configuring Health Monitoring
T Port Connectivity Method When this method is selected, AppDirector attempts to connect to the specified application port by completing the T three-way handshake, which includes the following steps: 1.
AppDirector initiates a request by sending a SYN packet.
2.
The server sends a SYN-ACK packet back to AppDirector.
3.
AppDirector sends a FIN-ACK packet to the server, completing the T 3 way handshake and requesting to terminate the connection.
4.
The server replies with an ACK packet followed by a FIN-ACK packet.
5.
To close the connection, AppDirector sends an ACK packet to the server.
When connection between a server and AppDirector cannot be established, AppDirector automatically sends connectivity checks every 3.5 seconds, regardless of Connectivity Interval value. You can configure the Timeout for connectivity checks by setting the Timeout After T Failure parameter. When this is enabled, AppDirector sends connectivity checks according to the Connectivity Interval parameters in the farm configuration.
Note: Configurations established in the Advanced Settings window apply to all AppDirector farms that use the T Port connectivity check method. 6.
To enable the -defined timeout for the connectivity check specified in the Connectivity Interval parameter (even after a T check failure), select Timeout After T Failure.
UDP Port Connectivity Method When UDP Port Connectivity Method is selected, AppDirector attempts to connect to the specified application port, according to the UDP protocol. If the predefined port is not available, AppDirector receives a message “Destination Unreachable.” If the port is available, no answer is sent. It is impossible to know whether the answer was not sent because the server is available, or because the host computer is not working and is unable to send a response of any kind. To get a clear indication as to whether the server is available or not, AppDirector pings the server when no answer is received.
Note: A server is active only when no answer is received from the server during attempts to connect using the UDP protocol, AND AppDirector receives a successful ping reply.
HTTP Page Connectivity Method For HTTP Page checking, AppDirector periodically performs HTTP GETs for a predefined URL. If the requested Web page is unavailable, the server is considered down. The URL is defined in the Home Page parameters. You can define a Home Page URL that is up to 80 characters long. The Retrieval Frequency saves unnecessary Web page requests by performing only periodical Web page retrieval. The Web page is requested only once in a number of requests, according to the predefined Retrieval Frequency. Otherwise, a simple T check occurs on port 80, or a -defined port. AppDirector examines the HTTP header of the server response and considers responses with the -defined HTTP status code to indicate a healthy server. You can configure HTTP status codes to be used as acceptable responses. By default, an HTTP code of 200 indicates that the service is available.
354
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Configuring Health Monitoring AppDirector can examine the content of the returned Web page and check for the presence or absence of a defined content string using the Content Checking for HTTP parameters. A string (up to 64 characters, case insensitive) can be defined per AppDirector farm. When an AppDirector farm polls an HTTP page from a server, AppDirector issues the request to the server in the format: GET /
Long URL Checks When using the HTTP Farm Connectivity Check, URLs of more than 80 characters can be configured. The Long Extended Check URL window allows you to enter and view Long URLs for an HTTP Farm Connectivity Check. When using Configuration from the device, this configuration is not sent as part of the configuration file. However, this configuration is saved in the compact flash and is not erased when the device is reset
To enter a Long URL for an HTTP Farm Connectivity Check 1. From the AppDirector menu, select Farms > Long URL Check. The Long Extended Check URL window appears. 2. Set the parameters.
Parameter
Description
Farm
Name of the required farm.
Long Extended Check URL
URL of more than 80 characters to be checked.
3. Click Set. Your configuration is set.
To view a Long URL for a specific HTTP Farm Connectivity Check 1. From the Long Extended Check URL window, select the required farm. 2. Click Get. The URL appears and can be edited.
Response Threshold Using Farm connectivity checks with HTTP Page check, the Response Threshold parameter defines the number of milliseconds the server has to 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 is 0.
Disabled Connectivity Method Connectivity checking is disabled. If no farm connectivity checks are performed, AppDirector considers all servers to be available by default. If farm connectivity checks were performed and then the Connectivity Method becomes disabled, the status of the servers remains the same as it was the moment the checks were disabled. If connectivity checks are disabled, and a server renews its activity after a failure, this server is still regarded by the AppDirector as not available.
Document ID: RDWR-AD-V021403-UG0211
355
AppDirector Guide Configuring Health Monitoring
356
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Classes and Bandwidth Management
Chapter 6 – Classes and Bandwidth Management This describes Classes and Bandwidth Management and includes these sections: •
Bandwidth Management Introduction, page 357
•
Bandwidth Management and Classifier Settings, page 361
•
Configuring Bandwidth Management, page 364
•
Services, page 374
Bandwidth Management Introduction Standard Acceleration Bandwidth management, in general, is a simple concept. The idea is to be able to differentiate orclassify traffic according to a wide array of criteria and then assign various priorities to eachclassified packet or session. For example, bandwidth management allows an togive HTTP traffic a higher priority over SMTP traffic, which in turn may have higher priority overFTP traffic. A bandwidth management solution can also track the bandwidthused by each application and set limits as to how much each classified traffic pattern can utilize. There are a variety of methods used to enforce the bandwidth management policies configured by an . The simplest method would be to discard packets when certain thresholds are reached or when certain preallocated session buffers are overflowing. More complex mechanisms include T rate shaping and priority based queuing. T rate shaping uses the inherent flow control mechanisms of the T protocol. By adjusting parameters in the packets’ T headers, a bandwidth management solution can signal the end nodes to throttle the rate at which to transmit packets. Needless to say, the mechanism only works with T sessions. T rate shaping also has some uncertainties associated with it, as the amount of bandwidth associated with sessions can rarely be exactly enforced. Rate shaping also does not work well with protocols that use short lived sessions (such as HTTP), since such sessions usually end before the bandwidth manager has decided how to shape the rate of the session. Priority based queuing is a means by which all classified packets are placed in packet queues,each with its own preset priority. A number of queues are available and when it comes to traffic forwarding, packets are forwarded from the higher priority queues first. This is an oversimplified version of what really happens, but it presents the general concept. Various algorithms and safety measures should be deployed to ensure methodical packet forwarding and protection against “starvation”, where lower priority packets wait in queues for intolerably long amounts of time. Radware’s bandwidth management solution uses priority queues as the fundamental framework behind its operation.
Document ID: RDWR-AD-V021403-UG0211
357
AppDirector Guide Classes and Bandwidth Management
Radware Implementation of Bandwidth Management Although the general concept of bandwidth management is simple, the complexity lies within the implementation and the intricacies. The following diagram describes the general components and tasks that make up Radware’s bandwidth management mechanism.
Figure 16: Radware’s Implementation of 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 . For example, Bandwidth Management allows you to give HTTP traffic a higher priority than SMTP traffic, which in turn, may have higher priority than FTP traffic. The Bandwidth Management solution can also track the total bandwidth used by each application, ensuring a guaranteed bandwidth for certain applications and setting limits for each classified traffic pattern. AppDirector’s Bandwidth Management capability allows you to define policies that restrict or maintain the bandwidth that can be sent or received by each application, , or segment. Controlling the maximal bandwidth of corporate resources that DoS attacks can consume limits the attack spread, ensuring that other mission critical operations 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 by another customer. Using the Bandwidth Management module, Radware devices classify traffic according to pre-defined criteria and enforce a set of actions on that traffic. A comprehensive set of -configurable policies controls how the device identifies and acts upon each packet. There are 4 major components in the system: the classifier, the queues, the scheduler and the Policy Database.
358
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Classes and Bandwidth Management
Classifier The packet first flows into the system through the classifier. It’s the classifier’s duty to decide what to do with the packet. A very comprehensive set of -configurable policies that make up the policy database control how the classifier identifies each packet and what it does with each packet. When the classifier sees the packet, it can do one of three things: •
Discards the packet - This allows the Bandwidth Management module to provide packet filtering. If configured, a reset packet is sent to the server and/or the client.
•
Forwards the packet in “real time” - This means the packet byes 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.
•
Prioritizes the packet - This allows the device to prioritize services.
How the classifier treats the packet is governed by the policy that best matches the packet. If the classifier prioritizes the packet it places it into a queue, which. then gets a priority from 0-7, with 0 being the highest priority and 7 the lowest. Each policy gets its own queue. So, 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 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, etc. The scheduler systematically goes through queues of the same priority when it is time to forward a packet with this priority. The queues with the highest priorities are emptied before lower priority queues. A ratio of 2:1 ensures that a queue is not starved. The CBQ algorithm has the same packet-forwarding pattern as the Cyclic algorithm, with one significant difference. The CBQ algorithm is aware of a predefined bandwidth configured per policy. Each policy can be configured with a guaranteed bandwidth and a maximum bandwidth (see Guaranteed Bandwidth, page 362).
Application Classification Application Classification is defined as Per Packet or Per Session. If it is defined as Per Packet, the device classifies each packet that flows through it. In this mode, every packet must be individually classified. If the 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. Once the session is classified, all packets belonging to the same session are given the same classification, allowing the classifier to classify sessions rather than every single packet.
Classification Mode The following classification modes are available: •
Policies: The device classifies each packet or session by matching it to policies configured by the .
•
Diffserv: The device classifies packets only by the DS (Differentiated Services Code Point) value.
•
ToS: The device classifies packets only by the ToS (Type of Service) bit value.
Document ID: RDWR-AD-V021403-UG0211
359
AppDirector Guide Classes and Bandwidth Management
Bandwidth Borrowing if the scheduler is operating through the CBQ algorithm, it can forward packets from queues, considering the maximum bandwidth configured by that queue’s policy. If borrowing is enabled and the scheduler visits a queue whose bandwidth has been exceeded (or is about to be exceeded), then the scheduler will see if any other policy has “left over” bandwidth. If such a policy is found, bandwidth is borrowed from that policy and allocated to the policy whose bandwidth limit was about to be violated. This allows a scheduling scheme where available bandwidth can be used from other queues, if the queue in question has exceeded its configured 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
Random Early Detection The Random Early Detection (RED) algorithm is used to protect queues from overflowing. The algorithm draws from the inherent retransmission and flow control characteristics of T. When the RED algorithm is deployed, the status of the queues is monitored. When the queues approach full capacity, random T packets are intercepted and dropped. T sends fewer packets when packets are being dropped. Radware's bandwidth management device deploys RED in two forms: •
Global RED - Global RED monitors the capacity of all the queues (i.e., the global set of queues), and randomly discards T packets before the classifier sees them.
•
Weighted RED (WRED) - The RED algorithm checks the priority of the queue (instead of all the packets in the queues), before deciding whether or not packets get dropped.
Maximum Bandwidth Each policy in the policy database can be configured with its own maximum allowed bandwidth. Aside from per-policy configurations, the device can also be configured with a global bandwidth limit. This is the bandwidth limit for the entire device, regardless of individual policy configurations. This limit is the sum of per-physical-port maximum bandwidth configuration. Each physical port for the device can be configured with its own maximum allotted bandwidth, the sum of which will make up the global device bandwidth limit. Note that if borrowing is enabled, bandwidth can not be borrowed beyond the configured maximum bandwidth.
360
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Classes and Bandwidth Management
Bandwidth Management and Classifier Settings Bandwidth Management policy settings enable you to classify and manage traffic ing through the Radware device. A policy is a set of conditions (classification criteria) and the actions that apply as a consequence of the conditions being satisfied. The policy database has 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. Changes to these policies are not effected until the inactive database is activated. Activation updates the active policy database, which sorts the packets that flow through it. The second section of the Policy Database is the polices, by which the device classifies the traffic. To activate the inactive database, s need to manually update the policiy database. When the classifier classifies the traffic it scans the entire policy database until there is a match between the packet/session to one of the policies. Once there is a match the classifier stops the scan. Hence it is important to set the order of the policy according to the volume of the traffic, and set the most common protocol first. •
Default Policy - The last policy in the policy database is the default policy. All traffic that is not matched by the defined policy is matched by the default policy. By default, the default policy forward traffic is assigned a priority 4.
Bandwidth Management Classification Criteria A policy has two main functions: •
To define how traffic should be classified to match the policy
•
To define which action is to be applied on the classified traffic
A policy includes the following traffic classification criteria: •
Source: Defines the source of traffic. This can be a specific IP address or a network. A network is a collection of ranges and/or subnets. Configure the networks; the default value is any, covering 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 traffic direction. Setting direction to "one way" enables asymmetric Bandwidth Management. When a policy is set to "one way", the classifier searches for traffic in one direction only and the device classifies only traffic in one direction; return traffic is not classified. When a policy is set to "two way", the classifier searches for traffic in both directions and the device replaces Source and Destination IP addresses and ports (if the policy is a Layer 4 or Layer 7) of the return traffic.
•
Service: Defines the traffic type. The Service configured per policy allows the policy to consider other aspects of the packet, such as protocol (IP/T/UDP), T/UDP port numbers, bit patterns at any offset in the packet, and content (such as URLs or Cookies) deep in the upper layers of the packet. The default value is none, which covers all protocols.
•
Inbound Physical Port Group: Classifies only traffic received on physical interfaces of the device. It enables you to set different policies on identical traffic classes 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 limited via this policy. The available options are:
Document ID: RDWR-AD-V021403-UG0211
361
AppDirector Guide Classes and Bandwidth Management —
Client (Source IP)
—
Session (Source IP and port)
—
Connection (Source IP and Destination IP)
—
Full Layer 4 Session (Source and Destination IP and port)
—
Session Cookie (must configure cookie identifier)
—
None (bandwidth is performed on the whole session)
—
Cookie Field Identifier (string that identifies the cookie field with the that value used to determine the different traffic flows)
Note: This is required only when Traffic Flow Identification is set to SessionCookie. In such a case, the BWM classifier searches for the Cookie Field Identifier followed by “=” and classifies flows according to the value. •
Classification Point: In the nature of Traffic Redirection and Load Balancing decisions, the device has to modify packets when it forwards the packets to and from the servers. In AppDirector for example, client's traffic is destined to the Layer 4 Policy VIP, but the AppDirector makes a Load Balancing decision and forwards the packet to the selected server, it has to change the destination IP address to the server's real IP address. On LinkProof, client’s use their own IP addresses and after LinkProof forwards the traffic to the NHR, it uses the SmartNAT and changes the source IP address. Bandwidth Management allows s to select at which point in the traffic flow the classification is performed: before modifying the packet or after the modification.
Bandwidth Management Rules Once traffic is classified and matched to a policy, Bandwidth Management rules are 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 T traffic, an RST packet is sent to the client.
•
Block and Bi-directional Reset: All packets are dropped. In T traffic, an RST packet is sent to both the client and the server.
Priority If the action associated with the policy is “forward,” the packet is classified according to the configured priority. There are nine options available; 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 does not allow classified packets to exceed this allotted bandwidth, unless borrowing is enabled. Note that 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.
362
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Classes and Bandwidth Management
Maximum Limit Borrowing can be enabled when the scheduler operates through the CBQ algorithm. If enabled, the scheduler can borrow bandwidth from other queues, to forward packets from queues that have exceeded, or are about to exceed, their allotted amount of bandwidth. Guaranteed Bandwidth and Maximum Limit with the following values cause bandwidth allotted to a policy to act as follows:
Guaranteed Bandwidth
Maximum Bandwidth
Policy Bandwidth
No Minimum
No Minimum
Burstable with no limit, no minimum guaranteed.
X
No Minimum
Burstable with no limit, minimum of X guaranteed.
No Minimum
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 Group 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 within the same group can share bandwidth. The total bandwidth available for a policy group is the sum of the Guaranteed Bandwidth values of all the policies in the group. Also see Viewing Active Policy Groups, page 368.
Configuring a Policy Group Workflow 1. Set the Global BWM Dynamic Borrowing to Enable. 2. Define policy groups. 3. Define the device policies. Configure Guaranteed Bandwidth to the desired value and Maximum Bandwidth to 0. The bandwidth limitation is ignored as the policies borrow unused bandwidth from other policies in the group. Assign each policy to the relevant policy group. 4. Perform Update policies command.
Traffic Flow Max BW Traffic flow is the path of traffic between network elements. This is the maximum bandwidth allowed per traffic flow.
Max Concurrent Sessions The maximum number of concurrent sessions allowed for a client IP.
Note: Not available when Traffic Flow Identification is set to Session or Full Layer 4 Session.
MAX Requests Per Second When the Traffic Flow Max BW parameter is configured and the Traffic Flow Identification is set to Session Cookie, the device tracks and limits the number of requests, such as HTTP GET, Post or HEAD per Cookie.
Document ID: RDWR-AD-V021403-UG0211
363
AppDirector Guide Classes and Bandwidth Management
Packet Marking Packet Marking refers to Differentiated Services Code Point (DS) or Diffserv. It enables the device to mark the matched packet with a range of bits.
Policy Index (Order) The Policy Index, or order, is a number that determines the order of the policy in the 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 and descending in order. The search stops once a policy is matched. The last policy configured is the policy enforced on all packets that do not match other policies; the “default” policy.
Activation/Inactivation Schedule Some policies in a network remain inactive during specific hours of the day and are activated during others. For example, an enterprise may give high priority to mail traffic between 08:00 - 10:00. You can schedule the activation and inactivation of specific Bandwidth Management policies using the Event Scheduler, which can then be attached to a policy's configurations. "Events" define the date and time in which an action must be performed.
Configuring Bandwidth Management Standard Acceleration You can configure the bandwidth for your device according to your needs by using Radware's Quality of Service (QoS) tool. This enables you to classify traffic according to a wide array of criteria, then traffic is handled according to the matching policy. A Bandwidth Management solution can also track the bandwidth used by each application and set limits as to how much bandwidth is used.
Note: Full functionality of the Bandwidth Management module is only available with a SynApps license. The BWM Global Parameters window specifies the BWM functionality of the device.
364
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Classes and Bandwidth Management
To configure Bandwidth Management 1. From the BWM menu, select Global Parameters. The Global Parameters window appears. 2. Set the parameters.
Parameter
Description
Classification Mode
Select from: • Disable: No classification. BWM management feature is disabled. • Policies: The device classifies each packet or session by matching it to policies configured by the . • Diffserv: The device classifies packets only by the DS (Differentiated Services Code Point) value. • ToS: The device classifies packets only by the ToS (Type of Service) bit value. Note: After changing Classification Mode, device needs a reboot.
Scheduling Algorithms
The scheduler forwards packets from the queues. The scheduler operates through one of two algorithms: WRR (Weighted Round Robin) and CBQ (Class Based Queuing). • WRR (Weighted Round Robin) - the scheduler gives each priority a preference ratio of 2:1 over the immediately adjacent lower priority. A 0 queue has twice the priority of a 1 queue, which has twice the priority of a 2 queue, etc. The scheduler systematically goes through same priority queues when it is time to forward a packet with this priority. • CBQ (Class Based Queuing) - has the same packet-forwarding pattern as WRR, with one significant difference. CBQ is aware of the predefined bandwidth configured per policy. As policies are configured, they can be given a guaranteed minimum and a maximum allotted bandwidth, in Kbps. Note: Unless CBQ is used, policies cannot be configured with an associated bandwidth allocation.
Random Early Detection (RED)
If the RED algorithm is deployed, the status of the queues is monitored. If the queues approach full capacity, random T packets are intercepted and dropped. The bandwidth management device can deploy RED in two forms: • Global: The RED algorithm monitors the capacity of all queues and randomly discards T packets before the classifier sees them. • Weighted: The RED algorithm checks the priority of the queue (instead of for all the packets in all the queues) before deciding whether a packet gets dropped or not.
Queue Size
The number of packets in each BWM queue. There is 1 queue per each traffic shaping policy. Default: 128
Dynamic Borrowing (checkbox)
Enables the scheduler to borrow bandwidth from other queues within a group, to forward packets from queues that have exceeded (or are about to exceed) their allotted amount of bandwidth. Available only when the scheduler operates through the CBQ algorithm.
Document ID: RDWR-AD-V021403-UG0211
365
AppDirector Guide Classes and Bandwidth Management
Parameter
Description
BW per Traffic Flow Aging
Time, in seconds, a non-active traffic flow is kept in the flow table used by the Bandwidth Management module.
Max packets for Session Classification
When Application Classification mode is set to Per Session and one of the policies is configured to search for content, this parameter displays maximum number of packets that the device searches through for the configured content. If the device cannot find the content after searching the number of packets defined in the parameter, the device will stop searching. Values: 0 (Disabled - the device will search for the content in all the packets belonging to the session) - 100. Default:5
3.
Click Set. Your configuration is set.
Viewing Active BWM Policies You can view active policies, and configure new ones. The Bandwidth Management module uses a policy database. The policies in a database can be altered and configured without affecting the current operation of the device. As these policies are adjusted, the changes are not in effect unless the inactive database is activated. The activation updates the active policy database, which is what the classifier uses to sort through the packets that flow through it. You can modify these policies according to your requirements at any given time.
To view active policies 1.
From the BWM menu, select View Active Policies. The Active Policies Table window appears.
2.
From the Active Policies Table window, select the policy you wish to view. The table displays the parameters of the active policy.
Parameter
Description
Name
-defined name of the policy.
Index
Index number of the policy.
Destination
Destination address of the packet being matched by the policy. Note: The source or destination can be an IP address or a network address.
366
Source
Source address of the packet being matched by the policy.
Action
Action to be applied to the packet is either Forward, Block, Block and reset, or Block and bi-directional reset.
Direction
Direction to which the policy relates is either Oneway or Twoway. Oneway means a policy only matches packets where the source IP and port match the source, and the destination. Twoway means that if the source matches the destination and vice versa, this is also a match.
Priority
Priority attached to the packet by which it is forwarded is either Realtime or a value of 0-7, 7 being the lowest priority. Priority is only applicable if the action is forward.
Policy Type
Type of policy, BWM or Farm Cluster.
Description
A description of the policy.
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Classes and Bandwidth Management
Parameter
Description
Guaranteed Bandwidth
Defined bandwidth limitation for packets matching this policy. This option is used in conjunction with CBQ, not WWR.
Maximum Bandwidth
Maximum amount of bandwidth that can be borrowed for this policy.
Service Type
Values: None, Basic Filter, Advanced Filter or Filter Group.
Service
Name of the service required for this policy, based on the Service Type.
Packet Marking
Refers to Differentiated Services Code Point (DS) or Diffserv. Enables you to mark the packet with a range of bits displayed in the dropdown list.
Reporting
Whether blocked packets should be reported, either Enable or Disable.
Inbound Physical Port Group
set policies for identical traffic classes that are received on different interfaces of the device. For example, the can allow HTTP access to the main server only to traffic entering the device via physical interface 3. This provides greater flexibility in configuration.
VLAN Tag Group
From dropdown list, select name of tag group that you want to use.
Policy Group
Select from the list of the defined Policy Groups.
View Active Policy Extensions You can view the additional policy parameters in the Active Policies Extensions window.
To view Active Policies Extensions 1. From the BWM menu, select View Active > Policy Extensions. The Active Policies Extensions window appears, which contains the following read-only parameters.
Parameter
Description
Name
The -defined name of the policy.
Classification Point
Indicates whether the classification is done before of after packet modification. • After Changes: Classifies the device after the packet changes. • Before Changes: Classifies the device before the packet changes.
Traffic Flow Identification
Defines what type of traffic flow we are going to limit via this policy. The available options are: • 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).
Traffic Flow Max BW Maximum bandwidth in Kbps allowed per traffic flow. (Kbps) Max Concurrent Sessions
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.
Document ID: RDWR-AD-V021403-UG0211
367
AppDirector Guide Classes and Bandwidth Management
Parameter
Description
Max HTTP Rqts 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 or Post or HEAD per Cookie.
Cookie Field Identifier
String that identifies the cookie field whose value must be used to determine the different traffic flows. Note: This is required only when Traffic Flow Identification is set to SessionCookie. When Traffic Flow Identification is set to SessionCookie, the BWM classifier searches for the Cookie Field Identifier followed by “=” and classifies flows according to the value.
Policy Group
Select from the list of the defined policy groups.
Inactivation Schedule
You can schedule the inactivation of specific Bandwidth Management policies. Using 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.
Viewing Active Policy Groups You can view the active policy groups in the Active Policies Table window. This table displays all the active policy groups. You cannot add or remove policy groups from this table.
To view policy groups From the BWM menu, select View Active > Policy Group. The Active Policy Group Table window appears, with the following parameter.
Parameter
Description
Name
The -defined name of the policy.
Modify Policies You can add, modify and delete policies in the Modify Policies Table window, according to your requirements. In addition, you can edit the default policy of the device. A default policy exists, which can be matched to any traffic that does not match a -defined policy. You can change the action and the priority of the default policy only.
To create a new policy 1.
From the BWM menu, select Modify Policies. The Modify Policies Table window appears.
2.
Click Create. The Modify Policies Table Create window appears.
3.
Set the parameters.
368
Parameter
Description
Name
The -defined name of the policy.
Index
The index number of the policy
Source
The source address of the packet being matched by the policy.
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Classes and Bandwidth Management
Parameter
Description
Destination
The destination address of the packet being matched by the policy. Note: The source or destination can be an IP address or a network address
Direction
The direction to which the policy relates is either Oneway or Twoway. Oneway means a policy only matches packets where the source IP and port match the source, and the destination. Twoway means that if the source matches the destination and vice versa, this is also a match.
Action
The action to be applied to the packet is either Forward, Block, Block and reset, or Block and bi-directional reset.
Priority (SynApps only)
The priority attached to the packet by which it is forwarded is either Real-time or a value of 0-7, 7 being the lowest priority. Priority is only applicable if the action is forward.
Policy Type
The type of policy, BWM or Farm Cluster.
Guaranteed Bandwidth (SynApps only)
The defined bandwidth limitation for packets matching this policy. This option is used in conjunction with CBQ, not WWR.
Service
Name of the service required for this policy, based on the Service Type.
Service Type
Values: None, Basic Filter, Advanced Filter or Filter Group.
Description
A description of the policy.
Operational Status
Specifies the operational status of the policy, Active or Inactive. Note: If you select inactive, when policies are updated, this policy is not used to be matched against packets.
Packet Marking (SynApps only)
Refers to Differentiated Services Code Point (DS) or Diffserv. Enables you to mark the packet with a range of bits displayed in the dropdown list.
Reporting
Whether blocked packets should be reported, either Enable or Disable.
Maximum Bandwidth (SynApps)
Maximum amount of bandwidth that can be borrowed for this policy.
Inbound Physical Port set policies for identical traffic classes that are received on Group different interfaces of the device. For example, the can allow HTTP access to the main server only to traffic entering the device via physical interface 3. This provides greater flexibility in configuration. VLAN Tag Group
From dropdown list, select name of the tag group that you want to use.
Policy Group
Select from the list of the defined policy groups.
4. Click Set. Your preferences are recorded.
Modify Policy Group 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, enabling them to borrow from other policies preventing starvation and utilizing the bandwidth more efficiently. Only policies that participate in a specific group can share bandwidth. To total bandwidth available for a policy group is the sum of Guaranteed Bandwidth values of all policies in the group.
Document ID: RDWR-AD-V021403-UG0211
369
AppDirector Guide Classes and Bandwidth Management The Policies Group table contains all the bandwidth policy groups. You can add new policy groups to this table.
Note: For all the policies that are associated with a policy group the Guaranteed Bandwidth parameter must be set to a value greater than 0 and Borrowing Limit parameter to 0. The Dynamic Borrowing global parameter must be enabled.
To create a new Policy Group 1.
From the Bandwidth Management menu, select Modify > Policy Groups. The Modify Policy Group Table window appears.
2.
Click Create. The Modify Policy Group Table Create window appears.
3.
In the Name text box, type the name of the new Policy Group and click Set. The new policy group appears in the Modify Policy Group Table window and the Active Policy Group Table.
4.
Continue to set the remaining parameters.
Parameter
Description
Name
-defined name of the policy.
Index
Index number of the policy
Source
Source address of the packet being matched by the policy.
Destination
Destination address of the packet being matched by the policy. Note: The source or destination can be an IP address or a network address
Direction
Direction to which the policy relates is either Oneway or Twoway. Oneway means a policy only matches packets where the source IP and port match the source, and the destination. Twoway means that if the source matches the destination and vice versa, this is also a match.
Action
Action to be applied to the packet is either Forward, Block, Block and reset, or Block and bi-directional reset.
Priority (SynApps only)
Priority attached to the packet by which it is forwarded is either Realtime or a value of 0-7, 7 being the lowest priority. Priority is only applicable if the action is forward.
Policy Type
Type of policy: BWM or Farm Cluster.
Guaranteed Bandwidth (SynApps only)
Defined bandwidth limitation for packets matching this policy. This option is used in conjunction with CBQ, not WWR.
Service
Name of the service required for this policy, based on the Service Type.
Service Type
Values: None, Basic Filter, Advanced Filter or Filter Group.
Description
A description of the policy.
Operational Status
Specifies the operational status of the policy, Active or Inactive. Note: If you select inactive, when policies are updated, this policy is not used to be matched against packets.
Packet Marking (SynApps only)
370
Refers to Differentiated Services Code Point (DS) or Diffserv. Enables you to mark the packet with a range of bits displayed in the dropdown list.
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Classes and Bandwidth Management
Parameter
Description
Reporting
Whether blocked packets should be reported, either Enable or Disable.
Maximum Bandwidth (SynApps)
Maximum amount of bandwidth that can be borrowed for this policy.
Inbound Physical Port set policies for identical traffic classes that are received on Group different interfaces of the device. For example, the can allow HTTP access to the main server only to traffic entering the device via physical interface 3. This provides greater flexibility in configuration. VLAN Tag Group
From dropdown list, select name of the tag group that you want to use.
Policy Group
Select from the list of the defined policy groups.
5. Click Set. Your preferences are recorded.
To delete policies 1. From the Modify Policies Table window, select the policy you require to delete. 2. Click Delete. The policy is deleted.
Modify Policy Extensions In the Modify Policies Extensions window you can modify policy extensions according to your requirements.
To Modify Policies Extensions 1. From the BWM menu, select View Active > Modify > View Active Policy Extensions. The Active Policies Extensions window appears. 2. Set the parameters.
Parameter
Description
Name
-defined name of the policy.
Classification Point
Indicates whether the classification is done before of after packet modification. • After Changes: Classifies the device after the packet changes. • Before Changes: Classifies the device before the packet changes.
Traffic Flow Identification
Defines what type of traffic flow we are going to limit via this policy. The available options are: • 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).
Traffic Flow Max BW Maximum bandwidth in Kbps allowed per traffic flow. (Kbps)
Document ID: RDWR-AD-V021403-UG0211
371
AppDirector Guide Classes and Bandwidth Management
Parameter
Description
Max Concurrent Sessions
Maximum number of concurrent sessions allowed for a client IP.
Max HTTP Rqts 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 or Post or HEAD per Cookie.
Cookie Field Identifier
String that identifies the cookie field whose value must be used to determine the different traffic flows.
Note: This option is not available if the Traffic Flow Identifier is set to Session or FullL4Session.
Note: This is required only when Traffic Flow Identification is set to SessionCookie. When Traffic Flow Identification is set to SessionCookie, the BWM classifier searches for the Cookie Field Identifier followed by “=” and classifies flows according to the value.
3.
Policy Group
Select from the list of the defined policy groups.
Inactivation Schedule
You can schedule the inactivation of specific Bandwidth Management policies. Using 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.
Click Set. Your preferences are recorded.
Bandwidth Management and Classes Update Policies You can activate the latest changes made in Bandwidth Management or Classes. You use the Activate Latest Changes window to activate the Inactive Policies.
To activate inactive policies 1.
From the BWM or Classes menu, select Update Policies. The Activate Latest Changes window appears.
2.
Click Set to implement the latest policy changes.
Configuring Networks The Bandwidth Management module allows multiple Networks to have the same configured “name.” This allows a Network with the name “net1” to encom multiple, disted IP address ranges. This makes the Network “name” a logical pointer to all ranges configured with that name and further facilitates the configuration and management of the system. You can view active networks, and configure new ones. You can define networks used by the device (active) and you can define networks kept in a separate database until they are required (inactive). You can add, modify and delete these networks according to your requirements.
372
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Classes and Bandwidth Management
To create a new network 1. From the Classes menu, select Modify > Networks. The Modify Network Table window appears. 2. Click Create. The Modify Network Table Create window appears. 3. Set the parameters.
Parameter
Description
Name
-defined network name.
Sub Index
Unique index number of the subnet. Each network can have several subnets. Sub Indexes for the subnets within the same network must be unique.
Address
IP address of the subnet.
Mask
Mask address of the subnet.
From IP
First IP address in the range of addresses.
To IP
Last IP address in the range of addresses.
Mode
Network mode is either IP Mask or IP Range.
4. Click Set. Your configuration is set.
Note: To simplify configuration, a network can consist of a combination of network subnets and ranges. For example: >> Range = 176.200.100.0: 176.200.100.255 >> Subnet = 172.0.0.0: 255.0.0.0
Viewing Active Networks The View Active Networks window allows you to view and modify active networks and to configure new ones. You can define networks to be used by the device, which are kept in the active part of the database, and you can define networks that will kept in a separate, temporary database until they are required. You can add, modify and delete these networks according to your requirements.
To view active networks From the Classes menu, select View Active Networks. The Active Network Table window appears, with the network parameters as listed above.
To edit a network 1. From the Modify Network Table window, select the network you require to edit. The Modify Network Table Update window appears. 2. Adjust the values of the appropriate fields.
Document ID: RDWR-AD-V021403-UG0211
373
AppDirector Guide Classes and Bandwidth Management 3.
Click Set. Your configuration is set.
To delete networks 1.
From the Modify Network Table window, select the network you want to delete.
2.
Click Delete. The network is deleted.
Services Services can be configured within the Bandwidth Management system and 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.
Basic Filters A basic filter has the following components: •
•
Protocol: The specific protocol that the packet carries. The possible choices are IP, T, UDP, ICMP, and Other. If the protocol is configured as IP, all IP packets (including T and UDP) are considered. When configuring T or UDP protocol, some additional parameters are also available: —
Destination Port (From-To) - Destination port number for the protocol. For example, for HTTP, the protocol is configured as T 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 carries to match the filter.
Offset Mask Pattern Condition (OMPC): The OMPC is a condition where any bit pattern can be located for a match at any offset in the packet. This helps to locate specific bits in the IP header. You do not have to configure an OMPC per filter. However, when an OMPC is configured, the packet needs to match the configured protocol (and Source/Destination ports) AND the OMPC.
Content When the protocol configured is T or UDP, you can search for any text string in the packet. Similar to an OMPC, a text pattern can be searched for at any offset in the packet. HTTP URLs are perfect examples of how a text search can help in classifying a session. The service editor allows you to choose between multiple types of configurable content: URL, host name, HTTP header field, Cookie, mail domain, mail to, mail from, mail subject, file type, regular expression and text. For example, when the content type is “URL”, 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 content of a packet/session into , the classifier can recognize and classify a wider array of packets and sessions. Like OMPCs, content rules are not mandatory to configure. However, when a content rule exists in the filter, the packet needs to match the configured protocol (and ports), OMPC (if one exists) AND the content rule.
374
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Classes and Bandwidth Management
Pre-Defined Filters This table lists pre-defined Bandwidth Management filters for each service.
Table 6:
Service Name
Description
Filter Name
ERP/CRM sap
Basic
Database mssql
Microsoft SQL service group
Group
mssql-monitor
SQL monitoring traffic
Basic
mssql-server
SQL server traffic
Basic
oracle
Oracle database application service group
Group
oracle-v1
Oracle SQL* Net v1-based traffic (v6, Oracle7)
Basic
oracle-v2
Oracle SQL*Net v2/Net 8-based traffic (Oracle7,8,8i,9i)
Basic
oracle-server 1
Oracle Server (e-business solutions) on port 1525
Basic
oracle-server2
Oracle Server (e-business solutions) ON PORT 1527
Basic
oracle-server3
Oracle Server (e-business solutions) on port 1529
Basic
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 Architecture (ICA)
Basic
citrix-rtmp
Citrix RTMP
Basic
citrix-rtmp
Citrix RTMP
Basic
citrix-ima
Citrix Integrated Management Architecture
Basic
citrix-ma-client
Citrix MA Client
Basic
citrix-
Citrix
Basic
p2p
Peer-2-Peer applications
Group
edonkey
File sharing application
Basic
gnutella
File sharing and distribution network
Basic
fasttrack
-to- Media Exchange
Basic
Kaaza
File Sharing Application (Note: Music City Morpheous and Grokster classify as Kaaza)
Basic
Peer-to-Peer
Internet dns
Domain Name Server protocol
ftp-session
File Transfer Protocol service - both FTP commands and data
Basic
http
Web traffic
Basic
http-alt
Web traffic on port 8080
Basic
https
Secure Web traffic
Basic
icmp
Internet Control Message Protocol
Basic
Document ID: RDWR-AD-V021403-UG0211
375
AppDirector Guide Classes and Bandwidth Management
Table 6:
Service Name
Description
ip
IP traffic
nntp
Usenet NetNews Transfer Protocol
Filter Name 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
yahoo-msg2
Yahoo Messenger on port 5050
Basic
yahoo-msg3
Yahoo Messenger on port 5100
Basic
Email mail
Group
smtp
Basic
imap
Basic
pop3
Basic
Basic Filters The Active Basic Filters window allows you to view the basic filters of the active services.
To view a basic filter 1.
From the Classes menu select Modify Services > Basic Filters. The Active Basic Filters window appears.
2.
Select the required name. The Active Basic Filters Update window appears with these read-only parameters.
Parameter
Description
Name
Name of the filter as you define it
Protocol
Values: IP, UDP, T, ICMP. NonIP, SCTP
Destination App Port
Last port in the range of destination ports for UDP and T traffic only. Values: 0 (default) - 65535. Defined value must be greater than Destination Port Range: From value.
376
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Classes and Bandwidth Management
Parameter
Description
Source App. Port
Last port in the range of source ports for UDP and T traffic only. Values: 0 (default) - 65535. Defined value must be greater than the Source Port Range: From value.
OMPC Offset
Location in the packet from which the checking of data is started to find specific bits in the IP/T header. Values: 0 (default) - 1513
OMPC Offset Relative to
Indicates to which OMPC offset the selected offset is relative to. If the IP/UDP/ICMP protocols are selected, you can configure: • None (Default), IP Header, IP Data. If the T protocol is selected, you can set these values: • None (Default), IP Header, IP Data, T Data.
OMPC Mask
Mask for OMPC data. Values: a combination of hexadecimal numbers (0-9, a-f). Value must be defined according to the OMPC Length parameter.
OMPC Pattern
Fixed size pattern within the packet that OMPC rule attempts to find. Values: a combination of hexadecimal numbers (0-9, a-f). The value must be defined according to the OMPC Length parameter. OMPC Pattern 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 Pattern can be:abcd0000. Default: 00000000.
OMPC Condition
Values: N/A (Default), equal, notEqual, greaterThan or lessThan.
OMPC Length
Values: N/A (Default), oneByte, twoBytes, threeBytes or fourBytes.
Content Offset
Location in packet from which the checking of content is started. Values: 0 (default) - 1513
Content
Contains the value of the content search. Values: < space > ! " # $ % & ' ( ) * + , -. / 0 1 2 3 4 5 6 7 8 9 : ; < =>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_ `abcdefghijklmnopqrstuvwxyz{|}~.
Document ID: RDWR-AD-V021403-UG0211
377
AppDirector Guide Classes and Bandwidth Management
Parameter
Description
Content Type
Enables you to search for a specific content type from these values: • N/A (Default) • URL: In the HTTP Request URI • Host Name: In the HTTP Header • Text: Anywhere in the packet • HTTP Header Field: In the HTTP Header • Mail Domain: In the SMTP Header • Mail To: In the SMTP Header • Mail From: In the SMTP Header • Mail Subject: In the SMTP Header • Regular Expression: Anywhere in the packet • Header Type: HTTP Header field. The "Content" field includes the header field name, and the "Content data" field includes the field value • File Type: Type of requested file in the http GET command (jpg, exe etc.) • Cookie Data: HTTP cookie field. The "content" field includes the cookie name, and the "content data" field includes the cookie value.
Filter Type
Select Application Security for Application Security filters, OR Regular for Bandwidth Management filters.
Content Max Length
Maximum length to be searched within the selected Content Type. Values: 0(default) - 1513 Content Max Length value must be equal or greater than Offset value.
Content Data
Refers to search for content within the packet. Values: N/A, URL or Text.
Content Encoding
Application Security can search for content in languages other than English, for case sensitive/insensitive text and hexadecimal strings. Values: • None (Default) • Case Insensitive • Case Sensitive • HEX • International
Content Data Encoding Application Security can search for content in languages other than English, for case sensitive/insensitive text and hexadecimal strings. Values: • None (Default) • Case Insensitive • Case Sensitive • HEX • International Description
378
A description of the filter.
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Classes and Bandwidth Management 3. Click Set. The new Basic Filter is added to the Basic Filters Table.
Note: If you edit the parameters of the filter, which is bound to the existing policy, you need to activate the latest changes
AND Group Filters and OR Group Filters An AND Group 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. An OR Group Filter is a combination of basic filters and/or 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}. In order for 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 pre-configured with a set of basic filters and group filters that represent applications commonly found in most networks.
Creating and Modifying AND Group Tables AppDirector enables you to view active services and to configure new services. You can define services used by the device, which are kept in the active part of the database, and you can define services kept in a separate, temporary database until they are required. You can create basic filters and then combine them with logical conditions to achieve more sophisticated filters, as shown in the Modify AND Group Table window. Use filter groups (for logical OR between filters) and advanced filters (for logical AND between filters). The Modify AND Group Table window allows you to modify an advanced filter.
To create or modify an AND Group table 1. From the Classes menu, select Modify > Services > AND Groups. The Modify AND Groups Table window appears. 2. Select the required advanced name. The Modify AND Groups Update Table window appears, with these read-only parameters:
Parameter
Description
AND Group Name
-defined AND Group name.
Basic Filter Name
Name of the basic filter that is to be added to the Advance Filter.
3. Click Set. Your configuration is set.
Note: If you edit the parameters of the advanced filter, which is bound to the existing policy, you need to activate the latest changes.
Document ID: RDWR-AD-V021403-UG0211
379
AppDirector Guide Classes and Bandwidth Management
Creating and Modifying OR Groups Table You can also add, modify and delete the filters that build the services according to your requirements. The Modify OR Groups Table window allows you to modify an existing filter group.
To add/modify a new OR Group 1.
From the menu select Classes > Modify > Services > OR Groups. The Modify OR Groups Table window appears.
2.
Click Create. The Modify OR Groups Table Create window appears.
3.
Set the parameters.
Parameter
Description
OR Group Name
Name of the Filter Group that you define
Filter Type
Basic: The basic building block of a Service is a basic filter which is made up of the following components: • Protocol: • Destination Port (From-To) • Source Port (From-To) • Offset Mask Pattern Condition (OMPC) • Content AND Group: Combination of basic filters with a logical AND between them. Note: A Filter Group is a combination of basic filters and/or 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}
Filter Name 4.
Name of entry assigned to a specific filter group.
Click Set. Your configuration is set.
Viewing Active Services AppDirector enables you to view active services, and configure new ones.
To view active services From the Classes menu, select View Active > Services > Basic Filters or AND Groups, or OR Groups. OR From the Security menu select Application Security > View Active Services > Basic Filters, Advanced Filters or Filter Groups. The selected table window appears. OR From the Security menu select Application Security > DoS Shield > View Active Services > Basic Filters, Advanced Filters. The selected table window appears.
380
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Classes and Bandwidth Management
Application Port Groups Application Port Groups represent the Layer 4 ports for UDP and T traffic. 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.
To Create or Modify Application Port Groups 1. From the Classes menu, select Modify > Application Port Groups. The Modify Application Port Groups Table window appears. 2. Click Create. The Modify Application Port Groups Table Create window appears. 3. Set the parameters .
Parameter
Description
Name
A defined group name
From Port
Define the first 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.
To Port
Define the last port in the range.
Group Type
Defines the group type either static or regular.
4. For Updating, in the Modify Application Port Groups Table window, click on the application name. The Modify Appl. Port Groups Table Update window appears 5. Click Set. Your configuration is set.
To view Application Port Groups 1. From the Classes menu, select View Active > Appl Port Groups. The Active Application Port Groups Table window appears. 2. Select the desired name. The Active Application Port Groups Table Update window appears which contains the following read-only parameters.
Parameter
Description
Name
A defined group name
From Port
Define the first 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.
Document ID: RDWR-AD-V021403-UG0211
381
AppDirector Guide Classes and Bandwidth Management
382
To Port
Define the last port in the range.
Group Type
Defines the group type either static or regular.
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Classes and Bandwidth Management
Physical Port Groups You can set different policies to identical traffic classes that are received on different interfaces of the device. For example, you can allow access to the main server only to traffic entering the device via physical interface 3. This provides greater flexibility in configuration. You must first configure Port Groups, which are collections of Physical Interfaces of the device, and then associate a Port Group to the required policies. The Modify Physical Port Groups Table window allows you to modify an existing port group.
To modify a port group 1. From the Classes menu, select Modify > Port Groups. The Modify Physical Port Groups Table window appears. 2. Select a group name. The Modify Physical Port Groups Table Update window appears. 3. Set the parameters.
Parameter
Description
Group Name
-configured name of the port group.
Inbound Port
Inbound port for this group. Values can be a port number or Any.
4. Click Set. The Port Group is configured.
VLAN Tag Groups VLAN Tag Groups enable you to set different policies for identical traffic classes received with different values of 802.1q VLAN Tags; e.g., you can allow SMTP access to the Internet only to traffic tagged with a specific value VLAN Tag. This provides configuration flexibility. You must first configure the VLAN Tag Groups.
To modify VLAN tag groups 1. From the Classes menu select Modify > VLAN Tag Groups. The Modify VLAN Tag Groups Table window appears. 2. Set the parameters.
Parameter
Description
Group Name
Name of the group of VLAN Tags.
VLAN Tag
A VLAN Tag number.
VLAN Tag Range From
Lowest value in range of VLAN Tags that you want to define.
VLAN Tag Range To
Highest value in range of VLAN Tags that you want to define.
Group Mode
Mode of the group that you want to define is Discrete if you define a single VLAN Tag number, OR Range if you define range of the group.
3. Click Set. Your configuration is set.
Document ID: RDWR-AD-V021403-UG0211
383
AppDirector Guide Classes and Bandwidth Management
Note: This feature is applicable only when the 802.1q parameter is set to Enabled. Classifications performed according to the tag of the received packet
To view VLAN tag groups 1.
From the Classes menu select View Active > VLAN Tag Groups. The Modify VLAN Tag Groups Table window appears
2.
Set the parameters.
3.
Parameter
Description
Group Name
Name of the group of VLAN Tags.
VLAN Tag
A VLAN Tag number.
VLAN Tag Range From
Lowest value in range of VLAN Tags that you want to define.
VLAN Tag Range To
Highest value in range of VLAN Tags that you want to define.
Group Mode
Mode of group that you want to define is Discrete if you define a single VLAN Tag number, OR Range if you define range of the group.
Click Set. Your configuration is set.
MAC Groups
To view or modify MAC Groups 1.
From the Classes menu select Modify > MAC Groups. The Modify MAC Address Groups Table appears.
2.
Click Create. The Modify MAC Address Groups Table Create window appears.
3.
Set the parameters.
4.
Parameter
Description
Group Name
Name of the MAC address group.
MAC Address
A MAC Address number.
Click Set. Your configuration is set.
Protocol Discovery This describes the Protocol Discovery feature that allows you to recognize different applications running on your network by creating Protocol Discovery Policies. To use the Bandwidth Management module optimally, network s must be aware of the different applications running on their networks 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.
384
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Classes and Bandwidth Management
Protocol Discovery Policies A Protocol Discovery policy comprises traffic classification criteria including: •
Source: Defines the source of traffic. It can be a specific IP address or a network. A network is a collection of ranges and/or subnets. Configure the Networks; the default value is any, which covers traffic from any source.
•
Destination: Defines the traffic destination. 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: Views applications and protocols present in the traffic sent by a transparent network device (firewall, router).
•
Destination MAC Group: Views 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.
•
Classification Point: Defines the point where traffic redirection occurs. The device modifies packets by changing the Destination IP from the Virtual IP to the server’s real IP address. The traffic can be classified as before packet changes, or after packet changes, After Changes.
•
Direction: Defines the direction of the traffic. It can be One Way (from Source to Destination) or Two Way.
•
Operational Status: Determines whether Policy is active or not. Select from Active or Inactive.
Interface Classification This describes the process of interface classification, which enhances Bandwidth performance
Editing Port Bandwidth To optimize the queuing algorithm, it is essential for the BWM 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 is determined by the port type - 100 Mbps for FE ports and 1Gbps for Giga ports. The queuing filter only starts functioning upon link saturation. Configuring the maximum is the only way to determine if the link is saturated.
To edit Port Bandwidth 1. From the BWM menu select Miscellaneous > Port Bandwidth Table. The Port Bandwidth Table window appears. 2. Select the port for which you require to edit the bandwidth. The Port Bandwidth Table Update window appears. 3. Set the parameters.
Parameter
Description
Port Index
Port number.
Port Bandwidth (kbps) Bandwidth available to the specific port. Port Used Bandwidth (kbps)
Amount of bandwidth used on the specific port.
4. Click Set. Your preferences are recorded.
Document ID: RDWR-AD-V021403-UG0211
385
AppDirector Guide Classes and Bandwidth Management
Cancel Classification Per Port This feature enables the to configure ports where classification is not performed. In this way valuable processing time can be saved while enabling a simpler method of configuring the device. Cancel Classification Per VLAN is also available for a VLAN configuration.
To cancel classification for a port 1.
From the BWM menu select Miscellaneous > Cancel Classification Per Port. The Cancel Classification Per Port window appears.
2.
Set the parameters.
Parameter
Description
Inbound Port
Number of the required port for inbound traffic.
Outbound Port
Number of the required port for outbound traffic.
Direction
Direction of traffic 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.
3.
Click Set. Your preferences are recorded.
Modifying Application Port Groups Application Port Groups represent the Layer 4 ports for UDP and T traffic. Each group is identified by its unique name and each group name can be associated with a number of entries in the Application Port Groups table.
To create the Modify Appl. Port Groups Table parameters 1.
From the Classes menu, select Modify Appl Port Groups. The Modify Appl. Port Groups Table window appears.
2.
Click Create. The Modify Appl. Port Groups Table Create window appears.
3.
Set the parameters.
386
Parameter
Description
Name
A defined group name.
From Port
Define the first port in the range. (Values from 0)
To Port
Define the last port in the range.(Values to 65535)
Group Type
Defines the group type either static or regular.
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Classes and Bandwidth Management
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 Set. Your preferences are recorded.
To update the parameters of the Modify Appl. Port Groups Table 1. From the Classes menu, select Modify Appl Port Groups. The Modify Appl. Port Groups Table window appears. 2. Click on the application name. The Modify Appl. Port Groups Table Update window appears. Proceed from step 3.
Viewing Application Port Groups
To view active application port groups 1. From the Classes menu, select View Active > Appl Port Groups. The Active Application Port Groups Table window appears. 2. Select the desired name. The Active Application Port Groups Table Update window appears with read-only parameters. See To create the Modify Appl. Port Groups Table parameters, page 385.
Modify MAC Groups
To modify MAC Groups 1. From the Classes menu select Modify > MAC Groups. The Modify MAC Address Groups Table appears. 2. Click Create. The Modify MAC Address Groups Table Create window appears. 3. Set the parameters.
Parameter
Description
Group Name
Name of the MAC address group.
MAC Address
A MAC address number.
4. Click Set. Your preferences are recorded.
View Active MAC Groups To classify traffic according to Mac addresses, you can create groups of Mac addresses.
Document ID: RDWR-AD-V021403-UG0211
387
AppDirector Guide Classes and Bandwidth Management
To view the Active MAC Groups: From the Classes menu select View Active MAC Groups. The Active MAC Address Groups Table window appears with read-only parameters. See To modify MAC Groups, page 386.
View Active VLAN Tag Groups The Active VLAN Tags Table Update window allows you to view the active VLAN tag groups.
To view the Active VLAN Tag Groups 1.
From the Classes menu select View Active VLAN tag Groups. The Active VLAN Tags Table window appears.
2.
Select a group name. The Active VLAN Tags Table Update window appears which contains the following read-only parameters.
Parameter
Description
Group Name
Name of the group of VLAN Tags.
VLAN Tag
A VLAN Tag number.
VLAN Tag Range From
Lowest value in the range of VLAN Tags that you want to define.
VLAN Tag Range To
Highest value in the range of VLAN Tags that you want to define.
Group Mode
The group mode that you want to define is: • Discrete: when you define a single VLAN Tag number, OR • Range: when you define the range of the group.
Note: This is applicable only when the 802.1q parameter is set to Enabled. Classifications performed according to the tag of the received packet.
Modify Port Groups You can set different policies to identical traffic classes that are received on different interfaces of the device. For example, you can allow access to the main server only to traffic entering the device via physical interface 3. This provides greater flexibility in configuration. You must first configure Port Groups, which are collections of Physical Interfaces of the device, and then associate a Port Group to the required policies. The Modify Physical Port Groups Table window allows you to modify an existing port group.
To modify a port group 1.
From the Classes menu, select Modify Port Groups. The Modify Physical Port Groups Table window appears.
2.
Select a group name. The Modify Physical Port Groups Table Update window appears.
388
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Classes and Bandwidth Management 3. Set the parameters.
Parameter
Description
Group Name
-configured name of the port group.
Inbound Port
Inbound port for this group. Values can be a port number or Any.
4. Click Set. The Port Group is configured.
To create a new port group 1. From the Classes menu select Modify >Port Groups. The Modify Physical Port Groups Table window appears. 2. Select Create. The Physical Port Groups Table Create window appears. Proceed as step 3.
Document ID: RDWR-AD-V021403-UG0211
389
AppDirector Guide Advanced Capabilities
Chapter 7 – Advanced Capabilities This chapter displays AppDirector advanced capabilities and includes the following sections: •
Diameter and LDAP Load Balancing, page 389
•
Multihoming, page 392
•
Segmentation, page 398
•
Session Initiation Protocol (SIP), page 404
•
Stream Control Transmission Protocol (SCTP), page 406
•
Performance Statistics, page 408
•
Statistics Monitor, page 437
•
Utilities, page 439
Diameter and LDAP Load Balancing Standard Acceleration OR USING AN APPDIRECTOR WITH AN APPXCEL DEVICE (also see Optimizing AppDirector with AppXcel Application Accelerator, page 581). Radware enables the management and load distribution of LDAP messages originating from a single T connection across multiple LDAP servers. By handling LDAP messages independently of the number of sources and transmission control protocol (T) connections, Radware guarantees highavailability, accelerated performance. How does it work? 1. Perform Load Balance and maintain the connection — Due to the nature of this protocol you need to do T splitting to perform Load Balancing. The T Splitting table defines for AppDirector which backend servers provide the service that an AppXcel farm must perform T Splitting for, so that the AppDirector knows which backend servers to configure on the AppXcel devices in this farm. 2. Monitor the Diameter or LDAP servers — The Diameter health check (see initiates a connection to the Diameter server. The module then performs a Diameter handshake (CER or CEA) and sends an LIR message or another application message. This monitor help you to see if the server is down in order to send the traffic to another server.
Document ID: RDWR-AD-V021403-UG0211
389
AppDirector Guide Advanced Capabilities
Application Server T Splitting
Standard Acceleration T Splitting is the ability to maintain open concurrent connections opposite all servers providing Diameter or LDAP services, while a single connection was opened by the client. It is important to improve T throughput due to the many applications that use T. A performance characteristic of T is that the rate at which its window size increases is inversely proportional to the average round trip time (RTT), and the average window size is directly related to the throughput. Thus, reducing the RTT between connection endpoints can increase the window size faster, resulting in increased throughput. An intuitive way to reduce the effective RTT of a direct T connection between any two hosts is to split that connection into multiple pipelined sub-connections so that each sub-connection has a lower RTT than the direct connection. In addition to increasing throughput, T Splitting can also route around failures and discover paths that are better than the direct path. This not only improves the connection throughput but also improve the reliability and quality of paths between endpoints.
How does T Splitting work? T splitting uses a performance enhancing proxy access node that divides the end-to-end T connection between the client and the server into a multi-overlay-hop path where each overlay hop is an independent T connection, such that the RTT of each overlay hop is lower than the direct RTT between A and B. Each hop's throughput is governed by that hop's RTT and will be individually higher than the direct throughput between A and B. But performance issues can arise due to the interaction among path segments and different layers for any particular solution. For example, in T Splitting, the intermediate node (the spoofer) sends back a spoofing ACK packet to the T sender immediately upon receiving a T data packet instead of waiting for the ACK from the final T destination. One of the well known problems of T splitting is that by breaking the end-to-end connection, a split T connection is no longer reliable or secure, and a server failure may cause the client to believe that data has been successfully received when it has not. From the Application Server T Splitting window you can access the T Splitting for the Application Server.
To update the Application Server T Splitting 1.
From the AppDirector menu, select Servers > Application Servers > T SplittingTable. The Application Server T Splitting Table window is displayed.
2.
Select a server to edit. Click Create. The Application Server T Splitting Update Table Create window is displayed.
3.
Set the parameters.
4.
390
Parameter
Description
Farm Name
The farm name.
Server Address
The server address.
Server Port
The server port.
Managed Device Name
The name of the managed device in the managed device table.
Tunnel ID
The tunnel ID of the tunnel in the AppXcel.
Click Set. Your configuration is set.
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Advanced Capabilities
T Splitting Table
Standard Acceleration Dynamic load balancing protects ISP networks from sudden congestion caused by load spikes or link failures. Dynamic load balancing protocols, however, require schemes for splitting traffic across multiple paths at a fine granularity. Current splitting schemes present a tussle between slicing granularity and packet reordering. Splitting traffic at the granularity of packets quickly and accurately assigns the desired traffic share to each path, but can reorder packets within a T flow, confusing T congestion control. Splitting traffic at the granularity of a flow avoids packet reordering but may overshoot the desired shares by up to 60% in dynamic environments, resulting in low end-to-end network throughput. The T Splitting table defines for AppDirector which backend servers provide the service that this AppXcel farm must perform T Splitting for, so that AppDirector knows which backend servers to configure on the AppXcel devices in this farm. An entry in this table is configured by selecting a Layer 4 policy from a drop-down list. The dropdown list only displays Layer 4 policies that meet the following conditions: •
It is a T Policy with a specific port.
•
A farm is associated to this Layer 4 policy (not an Layer 7 policy).
•
In the farm associated with the policy: the Transparent Server parameter is set to T Splitting.
Once a Layer 4 policy is configured in the T Splitting table of a Front-End AppXcel farm, the Layer 4 policy parameters that are subjected to the conditions above (Layer 4 Protocol and Layer 4 Port, Farm Name) and the Transparent Server parameter of the Layer 4 policy farm, cannot be changed to values that do not meet the above conditions. See also Application Server T Splitting, page 390.
To create or update the Application Server T Splitting Table 1. From the AppDirector menu, select Farms > T Splitting Table. The T Splitting Table window is displayed. 2. Select a server to edit. The Application Server T Splitting Update window is displayed. 3. Set the parameters.
Parameter
Description
Front-End AppXcel Farm Name
Farm name that holds the Front-End servers (AppXcel tunnels).
Backend L4 Policy Name
Layer 4 policy name that points to the Backend server.
4. Click Set. Your preferences are recorded.
Document ID: RDWR-AD-V021403-UG0211
391
AppDirector Guide Advanced Capabilities
Multihoming This section explains AppDirector Multihoming capability as a solution to load balancing between servers and routers of different ISPs and includes the following topics: •
Default Router Per Virtual IP, page 393
•
Using Redirect to Self in Multi-Homed Environments, page 396
The AppDirector Multihoming solution is intended for networks in which AppDirector is connected to multiple ISPs. Using Multihoming, AppDirector can simultaneously use multiple ISPs for inbound traffic. To achieve multihoming AppDirector uses the ability to configure a default router per Virtual IP Next Hop Router, (VIP NHR) and to redirect to self. To ensure ISP persistency for HTTP transactions (all the sessions related to a HTTP transaction are processed via the same ISP) it is recommended to use Insert Cookie for HTTP persistency capability. This capability must be enabled for all farms involved in the process. Here, AppDirector will ensure ISP persistency automatically.
Figure 17: Multihoming with AppDirector
Router 1
Router 2
Router 3
AppDirector VIP1
VIP3
VIP2
Farm 1
Farm 2
Router 1
Farm 3
Router 2
Router 3
AppDirector VIP1 Farm 1
392
VIP2 Farm 2
VIP3 Farm 3
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Advanced Capabilities
Default Router Per Virtual IP AppDirector allows defining a different default router, and a backup one, for each Virtual IP (including Virtual IP Interfaces) and Outbound NAT addresses. Load sharing can be enabled between the two routers to enable multihoming. The VIP's default router is used for any type of traffic forwarded by the AppDirector from this VIP, or generated by the AppDirector in respect to this VIP, such as: •
DNS answers.
•
LRP or PRP communication.
•
Client proximity checks.
•
HTTP redirection instructions.
•
Triangulated packets.
Note: Static routes cannot be configured per Virtual IP, only the default router can be configured individually for each Virtual IP. Specific static routes are configured globally for the device and take precedence over the default route. You can set a backup default router for AppDirector. This enables using a backup router for traffic generated by AppDirector that is not farm-related, such as ping, SNMP, or DNS requests, and for traffic related to farms that do not have a default router configured.
Setting Up Default Router Per VIP All the Next-Hop Routers that are connected to the AppDirector device are defined in the NHR table. NHRs are associated with the Virtual IP addresses of the device using the VIP NHR table.
Note: The VIP NHR table is enabled only when the packet is destined for the default gateway of the box but because of the static route, the packet was not destined for the default gateway so in these instances the VIP NHR table is not enabled. The NHR per VIP feature works only for traffic that matches the device's default gateway.
Document ID: RDWR-AD-V021403-UG0211
393
AppDirector Guide Advanced Capabilities Before defining the VIP NHR table, you need to add a new NHR to the network and set up the general NHR parameters.
Parameter
Description
NHR IP Address
Address of the selected NHR.
istrative Status Enabled
The -defined management status of the NHR: • Enabled (Default): NHR is active and ready • Disabled: The NHR is not active.
Check Method
The following methods are available: • Ping: AppDirector pings the desired Path Health Check IP according to the predefined Check Interval and Retries. • Disabled (Default): When the router Health Check is disabled, AppDirector still checks by sending ARPs to the router's MAC address. • Health Monitoring Module: NHR is checked using the Health Monitoring module. AppDirector continually sends ARP requests to the NHR to ensure its MAC is correct. If the ARP requests fail, the NHR is labeled ‘Not-in-Service’.
Path Health Check IP
AppDirector pings the remote IP via the specified router to make sure the router is healthy and connected to its uplink. If a Path Health Check fails, the relevant router is considered Not in Service. Default: 0.0.0.0
Check Interval
How often AppDirector polls the NHR (in seconds). Default: 10
Check Retries
Number of polling attempts that are made before a NHR is considered inactive. Default: 3
Note: When the Health Check of the router is disabled, AppDirector still checks the health of the router by sending ARPs to the router's MAC address. Once the general NHR parameters are defined, you can set up the VIP NHR table parameters. For each Virtual IP, you can configure a default router and a backup router, as shown here.
Parameter
Description
VIP Address
VIP address on AppDirector for which default gateway is set. This includes Layer 4 Policy addresses, Virtual IP Interface Addresses, etc. A special entry for Virtual IP 0.0.0.0 is automatically inserted into the VIP NHR table, reflecting the AppDirector default router from the Routing Table. Default: 0.0.0.0
NHR Weight
Weight that AppDirector considers when distributing sessions of the Virtual IP among the NHRs, ensuring that each session uses a single NHR. Default: 1
Backup NHR IP Address
The backup router for this Virtual IP. Default: 0.0.0.0, no NHR is set.
394
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Advanced Capabilities
Parameter
Description
Backup NHR Weight
Backup weight that AppDirector considers when it distributes sessions of Virtual IP among the NHRs. Default: 1
No Route Action
If both routers set for a VIP are down, AppDirector behaves as follows: • Discard: Discards the packet. • Use Regular Routing (Default): Uses the Routing Table.
NHR Load Sharing
Enables or disables load sharing between the primary and backup NHRs, as follows: • Layer 3 Hashing: Traffic is sent through both primary NHR and backup NHR. Load sharing is based on Layer 3 information (IP addresses). • Layer 4 Hashing: Traffic is sent through both primary NHR and backup NHR. Load sharing is based on Layer 4 information (IP addresses and ports). • Disabled (Default): Traffic is sent through primary NHR only.
When a default router and a backup router are configured, you can send outgoing traffic through both NHRs simultaneously. AppDirector performs load sharing between the NHRs of the traffic that arrives from the farms, using Hashing on the Source and Destination IP addresses. This ensures that each session uses a single NHR.
Note: When a server participates in multiple farms, each with a different NHR, AppDirector makes sure to use a NAT address, which is a VIP address that has an active NHR. This means AppDirector keeps a list of up to three VIPs to which a server belongs. When a NAT address for the server is needed, AppDirector uses only VIPs with an active NHR.
Document ID: RDWR-AD-V021403-UG0211
395
AppDirector Guide Advanced Capabilities
Example Default Router per VIP Figure 18 - Default Router Per VIP, page 396, illustrates a typical configuration where a default router is defined for each VIP on AppDirector.
Figure 18: Default Router Per VIP ISP 1
ISP 2
Router 1
Router 2
201.1.1.20
202.2.2.20
201.1.1.1
Port 1 202.2.2.10 AppDirector
VIP: 201.1.1.10
VIP: 202.2.2.10 Port 2 10.1.1.10
Server 1
10.1.1.1
Server 2
10.1.1.2
Properties: •
VIP 1 uses Router 1
•
VIP 2 uses Router 2
•
AppDirector general traffic s Router 1 Configuration
Using Redirect to Self in Multi-Homed Environments Redirect to Self is the ability to redirect clients accessing a VIP to another VIP on the same AppDirector device. The Redirect to Self capability can be used in various configurations and serve various needs. Take, for example, a Multi-homed environment. Farm 1 can redirect requests for service to Farm 2, while Farm 2 redirects to Farm 1, where Farm 1 and Farm 2 are on the same AppDirector, each accessible via a different ISP. Configuration of the Redirect to Self capability in AppDirector is based on defining farms as servers. You can set up a farm using other farms as servers in your farm. The type of server used in this configuration is the LocalFarm server type. The LocalFarm server is another farm on the same
396
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Advanced Capabilities AppDirector. When using redirection based on IP addresses, the IP representing the LocalFarm is an IP address that can be accessed by the clients; usually a public IP address. The Redirect to Self capability works with the following redirection methods: DNS, SIP, HTTP, and RTSP.
Note: Redirect to Self cannot be used with Global Triangulation. In a Multi-homed environment, the Redirect to Self capability can be utilized to share traffic between multiple ISPs, where AppDirector is directly connected to the access routers of these ISPs. Using this configuration, you can load balance not only between servers, but also between ISP routers.
Note: This configuration requires the NHR per VIP feature (see Default Router Per Virtual IP, page 393).
Example Redirect to Self For example, AppDirector is connected to two ISPs, where Router 1 is connected to ISP 1, and Router 2 is connected to ISP 2. Two identical farms (containing the same servers) are configured on the AppDirector device, each associated with an IP address that belongs to one of the ISPs and with a default router which is the router of the ISP. Router 1 is the default router of Farm 1, and Router 2 is the default router of Farm 2. Then, Farm 1 is added as a server for Farm 2, and Farm 2 as a server for Farm 1. This enables Farm 1 to redirect clients to VIP 2 representing Farm 2, and vice versa. When a client accesses Farm 1, a server is selected in this farm using the predefined Dispatch Method. If the server Farm 2 is selected, redirection takes place. Using this configuration, you can achieve load balancing not only between the servers, but also between the routers of the ISPs. This figure illustrates this configuration.
Example Multi-homed Environment This figure presents a regular configuration of a Multi-homed environment where AppDirector is connected to multiple ISPs.
Document ID: RDWR-AD-V021403-UG0211
397
AppDirector Guide Advanced Capabilities
Figure 19: Multihomed Environment ISP 2
ISP 1
Router 1
Router 2
201.1.1.20
202.2.2.20
201.1.1.10
202.2.2.10 Port 1 AppDirector VIP: 202.2.2.10
VIP: 201.1.1.10
Port 2 10.1.1.10 Server 2
Server 1 10.1.1.1
10.1.1.2
Properties •
Traffic is shared between multiple ISPs.
•
When a client accesses Farm 1, a server is selected in this farm, by the usual load balancing considerations. If server Farm 2 is selected, then redirection takes place.
•
Using this configuration, the achieves load balancing not only between the servers, but also between the routers of the ISPs.
Segmentation This section discusses the use of segmentation when working with AppDirector in the network and includes the following topics: •
Segmentation Overview, page 398
•
Implementing Segmentation with AppDirector, page 400
Segmentation Overview Segmentation involves dividing your network into logical segments, where a single AppDirector load balances the traffic for all segments, but traffic between segments is always inspected by a external inspection device (e.g. firewalls, anti-virus device etc.) Using Segmentation, a single AppDirector device connects to multiple segments around the firewall (see Figure 20 - Physical Port Segmentation, page 399). AppDirector forces the traffic originating in one firewall segment and destined to a different segment to through the firewall. This also applies when the Destination IP is a VIP of the Layer 4 Policy that resides on the same AppDirector device.
398
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Advanced Capabilities
Notes: >> You have to attach the VIP to a "different segment" otherwise the traffic from the "firewall segment" to a VIP in the default segment will be redirected to the "firewall" segment NHR on the request path. >> On the reply path the behavior will be according to the non-segment-action parameter.
Figure 20: Physical Port Segmentation Firewall
Interface 2 DMZ2 VIP
Interface 1 10.10.10.2
20.20.20.2
10.10.10.1
20.20.20. Interface 2
DMZ1 VIP 10.10.10.100
Interface 1
AppDirector
Segmentation can be configured using physical ports, as shown here. Physical switches’ ports that connect computing devices (nodes) can be logically grouped together to form segmented virtual LANs on the same physical switch. VLANs require switches that have managed Layer 2 switching capabilities. Switches without management capabilities are usually not capable of implementing VLANs. Segmentation can also be configured using VLAN tags, as shown here.
Figure 21: VLAN Tag Segmentation Clients
Firewall AppDirector Tag 20 Tag 10 DMZ 2 VIP 2
DMZ 1 VIP 1
Document ID: RDWR-AD-V021403-UG0211
399
AppDirector Guide Advanced Capabilities
Implementing Segmentation with AppDirector When implementing Segmentation with AppDirector, you define a type of network entity known as a segment. Segments are logical entities that can be associated either with physical ports (including VLANs and Trunks) or with VLAN Tags. A NHR must be associated with each segment. Typically this would be the firewall interface of that segment. A backup NHR can also be configured for each segment. Layer 4 policies are also associated with segments, to define the logical location of each VIP. Segmentation is performed when there is a conflict between the segment to which the client belongs and the segment to which the Layer 4 policy belongs. AppDirector directly redirects traffic for a Layer 4 policy’s VIP only when the traffic arrives from a client in the same segment where this policy resides. When the device receives traffic that cannot be handled due to segment conflicts, (meaning the segment over which traffic was received does not match the Layer 4 policy segment) the device sends this traffic to the NHR of the receiving (clients) segment, while reply traffic is forwarded from the server to the NHR of the Layer 4 policy segment.
Default Segments Physical ports, Trunks and 802.1q VLAN Tags that are not part of any segment are considered to be of a default segment. No specific NHR is defined for the default segment, but the default gateway belongs to the default segment. Traffic from a client belonging to segment to a destination (the default segment for the server or VIP) will be redirected via the segment NHR. However, the reply will be redirected according to the Default Segment Operating Method.
Note: If you want to allow asymmetric routing, on an ODS 3 platform, the Session Table must to be disabled in order for the traffic to be correctly routed.
Configuring Segmentation 1. Enable Segmentation and configure default segment behavior 2. Configure Segments and attach NHRs.
Notes: >> AppDirector default gateway can only belong to the default segment. >> Device management can only be performed via a port or VLAN tag that belongs to the default segment.
400
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Advanced Capabilities
Segmentation Configuration
To set the Segmentation Global Parameters 1. From the AppDirector menu, select Segmentation > Global Parameters. The Segmentation Global Parameters window is displayed. 2. Set the parameters:
Parameter
Description
Segmentation Operating Method
Select one of the following operating methods: • Ports — Segmentation is enabled and is based on the device physical ports, trunks or VLANs. • VLAN Tag — Segmentation is enabled and based on the 802.1q environment. When the VLAN Tag mode is in use, the 802.1q environment must be enabled and the Multi-VLAN Tag Handling parameter must be set to Overwrite. • Disable (default): The feature is disabled.
Shared Ports
The segmentation shared port list. This is used to configure Ports or VLANs.The device will not perform segmentation on any sessions from or to these Layer 2 interfaces (ports, trunks and/or VLANs). To disable the feature set an empty string. Notes: • Traffic from a default segment to a shared port will be routed normally and will ignore the Default Segment Operating Method. • Shared ports cannot be VLANs.
Default Segment Operating Method
Physical ports, Trunks and 802.1q VLAN Tags that are not part of any segment are considered to be of a default segment. You can configure the behavior of traffic from a port or tag that is not a member of any segment and is destined to a port or tag that is a segment member. Select the Default Segment Operating Method, from one of these: • Forward (Handling without Segmentation): Forwards traffic to destination (not via a firewall)- as if Segmentation was disabled. • Discard: Discards the traffic. • Default Gateway (Handling with Segmentation if necessary)(Default): Forwards the traffic to the AppDirector Default gateway with Segmentation, if necessary. Notes: • Traffic from a shared port to a VIP (Load balanced) or directly to a server (Routing) will be sent directly. • Load balancing to a VIP and the selected server is on a shared port the shared port is unrelated in this scenario. Segmentation will never occur between the VIP and the server's segment. Segmentation conflict might happen here but this depends on the client and VIP parameter.
Document ID: RDWR-AD-V021403-UG0211
401
AppDirector Guide Advanced Capabilities
Parameter
Description
Default Segment Shared VIP
This shows segmentation prevention for sessions from the server to the Layer 4 policy with this segment. When disabled, the segmentation will not be honored. Enables you to provide clients in any other segment direct access, without ing via the firewall, to the Layer 4 policy VIPs belonging to this segment. Default: Disabled Note: Segmentation is always applied to traffic from other segments to IPs belonging to servers in this segment.
... next to Shared Ports. The Arguments for Port List window is displayed as shown here.
3.
Click
4.
Mark the port check boxes as required.
5.
Click Set. You are returned to the Segment Table window.
6.
Click Set. Your configuration is set.
Segment Table The Segment Table allows you to create segments and associate physical ports, VLANs Trunks or 802.1q VLAN Tags to the segment. Sometimes you need to use a single AppDirector device to load balance multiple farms, each located on a different segment around a firewall. In such cases, AppDirector must ensure that all traffic between segments es through the firewall.
To define the parameters of the Segment Table 1.
From the AppDirector menu select Segmentation > Segment Table. The View Filters window is displayed.
2.
Click Create. The Segment Table Create window is displayed.
3.
Set the parameters.
402
Parameter
Description
Segment Name
Enter a name for the new segment.
Port List
Allows you to associate Fast Ethernet ports, Giga Ethernet ports or trunk ports with the segment.
VLAN Tag List
VLAN tag associated with this segment.
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Advanced Capabilities
Parameter
Description
Shared VIP
Enables you to provide clients in any other segment direct access, without ing via the firewall, to the Layer 4 policy VIPs belonging to this segment. Values: Enable or Disable (default) Note: Segmentation is always applied to traffic from other segments to IPs belonging to servers in this segment, (routed traffic).
Backend Segmentation
This defines the behavior when the Layer 4 policy (VIP) and server providing service to this VIP belong to different segments. Values: • Enabled (default): Performs segmentation (forward traffic to Layer 4 policy segment NHR). • Disabled: Forwards traffic directly to server.
4. Click
... next to Port List. The Arguments for Port List window is displayed as shown here.
5. Mark port check boxes as required. 6. Click Set. You are returned to the Segment Table window. 7. Click Set. Your configuration is set.
Segmentation NHR The Segmentation NHR Table is used to assign and update next hop routers to segments. A NHR must be associated with each segment. Typically this would be the firewall interface of that segment. When AppDirector receives traffic that cannot be handled due to segment conflicts (that is, the segment over which traffic was received does not match the segment over which traffic should be forwarded), AppDirector sends this traffic to the NHR of the receiving segment
To assign an NHR to a segment 1. From the AppDirector menu select Segmentation > Segment NHR. The Segmentation NHR window is displayed. 2. Click Create. The Segment NHR Table Create window is displayed 3. Set the parameters.
Parameter
Description
Segment Name
Select the segment name from the drop-down list.
NHR IP Address
IP hop of the next router.
Backup NHR IP Address
IP of the Backup to NHR.
Document ID: RDWR-AD-V021403-UG0211
403
AppDirector Guide Advanced Capabilities
Parameter NHR Weight
Description Configure a weight for each NHR. Default: 1
Backup NHR Weight
Define a backup weight for the NHR. Default: 1
NHR Load Sharing
Enabling NHR Load Sharing sends outgoing traffic through both NHRs at the same time. Default: Disabled
No Route Action
Allows you to configure AppDirector behavior when both the main and backup NHRs are down. Values: • Discard (default): Discards the traffic • Use Regular Routing: Sends traffic according to the regular route
4.
Click Set. Your configuration is set.
To update a segment NHR 1.
From the AppDirector menu select Segmentation > Segment NHR. The Segmentation NHR window is displayed.
2.
Select the desired segment name. The Segment NHR Table Update window is displayed
3.
Set the parameters as shown in assign an NHR to a segment.
4.
Click Set. Your configuration is set.
Session Initiation Protocol (SIP) This explains SIP server load balancing and client-server persistency and includes these topics: •
SIP Load Balancing with AppDirector, page 405
•
Farm Selection Based on SIP Parameters, page 405
•
Load Balancing SIP Servers, page 405
•
Outbound SIP Sessions, page 406
The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include internet telephone calls, multimedia distribution, and multimedia conferences. However, it can be used in any application where session initiation is a requirement. SIP works with several other protocols and is only involved in the signalling portion of a communication session. SIP acts as a carrier for the Session Description Protocol (SDP), which describes the media content of a session, e.g. what IP ports to use, the codec being used etc. All voice or video communications are performed over separate session protocols, usually RTP.
404
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Advanced Capabilities
SIP Load Balancing with AppDirector AppDirector provides the following for load balancing SIP traffic: •
Application specific health checks using the OPTIONS SIP method, see Health Checks Per Farm, page 333.
•
Application-aware farm selection for SIP over UDP (Layer 7 policies).
•
Application-aware server persistency for SIP over UDP, see SIP Persistency, page 261.
Note: For SIP over T, AppDirector offers Layer 4 farm selection and server persistency, and application specific health check
Farm Selection Based on SIP Parameters AppDirector can be used to provide Layer 7 farm selection based on SIP header data for SIP over UDP. The same Layer 7 methods for HTTP can be used for SIP. Using Layer 7 Policies, you can select different farms based on different parameters. For example, one farm can handle all the SIP Registration and a second farm handles the SIP call setup and termination. Layer 7 Policies allow redirection of the session when a specific policy is matched. This can be done using the 302 return status code.
Load Balancing SIP Servers In SIP protocol, IP addresses can be embedded in SIP headers and SDP data. This poses a problem when load balancing SIP traffic. The SIP server that handles the traffic will respond using its own IP address in the SIP data. Since the client who sent the traffic to AppDirector expects an answer at the SIP level (not UDP level) from VIP, this will cause the SIP session to fail. Here are a few available options for solving this issue: 1. Define the SIP servers as Local Triangulation servers in AppDirector. a. b.
On each SIP server configure the loopback adapter with a SIP service VIP. AppDirector will send the traffic to the loopback address of the selected server and the server will use this address inside the SIP payload in the answer.
Note: The network configuration does not need to be Local Triangulation - response traffic can return via AppDirector, (AppDirector must be the default gateway for the servers). 2. Define the SIP servers as Regular servers in AppDirector. a.
b. c.
On each SIP server, there is a physical IP interface. Configure a second IP interface using the SIP service VIP. This can be configured on the physical adapter, a loopback adapter or a virtual adapter. Bind the SIP application to this interface, instead of the physical IP interface. AppDirector sends traffic to the physical address of the server and the server will use this address inside the SIP payload in the answer.
SIP sessions always load balance with servers per session, even if you define eps or regular Sessions Mode on the farm.
Document ID: RDWR-AD-V021403-UG0211
405
AppDirector Guide Advanced Capabilities
Outbound SIP Sessions Outbound SIP sessions must use Server NAT to hide server IP address behind service IP (VIP). Since all sessions from servers within the SIP farm are forwarded using the same IP address as a Source IP and the same source port, AppDirector needs a special process to return the traffic to the initiator server. Dynamic Sessions ID must be used, and the Learning Direction must be set to “Both Directions.” Then, AppDirector returns the traffic based on any of the SIP headers, such as Call-ID. All traffic is routed via AppDirector when using such configurations. for Outbound SIP sessions has a performance impact. To prevent this, the feature must be activated by flagging Outbound SIP only when required (disabled by default). This flag is available in WBM via the AppDirector > Global >Tweaks window, (see Configuring AppDirector Advanced Global Parameters, page 289) and in CLI via appdirector global outbound-sip command. The Layer 4 policy can either use port 5060 and UDP as the Layer 4 protocol or specify SIP as the application.
Notes: Please note that when Outbound SIP traffic needs to be ed the following requirements must be met: >> Servers from which outbound traffic is sent can only belong to farms that are attached to a SIP Layer 4 policy - to ensure a SIP service VIP is used as Server NAT. >> If Layer 7 load balancing is used (for the inbound SIP Layer 4 policies), DSID must be enabled for all the farms that belong to that Layer 7 policy.
Stream Control Transmission Protocol (SCTP) Stream Control Transmission Protocol (SCTP) is a Transport Layer protocol, serving in a similar role to the popular protocols Transmission Control Protocol (T) and Datagram Protocol (UDP). It provides some of the same service features, ensuring reliable, in-sequence, transport of messages with congestion control. In the absence of native SCTP in operating systems you can tunnel SCTP over UDP, and map T API calls to SCTP ones. SCTP is a reliable transport protocol operating on top of a potentially unreliable connectionless packet service such as IP. It offers acknowledged error-free non-duplicated transfer of datagrams (messages). Detection of data corruption, loss of data and duplication of data is achieved by using checksums and sequence numbers. A selective retransmission mechanism is applied to correct loss or corruption of data. The decisive difference from T is multi-homing and the concept of several streams within a connection. In T, a stream is referred to as a sequence of bytes, but in a SCTP, a stream represents a sequence of messages (and these may be very short or long). SCTP can be used as the transport protocol for applications where monitoring and detection of loss of session is required. For such applications, the SCTP path or session failure detection mechanisms, especially the heartbeat, will actively monitor the connectivity of the session. An SCTP association looks like this, so the services of SCTP are naturally at the same layer as T or UDP services.
406
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Advanced Capabilities
Figure 22: Diagram showing the concept of an SCTP association
: We define a single-home SCTP association as a connection between two single IP addresses. A multi-home SCTP association is a connection between multiple addresses. Both client and server can supply additional addresses on top of the one that is carried in the L3 header. The client sends the additional IP addresses in the INIT packet while the server sends the additional IP addresses in the INIT-ACK packet. When NAT is performed for SCTP the INIT and INIT-ACK packets should be updated and the SCTP association should be ed.
SCTP Load Balancing with AppDirector AppDirector s Layer 4 load balancing for SCTP. The following SCTP communication types are ed: •
Single-homed SCTP
•
Multi-homed SCTP
•
NAT for outbound SCTP
Note: Layer 7 load balancing is not ed for SCTP.
Single-homed SCTP A single-home SCTP association is a connection between two single IP addresses. To single-homed Layer 4 load balancing, the following configuration is required in the Layer 4 policy: •
Protocol set to SCTP
•
Application set to SCTP
Document ID: RDWR-AD-V021403-UG0211
407
AppDirector Guide Advanced Capabilities
Multi-homed SCTP A multi-homed SCTP association is a connection between multiple addresses belonging to the same entities. Both client and server can supply additional addresses on top of the one that is carried in the L3 header. The client sends the additional IP addresses in the INIT packet while the server sends the additional IP addresses in the INIT-ACK packet. To multi-homed association for inbound traffic the following configuration is required: •
A farm with one regular server and one backup server for each external link
•
Layer 4 policy with VIP for each external link: —
Protocol set to SCTP
—
Application set to MH-SCTP
The SCTP server answers with multiple internal IP addresses in the INIT-ACK message (a server IP from each farm). AppDirector must NAT all addresses to their respective VIPs (VIP to each server is associated).
Note: Sessions Mode Regular and Client NAT cannot be used for multi-homed SCTP associations.
Outbound SCTP For outbound SCTP traffic AppDirector can NAT all the IP addresses that appear in the INIT message. See also Outbound NAT Addresses, page 286.
To configure NAT for outbound SCTP 1.
Configure Outbound NAT range with NAT Mode set to SCTP NAT.
2.
Configure Outbound NAT Intercept range that includes the SCTP servers and connect to the appropriate Outbound NAT range. The two ranges must have the same size.
Note: Outbound NAT is performed only for SCTP traffic initiated by servers that are defined as farm servers on AppDirector.
Performance Statistics This section discusses general performance indicators (statistics) and includes the following topics: •
Acceleration Engine Statistics, page 409.
•
Last Second Statistics, page 423.
•
Element Statistics, page 424.
•
IP Interface Statistics, page 428.
•
Servers, page 430.
•
AppDirector Statistics, page 432.
•
T Splitting Statistics, page 433.
•
Protocol Statistics, page 435.
408
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Advanced Capabilities
Acceleration Engine Statistics
Enhanced Acceleration You also have the ability to take a comprehensive view of monitoring and statistics information through the WBM. Acceleration engine data is shown in aggregated tables that facilitate a quick check on the Acceleration Engine status and value. Using these statistics tables, you can drill down to a specific interface, Layer 4 policy or Rule-list rules.
Notes: >> All Views are set to refresh automatically according to the refresh rate specified in configuration view. >> In WBM, all statistics pages allow you to filter for viewing only specific items. >> The configurable statistics measuring period and WBM view Auto-refresh time are shown at the bottom of each statistics window. To edit go to Configuration, page 421.
Throughput Summary From the Performance menu, select Acceleration > Throughput> Summary. The Acceleration Engine Throughput Summary window is displayed with these read-only parameters:
Parameter
Description
Client Side Throughput • Mbits In - Average of incoming traffic from clients into the Acceleration Engine per second. • Mbits Out - Average of outgoing traffic towards clients from the Acceleration Engine per second. • Total (In + Out) - Average of total clients related traffic going in both ways through the Acceleration Engine per second. Server Side Throughput
• Mbits In - Average of incoming traffic from servers into the Acceleration Engine per second. • Mbits Out - Average of outgoing traffic towards servers from the Acceleration Engine per second. • Total (In + Out) - Average of total servers related traffic going in both ways through the Acceleration Engine per second.
Total Throughput
• Mbits In - Average of incoming traffic coming into the Acceleration Engine per second. • Mbits Out - Average of outgoing traffic from the Acceleration Engine per second. • Total (In + Out) - Average of total traffic going in both ways through the Acceleration Engine per second.
Document ID: RDWR-AD-V021403-UG0211
409
AppDirector Guide Advanced Capabilities
Throughput per Layer 4 Policy From the Performance menu, select Acceleration > Throughput> Per L4 Policy. The Acceleration Engine Throughput Per L4 Policy window is displayed with these read-only parameters:
Parameter
Description
Client Side Throughput
• Mbits In - Average of incoming traffic from clients into the Acceleration Engine per second per Layer 4 policy. • Mbits Out - Average of outgoing traffic towards clients from the Acceleration Engine per second per Layer 4 policy. • Total (In + Out) - Average of total clients related traffic going in both ways through the Acceleration Engine per second per Layer 4 policy.
Server Side Throughput
• Mbits In - Average of incoming traffic from servers into the Acceleration Engine per second per Layer 4 policy. • Mbits Out - Average of outgoing traffic towards servers from the Acceleration Engine per second per Layer 4 policy. • Total (In + Out) - Average of total servers related traffic going in both ways through the Acceleration Engine per second per Layer 4 policy.
Total Throughput
• Mbits In - Average of incoming traffic coming into the Acceleration Engine per second per Layer 4 policy. • Mbits Out - Average of outgoing traffic from the Acceleration Engine per second per Layer 4 policy. • Total (In + Out) - Average of total traffic going in both ways through the Acceleration Engine per second per Layer 4 policy.
Note: Statistics shown for all Layer 4 policies also include their Acceleration capabilities, that is. their traffic flows through Acceleration Engine. A Layer 4 policy that does not include any Acceleration policy (SSL, Cache, compression, Multiplexing) will not show this view.
Connections Summary From the Performance menu, select Acceleration > Connections> Summary. The Acceleration Engine Connections Statistics Summary window is displayed.
Parameter
Description
Client Side Concurrent Connections
Current Number of clients concurrent connections held by Acceleration Engine.
Client Side New Connections
Counted Number of new clients connections opened by Acceleration Engine every measuring period.
Server Side Concurrent Connections
Current Number of concurrent servers connections held by Acceleration Engine.
Server Side New Connections
Counted Number of new servers connections opened by Acceleration Engine every measuring period.
Total Concurrent Connections
Total Counted Number of clients connections opened by Acceleration Engine every second.
Total New Establish Connections
Total Counted Number of new clients connections opened by Acceleration Engine every second.
410
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Advanced Capabilities
Parameter
Description
Connections Multiplexing Percentage (Server or Client Connections)
Percentage of number of clients connections and server connections that shows how well the Acceleration Engine decreases the connection load on servers at the time of measuring (instantaneous measuring).
New Connections Establishing Rate (Conn/Sec)
Average number of connections opened to or by the Acceleration Engine per second.
Connections per Layer 4 Policy From the Performance menu, select Acceleration > Connections> Summary. The Acceleration Engine Connections Statistics Per L4 Policy window is displayed.
Parameter
Description
Client Side Connections
Concurrent
Current Number of clients concurrent connections held by Acceleration Engine per Layer 4 policy.
New
Counted Number of new clients connections opened by Acceleration Engine every second per Layer 4 policy.
Concurrent
Current Number of concurrent servers connections held by Acceleration Engine per Layer 4 policy.
New
Counted Number of new servers connections opened by Acceleration Engine every second per Layer 4 policy.
Concurrent
Total Counted Number of clients connections opened by Acceleration Engine every second per Layer 4 policy.
New
Total Counted Number of new clients connections opened by Acceleration Engine every second per Layer 4 policy.
Server Side Connections
Total Connections
Multiplexing Percentage
Percentage of the number of clients connections and server connections that shows how well the Acceleration Engine decreases the connection load on servers at the time of measuring (instantaneous measuring) per Layer 4 policy.
New Connections/Sec
Average number of new connections opened by Acceleration Engine per second per Layer 4 policy.
Note: Statistics shown for all Layer 4 policies also include their Acceleration capabilities, that is. their traffic flows through Acceleration Engine. A Layer 4 policy that does not include any Acceleration policy (SSL, Cache, compression, Multiplexing) will not show this view.
HTTP Requests Summary From the Performance menu, select Acceleration > HTTP> Requests And Responses >Summary. The Acceleration Engine HTTP Requests Summary window is displayed.
Parameter
Description
Requests - Clients > AppDirector
Number of clients requests from AppDirector done in the measuring period.
Requests - AppDirector > Servers
Number of AppDirector requests from Servers done in the measuring period.
Document ID: RDWR-AD-V021403-UG0211
411
AppDirector Guide Advanced Capabilities
Parameter
Description
Responses - Servers > AppDirector
Number of Servers responses to AppDirector in the measuring period.
Responses - AppDirector > Clients
Number of AppDirector responses to Clients in the measuring period.
HTTP Transaction Rate
Transactions per seconds rate calculated by total number of transactions divided by measuring period.
HTTP Requests per Layer 4 Policy From the Performance menu, select Acceleration > HTTP> Requests And Responses >Per L4 Policy. The Acceleration Engine HTTP Requests Per L4 Policy window is displayed.
Parameter
Description
L4 Policy
Name of L4 Policy for which this row shows statistics.
Requests
Clients -> AE
Number of clients requests from AppDirector done in the measuring period per Layer 4 policy.
AE -> Servers
Number of AppDirector requests from Servers done in the measuring period per Layer 4 policy.
Clients -> AE
Number of Servers responses to AppDirector in the measuring period per Layer 4 policy.
AE -> Servers
Number of AppDirector responses to Clients in the measuring period per Layer 4 policy.
Responses
Transaction/Sec.
Transactions per seconds rate calculated by total number of transactions divided by measuring period per Layer 4 policy.
Note: Statistics shown for all Layer 4 policies also include their Acceleration capabilities, that is. their traffic flows through Acceleration Engine. A Layer 4 policy that does not include any Acceleration policy (SSL, Cache, compression, Multiplexing) will not show this view.
HTTP Statistics Summary From the Performance menu, select Acceleration > HTTP> Statistics >Summary. The Acceleration Engine HTTP Statistics Summary window is displayed.
Parameter
Description
Clients Using Keep-Alive
Number of clients counted sending "Connection: Keep-Alive" HTTP Header or Using HTTP 1.1.
HTTP 1.0 Percentage
Percent of requests done using HTTP 1.0 during measuring period.
HTTP 1.1 Percentage
Percent of requests done using HTTP 1.1 during measuring period.
Number of HTTP to HTTPS redirections
Number of HTTP redirect location headers updated from HTTP to HTTPS by AppDirector.
Average Number of Requests per Connection
Average number of requests done over each client connection calculated by total number of client request divided by number of clients side connections.
412
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Advanced Capabilities
Parameter
Description
Number of responses smaller than 1KB
Number of Responses for which content size reported smaller than 1KB.
Number of responses 1KB - 10KB
Number of Responses for which content size reported between 1KB and 10KB.
Number of responses 11KB - 50KB
Number of Responses for which content size reported between 11KB and 50KB.
Number of responses 51KB - 100KB
Number of Responses for which content size reported between 51KB and 100KB.
Number of responses larger than 100KB
Number of Responses for which content size reported larger than 100KB.
HTTP Statistics per Layer 4 Policy From the Performance menu, select Acceleration > HTTP> Statistics >L4 Per Policy. The Acceleration Engine HTTP Statistics Per L4 Policy window is displayed.
Parameter
Description
L4 Policy
Name of L4 Policy for which this row shows statistics.
Clients Using Keep Alive
Number of clients counted sending "Connection: Keep-Alive" HTTP Header or Using HTTP 1.1 per Layer 4 policy.
HTTP 1.0 v 1.1 Percentage
Percentage of the number of HTTP statistics per Layer 4 policy.
HTTP to HTTPS Redirections
Number of HTTP redirect location headers updated from HTTP to HTTPS by AppDirector per Layer 4 policy.
Average Requests/Connection
Average number of requests done over each client connection calculated by total number of client request divided by number of clients side connections per Layer 4 policy.
Number of responses per Content size
Document ID: RDWR-AD-V021403-UG0211
Smaller than 1KB
Number of Responses for which content size reported smaller than 1KB per Layer 4 policy.
1KB - 10KB
Number of Responses for which content size reported between 1KB and 10KB per Layer 4 policy.
11KB - 50KB
Number of Responses for which content size reported between 11KB and 50KB per Layer 4 policy.
51KB -100KB
Number of Responses for which content size reported between 51KB and 100KB per Layer 4 policy.
Larger than 100KB
Number of Responses for which content size reported larger than 100KB per Layer 4 policy.
413
AppDirector Guide Advanced Capabilities
Note: Statistics shown for all Layer 4 policies also include their Acceleration capabilities, that is. their traffic flows through Acceleration Engine. A Layer 4 policy that does not include any Acceleration policy (SSL, Cache, compression, Multiplexing) will not show this view.
SSL Statistics Summary From the Performance menu, select Acceleration > SSL> Statistics Summary. The Acceleration Engine SSL Statistics Summary window is displayed.
Parameter
Description
New SSL handshake (Session/Sec)
Number of New SSL handshakes between Clients and AppDirector per second.
Reused SSL sessions (Session/Sec)
Number of Existing SSL Handshakes reused by clients to communicate with AppDirector per second.
Reused SSL sessions (%)
Percentage of SSL session reusing keys.
SSLv2 Percentage
Percentage of session using SSLv2 out of all session during measuring period.
SSLv3 Percentage
Percentage of session using SSLv3 out of all session during measuring period.
TLS Percentage
Percentage of session using TLS out of all session during measuring period.
SSL Statistics per Layer 4 Policy From the Performance menu, select Acceleration > SSL> Statistics per L4 Policy. The Acceleration Engine SSL Statistics Per L4 Policy window is displayed.
Parameter
Description
Name
Name of L4 Policy for which this row shows statistics.
New Handshakes/Sec
Number of New SSL handshakes between Clients and AppDirector per second per Layer 4 policy.
Reused Sessions /Sec
Number of Existing SSL Handshakes reused by clients to communicate with AppDirector per second per Layer 4 policy.
Reused Session Percentage
Percentage of SSL session reusing keys per Layer 4 policy.
SSL V2 Percentage
Percentage of session using SSLv2 out of all session during measuring period per Layer 4 policy.
SSL V3 Percentage
Percentage of session using SSLv3 out of all session during measuring period per Layer 4 policy.
TLS Percentage
Percentage of session using TLS out of all session during measuring period per Layer 4 policy.
Note: Statistics displayed for all Layer 4 policies also includes their Acceleration capabilities, (their traffic flows through Acceleration Engine). A Layer 4 policy that does not include any Acceleration policy (SSL, Cache, compression, Multiplexing) does not show this view.
414
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Advanced Capabilities
Cache Summary From the Performance menu, select Acceleration > Cache > Summary. The Cache Summary window is displayed.
Parameter
Description
Number of Objects Served from Cache
Number of Objects served by cache within the measuring period.
Cache Hits Percentage
Percent of HTTP requests served by objects from cache.
Cache Serving Rate (Requests/ Second)
Rate of requests served by cache every second, calculated by total number of requests served by cache divided by measuring period.
Number of New Cached objects
Amount of new objects cached by size during the measuring period.
Object Caching Rate (Requests/ Second)
Average number of objects cached by size every second calculated by amount of new cached objects divided by measuring period.
New Cached Bytes
Amount of new bytes cached by size during the measuring period.
Byte Caching Rate (Bytes/Second)
Average number of bytes cached every second calculated by amount of new bytes objects divided by measuring period.
Objects of Average Size Smaller than 10KB
Amount of objects cached by size during last measuring period of Average size smaller than 10KB.
Objects of Average Size 11KB100KB
Amount of objects cached by size during last measuring period of Average size between 11KB and 100KB.
Objects of Average Size 101KB-1MB Amount of objects cached by size during last measuring period of Average size between 101KB and 1MB Objects of Average Size Larger than Amount of objects cached by size during last measuring 1MB period of Average size larger than 1MB.
Document ID: RDWR-AD-V021403-UG0211
415
AppDirector Guide Advanced Capabilities
Cache Rates per Layer 4 Policy Summary From the Performance menu, select Acceleration > Cache > Rates per L4 Policy. The Cache Rates Per L4 Policy window is displayed.
Parameter
Description
Name
Name of L4 Policy for which this row shows statistics.
Number of Objects Served
Number of Objects served by cache within the measuring period per Layer 4 policy.
Cache Hits%
Percent of HTTP requests served by objects from cache per Layer 4 policy.
Cache Requests/Sec
Rate of requests served by cache every second, calculated by total number of requests served by cache divided by measuring period per Layer 4 policy.
New Cached Objects
Amount of new objects cached during the measuring period per Layer 4 policy.
Objects/sec Cached
Average number of objects cached every second calculated by amount of new cached objects divided by measuring period per Layer 4 policy.
New Cached Bytes
Amount of new bytes cached during the measuring period per Layer 4 policy.
Bytes/Sec Cache
Average number of bytes cached every second calculated by amount of new bytes objects divided by measuring period per Layer 4 policy.
Note: Statistics shown for all Layer 4 policies also include their Acceleration capabilities, that is, their traffic flows through Acceleration Engine. A Layer 4 policy that does not include any Acceleration policy (SSL, Cache, compression, Multiplexing) will not show this view.
Cache Statistics per Layer 4 Policy From the Performance menu, select Acceleration > Cache > Statistics per L4 Policy. The Cache Statistics per L4 Policy window is displayed.
Parameter
Description
Name
Name of Layer 4 policy for which this row shows statistics.
Objects of Average Size
Smaller than 10K
Amount of objects cached by size during last measuring period of Average size smaller than 10KB per Layer 4 policy.
11KB - 100KB
Amount of objects cached by size during last measuring period of Average size between 11KB and 100KB per Layer 4 policy.
101KB - 1MB
Amount of objects cached by size during last measuring period of Average size between 101KB and 1MB per Layer 4 policy.
Larger than 1MB
Amount of objects cached by size during last measuring period of Average size larger than 1MB per Layer 4 policy.
416
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Advanced Capabilities
Note: Statistics shown for all Layer 4 policies also include their Acceleration capabilities, that is, their traffic flows through Acceleration Engine. A Layer 4 policy that does not include any Acceleration policy (SSL, Cache, compression, Multiplexing) will not show this view.
Cache URL-Exceptions Rule-Lists From the Performance menu, select Acceleration > Cache > URL- Exceptions > Rule-Lists Statistics. The Cache URL-Exceptions Rule-Lists Statistics window is displayed.
Parameter
Description
Name
Name of Layer 4 policy for which this row shows statistics.
Cached Objects
Number of objects cached per URL Exceptions policy.
Cached Bytes
Number of bytes cached per URL Exceptions policy.
Cache URL Rule-List per Rule From the Performance menu, select Acceleration > Cache > URL- Exceptions > Rule-Lists perRule Statistics. The Cache URL-Exceptions Rule-Lists per-Rule Statistics window is displayed.
Parameter
Description
Rule List Name
There are multiple rule-lists. Each is a “policy” that contains multiple rules.
Rule Name
Name of each rule in the Rule-List used to identify it.
Rule Priority
Location of the rule in the Rule-List. Since Rule-Lists are scanned for a match from top (priority 1) to bottom (priority ~65000) this enables to set the location of the rule in the rule-list. See Leveraging Rule List Behavior, page 219 on how to use the priority efficiently.
Cached Objects
Number of objects cached as a result of matching the rule.
Cached Bytes
Number of bytes cached as a result of matching the rule.
Notes: >> You can use URL files to specify folders or file types to be cached or not cached. You can do this by entering a string in the URL filed containing only the file extension or folder name. >> If these strings appear elsewhere in the URL, they will also be matched.
Cache Content You can a file containing the entire list of objects residing in cache at time. 1. From the Performance menu, select Acceleration > Cache > Cache Content. The Acceleration Engine Cache Object-List window is displayed. 2. To save the file listing all cache content, select Save Cache Dump file. 3. A dialog box is displayed asking you if you wish to open or save the Cache Dump file.
Document ID: RDWR-AD-V021403-UG0211
417
AppDirector Guide Advanced Capabilities 4.
If you click Open, a Microsoft Excel .csv file will open displaying the following parameters:
Parameter
Description
URL
Object’s full URI path.
Size (KB)
Size of the cached object.
Chunked
Is object stored chunked? Values Yes or No. The same object can be cached more than once in a chunked copy and unchunked copy.
Compressed
Is object stored or compressed? Values: Yes or No.
Last Access 5.
Date or Time of last access to objects.
If you click Save, you are prompted to save a .csv file in the following default format:
yyyy-mm-dd-hh-mm-ss_cache_dump_file.csv based on your current device system time.
Compression Summary From the Performance menu, select Acceleration > Compression > Summary. The Compression Summary window is displayed.
Parameter
Description
Uncompressed Throughput (Kbps)
Total Throughput of compressible objects before compression counted during measuring period.
Average Uncompressed Object Size (Kbps) Average object size before compression. Compressed Throughput (Kbps)
Total Throughput of compressible objects after compression counted during measuring period.
Average Compressed Object Size (Kbps)
Average object size after compression.
Average Compression Percentage (%)
Average compression percentage during measuring period calculated by average uncompressed size divided by average compressed size.
418
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Advanced Capabilities
Compression Statistics per Layer 4 Policy From the Performance menu, select Acceleration > Compression > Statistics per L4 Policy. The Compression Statistics Per L4 Policy window is displayed.
Parameter
Description
Name
Name of Layer 4 policy for which this row shows statistics.
Uncompressed Throughput (KB)
Total Throughput of compressible objects before compression counted during measuring period per Layer 4 policy.
Average Uncompressed Size (KB)
Average object size before compression per Layer 4 policy.
Compressed Throughput (KB)
Total Throughput of compressible objects after compression counted during measuring period per Layer 4 policy.
Average Compressed Size (KB)
Average object size after compression per Layer 4 policy
Compression Percentage
The compression percentage is measured by ((Server Side Objects accumulative size) – (Client Side Objects accumulative size))*100/(Server Side Objects accumulative size). e.g. 1MB received from server 400KB sent to client = 60% compression by (1000-400)*100/1000.
Note: Statistics shown for all Layer 4 policies also include their Acceleration capabilities, i.e. their traffic flows through Acceleration Engine. A Layer 4 policy that does not include any Acceleration policy (SSL, Cache, compression, Multiplexing) will not show this view.
Compression URL- Exceptions Rule-Lists From the Performance menu, select Acceleration > Compression > URL - Exceptions > RuleLists Statistics. The Compression URL-Exceptions Rule-Lists Statistics window is displayed.
Parameter
Description
Name
Name of Compression’s URL Exception Policy for which this row shows statistics.
Matched Objects
Number of objects matched during measuring period by the URL Exception Policy for which this row shows statistics.
Size Before Compression Total uncompressed size of objects matched during measuring period by the URL Exception Policy for which this row shows statistics. Size After Compression
Total compressed size of objects matched during measuring period by the URL Exception Policy for which this row shows statistics.
Document ID: RDWR-AD-V021403-UG0211
419
AppDirector Guide Advanced Capabilities
Compression URL- Exceptions Rule-List per Rule From the Performance menu, select Acceleration > Compression > URL- Exceptions > RuleList per Rule Statistics. The Compression URL-Exceptions Rule-List per Rule Statistics window is displayed.
Parameter
Description
Rule List Name
There are multiple rule-lists. Each Rule-List is a “policy” that contains multiple rules.
Rule Name
Name of each rule in the Rule-List used to identify it.
Rule Priority
Location of the rule in the Rule-List. Since Rule-Lists are scanned for a match from top (priority 1) to bottom (priority ~65000) this enables to set the location of the rule in the rule-list. See Leveraging Rule List Behavior, page 219on how to use the priority efficiently.
Matched Objects
Number of objects matched by this rule during measuring period.
Size Before Compression
Total size of all matched objects before compression.
Size After Compression
Total size of all matched objects after compression.
Compression Percentage
Compression percentage per rule.
Notes: >> You can use URL files to specify folders or file types to be compressed or not compressed. You can do this by entering a string in the URL filed containing only the file extension or folder name. >> If these strings appear elsewhere in the URL, they will also be matched.
Compression Browser-Exceptions Rule-Lists From the Performance menu, select Acceleration > Compression > Browser - Exceptions > Rule-Lists Statistics. The Compression Browser-Exceptions Rule-Lists Statistics window is displayed.
Parameter
Description
Name
Name of Compression’s URL Exception Policy for which this row shows statistics.
Matched Objects
Number of objects matched during measuring period by the URL Exception Policy for which this row shows statistics.
Size Before Compression
Total uncompressed size of objects matched during measuring period by the URL Exception Policy for which this row shows statistics.
Size After Compression
Total compressed size of objects matched during measuring period by the URL Exception Policy for which this row shows statistics.
Compression Browser-Exceptions Rule-List per Rule From the Performance menu, select Acceleration > Compression > Browser- Exceptions > Rule-List per Rule Statistics. The Compression Browser-Exceptions Rule-List per Rule Statistics window is displayed.
Parameter
Description
Rule List Name
There are multiple rule-lists. Each Rule-List is a “policy” that contains multiple rules.
420
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Advanced Capabilities Rule Name
Name of each rule in the Rule-List used to identify it.
Rule Priority
Location of the rule in the Rule-List. Since Rule-Lists are scanned for a match from top (priority 1) to bottom (priority ~65000) this enables to set the location of the rule in the rule-list. See Leveraging Rule List Behavior, page 219 on how to use the priority efficiently.
Matched Objects
Number of objects matched by this rule during measuring period.
Size Before Compression
Total uncompressed size of all objects matched by this rule.
Size After Compression
Total compressed size of all objects matched by this rule.
Compression Percentage
Percentage of compressed and uncompressed size of all objects matched by this rule.
Configuration 1. From the Performance menu, select Acceleration > Compression > Configuration. The Acceleration Engine Configuration window is displayed.
Parameter
Description
Statistics measuring period (Sec)
Defines time period in which values are being collected. Data always shows results of previous measuring period. All measuring and statistics are performed within a defined timeframe. This parameter allows controlling this time frame. Since numbers are updated at the end of every measuring period, a longer period will give better Averages results but will lower the ability to see real time monitoring values. Default: 5 seconds.
WBM Statistics display auto- Defined the period after which the WBM display will automatically refresh (Sec) refresh to show recently measured values. 2. Click Set. Your configuration is set.
Document ID: RDWR-AD-V021403-UG0211
421
AppDirector Guide Advanced Capabilities
Bandwidth Management Statistics The following are relevant when running a Bandwidth Management policy.
Policy Statistics Global Parameters Status You can enable or disable the monitoring of policy statistics and adjust the monitoring period, using the Policy Statistics Global Parameters window.
To configure Policy Statistics Global Parameters 1.
From the Performance menu, select BWM Policy Statistics Global Parameters. The Policy Statistics Global Parameters window is displayed.
Parameter
Description
Statistics measuring period (Sec)
Defines the time period in which values are being collected. Presented data always shows results of previous measuring period. All measuring and statistics are performed within a defined timeframe. This parameter allows controlling this time frame. Since numbers are updated at the end of every measuring period, a longer period will give better Averages results but will lower the ability to see real time monitoring values. Default: 5 seconds.
WBM Statistics display Defined the period after which the WBM display will automatically auto-refresh (Sec) refresh to show recently measured values. 2.
3.
422
Set the parameters.
Parameter
Description
Policy Statistics Monitoring
Enables or disables (default) the monitoring of policy statistics by the device.
Policy Statistics Reporting Period
Amount of time, in seconds, that policy statistics should be monitored.
SRP
Enables or disables (default) SRP.
Default: 60
Click Set. Your preferences are recorded.
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Advanced Capabilities
Last Second Statistics The Policy Statistics window enables you to view the policy statistics.
Note: To view this table, Application Servers Statistics, page 430 must be enabled.
To view Policy Statistics for the last second From the Performance menu, select BWM Policy Statistics > Last Second Statistics. The Policy Statistics Table window is displayed with the following parameters.
Parameter
Description
Policy Name
The name of the displayed policy.
Packets (sec)
The number of packets matching the policy during the last second.
Matched BW (Kbits)
The amount of matched bandwidth.
Sent BW (Kbits)
The amount of bandwidth sent during the last second.
Last Period Statistics
To view Policy Statistics for the last period 1. From the Performance menu, select BWM Policy Statistics > Last Period Statistics. The Policy Statistics Table window is displayed, which contains the following parameters. 2. Select the name of a specific Policy. The Policy Statistics Table window is displayed, which contains the following read-only parameters.
Parameter
Description
Policy Name
The name of the displayed policy.
Packets (sec)
The number of packets matching the policy during the last period.
Matched BW (Kbits)
The amount of matched bandwidth.
Sent BW (Kbits)
The amount of bandwidth sent during the last period.
Document ID: RDWR-AD-V021403-UG0211
423
AppDirector Guide Advanced Capabilities
Element Statistics Element statistics contains several indicators for viewing AppDirector performance. They include: •
IP Packet Statistics, page 424
•
SNMP Packet Statistics, page 425
•
IP Router Statistics, page 426
•
OSPF Packet Statistics, page 427
•
Resource Utilization Statistics, page 428
IP Packet Statistics The IP Packets Statistics window allows you to view statistics for the IP elements of the device.
To view IP Packet statistics From the Performance menu, select Element Statistics > IP. The IP Packets Statistics window is displayed.
Parameter
Description
IP Receives
Total number of input datagrams received from interfaces, including those received in error.
IP Header Errors
Number of input datagrams discarded due to header error due to errors in their IP headers, including bad checksums, version number mismatch, other format errors, time-to-live exceeded, errors discovered in processing their IP options, etc.
IP Discarded
Total number of input datagrams discarded. Note: This counter does not include any datagrams discarded while awaiting re-assembly.
IP Successfully Delivered
Total number of input datagrams successfully delivered to IP protocols (including ICMP).
IP Out Requests
Total number of IP datagrams, which local IP -protocols (including ICMP) supplied to IP in requests for transmission.
IP Out Discard
Number of output IP datagrams for which no problem was encountered to prevent their transmission to their destination, but which were discarded (e.g., for lack of buffer space).
424
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Advanced Capabilities
SNMP Packet Statistics The SNMP Packet Statistics window enables you to view statistics for the device’s SNMP elements.
To view SNMP packet statistics From the Performance menu select Element Statistics > SNMP. The SNMP Packets Statistics window is displayed. .
Parameter
Description
SNMP Received Packets Total number of messages delivered to the SNMP entity from the transport service. SNMP Sent Packets
Total number of SNMP messages ed from the SNMP protocol entity to the transport service.
SNMP Successful 'Get' Requests
Total number of MIB objects retrieved successfully by the SNMP protocol entity as the result of receiving valid SNMP Get-Request and Get-Next PDUs.
SNMP Successful 'Set' Requests
Total number of MIB objects altered successfully by the SNMP protocol entity as the result of receiving valid SNMP Set-Request PDUs.
SNMP 'Get' Requests
Total number of SNMP Get-Request PDUs processed PDUs accepted and processed by the SNMP protocol entity.
SNMP 'Get-next' Requests
Total number of SNMP Get-Request PDUs accepted and processed by the SNMP protocol entity.
SNMP 'Set' Requests
Total number of SNMP Set-Request PDUs accepted and processed by the SNMP protocol entity.
SNMP Out 'TooBig'
Total number of SNMP PDUs generated by the SNMP protocol entity and for which the value of the error-status field is 'tooBig.'
SNMP Out 'NoSuchName'
Total number of SNMP PDUs generated by the SNMP protocol entity and for which the value of the error-status is 'noSuchName.'
SNMP Out 'BadValue'
Total number of SNMP PDUs generated by the SNMP protocol entity and for which the value of the error-status field is 'badValue.'
SNMP Out 'GenErrs'
Total number of SNMP PDUs generated by the SNMP protocol entity and for which the value of the error-status field is 'genErr.'
SNMP Out 'GetResponses'
Total number of SNMP Get-Response PDUs generated by the SNMP protocol entity.
SNMP Out Traps
Total number of SNMP Trap PDUs generated by the SNMP protocol entity.
Document ID: RDWR-AD-V021403-UG0211
425
AppDirector Guide Advanced Capabilities
IP Router Statistics The IP Router Statistics window allows you to view statistics for the IP Router elements of the device.
To view IP Router statistics From the Performance menu select Element Statistics > IP Router. The IP Router Statistics window is displayed and contains these read-only parameters:
Parameter
Description
IP Forwarded
Number of input datagrams for which this entity was not their final IP destination, as a result of which an attempt was made to find a route to forward them to that final destination. In entities, which do not act as IP Gateways, this counter will include only those packets that were Source - Routed via this entity, and the Source - Route option processing was successful.
IP Unknown Protocol
Number of locally-addressed datagrams received successfully but discarded because of an unknown or uned protocol.
IP Out No Routes
Number of IP datagrams discarded because no route could be found to transmit them to their destination. This counter includes packets counted in ipForwDatagrams which meet this `no-route' criterion. Notes: • This includes datagrams, which a host cannot route as all its default gateways are down. • This counter includes any packets counted in ipForwDatagrams, which meet the `no-route' criterion. It also includes datagrams that cannot be routed as all its default gateways are down.
IP Fragments Received
Number of IP fragments received which needed to be reassembled at this entity.
IP Fragments Successfully Number of IP datagrams successfully re-assembled. Re-assembled IP Fragments Failed Reassembly
Number of failures detected by IP re-assembly algorithm (reason: timed out, errors, etc). Note: This is not necessarily a count of discarded IP fragments since some algorithms (notably the algorithm in RFC 815) can lose track of the number of fragments by combining them when received.
IP Datagrams Successfully Number of IP datagrams successfully fragmented at this entity. Fragmented IP Datagrams Discarded Failed Fragmentation
Number of IP datagrams discarded because they needed to be fragmented at this entity but could not be, e.g., because their Don't Fragment flag was set.
IP Datagram Fragments Generated
Number of IP datagram fragments generated as a result of fragmentation at this entity.
IP Datagram Fragments Generated
Number of IP datagram fragments generated as a result of fragmentation at this entity.
Valid Routing Entries Discarded
Number of valid routing entries discarded.
426
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Advanced Capabilities
Parameter
Description
RIP - Changes Made to IP Route Database
Number of changes made to the IP Route Database by RIP.
RIP - Global Responses Sent to RIP Queries
Number of responses sent to RIP queries from other systems.
OSPF Packet Statistics Open Shortest Path First (OSPF) is an interior gateway routing protocol developed for IP networks. OSPF is based on the shortest path first or link-state algorithm. Routers use link-state algorithms to send routing information to all nodes in a network by calculating the shortest path to each node, based on a topography of the internet constructed by each node. After sending the routing information, each router sends the portion of the Routing Table (keeps track of routers to particular network destinations) that describes the state of its own links, and the complete routing structure (topography). Shortest path first algorithms allow for more frequent updates. With OSPF, you can build a more stable network as fast convergence prevents such problems as routing loops and Count-to-Infinity (when routers continuously increment the hop count to a particular network). The OSPF Packet Statistics window allows you to view statistics for the OSPF packet statistics elements of the device.
To view OSPF packet statistics From the Performance menu select Element Statistics > OSPF. The OSPF Packet Statistics window is displayed, which contains the following read-only parameters.:
Parameter
Description
OSPF - New LSAs originated
Reports the number of originating OSPF link-state ments in the link-state database.
OSPF - LSAs received - The number of link-state ments received that are determined to new instantiations be new instantiations. This number does not include newer instantiations of self-originated link-state ments
Document ID: RDWR-AD-V021403-UG0211
427
AppDirector Guide Advanced Capabilities
Resource Utilization Statistics The Resource Utilization window allows you to view statistics on for the device's average resource utilization.
To view resource utilization statistics From the Performance menu, select Element Statistics > Resources. The Resource Utilization window is displayed, which contains the following read-only parameters:
Parameter
Description
Resource Utilization
Percent of device's U currently utilized.
RS Resource Utilization
Percent of device's RS resource currently utilized.
RE Resource Utilization
Percent of device's RE resource currently utilized.
Last 5 sec. Average Utilization
Average resources utilization in the last 5 seconds.
Last 60 sec. Average Utilization
Average resources utilization in the last 60 seconds.
Acceleration-Engine Cores These statistics measure U utilization per accelerator.
Enhanced Acceleration
Parameter
Description
Accel-Engine System Total Percentage of Acceleration engine RAM allocated for cache occupied on Memory measuring time. Also see Caching Policies, page 220. Values: 1 - 50% Default: 20% Acceleration-Engine id 1
% U Utilization per accelerator
Acceleration-Engine id 2
% U Utilization per accelerator
Acceleration-Engine id 3
% U Utilization per accelerator
IP Interface Statistics The IP Interface Statistics window allows you to monitor the number of packets discarded and ignored, enabling you to quickly summarize the state of network congestion from a given interface.
To view IP statistics 1.
From the Performance menu select; IP Statistics. The IP Statistics window is displayed.
2.
Select the desired interface entry. The IP Statistics Update window is displayed.
428
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Advanced Capabilities 3. Set the parameters.
Parameter
Description
Interface Address
IP address of the selected interface.
RIP - Response Packets Number of RIP responses received by RIP process which were Discarded subsequently discarded for any reason. Discard Examples: • version 0 packet • unknown command type • packet was smaller than the minimum size allowed for IPRIP packets. • received a packet with an invalid version in its header. • received a packet with an invalid header. • discarded a response packet from a neighbor with IP address: %1. IPRIPv2 is not configured to accept packets from this neighbor. • discarded a version: %1 packet received on the interface with IP address: %2 from a neighbor with IP address: %3. The above interface is configured to accept only version: %4 packets. • discarded a packet received on the interface with IP address: %1 from a neighboring router with IP address: %2, because the packet failed authentication. • discarded a response packet from a neighbor with IP address: %1. The packet was not sent from the standard IP RIP port (520). RIP - Routes Ignored
Number of routes, in valid RIP packets, ignored for any reason. Ignore Examples: • unknown address family. • invalid metric. • discontiguous networks (major nets separating other major nets). • new route is inferior to previous one prior to update. • certain RIP implementations set up to ignore host routes. • response did not originate from a RIP port.
RIP - Updates Sent
Number of triggered RIP updates sent on this interface. This explicitly does NOT include full updates sent containing new information.
4. Click Set. The status is changed.
Document ID: RDWR-AD-V021403-UG0211
429
AppDirector Guide Advanced Capabilities
Servers As part of AppDirector’s toolset, you can monitor server performance including server status, traffic load and numbers of connections and disconnections.
Application Servers Statistics The Application Server Statistics window allows you to view performance statistics of the application servers.
To monitor application server statistics 1.
From the Performance menu, select Server > Application Server Statistics. The Application Server Statistics window is displayed.
2.
From the Farm drop down list, select the farm for which you want to present the servers summary. The Application Servers Summary table displays the following read-only statistics:
Parameter
Description
Status
The status of the farm/server: • Active — The farm/the server is up and running. A farm is active when it has at least one server up and running. • No New Sessions — No new sessions can be forwarded to the farm/server due to overload. • Not in Service — This farm/server is not available. A farm is not available when all its servers are Not In Service.
Farm/Server
Name of farm/server, (click the farm or server name to read the confirmation go to the respective farm/server configuration window).
Kbits
Amount of traffic in kbits forwarded to/from the farm/server in the last second.
Packets
Amount of packets forwarded to/from the farm/server in the last second.
Connections
Number of concurrent connections established with the farm/server. • Current — displays the current number of concurrent connections active on the farm/server. • Peak — displays the maximum number of concurrent connections active on the farm/server since device reboot or statistics reset. • Total — displays the total number of all connections that were opened to the farm/server since device reboot or statistics reset.
430
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Advanced Capabilities
Parameter
Description
T Disconnections
Number of disconnections in the T sessions established with the farm/server. • Current — displays the number of T connections to the farm/ server terminated during the last second. • Peak — displays the maximum number of T connections to the farm/server terminated per second since device reboot or statistics reset. • Total — displays the total number of T connections to the farm/server terminated since device reboot or statistics reset.
New T Connections
Number of T connections with the farm/server. • Current — displays the number of new T connections opened to the farm/server during the last second. • Peak — displays the maximum number of T connections per second opened to the farm/server since device reboot or statistics reset. • Total — displays the total number of T connections opened to the farm/server since device reboot or statistics reset.
3. To define the frequency in which the summary is refreshed, in the Refresh Interval text box, type the number of seconds and click Set. 4. To reset statistics, click Set.
Physical Servers Statistics The Physical Server Statistics window allows you to view performance statistics of the physical servers.
To monitor physical server statistics 1. From the Performance menu, select Server > Physical Server Statistics. The Physical Server Statistics window is displayed. 2. The Physical Servers Summary table displays these read-only statistics.
Parameter
Description
Status
The status of the farm or server: • Active: the server is up and running • No New Sessions: No new sessions can be forwarded to the farm/ server. • Not in Service: This server is not available.
Physical Server
Name of farm or server, (click the farm or server name to read the confirmation window).
Kbits
Amount of traffic in kbits forwarded to or from farm or server.
Packets
Amount of packets forwarded to or from farm or server.
Connections
Number of connections established with the farm or server.
Document ID: RDWR-AD-V021403-UG0211
431
AppDirector Guide Advanced Capabilities
Parameter
Description
T Disconnections Number of disconnections in the T sessions established with the farm or server. New T Connections
Number of T connections established with the farm or server.
Note: Incoming connections are those accepted by the server. Outgoing connections are those initiated by the server. 3.
To define the frequency in which the summary is refreshed, in the Refresh Interval text box, type the number of seconds and click Set.
4.
To reset statistics, click Set.
AppDirector Statistics The AppDirector statistics window enables you to monitor specific AppDirector elements providing you with a picture of how well AppDirector is performing using measures of Client table and Proximity table fillup or Redundancy failure.
To monitor AppDirector statistics From the Performance menu, select AppDirector Statistics. The AppDirector Statistics window is displayed, which contains the following read-only parameters:
Parameter
Description
Redundancy Failure
Indicates that the AppDirector failed.
Redundancy Takeover
Indicates that the AppDirector failed.
Client Table Fillup
Indicates that the client table filled up.
Proximity Table Fillup
Indicates how many times the proximity redirection method was reached.
DNS Request (last second)
Number of DNS queries received in last second
DNS Replies (last second)
Number of DNS queries answered in last second.
432
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Advanced Capabilities
T Splitting Statistics
Standard Acceleration T Splitting is the ability to maintain open concurrent connections opposite all servers providing Diameter or LDAP services, while a single connection was opened by the client. The T Splitting Statistics window allows you to view performance statistics of the T distribution process for each AppXcel Front-End farm and its servers.
To monitor T Splitting Statistics 1. From the Performance menu, select T Splitting Statistics. The T Splitting Statistics window is displayed. 2. From the Farm drop down list, select the farm for which you want to present the T splitting summary. The T Splitting Summary table displays the following read-only statistics:
Parameter
Description
Refresh Interval
How often the data is automatically refreshed. Default: 60 seconds.
Update
Click to refresh the display.
Reset
Click to reset the statistics to zero.
For each physical server, the following information is displayed:
Note: C = Current, P = Peak, T = Total
Parameter
Description
Status
Status of the farm or server. One of the following: • Active. For a farm, all servers in the farm are active. • No New Sessions (NNS). For a farm, none of the servers have new sessions. • Not In Service (NIS). For a farm, no servers in the farm are in service. • In a farm, at least one server is NIS or NNS
Farm/Server Kbits
Name of the farm or server In
Out Packets
In
Out
Number of Kilo-bits received by the server since the Reset button was last pressed. Number of Kilo-bits transmitted by the server since the Reset button was last pressed. Number of packets received by the server since the Reset button was last pressed. Number of packets transmitted by the server since the Reset button was last pressed.
Document ID: RDWR-AD-V021403-UG0211
433
AppDirector Guide Advanced Capabilities
Parameter
Description
Connections
C
Current number of inbound connections (the number of client table entries with type Regular).
P
Peak number of inbound connections (the number of client table entries with type Regular) since the Reset button was last pressed.
T
Total number of inbound connections (the number of client table entries with type Regular) since the Reset button was last pressed.
T Connections C
New T Connections
Application Connections
Number of T connections to the server that were terminated during the last second.
P
Peak number of T connections to the server that were terminated during one second since the Reset button was last pressed.
T
Total number of T connections to the server that were terminated since the Reset button was last pressed.
C
Number of new T connections that were opened to the server during the last second.
P
Peak number of new T connections that were opened to the server during one second since the Reset button was last pressed.
T
Total number of new T connections that were opened to the server since the Reset button was last pressed.
C
Number of application handshakes that the AppXcel device counted during the last 5 seconds. • LDAP: the number of bind messages • Diameter: the number of CER messages
Application Disconnections
P
Peak number of application handshakes that the AppXcel device counted.
T
Total number of application handshakes that the AppXcel device counted.
C
Number of application messages that terminated the connection during the last 5 seconds. • LDAP: the number of unbind messages • Diameter: the number of DPR (Disconnect Peer Request) messages
Application Request
Application Failure
P
Peak number of application messages that terminated the connection.
T
Total number of application messages that terminated the connection.
C
Number of application messages forwarded and load-balanced by the AppXcel device between all servers during the last 5 seconds. Note: Not including handshake and disconnection messages.
P
Peak number of application messages forwarded and load-balanced by the AppXcel device during one second between all servers.
T
Total number of application messages forwarded and load-balanced by the AppXcel device between all servers.
C
Number of application messages with errors (indicated by a field in the message) during the last 5 seconds.
P
Peak number of application messages with errors during one second.
T
Total number of application messages with errors.
3.
To define the frequency in which the summary is refreshed, in the Refresh Interval text box, type the number of seconds and click Set.
4.
To reset statistics, click Set. Your configuration is set.
434
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Advanced Capabilities
Protocol Statistics You can display complete protocol statistics information using this feature. If enabled, Protocol Discovery classification is performed only on traffic to or from the configured default gateway.
Protocol Statistics Global Parameters You can configure the global parameters of protocol statistics using the Protocol Statistics Global Parameters window.
To configure Protocol Statistics Global Parameters 1. From the Performance menu, select Protocol Statistics > Global Parameters. The Protocol Statistics Global Parameters window is displayed 2. Set the parameters
Parameter
Description
Status
This variable indicates whether the device will gather protocols' statistics Default: Enable or Disable
Protocol Statistics Reporting Period [secs.]
Amount of time that protocol statistics should be monitored.
SRP Destination Address
IP Address of the SRP. The statistics will be sent to this address in SRP mode.
Default: 60
Default: 0.0.0.0 SRP
Configures the protocol statistics reporting operation Values: Enables or disables (default) SRP.
Protocol Statistics Aging
Period in which table entries are kept until removed. Default: Entries Lifetime
3. Click Set. Your configuration is set.
Protocol Discovery Policies You need to be aware of the different applications running on your network and the amount of bandwidth they consume. To allow a full view of the different protocols running on the network there is a protocol discovery feature that can be activated on the entire network or on separate subnetworks by defining Protocol Discovery policies in the Protocol Discovery Policies window.
To set the Protocol Discovery Policies 1. From the Performance menu select, Protocol Statistics > Protocol Discovery Policies. The Protocol Discovery Policies window is displayed. 2. Click Create. The Protocol Discovery Policies Create window is displayed.
Document ID: RDWR-AD-V021403-UG0211
435
AppDirector Guide Advanced Capabilities 3.
Set the parameters.
Parameter
Description
Name
-defined name of the policy.
Index
Location of policy in protection table that reflects the order in which the classification is performed.
Destination
Defines destination of the traffic. Can be specific IPs, or a range of IP addresses or IP Subnet address. Default is “any” which covers traffic to any destination.
Source
Defines source of traffic. Can be specific IPs, or a range of IP addresses or IP Subnet address. Default is “any” which covers traffic from any source.
Destination MAC Address Group
Enables you to discover applications and protocols present in traffic sent to a transparent network device. Default: None
Source MAC Address Enables you to discover applications and protocols present in the traffic Group sent by a transparent network device (firewall, router). Default: None Inbound Physical Port Group
Classifies only traffic received on certain interfaces of the device. Enables you to set different policies to identical traffic classes received on different interfaces of the device. Default: None
VLAN Tag Group
Defines VLAN traffic classification according to VLAN ID (VLAN Identifier) tags. Default: None
Direction
Defines the direction of the traffic. Values One Way (from Source to Destination) /Two Way (Default)
Operational Status
Select either Active (Default) or Inactive.
Classification Point
Indicates whether classification is done before or after packet modification. • After Changes (Default): Classifies the device after the packet changes. • Before Changes: Classifies the device before the packet changes.
4.
436
Click Set. Your configuration is set.
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Advanced Capabilities
View Protocol Statistics The Protocol Statistics Table window enables you to view the protocol statistics.
Note: To view this table, Protocol Statistics Monitoring must be enabled. See Protocol Statistics Global Parameters, page 435.
To view the Protocol Statistics Table From the Statistics menu, select Protocol Statistics and then choose View Protocol Statistics. The Protocol Statistics Table window is displayed, which contains the following parameters:
Parameter
Description
Policy Name
Name of the policy.
Protocol
IP protocol.
Port
T or UDP port used by the protocol.
Bandwidth
Total bandwidth per second used for this protocol during the last period.
Peak Bandwidth
Peak bandwidth per second used for this protocol during the last period.
Packets
Total number of packets per second used for this protocol during the last period.
Statistics Monitor This section shows you how to configure and send statistics to or from the Statistics Monitor.
Statistics Monitor SRP The SRP Management Host IP Address window is used to create statistics files on a remote machine.
To send statistics from/to the Statistics Monitor 1. From the Services menu, select Statistics Monitor > SRP. The SRP Management Host IP Address window is displayed. 2. Type the SRP Management Host IP Address: The IP address of the machine where to create the statistics files. This is normally the machine where either the web-based software is running. 3. Click Set. The statistics are sent to the statistics monitor.
Document ID: RDWR-AD-V021403-UG0211
437
AppDirector Guide Advanced Capabilities
Statistics Monitor Configuration The Statistics Monitor window is used to create statistics files on a remote machine.
To send statistics from the AppDirector to the Statistics Monitor 1.
From the Services menu, select Statistics Monitor > Configuration. The Statistics Monitor Configuration window is displayed.
2.
Set the parameters.
Parameter
Description
Statistic Reporting Mode
Enables or disables the creation of statistics files. You can choose what kind of statistics to broadcast: • Full: Broadcasts all statistics • Disable (Default): Disables broadcasting • Flow: Broadcasts statistics concerning flow • Health: Broadcasts statistics concerning health
Flow Statistics Polling How often, in minutes and seconds, to update the statistics file with Time [sec] new flow rate data. The file is cumulative, and new data is added to existing data. Health Statistics Polling Time [sec]
3.
How often, in minutes and seconds, to update the statistics file with new health data. The file is cumulative, and new data is added to existing data.
Click Set. Your configuration is set.
Note: Since the statistics files are cumulative, you must ensure that you disable the Statistic Reporting Mode before you create files larger than you desire. Failure to do so can result in creating files that fill all available memory.
438
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Advanced Capabilities
Utilities This section contains additional device-related AppDirector utilities and includes these topics: •
DNS Client, page 439
•
Time Settings, page 440
•
Event Scheduler, page 442
DNS Client You can configure AppDirector to operate as a DNS client. When the DNS client is disabled, IP addresses cannot be resolved. When the DNS client is enabled, you need to configure servers for which AppDirector will send out queries for host name resolving. You can set the Domain Name Service parameters in the DNS Client Parameters window. You can define the primary and the alternate DNS servers for dynamic DNS. In addition you can set static DNS parameters.
To define DNS servers 1. From the Services menu, select DNS. The DNS Client Parameters window is displayed. with parameters shown below.
Parameter DNS Client
Description Status of DNS Client. Enabled or Disabled (default) DNS client functionality.
Primary DNS Server
The primary DNS server address that should be used by the device for DNS
Alternate DNS Server
The alternate DNS server address that should be used by the device for DNS
2. To define the primary DNS server, in the Primary DNS server box type the IP address of the primary DNS server and click Set. 3. To define the alternate DNS server, in the Alternate DNS server box type the IP address of the alternate DNS server and click Set.
Note: Primary and alternate DNS server addresses contain the default value 0.0.0.0. If you decide to delete primary or secondary DNS server addresses, which are already configured with a different value, you can reset them back to this default value - 0.0.0.0
To set static DNS 1. From the Services menu, select DNS. The DNS Client Parameters window is displayed. 2. Click Create. The Static DNS Table Create window is displayed
Document ID: RDWR-AD-V021403-UG0211
439
AppDirector Guide Advanced Capabilities 3.
4.
Set the parameters.
Parameter
Description
Host Name
Domain name for the specified IP address.
IP Address
IP address for the specified domain name.
Click Set.Your configuration is set.
Time Settings This collection of utilities helps you to synchronize and configure devices for appropriate daylight saving periods. Utilities included are: •
Configuring Network Time Protocol, page 440.
•
Daylight Saving, page 440.
•
Date and Time, page 442.
Configuring Network Time Protocol Network Time Protocol (NTP) enables s 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 returns the date and time to the device. Enabling or disabling the NTP feature results in different levels of accuracy. When NTP is disabled, the device’s time and date have to be set manually. 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 define the NTP parameters 1.
From the Services menu select Time Settings > NTP. The Network Time window is displayed
2.
Set the parameters.
3.
Parameter
Description
NTP Server
IP address of the NTP server.
NTP Polling Interval [sec]
Amount of time between sending of requests to the NTP server.
NTP Time Zone
Time zone in which the device is located, in correlation to GMT (12:00 to + 12:00 hours).
NTP Server Port
Access port number for the NTP server.
NTP Status
Status of NTP function, either Enable or Disable (Default). When this feature is disabled the time and date must be set manually.
Click Set. Your configuration is set.
Daylight Saving Radware devices daylight saving time. You need to configure the start and end date of the daylight saving time. 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.
440
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Advanced Capabilities
To configure the Daylight Saving hours 1. From the Services menu, select Time Settings > Daylight Saving. The Daylight Saving window is displayed with the following parameters: 2. Set the parameters.
Parameter
Description
Daylight Saving Status
Enables and disables (default) Daylight Saving feature.
Daylight Saving States the Daylight Saving Designation zone Designations (Readonly) Starts [dd/mm:hh]
Click the dotted icon alongside. A pop-up is displayed. Enter the date and time from which Daylight Saving starts with the following parameters: • Mode: Date - an absolute date to configure OR • Recurring: - if it is the same instance for start or/and end (e.g. DST always starts on the 1st Sunday in April) • Month: January-December • Day: 1-31 • Hour:0-22
Start Date and Time Shows the Start date and time in full as follows e.g. TUE JUL 01 02:00:00 (Read Only) 2007. Ends [dd/mm:hh]
Click the dotted icon alongside. A pop-up is displayed. Enter the date and time when Daylight Saving ends as follows: • Mode: Date - an absolute date to configure OR • Recurring: - if it is the same instance for start or/and end (e.g. DST always starts on the 1st Sunday in April) • Month: January-December • Day: 1-31 • Hour:1-23
End Date and Time (Read Only)
Shows the End date and time in full as follows e.g. TUE JAN 01 02:00:00 2008.
Delta
Difference between Daylight Savings Time and Standard Time Setting. The number of hours by which the clock is to be adjusted is configurable using the Delta parameter. Default: 1 hour
3. Click Set. Your configuration is set.
Document ID: RDWR-AD-V021403-UG0211
441
AppDirector Guide Advanced Capabilities
Date and Time
To configure the Date and Time 1.
From the Services menu, select Time Settings > Date and Time. The Daylight Saving System date and Time window is displayed with the following parameters.
2.
Set the parameters according to the explanations providedparameters.
3.
Parameter
Description
System Time [hh:mm:ss]
Manages the device's system time, in the format hh:mm:ss.
System Date [dd/mm/yyyy]
Manages the device's system date, in the format dd/mm/yyyy.
Click Set. Your configuration is set.
Event Scheduler
Standard Acceleration Some network policies remain inactive during specific hours of the day and are activated during others. For example, an enterprise may give high priority to mail traffic between 08:00 - 10:00. Sometimes within networks we need specific policies to remain inactive during certain hours of the day, or for a certain policy to be activated in the middle of the night. 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. You can schedule the activation and inactivation of specific Bandwidth Management policies using the Event Scheduler, which can then be attached to a policy's configurations. Events define the date and time in which an action must be performed.
To configure the Event Scheduler 1.
From the Services menu, select Event Scheduler. The Event Scheduler window is displayed.
2.
Click Create. The Event Scheduler Create window is displayed.
3.
Set the parameters.
Parameter
Description
Name
A defined name for the event.
Frequency
Defines the event frequency, whether it occurs once, daily or weekly.
Time (hh:mm)
The time on the designated day. Note: If multiple days are selected, then the "Time" value is the same for all the configured days in which the event occurs. Default: 12:00 am (0000).
442
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Advanced Capabilities
Parameter
Description
Days
If Weekly Frequency is selected, you must configure where day the event occurs.
Date (dd/mm/yyyy)
If Frequency selected is once, then you need to configure the date where the event occurs.
4. Click Set. Your configuration is set.
Document ID: RDWR-AD-V021403-UG0211
443
AppDirector Guide Advanced Capabilities
444
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security
Chapter 8 – Security This chapter discusses Security modules and sub-modules, and contains these sections: •
AppDirector Device Security, page 445
•
Keys and Certificates, page 450
•
Application Security, page 456
AppDirector Device Security This section describes AppDirector device security interfaces and methods and includes these topics: •
Management Ports (Setting Physical Management Ports Restrictions), page 445
•
Ports Access, page 446
•
Table and Authentication, page 446
Caution: All Radware devices include security features and settings that help prevent unauthorized access and unit tampering.
Management Ports (Setting Physical Management Ports Restrictions) On AppDirector devices, network traffic to the management port is fully isolated from traffic ports and therefore no network traffic is forwarded between management and traffic ports. Radware devices provide a packet-filtering database, which can be configured to control access to and through the unit, based on various factors, e.g. protocol, port, and source or destination addresses. Access to devices can be limited to specified physical interfaces. Interfaces connected to insecure network segments can be configured to discard some or all management traffic directed at the device itself. s can allow certain types of management traffic to a device (for example; SSH), while denying others such as SNMP. If an intruder attempts to access the device through a disabled port, the Radware unit denies access, and generates syslog and CLI traps as notification. This option enables you to define the permissible management ports using WBM and Telnet.
To configure the Management Ports 1. From the Security menu, select Management Ports. The Management Ports Table window appears. 2. Select a Port. The Management Ports Table Update window appears. 3. Set the parameters.
Parameter
Description
Port Number
Displays the ID number of each physical port.
SNMP
Displays access permission for SNMP configuration for each management port. Values: Enable (Default) or Disable.
Document ID: RDWR-AD-V021403-UG0211
445
AppDirector Guide Security
Parameter
Description
Telnet
Displays access permission for Telnet configuration for each management port. Values: Enable (Default) or Disable.
SSH
Displays access permission for SSH configuration for each management port. Values: Enable (Default) or Disable.
SSL
Displays access permission for SSL configuration for each management port. Values: Enable (Default) or Disable.
Web
Displays access permission for Web Based configuration for each management port. Values: Enable (Default) or Disable.
4.
Select the state from the dropdown lists, Enable or Disable, for each management option.
5.
Click Set. Your configuration is set.
Ports Access You can 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 the interfaces of the device allow pings.
To configure physical ports to allow ping 1.
From the Security menu, select Ports Access. The Ports Access window appears.
2.
Select a Port Number link. The Ping Ports Access Update window appears.
3.
In the Ping Device field, select Enabled or Disabled.
Parameter
Description
Port Number
Displays the ID number of each physical port.
Ping State
• Enabled (default) - accept Ping operations on the physical port. • Disabled - ignore Ping operations on the physical port.
4.
Click Set. The configuration is updated.
Table and Authentication This feature enables you to define additional s to access via Telnet, SSH and Web services (Webbased management and SOAP). This option is protected with an individual configurable for each , and also may be configured to alert the to errors in the system via e-mail. Up to 20 s can be defined.
446
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security
To configure the method of authenticating the 's access 1. From the Security menu, select s. The Table and Authentication window appears. 2. Set the parameters.
Parameter
Description
Authentication Method
Method of authenticating a 's access to configuration tool. • Local Table (Default): Device uses the Table to authenticate access. • Radius and Local Table: Device uses Radius server(s) to authenticate access. If request to Radius server is timed out, then the device uses the Table to authenticate access. Note: At least one with read-write access level must be configured in the local Table, to enable device access, even if RADIUS servers are unavailable.
3. Select the appropriate Authentication Method and click Set. The Authentication Method is set.
To configure the s Table 1. From the Security menu, select s. The Table and Authentication window appears. 2. Click Create. The Table Create window appears. 3. Set the parameters.
Parameter
Description
Name
The name of the .
The text for this .
The e-mail address for this
Severity
Level of warning required by . Options are as follows: • None (Default): AppDirector will not send warning messages to . • Fatal: AppDirector sends only Fatal messages to . • Error: AppDirector sends Fatal and Error messages to . • Warning: AppDirector sends Fatal, Error, Warning messages to . • Info: AppDirector sends Fatal, Error, Warning, Info messages to .
Access Level
Sets the ’s level of access to the WBM and CLI interfaces. Values: Read-Write, Read-Only, None.
Document ID: RDWR-AD-V021403-UG0211
447
AppDirector Guide Security
Parameter
Description
SSH Public Key Name
Select from the drop-down list, the name of the SSH public key relevant for this . This is the name of the certificate table entry where the SSH public key resides Note: This public key must have been previously imported into AppDirector via the Certificates management capability.
4.
Click Set. Your configuration is set.
RADIUS Authentication RADIUS (Remote Authentication Dial In Service), defined in RFC 2865, is a protocol for remote authentication and ing. RADIUS enables centralized management of authentication data, such as names and s. When a attempts to to a RADIUS client, such as a router, the router send the authentication request to the RADIUS server. The communication between the RADIUS client and the RADIUS server are authenticated and encrypted through the use of a shared secret, which is not transmitted over the network. RADIUS utilizes the MD5 algorithm for secure hashing.
Radware and RADIUS Authentication Radware devices provide additional security by authenticating s accessing the device for management purposes. Before a management session starts, the device can authenticate the with a RADIUS server. These servers determine whether a can access AppDirector management, using CLI, Telnet, SSH, or WBM. If a RADIUS server is not available, then the device uses the Table to authenticate access. Therefore, at least one with a read-write access level must be configured in the local Table, to enable device access, even if RADIUS servers are unavailable. If the remote is successfully authenticated by the authentication server, the device verifies the privileges of the remote and authorizes the appropriate access. For this purpose, AppDirector searches for Service-Type attribute (AVP 6), built into all RADIUS servers, in the Access-Accept response. •
Read-Write () privilege is built into all Radius servers (Service-Type value 6).
•
Read-Only privilege (Service-Type value 255) has to be defined in the RADIUS dictionary.
•
The file name of the dictionary is RADIUS vendor-dependent.
•
Radware private enterprise code is 89.
Table 7: RADIUS dictionary sample:
Attribute
Service-Type
26
[vid=89 type1=26 len1=+1 data=integer] R
Value
Service-Type
Read-Only
255
448
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security
To configure RADIUS authentication 1. From the Services menu, select Management Interfaces > Radius Authentication. The Radius Parameters window appears. 2. Set the parameters.
Parameter
Description
Main RADIUS IP Address
IP address of the primary RADIUS server.
Main RADIUS Port Number
Access port number of the primary Radius server. Access port numbers can be either 1645 (default) or 1812.
Main RADIUS Secret
Authentication for primary RADIUS server.
Backup RADIUS IP Address
IP address of the backup RADIUS server.
Backup RADIUS Port Number
Access port number of the backup Radius server. Access port numbers can be either 1645 (default) or 1812.
Backup RADIUS Secret
Authentication for backup RADIUS server.
RADIUS Timeout
Time that device waits for reply from RADIUS server before a retry, or (if the value RADIUS Retries is exceeded) before the device acknowledges that the server is offline. Default: 5
RADIUS Retries
Number of connection retries to RADIUS server, when the RADIUS server does not respond to first connection attempt. If RADIUS Retries is exceeded, and if all connection attempts fail (RADIUS Timeout), the backup RADIUS server is used. Default: 3
RADIUS Client Life Time
Duration (in seconds) of client's authentication. After RADIUS Client Lifetime expires, the device re-authenticates the . Default: 30
Default Authorization
This defines the access level to be provided to a authenticated by a RADIUS server, but where privileges were not provided (or unknown privileges were provided). Values: • Read-Write (default) • Read-Only • No Access ( is denied access)
3. Click Set. The Radius authentication parameters are configured.
Document ID: RDWR-AD-V021403-UG0211
449
AppDirector Guide Security
Keys and Certificates This section covers keys and certificates management and includes these topics: •
Certificates, page 450
•
Keys, page 450
•
Certificates Workflows, page 450
•
Configuration of Keys and Certificates, page 452
Certificates Certificates are digitally signed indicators which identify the server or . They are usually provided in the form of an electronic key or value. The digital certificate represents the certification of an individual business or organizational public key but can also be used to show the privileges and roles for which the holder has been certified. It also includes information from a third party ing identity. Authentication is needed to ensure that s in a communication or transaction are who they claim to be. A basic certificate includes: •
The certificate holders identity
•
The certificate‘s serial number
•
The certificate holders expiry date
•
A copy of the certificate holder’s public key
•
The identity of the Certificate Authority (CA) and its digital signature to affirm the digital certificate was issued by a valid agency.
Keys A key is a variable set of numbers that the sender applies to decrypted data to produce encrypted data, to be sent via the internet. Usually a pair of public and private keys is used. A private key is kept secret and used, only by its owner, to encrypt and decrypt data. A public key has a wide distribution and is not secret. It is used for encrypting data and for ing signatures. One key is used by the sender to encrypt or interpret the data. The recipient also uses the key to authenticate that the data comes from the sender. The use of keys ensures that unauthorized personnel cannot decipher the data. Only with the appropriate key can the information be easily deciphered or understood. Stolen or copied data would be incomprehensible without the appropriate key to decipher it and prevent forgery. AppDirector s the following key size lengths - 512, 1024 or 2048 bytes.
Certificates Workflows
To create a Certificate g Request (CSR) When a new Certificate is needed, this process should be followed 1.
Create a certificate (see Certificates Table) and select CSR.
2.
Complete the relevant fields (or update the defaults before you start)
3.
Click OK. The Key and CSR are created
4.
Move to the Export Certificates window. Export the CSR to file or Text and send to a Certificate g Authority such as Varisign.
5.
After receiving the signed certificate back from CA, use the Import Certificates window to import it into the CSR and convert it to a Key and a Certificate.
450
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security
To create a Self-Signed Certificate If the certificate does not need to be trusted by s (e.g. lab environment or other internal only cases), AppDirector can create a certificate on its own. 1. Create a Certificate and select Certificate 2. Complete the relevant fields (or update the defaults before you start) 3. Click OK. Key and Certificate are created
To move a Key and Certificate pair from Web server to AppDirector or between AppDirectors (in redundancy configuration) 1. On the 1st AppDirector machine go to Export Certificates window and select Export Key. 2. On the 1st AppDirector machine go to Export Certificates window and export a Certificate, (if you have web servers you can export in one PKCS12 unified file). 3. On the 2nd AppDirector machine go to Import Certificates window and select Import Key. 4. On the 2nd AppDirector machine go to Import Certificates window and import Certificate.
To use an Intermediate CA for Signed Certificate 1. In the Import Certificates window, import the Intermediate CA server certificate. 2. In the AppDirector SSL Policy window, select Imported certificate in the Intermediate CA field. Figure 23 - Intermediate CA, page 451 shows an example of Intermediate CA and its usage.
Figure 23: Intermediate CA
Document ID: RDWR-AD-V021403-UG0211
451
AppDirector Guide Security
Configuration of Keys and Certificates Keys and certificates are an important part of AppDirector configuration. A key is a set of numbers or characters used to encode/decode data. A certificate is an electronic identity containing information about your company and verification from a third party about this identity. Radware s the Privacy Enhanced Mail (PEM) and Public Key Cryptography Standard # 12, (PKCS#12) exchange methods. •
PEM - helps to secure email using public key cryptography
•
PKCS#12 - is a standard for storing private keys and certificates securely and is used in Internet browsers with their import and export options.
This file format can encrypt and seal private keys and certificates with a digital signature, if required. It can be imported into the device regardless of encryption. AppDirector can be configured using an existing key/certificate, or by creating a new key/certificate.
Note: Secure management of PKI components - all certificates and key management operations can only be performed using secure protocols such as HTTPS, SSH and SNMPv3. Read-Only capabilities are still available when using HTTP, Telnet or SNMPv1 and v2.
Certificates Table This table holds all imported and created PKI entities. Each PKI entity in the table has a name used for viewing the certificate details.
To View/Create/Update the Certificates Table 1.
From the Security Menu, select Certificates > Table. The Certificates window appears.
2.
For Updating, click on the Certificate name. The Certificate Update window appears.
3.
For creating a new certificate, click Create. The Certificate Create window appears
4.
Set the parameters.
Parameter
Description
Name
Name of Key or Certificate.
Entry Type
This displays the type of the entry. With a Certificate or g Request (CSR) type, the entry also includes a Private Key. • Key • Certificate • g Request • Intermediate CA certificate • Certificate of Client CA
Key Size
Larger key sizes offer an increased level of security. We recommend that certificates have a key size of 1024 bits or more. Using a certificate of this size makes it extremely difficult to forge a digital signature or decode an encrypted message. Select from (Bytes): • 512 • 1024 • 2048
452
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security
Parameter
Description
Key phrase
The Key phrase encrypts the key in storage and is required to export the key from AppDirector. Since Private Keys are the most sensitive parts of PKI data they must be protected by phrase. A phrase should be at least 4 characters and you should use stronger phrases than those based on letters, numbers and signs. Maximum size: 1995 bytes.
Certificate / Certificate g Request (CSR) Details Common Name
The domain name of the organization. For example, www.radware.com
Locality
Name of the city.
State or Province
State or province.
Organization
Name of the organization.
Organization Unit
Department/ Unit within the organization
Country Name
Organization country.
Any email address that you want to include within the certificate.
Certificate Validity
Duration (in days) that the certificate will remain valid. Values: 1 - 365 days.
5. Click Set. Your configuration is set.
Notes: >> Default values for Certificate and CSR fields can be set in Certificate Defaults, page 456. >> A key can also be modified into a certificate by importing its corresponding certificates (to complete the PKI key-pair) to AppDirector. >> You cannot create a new entry with same name as the key entry.
Certificate Expiry SNMP traps are sent when certificates are about to expire. They are sent per certificate 30, 15, and 5 days before expiration. You should check only server certificates (used for SSL) in repository once a day for expiration date. If Certificate expiration is in 30, 15 or 5,4,3,2,1 days, a SNMP Alert (warning) is generated and if a Certificate has expired, a SNMP Alert (Error) is generated.
Importing Certificates This enables you to either import Keys/Certificates from another machine (Duplicate), to import a Certificate to an existing g Request to complete its process, and to import a Intermediate CA or Certificate of Client CA to be used in Certificate configuration or Client Authentication configuration. Keys and Certificates can be imported to AppDirector in either PEM or PKCS#!2 formats. If your key and certificate are encapsulated in a PKCS#12 (*.p12) file you can import them to AppDirector by selecting “Key & Certificate” as entity type. If you have separate PEM files for Key and for certificate you will need to import them consecutively into the same entity name.
Document ID: RDWR-AD-V021403-UG0211
453
AppDirector Guide Security
To import Certificates 1.
From the Security Menu, select Certificates > Import. The Import PKI Components window appears showing.
2.
Set the parameters..
Parameter
Description
Entry Name
Input new entry name to create by import, or existing entry name to overwrite or complete Key or CSR.
Entry Type
The following values are in PEM format: • Key - import key from backup or exported from another machine. To complete the configuration, you will need to import a certificate into this key. • Key and Certificate - If your key and certificate are encapsulated in a PKCS#12 (*.p12) file, you can import them to AppDirector. • Certificate - import certificate from backup or exported from another machine. The certificate must be imported onto a matching key or CSR. • Intermediate CA - import a certificate to be used in the SSL policy. See Intermediate CA in SSL Policies, page 195. • Certificate of Client CA - import a certificate to be used in the Client Authentication policy “Certificate of Client CA” field. See Client Authentication Policies, page 199. This value is not in PEM format: • Certificate of TSL Root CA - See Configuring TSL Files Chain, page 206.
Format (Read Only)
Parameter derived from type and displaying the expected file format.
phrase
Since Private Keys are the most sensitive parts of PKI data they must be protected by phrase. A phrase should be at least 4 characters and you should use stronger phrases than those based on letters, numbers and signs. Maximum size: 1995 bytes.
Text 3.
In this area you can paste Certificate or Key in encrypted text format.
Now, click Import.
Exporting Certificates Key, Certificate and g Request export is used for backup purposes, moving existing configurations to another machine or for completion of g Request processes. Here is a brief explanation of how to export certificates from a device either by copying and pasting a key or ing a file. Keys and Certificates can be exported from AppDirector in either PEM or PKCS#!2 formats. If you want to encapsulate key and certificate in a PKCS#12 file (*.p12) you can export them from AppDirector selecting “Key & Certificate” as entity type. If you want them as separate PEM files for Key and for certificate you need to export them consecutively selecting “Key” and “Certificate” as entry types.
454
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security
Note: The Radware key is created without a Radware at system startup, thus it can be exported without a Radware .
To export Certificates 1. From the Security Menu, select Certificates > Export. The Export PKI components window appears showing. Key, Certificate or CSR. 2. To display an existing key, certificate or CSR with all parameters, click Show. All certificate details are displayed here.
Parameter
Description
Entry Name
Select name of entry to export.
Entry Type
This displays the type of the entry. In case of a Certificate or g Request (CSR) type the entry also includes a Private Key. Select from: • Key - import key from backup or exported from another machine. To complete the configuration, you will need to import a certificate into this key. • Key and Certificate - If your key and certificate are encapsulated in a PKCS#12 (*.p12) file, you can import them to SIP Director. • Certificate - import certificate from backup or exported from another machine. The certificate must be imported onto a matching key or CSR.
Format
Read-Only parameter derived from the type and displaying the expected file format.
phrase
Required when exporting Keys. Use phrase entered when key was created/imported. You need to enter the key phrase to validate that you are authorized to export it. Since Private Keys are the most sensitive parts of PKI data they must be protected by a phrase. A phrase should be at least 4 characters and you should use stronger phrases than those based on letters, numbers and signs. Maximum size: 1995 bytes.
Text
In this space the Key/Certificate/CSR text is shown in text format for you to Copy-paste it, when you use the "show" option.
3. Choose Show or Export. Click Show to display Key/Certificate/CSR in encrypted text format for copy-paste purposes, e.g. sending CSR to Certificate g authority. 4. A dialog message appears asking if you want to open or save the certificate file? If you click Open, the file is opened in a browser window. If you click Save you are prompted to save the file.
Document ID: RDWR-AD-V021403-UG0211
455
AppDirector Guide Security
Certificate Defaults This enables you to define your organization's default parameter to be used when creating g Requests or Self-signed certificates.
To view/edit Default Values for Certificates 1.
From the Security Menu, select Certificates > Default Values. The Default Values window appears.
2.
Set the parameters.
Parameter
Description
Certificate Common
Domain name of the organization. For example, www.radware.com.
Certificate Locality
Name of the city.
Certificate State or Province
State or province.
Certificate Organization
Name of the organization.
Certificate Organization Unit
Department/ Unit within the organization
Certificate Country Name Organization country Certificate Email 3.
Any email address to include within the certificate.
Click Set. Your configuration is set.
Application Security This section helps you set up and configure Application Security profiles and contains these topics: •
SYN Flood Protection, page 457
•
Session Table and Session Table Lookup Mode, page 462
The following topics can only be accessed when you are in:
Standard Acceleration Mode •
Signature Protection, page 465
•
Behavioral DoS, page 487
•
Connection Limit, page 499
•
Global Suspend Table, page 503
•
Security Reporting, page 504
•
Attack Database, page 509
•
Update Policies, page 512
•
Packet Anomalies, page 512
Applications only control the use of resources granted to them, and not which resources are granted to them. They, in turn, determine the use of these resources by s of the application through application security.
456
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security Application Security: •
provides protection against single or multiple packet attacks that cause denial of service.
•
encomes measures taken throughout the application's life-cycle to prevent exceptions in an application’s security policy or the underlying system (vulnerabilities) through flaws in the design, development, deployment, upgrading, or maintenance of the application.
Application Security profiles: •
are part of the protection from and prevention of denial of service attacks.
•
are predefined traffic detectors that scan incoming traffic identifying known attack signatures. The profiles use various attacks that find malicious packets and make decisions based on predefined settings.
SYN Flood Protection SYN Flood Protection is a service that protects the hosts located behind the device, and the device itself, from SYN flood attacks, with delayed binding. A SYN Flood attack is a DoS attack where the attacker sends a huge amount of please-start-aconnection packets but no follow-up packets. The SYN Flood attack is performed by sending a SYN packet without completing the T three-way handshake. Another type of SYN Flood attack is done by completing the T three-way handshake, but without sending data packets afterwards. Radware provides complete protection against both types of SYN Flood attacks. These attacks are detected and blocked by SYN Flood Protection Policies.
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. SYN attack detection is operational only when the device operates at Layer 4.
SYN Flood Protection Settings And Tunings SYN profiles provide protection against SYN flood attacks. During a SYN flood attack, the attacker sends a volume of T SYN packets requesting new T connections without completing the T handshake, or completing the T handshake, but not requesting data. This fills up the server connection queues, denying service to legitimate T s. SYN Flood Protection protects the hosts located behind the device and the device itself from SYN flood attacks by performing delayed binding. A SYN flood attack is a denial of service attack where the attacker sends a huge amount of please-start-a-connection packets and then no follow up packets. The SYN Flood attack is performed by sending a SYN packet without completing the T three-way handshake. Another type of SYN Flood attack is done by completing the T three-way handshake, but no data packets are sent afterwards. Radware provides complete protection against both types of SYN Flood attacks. The attacks are detected and blocked by SYN Flood Protection Policies. The reports regarding the current attacks appear in the Active Triggers table.
SYN-ACK Reflection Attacks Prevention SYN-ACK Reflection Attacks Prevention prevents reflection of SYN attacks and reduces the SYN-ACK packet storms created as a response to DoS attacks. When a device is under SYN attack, it sends a SYN-ACK packet with an embedded Cookie, to prompt the client to continue the session. With 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 blocks legitimate traffic.
Document ID: RDWR-AD-V021403-UG0211
457
AppDirector Guide Security
To enable SYN Flood Protection 1.
From the Security menu, select SYN Flood Protection > Global Parameters. The SYN Flood Protection Parameters window appears.
2.
Set the parameters.
Parameter
Description
SYN Flood Protection Status
Enables (default) / Disables SYN Flood Protection mode. Values: Enabled, Disabled, Standby. Standby activates the SYN Flood Protection module without rebooting the device.
Statistics Max For each policy, the maximum number of destinations that can be destinations per policy reflected in the statistics report. Note: Destination is a single IP, dest port, or RX port. Values: 1 - 100 Default: 5 Statistics time period (Secs)
Number of seconds used to calculate average values for SYN protection statistics. Values: 1 - 100 Default: 60
Attack Periodic Report Threshold (% incomplete secs)
If the percentage of incomplete sessions for a destination protected by a policy exceeds this threshold, the attack is reported periodically. A value of 0 means no report is available. Values: 1 - 100% Default: 50
SYN ACK Reflection Limiting threshold representing the maximum number of uncompleted Maximum SYN Cookies T sessions per source IP per second, to be answered. Any session per Source exceeding this frequency is ignored. Values: 1 - 100,000 Default: 1,000 T Protection Timeout Timeout to complete the T 3-way handshake. Values: 0-10 seconds (0 means no timeout). Default: 5 SYN Protection Tracking Time
The number of seconds during which the number of SYNs directed to the same destination must be below the Deactivation Threshold value. If the number of SYNs exceeds the deactivation threshold within that time, the destination protection is deactivated. Values: 0 -10 seconds (0 means no timeout). Default:5
SYN ACK Reflection SrcIP Sampling Per Second
Amount of SYN packets per second that are sampled and their source IP is to be monitored. Values: 0 - 10000 Default: 100
SYN ACK Reflection Protection Mode
Activate SYN-ACK Reflection Attack Prevention using these modes: • Enable: The prevention mode • Report Only: The report-only mode (no prevention) • Disable (Default): The mechanism is disabled
458
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security
Parameter
Description
Maximum Traps per Time Interval
Maximum number of SYN Flood and ACK reflection traps per defined time interval. Value: >0 Default: 100
Traps Time Interval (seconds)
-defined time interval (in seconds) for limiting traps. Value: >0 Default: 60 seconds.
3. Click Set. Your configuration is set.
Note: Before enabling SYN Flood protection you must set the Session/Client Table to operate in the Layer 4 mode.
SYN Protection Policies SYN Protection Policies are sets of predefined SYN flood detectors and protectors. Here, you can configure SYN Protection Policies for AppDirector version 2.10.
SYN Flood Protection Policies Once the SYN Flood Protection is enabled, you can define Protection policies. A policy is defined according to a destination address or address range.
To create a SYN Flood Protection Policy 1. From the Security menu select SYN Flood Protection > Protection Policies. The SYN Flood Protection Policies window appears. 2. Click Create. The SYN Protection Policies Create window appears. 3. Set the parameters.
Parameter
Description
Name
The -defined name of the policy
Index
Location of policy in the protection table that reflects the order in which the classification is performed.
Protection Mode
Includes a dropdown menu with the following options: • Enabled: Activates SYN Cookies for all sessions • Triggered: Activates SYN Cookies only when SYN attack is identified • Disabled: Never use SYN Cookies
Operational Status
Active or Inactive.
Activation Threshold 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. Default: 2500 Verification Type
Define the process of completing the T session:
Document ID: RDWR-AD-V021403-UG0211
459
AppDirector Guide Security
Parameter
Description
Description
A free text describing the policy.
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 Deactivation Threshold, the SYN Flood protection policy is deactivated and the traffic is no longer protected. Default: 1500
4.
Ack
Session is completed when the Ack packet arrives (following a SYN / SYN-ACK packets exchange)
Request
Session is completed when the first data request packet arrives (following a SYN / SYN-ACK packets exchange)
Destination
Destination address of packet matched by policy.
Physical Port Group
-defined physical port group or aggregated Link for SYN flood protection.
Count Statistics
Enable or disable counting of statistics for destinations defined in policy.
Service
Basic filter of protected application destination port.
Click Set. Your configuration is set.
SYN Flood Statistics To make the process of defining policy thresholds easier for you, you can view SYN Statistics prior to configuring the thresholds. The SYN statistics window provides information on the number of SYNs, complete sessions and other data, thus helping you to define reliable thresholds.
To access the SYN statistics 1.
From the Security menu select SYN Flood Protection > Statistics. The SYN Flood Protection Statistics window appears.
2.
Select the desired policy. Leaving this field empty displays statistical data for all policies. For each policy the following data appears:
460
Parameter
Description
Name
Name of policy whose 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
Current status of attack. 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
Highest value of SYNs per second during the statistical analysis period.
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security
Parameter
Description
Valid Sess/Sec Peak
Highest value of valid sessions per second during statistical analysis period.
Attack Start
Last attack detection time and date.
Attack Term
Last attack termination time and date.
3. To update the table click Set.
Notes: >> To define a group with a single port, assign the same value to From Port and To Port. >> Use the same group name for all ranges that you want to include in the group. 4. Click OK. A new row appears in the Application Port Group table. 5. Click OK. The Application Port Group window closes. 6. From the Destination App. Port Group drop-down list, select a group that was defined in the Application Port Groups table. 7. In the Attack Description field, enter a description of the attack. 8. Click OK. The SYN Attack Configuration window closes, and a new -defined attack appears in the All Regular Filters pane of the Connect & Protect Table window.
Note: AppDirector will recognize an attack when there is more then 1000 packets per second.
Viewing the SYN Statistics To make 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, from which you can define reliable thresholds in custom policies.
SYN Flood Reporting - Active Triggers You can view active SYN Flood attacks via the Active Triggers table. This table displays the parameters of the Active Triggers table.
To view the SYN Flood Active Triggers Table From the Security menu select SYN Flood Protection > Active Triggers. The Active SYN Protection Triggers window appears, which contains the following read-only parameters:)
Parameter
Description
Type
The type of the identified attack:
IP Address
Source IP for SYN ACK Reflection, and dest IP for all other types.
Active Time (Secs)
Number of seconds since the attack began.
Total SYN
Total number of SYN packets for this trigger.
Total SYN Dropped sessions
Total number of unverified sessions for this trigger.
Document ID: RDWR-AD-V021403-UG0211
461
AppDirector Guide Security
Parameter
Description
Last Sec SYN
Number of SYN Flood attacks recognized in last second.
Last Sec Verified
Number of ACKs recognized in the last second.
T-Handshake-Timeout The Timeout for the SYN option enables the protection of the Client Table against SYN attacks that occur during the T handshake process. When a client sends SYN to the Layer 4 Policy, AppDirector selects a server, adds a new entry to the Client Table, and forwards SYN to the selected server. If, during a predefined period of time (which can last for 1 to10 seconds), no additional response arrives from this client, it is regarded as a SYN attack. In that case, the entry is deleted from the Client Table, and the Reset command is sent to the server to release the resources allocated to this session. Values run from 1 to 10 seconds and the default is 5 seconds.
Note: The Timeout for SYN parameter is applicable only when the Open Entry When Source Port Different or the Select New Server When Source Port Different parameters are enabled. The Timeout for SYN parameter applies only to T sessions. You can enter the value (in seconds) that AppDirector assigns to a new session started by a SYN packet if no further traffic is received from the client, until the entry is removed from the Client Table and a Reset is sent to the server. If the defined SYN Timeout is 0 (regular aging time), this indicates that the parameter is disabled, and sessions are removed from the Client Table according to the value defined as the Aging Time.
Session Table and Session Table Lookup Mode The Session Table enables the device to efficiently process traffic that is only routed or bridged by the device and not load balanced. It is a mechanism similar to the Client Table that allows the device to track sessions that are not recorded in the Client Table The Session Table records session information when bandwidth management Layer 7 policies are applied to traffic running through the device. It s stateful features for traffic, such as SYN Protection. The Session Table Lookup mode indicates what layer of address information is used to categorize packets in the Session Table.
Notes: >> The Session Table is disabled by default. When SYN Flood Protection is used, the Session Table must be enabled. >> Full Layer 3 and Full Layer 4 modes are ed. >> Packets must be categorized with the Full Layer 4 Session Table Lookup mode when SYN Protection is used.
462
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security
To configure the Session Table Global parameters 1. From the Device menu, select Session Table> Global Parameters. The Session Table Parameters window appears. 2. Set the Parameters.
Parameter
Description
Session Table Status
Whether the session table is active or not. If the device does not need to provide high performance for routed or bridged traffic, it is disabled. Default: Disabled
Session Table Aging Time
Amount of time a non-active session is kept in Session Table ( secs). If 0 - the regular session aging time is used Default: 100 seconds.
Session Table Lookup Mode
Indicates what layer of address information is used to categorize packets in the Session Table. This means whether the sessions are treated per (L3-IP address) or per session (L4-IP addresses and ports). Modes include: • Full Layer3: An entry exists in the Session Table for each Source IP and Destination IP combination of packets ing through the device. This mode is recommended for higher performance, unless traffic classification on Layer 4 or 7 is required. • Full Layer4 (Default): An entry exists in the Session Table for each Source IP, Source port, Destination IP, and Destination port combination of packets ing through the device. This default mode for the Session Table and is recommended when traffic classification on Layers 4 or 7 is required.
Remove Session Table Entry at Session End
Removes sessions from the Session Table when the session ends (only valid for Full Layer 4 Lookup mode). Recommended to free resources when the Aging Time of Session Table is set to a high value; however, it can cause slight performance degradation. Default: Enabled
Send Reset To Server Status
Checks whether the Session Table sends a reset packet to the server if no data is transmitted through the session, because it could be a SYN attack. Default: Disabled
3. Click Set. Your configuration is set.
Document ID: RDWR-AD-V021403-UG0211
463
AppDirector Guide Security
View Table Query Results The View Table Query Results window allows you to define the way in which the Session Table information is represented. The Session Table Entries table displays the information that you decided to present. Using Session Table Query Filters you can set what information is displayed in the Session Table Entries table.
To define what information is presented in the Session Table Entries table 1.
From the Device menu, select Session Table > View Table Query Results. The Session Table Entries window appears.
2.
To set the Session Table Query Filters, from the Session Table Entries window click Create. The Session Table Query Filters Table Create window appears.
3.
Set the parameters.
Parameter
Description
Maximum Displayed Entries
Maximum number of session table entries that will be displayed. To set the number of Session Table entries that you want to present, type the number that you want here.
Number of Used Entries (Read Only)
Number of entries currently used.
Session Table Entries Source IP
Source IP within the defined subnet.
Dest IP
Destination IP within the defined subnet.
Source Port
Session source port.
Dest Port
Session destination port.
Protocol
4.
464
Lifetime
Lifetime of the entry.
Aging Type
Aging Type of the entry.
SYN Flood Status
SYN flood status of the entry.
Click Set. The Session Table Entries table displays information from the Session Table according to your preferences with these parameters.
Parameter
Description
Name
Unique filter name.
Source IP
Source IP within the defined subnet.
Dest IP
Destination IP within the defined subnet.
Source Port
Session source port.
Dest Port
Session destination port.
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security
Working in Application Acceleration Disabled Mode
Standard Acceleration When you disable the acceleration engine, (see Tweaks, page 290), you can utilize the further security features based on other licenses shown here. But first you need to follow these steps: 1. Ensure that you have the correct licenses. a. b. c.
As a default, all AppDirector s receive a basic AppDirector licence. In addition, you may also have a cookie persistency license. However, to run Bandwidth Management and IPS features, you will additionally need a bwmips licence. To run DoS Shield and BDos features, you need a dos license but will first need the BWM and IPS license, bwm-ips.
2. If you do not have the correct license(s), you will need to obtain them as follows: a. b.
Order the required license part number. Send with the order, the MAC address and the current license ID for the license type you require. This information is available in the License Upgrade window in Web Based Management
c.
The new license string will be received by email.
3. Using Web Based Management (Device / License Upgrade), or CLI (using the command system license) enter the new license string. Also see Upgrading Licenses Using WBM, page 53 and Upgrading Licenses Using the CLI, page 55.
Signature Protection Signature protection detects and prevents network-oriented attacks, Operation System (OS) oriented attacks and application-oriented attacks by comparing each packet to the set of signatures stored in the Signatures database. The attacks handled by this protection can be divided into the following groups: •
Server-based vulnerabilities: —
Web vulnerabilities
—
Mail server vulnerabilities
—
FTP server vulnerabilities
—
SQL server vulnerabilities
—
DNS server vulnerabilities
—
SIP server vulnerabilities
•
Worms & Viruses
•
Trojans & Backdoors
•
Client side vulnerabilities
•
IRC bots
•
Spyware
•
Phishing
•
Anonymizers
Radware provides you with the Signatures database that contains signatures of predefined attacks. These attacks are included in the predefined groups and profiles supplied by Radware. Using the predefined groups and profiles, you can create new protection policies. Each attack group includes a number of attack signatures that are grouped together according to their common characteristics. The groups are included in protection profiles that are applied to protection policies
Document ID: RDWR-AD-V021403-UG0211
465
AppDirector Guide Security
Security Signatures File Update To constantly update the signatures database, AppDirector 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 whether you can access 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), plus, the website is updated on an ongoing basis with emergency updates when required. You can Update the Signatures file in the following ways: •
Manual updating: If you have an updated file that was ed manually from the Radware website, you can the signatures file to AppDirector manually.
•
Manual ing and updating: You can the update file from the Radware website and update using this file.
•
Automatic ing and updating: You can schedule automatic s and updates of the signatures file.
Tip: To provide protection for your network, it is recommended to set automatic daily updates. The Signature Protection option contains these features: •
Application Security Global Parameters, page 467.
•
IP Reassembly and Min IP Fragmentation, page 467
•
Denial of Service (DoS), page 469
•
DoS Shield, page 469.
•
Basic Static Filters, page 470.
•
Basic Filters, page 474.
•
Advanced Static Filters, page 476.
•
Advanced Filters, page 477.
•
Attacks, page 477
•
Static Attacks, page 478.
•
Attacks, page 480.
•
Copy Groups, page 482.
•
Static Groups, page 483.
•
Groups, page 483.
•
Copy Profiles, page 484.
•
Static Profiles, page 484.
•
Profiles, page 485.
•
Signature Protection Policies, page 485.
•
Exclude Attacks, page 486.
466
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security
Application Security Global Parameters Application Security is a mechanism that delivers advanced attack detection and prevention capabilities. This mechanism is used by several security modules to provide maximum protection for network elements, hosts and applications.
To set the Application Security Global Parameters 1. From the Security menu select, Signature Protection > Application Security > Global Parameters. The Application Security Tuning window appears. 2. Set the parameters.
Parameter
Description
Start Protection
Select Enable (default) to start protection.
Min Risk
From the drop-down list define the risk level. Values: Info, Low, Medium, High
MAX URI Length
Maximum URI length permitted. If URI is longer than the configured value, this URI is considered as illegitimate and is dropped. The default value is 500 characters.
MIN fragmented URI packet Size
The minimum permitted size of an incomplete URI in an HTTP request. A shorter packet length is treated as URI protocol anomaly and is dropped. The default value is 50 characters.
Security Tracking Tables Free-Up Frequency [ms]
The Free-Up Frequency for each table determines how often the device clears unnecessary entries from the table, and stores information about newly detected security events.
Unicode Encoding
The language encoding (the language and character set) to use for detecting security events.
Session-Drop Mechanism Status
When enabled, terminates the whole session when a single malicious packet is recognized.
3. Click Set. Your preferences are recorded.
IP Reassembly and Min IP Fragmentation AppDirector provides protection against IP traffic evasion techniques with a signature-based recognition of IP attacks. Signature lookup is done on a packet-by-packet basis. Hackers (or a host operating system) may split an attack over two or more IP fragments belonging to the same IP packet, bying 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 byed. Used by hackers, this technique is called Evasion. AppDirector enables assembling IP fragments into a complete IP packet to search for attack signatures split among multiple IP fragments. Fragments of an IP packet are assembled until the packet is complete. The device continues to forward the fragments and only when 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.
Document ID: RDWR-AD-V021403-UG0211
467
AppDirector Guide Security To provide protection from fragmented IP traffic, AppDirector uses: •
IP Reassembly: AppDirector assembles the IP fragments into a complete IP packet and looks for attack signatures split among multiple IP fragments.
•
Min IP Fragmentation: AppDirector detects abnormally small IP fragments and applies a predefined Action mode to them.
There is no report of a specific attack. It is mentioned only when a fragment has been identified as an attack.
To configure the IP Defragmentation parameters 1.
From the Security menumenu select, select Signature Protection > Application Security > IP FragmentsGlobal Parameters. The Application Security IP Fragments Tuning window appears.
2.
Set the parameters.
Parameter
Description
Protection Status
Enable / Disable (default).
IP Reassembly no memory Action Mode
The device action when the device lacks memory resources to perform IP reassembly. Values
IP Reassembly aging time [sec]
•
Drop: The packet is discarded
•
Forward (default): The packet is forwarded to the defined destination
Maximum period of time, in seconds, during which DefensePro keeps consecutive fragments of the same IP packet in case not all the fragments of this packet have been received yet. After this period DefensePro drops the fragments. Default: 3
IP Reassembly Overlap status
Sets the data overlapping status within IP fragments. Overlapping may also indicate an attack evasion technique. Values:
IP Reassembly Overlap Action Mode
468
•
Allow (default): 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
The Action mode settings when IP Reassembly Overlap status is set to "Deny." •
Report Only (default): The fragment is forwarded to the defined destination
•
Drop: The fragment is discarded
•
Reset Source: A T-Reset packet is sent to the packet Source IP
•
Reset Destination: A T-Reset packet is sent to the destination address
•
Reset Bi-directional: T-Reset packets are sent to both the packet source IP and the packet destination IP
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security
Parameter Min IP Fragment protection status
Min IP Fragment Action Mode
Description Enable/Disable (default) the Min Fragment protection feature. Note: There is no dependency between the IP Reassembly feature and the Min Fragment protection feature. Min Fragment protection can be enabled when the IP Reassembly feature is Enabled or Disabled. Action mode settings when Min IP Fragment Protection is set to Enable: • Report Only: The fragment is forwarded to the defined destination • Drop (default): The fragment is discarded • Reset Source: A T-Reset packet is sent to the packet Source IP • Reset Destination: A T-Reset packet is sent to the destination address • Reset Bi-directional: T-Reset packets are sent to both the packet source IP and the packet destination IP
MIN IP 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. Values: 1-65535 Bytes. Default: 512 Bytes. 3. Click Set. Your preferences are recorded.
Denial of Service (DoS) 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, causing denied access for legitimate s. This is known as a Denial of Service (DoS) or Distributed Denial of Service (DDoS) attack. DoS occurs as a result of various types of flooding caused by hackers, such as UDP, T, and ICMP. The DoS/DDoS module provides protection against packet flooding, thereby preventing denial of service. To provide protection against denial of service, the DoS/DDoS module incorporates two different services that mitigate DoS attacks: •
DoS Shield Profiling: Sampling-based service that provides protection against the packet flooding which causes a denial of service effect. This protection is provided for T, UDP, and ICMP floods. This service utilizes advanced sampling, which significantly reduces the device U load compared to packet-by-packet scanning.
•
Application Security Profiling: 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.
DoS Shield To prevent denial of service, DoS Shield samples traffic flowing through the device and limits the bandwidth of traffic that has been recognized as a DoS attack using predefined actions. This is based on working with two attack states: Dormant and Active. Dormant state indicates using the sampling method 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.
Document ID: RDWR-AD-V021403-UG0211
469
AppDirector Guide Security Active state indicates that the action must be implemented on each packet that matches the attack signature. 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. DoS Shield utilizes two processes working in parallel. One statistically monitors traffic to check if any of the attacks in Dormant state have become active. When an attack is detected as active, this attack is handled by the second process. Each packet ing 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 while the other packets are forwarded to the network. Prior to using DoS Shield, you need to enable the DoS Shield module. In the DoS Shield Global Parameters window you can enable the DoS Shield module and set its global parameters.
To configure DoS Shield Global Parameters 1.
From the Security Menu select Signature Protection > DoS Shield > Global Parameters. The DoS Shield Global Parameters window appears.
2.
Set the parameters.
Parameter
Description
Start Protection
Enable (default) DoS Shield module operation.
Sampling Rate
The rate in which packets are sampled and compared to the Dormant Attacks. You can configure a number indicating how many packets the sampling is performed. Default: 101, (1 out of 101 packets is checked).
Sampling Frequency [sec]
3.
How often DoS Shield compares the predefined thresholds for each Dormant Attack to the current value of counters of packets matching the attack. Default: 5 seconds
Click Set. Your preferences are recorded.
Basic Static Filters The Security Basic Static Filters window allows you to view the Basic Filter, which constitutes protection against a specific attack, meaning that each Basic Filter has a specific attack signature and protection parameters. The Advanced Filter represents a logical AND between two or more Basic Filters. Some attacks have a complex signature comprised of several patterns and content strings. These attacks require more than one basic filter to protect against them.
Note: You can create the Advanced Filters using the -defined Basic Filters only.
470
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security
To view the Security Basic Static Filters 1. From the Security menu, select Signature Protection > Filters > Basic Filters > Static. The Static Basic Filter Table window appears. 2. Select the basic static filter for which you want to view the details. The Static Basic Filter Table Update window appears with the following read-only parameters.
Parameter
Description
Name
The name of the filter as you define it.
Protocol
The protocol used: IP, UDP, T or ICMP.
Source App. Port
The source application ports. Values: 0 (default) - 65535
Destination App. Port
The destination application ports.
OMPC Offset
The location in the packet from which the checking of data is started to find specific bits in the IP/T header.
Values: 0 (default) - 65535
Values: 0 (default) - 1513 OMPC Offset Relative to
Indicates to which OMPC offset the selected offset is relative to.
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 Pattern parameter definition must contain 8 symbols. If the OMPC Length value is lower than fourBytes, you need complete it with zeros.
Values: None (default), IP Header, IP Data, L4 Data, L4 Header, Ethernet.
For example, if OMPC Length is twoBytes, OMPC Mask can be:abcd0000. Default value: 00000000. OMPC Pattern
The fixed size pattern within the packet that OMPC rule attempts to find. 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 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 Pattern can be:abcd0000. Default value: 00000000.
OMPC Condition
The OMPC condition can be either N/A, equal, notEqual, greaterThan or lessThan. Default: N/A.
OMPC Length
The length of the OMPC (Offset Mask Pattern Condition) data can be N/A, oneByte, twoBytes, threeBytes or fourBytes. Default: N/A.
Content Offset
The location in the packet from which the checking of content is started. Values: 0 (default) - 1513
Distance
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.
Document ID: RDWR-AD-V021403-UG0211
471
AppDirector Guide Security
Parameter
Description
Content
Contains the value of the content search. Possible values: < space > ! " # $ % & ' ( ) * + , -. / 0 1 2 3 4 5 6 7 8 9 : ; < = > ? @ A B C D E F G H I JKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmno pqrstuvwxyz{|}~
Content Type
Enables you to search for a specific content type, which can include: • URL: In the HTTP Request URI. No normalization procedures are taken. • Normalized URL: To avoid evasion techniques when classifying HTTPGET requests, the URL content is transformed into its canonical representation, to interpret the URL in the same way the server would. The normalization procedure s 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 , UTF-8 and IIS encoding.
• Host Name: In the HTTP Header • Text: Anywhere in the packet • HTTP Header Field: In the HTTP Header • Mail Domain: In the SMTP Header • Mail To: In the SMTP Header • Mail From: In the SMTP Header • Mail Subject: In the SMTP Header • Regular Expression: Anywhere in the packet • Header Type: HTTP Header field. The "Content" field includes the header field name, and the "Content data" field includes the field value. • File Type: The type of the requested file in the http GET command (jpg, exe etc). • POP3 : field in the POP3 Header • Cookie Data: HTTP cookie field. The "content" field includes the cookie name, and the "content data" field includes the cookie value • 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 is used to delimit several RPC requests sent on top of the transport protocol. When there is a stream-oriented protocol (T or SCTP), 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.
• N/A: Default
472
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security
Parameter
Description
Content Max Length Maximum length to be searched within the selected Content Type. Values: 0 (default) - 1513 The Content Max Length value must be equal or greater than the Offset value. Content Data
Refers to the search for the content within the packet. It can be N/A, URL or Text.
Content Encoding
Application Security can search for content in non-english languages for case sensitive or case insensitive text and hexadecimal strings. Values: • None (default) • Case Insensitive • Case Sensitive • HEX • International The value of this field corresponds to the Content Type parameter.
Content Data Reg Expression
Expression content held anywhere within the packet. Select this parameter to indicate that the Content Data field value is formatted as a regular expression (and not as free text to search). From the dropdown list, select either Yes/No.
Content Regular Expression
A regular expression (abbreviated as regexp, regex), is a string that describes or matches a set of strings, by certain syntax rules. You can set a Regex search for all content types. This parameter allows you to search for content type anywhere in the packet. (Content is T/UDP data or IP Data for other protocols or beginning L3 of non-IP traffic. From the dropdown list, select either Yes/No.
Content Data Encoding
Application Security can search for data in languages other than English, for case sensitive or case insensitive data and hexadecimal strings. Values: • None (default) • Case Insensitive • Case Sensitive • HEX • International The value of this field corresponds to the Content Type parameter.
Document ID: RDWR-AD-V021403-UG0211
473
AppDirector Guide Security
Basic Filters
To view the Security Basic Static Filters 1.
From the Security menu, select Signature Protection > Filters > Basic Filters > . The Basic Filter Table window appears.
2.
Select the basic static filter for which you want to view the details. The Basic Filter Table Update window appears with the following read-only parameters.
Parameter
Description
Name
Name of the filter as you define it.
Protocol
Protocol used: IP, UDP, T or ICMP.
Source App. Port
Source application ports. Values: 0 (default) - 65535
Destination App. Port
Destination application ports. Values: 0 (default) - 65535
OMPC Offset
Location in the packet from which the checking of data is started to find specific bits in the IP/T header. Values: 0 (default) - 1513
OMPC Offset Relative to
Indicates to which OMPC offset the selected offset is relative to.
OMPC Mask
Mask for the OMPC data.
Values: None (default), IP Header, IP Data, L4 Data, L4 Header, Ethernet. Values: A combination of hexadecimal numbers (0-9, a-f). These must be defined according to the OMPC Length parameter. The OMPC Pattern parameter definition must contain 8 symbols. If the OMPC Length value is lower than fourBytes, you need to complete it with zeros. For example, if OMPC Length is twoBytes, OMPC Mask can be:abcd0000. Default: 00000000.
OMPC Pattern
Fixed size pattern within the packet that OMPC rule attempts to find. 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 8 symbols. If the OMPC Length value is lower than fourBytes, you need to complete it with zeros. For example, if OMPC Length is twoBytes, OMPC Pattern can be:abcd0000. Default: 00000000.
OMPC Condition
Values: N/A (default), equal, notEqual, greaterThan or lessThan.
OMPC Length
Length of the OMPC (Offset Mask Pattern Condition) data: Values: N/A (default), oneByte, twoBytes, threeBytes or fourBytes.
Content Offset
Location in packet from which the checking of content is started. Values: 0 (default) - 1513
Distance
A range that defines allowed distance between two content characters. If the distance is beyond the specified range, it is recognized as an attack.
474
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security
Parameter
Description
Content
Contains the value of the content search. Values: < space > ! " # $ % & ' ( ) * + , -. / 0 1 2 3 4 5 6 7 8 9 : ; < = >?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`a bcdefghijklmnopqrstuvwxyz{|}~
Content Type
Enables you to search for a specific content type, including: • URL: In the HTTP Request URI. No normalization procedures are taken. • Normalized URL: To avoid evasion techniques when classifying HTTP-GET requests, URL content is transformed into its canonical representation, to interpret the URL in the same way the server would. The normalization procedure s 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 , UTF-8 and IIS encoding.
• Host Name: In the HTTP Header • Text: Anywhere in the packet • HTTP Header Field: In the HTTP Header • Mail Domain: In the SMTP Header • Mail To: In the SMTP Header • Mail From: In the SMTP Header • Mail Subject: In the SMTP Header • Regular Expression: Anywhere in the packet • Header Type: HTTP Header field. The "Content" field includes the header field name, and the "Content data" field includes the field value • File Type: The type of the requested file in the http GET command (jpg, exe etc.). • POP3 : field in the POP3 Header • Cookie Data: HTTP cookie field. The "content" field includes the cookie name, and the "content data" field includes the cookie value • 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 is used to delimit several RPC requests sent on top of the transport protocol. In case of a stream-oriented protocol (T or SCTP) 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.
• N/A: Default
Document ID: RDWR-AD-V021403-UG0211
475
AppDirector Guide Security
Parameter
Description
Content Max Length
Maximum length to be searched within the selected Content Type. Values: 0 (default) - 1513 Content Max Length value must be equal or greater than Offset value.
Content Data
Refers to search for content within the packet. Values: N/A, URL or Text.
Content Encoding
Application Security can search for content in languages other than English, for case sensitive or case insensitive text and hexadecimal strings. Values: • None (default) • Case Insensitive • Case Sensitive • HEX • International The value of this field corresponds to the Content Type parameter.
Content Data Reg Expression
Expression content held anywhere within the packet. Select this parameter to indicate that the Content Data field value is formatted as a regular expression (and not as free text to search). From the dropdown list, select either Yes/No.
Content Regular Expression
A regular expression (abbreviated as regexp, regex), is a string that describes or matches a set of strings, by certain syntax rules. You can set a Regex search for all content types. This parameter allows you to search for content type anywhere in the packet. (Content is T/UDP data or IP Data for other protocols or beginning L3 of non-IP traffic. From the dropdown list, select either Yes/No.
Content Data Encoding
Application Security can search for data in languages other than English, for case sensitive or case insensitive data and hexadecimal strings. Values: • None (default) • Case Insensitive • Case Sensitive • HEX • International The value of this field corresponds to the Content Type parameter.
Advanced Static Filters The Advanced Filter represents a logical AND between two or more Basic Filters. Some attacks have a complex signature comprised of several patterns and content strings. These attacks require more than one basic filter to protect against them.
Note: Note: You can create the Advanced Filters using the Defined Basic Filters only. The Advanced Static Filters window allows you to view the Advanced Static Filter Table.
476
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security
To view Advanced Static Filters From the Security menu, select Signature Protection > Filters > Advanced Filters > Static. The Static Advanced Filters window appears. The Advanced Filters Table contains the following parameters:
Parameter
Description
Name
The name of the filter.
Number of Filters
The number of filters for this entry.
Advanced Filters The Advanced Filter represents a logical AND between two or more Basic Filters. Some attacks have a complex signature comprised of several patterns and content strings. These attacks require more than one basic filter to protect against them. The Defined Advanced Filters window allows you to create Advanced Filters.
To create a Advanced Filter 1. From the Security menu, select Signature Protection > Filters > Advanced Filters > . The Defined Advanced Filters window appears. 2. Click Create. The Create Advanced Filter window appears. 3. Set the parameters.
Parameter
Description
Advanced
The name of the Advance Filter that you define.
Basics
The name of the Basic filter that is associated to the Advanced filter.
4. Click Set. Your preferences are recorded.
Attacks An Attack is a building block of the profile. Each Attack contains one or more protection filters and attributes that determine which packets are malicious and how the signature protection mechanism treats those packets. Attack parameters define how the malicious packet is tracked and treated once its signature is recognized in the traffic. Each Attack is bound to a tracking function, which defines how the packet is handled when it is matched with the signature. The main purpose of these functions is to determine whether a packet is harmful and to take appropriate action. The Attacks table provides you with filtering that allows viewing of Radware and -defined Attacks. You can define filtering criteria and display all Attacks matching the criteria in the Attacks table. In addition you can add -defined Attacks. For further information see: •
Top Ten Attacks, page 506
•
Attack Database Version, page 509
•
Attack Database Send to Device, page 509
Document ID: RDWR-AD-V021403-UG0211
477
AppDirector Guide Security
Static Attacks The Attacks Database contains attacks provided by Radware. You can add -defined attacks to reflect specific needs of your network, or edit the existing attacks.
To edit a Static Attack 1.
From the Security menu select, Signature Protection > Attacks > Static. The Signature Protection Static Attack Configuration Table window appears.
2.
Select a static attack. The Signature Protection Static Attack Configuration Update window appears.
3.
Set the parameters.
Parameter
Description
ID
The unique identifying number (read-only).
Attack Name
-defined name for this attack. Attack Name is used when DoS Shield sends information about attack status changes (read-only).
Filter Name
The filter assigned to this attack (read-only).
Filter Type
The type of filter (read-only).
Tracking Time
Sets amount of time (in milliseconds) in which the threshold is measured. When a number of packets greater than the threshold value es through the device, during this defined time period, the device recognizes it as an attack. Default: 1000
Active 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: 10
Tracking Type
Defines how the device decides which traffic to block or drop, when under an attack of this type. Values: • Drop All (default): Use when each packet of the defined attack is harmful. For example: Code Red and Nimda attacks. • Source Count: Select this option when the defined attack is source-based, meaning the hacker attack can be recognized according to its source address. For example: Horizontal Port Scan, were the hacker scans a certain application port (T or UDP) to detect which servers are available on the network. • Target Count: Select this option when the defined attack is destination-based, meaning the hacker is attacking a specific destination such as a Web server. For example: Ping Flood and DDoS attacks • Source and Target Count: Select this option when the attack type is a source and destination based attack, meaning the hacker is attacking from a specific source IP to a specific destination IP. For example: Port Scan attack. • Sampling: Select this option when the defined attack is based on sampling. The rate at which packets are sampled and compared to the Dormant Attacks.
478
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security
Parameter
Description
Action Mode
When an attack is detected, one of the following actions can be taken: • Report Only: The packet is forwarded to the defined destination. • Drop (default): The packet is discarded. • Reset Source: Sends a T-Reset packet to the packet Source IP. • Reset Destination: Sends a T-Reset packet to the destination address. • Reset Bi-directional: Sends a TReset packet to both, the packet source IP and the packet destination IP.
Attack Type
Static or -defined attack type.
Risk
You can define the attack risk as High, Medium (default) or Low depending on the severity of the damage that the attack can cause to your system.
Direction
A certain protection policy may contain attacks that should be searched only for traffic from client to server or only on traffic from server to client. To provide simple and efficient scanning configuration you can set per attack the traffic direction for which it is relevant. Values: • Inbound: On traffic from policy Source to policy Destination • Outbound: On traffic from policy Destination to policy Source • Inbound & Outbound (default for custom attacks) : On all traffic between policy Source to policy Destination.
Suspend Action
This functionality allows the to define that for certain attacks, in addition to the action defined in the attack, the device should also suspend traffic from the IP address that was the source of the attack, for a period of time. Values: • 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, DestPort. Traffic from the IP address identified as source of this attack to the destination IP and port under attack will be suspended. • SrcIP, DestIP, Srort, DestPort. Traffic from the IP address and port identified as source of this attack to the destination IP and port under attack will be suspended.
Drop Threshold
The number of packets matching the attack 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.
Document ID: RDWR-AD-V021403-UG0211
479
AppDirector Guide Security
4.
Parameter
Description
Term Threshold
If for the duration of the Attack Aging Period this threshold is not exceeded, the status of the attack reverts to Dormant. You can also select Do not Deactivate (or 0).
Exclude Src
Exclude source IP address of the attack.
Exclude Dest
Exclude destination IP address of the attack.
State
Select Enable (default) to activate the policy.
Click Set. Your preferences are recorded.
Attacks The Attacks Database contains attacks provided by Radware. You can add -defined attacks to reflect specific needs of your network, or edit the existing attacks. The Attacks window allows you to edit existing attacks.
To edit a Attack 1.
From the Security menu, select Signature Protection > Attacks > . The Attacks Table window appears.
2.
Click Create. The Attacks Table Create window appears.
3.
Set the parameters.
Parameter
Description
ID
The unique identifying number (read-only).
Attack Name
-defined name for this attack. Attack Name is used when DoS Shield sends information about attack status changes (read-only).
Filter Name
The filter assigned to this attack (read-only).
Filter Type
The type of filter (read-only).
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 es through the device, during this defined time period, the device recognizes it as an attack. Default: 1000
Active 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: 10
480
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security
Parameter
Description
Tracking Type
Defines how the device decides which traffic to block or drop, when under an attack of this type. Values: • Drop All (default): Use when each packet of the defined attack is harmful. For example: Code Red and Nimda attacks. • Source Count: Select this option when the defined attack is sourcebased, meaning the hacker attack can be recognized according to its source address. For example: Horizontal Port Scan, were the hacker scans a certain application port (T or UDP) to detect which servers are available on the network. • Target Count: Select this option when the defined attack is destination-based, meaning the hacker is attacking a specific destination such as a Web server. For example: Ping Flood and DDoS attacks • Source and Target Count: Select this option when the attack type is a source and destination based attack, meaning the hacker is attacking from a specific source IP to a specific destination IP. For example: Port Scan attack. • Sampling: Select this option when the defined attack is based on sampling. The rate at which packets are sampled and compared to the Dormant Attacks.
Action Mode
When an attack is detected, one of the following actions can be taken: • Report Only: The packet is forwarded to the defined destination. • Drop (default): The packet is discarded. • Reset Source: Sends a T-Reset packet to the packet Source IP. • Reset Destination: Sends a T-Reset packet to the destination address. • Reset Bi-directional: Sends a TReset packet to both, the packet source IP and the packet destination IP.
Attack Type
Static or -defined attack type.
Risk
You can define the attack risk as High, Medium (default) or Low depending on the severity of the damage that the attack can cause to your system.
Direction
A certain protection policy may contain attacks that should be searched only for traffic from client to server or only on traffic from server to client. To provide simple and efficient scanning configuration you can set per attack the traffic direction for which it is relevant. Values: • Inbound: On traffic from policy Source to policy Destination • Outbound: On traffic from policy Destination to policy Source • Inbound & Outbound (default for custom attacks) : On all traffic between policy Source to policy Destination.
Document ID: RDWR-AD-V021403-UG0211
481
AppDirector Guide Security
Parameter
Description
Suspend Action
This allows you to define that for certain attacks, in addition to the action defined in the attack, the device should also suspend traffic from the IP address that was the source of the attack, for a period of time. Values: • 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, DestPort. Traffic from the IP address identified as source of this attack to the destination IP and port under attack will be suspended. • SrcIP, DestIP, Srort, DestPort. Traffic from the IP address and port identified as source of this attack to the destination IP and port under attack will be suspended.
Drop Threshold
The number of packets matching the attack 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.
4.
Term Threshold
If for the duration of the Attack Aging Period this threshold is not exceeded, the status of the attack reverts to Dormant. You can also select Do not Deactivate (or 0).
Exclude Src
Exclude source IP address of the attack.
Exclude Dest
Exclude destination IP address of the attack.
State
Select Enable (default) to activate the policy.
Click Set. Your preferences are rSecorded.
Copy Groups Radware attack characteristics are static, meaning the cannot change any of the filter properties. Changing the attack setting is possible, as the settings include the tracking values and action values. If you want to change an attack group, you can create a new -defined attack group or new defined attack, respectively. You can then modify, remove or add attacks to -defined groups. You can copy a complete group as a -defined attack, for which you can add, remove or modify attack including attack characteristics modifications.
482
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security
To create a new defined group 1. From the Security menu, select Signature Protection > Groups > Copy Groups. The Copy Groups window appears 2. Set the parameters.
Parameter
Description
Existing Group
Select the relevant existing group for which you wish to create a copy.
New Group
The defined New Group name.
3. Click Set. Your preferences are recorded.
Static Groups The Static Groups window displays a list of existing groups of static filters. You can select a group name to see a list of the group's static filters.
To view Static Groups 1. From the Security menu, select Signature Protection > Groups > Static. The Static Groups window appears. 2. Set the parameters.
Parameter
Description
Name
The name of the group.
Description
A description of the group.
Number of Filters
The number of static filters in the group.
3. Click Set. Your preferences are recorded.
Note: To see a list of filters in a group, from the Static Groups window click the name of the group. The Group Contents window appears with a list of the group's filters
Groups The Groups window allows you to create groups of filters.
To configure Groups 1. From the Security menu, select Signature Protection > Groups > . The Defined Groups window appears. 2. Click Create. The Create Group window appears
Document ID: RDWR-AD-V021403-UG0211
483
AppDirector Guide Security 3.
Set the parameters.
Parameter
Description
Group
The defined group.
Attack
Contains a dropdown list of Radware Static Attacks.
4.
Click Set. Your preferences are recorded.
5.
To add another filter to an existing group, from the Defined Groups window, click the required group's name. The Group Contents window opens.
6.
Click Create. The Add Attack Into Group window appears.
7.
From the Attack dropdown list, select the attack to add to the group, and click Set.
Copy Profiles If you want to change a profile, you can create a new -defined profile by copying a previously created profile and then renaming it. You can then change the new profile.
To copy a profile 1.
From the Security menu, select Signature Protection > Application Security Profiles > Copy Profiles. The Application Security Copy Profiles window appears
2.
Set the parameters.
3.
Parameter
Description
Existing Profile
Contains a dropdown list of all the existing profiles.
New Profile
Type the new profile name.
Click Set. Your preferences are recorded.
Static Profiles Radware profile characteristics are static, meaning the cannot change any of the filter properties. Changing the profile setting is possible, as the settings include the tracking values and action values. In the Profiles window you can create profiles, which can then be applied to policies.
To create a new Static profile 1.
From the Security menu, select Signature Protection > Profiles > Static. The Static Profiles window appears presenting the configured profiles.
2.
Set the parameters.
3.
484
Parameter
Description
Profile Name
The name of the defined profile.
DoS Attack
Select an attack that you want to associate with the new profile.
Click Set. The window closes and the new profile appears in the Profiles table.
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security
To add more attacks to the same profile 1. From the DoS Profiles table, click on the profile to which you want to add more attacks. The DoS Profile (profile name) Contents window appears. 2. Click Create. The Add DoS Attack To DoS Profile window appears with the name of the profile in the DoS Profile Name box. 3. From the DoS Attack dropdown list, select the attack that you want to add to the profile and click Set. The new attack appears in the DOS Attacks Table that contains attacks associated with this specific profile.
Profiles The Defined Profiles window allows you to create profiles.
To create a defined profile 1. From the Security menu, select Signature Protection > Profiles > . The Profiles window appears, with a table of the existing -defined profiles. 2. Set the parameters.
Parameter
Description
Profile
The defined profile name.
Group
The group to which the profile belongs.
Category
The category to which the profile belongs: Values: Anomalies, Anti-Scanning, DOS, Intrusion (default).
3. Click Set. Your preferences are recorded. 4. To add another group to an existing profile, from the Profiles window, click the required profile's name. The Profile Contents window opens. 5. Click Create. The Add Group To Profile window opens. 6. From the Group dropdown list, select the group to add to the profile, and click Set.
Signature Protection Policies A Protection Policy is a mechanism that scans traffic of a particular Network and a physical port. Protection Policies are applied on filter groups. A filter group uses basic and advanced filters as its building blocks.
To create a Policy 1. From the Security menu, select Signature Protection > Policies. The Policies window appears. 2. Click Create. The Policies Create window appears.
Document ID: RDWR-AD-V021403-UG0211
485
AppDirector Guide Security 3.
Set the parameters.
Parameter
Description
Policy Name
The name of the Policy that you define.
Policy Profile
The predefined Filter Group for which this policy is created.
Policy Source Address Definition of the network range to which the Policy is applied. Default: any. Policy Destination Address
Definition of the network range to which the Policy is applied.
Direction
Whether you want to apply the Policy to the defined network range only in one direction: source - destination (oneway); or in two directions: source - destination, destination - source (twoways). Default: Oneway.
Default: any.
Inbound Physical Port The physical port group of the device that receives the inbound traffic. Group State
Select Active to activate the policy.
Action
The action taken when the policy is activated. Values: Block and Report; Report Only.
VLAN Tag Group
4.
Defines VLAN traffic classification according to VLAN ID (VLAN Identifier) tags.
Click Set. Your preference are recorded.
Exclude Attacks Excluded Attack Addresses are used in Signature protection profiles only. When installing an IPS to protect a wide range of servers and Source IP addresses running different applications, certain filters cause false alarms to specific proprietary servers/applications. You can exclude these servers/ applications from being checked by the signatures causing the false alarms. The Excluded Attack Addresses window enables you to exclude particular Attacks from your network definitions.
To define what attacks to exclude 1.
From the Security menu, select Signature Protection > Exclude Attacks. The Signature Protection Attacks Excluded Addresses Configuration window appears.
2.
Click Create. The Signature Protection Attacks Excluded Addresses Configuration Create window appears
3.
Set the parameters.
Parameter
Description
State
Select Active to activate the policy.
Action
The action taken when the policy is activated. Values: Block and Report; Report Only.
VLAN Tag Group
4.
486
Defines VLAN traffic classification according to VLAN ID (VLAN Identifier) tags.
Click Set. Your preferences are recorded.
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security
Behavioral DoS The Behavioral DoS (B-DoS) module provides 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 preventing unknown flood attacks by identifying the footprint of the anomalous traffic. The B-DoS module protects against Network Flood Attacks, which cause a great deal of irrelevant traffic to fill available network bandwidth, denying the use of network resources to legitimate s. Network Flood protection types include: •
SYN Flood
•
T Flood
•
UDP Flood
•
ICMP Flood
•
IGMP Flood
The B-DoS module utilizes known network traffic base lines for each protocol type (i.e., T, UDP,ICMP and IGMP) and compares traffic anomalies with them. The next step is identifying the attack footprint, which translates into an attack signature. This module then configures a filter to protect the network according to the policy settings, and activates the module to optimize the signature and reduce false positives. Once the attack has ceased, the process is also responsible for removing the attack signature. The Behavioral DoS module detects statistical traffic anomalies and creates an accurate attack footprint (signature) based on heuristic protocol information analysis. This ensures accurate attack filtering with few false-positives. The SYN flood protection provided by the B-DoS module is nonintrusive detecting attacks as they happen, cleaning the links from excessive traffic. This security option contains these features: •
Behavioral DoS Global Parameters, page 488.
•
Behavioral DoS Profiles, page 488.
•
Behavioral DoS Policies, page 489.
•
Behavioral DoS Advanced Settings, page 490.
•
Behavioral DoS Bandwidth Parameters, page 491.
•
Behavioral DoS Learning Reset, page 491.
•
Behavioral DoS Set Default Quotas, page 492.
•
Behavioral DoS Protocol Quotas, page 492.
•
Behavioral T Footprint By, page 494.
•
Behavioral T Syn Footprint By, page 496.
•
Behavioral UDP Footprint By, page 497.
•
Behavioral ICMP Footprint By, page 499.
•
Behavioral IGMP Footprint By, page 499.
Document ID: RDWR-AD-V021403-UG0211
487
AppDirector Guide Security
Behavioral DoS Global Parameters The Behavioral DoS Global Parameters window allows you to enable Behavioral DoS Protection Status.
Note: To configure the Behavioral DoS module, a B-Dos license is required in addition to the DoS License.
To set Behavioral DoS Global Parameters: 1.
From the Security menu select Behavioral DoS > Global Parameters. The Behavioral DoS Global Parameters window appears.
2.
Set the parameters.
3.
Parameter
Description
Protection Status
Enable/disable (default) Behavioral DoS global parameters.
Click Set. Your preferences are recorded.
Behavioral DoS Profiles The Behavioral DoS Profiles allows you to create a Behavioral DoS profile. A profile defines the set of protocols for protection, which can then be assigned to the Behavioral DoS policy.
To set Behavioral DoS Profiles 1.
From the Security menu select Behavioral DoS > Behavioral DoS Profiles. The Behavioral DoS Profiles window appears.
2.
Click Create. The Behavioral DoS Profiles Create window appears.
3.
Set the parameters.
Parameter
Description
Profile Name
Enter a defined name for the profile.
T SYN flood status
Values: Active/Inactive (default) Select Active to protect against T SYN flood attacks in this profile.
UDP flood status
Values: Active/Inactive (default) Select Active to protect against UDP flood attacks in this profile.
ICMP flood status
Values: Active/Inactive (default) Select Active to protect against ICMP flood attacks in this profile.
T Reset Flood status Values: Active/Inactive (default) Select Active to protect against T reset flood attacks in this profile. T FIN+ACK Flood status
488
Values: Active/Inactive (default) Select Active to protect against protect against T FIN+ACK flood attacks in this profile.
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security
Parameter
Description
T Push+ACK Flood
Values: Active/Inactive (default) Select Active to protect against T Push+ACK Flood attacks in this profile.
IGMP flood status
Values: Active/Inactive (default) Select Active to protect against IGMP flood attacks in this profile.
4. Click Set. Your preferences are recorded.
Behavioral DoS Policies A Behavioral DoS security policy contains security profiles activated within predefined ranges of ports/VLANs, or within a predefined network. First, create a security policy, then assign protection profiles to the policy.
To set Behavioral DoS Policies 1. From the Security menu select Behavioral DoS > Behavioral DoS Policies. The Behavioral DoS Policies window appears. 2. Click Create. The Behavioral DoS Policies Create window appears. 3. Set the parameters.
Parameter
Description
Policy Name
The name of the defined policy.
Policy Profile
The predefined filter group for which this policy is created.
Policy Source Address
Definition of the network range to which the policy is applied.
Policy Destination Address
Definition of the network range to which the policy is applied.
Direction
Whether to apply Policy to defined network range only in one direction:
Default: Any. Default: Any. Values: • source - destination (oneway)= default • source - destination and destination - source (twoways).
Inbound Physical Port Group
Physical port group of the device that receives the inbound traffic.
State
Values Inactive/Active (default) Select Active to activate the policy.
VLAN Tag Group
Defines VLAN traffic classification according to VLAN ID (VLAN Identifier) tags.
Packet Report
Used to view a capture of an individual attack packet. Enable/disable (default) packet reporting for this attack.
Action
Action taken when the policy is activated. Values: Block and Report (default), Report Only.
4. Click Set. Your preferences are recorded.
Document ID: RDWR-AD-V021403-UG0211
489
AppDirector Guide Security
Behavioral DoS Advanced Settings The Behavioral DoS Advanced Setting allows you to set the Learning Response Period upon which baselines are primary weighed and enabling the Sampling status and defining the severity level of the Footprint.
Note: You must configure network flood protection separately for T floods, UDP floods, ICMP floods, and IGMP floods.
To set Behavioral Advanced Settings 1.
From the Security menu select Behavioral DoS > Advanced > Global Parameters. The Behavioral DoS Advanced Settings window appears.
2.
Set the parameters.
Parameter
Description
Learning Response Period
Defines the period upon which the baselines are primarily weighed. If major structural changes occur in the network, such as major bandwidth addition or reduction, new network-intensive applications are installed, or other major network changes, then you should change the Learning Response Period to day. Values: day, week (default), month
Sampling Status
The Sampling Status allows you to aggregate Traffic Statistics to improve performance levels. Select either: • Enable (default): Traffic statistics are aggregated through a sampling algorithm which improves overall performance of the AppDirector protection system. The risk: although the decision engine is tuned according to the sampling error, the chances for false positive decisions are increased. • Disable: Traffic statistic are aggregated without sampling.
Footprint Strictness
When a new attack is detected, the B-DoS module generates on the fly an attack signature to block the traffic anomaly created by the attack. As there is no mechanism free of false positives, there is a trade-off in this module between the false-positive rate and blocking rate. Define the strictness level of the footprint, either: Low: By setting the strictness to Low the device will perform best attacks blocking, however the false positive ratio is increased. Medium: Default 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.
3.
490
Click Set. Your preferences are recorded.
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security
Behavioral DoS Bandwidth Parameters The Behavioral DoS Bandwidth Parameters window allows you to configure the amount of Bandwidth for inbound and outbound traffic. To create a B-DoS security policy, you first need to define the Bandwidth settings for Behavioral DoS inbound and outbound traffic.
Note: Don’t forget to enter bandwidth values before you configure network protections.
To set Behavioral DoS Bandwidth Parameters 1. From the Security menu select Behavioral DoS > Advanced > Bandwidth Parameters. The Behavioral DoS Bandwidth Parameters window appears. 2. Set the parameters.
Parameter
Description
Inbound Bandwidth Available bandwidth for inbound traffic. The value should be lower than [Kbit/Sec] the bandwidth of the circuit or the assigned inbound bandwidth from your Internet Service Provider. Default: 300,000 Outbound Bandwidth [Kbit/ Sec]
Available bandwidth for outbound traffic. The value should be lower than the bandwidth of the circuit or the assigned outbound bandwidth from your Internet Service Provider. Default: 300,000
3. Click Set. Your preferences are recorded.
Behavioral DoS Learning Reset Behavioral DoS protection learns traffic parameters from the transport layer of incoming packets and generates normative baselines for traffic. The Learning Period setting defines the period based upon which baselines are primarily weighted. When the baseline for the policy is reset, the baseline traffic statistics are cleared and then AppDirector immediately initiates a new learning period. 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. The Behavioral DoS Learning Reset window allows you to reset the learning period for all, none or specific policies.
Document ID: RDWR-AD-V021403-UG0211
491
AppDirector Guide Security
To set the Behavioral DoS Learning Reset 1.
From the Security menu select Behavioral DoS > Advanced > Learning Reset. The Behavioral DoS Learning Reset window appears.
2.
Set the parameters.
Parameter
Description
Reset Baseline For Policy
From the dropdown list, select either: • None • All Policies according to the explanations provided.
3.
Click Set. Your preferences are recorded.
Behavioral DoS Set Default Quotas The Behavioral DoS Default Quotas can be set in the Behavioral DoS Set Default Quotas window.
To set the Behavioral DoS Default Quota 1.
From the Security menu select Behavioral DoS > Advanced > Set Default Quota. The Behavioral DoS Set Default Quota window appears.
2.
Click Set. Your preferences are recorded.
Behavioral DoS Protocol Quotas The Behavioral DoS Protocol Quotas window allows you to define the quota limits for the percentage of total inbound and outbound bandwidth that a specific protocol is permitted to use.
Note: You should always use the default quotas initially. Adjust quota values based on your experience with your network’s performance and usual protocol traffic characteristics.
To set the Behavioral DoS Protocol Quotas 1.
From the Security menu select Behavioral DoS > Advanced >Quotas. The Behavioral DoS Protocol Quotas window appears.
2.
Select a direction. The Behavioral DoS Protocol Quotas window appears.
3.
Set the parameters.
492
Parameter
Description
Direction
Inbound or Outbound according to which direction was selected from the table (Read-only).
T Quota [%]
Set the quota limits for the percentage of total inbound and outbound bandwidth for the T quota.
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security
Parameter
Description
UDP Quota [%]
Set the quota limits for the percentage of total inbound and outbound bandwidth for the UDP quota.
ICMP Quota [%]
Set the quota limits for the percentage of total inbound and outbound bandwidth for the ICMP quota.
IGMP Quota [%]
Set the quota limits for the percentage of total inbound and outbound bandwidth for the IGMP quota.
4. Click Set. Your preferences are recorded.
By Footprints Flood attacks commonly disrupt networks by using all or most of the available bandwidth. You can configure AppDirector to detect and block network flood attacks by defining attack footprints. Attack Footprints are selected fields in the packet header or payload. AppDirector automatically detects the footprints and generates filters to protect against the attack The following table displays the Footprint by types and values for each attack group.
Footprint Type
UDP
ICMP
T
IGMP
Default By Values
Range
Transport layer checksum
+
+
NR
+
Values cannot be configured.
No values.
T Sequence Number
NR
NR
+
NR
0 - (2^32-1)
IP ID Number
+
+
+
+
0 - (2^16-1)
DNS ID
+
NR
NR
NR
0 - (2^16-1)
DNS Qname checksum
+
NR
NR
NR
Values cannot be configured.
No Values.
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.25 5
ToS
+
Document ID: RDWR-AD-V021403-UG0211
+
+
+
1 - 255
493
AppDirector Guide Security
Footprint Type
UDP
ICMP
T
IGMP
Default By Values
Range
Packet Size
+
+
+
+
ICMP: 74 (60 L3)
0 - (2^16-1)
T Syn: 60, 62, 66, 74,(46, 48, 52, 60 L3) T ACK: 60 (46 L3) T ACK + FIN: 60 (46 L3) T RST: 60 (46 L3) Fragment
+
+
+
+
Destination Port
+
NR
+
nr
0 - (2^16-1)
Destination IP
+
+
+
+
0.0.0.0 255.255.255.25 5
ICMP/IGMP Message Type
NR
+
NR
+
0-255
TTL
+
+
+
+
0-255
Values cannot be configured.
No Values.
Behavioral T Footprint By The DoS Shield mechanism implements the sampling algorithm and accommodates traffic flooding targeted to create denial of network services. The Behavioral T Footprint By can be set in the Behavioral T Footprint By window.
To set the Behavioral T Footprint By 1.
From the Security menu select Behavioral DoS > Advanced > Footprint By > T. The Behavioral T Footprint By window appears.
2.
Select a by field. The Behavioral T Footprint By Update window appears.
494
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security 3. Set the parameters.
Parameter
Description
By Field
Enter the values for the By fields: • Sequence Number - The Sequence number value from the T packet header. • ID Number - The ID number from the IP packet header. • Source Port - The Source Port of the generated attack. • Source IP - The Source IP address of the generated attack. • ToS - The Type of Service value from the IP packet header. • Packet Size - The size of the packet in bytes, including data link header. • Destination Undefined Port - The destination T port of the attack, if the port is not defined in the Protected Service file for T SYN Attack protection. • Destination Undefined IP - The destination IP address of the attack if the host is not defined in the Protected Hosts file for T SYN Attack protection. • Fragment - T Fragmented Packet. • Destination Defined Port - The destination T port of the attack, if the port is explicitly defined in the Protected Services file for T SYN Attack protection. • Destination Defined IP - The destination IP address of the attack, if the host is explicitly defined in the Protected Hosts file for T SYN Attack protection. • TTL - Time-to-Live value in the IP packet header.
By Status
Allows you to define the status of the by, from the dropdown list. Values: Accept (default), By
By Values
Enter the by values for the By fields. • T Sequence Number: 0 - (2^32-1) • ID Number: 0 - (2^16-1) • Source Port: 0 - (2^16-1) • Source IP: 0 - (2^16-1) • ToS: 1-255 • Packet Size: 0 - (2^16-1) • Destination Undefined Port: 0 - (2^16-1) • Fragment : No values • Destination Defined Port: 0 - (2^16-1) • Destination Defined IP: 0.0.0.0 - 255.255.255.255 • TTL: 0 - 255
4. Click Set. Your preferences are recorded.
Document ID: RDWR-AD-V021403-UG0211
495
AppDirector Guide Security
Behavioral T Syn Footprint By The Behavioral T Syn Footprint By window allows you to update the T-SYN Footprint By fields.
To set the Behavioral T Syn Footprint By 1.
From the Security menu select Behavioral DoS > Advanced > Footprint By > T SYN. The Behavioral T Syn Footprint By window appears.
2.
Select a by field. The Behavioral T Syn Footprint By Update window appears.
3.
Set the parameters.
Parameter
Description
By Field
Enter the values for the By fields: • Sequence Number - The Sequence number value from the T/ SYN packet header. • ID Number - The ID number from the IP packet header. • Source Port - The Source Port of the generated attack. • Source IP - The Source IP address of the generated attack. • ToS - The Type of Service value from the IP packet header. • Packet Size - The size of the packet in bytes, including data link header. • Fragment - T/SYN Fragmented Packet. • Destination Defined Port - The destination T/SYN port of the attack, if the port is explicitly defined in the Protected Services file for T SYN Attack protection. • Destination Defined IP - The destination IP address of the attack, if the host is explicitly defined in the Protected Hosts file for T SYN Attack protection. • TTL - Time-to-Live value in the IP packet header.
By Status
496
Allows you to define the status of the by, from the dropdown list. Values: Accept (default), By
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security
Parameter
Description
By Values
Enter the by values for the By fields. • Sequence Number - The Sequence number value from the T/ SYN packet header. • ID Number - The ID number from the IP packet header. • Source Port - The Source Port of the generated attack. • Source IP - The Source IP address of the generated attack. • ToS - The Type of Service value from the IP packet header. • Packet Size - The size of the packet in bytes, including data link header. • Fragment - T/SYN Fragmented Packet. • Destination Defined Port - The destination T/SYN port of the attack, if the port is explicitly defined in the Protected Services file for T SYN Attack protection. • Destination Defined IP - The destination IP address of the attack, if the host is explicitly defined in the Protected Hosts file for T SYN Attack protection. • TTL - Time-to-Live value in the IP packet header.
4. Click Set. Your preferences are recorded.
Behavioral UDP Footprint By The Behavioral UDP Footprint By window allows you to update the UDP By field, status and values.
To set the Behavioral UDP Footprint By 1. From the Security menu select Behavioral DoS > Advanced > Footprint By > UDP. The Behavioral UDP Footprint By window appears. 2. Select a by field. The Behavioral UDP Footprint By Update window appears.
Document ID: RDWR-AD-V021403-UG0211
497
AppDirector Guide Security 3.
Set the parameters.
Parameter
Description
By Field
Enter the values for the By fields: • Enter in the values for the By fields: • Checksum - Checksum value in the UDP header of the packet. • Packet ID Number - ID number in the IP packet header. • DNS Query ID Number - ID number of a DNS query. • DNS Query Qname - Domain name requested by a DNS query. • DNS Qcount - Number of DNS queries in a single DNS session. • Source Port -Source port of the attack. • Source IP - Source IP address of the attack. • ToS -Type of Service value from the IP packet header. • Packet Size - Size of the packet in bytes, including the data-link layer. • Destination Undefined Port - Destination port of the attack, if this port is not defined in the Protected Services table. • Destination undefined IP - Destination IP address of the attack, if this host is not defined in the Protected Hosts Table. • Fragment - UDP fragmented packet. • Destination Defined Port - Destination port of the attack, if this port is defined in the Protected Services table. • Destination Defined IP - Destination IP address of the attack, if this host is defined in the Protected Hosts table. • TTL - Time-To-Live value in the IP packet header.
By Status
Allows you to define the status of the by, from the dropdown list. Values: Accept (default), By
By Values
Enter the by values for the By fields. • Checksum: No values • Packet ID Number: 0 - (2^32-1) • DNS Query ID Number: 0 - (2^16-1) • DNS Query Qname: No Values • DNS Qcount: 0 - (2^16-1) • Source Port: 0 - (2^32-1) • Source IP: 0.0.0.0 - 255.255.255.255 • ToS: 1- 255 • Packet Size: 0 - (2^16-1) • Destination Undefined Port: 0 - (2^16-1) • Destination undefined IP: 0.0.0.0 - 255.255.255.255 • Fragment : No values • Destination Defined Port: 0 - (2^16-1) • TTL: 0 - 255
4.
498
Click Set. Your preferences are recorded.
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security
Behavioral ICMP Footprint By ICMP Header Violation attacks exploits existing vulnerabilities in some of the IP stack implementations through corrupted ICMP packets (i.e., Unknown IM message types, etc.). The Behavioral ICMP Footprint By window allows you to update the ICMP By field, status and values.
To set the Behavioral ICMP Footprint By 1. From the Security menu select Behavioral DoS > Advanced > Footprint By > ICMP. The Behavioral ICMP Footprint By window appears. 2. Select a by field. The Behavioral ICMP Footprint By Update window appears. 3. Set the parameters. 4. Click Set. Your preferences are recorded.
Behavioral IGMP Footprint By The Behavioral IGMP Footprint By window allows you to update the IGMP By field, status and values.
To set the Behavioral IGMP Footprint By 1. From the Security menu select Behavioral DoS > Advanced > Footprint By > IGMP. The Behavioral IGMP Footprint By window appears. 2. Select a by field. The Behavioral IGMP Footprint By Update window appears. 3. Set the parameters. 4. Click Set. Your preferences are recorded.
Connection Limit The Dos-Shield module provides protection against known DoS attacks. To protect against unknown flooding attacks, AppDirector implements the connection limit capability. This mitigates any kind of T or UDP flood attack whether a half-open attack (SYN-attack), a connection attack or a request attack. This security option contains these features: •
Connection Limit Profiles, page 500
•
Connection Limit Policies, page 500
•
Connection Limit Attacks, page 501
Document ID: RDWR-AD-V021403-UG0211
499
AppDirector Guide Security
Connection Limit Profiles The Connection Limit Profiles window allows you to create a new Connection Limit profile.
To create a connection limit profile 1.
From the Security menu select Connection Limit > Profiles. The Connection Limiting Profiles window appears.
2.
Select Create. The Connection Limiting Profiles Create window appears
3.
Set the parameters.
4.
Parameter
Description
Connection Limiting Profile
Type in a defined name for your new profile.
Connection Limiting Attack
Select the type of attack from the dropdown list .
Click Set. Your preferences are recorded.
Connection Limit Policies The Connection Limit Policies window allows you to define a policy for the Connection Limit.
To create a connection limit policy 1.
From the Security menu select Connection Limit > Policy. The Connection Limiting Policy window appears.
2.
Select Create. The Connection Limiting Policy Create window appears
3.
Set the parameters.
Parameter
Description
Policy Name
The name of the policy to be applied.
Policy Profile
From the Policy dropdown list select the name of your profile created in the Behavioral DoS Profiles window.
Policy Source Address Definition of the external network range to which the Policy is applied. The range of IP addresses making up the protected network. You must enter the Policy Source Address of the protected network to activate protection. All defined protected hosts are automatically entered into the network range. Default: Any. Policy Destination Address
Definition of the internal network range to which the Policy is applied. The range of IP addresses making up the protected network You must enter the Policy Destination Address of the protected network to activate protection. All defined protected hosts are automatically entered into the network range. Default: Any.
500
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security
Parameter
Description
Direction
From the dropdown list select the direction of your policy, either: • Oneway (default) - Protects from attacks from the external to internal (inbound traffic) • Twoway - Protects from attacks from external to Internal and from Internal to external (outbound).
Inbound Physical Port Group
The physical port group of the device that receives the inbound traffic.
State
Select Active to activate the policy. • Active (default) • Inactive
VLAN Tag Group
Defines VLAN traffic classification according to VLAN ID tags.
Action
Defines the required action of the policy, select either: • Report Only. • Block and Report (default)
4. Click Set. Your preferences are recorded.
Connection Limit Attacks The Connection Limit Attacks window allows you to define a Connection Limit Attack.
To create a connection limit attack 1. From the Security menu select Connection Limit > Attacks. The Connection Limiting Attack window appears. 2. Select Create. The Connection Limiting Attack Create window appears. 3. Set the parameters.
Parameter
Description
ID
The unique identifying number (read-only).
Attack Name
-defined name for this attack. Attack Name is used when DoS Shield sends information about attack status changes (read-only).
Destination App. Port
Group of Layer 4 ports that represent the application that you want to protect.
Protocol
Layer 4 protocol of the application that you want to protect, T/UDP.
Threshold
Maximum number of sessions per second that allowed for each Layer3 entity tracked by this attack – any additional session is dropped. When the threshold is reached an attack is identified and alert is sent. Default: 10
Document ID: RDWR-AD-V021403-UG0211
501
AppDirector Guide Security
Parameter
Description
Tracking Type
Defines how the device decides which traffic to block or drop, when under an attack of this type. Values: • Drop All (default): Use when each packet of the defined attack is harmful. For example: Code Red and Nimda attacks. • Source Count: Select this option when the defined attack is sourcebased, meaning the hacker attack can be recognized according to its source address. For example: Horizontal Port Scan, were the hacker scans a certain application port (T or UDP) to detect which servers are available on the network. • Target Count: Select this option when the defined attack is destination-based, meaning the hacker is attacking a specific destination such as a Web server. For example: Ping Flood and DDoS attacks • Source and Target Count: Select this option when the attack type is a source and destination based attack, meaning the hacker is attacking from a specific source IP to a specific destination IP. For example: Port Scan attack.
Action Mode
When an attack is detected, one of the following actions can be taken: • Report Only: The packet is forwarded to the defined destination. • Drop (default): The packet is discarded. • Reset Source: Sends a T-Reset packet to the packet Source IP. • Reset Destination: Sends a T-Reset packet to the destination address. • Reset Bi-directional: Sends a TReset packet to both, the packet source IP and the packet destination IP.
Risk
You can define the attack risk as High, Medium, or Low depending on the severity of the damage that the attack can cause to your system. Default: Medium
Tracking Time
Sets the amount of time, in milliseconds, for measuring Threshold. When a number of packets exceeding the Threshold value es through the device within the configured Tracking Time period, the device recognizes it as an attack. Default: 1000
502
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security
Parameter
Description
Suspend Action
This enables you to define that for certain attacks, in addition to the action defined in the attack, the device should also suspend traffic from the IP address that was the source of the attack, for a period of time. Values: • 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, DestPort. Traffic from the IP address identified as source of this attack to the destination IP and port under attack will be suspended. • SrcIP, DestIP, Srort, DestPort. Traffic from the IP address and port identified as source of this attack to the destination IP and port under attack will be suspended.
4. Click Set. Your preferences are recorded.
Global Suspend Table The Suspend Table allows you 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
The period for which a source is suspended is set according to the following algorithm: The first time a source is suspended, the suspension time is according to the Minimal Aging Time configured for the Suspend Table. Each time the same source is suspended again the suspension length is doubled, until it reaches the Maximum Aging Time set for the Suspend Table. Once the suspension length has reached the maximum length allowed, it will remain constant for each additional suspension. This security option contains these features: •
Global Suspend Table Parameters, page 504
•
Global Suspend Table, page 504
Document ID: RDWR-AD-V021403-UG0211
503
AppDirector Guide Security
Global Suspend Table Parameters The Suspend Table Parameters window enables you to set the tuning parameters for the Suspend Table.
To set the Suspend Table parameters 1.
From the Security menu select Global > Suspend Table > Parameters. The Suspend Table Parameters window appears.
2.
Set the parameters.
Parameter
Description
Suspend Table min. blocking time [Sec]
Length of time for which source IPs that are “first-time offenders” are suspended. Default: 10 seconds
Suspend Table max blocking time [Sec]
Maximum length of time for which a source IP can be suspended.
Suspend Table max same source entries
If the number of entries for the same source IP is higher than this threshold all traffic from this source IP is suspended (this can happen when Suspend Action is not set to SrcIP only)
Default: 600 seconds
Default: 4 3.
Click Set. Your preferences are recorded.
Global Suspend Table The Suspend Table window allows you to view and monitor attacks that are currently in the Suspend Table.
To view the Suspend Table From the Security menu select Global > Suspend Table > Table. The Suspend Table Parameters window appears, which contains the following read-only parameters.
Security 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 the specific attack. Once an event has been created, the device reports it in the following ways: •
Security Logs, which are saved in a flash.
•
SNMP traps.
•
Syslog messages can be sent to a Syslog station.
•
E-mail messages can be sent to specific s.
•
Security Terminal Echo
You can enable the reporting channels used by Radware devices to receive information about security events. You can also set the device to report detected attacks based on various risk levels.
504
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security The Security Reporting option contains these features: •
Reporting Global Parameters, page 505
•
NetForensics, page 506
•
Top Ten Attacks, page 506
•
Reporting Security Log Show, page 507
•
Reporting Security Log Clear, page 509
Reporting Global Parameters The Reporting Global Parameters window allows you to enable AppDirector reporting channels, set the polling time parameters of the Alert Table and the Log File.
To define the Reporting Global Parameters 1. From the Security menu, select Reporting > Global Parameters. The Global Parameters Information window appears. 2. Set the parameters.
Parameter
Description
Report Interval
Number of seconds that defines frequency in which the reports are sent though the reporting channels. Default: 5
Max Alerts per Report
Number of alerts that define the maximum number of security events that can appear in each report (sent within the reporting interval). Default: 1000
Report Per-Attack Aggregation Threshold
Sets the number of events for a specific attack during a reporting interval before the events are aggregated to a report. Default: 5 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."
SNMP Traps Sending Enable/Disable (default) sending of SNMP traps. Syslog Sending
Enable/Disable (default) sending of syslog.
Terminal Echo
Enable/Disable (default) reporting using the terminal echo.
Email Sending
Enable/Disable (default) sending email reports.
SNMP Traps Sending Defines the risk level. Risk Values: Low (default), Medium, High Email Sending Risk
Defines the risk level. Values: Low (default), Medium, High
Terminal Echo Risk
Defines the risk level. Values: Low (default), Medium, High
Syslog Sending Risk Defines the risk level. Values: Low (default), Medium, High
Document ID: RDWR-AD-V021403-UG0211
505
AppDirector Guide Security
Parameter
Description
Security Log Status
All events and alerts are logged in an all-purpose cyclic Log File. The Log File can be obtained at any time but its size is limited. When the number of entries is beyond the permitted limit, the oldest entries are overwritten. You are notified about the status of Log File utilization. Notifications appear when the file is 80% utilized and 100% utilized. Values: Enable/Disable (default)
3.
Click Set. Your preferences are recorded.
NetForensics netForensics is a Security Information Management (SIM) that gathers information from various security equipment in the network and provides analysis tools and a unified view of network security. netForensics s the collection of security events generated by Radware devices.
To set the NetForensics parameters 1.
From the Security menu, select Reporting > NetForensic. The NetForensic Reporting Configuration window appears.
2.
Set the parameters.
Parameter
Description
Reporting Status
Defines reporting status to NetForensic agent. Values: Enabled/Disabled (default)
Agent IP Address
The IP address of the NetForensic collector. Default: 0.0.0.0
Agent Port
The T listening port of the NetForensic collector. Default: 555
3.
Click Set. Your preferences are recorded.
Top Ten Attacks Predefined attack reports help you to explore Security attack patterns over time. Radware has created predefined reports for specific types of attack analysis. Attacks can be ranked by volume and by type. Predefined reports also include reports for groups of attacks, or attacks relating to a specific module. Predefined reports allow you to focus attention on specific threats. Attack information is pre-sorted, with the most important security event information plotted in easily read charts, for your convenience. The following predefined attack reports are available:
Parameter
Description
SNMP Traps Sending Risk
Defines the risk level.
Email Sending Risk
Defines the risk level.
Values: Low (default), Medium, High Values: Low (default), Medium, High
506
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security
Parameter
Description
Terminal Echo Risk
Defines the risk level. Values: Low (default), Medium, High
Syslog Sending Risk
Defines the risk level. Values: Low (default), Medium, High
Security Log Status
All events and alerts are logged in an all-purpose cyclic Log File. The Log File can be obtained at any time. The size of Log File is limited. 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. Values: Enable/Disable (default)
To generate a predefined report 1. From the Security menu select Reporting > Top Ten Attacks. The Top Ten Attacks window appears. 2. Set the parameters.
Parameter
Description
Choose Type
Select the type of attack report you want.
Seconds
Enter the number of seconds (retroactive from the current time) for the report.
3. Click Set. The report is generated and displayed.
Reporting Security Log Show When the device recognizes security events, they are logged in a cyclic Log File. This can be accessed at any time, but it is limited; when the entry number exceeds the limit, the oldest entries are overwritten. Notifications about the Log File utilization status appear when the file is 80% and 100% utilized. To start logging, configure one or more devices to perform logging. All events and alerts are logged in an all-purpose cyclic Log File. This can be obtained at any time.
To The size of Log File is limited. 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.view alerts 1. From the Security menu, select Reporting > Security Log > Show. The Security Log File window appears. 2. From the Logfile Table, click on the Attack Index number to view the event parameters of the attack. The Security Log File Update window appears, showing the event parameters.
Document ID: RDWR-AD-V021403-UG0211
507
AppDirector Guide Security 3.
Set the parameters.
Parameter
Description
Attack Index
The number of the entry in the table.
Radware ID
ID Radware’s unique identifier of the attack.
Attack Name
The name of the attack that was detected.
Attack Source Address The IP address from which the attack arrived. Attack Destination Address
The IP address to which the attack is destined.
Message Type
The current status of the event: • Occurred - Each packet matched with signatures is reported as an attack and must be dropped. In that case the Tracking Type that is activated is Drop All. • Started/terminated - When the amount of packets that match with signatures, goes beyond the predefined threshold within the Tracking Time, the reported Attack Status is started. When the amount of packets that match with signatures is below the predefined threshold, the reported Attack Status becomes terminated. In that case the Tracking Type that is activated is Target, or Target & Source.
Attack Time
The time and date when the report was generated.
Source Port
T/UDP source port.
Destination Port
T/UDP destination port
Context
Context in which the attack was recognized: Regular/ SSL tunneling.
Protocol
The transmission protocol used: T/ UDP/ ICMP/IP.
Physical Port
The port on the device from which the attack arrived.
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: AppDirector on Application Switch 4 does not VLAN Tagging, and a value of "0" is always placed.
Category
The category of the attack: Anomalies, Anti-Scanning, DOS, Intrusion.
Policy Name
The policy that was used to detect the attack.
Packet Count
The number of packets in the attack since the latest trap was sent.
Byte Count
The number of Bytes that were dropped/forwarded.
Action
The reported action can be: • Forward: The packet is forwarded to its destination. • Drop: The packet is discarded. • Reset Source: Sends a T-Reset packet to the packet Source IP. • Reset Destination: Sends a T-Reset packet to the destination address.
508
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security
Parameter
Description
Report Mode
The following Report Modes are available: • Drop: The packet is discarded. • Forward: The packet is forwarded to the defined destination. • Reset Source: Sends T-Reset packet to the packet Source IP. • Reset Destination: Sends T-Reset packet to the destination address. • Default: Takes the Action Mode parameter defined in the Application Security Global Parameters window.
Risk
How dangerous the attack is: High, Low, Medium, Not Available.
4. Click Set. The report is generated and displayed.
Reporting Security Log Clear The Security Log Clear window allows you to clear the previously created log.
To clear the Log 1. From the Security menu select Reporting > Security Log > Clear. The Clear Security Log window appears. 2. Click Set. The Security log is cleared.
Attack Database The Dormant Attacks database is a list 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 existing DoS attacks can be prevented using Radware attacks.
Attack Database Version The Attack Database Version window is a read-only window displaying the version of the current attack database.
To view the attack database version From the Security menu select Attack Database > Version. The Attack Database Version window appears, displaying the version number of the current attack database.
Attack Database Send to Device The Application Security module uses the Application Security Signature File Update feature for constant updates of the signatures database. All devices with the Application Security module are updated using the latest Application Security Signature file, which is a database that contains a list of updated attacks. The update of the Application Security Signature File is performed per device using the Send to Device window.
Document ID: RDWR-AD-V021403-UG0211
509
AppDirector Guide Security You can an updated Application Security Signature file from the Radware Web site every Monday. If an emergency update is required, the Web site is updated in addition to weekly updates.
To view the Attack Database version: 1.
From the Security menu, select Attack Database > Send to Device. The Send to Device window appears displaying the current Attack Database version of the device.
2.
From the File field, type the name of the file, or click Browse to navigate to the relevant file.
3.
Click Set.
View Active Policy Extensions You can view the additional policy parameters in the Active Policies Extensions window.
To view Active Policies Extensions From the BWM menu, select View Active > Policy Extensions. The Active Policies Extensions window appears, which contains these read-only parameters.
Parameter
Description
Name
The -defined name of the policy.
Classification Point
Indicates whether classification is performed before/after packet modification. • After Changes: Classifies the device after the packet changes. • Before Changes: Classifies the device before the packet changes.
Traffic Flow Identification
Defines what type of traffic flow we are going to limit via this policy. The available options are: • 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).
Traffic Flow Max BW (Kbps)
Maximum bandwidth in Kbps allowed per traffic flow.
Max Concurrent Sessions
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 HTTP Rqts 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 or Post or HEAD per Cookie.
Cookie Field Identifier
String that identifies the cookie field whose value must be used to determine the different traffic flows. Note: This is required only when Traffic Flow Identification is set to SessionCookie. The BWM classifier searches for the Cookie Field Identifier followed by “=” and classifies flows according to value.
510
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security
Parameter
Description
Policy Group
Select from the list of the defined policy groups.
Inactivation Schedule
You can schedule the inactivation of specific Bandwidth Management policies. Using 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.
Modify Policy Group 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, enabling them to borrow from other policies preventing starvation and utilizing the bandwidth more efficiently. Only policies that participate in a specific group can share bandwidth. To total bandwidth available for a policy group is the sum of Guaranteed Bandwidth values of all policies in the group. The Policies Group table contains all the bandwidth policy groups. You can add new policy groups to this table.
Note: For all the policies associated with a policy group, the Guaranteed Bandwidth parameter must be set to a value greater than 0 and Borrowing Limit parameter to 0. The Dynamic Borrowing global parameter must be enabled.
To create a new Policy Group 1. From the Bandwidth Management menu, select Modify > Policy Groups. The Modify Policy Group Table window appears. 2. Click Create. The Modify Policy Group Table Create window appears. 3. In the Name text box, type the name of the new Policy Group and click Set. The new policy group appears in the Modify Policy Group Table window and the Active Policy Group Table.
Editing Port Bandwidth To optimize the queuing algorithm, it is essential for the BWM 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 is determined by the port type - 100 Mbps for FE ports and 1Gbps for Giga ports. The queuing filter only starts functioning upon link saturation. Configuring the maximum is the only way to determine if the link is saturated.
To edit Port Bandwidth 1. From the BWM menu select Miscellaneous > Port Bandwidth Table. The Port Bandwidth Table window appears. 2. Select the port for which you require to edit the bandwidth. The Port Bandwidth Table Update window appears.
Document ID: RDWR-AD-V021403-UG0211
511
AppDirector Guide Security 3.
4.
Set the parameters.
Parameter
Description
Port Index
The port number.
Port Bandwidth (kbps)
The bandwidth available to the specific port.
Port Used Bandwidth (kbps)
The amount of bandwidth used on the specific port.
Click Set. Your preferences are recorded.
Cancel Classification Per Port This feature enables the to configure ports where classification is not performed. In this way valuable processing time can be saved while enabling a simpler method of configuring the device. Cancel Classification Per VLAN is also available for a VLAN configuration.
To cancel classification for a port 1.
From the BWM menu select Miscellaneous > Cancel Classification Per Port. The Cancel Classification Per Port window appears.
2.
Set the parameters.
3.
Parameter
Description
Inbound Port
The number of the required port for inbound traffic.
Outbound Port
The number of the required port for outbound traffic.
Direction
Direction of traffic 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.
Click Set. Your preferences are recorded.
Update Policies In case you edit the parameters of a basic filter or an advanced filter, which is bound to the existing policy, you need to update the policy with the recent changes.
To activate the latest changes 1.
From Security menu, select Update Policies. The Activate Latest Changes window appears.
2.
Click Set. The policies are updated.
Packet Anomalies To avoid detection, hackers use evasion techniques, such as splitting packets and sending attacks in fragments. An attack that contains fragmented packets is called a Protocol Anomaly attack. These attacks are detected and blocked.
512
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security Whenever a packet matching one of the predefined checks arrives, it is automatically blocked ,discarded and reported. However you can also allow certain anomalous traffic to flow through the device without inspection. The Packet Anomalies window allows you to allow certain packets to through the device without inspection and defining the risk factor.
To set the Packet Anomalies parameters 1. From the Security menu, select Packet Anomalies > Attacks. The Packet Anomalies Attacks window appears. 2. Select the relevant ID from the table. The Packet Anomalies Attacks Update window appears. 3. Set the parameters.
Parameter
Description
ID
Displays the selected ID number of the packet selected from the table.
Name
Displays the name of the Packet Anomaly according to what was selected in the Packet Anomalies table.
Action
From the dropdown list, define the action for the Packet Anomaly, select either: • Forward: Selecting Forward means that the packet is allowed to through the device without inspection. • Drop: Selecting Drop means that the Packet is dropped.
Risk
Define the risk for the Packet Anomaly according to your preference. Values: Info, Low, Medium, High
4. Click Set. Your preferences are recorded.
Modifying Application Port Groups Application Port Groups represent the Layer 4 ports for UDP and T traffic. Each group is identified by its unique name and each group name can be associated with a number of entries in the Application Port Groups table.
To create the Modify Appl. Port Groups Table parameters 1. From the Classes menu, select Modify Appl Port Groups. The Modify Appl. Port Groups Table window appears. 2. Click Create. The Modify Appl. Port Groups Table Create window appears. 3. Set the parameters..
Parameter
Description
Name
A defined group name.
From Port
Define the first port in the range. (Values from 0)
To Port
Define the last port in the range.(Values to 65535)
Group Type
Defines the group type either static or regular.
Document ID: RDWR-AD-V021403-UG0211
513
AppDirector Guide Security
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 Set. Your preferences are recorded.
To update the parameters of the Modify Appl. Port Groups Table 1.
From the Classes menu, select Modify Appl Port Groups. The Modify Appl. Port Groups Table window appears.
2.
Click on the application name. The Modify Appl. Port Groups Table Update window appears. Proceed from step 3.
Viewing Application Port Groups
To view active application port groups 1.
From the Classes menu, select View Active > Appl Port Groups. The Active Application Port Groups Table window appears.
2.
Select the desired name. The Active Application Port Groups Table Update window appears with read-only parameters. See To create the Modify Appl. Port Groups Table parameters, page 513.
Modify MAC Groups
To modify MAC Groups 1.
From the Classes menu select Modify > MAC Groups. The Modify MAC Address Groups Table appears.
2.
Click Create. The Modify MAC Address Groups Table Create window appears.
3.
Set the parameters.
4.
514
Parameter
Description
Group Name
The name of the MAC address group.
MAC Address
A MAC address number.
Click Set. Your preferences are recorded.
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security
View Active MAC Groups To classify traffic according to Mac addresses, you can create groups of Mac addresses.
To view the Active MAC Groups: From the Classes menu select View Active MAC Groups. The Active MAC Address Groups Table window appears with read-only parameters. See To modify MAC Groups, page 514.
View Active VLAN Tag Groups The Active VLAN Tags Table Update window allows you to view the active VLAN tag groups.
To view the Active VLAN Tag Groups 1. From the Classes menu select View Active VLAN tag Groups. The Active VLAN Tags Table window appears. 2. Select a group name. The Active VLAN Tags Table Update window appears which contains the following read-only parameters:
Note: This is applicable only when the 802.1q parameter is set to Enabled. Classifications performed according to the tag of the received packet.
Modify Port Groups You can set different policies to identical traffic classes that are received on different interfaces of the device. For example, you can allow access to the main server only to traffic entering the device via physical interface 3. This provides greater flexibility in configuration. You must first configure Port Groups, which are collections of Physical Interfaces of the device, and then associate a Port Group to the required policies. The Modify Physical Port Groups Table window allows you to modify an existing port group.
To modify a port group 1. From the Classes menu, select Modify Port Groups. The Modify Physical Port Groups Table window appears. 2. Select a group name. The Modify Physical Port Groups Table Update window appears. 3. Set the parameters.
Parameter
Description
Group Name
The -configured name of the port group.
Inbound Port
The inbound port for this group. Values can be a port number or Any.
4. Click Set. The Port Group is configured.
Document ID: RDWR-AD-V021403-UG0211
515
AppDirector Guide Security
To create a new port group 1.
From the Classes menu select Modify >Port Groups. The Modify Physical Port Groups Table window appears.
2.
Select Create. The Physical Port Groups Table Create window appears. Proceed as step 3.
Application Security Tuning From the Application Security Tuning Parameters window you can view and edit the application security tuning parameters. The changes take effect after the reset.
Caution: It is strongly advised that Application Security tuning only be performed after consulting Radware Technical .
To tune AppDirector Application Security tables 1.
From the Services menu, select Tuning > Security > Application Security. The Application Security Tuning window appears.
2.
Set the parameters.
Parameter
Description
Source Table
The current number of entries in the Source Table that contains attacks detection mechanism, which is based on the source addresses of the incoming traffic. If the number of packets sent from the same source is above the predefined limit, this is identified as an attack. The Source Table tuning parameter defines in how many sessions to check the source address.
Source Table After Reset
The number of entries in the Source Table after reset.
Target Table
Represents the current size of the table for destination entries. This table contains attacks detection mechanism, which is based on the destination addresses of the incoming traffic. If the number of packets sent to the same destination is above the predefined limit, this is identified as an attack. The Target Table tuning parameter defines in how many sessions to check the destination address.
516
Target Table After Reset
The size of the table for destination entries that you define. The settings are applied after reset.
Source and Target Table
Represents the current size of the table for both source and destination entries, which are counted as one.
Source and Target Table After Reset
The size of the table for both source and destination entries that you define. The settings are applied after reset.
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Security
Parameter
Description
DH Table
The current number of entries in the DH Table that contains attacks detection mechanism based on counting of IP requests for each MAC address. The requests are made using the Dynamic Host Configuration Protocol. When the number of IP requests for a particular MAC address is above the predefined limit, an attack is identified. The DH Discover tuning parameter determines for how many MAC addresses to check the number of IP requests.
DH Table After Reset
Number of entries in the DH Table after reset.
Maximal number of groups to be defined by
Maximum number of defined groups that can be defined on the device.
Maximal number of groups to be defined by after reset
Maximum number of defined groups that can be defined on the device after reset.
Maximal number of attacks to be defined by
Maximum number of defined attacks that can be defined on the device.
Maximal number of attacks to be defined by after reset
Maximum number of defined attacks that can be defined on the device after reset.
IP Reassembly buffers Current allotted memory, in MB, of the IP Reassembly buffers pool. pool size [MB] IP Reassembly buffers Allotted memory, in MB, of the IP Reassembly buffers pool after reset. pool size after reset [MB] Maximal number of entries in NF table
Maximum number of entries that can be defined in the NPCF table.
Maximal number of entries in NF table after reset
Maximum number of entries that can be defined in the NPCF table after reset.
Maximal number of srcIPs in Suspend Table
Maximum number of entries that can be defined in the Suspend table.
Maximal number of srcIPs in Suspend Table after reset
Maximum number of entries that can be defined in the Suspend table after reset.
Maximal number of Maximum number of entries that can be defined in the Anti-Scanning IP Anti-Scanning IP pairs pairs table. Table Maximal number of Maximum number of entries that can be defined in the Anti-Scanning IP Anti-Scanning IP pairs pairs table after reset. Table after reset 3. Click Set. Your preferences are recorded.
Document ID: RDWR-AD-V021403-UG0211
517
AppDirector Guide Security
Behavioral DoS Tuning Parameters The Behavioral DoS Tuning Parameters window allows you to set the maximal number of Behavioral DoS policies. The default number of policies for Behavioral DoS is 10. If you wish to configure more then you need to reset the number of policies allowed.
Note: Each time you update a value for a Behavioral DoS, you can check whether there is enough free memory for the requested value.
To set the maximum number of Behavioral DoS policies 1.
From the Services menu, select Tuning > Security > Behavioral DoS. The Behavioral DoS Tuning Parameters window appears.
2.
Set the parameters.
3.
518
Parameter
Description
Maximal number of Behavioral DoS policies
Maximum number of Behavioral DoS policies that can be defined on the device.
Maximal number of Behavioral DoS policies after reset
Maximum number of Behavioral DoS policies that can be defined on the device after reset.
Click Set. Your preferences are recorded.
Document ID: RDWR-AD-V021403-UG0211
Appendix A – Radware Technical Glossary This glossary is a list of and definitions used in the Radware technical environment. Some of the words belong to the public domain, and some are Radware-specific, but all are used in the Radware documentation.
Term
Definition
802.1Q Trunking
802.1Q Trunking is an IEEE protocol that interconnects VLANs between multiple switches, routers, and servers. With 802.1Q. A network can define a VLAN topology to span multiple physical devices. When VLANs are physically attached to different switches, because the trunk link carries traffic for all of these VLANs, all the s in a given VLAN are in the same broadcast domain. IEEE 802.1Q switches normally FastEthernet and GigabitEthernet interfaces. An 802.1Q trunk link provides VLAN identification by adding a 4byte tag to an Ethernet Frame as it leaves a trunk port. Because the frame has been changed, a new frame check sequence (FCS) must also be computed and added to the frame.
Active-Active
Active-Active is a redundancy configuration involving two AppDirector devices (both must be the same type) where each device can be both the Active device for predefined Farms and the Backup device for other Farms. In the event of a failure of one device, the other device temporarily assumes ownership of all Farms.
Active-Backup
In an Active/Backup configuration, the primary AppDirector device is configured with the primary Virtual IP addresses. This device performs the regular AppDirector operations, handling all the inbound sessions to the Virtual IP addresses and distributing traffic among the servers in the farm linked to the Virtual IP address (via Layer 4 Policy).
Document ID: RDWR-AD-V021403-UG0211
519
AppDirector Guide Radware Technical Glossary
Term
Definition
Application Delivery Controller (ADC)
Application Delivery Controllers (ADCs) enhance the performance and security of Web- or Internet Protocol-based applications for end s by providing a suite of services at the network and application layers. ADCs reside in the data center, in front of frontline Web servers; devices for optimizing response time of applications on a network, using load balancing technologies on Layer 4-7. They are deployed asymmetrically (only at the data center end). These services can include: • Layer 4 through Layer 7 redirection, load balancing and failover. • Transmission Control Protocol (T) connection multiplexing. • Server offloading (for example, SSL termination and T connection management). • Data compression. • Network-address translation. • Network-level security functions, distributed denial-of-service protection and server cloaking. • Selective compression. • Caching. • Content transformation and rewrite. • Application firewall. • Transaction assurance. • Rules and programmatic interfaces. • HTML (and other application protocol) optimizations — "pre-fetching" or selective encoding. • Virtualization.
Application Delivery Network
An Application Delivery Network (ADN) is a suite of technologies that, when deployed together, provide application availability, security, and acceleration. At the core of an ADN is the Application Delivery Controller (ADC), an advanced traffic management device that is often also referred to as a web switch, content switch, or multilayer switch, the purpose of which is to distribute traffic among a number of servers or geographically dislocated sites based on application specific criterion. The ADN evolved from Layer 4-7 switches in the late 1990s when it became apparent that traditional load balancing techniques were not robust enough to handle the increasingly complex mix of application traffic being delivered over a wider variety of network connectivity options.
AND Group
520
An AND Group is a combination of basic services (link) with a logical AND between them. AND Group is defined as a part of Classes (link) traffic characterization.
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Radware Technical Glossary
Term
Definition
Anycast
Anycast is a network addressing and routing scheme that allows a single IP address to be announced from multiple locations. Data is routed to the "nearest" or "best" destination as determined by the routing topology, such as Proximity. With Anycast, although it is a one-to-many association, only one receiver is chosen, as determined by proximity. With Unicast, there is a one-to-one association between source and receiver. With Broadcast and Multicast, there is a one-to-many association between the source address and network endpoints (all information is replicated). Anycast offers two failover mechanisms: Equal Anycast uses standard routing protocols (BGP, OSPF, and RIP) to service availability from all global AppDirector sites. It relies on the routing logic to govern the delivery of messages to one of these locations. Using “Equal Anycast” optimizes the response time, as each request is routed to the closest site. Prioritized Anycast allows the selective failover mechanism by advertising the service with different priorities to different locations. As a result, once a site fails, the routing system will immediately redirect its traffic to the backup sites. “Prioritized Anycast” allows transparent application continuity in case of site failure.
API
An Application Programming Interface (API) is a source code interface that a computer application, operating system or library provides to requests for services to be made of it by a computer program. An API is similar to an Application Binary Interface (ABI) in that it specifies details of how two independent computer programs can interact, however an API is defined at a higher level.
AppDirector (Radware)
Radware AppDirector (AD) is an intelligent application delivery controller for data centers that provides scalability and application-level security for IT infrastructure optimization, fault tolerance and redundancy. AppDirector combines the power of Radware’s Multi-Gigabit Application Switching hardware with APSolute OS Application-Smart Networking to ensure local and global server availability, accelerated application performance and safeguard applications with integrated intrusion prevention and denial of service protection for fast, reliable, secure application delivery. AppDirector uses advanced Layer 4-7 policies and granular application intelligence for end-to-end application-smart networking, aligning server infrastructure operations with application front end requirements to eliminate traffic surges, server bottlenecks, connectivity disconnects and downtime for assured application access, full application continuity and redundancy. AppDirector enables fine tuning of network behavior at all critical points, endto-end, based on granular application-specific classification of packets to optimize traffic flows for a wide range of enterprise web applications such as CRM, ERP, and other IP-based applications including for VoIP, streaming media, and secure LDAP applications.
Document ID: RDWR-AD-V021403-UG0211
521
AppDirector Guide Radware Technical Glossary
Term
Definition
Application Delivery Controller (Radware)
Radware’s Application Delivery Controller (ADC) solution ensures application uptime and transaction completion through real time identification and bying of inactive / faulty elements along the transaction path (such as, application failure, server failure, server farm failure or site failure). The integrated local and global load balancing capabilities provide the industry’s most comprehensive disaster recovery solution for globally dispersed data centers, guaranteeing optimal response time and application availability at all times. ADC provides: • Removal of performance bottlenecks • Full availability of the entire transaction path, accelerating response time across Wide Area Network connections • Comprehensive mitigation of network and application level attacks
Application Grouping
Application Grouping allows you to select the next hop routers to handle traffic destined for a specific application port.
APSolute Operating System
The APSolute Operating System is the operating system for the Radware ASIC-based Application Switches. The AppDirector is based on Radware’s APSolute Operating System.
You use the Application Grouping Table to configure destination grouping. Application grouping is only available when Client Table Mode is set to Layer 4.
The core of this OS is a classification and flow-management engine that uses a rule database for traffic identification and redirection. The database is configured with policies based on Layer 3 to Layer 7 information, including source and destination IPs, application type, session IDs, cookies, payload information and content.
ARP
Address Resolution Protocol (ARP) is the standard Layer 2 method for finding a host's hardware address (MAC) via its network layer address (IP). A client station broadcasts an ARP request onto the network with the IP address of the target node it wishes to communicate with, and the node with that address responds by sending back its physical address so that packets can be transmitted. ARP returns the layer 2 address for a layer 3 address. Due to the overwhelming prevalence of IPv4 and Ethernet, ARP is primarily used to translate IP addresses to Ethernet MAC addresses. It is also used for IP over other LAN technologies, such as Token Ring, FDDI, or IEEE 802.11, and for IP over ATM.
522
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Radware Technical Glossary
Term
Definition
ARP, Fake
A Fake ARP is an optional, additional Gratuitous ARP broadcast sent by a Backup AppDirector device containing an IP Address owned by an Active device and using the Active MAC Address. In a redundancy cluster with two AppDirector devices, the Backup device constantly monitors the health of the Active device. When it detects that the main device is down it takes over control, including IP addresses, . The backup device sends gratuitous ARPs to all local stations informing them that the main device IP addresses now correspond to the MAC addresses of the backup device. After the Active device becomes active again, it also does the same; it 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. To speed up this process, the backup device publishes a message. This is a fake ARP, as one device (the backup) publishes the ARP of another device (the Active). 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.
ARP, Gratuitous
A Gratuitous ARP is an ARP broadcast sent out by a device for the sole purpose of keeping other devices informed of its presence on the network.
ARP Table
ARP table contains the destination MAC address for each destination IP.
Authority DNS Server
Authority DNS Server - any DNS server that contains a complete copy of the domain's zone file is considered to be authoritative for that domain only. A complete copy of a zone file must have: A valid Start of Authority (SOA) record Valid Name Server (NS) records for the domain The listed NS records should match the servers listed in the SOA record. Servers listed in the zone file, but not in the SOA record are called lame servers. It is considered standard practice to have a primary authoritative DNS server (the first server on your list) and a secondary authoritative DNS server/s (all other servers on your list). The secondary and primary servers should be on different IP subnets and the hardware should be located in different physical locations, for safety and redundancy purposes. A secondary server can, and should be, authoritative for any domain for which it performs secondary authoritative resolution.
Backup in VLAN
In Regular VLAN configuration, the device that is inactive can cause broadcast storms and lead to loops. Backup in VLAN, when enabled, prevents loop creation.
BER
Basic Encoding Rules (BER) are a set of ASN.1 encoding rules that define a specific way in which information may be encoded in a binary form. It is used as the underlying mechanism for encoding LDAP messages.
Document ID: RDWR-AD-V021403-UG0211
523
AppDirector Guide Radware Technical Glossary
Term
Definition
BGP
The Border Gateway Protocol (BGP) routing protocol, defined in RFC 1771, provides loop-free inter-domain routing between Autonomous Systems (AS is a set of routers that operate under the same istration). BGP is often the protocol used between gateway hosts on the Internet and is also often run among the networks of Internet service providers (ISPs). Hosts using BGP communicate using the Transmission Control Protocol (T) and send updated router table information only when one host has detected a change. Only the affected part of the routing table is sent.
Binding
Binding is the process by which protocols are associated with one another and the network adapter to provide a complete set of protocols needed for handling data from the application layer to the physical layer. For example, the configuration of a Load Balancer to associate certain servers with certain applications.
Binding, Delayed
Delayed Binding (T splicing), is the delaying of the connection between the client and the server until sufficient information is acquired to make a routing decision. Some application switches and routers delay binding the client session to the server until the proper handshakes are completed.
BOOTP
Bootstrap Protocol (BOOTP), is a UDP network protocol used by a network client to obtain its IP address automatically. This is usually done in the bootstrap process of computers or operating systems running on them. BOOTP servers obtain IP addresses from a pool of addresses and assign them to clients, enabling 'diskless workstation' computers to obtain an IP address prior to loading any advanced operating system.
Bridging
Bridging - is a packet-forwarding method, implemented in software, (as opposed to a VLAN where traffic is switched in hardware). In a bridged network, no correspondence is required between addresses and paths. Unlike routing, bridging makes no assumptions about where in a network a particular address is located. Instead, it depends on broadcasting to locate unknown devices. AppDirector learns the MAC addresses of frames arriving from each physical interface, and maintains a list of MAC addresses per interface, stored in a Bridge Forwarding table. When a frame arrives from an interface, AppDirector looks for the frame destination addresses according to the following conditions: • If the destination address is listed in the same interface as the source address, AppDirector discards the frame. • If the destination address is listed in another interface, AppDirector forwards the frame to the relevant interface. • If the address is not listed in any interface, AppDirector broadcasts the frame to all interfaces participating in the VLAN.
Bridge Forwarding Table
524
This lists the MAC addresses of frames arriving from each physical interface.
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Radware Technical Glossary
Term
Definition
Broadcast Domain
A Broadcast Domain is a set of all devices that will receive broadcast frames originating from any device within the set. Broadcast domains can be bounded by VLANs in a stand-alone environment. In an internetworking environment, they are bounded by routers because routers do not forward broadcast frames.
Class
Class, in object-oriented programming, a class is a programming language construct used to gather related instance variables and methods. In Radware, a class is defined as a combination of service definitions and network segment definitions that characterize a certain type of traffic. Services characterize traffic by Layer 3-7 criteria, while network segments characterize traffic by Layer 1-3 criteria. The Classes module allows multiple Networks to have the same configured name. This allows a Network with the name “net1” to encom multiple disted IP address ranges. This makes the Network Group Name a logical pointer to all ranges configured with that name.
Client NAT Address table
Client NAT Address table - defines the addresses that are available for the AppDirector to choose from to perform NAT.
Client Table (Radware)
A Radware Client Table is an internal table used by a Web Server Device to store Client session information, such as Client IP Address, Client IP Port, Farm IP Address, Server IP Address, Last Activity Time, Attach Time. It keeps track of clients connected to the servers for each of the Local Farms to maintain client-server persistency.
The NAT addresses are also configured in ranges. The maximum number of configurable NAT addresses depends on the value of the NAT Addresses table parameters.
The Layer 3 Client table contains information about the server selected for each client (Source IP address) in each farm, defined as a percent of the Client Table size. If AppDirector finds that a request exists in the Client Table the request is directed to the server recorded in the table. If an entry does not exist, a farm is selected according to the service requested, and a server is selected according to load balancing considerations or according to the Layer 7 Persistency info, The selected server is recorded in the table. Once an entry is created in the Client Table, all subsequent packets that arrive from the client to a farm are forwarded to the server recorded in the entry.
Client Table, Mirrored
A Mirrored Client Table is the internal table used by a Backup device to store the Client session information mirrored by the Active device.
Cluster
A Cluster is a group of multiple servers that appear to be a single unit. A Cluster is two or more Radware devices (AD, LP, and CID) configured in active/active or active/backup redundancy.
Document ID: RDWR-AD-V021403-UG0211
525
AppDirector Guide Radware Technical Glossary
Term
Definition
Cookies, HTTP
HTTP cookies are parcels of text sent by a server to a via a web browser to allow the server to store its own information about a and then sent back unchanged by the browser each time its client accesses that server. HTTP cookies are used for authenticating, tracking, and maintaining specific information ers, such as site preferences and the contents of their electronic shopping carts. When a initiates a connection to the server, a new T connection is established with the server and an HTTP request is sent. A cookie-enabled server processes the HTTP request and sends the an HTTP response containing a Set-Cookie HTTP Header with the relevant cookie. Once the client receives the cookie in the HTTP response, it stores it locally (unless configured to ignore cookies), usually in a form of a text file. Multiple Set-Cookie Headers may be used in an HTTP reply. A Set-Cookie header contains the following information: • Cookie name and value, in the format of key=value, (minimum character length is 1). • A comment (optional). • A domain name, which always starts with a leading dot (optional). • The expires parameter, which indicates the maximum age of the cookie (optional). When not specified in the Set-Cookie Header, the browser deletes the cookie as soon as the browser is closed.
Cookie, Session
A Session Cookie (aka transient cookie) is stored in temporary memory and erased when the closes the Web browser. Session cookies do not collect information from the ’s computer. They store information in the form of a session identification that does not personally identify the
Cookie, Persistent
A Persistent Cookie (aka permanent cookie) is stored on a ’s hard drive until it expires (persistent cookies are set with expiration dates) or until the deletes the cookie. Persistent cookies are used to collect identifying information about the , such as Web surfing behavior or other preferences.
DH
Dynamic Host Configuration Protocol (DH) is a protocol used by networked computers (clients) to obtain IP addresses and other parameters such as the default gateway, subnet mask, and IP addresses of DNS servers from a DH server. The DH server ensures that all IP addresses are unique, e.g., no IP address is assigned to a second client while the first client's assignment is valid (its lease has not expired). Thus IP address pool management is done by the server and not by a human network .
526
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Radware Technical Glossary
Term
Definition
DNS Resolution
A Domain Name Server (DNS) translates hostnames to IP addresses. At the stage when the domain points to name servers across all (or most) servers on the net, the domain is said to have been resolved (or propagated), that is, has arrived at DNS Resolution. For example, when you want to know the internet address of en.wikipedia.org, DNS can tell you it's 66.230.200.100. In addition, the DNS makes it possible to assign Internet destinations to the human organization or concern they represent, independently of the physical routing hierarchy represented by the numerical IP address. Because of this, hyperlinks and Internet information can remain the same, whatever the current IP routing arrangements may be, and can take a human-readable form (such as "wikipedia.org").
Dynamic Cookies
Dynamic Cookies are ed by AppDirector, as set by the servers. The defines a fixed key for the farm, then AppDirector tracks the use of different cookie values, or session IDs, by different servers. When a client request arrives at the AppDirector without a cookie, AppDirector selects a server according to the regular algorithms. The server will generate a dynamic cookie and send it to this client. AppDirector detects the dynamic cookie and re that the specific session ID is a cookie that was sent from that specific server. This information is kept in AppDirector's memory for a configurable period of time (Inactivity Timeout). During this period, whenever a client connects with the same cookie (the client's IP address may change), AppDirector will send that client to the same server that generated the cookie.
Dynamic Routing
Dynamic Routing constructs routing tables automatically, based on information carried by dynamic routing protocols. Dynamic routing protocols perform path determination and route table update functions. They also determine the next-best path if the best path to a destination becomes unusable. The capability to compensate for topology changes is the most important advantage dynamic routing offers over static routing. Dynamic Routing Protocols are, for example, OSPF, RIP, BGP ...
Dynamic IP Address
Dynamic IP address - is an IP address selected from a table that changes every time a logs on to the network (Internet).
Dynamic Proximity Table
Dynamic Proximity Table is the internal table used by an AppDirector device to store Dynamic Network Proximity information, such as Farm Address, 24-bit IP Subnet, Server IP Addresses, Latency per Server, and Hops per Server. The information can either be calculated by the AppDirector device itself or reported by other AppDirector devices comprising a multi-site, global solution. Dynamic Proximity features are only available on the WSD-NP.
Document ID: RDWR-AD-V021403-UG0211
527
AppDirector Guide Radware Technical Glossary
Term
Definition
Element, Checked
A Checked Element is a network element that is managed and load balanced by the Radware device. For example, AppDirector-checked elements include the Farm Servers, NHRs, and LRP and PRP reports. 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 AppDirector may depend on the health of a database server, or other application servers, which are not load balanced by the AppDirector, or the health of a Next Hop Router managed by LinkProof may depend on the availability of the service provider.
Failover
A Failover of a machine in a cluster is when a machine takes over packet filtering in place of another machine in the cluster that failed.
Farm (Server )
An AppDirector Server Farm (aka. Farm) is a collection of one or more networked and load-balanced servers hosting a common service or application that is accessible via a common VIP. A server can be a member of more than one Farm. Using a load balancer, a server farm streamlines internal processes by distributing the workload between the individual components of the farm and expedites computing processes by harnessing the power of multiple servers. Server farms rely on load-balancing software to satisfy tracking demand for processing power from different machines, prioritizing the tasks, and scheduling and rescheduling them depending on priority and demand. When one server in a farm fails, another takes up the load. Servers contained in a server farm can be placed in different physical locations, belong to different vendors, or have different capacities, all of which is transparent to the . A server in a farm can also serve in multiple farms.
Farm Profile
See Profile, Load Balancing.
Filter, Basic
Filter, Basic is a regular filter which defines the criteria for classifying traffic. A filter can consist of Layer 2 - Layer 7 classifying criteria, part of the classes database
Force Port Down
Force Port Down enables the temporary forcing down electrically of physical ports belonging to a VLAN when the VLAN is disabled due to Interface Grouping activation. This allows the switches connected to these ports to clear their MAC tables and prevent them from continuing to send traffic to the wrong AppDirector device; this problem is relevant mainly for Regular VLANs. This capability is ed only in VRRP configuration.
528
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Radware Technical Glossary
Term
Definition
FTP
File Transfer Protocol (FTP) is a protocol for exchanging files over the Internet. FTP works in the same way as HTTP for transferring Web pages from a server to a 's browser and SMTP for transferring electronic mail across the Internet in that, like these technologies, FTP uses the Internet's T/IP protocols to enable data transfer. FTP is most commonly used to a file from a server using the Internet or to a file to a server (e.g., ing a Web page file to a server).
Full Duplex
Full Duplex is the transmission of data in two directions simultaneously. In full-duplex mode, the data that you transmit does not appear on your screen until it has been received and sent back by the other party. This enables you to validate that the data has been accurately transmitted.
Gateway
A Gateway on a network is a device, often a specialized computer, that enables communication between networks of different architectures and using different protocols. The gateway converts the information being transmitted to a form that is understood by the receiving network
Global Solution
Radware’s Global Rapid Application Delivery solution enables the deployment of geographically dispersed sites to facilitate the direction of s to the site best suited to provide service. If one site becomes unavailable, s are transparently redirected to an available site. Radware provides: • Six different redirection methods which can seamlessly redirect sessions between servers and sites for any IP application to ensure availability, performance, security and 100% persistency. • Multiple session tracking mechanisms that enable identification of individual sessions, understand where that session is being served and share the session information between Radware devices in each of the sites.
Group Health Check
Group Health Checks enables the creation of complex health conditions for Checked Elements. For instance, consider a Web server that communicates with one of two database servers and uses one of two routers to provide service. This Web server is bound using three different binding groups: • One contains Health Checks for the two routers (each check is nonmandatory). • Another contains Health Checks for the database servers (each check is non-mandatory). • The third contains the Health Checks for the Web server. As long as one of the database servers and one of the routers are active, and the Web server Health Check es, the Web server is considered active. Otherwise, the Health Monitoring module determines that the Web server is unable to provide the required service.
Document ID: RDWR-AD-V021403-UG0211
529
AppDirector Guide Radware Technical Glossary
Term
Definition
Group, Server
A Server Group is subset of configured server hosts used for a particular service. A server may belong to several groups and a group may transverse several farms.
Hardware Load Balancer
A hardware load-balancing device (HLD), also known as a Layer 4-7 router, is a physical unit that directs requests to individual servers in a network, based on factors such as server processor utilization, the number of connections to a server, or the overall server performance. The use of an HLD minimizes the probability that any particular server is overwhelmed and optimizes the bandwidth available to each computer or terminal. In addition, the use of an HLD can minimize network downtime, facilitate traffic prioritization, provide end-to-end application monitoring, provide authentication, and help protect against malicious activity such as denial-of-service (DoS) attacks.
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 T/UDP port to which the test is sent, the time interval for the test, its timeout, the number of retries, and more. A network element can be tested using one or more Health Checks.
Health Checking, Advanced
Advanced health checking is the ability of an Application Delivery Network (ADN) to determine not only the state of the server where an application is hosted, but the status of the application it is delivering. Advanced health checking techniques allow the Application Delivery Controller (ADC) to intelligently determine whether or not the content being returned by the server is correct and should be delivered to the client.
Health Monitoring
Health Monitoring is the mechanism by which a load balancer checks to ensure that a load balanced server is up and functioning. Health monitoring includes: • ICMP ping • T port open • HTTP HEAD or GET command and looking for an HTTP 200 response. Radware’s health monitoring includes an extensive library of pre-defined health checks to identify any type of failure, whether it is a server hardware failure, an operating system problem, a specific application failure or a backend database failure.
High Availability
High Availability is the ability of a cluster to maintain a connection after a failure without loss of connectivity. In an Active-Backup cluster, only the Active machine filters packets. If a failure occurs on the Active machine, one of the other machines in the cluster assumes its responsibilities.
530
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Radware Technical Glossary
Term
Definition
Hop
A hop is the trip that a data packet takes from one router to another as it traverses a network on the way to its destination.
ICMP
The Internet Control Message Protocol (ICMP) is a a protocol that carries information about the status of the network, used by networked computers’ operating systems to send error messages—indicating, for instance, network congestion, unavailability of a requested service or that a host or router could not be reached.
IDN
Internationalized Domain Names (IDN) is a standard for Internet domain naming that allows characters other than the 37 basic ASCII characters (a-z, 0-9 and -) as laid down in RFC 3490 ("Internationalizing Domain Names in Applications" (IDNA)). AppDirector uses host names in the following configurations: • As a DNS server, AppDirector replies with a Layer 4 Virtual IP address or an external NAT address. • With Layer 7 Polices, farm selection can be based on host names. It is also possible to redirect HTTP, HTTPS, and SIP traffic. • With HTTP redirection, the server name or server's "Redirect to" attribute are used for the redirection.
Interface Grouping
Interface Grouping in a Redundancy cluster ensures that the Backup device will take over even if only some of the Active device physical ports are down. When this feature is enabled, a device will intentionally stop responding to ARPs on all of its ports if any of its physical ports is down, causing the Backup device to take over. Selective Interface Grouping - enables the definition of the physical ports that will trigger interface grouping, and subsequently device failover. When Interface grouping is triggered, it stops responding to ARP only on the ports that are included in the Selective Interface Group. The most common example of a port that should not usually trigger device failover is the Management Pport.
Interface, Hardware (Physical)
A Hardware Interface is an architecture that interconnects two pieces of hardware. It includes the design of the plug and socket, the type, number and purpose of the wires and the electrical signals that are ed across them. USB, FireWire, Ethernet, parallel and serial ports and CompactFlash cards, PCI cards and PC cards are all examples of hardware interfaces (devices connecting to other devices).
Interface, Physical (Radware)
A Physical Interface, as defined in Radware terminology, is one of the Fast Ethernet or Application Switch ports of the AppDirector / DefensePro. In the Fast Ethernet platform, AppDirector can have either 2 or 4 physical interfaces, depending on the hardware configuration. In the Application Switch platform, AppDirector can have up to 10 physical interfaces.
Document ID: RDWR-AD-V021403-UG0211
531
AppDirector Guide Radware Technical Glossary
Term
Definition
Interface, IP Physical
A Physical IP Address is an IP address assigned to an AppDirector interface.
IP Interface (Radware)
An IP Interface is an interface that allows interoperable connection of virtual components to devices to ensure rapid creation and integration of interoperable virtual components.
This address belongs to AppDirector and is used for SNMP management and/ or routing purposes.
An IP Interface has a format and language (description of signals and protocol) that defines the services one system is capable of delivering to another. The standards define a protocol for the transfer of requests and responses and the contents and coding of these requests and responses. • An IP interface on AppDirector is comprised of two components: • An IP address • An associated interface. The associated interface can be a physical interface or a virtual interface (VLAN). IP routing is performed between AppDirector IP interfaces, while bridging is performed within an IP interface that contains an IP address associated with a VLAN.
IP Address, Physical
A Physical IP Address is assigned to an AppDirector interface. This address belongs to AppDirector and is used for SNMP management and/or routing purposes.
IP Forwarding Table
The IP Forwarding Table contains the destination MAC address and port for each destination IP address.
IP Routing
The forwarding of IP packets to their destination using a Routing Table.
IPCS
Internet Protocol Communication Server (IPCS)
IPCM
Internet Protocol Call Manager (IPCM)
LAN
A Local Area Network (LAN) can be defined as a broadcast domain.
A MAC address is searched in this table before it is searched in the ARP table.
Hubs, bridges or switches in the same physical segment or segments connect all end node devices. End nodes can communicate with each other without the need for a router. Communications with devices on other LAN segments requires the use of a router.
532
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Radware Technical Glossary
Term
Definition
Layer 4 Classification
A Layer 4 Classification allows you to set a single Virtual IP address for multiple application services for different groups of s. You can define traffic segregation for a Layer 4 Classification on the basis of the Destination port and Layer 4 protocol. All the VIPs managed by AppDirector are defined under Layer 4 Classifications. When AppDirector receives the first packet of a session destined to a Virtual IP address, it searches for a Layer 4 Classification that matches the Layer 4 Protocol, Destination port, Source IP. Then, based on this information, Traffic Redirection selects the farm allocated to this service, while the Load Balancer finds the best server for the task from that farm, and forwards the packet to that server.
Layer-4-7 Switching
Layer 4 through 7 switching means switching packets based on Layer 4-7 protocol header information in the packets.
Layer-7 Switching
Layer-7 Switching (aka Layer-7 load balancing or application-level load balancing) parses requests in the application layer and distributes requests to servers to destination farms in Layer-4 Policies that match the request (Traffic Redirection). The Load Balancing function then allocates the request to the best server in the farm.
Layer 7 Classification Rule
A Layer 7 Classification Rule consists of one or two Layer 7 Methods.The rule can be bound to multiple Traffic Redirection rules on the same device, and the same Layer 7 Classification Rule can be reused on multiple devices.
Layer 7 Data Modification
Layer 7 Data Modfication is often required when changing the headers of an HTTP session. Some examples are:
T and UDP are the most used Layer 4 protocols and their headers contain the information required to make an intelligent switching decision. For example, the HTTP protocol normally runs on T Port 80. Radware’s Traffic Redirection can make the decision to prioritize, block or redirect traffic based on, for example, T or UDP port numbers.
• Insert HTTP Header X-Forwarded-For to convey to destination the originator of the communication. • Remove HTTP Header from server replies to clients to hide server identity. • Insert cookie for persistency purposes. AppDirector modifies Layer 7 fields such as URL, cookie, header fields and status lines and any Layer 7 data that can be identified by a certain string or regular expression.
Document ID: RDWR-AD-V021403-UG0211
533
AppDirector Guide Radware Technical Glossary
Term
Definition
LDAP
The Lightweight Directory Access Protocol (LDAP) is an application protocol for querying and modifying directory services running over T/IP. The most common example is the telephone directory, which consists of a series of names (either of a person or organization) organized alphabetically, with an address and phone number attached. LDAP deployments use Domain Name System (DNS) names for structuring the topmost levels of the hierarchy. Deeper inside the directory might appear entries representing people, organizational units, printers, documents, groups of people or anything else which represents a given tree entry (or multiple entries).
Layer 7 Methods
Layer 7 Methods are used to classify Layer 7 traffic, such as URLs, cookies, etc. A Layer 7 Method must be bound to a Layer 7 Classification rule in order for it to be used in a Traffic Redirection rule and the same Layer 7 Method can be reused on multiple devices.
License, Cookie Persistency
The Cookie Persistency License permits the AppDirector to check HTTP headers for Session ID Persistency. Without the Cookie Persistency license, AppDirector only inspects the URI and does not check further into the HTTP header.
Link Aggregation
Link Aggregation allows one or more links to be aggregated together (using multiple Ethernet network cables/ports in parallel) to form a logical Link Aggregation Group, such that a MAC client can treat the Link Aggregation Group as if it were a single link (from IEEE Standard 802.3, 2000 Edition, page 1215). Link Aggregation increases bandwidth beyond the limits of any one single cable or port. The failure or replacement of a single link within a Link Aggregation Group need not cause failure of a MAC Client. LA is available through Physical Layer technology options (10 Mb/s, 100 Mb/s, 1000 Mb/s, etc.). Load sharing can distribute MAC Client traffic across multiple links.
534
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Radware Technical Glossary
Term
Definition
Load Balancing
Load Balancing can be software, hardware or both. Radware Load Balancing software runs on servers, or appliances that contain the appropriate hardware and software, or Layer 2/3 switches with extended functionality. Load balancing software uses an algorithm or formula to distribute incoming HTTP requests across Web servers in a server farm to optimize traffic load. Dynamic load balancing uses current performance information from each node to determine the device that should receive each new packet, so that no single device is overwhelmed with traffic. The load balancer takes into consideration performance factors, such as current server performance and current connection load. Load Balancers have the following benefits: • Scalability – is the ability to continue functioning well even when distributing load across an increased number of real servers. • Availability – is the ability to divert requests (transparently and on the fly) to “healthy” servers when real servers or applications fail the health check. • Manageability – is the ability to continue serving requests, distributing the load to other servers, while a server is being upgraded. • Security - by being a front end to servers, a Load Balancer can “hide” (NAT) the private IP addresses of the servers and show only its own public VIP to the world. • Quality of Service – can be defined differently for each application. • Load Balancers have at least four applications: • Server load balancing – distributes load across multiple servers in a farm • Global server load balancing – directs requests to different data centers with server farms • Firewall load balancing – directs load across multiple firewalls • Transparent cache switching – offloads static content to caches to improve performance See also Stateless Load Balancing and Stateful Load Balancing.
Load Balancing, Software
A software load balancing solution can be loaded on the client’s hardware of the ’s choice, such as “DNS Round Robin”. Software solutions work best for smaller, less complex applications with a lower network complexity.
Load Balancing, Hardware
Hardware load balancers use virtual IP addresses to represent a group of servers and rewrite source and destination IP’s as they route traffic. There are two types of load balancing solutions that could be classified as hardware load balancers. Switch or router based which balances at the network level using layer 2 and 3 functionality. It is the most robust; however, it does not provide the ability to direct traffic based on cookies or URLs. A software/hardware solution that provides more functionality and flexibility with switching based on layers 4 through 7, but is more complicated to configure.
Document ID: RDWR-AD-V021403-UG0211
535
AppDirector Guide Radware Technical Glossary
Term
Definition
Load Balancing, Clustering
Clustering or Session Replication Load Balancing can be used as an alternative to hardware load balancing when sticky sessions or persistence is required. It consists of a farm or cluster of web application servers which have the ability to replicate and maintain session state in memory on all servers or using a common database. Traffic can then be directed to any server in the cluster even if persistence is required since all servers have current session state for all sessions. Clustering offers the advantage of high availability and failover . When one server fails or is taken out of service, the other servers are still aware of session states for sessions on the failed server and are therefore able to seamlessly take over. Clustering does not in actuality replace load balancing. The traffic still has to be directed to the servers in an ordered manner by some process. However it does solve the problem of maintaining session stickiness.
Load Distribution
Load distribution is helps to improve performance of Web Servers (response to requests) on a computer network by evenly dispersing jobs to different nodes or routes in a manner that no one route or node is overused. There are three well-known Load Distribution strategies: DNS-based – implements a round-robin assignment of requests to redundant WSs that maintains an optimum balance among those WSs. Mirror-based – provides access to the Web Server that is geographically closer. QoS-based – in this strategy, it is assumed that the DNS maintains the addresses of all the WSs that implement the required services, and makes the source browser responsible for implementing its own load distribution. The source browser interrogates the DNS to obtain the addresses of all the WSs that implement the required service. Before sending a request, the browser probes the WSs by sending a dummy request (broadcasting UDP messages) and determines the best URT ( Response Time). Load Distribution can be stateful (persistent) or stateless (single session).
Load Balancer Capacity
Load Balancer Capacity - Load Balancers are network devices, but they have more in common with Web servers when it comes to performance characteristics. Web servers are measured in connections per second, while routers and switches are measured in pure throughput (bits per second). The most important performance metric for load balancers is connections per second. The work involved in accepting and establishing a T session, potentially parsing the HTTP header, and forwarding the traffic to another Web server, is substantial when compared with the relatively easy task of throughput. Throughput is dependent on the speed of the network interface (Fast Ethernet: 100Mbps or Gigabit Ethernet: 1,000Mbps).
536
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Radware Technical Glossary
Term
Definition
Load Sharing
Load Sharing utilizes multi-path routing to allow a source to use any of several paths to a particular destination at any given time. Multi-path routing has several advantages as compared to single-path routing, including smoothing out the traffic, load balancing, ing QoS, improving reliability, and enhancing the privacy of the information being sent. In a Load Sharing Gateway Cluster, all machines in the cluster filter packets, providing transparent failover to any of the other machines in the cluster and enhanced reliability and performance. Load Sharing is also known as Active/Active.
Logical Server
Software that runs on physical servers, to process requests, such as web, mail, DNS, MYSQL and other servers.
LRP
Load Report Protocol (LRP) is used by AppDirectors to report their status and load to other AppDirectors and to the Global AppDirector. The redirection decisions which each global AppDirector makes are based on load, availability and proximity.
MAC
The Media Access Control (MAC) address is your computer's unique hardware number. On an Ethernet LAN, it is the same as your Ethernet address. When connected to the Internet, a correspondence table relates your IP address to your computer's physical (MAC) address on the LAN. The MAC address is used by the Media Access Control sublayer of the DataLink Layer (DLC) of telecommunication protocols. There is a different MAC sublayer for each physical device type. The other sublayer level in the DLC layer is the Logical Link Control sublayer.
MIB
A Management Information Base (MIB) is a formal description of a set of network objects that can be managed using the Simple Network Management Protocol (SNMP). The format of the MIB is defined as part of the SNMP. (All other MIBs are extensions of this basic management information base.) MIB-I refers to the initial MIB definition; MIB-II refers to the current definition. SNMPv2 includes MIB-II and adds some new objects.
MIME
Multipurpose Internet Mail Extensions (MIME) is a protocol widely used on the Internet to enable e-mail to include multiple types of information, such as text, graphics, sound, and video. MIME uses the message header for describing media types included in the document. This information is then used by software on the destination machine to determine whether the particular data types can be "replayed," and if so, by what programs.
Mirroring
Mirroring is a means of backing up data on a network by duplicating it, in its entirety, on a separate physical device.
Document ID: RDWR-AD-V021403-UG0211
537
AppDirector Guide Radware Technical Glossary
Term
Definition
Mirroring (dynamic client tables)
Mirroring (dynamic client tables) - in redundant clusters, mirroring maintains a copy of the dynamic client tables of the active device to the backup device. If the active device fails, the backup device takes up the sessions, and continues forwarding requests to the same server in the farm. Mirroring is recommended for use with state-sensitive and long-term sessions, such as Telnet or FTP, but should not be activated with HTTP applications where sessions are short and a reload mechanism is built-in or transparent. Mirroring should also not be used with Dynamic Session ID Tracking.
Monitor
A Monitor verifies connections and services on nodes that are of load balancing pools. A monitor can be either a health monitor or a performance monitor, to check the status of a node or service on an ongoing basis, at a set interval.
Multi-homing
Multi-homing (aka. Multi-WAN Switching) is where a corporate network uses more than one link and/or Internet Service Provider in parallel to connect to the outside world.
Multiplexing
Multiplexing is the process of weaving multiple signals onto a single channel or communications line. In multiplexing, segments of information from each signal are interleaved and separated by time, frequency, or space.
NAT
Network Address Translation (NAT) is the translation of an IP address used within one network (a LAN or internal network) to a different IP address known within another network (a public, external network). The purpose of NAT is to hide the Source IP address. The following NAT options are used in Radware: • NAT, Client - hides IP addresses of s sending requests to the Internet via the AppDirector • NAT, Server - translates the server’s IP address in outbound serverinitiated sessions, to a corresponding public address, using Static NAT (only the IP address is changed, no port NAT is done) • NAT, Outbound - allows only connections that originate from servers on the internal network to initiate sessions both with the internal network and with the public Internet.
NAT, Client
Client NAT - AppDirector uses this parameter to hide the IP addresses of the clients from the servers. The original Source IP of a request is replaced by the configured NAT IP and port before forwarding the request to the server. The Client NAT feature is used when, for example, the client and the server are on the same subnet, so that the IP address of the client must be hidden. If it is not, servers may send replies directly to clients, rather than sending them through AppDirector.
NAT, Dynamic
538
Dynamic NAT - maps an uned IP address to a ed IP address from a group of ed IP addresses.
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Radware Technical Glossary
Term
Definition
NAT, Outbound
Outbound NAT is used to perform IP address translation on traffic originating from behind an AppDirector or Web Server Director (WSD). The Outbound NAT parameter instructs AppDirector to replace the original source IP and source port of a packet with a Dynamic NAT IP from a ed IP list, and a NAT port. Outbound NAT is ed for T/UDP/ICMP traffic and applied only to traffic that is routed or bridged by AppDirector. The difference between Outbound NAT and Server NAT is that Outbound NAT generates an outbound NAT port (T/UDP).
NAT, Overlapping
Overlapping NAT is when IP addresses used on an internal network are ed IP addresses in use on another network. The router must maintain a lookup table of these addresses so that it can intercept them and replace them with ed unique IP addresses. The NAT router must translate the internal addresses to ed unique addresses and translate the external ed addresses to unique addresses in the private network. This can be done either through static NAT or by using DNS and implementing Dynamic NAT.
NAT, Pooled
Pooled NAT is similar to Port Address Translation (PAT) except there is a oneto-one mapping of addresses; the number of inside network clients is the same as the number of outside network IP addresses. The NAT router has a pool of available IP addresses, and each client receives its own IP address when it requests a NAT translation. The next available IP address is selected each time that the client requests a translation.
NAT, Server
Server NAT is a parameter in the AppDirector configuration that, when enabled, hides a server’s IP address for outbound traffic in sessions initiated by the server, using static NAT (only the IP address is changed, no port translation is done). Server NAT is applied to servers positioned behind AppDirector. When a session is initiated by a server, the server’s request for service is sent using its IP address as the source address. If the server’s IP address is a private IP address, the server’s address must be translated to a public IP address. The server’s IP is translated to the Layer 4 Classification’s VIP and a new entry is added to the Client Table. Sessions originating from servers are tracked in the Client Table and tagged with a “NAT” tag to differentiate this traffic from other inbound client traffic.
NAT, Static
Static NAT is a type of NAT in which client requests with private IP addresses are mapped to a fixed public IP address (for example, the case of an email server). This allows an internal host, such as a Web server, to have an uned (private) IP address and still be reachable over the Internet.
Networks
A Network is a generic term and is not described in this glossary.
Document ID: RDWR-AD-V021403-UG0211
539
AppDirector Guide Radware Technical Glossary
Term
Definition
Network (Scalefree)
In Scale-free Networks, structure and dynamics are independent of the system’s size (the number of nodes) It has the same properties irrelevant of the number of nodes.
Network Layers (OSI Model)
Layer 7: Application layer — interfaces directly to, and performs common application services for, the application processes; also issues requests to the presentation layer. Layer 6: Presentation layer — transforms data to provide a standard interface for the Application layer. MIME encoding, data encryption and similar manipulation of the presentation are done at this layer to present the data as a service or protocol developer sees fit. Layer 5: Session layer — controls the dialogues/connections (sessions) between computers. It establishes, manages and terminates the connections between the local and remote application. It provides for either full-duplex or half-duplex operation, and establishes checkpointing, adjournment, termination, and restart procedures. Layer 4: Transport layer — provides transparent transfer of data between end s, relieving the upper layers while providing reliable data transfer. Layer 3: Network layer — provides the functional and procedural means of transferring variable length data sequences from a source to a destination via one or more networks while maintaining the quality of service requested by the Transport layer. Layer 2: Data Link layer — provides the functional and procedural means to transfer data between network entities and to detect and possibly correct errors that may occur in the Physical layer. Layer 1: Physical layer — defines all the electrical and physical specifications for devices.
NHR
A Next-Hop Router (NHR) is a network element with an IP address through which traffic is routed.
NHRP
Next Hop Resolution Protocol (NHRP) is a protocol or method to find the most direct route (the fewest number of hops) to the receiving computer. NHRP informs the source of the most direct path to the closest router to the destination. NHRP is a query-and-reply protocol that builds a “network knowledge table” that can be used for all subsequent traffic, and send packets directly to the destination computer.
NMS
Network Management System (NMS) is a comprehensive system of equipment used in centrally monitoring, controlling, and managing a data communications network. An NMS has the ability to exchange information with other NMSs and EMSs via northbound interfaces.
NTP
The Network Time Protocol (NTP) is a protocol for synchronizing the clocks of computer systems over packet-switched, variable-latency data networks. NTP uses UDP port 123 as its transport layer. It is designed particularly to resist the effects of variable latency (jitter buffer).
540
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Radware Technical Glossary
Term
Definition
On Demand Switch
Radware's OnDemand Switch is a data center switch that scales up as a customer's business expands and demands increased application performance, increased throughput of data traffic and data availability.
OR Group
An OR Group is a logical OR between two Basic Filters, part of the classes database.
OSPF
Open Shortest Path First (OSPF) is a dynamic routing protocol used within large IP networks. Using OSPF, a host that obtains a change to a routing table or detects a change in the network, immediately multicasts the information to all other hosts in the network so that all will have the same routing table information. Unlike the RIP in which the entire routing table is sent, the host using OSPF sends only the part that has changed. With RIP, the routing table is sent to a neighbor host every 30 seconds. OSPF multicasts the updated information only when a change has taken place.
Out-of-band Monitoring
Out-of-band Monitoring is a health check by the Load Balancer for T response time generated specifically by the Load Balancer to the server. Using out-of-band monitoring, it is easier to check the validity of the request content. In contrast, in-band monitoring refers to a T health check using the natural traffic flow between the client and the server.
Outbound NAT Intercept Addresses Table
The Outbound NAT Intercept Addresses table lists networking elements with source addresses that have been NATed.
Packet, Network
A Network Packet consists of two kinds of data: protocol control information (PCI) and data (also known as payload). PCI carries information about the data, such as source and destination addresses, error detection codes like checksums, and sequencing information. PCI is found in packet headers and trailers, with data in between.
PAP
Authentication Protocol (PAP) is an access control protocol for dialing into a network that provides only basic functionality. When the client logs onto the network, the network access server (NAS) requests the name and from the client and sends it to the authentication server for verification. Since the is sent over the line unencrypted from the client, it provides checking, but is not secure from eavesdropping.
PAT
Port Address Translation (PAT) translates T or UDP communications between hosts on a private network and hosts on a public network. It allows a single public IP address to be used by many hosts on the LAN. A PAT device transparently modifies IP packets, as they from the multiple hosts on the LAN to the public network, so that all the packets appear to originate from a single host - the PAT device.
Document ID: RDWR-AD-V021403-UG0211
541
AppDirector Guide Radware Technical Glossary
Term
Definition
PBNM
Policy Based Network Management (PBNM) technology provides the ability to define and distribute policies for the management of enterprise and SP networks. Policies can reside either on the devices themselves or in the network management system to control essential network resources such as traffic engineering, bandwidth, and security.
Persistency
For interactive Web sites to successfully complete a single application transaction with dynamic content across a T/IP session, you must start and end a session serviced by the same web server (aka “sticky” session or Source IP Persistence). Session persistency is also achieved by forwarding all parts of a session that are identified by a unique identifier, to the same web server. There are no persistence requirements for static content. The two basic types of persistence methods for load balancers are source IP address and cookies. With Source IP Address, the load balancer looks at the source address (or source address and source port) of the incoming request to keep track of a session. With Cookie Persistence, the load balancer checks an HTTP cookie to differentiate s (the best method). The server only stores the information for a given time, as set by an expiration date in the cookie. In some cases, AppDirector must identify the session by an application identifier, rather than by Layer 3 (IP address) and Layer 4 (T/UDP ports) information.
Persistency, HTTP
HTTP persistency can mean either that AppDirector allows multiple HTTP requests within a single T session, or that AppDirector restricts the T session to a single HTTP request. The latter is required when the customer cannot guarantee that a single server can serve all requests within a single T session, for example, when different farms serve different file types.
Persistence, Session
Session Persistence (aka sticky connection, because client must stick to the same server for all sessions) is when the Load Balancer sends all connections from a gvien client to the same server.
Ping
PING is a utility to determine whether a specific IP address is accessible. It works by sending a packet to the specified address and waiting for a reply. PING is used primarily to troubleshoot Internet connections.
Port Group, Application
542
An Application Port Group combines Layer 4 ports for UDP and T 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.
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Radware Technical Glossary
Term
Definition
Port Groups, Physical
Port Groups is a method of grouping network segments by physical ports. Only packets that arrive from defined physical ports are classified by security policies and bandwidth management policies. For example, you can allow only HTTP traffic to the main server through a certain physical interface #3. On a Load Balancer, if a running application on any one group fails, the Load Balancer will mark the entire group of applications down on a given real server. It will direct requests only to those servers that have all the necessary applications running to complete a transaction.
Port Group, Physical Inbound / Outbound
Inbound Physical Port Groups classify only traffic received/sent on certain interfaces of the device, thus enabling you to set different rules for identical traffic classes that are received on different device interfaces.
Port Group, Source / Destination
Source / Destination Port Groups are intended for UDP and T traffic only.
Port Mirroring
Port Mirroring enables the AppDirector device to duplicate traffic from one physical port to another physical port on the same device. For example, when an Intrusion Detection System (IDS) device is connected to one of the ports on the AppDirector device, you can configure port mirroring for received traffic only, for transmitted traffic only, or for both. You can also decide whether to mirror the received broadcast packets.
Port Trunking
Port Trunking (aka 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.
Profile, Load Balancing
A Load Balancing Profile configures load-balancing parameters for a server farm.
Protocol Discovery
Protocol Discovery provides a view of the protocols running on the network.
Each server farm can have only one profile, although a Load Balancing profile can be applied to other farms.
Network s must be aware of the different applications running on their network and the amount of bandwidth they consume. The Protocol Discovery feature can be activated on the entire network or on separate subnetworks by defining Protocol Discovery rules. See Radware’s Content Inspection Director manual.
Protocol Port
A Protocol Port is an abstraction that T/IP transport protocols use to distinguish between multiple destinations within a given host computer. T/IP protocols identify ports using small positive integers. Usually, the operating system allows an application program to specify which port it wants to use. Some ports are reserved for standard services, such as e-mail.
Document ID: RDWR-AD-V021403-UG0211
543
AppDirector Guide Radware Technical Glossary
Term
Definition
Proximity
Global AppDirectors calculate round-trip latency and router hop-count from each remote site to incoming request to determine the fastest site. Requests are then dynamically redirected to a site where Response Time (URT), the time it takes from initiating a request until the gets a response, is the smallest. Technically, only Global AppDirectors can trigger proximity calculations and store the results, but even local AppDirectors can participate in the process. There are three consideration that determine the proximity of the server: • Traffic load on the available servers • Number of hops required to reach the server • Latency, the Response Time (URT) AppDirector-Global maintains two proximity databases that hold information about a specific subnet of IP addresses and list the best three servers according to proximity; the closest server is displayed first. The server is either a Virtual IP address on a Distributed AppDirector device (bound to a cluster of physical servers) or a standalone remote server. AppDirector-Global uses the weighted round-robin algorithm to determine the destination.
Proxy Redirection
Proxy Redirection uses the Client NAT mechanism to redirect traffic to another server or site, while ensuring that the return traffic flows through the AppDirector that received the original request.
PRP
Proximity Report Protocol (PRP) is a protocol running on UDP port 2091. It is used by Global AppDirectors to exchange information about the network proximity of clients with other Global AppDirectors, such as calculations of store results of proximity and distributed AppDirector partners in a Proximity Table.
Physical Servers
Actually or virtually self-contained computers with their own operating systems (Linux, FreeBSD Unix, or Windows).
RADIUS
Remote Authentication Dial In Service (RADIUS) – is a client/server protocol and application to enable remote access servers to communicate with a central server to authenticate dial-in s and authorize their access to the requested system or service. RADIUS allows a company to maintain profiles in a central database that all remote servers can share. Centralization allows the definition of a rule that can be applied at a single istered network point, and makes it easier to track usage for billing and for logging network statistics. Created by Livingston (now owned by Lucent), RADIUS is a de facto industry standard used by a number of network product companies and is a proposed IETF standard.
544
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Radware Technical Glossary
Term
Definition
RED
Random Early Detection (RED) – an algorithm that uses the inherent retransmission and flow control characteristics of T to protect queues from overflowing. Radware’s bandwidth management mechanism (BWM) deploys RED in two forms: Global RED and Weighted RED (WRED). The statuses of queues are monitored, and when queues approach full capacity, random T packets are intercepted and dropped. When all queues are full, packets are dropped from all sessions. All T session endpoints are forced to use flow control to slow down each session, causing all sessions to be throttled down making retransmission necessary. Furthermore, UDP packets are dropped and lost (UDP does not have any inherent packet recovery mechanism).
Redirection, Global (Radware)
Global Redirection directs requests for original content to specific caches based on content, service location and resource availability on a central server or global redirector. Radware Global Redirection is 3-tiered: • Tier-1 DNS Resolution Redirection – uses DNS resolution for site selection. Based on site availability, load and proximity, AppDirector responds with the VIP address of the best site. Implementing DNS resolution service on globally dispersed AppDirectors provides DNS redundancy. In addition the VIP address used for DNS resolution is announced to the routing domain by Anycast. • Tier 2 Global Application Redirection – uses HTTP redirection, Global Triangulation, redirection and Client NAT. Application persistency uses application server identifiers stored in the URL, HTTP cookie or SIP Call-ID to prevent session disconnect. • Tier 3 Local Server Selection – after the site is determined, the local AppDirector selects a local server using the Load Balancer, maintaining application persistency throughout the process.
Document ID: RDWR-AD-V021403-UG0211
545
AppDirector Guide Radware Technical Glossary
Term
Definition
Redirection Methods, Global
The following redirection methods are used: • DNS Redirection responds to DNS queries for the IP address of a specific host name representing the service, with an IP address that provides the best service. The IP address can belong to a Local Farm or to a remote farm/server. • HTTP Redirection redirects the request to an alternate site, either a standalone server or another AppDirector with its own VIP. • Redirection is to an alternate site, either to a standalone server or another AppDirector with its own VIP. • Triangulation – mainly intended for non-HTTP traffic, where traffic is sent to remote AppDirectors using reserved addresses. A data “triangle” is formed in which the request is the first point, the redirecting AppDirector the second point, and the AppDirector that responds to the request locally is the third point. This method is not applicable to a global configuration using remote servers. • HTTP & Triangulation – where HTTP traffic is redirected using the HTTP redirection method, traffic is redirected using the method, and non-HTTP traffic is redirected using the Triangulation method. • DNS & HTTP & Triangulation – provides the redirection suitable for the type of incoming traffic. The DNS method is used for DNS requests, HTTP redirection is used for HTTP requests, redirection is used for requests, and Global Triangulation method is used for other types of requests.
Redundancy (in Load Balancing)
Redundancy in load balancing can be set up as: • Active-Standby (one unit is Active and taking up all the load, while the Standby kicks in when the Active fails) • Active-Active (both units are Active concurrently) • Active-Active is more complicated to setup and troubleshoot. However, when you have two units of equal power, Active-Active can provide twice the capacity over Active-Standby, because both units are in use. But, when running close to 100% on both units, if you do have a failure you’re oversubscribed by 100% on the remaining unit, which degrades your “expected” performance.
Redundancy, Physical & Virtual IP addresses
When used in Redundancy cluster configurations, the Primary and Secondary AppDirector devices utilize both physical and virtual IP Addresses. While the same virtual IP address is defined on both the Primary and Secondary, different physical IP addresses are used. If a physical interface of the Primary is set as the default gateway of a server, then when the Secondary takes over, it also takes over the physical IP address. However, the Secondary cannot ping its default gateway IP address, as the Primary is down. Using Virtual IP Interface addresses as default gateway of AppDirector servers and other devices enables pinging. To do this, create a Virtual IP Interface address for each local subnet of AppDirector, and use this address in the relevant routing tables for hosts on that subnet. Make sure to set the same virtual IP Interface addresses as backup on the Secondary device.
546
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Radware Technical Glossary
Term
Definition
Redundancy, (Radware)
Redundancy is ed in the AppDirector and AppDirector devices in two modes: • Active-Backup - with up to three devices, where one of the devices is the designated Active (with the highest priority on Virtual Router) device for all services (VIPs). In the event of a failure of the Active device, the Backup device takes over and temporarily assumes ownership of the VIPs. • Active-Active - with up to three devices, where each device is both the Active device for some VIPs and the Backup device for other VIPs. In the event of a failure of one device, the other device temporarily assumes ownership of all VIPs. Radware also provides a proprietary redundancy method that uses the Address Resolution Protocol (ARP) to monitor the other devices and to check their availability. The recommended redundancy mechanism for AppDirector is Virtual Router Redundancy Protocol (VRRP).
Regular Expression
A regular expression (can be abbreviated to “regex”) is a method of searching for a specified pattern in text. For example, a regular expression could tell a program to search for all text lines that contain the word “header” and then to print out each line in which a match is found or substitute another text sequence (for example, just “H”) where any match occurs. As an example of the syntax, the regular expression \bex can be used to describe (and search for) all of the instances of the string “ex” that occur at word breaks (signified by the \b). Thus in the phrase, “Texts for expert experimenters,” the regular expression \bex returns the “ex” in “expert” and “experimenters,” but not in “Texts” (because the “ex” occurs inside the word there and not at the word break).
Requests Table
Contains Layer 7 information saved during Delayed Binding.
REXEC
Remote Exec (rexec), like rsh allows you to execute non-interactive programs on another system. The difference between rsh and rexec is that rexec requires you to specify a valid for the other system and rsh does not. The other system must be running a remote exec daemon (rexecd) to handle the incoming rexec command. Most Unix and Linux systems include a remote exec daemon, but Windows does not.
Document ID: RDWR-AD-V021403-UG0211
547
AppDirector Guide Radware Technical Glossary
Term
Definition
RIP
Routing Information Protocol (RIP) is a widely-used Interior Gateway Protocol (IGP) routing protocols for managing router information within a selfcontained network such as a corporate LAN or an interconnected group of such LANs. Using RIP, a gateway host (with a router) sends its entire routing table (which lists all the other hosts it knows about) to its closest neighbor host every 30 seconds. The neighbor host in turn will the information on to its next neighbor until all hosts within the network have the same knowledge of routing paths, a state known as network convergence. RIP uses a hop count as a way to determine network distance. Each host with a router in the network uses the routing table information to determine the next host to route a packet to for a specified destination. RIP is considered an effective solution for small homogeneous networks. For larger, more complicated networks, RIP’s transmission of the entire routing table every 30 seconds may put a heavy load of extra traffic on the network. The major alternative to RIP is the Open Shortest Path First Protocol (OSPF). AppDirector s RIP version 1 and RIP version 2.
Router
A Router is a network device, operating on Layer 3, that transmits message packets, routing them over the best route available at the time. Routers are used to connect multiple network segments, including those based on differing architectures and protocols.
Router, Neighbor
A router sharing a common data link. A distance vector routing protocol sends its updates to neighboring routers and depends on them to the update information along to their neighbors. For this reason, distance vector routing is said to use hop-by-hop updates.
Routing Engine (RE)
The Radware Routing Engine (RE) deals with: • Real time traffic: forward, update tables, move to RS or discard • LB -> Layer 4 Classification, farm and server selection, Layer 3 & Layer 7 persistency • In-depth packet inspection -> Layer 7 persistency • Routing, bridging • IPFTT (ARP and Routing cache), Bridge FFT (Bridge cache)
Routing Services (RS)
Radware Routing Services (RS) deals with Client Table Aging, HM, Statistics, SNMP (management), Dynamic routing, ARP, ICMP, Proximity.
Routing Table
A Routing Table is a table of routing rules used by routers to determine the path of a packet, either to the local network or via a next-hop router. By default, all networks directly attached to AppDirector are recorded in the routing table, information about destinations and the best available route. Additional entries to the table can either be statically configured or dynamically created through a Dynamic Routing Protocol, such as OSPF, RIP, BGP.
548
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Radware Technical Glossary
Term
Definition
RSH
Remote Shell (rsh) [aka remsh or rcmd] allows you to execute non-interactive programs on another system. RSH executes the command on the other system and returns the program's standard output and standard error output. The other system must be running a remote shell daemon (rshd) to handle the incoming rsh command. Unix and Linux systems include a remote shell daemon, but Windows does not.
RTP
Real-Time Transport Protocol (RTP) – defines a standardized packet format for delivering multimedia over the Internet. RTP does not have a standard T or UDP port where it communicates.
RTSP
RealTime Streaming Protocol () is an application layer protocol used to transmit streaming audio, video and 3D animation over the Internet. It enables the client software to provide remote control of the server with functions such as pause, rewind and fast forward. is widely used in conjunction with the RTP transport protocol.
SCTP
In computer networking, the Stream Control Transmission Protocol (SCTP) is a Transport Layer protocol, serving in a similar role as the popular protocols Transmission Control Protocol (T) and Datagram Protocol (UDP). SCTP applications submit their data to be transmitted in messages (groups of bytes) to the SCTP transport layer. SCTP places messages and control information into separate chunks (data chunks and control chunks), each identified by a chunk header. A message can be fragmented over a number of data chunks, but each data chunk contains data from only one message. SCTP chunks are bundled into SCTP packets. The SCTP packet, which is submitted to the Internet Protocol, consists of a packet header, SCTP control chunks when necessary, followed by SCTP data chunks when available.
Server Group
A set of configured server hosts used for a particular service.
Session
A logical connection created between two hosts to exchange data, using sequencing and acknowledgments to send data reliably. In the context of load balancing T/IP traffic, a set of client requests directed to a server. The server program sometimes maintains state information between requests.
Session ID
A Session ID is a unique number that a Web site's server assigns a specific for the duration of that 's visit (session). The session ID can be stored as a cookie, form field, or URL (Uniform Resource Locator). Some Web servers generate session IDs by simply incrementing static numbers. However, most servers use algorithms that involve more complex methods, such as factoring in the date and time of the visit along with other variables defined by the server .
Document ID: RDWR-AD-V021403-UG0211
549
AppDirector Guide Radware Technical Glossary
Term
Definition
Session ID Table
The Session ID table contains the Session IDs collected from server replies when Session ID Persistency is active.
SNMP
The Simple Network Management Protocol (SNMP) is an application layer, asynchronous command/response polling protocol that facilitates the exchange of management information between network devices. SNMP is a part of the Transmission Control Protocol/Internet Protocol (T/IP) protocol suite. Radware devices work with the following versions of SNMP: SNMPv1, SNMPv2, and SNMPv3. All management traffic is initiated by the SNMP-based network management station (except for trap messages), which addresses the managed entities in its management domain. Only the addressed managed entity answers the polling of the management station.
SNMP Community Name
An SNMP community name is a text string that acts as a . It is used to authenticate messages that are sent between APSolute Vision (the SNMP manager) and the AppDirector (the SNMP agent). The community string is included in every packet that is transmitted between the SNMP manager and the SNMP agent. Community names are recorded in a Community Name Table. They can be changed directly on the AppDirector.
SOA
Service-Oriented Architecture (SOA) - is software that builds applications out of software services. Online services are functions such as filling out an online application for an , viewing an online bank statement, or placing an online book or airline ticket order. Instead of services embedding calls to each other in their source code, protocols are defined which describe how one or more services can talk to each other. This architecture then relies on a business process expert to link and sequence services, in a process known as orchestration, to meet a new or existing business system requirement. These services communicate with each other by ing data from one service to another, or by coordinating an activity between one or more services.
SOAP
Simple Object Access Protocol (SOAP) is the standard for web services messages. Based on XML, SOAP defines an envelope format and various rules for describing its contents. With WSDL and UDDI, it is one of the three foundation standards of web services.
Socket
550
A sockect is a combination of IP address and port number.
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Radware Technical Glossary
Term
Definition
SSL Acceleration / Offloading
With SSL Offloading, the cryptography is performed with the load balancer’s main processor. SSL Offloading is less expensive, because no additional hardware is required. However, because U-intensive cryptographic functions are done on the general processor, the number of SSL connections a given device can handle is limited With SSL Acceleration, the cryptography is done on a separate SSL accelerator card (usually an installed PCI card), enabling even a modest box to handle thousands of SSL transactions per second. You can perform cookie-based persistence, even on an SSL connection. Without SSL offloading/acceleration, the load balancer cannot see the HTTP headers, which contain the cookie that is used for persistence. If you terminate the SSL session at the load balancer, the HTTP headers are then viewable by the load balancer. With SSL acceleration, you get the ability to do cookie persistence on Secure-HTTP traffic, and the performance increase that hardware acceleration gives you.
SSO
Single sign-on (SSO) is a method of access control that enables a to authenticate once and gain access to the resources of multiple software systems.
Shared Object
A Shared Object is a single instance of an object used in multiple entries, such as a Farm Profile that is used in multiple Farms.
SSL
Secure Sockets Layer (SSL) is a protocol developed by Netscape for transmitting private documents via the Internet. SSL uses a cryptographic system that uses two keys to encrypt data - a public key known to everyone and a private or secret key known only to the recipient of the message. Both Netscape Navigator and Internet Explorer SSL, and many Web sites use the protocol to obtain confidential information, such as credit card numbers.By convention, URLs that require an SSL connection start with https: instead of http:
SSL Table
Keeps track of SSL Session IDs.
Stateless Load Balancing
Stateless Load Balancing treats all requests equally. By using a hashing algorithm on source and destination ports and IP addresses in a request and according to the hash result directs the request to its destination server.
Stateful Load Balancing
Stateful Load Balancing detects session initiation and termination and uses load-distribution method to determine the destination server. All subsequent packets received for that session are sent to the same destination server until the session is terminated. To do this, the Load Balancer keeps a session table and creates an entry when a new session is initiated, then removing the entry when the session is terminated.
Document ID: RDWR-AD-V021403-UG0211
551
AppDirector Guide Radware Technical Glossary
Term
Definition
Stateful Failover
In a redundancy cluster, Stateful Failover enables the backup device to take over when a main device fails, without dropping existing sessions or breaking persistency. AppDirector s stateful failover between two devices in a cluster by mirroring the content of the tables that define session state: Client table, Session ID (persistency) table, Proximity table and DNS Persistency table. Instead of using mirroring, a dedicated direct connection (cross-cable or trunk) between the AppDirector devices reduces latency and avoids packet loss that can happen when sending mirroring data over the network.
Stateful Inspection
Stateful Inspection ensures that transmission and application stateful rules are enforced according to the protocol RFCs.
Switch, LAN
A LAN Switch is a network device that consists of multiple ports that connect LAN segments (Ethernet and Token Ring) and a high-speed port (such as 100Mbps Ethernet, Fiber Distributed Data Interface [FDDI], or 155-Mbps ATM). The high-speed port, in turn, connects the LAN switch to other devices in the network. A LAN switch has dedicated bandwidth per port, and each port represents a different segment. For best performance, network designers often assign just one host to a port, giving that host dedicated bandwidth of 10 Mbps, as shown in Figure 12–3, or 16 Mbps for Token Ring networks.
Switch, Network
A Network Switch is a small hardware device that operates at the Layer 2 (Data Link Layer) of the OSI model, that s multiple computers together within one local area network (LAN). A network switch contains more “intelligence” than a hub and is capable of inspecting data packets as they are received, determining the source and destination device of that packet, and forwarding it appropriately.
Super Farm
A Super Farm is a Farm of Farms.
T/IP
The Transmission Control Protocol (T) is a Layer 4 protocol, often simply referred to as T/IP. Using T, applications on networked hosts can create connections to one another, over which they can exchange streams of data using Stream Sockets. The protocol guarantees reliable and in-order delivery of data from sender to receiver. T also distinguishes data for multiple connections by concurrent applications (e.g., Web server and e-mail server) running on the same host.
Traffic, Network
552
Traffic is data transmitted over a network. Traffic is a very general term and refers to overall network usage at a given moment, although it can refer to specific transactions, messages, records or s in any kind of data or telephone network.
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Radware Technical Glossary
Term
Definition
TFTP
Trivial File Transfer Protocol (TFTP), a simple form of the File Transfer Protocol (FTP), TFTP uses the Datagram Protocol (UDP)and provides no security features. It is often used by servers to boot diskless workstations, X-terminals, and routers.
Traffic Redirection Policy
A Traffic Redirection Policy is a set of rules with Layer 4 and Layer 7 conditions that directs requests to the appropriate server farms.
Traffic Redirection Rule
A Traffic Redirection Rule is a set of Layer 4 and Layer 7 conditions that determines the destination server farm for a request.
Traffic Shaping
The purpose of traffic shaping is to increase network performance by controlling the amount of data that flows in and out of the network. Traffic is categorized, queued, and directed according to network policies that you define.
Trunk
Trunk’s main purpose is to carry traffic between switches and maintain VLAN information. Unlike an access link, the trunk link does not belong to a single VLAN but instead can carry traffic from several VLANs over a point-to-point link between two devices that understand the protocol. Because a trunk is a point-to-point connection between two switches, it is very efficient and highly recommended that it runs in full-duplex mode.
Trunk Port
Trunk Port - trunking is a special function that can be assigned to a port, making that port capable of carrying traffic for any or all of the VLANs accessible by a particular switch. Such a port is called a trunk port, in contrast to an access port, which carries traffic only to and from the specific VLAN assigned to it. A trunk port marks frames with special identifying tags (either ISL tags or 802.1Q tags) as they between switches, so each frame can be routed to its intended VLAN. An access port does not provide such tags, because the VLAN for it is preassigned, and identifying markers is therefore unnecessary.
TTL
Time To Live (TTL) is a limit on the period of time or number of iterations or transmissions in computer and computer network technology that a unit of data (such as a record) can experience before it should be discarded.
TTS
Text to Speech (TTS).
Document ID: RDWR-AD-V021403-UG0211
553
AppDirector Guide Radware Technical Glossary
Term
Definition
UDP
The Datagram Protocol (UDP) protocol enables programs on networked computers to send short messages sometimes known as datagrams (using Datagram Sockets) to one another. UDP is sometimes called the Universal Datagram Protocol or Unreliable Datagram Protocol. UDP does not provide the reliability and ordering that T does. Datagrams may arrive out of order, appear duplicated, or go missing without notice. Without the overhead of checking whether every packet arrived, UDP is faster and more efficient for many lightweight or time-sensitive purposes. Also, its stateless nature is useful for servers that answer small queries from huge numbers of clients. Compared to T, UDP is required for broadcast (send to all on local network) and multicast (send to all subscribers).
URL Parsing
URL Parsing is a Layer 7 (protocol aware) feature (sometimes referred to as content switching, but not switching in a Layer 2 network sense). It enables a site to send traffic to different servers according to the URL in the request. For instance, a group of image servers will serve up everything under http://exampledomain.com/images, while a set of map servers will handle anything under http://exampledomain.com/map.
Virtual DNS
Virtual DNS - in addition to or instead of using an IP address assigned to a physical port, an AppDirector device can use DNS Virtual Addresses to respond to DNS requests for its Farms.
Virtual IP
Virtual IP Address (VIP) is an IP address that is shared among multiple domain names or multiple servers. It enables one IP address to be used for multiple destinations, either when insufficient IP addresses are available, or as a means to balance traffic to multiple servers in a server farm.
Virtual Server
A Virtual Server with its virtual address is the visible, routable entity through which nodes in a load balancing pool are made available to a client, either directly or indirectly, through a rule.
554
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Radware Technical Glossary
Term
Definition
VLAN
A Virtual Local Area Network, in Radware terminology, is a group of selected physical interfaces that are configured as a single logical interface. This feature is similar to what is called a switch or bridge group. In Radware products, a VLAN of interfaces and 802.1q VLAN tagging are separate and distinct features. VLANs are configured through software rather than hardware, which makes them extremely flexible. One of the biggest advantages of VLANs is that when a computer is physically moved to another location, it can stay on the same VLAN without any hardware reconfiguration. LAN Switches (Layer 2 Services) - LAN switches can group individual ports into logical switched workgroups called VLANs, thereby restricting the broadcast domain to designated VLAN member ports. VLANs are also known as switched domains and autonomous switching domains. Communication between VLANs requires a router. VLANs offer a method of dividing one physical network into multiple broadcast domains. However, VLAN-enabled switches cannot, by themselves, forward traffic across VLAN boundaries. For inter-VLAN communication, a Layer 3 router is required.
VLAN, Regular (Radware)
A Regular VLAN can be described as an IP Bridge (a software bridge) between multiple ports that provides traffic redirection of traffic between Layer 2 and Layer 3. Several ports can be grouped for network segregation. Non-IP frames are transmitted transparently, whether VLAN-tagged or un-tagged. The entire traffic es through the U. A Regular VLAN is one of the following types: • IP Protocol - The VLAN requires an IP address. All of the traffic between ports is monitored transparently by AppDirector. Packets that need intelligent intervention are checked and modified and forwarded to the relevant port. Other packets are simply bridged by AppDirector 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 AppDirector. To handle both packets that need intelligent intervention and non-IP traffic, you can configure IP VLAN and “Other” VLAN on the same ports. Recommended: If only Layer 3 traffic es through the AppDirector, use IP Protocols, however, if the entire traffic es through the AppDirector, use Other Protocol.
VLAN Interface
A virtual LAN (VLAN) is a logical definition of a network work group. It is roughly equivalent to a broadcast domain. A VLAN interface is your system’s point of attachment to a given VLAN. A VLAN and a VLAN interface are analogous to an IP sub-network and an IP interface.
Document ID: RDWR-AD-V021403-UG0211
555
AppDirector Guide Radware Technical Glossary
Term
Definition
VLAN Tag
A VLAN Tag identifies traffic belonging to different VLANs. The IEEE standard 802.1Q standard defines a method called VLAN tagging, where switches insert a 4-byte VLAN tag into the header of each frame. The tag contains a 12-bit “VLAN ID” that identifies the frame’s VLAN hip. This enables multiple VLANs to use the same switch port. Each VLAN is tagged with a unique identifier to identify different VLAN traffic on the same physical portal, allowing VLANs to communicate with one another using a Layer-3 router. If a packet arrives without a VLAN tag, AppDirector sets a tag according to the destination local subnet. AppDirector can overwrite or retain VLAN Tags on packets ing through it. When the status of VLAN Tag is changed, the device must be rebooted.
VoIP
Voice-over-IP (VoIP) is a telephony term describing the facilities for delivering voice using IP. It involves sending voice information in some digital form in discrete packets rather than in the traditional circuit-oriented format of the PSTN.
VoIP/SIP
VoIP/SIP Front-End solutions - A high availability VoIP/SIP signaling and messaging solution for network border elements / SBC to carriergrade SIP-based VoIP multimedia service delivery.
VRID
Virtual Router IDentifier - a virtual router must use 00-00-5E-00-01-XX as its Media Access Control (MAC) address. The last byte of the address (XX) is the Virtual Router IDentifier (VRID), which is different for each virtual router in the network. This address is used by only one physical router at a time, and is the only way that other physical routers can identify the master router within a virtual router. Physical routers acting as virtual routers must communicate within themselves using packets with multicast IP address 224.0.0.18 and IP protocol number 112. Master routers have a priority of 255 and backup router(s) can have priority between 1-254. When a planned withdrawal of a master router is to take place, it changes its priority to zero which forces a backup router to take up the master router status more quickly. This is to reduce the black hole period.
556
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Radware Technical Glossary
Term
Definition
VRRP
Virtual Router Redundancy Protocol (VRRP) – eliminates a single point of failure inherent in static default routed environments. VRRP was initially developed to provide high availability for routers, however it can be ed by a wide range of devices that are not routers as it is not a routing protocol - it does not IP routes nor affect the routing table. In redundancy setups 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 Increased availability is achieved by advertising a “virtual router” (an abstract representation of master and backup routers acting as a cluster) as a default gateway to the host(s) instead of one physical router. Two or more physical routers are then configured to stand for the virtual router, with only one doing the routing at any given time. If the current physical router that is routing the data on behalf of the virtual router fails, an arrangement is made for another physical router to automatically replace it. The physical router that is currently forwarding data on behalf of the virtual router is called the master router. Physical routers standing by to take over from the master router in case something goes wrong are called backup routers.
Weight, Server
Server Weight is a ratio assigned to a server that determines the amount of traffic forwarded to it relative to other servers. Server weights range from 1 to 10,000. For example, when the Dispatch Method is Least Number of s, a weight of 3 gives that server three times the number of s than a server with a weight of 1. With Least Amount of Traffic, a server with weight 2 receives twice the amount of traffic as a server with weight 1. Default weight is 1.
Document ID: RDWR-AD-V021403-UG0211
557
AppDirector Guide Radware Technical Glossary
558
Document ID: RDWR-AD-V021403-UG0211
Appendix B – Regular Expressions This appendix provides an overview of the basic syntax of regular expressions used in AppDirector modules, for example in the DNS Regexp Host Name 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"
•
"^abc$": 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. 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.
•
"^.{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]");
Document ID: RDWR-AD-V021403-UG0211
559
AppDirector Guide Regular Expressions •
"^[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:
"%[^a-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. 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.
560
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Troubleshooting
Appendix C – Troubleshooting This appendix provides: •
Diagnostic Tools, page 561
•
Acceleration-Engine Logs, page 576
•
ing the Technical File, page 578
Diagnostic Tools This section contains common Diagnostics tools to use with AppDirector and contains these topics: •
Diagnostics Trace-Log, page 561
•
Traffic Capture, page 564
•
Diagnostics Tools Policies, page 569
•
Diagnostics Tools File Management, page 571
•
System Diagnostics, page 572
When the device does not operate as expected and traffic is not redirected according to configured policies, you must diagnose the system to understand the problem, or to help provide Radware with more information. System s can use the following Diagnostics tools: •
Diagnostics Trace-Log
•
Traffic Capture
Diagnostics will stop automatically in the following cases: •
You manually stop the diagnostics tasks
•
You reboot the device
Diagnostics Trace-Log Understanding the traffic flow within the device is an important stage in the diagnostic process. Using the Diagnostics Trace-Log feature, system s can trace traffic ing via the device to understand the flow of packets. To pinpoint the source of the problem, Diagnostics TraceLog allows differentiating between various application modules. For example, you can trace the Health Monitoring Module to understand why a specific check fails.
INFO: starting check DH DEBUG: Destination port used=67 (Method: DH, Name: DH) WARNING: Calling Timeout function (Method: DH, Name: DH) DEBUG: Failure function called, failing check (Method: DH, Name: DH) For each Radware product, there is a list of available modules under the traced applications menu.
Note: In this version, Diagnostics Trace-Log is provided for APSolute OS generic modules only (Health Check, Bandwidth Management), not for AppDirector specific functionality. When using the Diagnostics Trace-Log, you can configure the message format using the following parameters: •
Date - The traced date.
•
Time - The traced time.
Document ID: RDWR-AD-V021403-UG0211
561
AppDirector Guide Troubleshooting •
Platform Name - The platform mib name.
•
Line Number -the line number in the source code (used by Radware's R&D).
•
Packet ID - an ID given by the device for each packet. This allows seeing the packets order.
•
Module Name - The name of the traced module.
•
Task Name - The name of the specific task of the traced module. >> The trace-log module is also used as a logging mechanism. When the trace-log feature is enabled the device will write logs for two scenarios, Packet Flow and Log File. In both cases the messages are written to the same log file. >> Packet flow – for each packet, logs are written describing the actions the device took regarding this packet. >> Log file – this is a regular log file as found in other (not Radware) applications. Each module in the device writes it own logs. In this case there is no direct connection between the logs written to the traffic ing through the device. For example, if the log severity level of the BWM module is set to Info the BWM module will write a message to the log each time the enable/disable the BWM feature.
Diagnostics Trace-Log Tool Configuration The Diagnostics Trace Tool Configuration window allows you to understand the traffic flow within the device is an important stage in the debugging process.
To set the Diagnostics Trace Tool Configuration parameters 1.
From the Services menu, select Diagnostics > Trace-Log > Parameters. The Diagnostics Trace Tool Configuration window appears.
2.
Set the parameters.
Parameter
Description
Status
Enables/disables the Diagnostics Trace capability.
Output To Sys-log Server
Enables/Disables the sending of output from the diagnostic trace to a Syslog Server.
Output To File
Enables/disables the file to be kept on the compact flash. Due to compact flash size limitation, two files are employed for the task of saving the data. Once the first file is filled up, the device automatically switches to the second file, until the second file is filled up and then it overwrites the first file and so on. Options are: • RAM drive and flash • RAM drive • None
Output To Terminal
3.
Enables/Disables the sending of output from the diagnostic trace to the Terminal.
Click Set. Your configuration is set.
Diagnostics Trace-Log Message Format The Diagnostics Trace Message Format window allows you to define the parameters that appear in the trace message.
562
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Troubleshooting
To set the parameters of the Diagnostics Trace Message Format window 1. From the Services menu, select Diagnostics > Trace > Message Format. The Diagnostics Trace Message Format window appears. 2. Set the parameters.
Parameter
Description
Date
Date when the message was generated.
Time
Time when the message was generated.
Platform Name
Platform mib name.
File Name
Output file name.
Line Number
Line number in the source code (used by Radware's R&D).
Packet Id
An ID assigned by the device to each packet. This enables you see the order of the packets.
Module Name
Name of the traced module.
Task Name
Name of the specific task of the traced module.
3. Click Set. Your configuration is set.
Trace-Log Modules The Trace Modules window allows you to view the results of the debug trace process according to the application modules employed by the device. Differentiating between various application modules in the debug process helps to pinpoint the source of the problem. For example, you can trace only the Health Monitoring Module to understand why a specific check fails.
To set the Traced Modules parameters 1. From the Services menu, select Diagnostics > Trace-Log > Modules. The Traced Modules window appears. 2. Set the parameters .
Parameter
Description
Name
Name of the traced module.
Status
Current status of the traced module.
Severity
Severity of bug traced in this module. Values: Notice, Emergency, Warning, Alert, Critical, Error, Info, Debug
3. Click on the relevant name from the table. The Traced Modules Update window appears. 4. Click Set. Your configuration is set.
Document ID: RDWR-AD-V021403-UG0211
563
AppDirector Guide Troubleshooting
Traffic Capture Traffic Capture allows system s to capture the traffic ing via the device and traffic that is generated by the device. The capture is saved in a TDUMP format for later analysis. For remote istration and debugging, it is also possible to send the output of the Traffic snapshots to the terminal (CLI / Telnet and SSH). System s may also configure the capture point - when the packet reaches the device, when packet leaves the device or in both cases. This allows better understanding of the traffic flow in case the device manipulates the packet, due to NAT, Traffic from VIP to real server, etc. Traffic Captures allow you to capture the traffic ing via the device and traffic that is generated by the device. Captured traffic can be saved in a TDUMP format for later analysis. For remote istration and debugging it is also possible to send the output of the Traffic Captures to the terminal (CLI / Telnet and SSH). You can configure the capture point. Using the snapshot point you can capture packets that reach the device, packets that leave the device or both. This allows better understanding of the traffic flow in case the device manipulates the packet, due to NAT, Traffic from VIP to real server etc.
To set the parameters of the Capture Tool Configuration window 1.
From the Services menu, select Diagnostics > Capture > Parameters. The Capture Tool Configuration window appears.
2.
Set the parameters.
Parameter
Description
Status
Enables/disables (default) the Traffic Snapshot capability.
Output To File
Enables/disables the file to be kept on the compact flash. Due to compact flash size limitation, two files are used to save data. Once the first file is full, the device automatically switches to the second, until it is full and then it overwrites the first file, etc. Values: RAM drive and flash, RAM drive, None
Output To Terminal
Enables/disables (default) sending output of the traffic captures to the Terminal.
Capture Point
Indicates location of capture point. Values: • On-Packet-Arrive - capture Rx only (only packets entering the device ports) • On-packet-send - capture Tx only (only packet leaving the device ports) • Both - capture both Rx and Tx Note: Capture can be performed when the packet arrives at the device, when it leaves the device or both.
564
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Troubleshooting
Parameter
Description
Traffic Match Mode
This controls how a session traversing a VIP will be captured logically. Each session sent to device VIP has two sides - client side (the session between the client and the VIP) and server side (the session between the AppDirector and the server). If the configured capturing policy matches any part of these two sessions then select: • Inbound only - capture the client side session only • Inbound and Outbound - capture both the client side and the corresponding server side sessions Note: This parameter has no effect on traffic that does not traverse a VIP.
3. Click Set. Your configuration is set.
Note: When rebooting the device, the capture moves to Disable.
System Diagnostics Capture Mode Capture Mode defines at what point of the Radware device the traffic is filtered by classification filters. •
This is relevant only for traffic that is handled by the Client Table.
•
This is relevant when the IP address changes during the session (examples: NAT, VIP etc.).
You can choose to match traffic patterns from two values: • Inbound only (Default): A device captures packets where the IP appears explicitly in the traffic. The device matches the configured policies against traffic as first seen when it enters the device. Only matching traffic is captured. This mode has a low performance penalty. • Inbound and Outbound:– A device captures the complete session, including parts where the configured IP does not appear (for example; before or after NAT). The device matches the configured policies against the traffic, both entering and leaving the device. Only matching traffic is captured. This mode has a high impact on device performance.
Notes: >> Inbound and Outbound mode can potentially affect performance. >> When rebooting the device, the capture option moves to "disable " (since the "enable" state reduces the performance of the device) .
System Diagnostics Capture Point Capture Point defines at what point in the Radware device the traffic is captured for the .cap file or terminal output. The options are: •
On-packet-arrive - Point A
•
On-packet-send - Point B
•
Both - Both Point A & B.
The Capture Point can also be set using the CLI command system diagnostics capture point. Traffic in this scenario is as follows: 1. Client IP to VIP 2. Client IP to Server IP
Document ID: RDWR-AD-V021403-UG0211
565
AppDirector Guide Troubleshooting 4.
VIP to Client IP
With Capture filters set to: Any to VIP and VIP to Any, the output depends on the Capture Mode used and on Capture Point, as follows: Mode \ Point
On-packet-arrive
On-packet-send
Inbound \ Both
Step #1
Step #2
Inbound & Outbound \ Both
Step #1 and Step #3
Step #1 trough Step #4
To capture all steps with Capture Mode of Inbound Only, use Capture Point of Both and set policies as follows: Any to VIP and Server IPs to Any.
T-Dump (Sniffer) T-Dump is a common packet sniffer that runs under the command line. It allows you to intercept and display T/IP and other packets being transmitted or received over a network. It is one of the most useful tools for debugging network problems. Benefits include: •
captures traffic flow through proxy for configuration debugging and checking purposes
•
well known syntax of filters available on the internet
•
standard pcap format has many tools available including wireshark
When the AppDirector acceleration engine module is used, information about T Connections and Sessions, terminated and processed by it, can be received using T-Dump. You can use T-Dump on any AppDirector interface. You can output dump to the CLI prompt or export it to a file (over SSH). After you connect to the acceleration engine module (see Direct Access to Proxy, page 575)use the following commands at prompt for T-Dump:
system tdump print [-t
system tdump export [-t
-t - The period for the T-Dump to collect data. By default It is 60 seconds.
•
-c - Maximum number of packets to collect. By default it is 10000 packets.
•
-s - Maximum packet length to be captured. By default it is 0 (capture whole packet).
You can apply traffic filters to the dump. AppDirector uses the Ethereal format of expressions. For a complete description refer to: http://www.ethereal.com/docs/man-pages/tdump.8.html
566
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Troubleshooting
Example for commonly used filters:
To filter by destination IP Enter: 'dst host' and the IP.
To filter by source IP Enter: 'src host' and the IP.
To filter by destination T port Enter: 'dst port' and the port.
To filter by source port Enter 'src port' and the port.
SSL Dump SSL dump is an SSL/TLS network protocol analyzer. It identifies T connections on the chosen network interface and attempts to interpret them as SSL/TLS traffic. When it identifies SSL/TLS traffic, it decodes the records and displays them in a textual form. If provided with the appropriate keying material, it will also decrypt the connections and display the application data traffic. Benefits include: •
captures encrypted traffic and can view it in the clear for debugging and checking.
•
previously you needed to export from the device and use 3rd party software combined with device Keys to decrypt and see traffic but with SSL dump, it is easier and safer.
Normally, one of the most useful tools for debugging network problems is sniffing or T-Dump utilities, however, because part of the traffic that goes through AppDirector acceleration engine is encrypted, an SSL dump is also required, to dump and decrypt traffic. This feature is available only from CLI, by direct access. For more information on how to direct access the proxy, see Direct Access to Proxy, page 575. Using this command you can dump traffic and decrypt it using keys configured on the device. The following need to be set: 1. The key(s) used for traffic decryption 2. SSLDump: a. b.
Traffic to dump and decrypt. This is set using a filter expression as described above in TDump (Sniffer), page 566. How long to capture traffic. This is set using the Timeout parameter, default is 60 seconds, (maximum packets to capture is 10000).
system ssldump print [-t
Document ID: RDWR-AD-V021403-UG0211
567
AppDirector Guide Troubleshooting This displays the SSLDump at the prompt. The information is continuously printed to the screen until the collection timeout is over.
system ssldump [-t
-t - The period for the SSLDump to collect data. By default It is 60 seconds. -k - specify the key names to be used separated by commas. If you do not enter the -k parameter, the device uses all existing keys.
The output of SSLdump is a text file (or multiple files, if multiple keys are used) and the output files are packed into a zip file. With SSLdump, print to screen is not available, the can only save the output to file (or multiple files if multiple keys are used).
Examples The following prompt is received:
Max packets count: 10000 Timeout: 60 seconds (as was set in the-t flag in the ssldump command) Max packet length: capture whole packet Enter filter expression. Press <enter> to continue: > 1.
When pressing "enter" you receive the following prompt:
Capture started. Press
The CLI is locked until capture timeout is reached, default maximum packet count has been reached (10,000) or you have pressed
3.
In the background, a tdump process is run with the default parameters or with the filter expression that you entered.
4.
The device now runs the "ssldump" on the output file of the "tdump" K times (1 time for each of the chosen keys). Eventually there will be K+1 files inside the machine: "tdump" capture file and K ssldump files (one for each key).
5.
These files will be zipped into one file called "ssldump.tar.gz", which is saved in /tmp dir.
6.
You are now prompted to export the file.
ssldump for the keyname id X when X is the key name. This is the prompt for each key. 1-SSH 2-Quit Please select export protocol [1-2]: 7.
If you choose "1", you will get the following prompt:
Capture ended. You must copy /tmp/ssldump.tar.gz via s:
s -P <SSH port, default: 1500> radware@<device ip>:/tmp/ssldump.tar.gz
Warning:
/tmp/ssldump.tar.gz will be deleted after the command ends.
Press enter to quit.
568
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Troubleshooting 8. Now you use s to copy the ssldump.tar.gz file to a local machine from the device. 9. When you press <enter>, the interactive command exits and the is back to the CLI prompt. At this point, all the ssldump, T-Dump and tar.gz files are deleted from the machine.
Diagnostics Tools Policies In most cases there is no need to capture the entire traffic ing via the device. With the powerful classification engine, system s can configure diagnostics policies. Using the diagnostics policies, the device classifies the traffic and only in case there is a match between the traffic patterns and diagnostics policies the device stores the information. The classification is based on a combination of the following criteria: The classification is based on a combination of the following criteria: 1. Inbound physical port group 2. Outbound physical port group 3. VLAN Tag group 4. Source MAC group 5. Destination MAC group 6. Source Network 7. Destination Network 8. Services (only filters based on L3 and L4 are ed). The Diagnostics Policies Create window allows you to define the debug policies.
Note: To reuse the policy, edit the policy and set it again.
To create a Diagnostics Policy parameters 1. From the Services menu, select Debug > Policies. The Diagnostics Policies window appears. 2. Click Create. The Diagnostics Policies Create window appears. 3. Set the parameters.
Parameter
Description
Name
defined name of the policy.
Index
Number assigned to this policy in Debug Policy table. Using this index number, policies are identified by the device.
Description
defined description of the policy.
VLAN Tag Group
VLAN Tag group to be classified.
Destination
All packets destined to defined IP address are classified.
Source
All packets originating from defined IP address are classified.
Inbound/Outbound Port Group
Inbound/outbound port group to be classified.
Service Type
Service Types to be classified.
Service
Services to be classified.
Document ID: RDWR-AD-V021403-UG0211
569
AppDirector Guide Troubleshooting
4.
Parameter
Description
Source/Destination MAC Group
MAC group to be classified.
Maximal Number of Packets
Maximal amount of packets to capture.
Maximal Packet Length
Maximal length for capture of a single packet.
Capture Status
Enables/Disables the Capture capability.
Trace Status
Enables/Disables the Trace capability.
Once the device captures the predefined amount of packets, it stops capturing traffic. In some cases, the device captures fewer number of packets than the configured value. This happens when the device is configured to drop packets.
Click Set. Your configuration is set.
In addition to the above, the can configure the amount of packets to capture. Once the device captures the predefined amount of packets, it stops capturing traffic for the specific policy. In some cases, the device captures fewer number of packets than the configurable value. This happens when the device is configured to drop packets.
Note: In capture mode when limiting the number of packets to reuse the policy, it is necessary to edit the policy and reset it. Classification by diagnostics policy is performed for all packets arriving to device immediately after their arrival. Only packets generated on device are being classified before the packet is sent. This may cause the following: •
When Capture point is set to "on-packet-send", the number of packets contained in the capture file may be lower than the preconfigured limit. This can happen if some packets arriving to device were matched by the policy but were not sent (since it was blocked by the device).
•
When Capture point is set to "both", the capture file may contain more packets than the predefined limit (This happens, when sending ping to device).
For Traffic Capture you can also configure the length of the packet that the device captures. By default the device captures the entire packet.
570
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Troubleshooting
Diagnostics Tools File Management The output of the Diagnostics Tools is kept on the RAM Drive and Flash memory (if configured). The device uses two files for each tool and once one file reaches its capacity limit, the device starts keeping the information in the other file. Once the second file reaches its capacity, the device overwrites the first file etc. When one of the files on the RAM Drive reaches its capacity limit, the device appends its contents to the file on the compact flash. The Diagnostic Tools Files Management window allows you to or delete files from the RAM or Main Flash drive to analyze the date.
To or delete Trace Files 1. From the Services menu, select Diagnostics > Files. The Diagnostic Tools Files Management window appears. 2. Set the parameters.
Parameter
Description
File Name
Name of RAM file or Main Flash file depending on file selection.
File Size
Indicates the file size in bytes.
Action
Select the required action: • : Selecting starts the process of the selected file. Follow the on screen instructions. • Delete: Deletes the selected file
3. Select either, the RAM or Flash file as appropriate. 4. From the action field select the required action and follow the on screen instructions. 5. Once the device collects the information, you can the output files as follows: —
To access the file system using FTP Client. The files are located under the dbgtools directories (CF / CM and RD). To access the device via the FTP service, the FTP server must be enabled prior to access.
—
Using TFTP In addition, the files can be sent to a TFTP server (ed only via the CLI using the CLI command "system diagnostics files send.
—
Using the Web Based Management.
Notes: >> Diagnostic Tools may cause a performance penalty on the AppDirector device by increasing U load and console response time. >> If a software upgrade is being performed while any of the diagnostics tools are being executed, operation of the diagnostics tools stops and all diagnostics files are erased. >> After reboot, the diagnostics tools is disabled by default.
Document ID: RDWR-AD-V021403-UG0211
571
AppDirector Guide Troubleshooting
Diagnostics Tools Tuning Using this feature, you can configure how many policies were run after reset.
To tune diagnostic policies 1.
Select Services > Tuning > Diagnostics. The Diagnostics Tools Tuning window appears.
2.
Enter the number of policies.
3.
Parameter
Description
Policies
Displays maximum number of policies in Debug Policies table.
Policies after reset
Displays maximum number of policies in Debug Policies table after reset.
Click Set. The configuration is saved.
System Diagnostics This section includes these topics: •
Traffic Captures, page 574
•
Diagnostics Trace, page 575
•
Direct Access to Proxy, page 575
Included in this appendix is a short introduction to Radware system diagnostics using CLI. The system diagnostics tool set is accessed by performing the command, System Diagnostics in the terminal console. For more detailed information see the accompanying CLI Reference Guide. capture
Packets Capture Diagnostics Tool
mode
Packets Capture Mode Definition
inbound - The filter in capture mode is performed on packets at each entry point to the RADWARE device. inbound and outbound - The filter in capture mode is performed on packets both at the entry and exit points to and from the AppDirector device(impairs performance severely) output
Capture Output Configuration
file Capture Output To File Configuration term Capture Output To Terminal Configuration point
Packets Capture Point Definition
(1) on-packet-arrive (2) on-packet-send (3) both status
Capture Tool Status
1 - enabled 2 - disabled files abort
572
Diagnostics Tools Generated Files Management Abort file
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Troubleshooting del
Delete file
system diagnostics files del [file name/all] [RD/MF] RD - RAM drive file MF - main flash file list List files generated by diagnostic tools send Send file to TFTP server system diagnostics files send [file name] [RD/MF] [TFTP Server ID] <-v> RD - RAM drive file MF - main flash file -v - send file to terminal policies Diagnostics Policies
set
destroy/del
<-switch>
Switches: -i
: Index
-d
: Description
-src : Source -dst : Destination -rx
: Inbound Port Group
-tx
: Outbound Port Group
-st
: Service Type
-srv : Service -vt
: VLAN Tag Group
-sm
: Source MAC Group
-dm
: Destination MAC Group
-cap : Capture Status -tr
: Trace-Log Status
-pn
: Maximal Number of Packets
-pl
: Maximal Packet Length
trace-log
Trace-Log Diagnostics Tool
modules
Trace-Log Modules
system diagnostics trace-log modules help:
set
help
<-switch>
Switches: -st
: Status
-sev : Severity msg-format Message Format Configuration
Document ID: RDWR-AD-V021403-UG0211
573
AppDirector Guide Troubleshooting date
Status of Date in the trace-log message format
file
Status of File in the trace-log message format
line
Status of Line in the trace-log message format
module
Status of Module in the tracelog message format
pckt-id Status of Packet-ID in the trace-log message format platform Status of Platform in the tracelog message format task
Status of Task in the trace-log message format
time
Status of Time in the trace-log message format
output file
Trace-Log Output Configuration
Trace-Log Output To File Configuration
syslog term
Trace-Log Output To Syslog Configuration Trace-Log Output To Terminal Configuration
status Diagnostics Trace-Log Status 1 - enabled 2 - disabled
Traffic Captures Parameter
Description
Status
Shows if Traffic Capture status is enabled or disabled
Output to File
Enables the file to be kept on compact flash. Due to compact flash size limitation, two files are employed to save data. Once the first is full, the device automatically switches to the second until the second file is full. The device then overwrites the first file etc.using this file name convention: capture_device_name_DDMMYYYY_HHMMSS (for Example capture_AppDirector_27122051_010302_1.cap).
Output to Terminal
Enables sending traffic output captures to the Terminal
Output to RAM Drive
Enables you to send traffic output captures to the RAM Drive. Here, the file is deleted after device reboot.
Capture Point
Shows location of capture point . Capture can be performed when the packet reaches the device, when packet leaves the device or both
Traffic Match Mode
Controls how a session traversing a VIP will be captured logically.
574
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Troubleshooting
Diagnostics Trace Parameter
Description
Status
Shows whether Diagnostics Trace status is enabled or disabled.
Output to File
Enables file to be kept on compact flash. Due to compact flash size limitation, two files are employed to save data. Once the first is full, the device automatically switches to the second until the second file is full and then it overwrites the first file etc. The device uses this file name convention: trace_log_Device_name_DDMMYYYY_HHMMSS (for Example - trace_log_AppDirector_27122051_010302_1.txt ).
Output to Terminal
Enables you to send traffic captures output to the Terminal.
Output to RAM Drive
Enables you to send traffic captures output to the RAM Drive - For AS 1.
Output to Syslog
Enables you to send the output of the Diagnostics Trace to a Syslog Server.
Direct Access to Proxy AppDirector enables you to directly connect to the internal AppDirector acceleration engine module where you need to perform related debugging or to view traffic flows. It provides the following benefits: •
you gain access to see the proxy module logs
•
you gain access to the proxy module to run T-Dump and SSLdump
•
you can run proxy CLI commands
To gain access, use the following command:
manage proxy-access status set enable and then you receive the following output:
Proxy |
SSH Port
------|---------1
|
1500
Use any IP address on AppDirector SSH enabled ports to access the proxy on the specified port (in the above example: 1500).
Note: Only a single IP can connect to a proxy port at any time. After you enable it, you can to the AppDirector acceleration engine through port 1500, (this is a default but not fixed) with s configured on the AppDirector. To control the log files, run the following command on direct access:
system logfile For using the tdump and ssldump feature see T-Dump (Sniffer), page 566.
Document ID: RDWR-AD-V021403-UG0211
575
AppDirector Guide Troubleshooting
Acceleration-Engine Logs
Application Acceleration Enabled Troubleshooting service problems requires an understanding of decisions and actions performed by AppDirector and its Acceleration Engine. These logs enable you to view these decisions and actions.
To configure the Acceleration Engine Logging 1.
From the Services menu, select Logging > Acceleration-Engine Logs. The AccelerationEngine Logs window appears.
2.
Set the parameters.
Parameter
Description
Compression Logs
Determines whether Compression activity is logged. Values: enable/disable (default).
Caching Logs
Determines whether Caching activity is logged. Values: enable/disable (default).
HTTP Logs
Determines whether HTTP activity is logged. Values: enable/disable (default).
SSL Logs
Determines whether SSL activity is logged. Values: enable/disable (default).
3.
Click Set. The Acceleration Engine Logs are configured.
To save a Log File When you have finished logging, you can the collected log data to a file on your PC. Select Save Log File and a save dialog window appears. Click Open or Save.
Note: The ed log file is in text format, and can be best viewed by importing into Microsoft Excel. For best results, import the file into Microsoft Excel.
To clear a Log File Finally, when you have the information that you need, you can select Clear Log File. A message will appear informing you that the log was successfully cleared.
576
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Troubleshooting
Using Acceleration Logs Efficiently To view Acceleration logs conveniently, you can import them via Microsoft Excel where they can be filtered and sorted.
To import a log 1. Open Microsoft Excel. 1. Open the log as a text file within Microsoft Excel. Step 1 of the Text Import Wizard dialog appears. 2. Mark the radio button Delimited.
3. Click Next. Step 2 of the Text Import Wizard dialog appears.
4. First define “space” as a delimiter . 5. Now select Treat consecutive delimiters as one, as shown in the example here. 6. Click Next. Step 3 of the Text Import Wizard dialog appears. 7. Click Finish. The Log opens as a Microsoft Excel spreadsheet.
Document ID: RDWR-AD-V021403-UG0211
577
AppDirector Guide Troubleshooting
To edit the Log file in Microsoft Excel 1.
Perform find and replace of all “+” to “ “ (space).
2.
Select row 8 (first row of logs) and go to Microsoft Excel 2007 View menu.
3.
Select Freeze Panes (to keep the header row constant).
Note: Use Windows > Freeze-Pane in older versions of Excel.
4.
Select row 7 (last headings row) and go to Data menu.
5.
Select the Filter button (Auto-Filters in older versions of Microsoft Excel). You can use the filters to see logs by date/time, and then filter the specific session that you want to review using the session-ID column filter.
ing the Technical File When debugging, AppDirector generates a separate file delivered in text format and aggregating all CLI commands needed by Radware Technical . The file also includes output of various CLI commands, e.g; a printout of the Client table. You can this file and send it to Radware Technical .
To the Technical file 1.
In the main WBM window, from the File menu select . The Technical Info File window appears.
2.
Click Set to the file. A file dialog box opens asking if you wish to open or save the file.
3.
Click Open or Save.
578
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Troubleshooting
Notes: >> The .TAR format that includes AppDirector , AppXcel DX log, AppXcel logger and the AppDirector configuration file is only available via WBM. However, if you the Technical file via CLI (.i.e. TFTP) it only includes the regular file. >> To ensure that all device messages are displayed, please define your AppDirector WBM as a "safe site" in your pop-up blocker, and enable it to display pop-up messages. >> For more information, refer to the Radware CLI Reference Manual.
Document ID: RDWR-AD-V021403-UG0211
579
AppDirector Guide Troubleshooting
580
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide Optimizing AppDirector with AppXcel Application
Appendix D – Optimizing AppDirector with AppXcel Application Accelerator This appendix describes how AppDirector interacts with AppXcel. For further detailed information on the AppXcel device see the AppXcel Guide. AppXcel and AppDirector, Radware’s infrastructure load balancer, are optimized to work together. AppXcel is a transaction accelerator that is optimized to perform SSL calculations. Off-loading these calculations to AppXcel relieves web server U, thereby increasing its capacity, and increases the service’s potential number of Transactions Per Second (TPS). Combining AppXcel with AppDirector creates a comprehensive solution that dramatically increases network certainty and performance. When SSL based traffic approaches the network, AppDirector identifies that the traffic must first be decrypted. AppDirector makes a load balancing decision about the best AppXcel accelerator to send the traffic to for decryption. Once the traffic is decrypted, AppDirector receives the traffic back and load balances the decrypted traffic to the best available server. When you use AppDirector with AppXcel in your ADC, you first create an AppXcel farm on AppDirector. A farm is a group of servers providing the same service. When a new service request arrives, AppDirector identifies the required service and selects the most available server within the farm that provides this service. Each farm is identified by its Virtual IP Address (VIP). This IP address is used by clients to approach the farm and each server within the farm is recognized by its IP address. For more information about configuring AppXcel with AppDirector, see the AppDirector Technical Solution Guide.
Document ID: RDWR-AD-V021403-UG0211
581
AppDirector Guide Optimizing AppDirector with AppXcel Application Accelerator
582
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide SSL Encryption,Certificates and Ciphers
Appendix E – SSL Encryption,Certificates and Ciphers This appendix is intended as an extra resource for security issues, speciifcally Certificates and Ciphers Suites. If you are planning to configure a SSL policy, then you will find valuable background information along with relevant Cipher Suites. See "Complete List of the Content Of All Cipher Suites (Front-end and Back-end)" on page 593. •
SSL Encryption, page 583
•
Certificates, page 584
•
Ciphers and Cipher Suites, page 590
SSL Encryption Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide communications security over the Internet. TLS and SSL encrypt the segments of network connections above the Transport Layer, using symmetric cryptography for privacy and a keyed message authentication code for message reliability. This allows us to encrypt the data stream itself, which can then be transmitted securely, using any of the application layer protocols. Two encryption techniques are used: •
Public key encryption is used to encrypt and decrypt certificates during the SSL handshake.
•
A mutually agreed symmetric encryption technique, such as DES (data encryption standard), or triple DES, is used in the data transfer following the handshake.
To make an environment secure, you must be sure that any communication is with "trusted" sites whose identity you can be sure of. SSL uses certificates for authentication — these are digitally signed documents which bind the public key to the identity of the private key owner. Authentication happens at connection time, and is independent of the application or the application protocol. Authentication involves making sure that sites with which you communicate are who they claim to be. With SSL, authentication is performed by an exchange of certificates, which are blocks of data in a format described in ITU-T standard X.509. The X.509 certificates are issued, and digitally signed by an external authority known as a certificate authority.
Encryption Protects Data During Transmission Web servers and Web browsers rely on the Secure Sockets Layer (SSL) protocol to create a uniquely encrypted channel for private communications over the public Internet. Each SSL Certificate consists of a public key and a private key. The public key is used to encrypt information and the private key is used to decipher it. When a Web browser points to a secured domain, a level of encryption is established based on the type of SSL Certificate as well as the client Web browser, operating system and host server’s capabilities. That is why SSL Certificates feature a range of encryption levels such as "up to 256-bit". Strong encryption, at 128 bits, can calculate 288 times as many combinations as 40-bit encryption. That's over a trillion times a trillion times stronger. At current computing speeds, a hacker with the time, tools, and motivation to attack using brute force would require a trillion years to break into a session protected by an SGC-enabled certificate. To enable strong encryption for the most site visitors, choose an SSL Certificate that enables at least 128-bit encryption for 99.9% of Web site visitors. True 128-bit SSL Certificates
Document ID: RDWR-AD-V021403-UG0211
583
AppDirector Guide SSL Encryption,Certificates and Ciphers
Credentials Establish Identity Online Credentials for establishing identity are common: a driver’s license, a port, a company badge. SSL Certificates are credentials for the online world, uniquely issued to a specific domain and Web server and authenticated by the SSL Certificate provider. When a browser connects to a server, the server sends the identification information to the browser. To view a Web sites’ credentials: •
Click the closed padlock in a browser window
•
Click the trust mark (such as the VeriSign Trust™ Seal)
•
Look in the green address bar*
Authentication Generates Trust in Credentials Trust of a credential depends on confidence in the credential issuer, because the issuer vouches for the credential’s authenticity. Certificate Authorities use a variety of authentication methods to information provided by organizations. VeriSign, the leading Certificate Authority, is well known and trusted by browser vendors because of our rigorous authentication methods and highly reliable infrastructure. Browsers extend that trust to SSL Certificates issued by VeriSign.
Certificates In cryptography, X.509 is an ITU-T standard for a public key infrastructure (PKI) for single sign-on (SSO) and Privilege Management Infrastructure (PMI). X.509 specifies, amongst other things, standard formats for public key certificates, certificate revocation lists, attribute certificates, and a certification path validation algorithm. In cryptography, a public key certificate (also known as a digital certificate or identity certificate) is an electronic document which uses a digital signature to bind together a public key with an identity — information such as the name of a person or an organization, their address, and so forth. The certificate can be used to that a public key belongs to an individual. In a typical public key infrastructure (PKI) scheme, the signature will be of a certificate authority (CA). In a web of trust scheme, the signature is of either the (a self-signed certificate) or other s ("endorsements"). In either case, the signatures on a certificate are attestations by the certificate signer that the identity information and the public key belong together. For provable security this reliance on something external to the system has the consequence that any public key certification scheme has to rely on some special setup assumption, such as the existence of a certificate authority. Certificates can be created for Unix-based servers with tools such as OpenSSL's ssl-ca or SuSE's gensslcert.
Contents of a Typical Digital Certificate •
Serial Number Used to uniquely identify the certificate.
•
Subject The person, or entity identified.
•
Signature Algorithm The algorithm used to create the signature.
•
Issuer The entity that verified the information and issued the certificate.
•
Valid-From The date the certificate is first valid from.
•
Valid-To The expiration date.
•
Public Key The public key to encrypt a message to the named subject.
•
Thumbprint Algorithm The algorithm used to hash the certificate.
•
Thumbprint The hash itself to ensure that the certificate has not been tampered with.
584
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide SSL Encryption,Certificates and Ciphers
Classes VeriSign introduced the concept of classes of digital certificates: •
Class 1 for individuals, intended for email
•
Class 2 for organizations, for which proof of identity is required
•
Class 3 for servers and software g, for which independent verification and checking of identity and authority is done by the issuing certificate authority
•
Class 4 for online business transactions between companies
•
Class 5 for private organizations or governmental security
Certificates and web site security The most common use of certificates is for HTTPS-based web sites. A web browser validates that an SSL (Transport Layer Security) web server is authentic, so that the can feel secure that their interaction with the web site has no eavesdroppers and that the web site is who it claims to be. This security is important for electronic commerce. In practice, a web site operator obtains a certificate by applying to a certificate provider with a certificate g request. The certificate request is an electronic document that contains the web site name, email address, and company information. The certificate provider signs the request, thus producing a public certificate. This public certificate is served to any web browser that connects to the web site and proves to the web browser that the provider believed that the provider issued a certificate to the owner of the web site. Before issuing a certificate, the certificate provider will request the email address for the web site from a public domain name registrar, and check that published address against the email address supplied in the certificate request. Therefore, an https web site is only secure to the extent that the end can be sure that the web site is operated by someone in with the person that ed the domain name. As an example, when a connects to https://www.example.com/ with their browser, if the browser gives no certificate warning message, then the can be sure that interacting with https://www.example.com/ is equivalent to interacting with the entity in with the email address listed in the public registrar under "example.com", even though that email address may not be displayed anywhere on the web site. No other surety of any kind is implied. Further, the relationship between the purchaser of the certificate, the operator of the web site, and the generator of the web site content may be tenuous and is not guaranteed. At best, the certificate guarantees uniqueness of the web site, provided that the web site itself has not been compromised (hacked) or the certificate issuing process subverted.
X.509 Certificates An X.509 certificate specifies a binding between a public key and a set of attributes that includes (at least) a subject, name, issuer name, serial number and validity interval. This binding may be subject to subsequent revocation d by mechanisms that include issuance of CRLs, OCSP tokens or mechanisms that are outside the X.509 framework, such as XKMS. An X.509 certificate may be used to validate a public key that may be used to authenticate a SOAP message or to identify the public key with SOAP message that has been encrypted. X.509 certificates rely on the use of key pairs. A key pair consists of two distinct values,either of which may be used to encrypt data. Once data has been encrypted with one of the keys, it can subsequently only be decrypted using the other key. For this reason the mechanism is sometimes referred to as asymmetric key cryptography. Once a key pair has been generated, then one of the keys is published (made known to anyone that wants it); theother remains known only to one person. An X.509 certificate for an entity contains (among other things) the public key for that entity. By presenting its certificate, as well as some data which has been encrypted with its privatekey, an entity can therefore prove its identity (because no one other than the owner of theprivate key could have encrypted the data). Provided the certificate owner is a trusted entity, a transaction can proceed safe in the knowledge that no-one is masquerading as that entity. A natural way of organising mutual authentication would be for everyone to keep a copy ofthe certificates for all the entities that they trust: when I am presented with a certificate, I just check to see if it’s in my list.
Document ID: RDWR-AD-V021403-UG0211
585
AppDirector Guide SSL Encryption,Certificates and Ciphers However, this doesn’t scale very well: a list of certificates for alllegitimate s might be impractically large, as well as being difficult to keep up to date. To make this easier, each X.509 certificate contains the identity of another entity which "issued"the certificate; such an entity is referred to as a Certificate Authority (CA). By issuing (org) a certificate, a CA vouches for the entity that owns the certificate. Assuming I trustthe CA, then by obtaining the CA’s certificate I can safely trust any certificate subsequentlypresented to me which has been signed by the CA. So an X.509 certificate contains (among other things) the following information: •
The identity of the Certificate Authority (CA) which issued the certificate·
•
A range of dates outside which the certificate may not be used·
•
The name of the entity that the certificate belongs to. Such names are represented as Distinguished Names.
Entity’s public key The process for obtaining a key pair and certificate for an entity is first to create a key pair and a Certificate g Request (CSR). The CSR includes (among other things) the public key and the name of the entity. The CSR is then submitted to the CA, which will (assuming it is happy to do so) produce a corresponding certificate, whose "issuer" field will contain the identity of the CA. The certificate issued by the CA for the entity may be given to anyone (the certificate itself contains no confidential information). But it can only be used to perform strong authentication by the entity itself, since using the certificate in this way requires knowledge of the private key.
Note: The CA never sees the entity’s private key (it is not contained in the CSR), so even it cannot subsequently use the certificate in this way.
Secure Identities Assuming you have obtained a certificate, then in order to make use of it to perform strong authentication, you need: •
The certificate itself
•
Your private key
Some information about what CAs you yourself are prepared to trust (because the other entity will send you their certificate, and you will want to check that whoever issued it is on your list) Isode software refers to this set of information as an "identity": you may have one or more identities, each of which will be stored in a separate file. Whenever X.509 strong authentication is performed, each entity will use an identity of its own. Since identities include sensitive data (the private key), they are stored in an encrypted form using a phrase, and can only be used by someone who knows that phrase. The phrase itself is used only to gain access to the identity on the local system: it is never transmitted as part of any strong authentication operation.
Signed Operations As part of the X.500 Directory Standard, individual directory operations (such as read, search and modify) may be "signed". In the case of a signed operation, a cryptographically secure signature is computed and included in both the request that is sent to the Directory, and the response which the Directory returns. g a message incurs an overhead, but makes it much less likely that the content of that message could be tampered with without the recipient realising.
586
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide SSL Encryption,Certificates and Ciphers
Online Certificate Status Protocol (OS) The Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate. It is described in RFC 2560 and is on the Internet standards track. It was created as an alternative to certificate revocation lists (CRL), specifically addressing certain problems associated with using CRLs in a public key infrastructure (PKI). Messages communicated via OCSP are encoded in ASN.1 and are usually communicated over HTTP. The "request/response" nature of these messages leads to OCSP servers being termed OCSP responders.
Compared to CRLs Since an OCSP response contains less information than a typical CRL(certificate revocation list), OCSP can feasibly provide more timely information regarding the revocation status of a certificate without burdening the network. However, the greater number of requests and connection overhead may overwhelm this benefit if the client does not cache responses. Using OCSP, clients do not need to parse CRLs themselves, saving client-side complexity. However, this is balanced by the practical need to maintain a cache. In practice, such considerations are of little consequence, since most applications rely on third-party libraries for all X.509 functions. CRLs may be seen as analogous to a credit card company's "bad customer list" – an unnecessary public exposure. OCSP discloses to the requester that a particular network host used a particular certificate at a particular time. OCSP does not mandate encryption, so this information also may be intercepted by other parties.
Basic PKI implementation Alice and Bob have public key certificates issued by Ivan, the Certificate Authority (CA). Alice wishes to perform a transaction with Bob and sends him her public key certificate. Bob, concerned that Alice's private key may have been compromised, creates an 'OCSP request' that contains Alice's certificate serial number and sends it to Ivan. Ivan's OCSP responder looks up the revocation status of Alice's certificate (using the certificate serial number Bob informed) in his own CA database. If Alice's private key had been compromised, this is the only trusted location at which the fact would be recorded. Ivan's OCSP responder confirms that Alice's certificate is still OK, and returns a signed, successful 'OCSP response' to Bob. Bob cryptographically verifies the signed response (He has Ivan's public key on-hand – Ivan is a trusted responder) and ensures that it was produced recently. Bob completes the transaction with Alice.
Protocol details An OCSP responder may return a signed response signifying that the certificate specified in the request is 'good', 'revoked' or 'unknown'. If it cannot process the request, it may return an error code. The OCSP request format s additional extensions. This enables extensive customization to a particular PKI scheme. OCSP can be resistant to replay attacks, where a signed, 'good' response is captured by a malicious intermediary and replayed to the client at a later date after the subject certificate may have been revoked. OCSP overcomes this by allowing a nonce to be included in the request that must be included in the corresponding response.
Document ID: RDWR-AD-V021403-UG0211
587
AppDirector Guide SSL Encryption,Certificates and Ciphers However, the replay attack, while a possibility, is not a major threat to validation systems. This is due to the steps it takes to actually exploit this weakness. The attacker would have to be in a position to •
capture the traffic and subsequently replay that traffic,
•
capture the status of a certificate whose status is about to change and
•
conduct a transaction requiring the status of that certificate within the time frame of the validity of the response.
Since it is not often that a revoked certificate is unrevoked (only if it is suspended is it even possible) a person would have to capture a good response and wait until the certificate was revoked then replay it. OCSP can more than one level of CA. OCSP requests may be chained between peer responders to query the issuing CA appropriate for the subject certificate, with responders validating each other's responses against the root CA using their own OCSP requests. An OCSP responder may be queried for revocation information by delegated path validation (DPV) servers. OCSP does not, by itself, perform any DPV of supplied certificates. The key that signs a response need not be the same key that signed the certificate. The certificate's issuer may delegate another authority to be the OCSP responder. In this case, the responder's certificate (the one that is used to sign the response) must be issued by the issuer of the certificate in question, and must include a certain extension that marks it as an OCSP g authority (more precisely, an extended key usage extension with the OID {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) keyPurpose(3) ocspg(9)})
OCSP Browser Internet Explorer starting with version 7 on Windows Vista (not XP) s OCSP checking. All versions of Firefox OCSP checking. Firefox 3 enables OCSP checking by default. Safari on Mac OS X s OCSP checking. OCSPD process in Safari is frequently the cause of Safari spinning beachballs and systemwide stalls or 'paralysis'. This may be confirmed by monitoring U or real memory usage of processes in the Activity Monitor application. Versions of Opera from 8.0[1] to the current version OCSP checking.
Certificate g Request (CSR) In public key infrastructure systems, a certificate g request (also CSR or certification request) is a message sent from an applicant to a certificate authority in order to apply for a digital identity certificate. Before creating a CSR, the applicant first generates a key pair, keeping the private key secret. The CSR contains information identifying the applicant (such as a distinguished name in the case of an X.509 certificate), and the public key chosen by the applicant. The corresponding private key is not included in the CSR, but is used to digitally sign the entire request. The CSR may be accompanied by other credentials or proofs of identity required by the certificate authority, and the certificate authority may the applicant for further information. If the request is successful, the certificate authority will send back an identity certificate that has been digitally signed with the private key of the certificate authority.
Certificate Authority In cryptography, a certificate authority or certification authority (CA) is an independent entity that issues digital certificates for use by other parties. It is an example of a trusted third party. Before issuing a certificate, a certificate authority will examine the credentials of the person or organization that has requested the certificate. When the certificate has been issued, information about it is held on a publicly accessible repository. s can consult the repository to check the status and validity of any certificates receivedCAs are characteristic of many public key infrastructure (PKI) schemes. In order that one system can be assured that a certificate received from another system is genuine, a trusted third party that can vouch for the certificate is needed.
588
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide SSL Encryption,Certificates and Ciphers Certificate authorities issue several levels of security certificates for different purposes. For example: •
Secure e-mail
•
Client authentication
•
Server authentication
There are many commercial CAs that charge for their services. There are also several providers issuing digital certificates to the public at no cost. Institutions and governments may have their own CAs.
Issuing a certificate This article may be confusing or unclear to readers. Please help clarify the article; suggestions may be found on the talk page. (February 2009) A CA issues digital certificates that contain a public key and the identity of the owner. The matching private key is not similarly made available publicly, but kept secret by the end who generated the key pair. The certificate is also an attestation by the CA that the public key contained in the certificate belongs to the person, organization, server or other entity noted in the certificate. A CA's obligation in such schemes is to an applicant's credentials, so that s and relying parties can trust the information in the CA's certificates. CAs use a variety of standards and tests to do so. In essence the Certificate Authority is responsible for saying "yes" this person is who they say they are, and we, the CA, that. If the trusts the CA and can the CA's signature, then he can also that a certain public key does indeed belong to whomever is identified in the certificate.
Subversion of CA If the CA can be subverted, then the security of the entire system is lost for each for whom the CA is attesting a link between a public key and an identity. For example, suppose an attacker, Eve (not using the Alice and Bob convention), manages to get a CA to issue to her a certificate that claims to represent Alice. That is, the certificate would publicly state that it represents Alice, and might include other information about Alice. Some of the information about Alice, such as her employer name, might be true, increasing the certificate's credibility. Eve, however, would have the all-important private key associated with the certificate. Eve could then use the certificate to send digitally signed email to Bob, tricking Bob into believing that the email was from Alice. Bob might even respond with encrypted email, believing that it could only be read by Alice, when Eve is actually able to decrypt it using the private key.
Security The problem of assuring correctness of match between data and entity when the data are presented to the CA (perhaps over an electronic network), and when the credentials of the person/company/ program asking for a certificate are likewise presented, is difficult. This is why commercial CAs often use a combination of authentication techniques including leveraging government bureaus, the payment infrastructure, third parties' databases and services, and custom heuristics. In some enterprise systems, local forms of authentication such as Kerberos can be used to obtain a certificate which can in turn be used by external relying parties. Notaries are required in some cases to personally know the party whose signature is being notarized; this is a higher standard than is reached by many CAs. In large-scale deployments, Alice may not be familiar with Bob's certificate authority (perhaps they each have a different CA server), so Bob's certificate may also include his CA's public key signed by a different CA2, which is presumably recognizable by Alice. This process typically leads to a hierarchy or mesh of CAs and CA certificates.
Document ID: RDWR-AD-V021403-UG0211
589
AppDirector Guide SSL Encryption,Certificates and Ciphers
Ciphers and Cipher Suites This section covers an introduction to Ciphers, Cipher suites in general and those specifically used by AppDirector. •
Ciphers, page 590
•
Cipher Suites, page 591
•
Cipher Suites, page 591
•
Cipher Suites Used by AppDirector, page 592
Ciphers In cryptography, a cipher (or cypher) is an algorithm for performing encryption or decryption — a series of well-defined steps that can be followed as a procedure. An alternative, less common term is encipherment. In non-technical usage, a “cipher” is the same thing as a “code”; however, the concepts are distinct in cryptography. In classical cryptography, ciphers were distinguished from codes. Codes operated by substituting according to a large codebook which linked a random string of characters or numbers to a word or phrase. For example, “UQJHSE” could be the code for “Proceed to the following coordinates”. When using a cipher the original information is known as plaintext, and the encrypted form as ciphertext. The ciphertext message contains all the information of the plaintext message, but is not in a format readable by a human or computer without the proper mechanism to decrypt it; it should resemble random gibberish to those not intended to read it. The operation of a cipher usually depends on a piece of auxiliary information, called a key or, in traditional NSA parlance, a cryptovariable. The encrypting procedure is varied depending on the key, which changes the detailed operation of the algorithm. A key must be selected before using a cipher to encrypt a message. Without knowledge of the key, it should be difficult, if not nearly impossible, to decrypt the resulting ciphertext into readable plaintext. Most modern ciphers can be categorized in several ways •
By whether they work on blocks of symbols usually of a fixed size (block ciphers), or on a continuous stream of symbols (stream ciphers).
•
By whether the same key is used for both encryption and decryption (symmetric key algorithms), or if a different key is used for each (asymmetric key algorithms). If the algorithm is symmetric, the key must be known to the recipient and sender and to no one else. If the algorithm is an asymmetric one, the enciphering key is different from, but closely related to, the deciphering key. If one key cannot be deduced from the other, the asymmetric key algorithm has the public/private key property and one of the keys may be made public without loss of confidentiality
Modern encryption methods can be divided by two criteria — by type of key used, and by type of input data.
Type of Key Used These ciphers are divided into: •
symmetric key algorithms (Private-key cryptography) — where the same key is used for encryption and decryption. In a symmetric key algorithm (e.g., DES and AES), the sender and receiver must have a shared key set up in advance and kept secret from all other parties; the sender uses this key for encryption, and the receiver uses the same key for decryption. The Feistel cipher uses a combination of substitution and transposition techniques. Most block cipher algorithms are based on this structure
•
asymmetric key algorithms (Public-key cryptography) — where two different keys are used for encryption and decryption. In an asymmetric key algorithm (e.g., RSA), there are two separate keys: a public key is published and enables any sender to perform encryption, while a private key is kept secret by the receiver and enables only him to perform correct decryption.
590
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide SSL Encryption,Certificates and Ciphers
Input Data Ciphers can be distinguished into two types by the type of input data: •
block ciphers, which encrypt block of data of fixed size, and
•
stream ciphers, which encrypt continuous streams of data
Key size and vulnerability In a pure mathematical attack (i.e., lacking any other information to help break a cipher), three factors above all, count: •
Mathematical advances that allow new attacks or weaknesses to be discovered and exploited.
•
Computational power available, i.e., the computing power which can be brought to bear on the problem. It is important to note that average performance/capacity of a single computer is not the only factor to consider. An adversary can use multiple computers at once, for instance, to increase the speed of exhaustive search for a key (i.e., “brute force” attack) substantially.
•
Key size, i.e., the size of key used to encrypt a message. As the key size increases, so does the complexity of exhaustive search to the point where it becomes infeasible to crack encryption directly.
Cipher Suites A cipher suite is a named combination of authentication, encryption, and message authentication code (MAC) algorithms used to negotiate the security settings for a network connection using the Transport Layer Security (TLS) or Secure Sockets Layer (SSL) network protocol. The structure and use of the cipher suite concept is defined in the documents that define the protocol (RFC 5246 standard for TLS version 1.2). A reference for named cipher suites is provided in RFC 2434, the TLS Cipher Suite Registry. When a TLS connection is established, a handshaking, known as the TLS Handshake Protocol, occurs. Within this handshake, a client hello (ClientHello) and a server hello (ServerHello) message is ed. (RFC 5246, p. 37) First, the client sends a cipher suite list, a list of the cipher suites that it s, in order of preference. Then the server replies with the cipher suite that it has selected from the client cipher suite list. (RFC 5246, p. 40) In order to test which TLS ciphers that a server s an SSL/TLS Scanner may be used. Each named cipher suite defines a key exchange algorithm, a bulk encryption algorithm, a message authentication code (MAC) algorithm, and a pseudorandom function (PRF). (RFC 5246, p. 40) The key exchange algorithm is used to determine if and how the client and server will authenticate during the handshake. (RFC 5246, p. 47). The bulk encryption algorithm is used to encrypt the message stream. It also includes the key size and the lengths of explicit and implicit initialization vectors (cryptographic nonces). (RFC 5246, p. 17). The message authentication code (MAC) algorithm is used to create the message digest, a cryptographic hash of each block of the message stream. (RFC 5246, p. 17). The pseudorandom function (PRF) is used to create the master secret, a 48-byte secret shared between the two peers in the connection. The master secret is used as a source of entropy when creating session keys, such as the one used to create the MAC. (RFC 5246, p. 16-17, 26).
Document ID: RDWR-AD-V021403-UG0211
591
AppDirector Guide SSL Encryption,Certificates and Ciphers
Cipher Suites Used by AppDirector The Cipher Suites parameter is used to configure SSL policies. It enables you to control which cipher suites are allowed by AppDirector during the SSL handshake, see SSL Policies, page 195. Complete List of the Content Of All Cipher Suites (Front-end and Back-end), page 593 shows a list of all Cipher suites including the following categories. • RSA (Default): Cipher suite using RSA key exchange. • ALL: All cipher suites. • PCI DSS Compliance: Payment Card Industry Data Security Standard • ALL Non-Null Ciphers: All cipher suites except the NULL ciphers and ciphers offering no authentication, which must be explicitly enabled. • SSLv3: SSL v3.0 cipher suites. • TLSv1: TLS v1.0 cipher suites • Export: Export encryption algorithms including 40 and 56 bit. • Low: “Low” exception cipher suites, currently using 64 or 56 bit encryption algorithms but excluding export cipher suites. • Medium: “Medium” encryption cipher suites, currently using 128 bit encryption • High: “High” encryption cipher suites. Currently key lengths are larger than 128 bits. • RSA:RC4-128:MD5: Cipher suites using RSA key exchange, 128 bit RC4 for encryption and MD5 for MAC. • RSA:RC4-128:SHA1: Cipher suite using RSA key exchange, 128 bit RC4 for encryption and SHA1 hash for MAC. • RSA:DES:SHA1:Cipher suite using RSA key exchange, 3DES for encryption and SHA1 hash for MAC. • RSA:3DES:SHA1:Cipher suite using RSA key exchange, 3DES for encryption and SHA1 hash for MAC. • RSA:AES-128:SHA1: Cipher suite using RSA key exchange, 128-bit AES for encryption and SHA1 hash for MAC. • RSA:AES-256:SHA1: Cipher suite using RSA key exchange, 256-bit AES for encryption and SHA1 hash for MAC. • MSIE Export56: 56 bit export version of Microsoft Internet Browser v 5. • Defined - AppDirector s all ciphers ed by the accepted OpenSSL format and more information can be found in OpenSSL documentation.
592
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide SSL Encryption,Certificates and Ciphers
Table 8: Complete List of the Content Of All Cipher Suites (Front-end and Back-end) The used in this table are: •
AES—Advanced Encryption Standard
•
DES—Data Encryption Standard
•
DSS—Digital Signature Standard
•
MD5—Message Digest algorithm
•
RC2, RC4—Rivest encryption
•
RSA—Rivest-Shamir-Adleman encryption
•
SHA-1—Secure Hash algorithm
•
3DES—DES applied three times
Cipher Suite Name
Kx – key exchange algorithm
Au – Enc –symmetric Mac – digest authentication encryption algorithm algorithm algorithm
AES256-SHA
Kx=RSA
Au=RSA
Enc=AES(256)
DES-CBC3-SHA
Kx=RSA
Au=RSA
Enc=3DES(168) Mac=SHA1
AES128-SHA
Kx=RSA
Au=RSA
Enc=AES(128)
Mac=SHA1
RC4-SHA
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=SHA1
RC4-MD5
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=MD5
DES-CBC-SHA
Kx=RSA
Au=RSA
Enc=DES(56)
Mac=SHA1
NULL-SHA
Kx=RSA
Au=RSA
Enc=None
Mac=SHA1
NULL-MD5
Kx=RSA
Au=RSA
Enc=None
Mac=MD5
ADH-AES256-SHA
Kx=DH
Au=None
Enc=AES(256)
Mac=SHA1
Front End - ALL Mac=SHA1
DHE-RSA-AES256-SHA
Kx=DH
Au=RSA
Enc=AES(256)
Mac=SHA1
DHE-DSS-AES256-SHA
Kx=DH
Au=DSS
Enc=AES(256)
Mac=SHA1
ADH-DES-CBC3-SHA
Kx=DH
Au=None
Enc=3DES(168) Mac=SHA1
EDH-RSA-DES-CBC3-SHA
Kx=DH
Au=RSA
Enc=3DES(168) Mac=MD5
EDH-DSS-DES-CBC3-SHA
Kx=DH
Au=DSS
Enc=3DES(168) Mac=SHA1
DHE-DSS-RC4-SHA
Kx=DH
Au=DSS
Enc=RC4(128)
ADH-AES128-SHA
Kx=DH
Au=None
Enc=AES(128)
Mac=SHA1
DHE-RSA-AES128-SHA
Kx=DH
Au=RSA
Enc=AES(128)
Mac=SHA1
DHE-DSS-AES128-SHA
Kx=DH
Au=DSS
Enc=AES(128)
Mac=SHA1
Mac=SHA1
ADH-RC4-MD5
Kx=DH
Au=None
Enc=RC4(128)
Mac=MD5
ADH-DES-CBC-SHA
Kx=DH
Au=None
Enc=DES(56)
Mac=SHA1
EDH-RSA-DES-CBC-SHA
Kx=DH
Au=RSA
Enc=DES(56)
Mac=SHA1
EDH-DSS-DES-CBC-SHA
Kx=DH
Au=DSS
Enc=DES(56)
Mac=SHA1
EXP1024-RC4-SHA
Kx=RSA(1024)
Au=RSA
Enc=RC4(56)
Mac=SHA1 export
EXP1024-DES-CBC-SHA
Kx=RSA(1024)
Au=RSA
Enc=DES(56)
Mac=SHA1 export
EXP-DES-CBC-SHA
Kx=RSA(512)
Au=RSA
Enc=DES(40)
Mac=SHA1 export
Document ID: RDWR-AD-V021403-UG0211
593
AppDirector Guide SSL Encryption,Certificates and Ciphers
Cipher Suite Name
Kx – key exchange algorithm
Au – Enc –symmetric Mac – digest authentication encryption algorithm algorithm algorithm
EXP-RC4-MD5
Kx=RSA(512)
Au=RSA
Enc=RC4(40)
Mac=MD5 export
EXP1024-DHE-DSS-RC4-SHA Kx=DH(1024)
Au=DSS
Enc=RC4(56)
Mac=SHA1 export
EXP1024-DHE-DSS-DESCBC-SHA
Kx=DH(1024)
Au=DSS
Enc=DES(56)
Mac=SHA1 export
EXP-ADH-DES-CBC-SHA
Kx=DH(512)
Au=None
Enc=DES(40)
Mac=SHA1 export
EXP-ADH-RC4-MD5
Kx=DH(512)
Au=None
Enc=RC4(40)
Mac=MD5 export
EXP-EDH-RSA-DES-CBC-SHA
Kx=DH(512)
Au=RSA
Enc=DES(40)
Mac=SHA1 export
EXP-EDH-DSS-DES-CBC-SHA Kx=DH(512)
Au=DSS
Enc=DES(40)
Mac=SHA1 export
Mac=SHA1
Front End - PCI DSS Compliance AES256-SHA
Kx=RSA
Au=RSA
Enc=AES(256)
DES-CBC3-SHA
Kx=RSA
Au=RSA
Enc=3DES(168) Mac=SHA1
AES128-SHA
Kx=RSA
Au=RSA
Enc=AES(128)
Mac=SHA1
RC4-SHA
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=SHA1
RC4-MD5
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=MD5
DHE-DSS-AES256-SHA
Kx=DH(512)
Au=DSS
Enc=AES(256)
Mac=SHA1
EDH-RSA-DES-CBC3-SHA
Kx=DH(512)
Au=RSA
Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC3-SHA
Kx=DH(512)
Au=DSS
Enc=3DES(168) Mac=SHA1
DHE-DSS-RC4-SHA
Kx=DH(512)
Au=DSS
Enc=RC4(128)
Mac=SHA1
DHE-DSS-AES128-SHA
Kx=DH(512)
Au=DSS
Enc=AES(128)
Mac=SHA1
Mac=SHA1
Front End - All Non Null Ciphers AES256-SHA
Kx=RSA
Au=RSA
Enc=AES(256)
DES-CBC3-SHA
Kx=RSA
Au=RSA
Enc=3DES(168) Mac=SHA1
AES128-SHA
Kx=RSA
Au=RSA
Enc=AES(128)
Mac=SHA1
RC4-SHA
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=SHA1
RC4-MD5
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=MD5
DES-CBC-SHA
Kx=RSA
Au=RSA
Enc=DES(56)
Mac=SHA1
DHE-RSA-AES256-SHA
Kx=DH
Au=RSA
Enc=AES(256)
Mac=SHA1 Mac=SHA1
DHE-DSS-AES256-SHA
Kx=DH
Au=DSS
Enc=AES(256)
EDH-RSA-DES-CBC3-SHA
Kx=DH
Au=RSA
Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC3-SHA
Kx=DH
Au=DSS
Enc=3DES(168) Mac=SHA1
DHE-DSS-RC4-SHA
Kx=DH
Au=DSS
Enc=RC4(128)
Mac=SHA1
DHE-RSA-AES128-SHA
Kx=DH
Au=RSA
Enc=AES(128)
Mac=SHA1
DHE-DSS-AES128-SHA
Kx=DH
Au=DSS
Enc=AES(128)
Mac=SHA1
594
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide SSL Encryption,Certificates and Ciphers
Cipher Suite Name
Kx – key exchange algorithm
Au – Enc –symmetric Mac – digest authentication encryption algorithm algorithm algorithm
EDH-RSA-DES-CBC-SHA
Kx=DH
Au=RSA
Enc=DES(56)
Mac=SHA1
EDH-DSS-DES-CBC-SHA
Kx=DH
Au=DSS
Enc=DES(56)
Mac=SHA1
EXP1024-RC4-SHA
Kx=RSA(1024)
Au=RSA
Enc=RC4(56)
Mac=SHA1 export
EXP1024-DES-CBC-SHA
Kx=RSA(1024)
Au=RSA
Enc=DES(56)
Mac=SHA1 export
EXP-DES-CBC-SHA
Kx=RSA(512
Au=RSA
Enc=DES(40)
Mac=SHA1 export
EXP-RC4-MD5
Kx=RSA(512
Au=RSA
Enc=RC4(40)
Mac=MD5 export
EXP1024-DHE-DSS-RC4-SHA Kx=DH(1024)
Au=DSS
Enc=RC4(56)
Mac=SHA1 export
EXP1024-DHE-DSS-DESCBC-SHA
Kx=DH(1024)
Au=DSS
Enc=DES(56
Mac=SHA1 export
EXP-EDH-RSA-DES-CBC-SHA
Kx=DH(512)
Au=RSA
Enc=DES(40)
Mac=SHA1 export
EXP-EDH-DSS-DES-CBC-SHA Kx=DH(512)
Au=DSS
Enc=DES(40)
Mac=SHA1 export
Mac=SHA1
Front End - SSL v3 AES256-SHA
Kx=RSA
Au=RSA
Enc=AES(256)
DES-CBC3-SHA
Kx=RSA
Au=RSA
Enc=3DES(168) Mac=SHA1
AES128-SHA
Kx=RSA
Au=RSA
Enc=AES(128)
Mac=SHA1
RC4-SHA
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=SHA1
RC4-MD5
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=MD5
DES-CBC-SHA
Kx=RSA
Au=RSA
Enc=DES(56)
Mac=SHA1
NULL-SHA
Kx=RSA
Au=RSA
Enc=None
Mac=SHA1
NULL-MD5
Kx=RSA
Au=RSA
Enc=None
Mac=MD5
ADH-AES256-SHA
Kx=DH
Au=None
Enc=AES(256)
Mac=SHA1
DHE-RSA-AES256-SHA
Kx=DH
Au=RSA
Enc=AES(256)
Mac=SHA1
DHE-DSS-AES256-SHA
Kx=DH
Au=DSS
Enc=AES(256)
Mac=SHA1
ADH-DES-CBC3-SHA
Kx=DH
Au=None
Enc=3DES(168) Mac=SHA1
EDH-RSA-DES-CBC3-SHA
Kx=DH
Au=RSA
Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC3-SHA
Kx=DH
Au=DSS
Enc=3DES(168) Mac=SHA1
DHE-DSS-RC4-SHA
Kx=DH
Au=DSS
Enc=RC4(128)
Mac=SHA1
ADH-AES128-SHA
Kx=DH
Au=None
Enc=AES(128)
Mac=SHA1
DHE-RSA-AES128-SHA
Kx=DH
Au=RSA
Enc=AES(128)
Mac=SHA1
DHE-DSS-AES128-SHA
Kx=DH
Au=DSS
Enc=AES(128)
Mac=SHA1
ADH-RC4-MD5
Kx=DH
Au=None
Enc=RC4(128)
Mac=MD5
ADH-DES-CBC-SHA
Kx=DH
Au=None
Enc=DES(56)
Mac=SHA1
EDH-RSA-DES-CBC-SHA
Kx=DH
Au=RSA
Enc=DES(56)
Mac=SHA1
Document ID: RDWR-AD-V021403-UG0211
595
AppDirector Guide SSL Encryption,Certificates and Ciphers
Cipher Suite Name
Kx – key exchange algorithm
Au – Enc –symmetric Mac – digest authentication encryption algorithm algorithm algorithm
EDH-DSS-DES-CBC-SHA
Kx=DH
Au=DSS
Enc=DES(56)
Mac=SHA1
EXP1024-RC4-SHA
Kx=RSA(1024)
Au=RSA
Enc=RC4(56)
Mac=SHA1 export
EXP1024-DES-CBC-SHA
Kx=RSA(1024)
Au=RSA
Enc=DES(56)
Mac=SHA1 export
EXP-DES-CBC-SHA
Kx=RSA(512)
Au=RSA
Enc=DES(40)
Mac=SHA1 export
EXP-RC4-MD5
Kx=RSA(512)
Au=RSA
Enc=RC4(40)
Mac=MD5 export
EXP1024-DHE-DSS-RC4-SHA Kx=RSA(1024)
Au=DSS
Enc=RC4(56)
Mac=SHA1 export
EXP1024-DHE-DSS-DESCBC-SHA
Kx=RSA(1024)
Au=DSS
Enc=DES(56)
Mac=SHA1 export
EXP-ADH-DES-CBC-SHA
Kx=RSA(512)
Au=None
Enc=DES(40)
Mac=SHA1 export
EXP-ADH-RC4-MD5
Kx=RSA(512)
Au=None
Enc=RC4(40)
Mac=MD5 export
EXP-EDH-RSA-DES-CBC-SHA
Kx=RSA(512)
Au=RSA
Enc=DES(40)
Mac=SHA1 export
EXP-EDH-DSS-DES-CBC-SHA Kx=RSA(512)
Au=DSS
Enc=DES(40)
Mac=SHA1 export
Mac=SHA1
Front End - TLSv1 AES256-SHA
Kx=RSA
Au=RSA
Enc=AES(256)
DES-CBC3-SHA
Kx=RSA
Au=RSA
Enc=3DES(168) Mac=SHA1
AES128-SHA
Kx=RSA
Au=RSA
Enc=AES(128)
Mac=SHA1
RC4-SHA
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=SHA1
RC4-MD5
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=MD5
DES-CBC-SHA
Kx=RSA
Au=RSA
Enc=DES(56)
Mac=SHA1
NULL-SHA
Kx=RSA
Au=RSA
Enc=None
Mac=SHA1
NULL-MD5
Kx=RSA
Au=RSA
Enc=None
Mac=MD5
ADH-AES256-SHA
Kx=DH
Au=None
Enc=AES(256)
Mac=SHA1
DHE-RSA-AES256-SHA
Kx=DH
Au=RSA
Enc=AES(256)
Mac=SHA1
DHE-DSS-AES256-SHA
Kx=DH
Au=DSS
Enc=AES(256)
Mac=SHA1
ADH-DES-CBC3-SHA
Kx=DH
Au=None
Enc=3DES(168) Mac=SHA1
EDH-RSA-DES-CBC3-SHA
Kx=DH
Au=RSA
Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC3-SHA
Kx=DH
Au=DSS
Enc=3DES(168) Mac=SHA1
DHE-DSS-RC4-SHA
Kx=DH
Au=DSS
Enc=RC4(128)
Mac=SHA1
ADH-AES128-SHA
Kx=DH
Au=None
Enc=AES(128)
Mac=SHA1
DHE-RSA-AES128-SHA
Kx=DH
Au=RSA
Enc=AES(128)
Mac=SHA1
DHE-DSS-AES128-SHA
Kx=DH
Au=DSS
Enc=AES(128)
Mac=SHA1
ADH-RC4-MD5
Kx=DH
Au=DSS
Enc=RC4(128)
Mac=MD5
596
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide SSL Encryption,Certificates and Ciphers
Cipher Suite Name
Kx – key exchange algorithm
Au – Enc –symmetric Mac – digest authentication encryption algorithm algorithm algorithm
ADH-DES-CBC-SHA
Kx=DH
Au=None
Enc=DES(56)
Mac=SHA1
EDH-RSA-DES-CBC-SHA
Kx=DH
Au=RSA
Enc=DES(56)
Mac=SHA1
EDH-DSS-DES-CBC-SHA
Kx=DH
Au=DSS
Enc=DES(56)
Mac=SHA1
EXP1024-RC4-SHA
Kx=RSA(1024)
Au=RSA
Enc=RC4(56)
Mac=SHA1 export
EXP1024-DES-CBC-SHA
Kx=RSA(1024)
Au=RSA
Enc=DES(56)
Mac=SHA1 export
EXP-DES-CBC-SHA
Kx=RSA(512)
Au=RSA
Enc=DES(40)
Mac=SHA1 export
EXP-RC4-MD5
Kx=RSA(512)
Au=RSA
Enc=RC4(40)
Mac=MD5 export
EXP1024-DHE-DSS-RC4-SHA Kx=DH(1024)
Au=DSS
Enc=RC4(56)
Mac=SHA1 export
EXP1024-DHE-DSS-DESCBC-SHA
Kx=DH(1024)
Au=DSS
Enc=DES(56)
Mac=SHA1 export
EXP-ADH-DES-CBC-SHA
Kx=DH(512)
Au=None
Enc=DES(40)
Mac=SHA1 export
EXP-ADH-RC4-MD5
Kx=DH(512)
Au=None
Enc=RC4(40)
Mac=MD5 export
EXP-EDH-RSA-DES-CBC-SHA
Kx=DH(512)
Au=RSA
Enc=DES(40)
Mac=SHA1 export
EXP-EDH-DSS-DES-CBC-SHA Kx=DH(512)
Au=DSS
Enc=DES(40)
Mac=SHA1 export
Front End - Export
Front End - Low DES-CBC-SHA
Kx=RSA
Au=RSA
Enc=DES(56)
Mac=SHA1
ADH-DES-CBC-SHA
Kx=DH
Au=None
Enc=DES(56)
Mac=SHA1
EDH-RSA-DES-CBC-SHA
Kx=DH
Au=RSA
Enc=DES(56)
Mac=SHA1
EDH-DSS-DES-CBC-SHA
Kx=DH
Au=DSS
Enc=DES(56)
Mac=SHA1
RC4-SHA
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=SHA1
RC4-MD5
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=MD5
DHE-DSS-RC4-SHA
Kx=DH
Au=DSS
Enc=RC4(128)
Mac=SHA1
ADH-RC4-MD5
Kx=DH
Au=None
Enc=RC4(128)
Mac=MD5
AES256-SHA
Kx=RSA
Au=RSA
Enc=AES(256)
Mac=SHA1
DES-CBC3-SHA
Kx=RSA
Au=RSA
Enc=3DES(168) Mac=SHA1
AES128-SHA
Kx=RSA
Au=RSA
Enc=AES(128)
Mac=SHA1
ADH-AES256-SHA
Kx=DH
Au=None
Enc=AES(256)
Mac=SHA1
DHE-RSA-AES256-SHA
Kx=DH
Au=RSA
Enc=AES(256)
Mac=SHA1
Front End - Medium
Front End - High
Document ID: RDWR-AD-V021403-UG0211
597
AppDirector Guide SSL Encryption,Certificates and Ciphers
Cipher Suite Name
Kx – key exchange algorithm
Au – Enc –symmetric Mac – digest authentication encryption algorithm algorithm algorithm
DHE-DSS-AES256-SHA
Kx=DH
Au=DSS
Enc=AES(256)
ADH-DES-CBC3-SHA
Kx=DH
Au=None
Enc=3DES(168) Mac=SHA1
EDH-RSA-DES-CBC3-SHA
Kx=DH
Au=RSA
Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC3-SHA
Kx=DH
Au=DSS
Enc=3DES(168) Mac=SHA1
ADH-AES128-SHA
Kx=DH
Au=None
Enc=AES(128)
Mac=SHA1
DHE-RSA-AES128-SHA
Kx=DH
Au=RSA
Enc=AES(128)
Mac=SHA1
DHE-DSS-AES128-SHA
Kx=DH
Au=DSS
Enc=AES(128)
Mac=SHA1
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=MD5
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=SHA1
Kx=RSA
Au=RSA
Enc=DES(56)
Mac=SHA1
Kx=RSA
Au=RSA
Enc=3DES(168) Mac=SHA1
Kx=RSA
Au=RSA
Enc=AES(128)
Mac=SHA1
Kx=RSA
Au=RSA
Enc=AES(256)
Mac=SHA1
AES256-SHA
Kx=RSA
Au=RSA
Enc=AES(256)
Mac=SHA1
DES-CBC3-SHA
Kx=RSA
Au=RSA
Enc=3DES(168) Mac=SHA1
AES128-SHA
Kx=RSA
Au=RSA
Enc=AES(128)
Mac=SHA1
RC4-SHA
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=SHA1
RC4-MD5
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=MD5
DES-CBC-SHA
Kx=RSA
Au=RSA
Enc=DES(56)
Mac=SHA1
DHE-RSA-AES256-SHA
Kx=DH
Au=RSA
Enc=AES(256)
Mac=SHA1
DHE-DSS-AES256-SHA
Kx=DH
Au=DSS
Enc=AES(256)
Mac=SHA1
EDH-RSA-DES-CBC3-SHA
Kx=DH
Au=RSA
Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC3-SHA
Kx=DH
Au=DSS
Enc=3DES(168) Mac=SHA1
DHE-RSA-AES128-SHA
Kx=DH
Au=RSA
Enc=AES(128)
Mac=SHA1
DHE-DSS-AES128-SHA
Kx=DH
Au=DSS
Enc=AES(128)
Mac=SHA1
DHE-DSS-RC4-SHA
Kx=DH
Au=DSS
Enc=RC4(128)
Mac=SHA1
EDH-RSA-DES-CBC-SHA
Kx=DH
Au=RSA
Enc=DES(56)
Mac=SHA1
EDH-DSS-DES-CBC-SHA
Kx=DH
Au=DSS
Enc=DES(56)
Mac=SHA1
EXP-DES-CBC-SHA
Kx=RSA
Au=RSA
Enc=DES(40)
Mac=SHA1 export
Mac=SHA1
RSA:RC4-128:MD5: RC4-MD5
RSA:RC4-128:SHA1: RC4-SHA
RSA:DES:SHA1: DES-CBC-SHA
RSA:3DES:SHA1: DES-CBC3-SHA
RSA:AES-128:SHA1: AES128-SHA
RSA:AES-256:SHA1: AES256-SHA
MSIE Export56
598
Document ID: RDWR-AD-V021403-UG0211
AppDirector Guide SSL Encryption,Certificates and Ciphers
Cipher Suite Name
Kx – key exchange algorithm
Au – Enc –symmetric Mac – digest authentication encryption algorithm algorithm algorithm
EXP-RC4-MD5
Kx=RSA
Au=RSA
Enc=RC4(40)
Mac=MD5 export
EXP-EDH-RSA-DES-CBC-SHA
Kx=DH(512)
Au=RSA
Enc=DES(40)
Mac=SHA1 export
EXP-EDH-DSS-DES-CBC-SHA Kx=DH(512)
Au=DSS
Enc=DES(40)
Mac=SHA1 export
Back-End - Low RC4-SHA
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=SHA1
RC4-MD5
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=MD5
DES-CBC-SHA
Kx=RSA
Au=RSA
Enc=DES(56)
Mac=SHA1
RC4-SHA
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=SHA1
RC4-MD5
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=MD5
AES256-SHA
Kx=RSA
Au=RSA
Enc=AES(256)
Mac=SHA1
DES-CBC3-SHA
Kx=RSA
Au=RSA
Enc=3DES(168) Mac=SHA1
AES128-SHA
Kx=RSA
Au=RSA
Enc=AES(128)
Back End - Medium
Back End - High
Mac=SHA1
Securing a Connection - the SSL Handshake The most computationally expensive part of an SSL session is the SSL handshake, where the SSL server (usually an SSL webserver) and the SSL client (usually a web browser) agree on a number of parameters that establish the security of the connection. Part of the role of the SSL handshake is to agree on session keys (symmetric keys, used for the duration of a given session), but the encryption and signature of the SSL handshake messages itself is done using asymmetric keys (contained in the certificates), which requires more computational power than the symmetric cryptography used for the encryption/decryption of the session data. Typically a hardware SSL accelerator will offload processing of the SSL handshake while leaving the server software to process the less intense symmetric cryptography of the actual SSL data exchange, but some accelerators act as a proxy handling all SSL operations and leaving the server seeing only unencrypted connections.
Document ID: RDWR-AD-V021403-UG0211
599
Related Documents 3m3m1z
Appdirector Guide Version 2.14 6x6s2w
December 2019 148
Cramm Version 5.1 Guide 4d1b41
December 2019 32
Maltego Version 3 Guide ks4f
December 2019 38
Codeigniter Guide Version 1.7.2 651q3z
December 2019 434
Smi Version 8 Guide 1i144p
December 2019 110
Maximo Guide Version 5.2 6t6w3a
October 2019 76More Documents from "eva" 3e5y3g
1.1.3. Ep. 1 Sop Penngembangan Dalam Penyelenggaraan Upaya Puskesmas (repaired) k1d2g
April 2020 40
Ethiopian Higher Education Proclamation Pdf 646w2h
January 2022 0
Kerangka Acuan 6p3j3a
December 2020 0
1.1.3.1sop-pengembangan-pelayanan.doc 1c2t15
December 2020 0
Appdirector Guide Version 2.14 6x6s2w
December 2019 148