Content Rules

 

1Introduction

The KEMP LoadMaster supports content switching, which is sometimes referred to as URL switching. This allows the LoadMaster to direct specific requests to specific Real Servers based on the contents of the requested URL.

For example, if there are two groups of servers - one to serve images and the other to serve all other content - rules can be created to separate these two types of request. Any URL that includes /images in it, for example http://example.com/images/demo.jpg, would get directed to the image server(s). Anything else gets directed to the other server(s).

Content switching allows the KEMP LoadMaster to break up traffic based on the content of the request. Traffic can be examined by the:

  • Request URL
  • HTTP Header
  • Source IP address
  • Body of a request

Content rules only apply to HTTP or HTTPS traffic.

 

The maximum number of content rules that a LoadMaster can have is 1024.

 

In this document, the term content switching does not refer to the process involved with Layer 2 switching. Instead, content switching refers to the switching of traffic between different servers, depending upon what content was requested.

1.1Document Purpose

This document describes various aspects of the Content Rules feature of the KEMP LoadMaster. It describes in detail how to configure the Content Rules feature using the LoadMaster Web User Interface (WUI).

1.2Intended Audience

This document is intended to help anyone who wishes to learn about or implement Content Rules within the KEMP LoadMaster.

2Advantages of Content Rules

Figure 2‑1: Content switching

Content switching can be very useful if there are dedicated server types that perform different functions such as image servers, static content servers, mapping servers, specialized content servers, application servers and media servers, that all need to be served from the same general hostname, for example www.mysite.com. Content switching also allows for hostname-specific servers and source IP-specific servers.

Content rules give the ability to:

  • Strip out server information
  • Redirect requests for the root of a server
  • Rewrite redirections from HTTP to HTTPS
  • Force connections to close
  • Secure cookies

3Configure a Virtual Service to use Content Rules

There are two parts to configuring content switching: the content rules, and the Virtual Service configuration. The content rules are configured globally on the LoadMaster, and various rules are applied to specific Real Servers operating under a Virtual Service.

The sections below describe the steps required to configure a Virtual Service that makes use of content switching.

3.1Setting up Content Rules

To set up a content rule, follow the steps below on the LoadMaster WUI:

  1. In the main menu, select Rules & Checking and then Content Rules.

There is a default (catch-all) rule, that matches everything. This rule is not editable and will always be the last one to match if Content Switching is enabled in a Virtual Service.

  1. Click the Create New... button.

Figure 3‑1: Create rule screen

  1. Fill out the form as needed. For details on what each of the options mean, refer to Section 3.3.
  2. Click Create Rule.

The rule will be added, but will not affect any Virtual Service. Once the rules have been added, they need to be applied to Real Servers within individual Virtual Services.

To create a rule that will send all URL requests that have /images/ as the root path to a group of servers, the Match String value should be images/* (where images/* is an example of a regular expression).

It is possible to perform content switching on URL, HTTP Header, Source IP or the body of a request. The default behaviour is to test the URL, however a Header Field may be specified instead. To use Source IP content switching, use the pseudo-header src-ip — the source IP of the client will then be available as a text field. The HTTP method can be matched upon by filling out the Header Field text box and the method. The body can be matched upon by entering body in the Header Field text box.

The Match String can be either a Shell Regular Expression or a Perl Compatible Regular Expression (PCRE) and can be 250 characters in length.

KEMP recommends using PCRE expressions instead of Shell.

3.2Configuring Virtual Services

To configure a Virtual Service to use content switching, follow the steps below:

  1. Log in to the relevant LoadMaster WUI.
  2. In the main menu, select Virtual Services and View/Modify Services.

Figure 3‑2: Virtual Services

  1. Click Modify on the relevant Virtual Service.
  2. Expand the Standard Options section.

Figure 3‑3: Standard Options

  1. Select the relevant persistence mode in the Persistence Options drop-down menu.
  2. Expand the Advances Properties section.

Figure 3‑4: Advanced Properties

  1. Click Enable in the Content Switching row.

The enable button will only be available if there is a Real Server set up on this Virtual Service.

 

If you exit the Virtual Service modify screen without adding a content rule to a Real Server you will need to re-enable Content Switching.

Figure 3‑5: Real Servers

  1. Expand the Real Servers section.

There will be a new column called Rules. Content switching has just been enabled, so no rules are active.

  1. Click the None button.
  2. Select the relevant rule in the drop-down list and click Add.

The maximum number of content rules that a LoadMaster can have is 1024. There is no limit on a per-Real Server basis regarding how many of these rules can be assigned.

The rule will be added to the Real Server. Multiple rules can be added to each Real Server.

3.3Content Rules WUI Options

The various fields associated with Content Rules in the LoadMaster WUI are described below.

Figure 3‑6: Content Rules

The Content Rules screen displays the rules that have been configured and gives the option to Modify or Delete.

To define a new rule, click on Create New.

Figure 3‑7: Create Rule screen

The rule must be given a unique name. The Rule Name must be alphanumeric, unique and start with an alpha character. They are case sensitive, thus two different rules can exist in the form Rule1 and rule1. It is not possible to name a content rule default.

The options that are available depend on the Rule Type that is selected. The available rules are as follows:

Rule Types:

  • Content Matching: Matches the content of the header or body of a request
  • Add Header: Adds a header according to the rule
  • Del Header: Deletes the header according to the rule
  • Replace Header: Replaces the header according to the rule
  • Modify URL: Changes the URL according to the rule

3.3.1Content Matching

When the Rule Type selected is Content Matching the following describes the options available.

Figure 3‑8: Create Rule

Rule Name

This is the name of the rule.

Match Type:

  • Regular Expression: A powerful way of creating complex matching and replacement rules. Regular expressions can also be used to reference parts of the original string.
  • Prefix: Matches from the beginning of the string only
  • Postfix: Matches from the end of the string only

When Prefix or Postfix is selected, the Match String should be in the form of a pure string, not a regular expressions.

 

Header Field

The header field name must be matched. If no header field name is set, the default is to match the string within the URL.

Rules can be matched based on the Source IP of the client by entering src-ip within the Header Field input field. The header field will be populated by the source IP of the client.

The Header Field can be set to method in order to match on the HTTP method field.

The body of a request can also be matched by typing body in the Header Field text box. When matching on the body, up to the first 50K of the input stream will be read.

Match String

Input the pattern that is to be matched. Both Shell Regular Expressions and Perl Compatible Regular Expressions (PCRE) are supported. KEMP recommends using the PCRE syntax. Both are the same in terms of performance. Performance will be affected if a highly complex expression is used. The maximum number of characters allowed is 250.

Negation

Negation inverts the sense of the match. Without negation, all requests that include /images/ for example, would match an applicable rule. With negation, all requests except /images/ would match the rule.

 

Ignore Case

If enabled, case is ignored when comparing strings.

Include Host in URL

If selected, this option prepends the hostname, for example for example support.kemptechnologies.com, to the request URL before performing the match.

You may achieve better results by using flagging instead of using the Include Host in URL option. For more information, refer to Section 3.3.1.1.

 

Include Query in URL

Selecting this option includes everything after the ? in a URL. This part of the URL is the URL query. For example, in the URL http://example.com/images/imagid.jsp?item=1, the query is item=1.

Fail on Match

If this rule is matched, then always fail to connect. If an error code or error URL is set, the code/URL will be sent back to the client.

3.3.1.1Use of Flags to Create Dependent Rules

By using the Perform If Flag Set and Set Flag If Matched options it is possible to make rules dependent on each other i.e., only execute a particular rule(s) if another rule(s) has been successfully matched.

For example, if a rule called Test2 should execute only if a rule called Test1 was matched successfully, complete follow the following steps:

  1. Log in to the LoadMaster WUI.
  2. In the main menu, select Rules & Checking and Content Rules.

Figure 3‑9: Content Rules

  1. Click Modify on the Test1 rule.

Figure 3‑10: Modify Rule

  1. Select Flag 1 from the Set Flag If Matched drop-down list.
  2. Click Modify Rule.
  3. Click Modify on the Test2 rule.

Figure 3‑11: Modify Rule

  1. Select Flag 1 from the Perform If Flag Set drop-down list.
  2. Click Modify Rule.

When the Test1 rule is successfully matched, a flag (Flag 1) is set. The Test2 rule will not execute unless Flag 1 is set. So, Test2 cannot run unless Test1 has been successfully matched.

If a flag is set during the matching of a request, this flag can be queried when processing response header modifications, i.e. if the request sets a given flag, when the server responds; any response rules that are dependent on the flag will only execute if it is set.

Up to nine rule dependencies can be set up (as there are nine flags available to set) which can create a chain of dependent rules.

3.3.2Add Header

This command adds a static header to the request. This can be used on the client header going to the server, or on the server header going to the client.

Figure 3‑12: Add Header options

 

Rule Name

Used for identification, should be named to help remember what the rule does in the VS.

 

Header Field to be Added

The name of the field inserted in the header.

Do not add the trailing colon.

 

Value of Header Field to be added

This is the value that will be associated with the inserted header.

 

Perform if Flag is Set

Only execute this rule if the specified flag is set.

The flag will have been set by a different rule.

3.3.3Delete Header

This option removes a header from the request. This can be used on the client header going to the server, or on the server header going to the client.

The delete header option uses a Regex over the whole header and value of the header. The header will only be deleted if it all matches.

For example, if the header is:

MyHeader: This is good

If /MyHeader.*This/ is matched, the field will be deleted.

If the header is:

MyHeader: bad news

It will not match so it will not be deleted.

Figure 3‑13: Delete Header options

Rule Name

Used for identification, should be named to help remember what the rule does in the Virtual Service.

Header Field to be Deleted

The LoadMaster will remove this field by this name from the request/response.

Do not add the trailing colon.

Perform if Flag is Set

Only execute this rule if the specified flag is set.

The flag will have been set by a different rule.

3.3.4Replace Header

Matches a header based on its value, and replaces its value with the one specified. This can be used on the client header going to the server, or on the server header going to the client.

Figure 3‑14: Replace Header options

Rule Name

Used for identification – the name should help to remind what the purpose of the rule is.

Header Field

This is the name of the field that the substitution will be performed on.

Do not add the trailing colon.

 

Match String

Enter a pattern here to match against the content of this header. If the content matches the pattern, the header value will be replaced. This follows regular expression rules.

 

Value of Header Field to be replaced

When the rule is matched, the value of the header will be replaced with this text. Regular expressions and back references can be used here to reuse part of the existing value.

\1 and \2 can be used as back reference marks in PCRE expressions. For example, if the expression is /Fred (w.*s) here/ is replaced by /Mike is \1 and \1 as well/ will result in the following:

Input: Fred wears here

Output: Mike is wears and wears as well

 

Perform if Flag is Set

Only execute this rule if the specified flag is set.

The flag will have been set by a different rule.

3.3.5Modify URL

A specialized header replacement that only matches the URL in the HTTP headers and replaces it with the one specified. This can be used on the client header going to the server.

Figure 3‑15: Modify URL options

Rule Name

Used for identification – the name should help to remind what the rule does in the Virtual Service.

Match String

Enter a pattern here to match against the URL. If the URL matches the pattern, the URL value will be replaced. This follows regular expression rules.

 

Modified URL

Enter the new URL to be sent to the server. Regular expressions and back references can be used here to reuse part of the existing value.

 

Perform if Flag is Set

Only execute this rule if the specified flag is set.

The flag will have been set by a different rule.

3.4Content Matching Rules

Content Matching rules are also known as selection rules. These rules allow you to match all or some of a Header Field or URL string and then set flags if there is a match.

3.4.1Adding Content Matching Rules

To add a content matching rule, follow the steps below:

  1. Log in to the relevant LoadMaster WUI.
  2. In the menu on the left, select Rules & Checking and Content Rules.

Figure 3‑16: Content Matching Rules

  1. Click the Create New… button.

Figure 3‑17: Create Rule

  1. Enter a recognizable Rule Name.
  2. Ensure Content Matching is selected as the Rule Type.
  3. Select which Match Type to use.

For more information on the Match Type options, or any of the fields on this form, refer to Section 3.3.1.

  1. Enter the relevant Header Field. Or enter body to match on the body of a request.
  2. Enter the Match String.
  3. Enable/disable any of the check boxes as required.
  4. Select any flags as needed in the Perform If Flag Set and Set Flag If Matched lists.
  5. Click Create Rule.

3.4.2Associating Content Matching Rules to a Virtual Service

Once a rule has been created, it can be associated to a Virtual Service. To do this, follow the steps below:

  1. In the main menu of the LoadMaster WUI, select Virtual Services and View/Modify Virtual Services.

Figure 3‑18: Virtual Services

  1. Click Modify on the relevant Virtual Service.
  2. Expand the Advanced Properties section.

Figure 3‑19: Advanced Properties section

  1. Click the Show Selection Rules button.

If any content matching rules exist on this LoadMaster, they will be visible here.

  1. Select the relevant rule and click the Add button.

Figure 3‑20: Content Matching Rules

If there is more than one rule in a section, the priority at which a rule is applied can be adjusted using the Promote button.

3.5Header Modification

Modifying headers gives control over how HTTP functions. The LoadMaster has the ability to add, delete and replace HTTP headers, including URL modification. This is done on a per Virtual Service basis and can be used for request and/or response headers.

Header modification can be used to add identifying information to incoming requests. For example, if the LoadMaster is offloading SSL, the traffic back to the server is usually HTTP plain text. Normally, the server would not know that this had come in on SSL originally. A header such as SSL_Offload: Yes can be added, in order to help identify this traffic as SSL originating.

Another application would be to delete/modify sensitive information returning from the server, such as operating system or web server version.

3.5.1Adding Header Modification Rules

To add a header modification rule, follow the steps below:

  1. Log in to the relevant LoadMaster WUI.
  1. In the menu on the left, select Rules & Checking and Content Rules.
  2. Click the Create New… button.

Figure 3‑21: Create Rule

From here a number of rule types can be added. The Add Header, Delete Header, Replace Header and Modify URL Rule Type options all modify the HTTP stream in some way. For information about what each of the fields mean, refer to Section 3.3. For Replace Header and Modify URL rules, shell syntax or PCRE style regular expressions can be used. For information on regular expressions, refer to Section 4.

3.5.2Associating Header Rules to a Virtual Service

Once a rule has been created, it can be associated to a Virtual Service. To do this, follow the steps below:

  1. Log in to the relevant LoadMaster WUI.
  1. In the main menu, select Virtual Services and View/Modify Virtual Services.

Figure 3‑22: Virtual Services

  1. Click Modify on the relevant Virtual Service.
  2. Expand the Advanced Properties section.

Figure 3‑23: Advanced Properties section

  1. Click the Show Header Rules button.

Figure 3‑24: Modification Rules

If any header modification rules exist for this LoadMaster, they will be visible here.

Here, either Request Rules or Response Rules can be added.

Request Rules: These are modifications to the client headers going to the server.

Response Rules: These are modifications to the server headers going back to the client.

  1. Select the relevant rule in the relevant section and click the Add button.

Figure 3‑25: Response Rules

7. If there is more than one rule in a section the priority at which a rule is applied can be adjusted using the Promote button.

4Perl Compatible Regular Expressions (PCRE)

PCRE implements regular expression pattern matching. It uses the same syntax and semantics as Perl 5. For further information regarding PCRE, please refer to www.PCRE.org

When using special characters in PCRE it is best practice to use the character’s ASCII or HTML equivalent rather than the actual character. For example, to match the percentage symbol, instead of writing /%/, for the HTML version, use /&#37/ and for the ASCII version use /\x25/.

To ensure that an expression is treated as a PCRE, the expression must be enclosed by the forward-slash character (/ ) or it will be treated as a Shell Regular Expression. For example, a PCRE expression would look like this: /^[Tt]est$/.

Character

Meaning

.

Matches any character but a line-break

\d

Matches any numeric digit

\c

Matches any alpha character

[]

Match a set of characters

?

Optionally matches the previous expression

*

Matches the previous expresssion zero or more times

+

Matches the previous expression one or more times

{x}

Matches the previous expression x times

{x, y}

Matches the previous expression x to y times

^

Matches the beginning of the string/line

$

Matches the end of the string/line

(x)

Allows grouping of expressions

a|b

Alternative expressions, matches a OR b

 

4.1PCRE Examples

Some PCRE examples are below:

  • ^/$ matches / and / only
  • ^.*test.*$ matches the whole line of any line where test is mentioned
  • [A-F0-9]{8} matches a string of 8 hex characters
  • Gr[ae]y matches both spellings of gray/grey
  • (^|www.)example\.com matches www.example.com and example.com
  • [www]?\.example\.com matches www.example.com and example.com
  • ^[^~].*$ match any line that does not start with ~
  • \s\s+ match multiple consecutive line breaks

5Shell Regular Expressions

Regular expressions can be used to craft complex matching and replacing rules. The Match String can be a Shell Regular Expression, which is a type of statement that matches or excludes based on the strings. An asterisk (*) in a Shell Regular Expression means “match all”.

A Shell Regular Expression is a sequence of characters. Any character, which is not a special character, will match itself. The following special characters are defined.

Character

Meaning

^

This can only be placed at the start of the string and means that the string must match at the start of the URL

$

This can only be placed at the end of the string and means that the string must match at the end of the URL

?

This matches any single character

*

This matches zero or more characters

[

This starts the set notation. This matches a single character which is contained within a set. If the set starts with ^, then this will match a single character which is not within the set

5.1Shell Regular Expression Examples

Some examples of Shell Regular Expressions are below:

  • [0-9] will match any single digit
  • [^abf] will match any character, which is not “a”, “b” or “f”
  • ^/[^a-z] will match any first character in the URL which is not a small letter
  • home/*.gif will match any URL which points to a .gif file in the /home directory
  • [gG][iI][fF] will match any URL which contains the string “gif”, “GIF”, “gIF”, “giF”, “GiF” and so on.

Given an input URL such as /home/cgi-bin/XXX.cmd?value=hello, the end of the string used in matching is terminated by the ? character, i.e. a postfix string of cmd will match this URL, while a postfix of hello will not. To include the end of the string, enable the Include Query in URL option.

6Content Rules Cookbook

Some example rules that could be used in real life scenarios are below. For further information on content rules, and to see further examples, please refer to http://kemptechnologies.com/load-balancing-support/kemp-support.

The examples provided here are for guidance purposes only. They may not work in all configurations.

6.1Alter the Host Header

Many times it is advantageous to have users refer to a web resource by a local hostname, rather than by the Fully Qualified Domain Name (FQDN). This can lead to server complexity if the server expects only the FQDN. This can be avoided by rewriting the host header at the LoadMaster.

Solution

Utilizing the "Rewrite_FQDN" rule below, requests will automatically have the full FQDN appended to the header so that server resources will see the full hostname.

Rule Name: Rewrite_FQDN

Rule Type: Replace Header

Header Field: Host

Match String: /(.*)/

Replacement String: \1.domain.com

Other Uses: This type of rule can be altered to perform full replacements of the hostname or more complex replacement patterns using PCRE style regular expressions.

6.2Naked Domain Redirect

There may be scenarios when a www prefix needs to get added to the original request, for example if the original request is mydomain.com, the redirect is to www.mydomain.com

Solution

Utilizing the “Naked_Domain_Redirect” rule below, requests will automatically have www appended to the original request.

Rule Name: Naked_Domain_Redirect

Rule Type: Content Matching

Match Type: Regular Expression

Header Field: Host

Match string: /^www\..*/

Negation: Selected

Fail On Match: Selected

6.3HTTP Redirect

There may be a need to redirect URLs, for example there is a URL called xyz.example.com and there is a new site that users should be directed to with the URL example.com/en/xyz.

Solution

To do this, two rules are needed. One to handle the host header rewrite, and the other to handle the URL rewrite.

Rule Name: Host_Rewrite

Rule Type: Replace Header

Header Field: Host

Match String: /^xyz.example.com$/

Replace String: example.com

Set Flag if Matched: Flag 1

 

Rule Name: URL_Rewrite

Rule Type: Content Matching

Match Type: Regular Expression

Match String: /^\/$/

Replace String: /en/xyz

Perform If Flag Set: Flag 1

Conditional content rules only work in LoadMaster version 6.0-44 or later.

6.4Change a URL

In some cases, there may be a need to change a URL, depending what the original URL is, using a header modification rule. For example, changing mywebsite:81 to mynewebsite but then, if the URL is mywebsite:81/project change it to ourprojects.

Solution

Several rules are needed to achieve this kind of modification.

 

Rule Name: mywebsite

Rule Type: Replace Header

Header Field: Host

Match String: mywebsite

Replace String: mynewwebsite

Set Flag if Matched: Flag 1

 

Rule Name: project

Rule Type: Modify URL

Match String: /^/project$/

Modified URL: /

Perform If Flag Set: Flag 1

 

Rule Name: ourprojects

Rule Type: Replace Header

Header Field: Host

Match String: /.*/

Replace String: ourprojects

Perform If Flag Set: Flag 2

6.5URL Rewrite Based on Source IP

In some cases, it may be required to rewrite a rule based on a source IP subnet. For example, if there are two different websites (A and B) on one webserver and depending on the source subnet the user should be redirected to either website A or B. The user is using the same external URL, for example aaa.bbb.com, but will get a different website based on the source IP.

Solution

This can be done one of two ways, but either will start the same. First, set up a conditional rule using the following parameters:

Rule Name: Subnet_A

Rule Type: Content Matching

Match Type: Regular Expression

Header Field: src-ip

Match String: /^10\.0\..*/

Set Flag If Matched: Flag 1

The subnet that needs to be rewritten should be entered in the Match String. It must be done as a “classful” address as the LoadMaster is using a pseudo-header “src-ip” to do a text match against the source IP of the request. That means that something like 192.168.0/17 cannot be used – instead, use something like /192\.168\.10\..*/ to match an entire Class A, B or C subnet.

Flag 1 is set if the above rule is matched. This can invoke another rule when matched. The rewrite can be done in two ways. Both are below.

Rule Name: Rewrite_Host

Rule Type: Replace Header

Header Field: Host

Match String: /.*/

Replace String: new.host.com

Perform If Flag Set: Flag 1

OR

Rule Name: Rewrite_URL

Rule Type: Modify URL

Match String: /.*/

Replace String: /new\0

Perform If Flag Set: Flag 1

 

Either of the two rewrite rules above can be used to either change the host header or the URL depending on how it needs to be changed on the server. KEMP recommends using the hostname option as it usually results in fewer issues.

Once the two rules have been created, navigate to the Virtual Service modify screen. In the Advanced Properties section, click Show Selection Rules and apply the Subnet_A rule. Then, click Show Header Rules and apply the rewrite rule. Now, the rewrite should be applied only to requests from the designated subnet.

6.6Add the SSL Secure Flag and HTTPonly Flag to Cookies from the Real Server

To add flags to a cookie being generated by the Real Server, the content switching engine must be used.

Rule Name: SetSecure

Rule Type: Replace Header

Header Field: set-cookie

Match String: /(.*?);?$/

Replace String: \1; secure; httponly

Perform If Flag Set: [Unset]

6.7Content Matching Rule Example

Figure 6‑1: Example Architecture

The diagram above shows an example architecture that can be achieved via the use of content matching rules and SubVSs. Details are in the section below.

6.7.1Content Matching Rules

First, the rules need to be added. Then, the Virtual Service and SubVSs can be created. Settings for the rules are below.

Rule Name

Rule Type

Match String

Header Field

Modified URL

Value of Header Field to be replaced

jdedv_content

Content Matching

jdedv

Host

N/A

N/A

jdeit_content

Content Matching

jdeit

Host

N/A

N/A

jdeps_content

Content Matching

jdeps

Host

N/A

N/A

jdest_content

Content Matching

Jdest

Host

N/A

N/A

jde_modify_url

Modify URL

/^\/$/

N/A

/jde/E1Menu.maf

N/A

jdedv_replace

Replace Header

/^.*$/

Host

N/A

10.11.0.194:9004

jdedv_replace_2

Replace Header

/^.*$/

Host

N/A

10.11.0.195:9004

jdeit_replace

Replace Header

/^.*$/

Host

N/A

10.11.0.194:9002

jdeit_replace_2

Replace Header

/^.*$/

Host

N/A

10.11.0.195:9002

jdeps_replace

Replace Header

/^.*$/

Host

N/A

10.11.0.194:9001

jdeps_replace_2

Replace Header

/^.*$/

Host

N/A

10.11.0.195:9001

jdest_replace

Replace Header

/^.*$/

Host

N/A

10.11.0.194:9003

Jdest_replace_2

Replace Header

/^.*$/

Host

N/A

10.11.0.195:9003

             

6.7.2Virtual Services

To add the parent Virtual Service, follow the steps below in the LoadMaster WUI:

  1. In the main menu, select Virtual Services.
  2. Select Add New.

Figure 6‑2: Virtual Service parameters

  1. Enter a valid IP address.
  2. Enter 80 as the Port.
  3. Enter a recognizable Service Name.
  4. Click Add this Virtual Service.

Figure 6‑3: Standard Options section

  1. Select Super HTTP as the Persistence Mode.
  2. Expand the Advanced Properties section.

Figure 6‑4: Advanced Properties section

  1. Select X-Forwarded-For in the Add HTTP Headers drop-down list.
  2. Expand the Real Servers section.

Figure 6‑5: Real Servers section

  1. Click Add SubVS.
  2. Click OK.

Figure 6‑6: SubVS section

  1. Click Modify.

Figure 6‑7: Basic Properties

  1. Enter jdedv_1 as the SubVS Name.
  2. Expand the Standard Options section.

Figure 6‑8: Standard Options

  1. Remove the tick from the Transparency check box.

Figure 6‑9: Advanced Properties section

  1. Click Show Header Rules.

Figure 6‑10: Request Rules

  1. In the Request Rules section, select Modify URL: jde_modify_url and click Add.

Figure 6‑11: Replace Header rule

  1. In the Request Rules section, select Replace Header: jdedv_replace and click Add.
  2. Expand the Real Servers section.

Figure 6‑12: Real Servers section

  1. Click Add New.

Figure 6‑13: Real Server parameters

  1. Enter the relevant address in the Real Server Address text box.
  2. Enter 9004 as the Port.
  3. Click Add This Real Server.

The steps from 11 to 24 above describe how to add one SubVS. In this example, 8 SubVSs are needed. To add the rest of the SubVSs, follow the steps above but use the settings outlined in the table below:

SubVS Name

 

Transparency

Request Rules

Checked Port

Real Server Port

jdedv_1 (steps above)

 

Disabled

jde_modify_url

jdedv_replace

9004

9004

jdeps_1

 

Disabled

jdeps_replace

jde_modify_url

9001

9001

jdedv_2

 

Disabled

jde_modify_url

jdedv_replace_2

9004

9004

jdeps_2

 

Disabled

jde_modify_url

jdeps_replace_2

9001

9001

jdeit_1

 

Disabled

jde_modify_url

jdeit_replace

9002

9002

jdest_1

 

Disabled

jde_modify_url

jdest_replace

9003

9003

jdeit_2

 

Disabled

jde_modify_url

jdeit_replace_2

9002

9002

jdest_2

 

Disabled

jde_modify_url

jdest_replace_2

9003

9003

             

7References

Unless otherwise specified, the following documents can be found at http://kemptechnologies.com/documentation.

WUI, Configuration Guide

KEMP LoadMaster, Product Overview

Virtual Services and Templates, Feature Description

Document History

Date

Change

Reason for Change

Ver.

Resp.

Sep 2015

Release updates

Updated for 7.1-30 release

3.0

LB

Oct 2015

Release updates

Updated screenshots

4.0

LB

Jan 2016

Minor changes

Updated

5.0

LB

Mar 2016

Release updates

Updated for 7.1-34 release

6.0

LB

Apr 2016

Minor updates

Enhancement made

7.0

LB

Was this article helpful?

1 out of 1 found this helpful

Comments

Powered by Zendesk