radware linkproof user guide 200-101_lp_level1-v9

North America Radware Inc. 575 Corporate Dr. Suite 205 Mahwah, NJ 07430 Tel 888 234 5763

International Radware Ltd. 22 Raoul Wallenberg St. Tel Aviv 69710, Israel Tel 972 3 766 8655

www.radware.com

C o u rs e Co d e: 200 -1 01

L in kP ro o f L evel 1

T r ai n in g M anu al October 2010

- 2 -

Radware 2010. All rights reserved. Distribution of this document needs approval from Radware Knowledge & Education Services.

LinkProof Training Manual Level 1 Date: October 2010 Page - 2 -

This document is protected by United States and International copyright laws. Neither this document nor any material contained within it may be duplicated, copied or reproduced, in whole or part, without the expressed written consent of Radware, Inc.

The features and functions of Radware devices discussed in this document are based on the following firmware version.

Product Version

LinkProof 6.12.xx (ODS hardware)

If your Radware device is running an older version of firmware some of the features and implementations discussed in this manual may not be available.

To upgrade your existing Radware device, please contact your Radware sales person.

Conventions

The following font conventions are used in this manual:

Bold indicates the series of menu items in Web Based Management used to reach a particular screen or window

Underline

Italics indicates the value or setting supplied in a window or screen

indicates an option or entry within Web Based Management screen or window

Courier indicates CLI or telnet commands

- 3 -



Table of Contents LINKPROOF LAB CONFIGURATION ............................................................................................................ 5

CHAPTER 1 LINKPROOF OVERVIEW ........................................................................................................ 7

INITIAL CONFIGURATION FOR LINKPROOF ................................................................................................ 9 LINKPROOF LAB 1 - LINKPROOF INITIAL CONFIGURATION ..........................................................................10 CHAPTER 1 REVIEW: ..............................................................................................................................18

CHAPTER 2 BASIC FARM CONFIGURATION FOR THE LINKPROOF ....................................................19

LINKPROOF LAB 2 CREATING A FARM AND ROUTER SERVERS (USING CLI) ...............................25 LINKPROOF CHAPTER 2 REVIEW .............................................................................................................31

CHAPTER 3 DEVICE MANAGEMENT FOR LINKPROOF .........................................................................32

SERVER PRIORITY ..................................................................................................................................32 RECOVERY TIME ...................................................................................................................................32 WARM UP TIME ....................................................................................................................................32 CONNECTION LIMITS .............................................................................................................................32 TRAFFIC LIMITS .....................................................................................................................................33 NHR OPERATIONAL MODE ....................................................................................................................33 CLIENT MANAGEMENT ..........................................................................................................................33 CLIENT AGING TIME AND AGING BY PORT .................................................................................................34 HEALTH CHECKING AND FULL PATH HEALTH MONITORING .......................................................................34 LINKPROOF LAB 3A ROUTER MANAGEMENT FOR LINKPROOF (USING CLI) ..............................................37 LINKPROOF LAB 3B CONNECTIVITY CHECKS AND HEALTH MONITORING (USING CLI) ................................40 CONNECTIVITY CHECKS LAB: ............................................................................................................40 HEALTH MONITORING LAB ................................................................................................................41 CHAPTER 3 REVIEW: ..............................................................................................................................46

CHAPTER 4 FLOW POLICIES ..............................................................................................................47

FLOW POLICIES ...................................................................................................................................47 LINKPROOF LAB 4 FLOW POLICIES (USING CLI) .....................................................................................52

LINKPROOF PRACTICAL EXERCISE #1 ......................................................................................................59

CHAPTER 5 LINKPROOF INBOUND LOAD-BALANCING .......................................................................60

PROXIMITY SETTINGS ............................................................................................................................61 SELECTIVE PROXIMITY CHECKS ...............................................................................................................64 LINKPROOF LAB 5 INBOUND LOAD BALANCING AND PROXIMITY (USING CLI) ...........................................67 CHAPTER 5 REVIEW: ...........................................................................................................................71

CHAPTER 6 LINKPROOF REDUNDANCY ...........................................................................................73

VRRP REDUNDANCY .........................................................................................................................73 CONFIGURATION .................................................................................................................................73 TABLE MIRRORING .............................................................................................................................74

LINKPROOF LAB 6 VRRP REDUNDANCY (USING CLI) ...............................................................75

- 4 -



CHAPTER 7 ONE IP CONFIGURATION .......................................................................................................81

LINKPROOF LAB 7 ONE IP CONFIGURATION (USING CLI) ........................................................................82

LINKPROOF MANAGEMENT .......................................................................................................................84

LINKPROOF LAB 8 MANAGING THE LINKPROOF (USING CLI) ...........................................................................84

BANDWIDTH MANAGEMENT ................................................................................................................92

LINKPROOF LAB 9 BANDWIDTH MANAGEMENT ON THE LINKPROOF (USING CLI) 94

LAB A BANDWIDTH MANAGEMENT SETUP ....................................................................................94 LAB B CREATING A SIMPLE BLOCK POLICY IN BWM ....................................................................97 LAB C CREATING A SIMPLE MINIMUM AND MAXIMUM POLICY ......................................................99

WEB BASED MANAGEMENT LAB STEPS .................................................................................................102

WBM CHAPTER 2 FARM CONFIGURATION FOR THE LINKPROOF ....................................................102

LINKPROOF LAB 2 CREATING A FARM AND ADDING NHRS (USING WBM) ..............................................102 LINKPROOF CHAPTER 2 REVIEW ...........................................................................................................108

CHAPTER 3 DEVICE MANAGEMENT FOR LINKPROOF .......................................................................109

LINKPROOF LAB 3A DEVICE MANAGEMENT FOR LINKPROOF (USING WBM) ..........................................109 LINKPROOF LAB 3B CONNECTIVITY CHECKS AND HEALTH MONITORING (USING WBM) .............112 CHAPTER 3 REVIEW: ............................................................................................................................119

CHAPTER 4 FLOW POLICIES ............................................................................................................121

LINKPROOF LAB 4 FLOW POLICIES (USING WBM) ...............................................................................121

LINKPROOF PRACTICAL EXERCISE #1 (OPTIONAL) ..............................................................................129

CHAPTER 5 LINKPROOF INBOUND LOAD-BALANCING .....................................................................130

LINKPROOF LAB 5 INBOUND LOAD BALANCING AND PROXIMITY (USING WBM) .....................................130 CHAPTER 5 REVIEW: ............................................................................................................................135

CHAPTER 6 LINKPROOF REDUNDANCY .................................................................................................136

LINKPROOF LAB 6 VRRP REDUNDANCY .............................................................................................136

CHAPTER 7 ONE IP CONFIGURATION .....................................................................................................143

LINKPROOF LAB 7 ONE IP CONFIGURATION (USING WBM) ..................................................................143

LINKPROOF MANAGEMENT .....................................................................................................................147

LINKPROOF LAB 8 MANAGING THE LINKPROOF (USING WBM) .....................................................................147

BANDWIDTH MANAGEMENT ...................................................................................................................160

LINKPROOF LAB 9 BANDWIDTH MANAGEMENT (USING WBM) ......................................................................160LAB B CREATING A SIMPLE BLOCK POLICY IN BWM ...................................................................................165LAB C CREATING A SIMPLE MINIMUM AND MAXIMUM POLICY .......................................................................166

- 5 -



LinkProof Lab Configuration During the training, students are divided into two teams (Alpha, Beta, Gamma and Delta) and each team will configure and manage a single Radware device. The steps and diagrams within the training material are based on this type of lab setup.

You and your fellow students will be working with a single LinkProof. Since there are four devices in this lab setup, take care to follow the instructions in the manual for the device you are working with.

In some situations, your instructor may have to deviate from the standard configuration to accommodate more students or to account for less available time.

The labs in this manual are designed to demonstrate the more commonly-used features and functions on the LinkProof. There are a great number of features on this device, and it would be impossible to provide labs for all of them without increasing the training period to several weeks.

Even so, the manuals do contain more labs than can be covered in the time available. Some of these labs are labeled optional and your instructor may likely choose to skip them.

Each lab contains step-by-step instructions on how to configure the device correctly using APSolute. These steps are illustrative only and are usually based only on the configuration of one device in the training lab.

Pay close attention to the tables and charts within the lab instructions. You will be expected to apply the appropriate settings for your device only. It will make for a particularly long day for you (and your instructor) if several students mistakenly use addresses and settings that belong to other students.

If you have any questions about how to configure your Radware device during a particular lab, please ask your instructor for assistance.

Listed below are the diagrams and details for each set of equipment:

- 6 -



Figure 1 Sample LinkProof Configuration

- 7 -



Chapter 1 LinkProof Overview Radwares LinkProof is designed to provide load balancing and fault tolerance for multiple network connections. Because it is an extension of the FireProof, the LinkProof can also load balance both transparent and non-transparent firewalls as well; however, it is optimized to work with multiple links.

The introduction of a LinkProof into a network can significantly reduce some of the common headaches associated with having only a single connection to the Internet (and thus a single point of failure). The LinkProof allows administrators to utilize multiple Internet connections at the same time, thus improving network throughput, instead of relying on an active / backup solution or segregating internal segments pointed to different gateways. Should a single Internet connection fail, the LinkProof will mark it inactive and continue to send traffic through the functioning link(s).

The LinkProof also maintains state between clients and the Internet connection to which they have been directed so that all traffic from a single client through a particular next-hop-router will continue through that device for the duration of the sessions.

LinkProof can load balance at layers 2 7, depending on administrators needs. For transparent routers, the LinkProof redirects clients requests to the MAC address of the device. When necessary, the LinkProof can also load balance clients requests based on changes in source port, effectively scattering individual client traffic across an array of next-hop-routers.

Dynamic Smart NAT allows the LinkProof to dynamically NAT client requests out two or more next hop routers, using an appropriate address from each routers network. Static Smart NAT allows the LinkProof to translate an internal hosts requests out one or more next-hop-routers using a single, static address on each routers network.

For load balancing inbound requests to internal hosts, the LinkProof can be configured to act as a DNS Name Server, answering incoming queries for resolution through the links it is connected to. Thus, if a LinkProof has 3 Internet connections, it can respond to DNS queries for an internal host with an address on any of the three Internet connections. This insures that DNS queries are answered with addresses on routes that are available at the time of the request.

- 8 -



Additionally, the LinkProof provides a Proximity feature that allows it to reply with resolved addresses that are better for a particular querying DNS server. The LinkProof will determine distance and latency to a specific querying DNS server through each of the links it is load balancing. It then builds a reference table so that future requests from the same DNS server (or servers on the same 24-bit network) can be given A Records that are closer or faster for their location.

The LinkProof uses several different methods to calculate Proximity, including traffic on UDP and TCP ports, as well as ping. It counts actual router hops (not Autonomous System hops like BGP) and real-time latency. Administrators can change the relative importance of Latency, Hop Count as well as network load for the LinkProofs calculations.

- 9 -



Initial Configuration for LinkProof Initial configuration of the LinkProof must be done through the serial port using the provided cable and a terminal emulation program such as Microsoft's HyperTerminal. Once the initial settings are applied, almost all configuration changes can be done through web based management, although most settings can also be accomplished through the command line interface (CLI).

There are three basic settings that have to be configured through the Command Line Interface (CLI):

IP Address Subnet Mask Interface Number Once these initial settings have been completed, the unit will restart and generate a number of boot messages.

The command line interface (CLI) provides access to all device settings and features:

bwm Policy management and classification classes Configures traffic attributes used for classification device Device Settings fp FireProof parameters health-monitoring Advanced Health Monitoring help Displays help for the specified command login Login into the device logout Logout of the device manage Device management configuration net Network configuration ping Sends echo requests reboot Reboot the device redundancy Redundancy settings security Security settings services General netwroking services statistics Device statistics configuration system System parameters LinkProof#

- 10 -



LinkProof Lab 1 - LinkProof initial configuration Lab Goals:

Using the serial cable provided, connect to the LinkProof using HyperTerminal (or similar application)

Apply the required minimum settings through the Startup Menu to allow connectivity

Configure and test Telnet access Configure and test Web Based Management Add Default Gateways Review the various options and settings available through the initial command

line menu Enable global options

Note: If you do not intervene at the Startup Menu within 30 seconds the LinkProof will set initial values. You can simply hit enter when the Startup Menu appears and the device will not apply a default configuration.

The default configuration will apply the following:

Interface 1 = 192.168.1.1 mask 255.255.255.0

Username and Password = radware

All Management enabled

Step-by-step:

1) Please go to page 183 and remove the topology, fill in the blanks with your team information as assigned by the instructor.

2) Make sure you have serial connectivity to the LinkProof your class might provide a

terminal access server instead of direct connections to the serial port if your class has a terminal server use step 3.

3) Use Putty or HyperTerminal to create a connection and set the values based on the presentation (Summary follows):

- 11 -



Baud Rate = 19200 Flow Control = None Make sure the right Com port is selected

4) If you have a terminal server telnet to the IP and port a) IP = 192.168.150.252 b) Port = 700#

5) Hit the return key a few times you should have a LinkProof> prompt. 6) Follow the instructions below to rest the device:

a) Press the enter key a few times and make sure you get a linkproof> prompt. b) Type login and use the default user name and password of radware

c) From the # prompt type reboot and hit enter.

d) When the device begins to boot up, you will see a message that says Press any

key to pause autoboot

Press any key on the keyboard (you have 4 seconds to do this)

e) From the > prompt type q1 and press enter f) On ODS hardware you have to confirm the configuration file erase type y

g) When the erase configuration completes and the > comes back, type @ and

press enter.

h) The device will be reset to factory defaults and you will be asked if you want to use the new CLI configuration wizard. Please make sure to say n Would you like to use new CLI configuration wizard (y/n) [y]: Type n since we want to configure the device step by step.

i) The Startup Configuration screen(see below) will come up, you have 60 seconds to enter values in the startup, otherwise it will default to 192.168.1.1 (See Next page step 7 for values or refer to your topology)

- 12 -



Startup Configuration 0. IP address 1. IP subnet mask 2. Port number 3. Default router IP address 4. RIP version (0,1,2) [0] 5. Enable OSPF (y/n) [n] 6. OSPF aread ID 7. User Name 8. User Password 9. Enable Web Access (y/n) [n] 10. Enable Secure Web Access (y/n) [n] 11. Enable Telnet Access (y/n) [n] 12. Enable SSH Access (y/n) [n] 13. SNMP Configuration 7) Assign the values based on your teams topology for the management port (MNGT-1

or Port 16) of 10.10.243.# where # is your team number.

a) 0. IP address

b)

= 10.10.243.#

1. IP subnet mask

c)

= 255.255.248.0

2. Port Number

d) Hit for ALL the other values to set them to default.

= MNG-1

Note: For those items on the list that are not applicable for this initial startup phase, you can hit the key and allow the menu to apply default settings to them.

8) When you have entered the appropriate information for this section of the Startup Menu, you will see another sub-menu for SNMP Configuration. Simply hit to accept all default values:

- 13 -



9) When you have filled in this menu, you will be returned to the previous one. If the

configuration is correct, confirm the reboot process and allow the device to restart. 10) Once the device has finished restarting, you will have to log in to the unit by typing

login. The default username and password for CLI access to the LinkProof is radware (without the quotes). When you have logged in, use the question mark (?) to display the commands.

You should see a list of commands similar to the one below:

11) Create two new IP addresses for interface 1. Use the following command and

substitute your teams appropriate values: 1.1.1.# and 2.2.2.# (where # is your team number). Multiple IP address can be added to a single interface.

All network masks are Class C 24 bit (255.255.255.0)

net ip-interface create 1 (you will use this command twice (for the 1.1.1.# address and the 2.2.2.# address)

Team Device Interface Number 1 Address

1 LinkProof 1 1.1.1.1 and 2.2.2.1

- 14 -



2 LinkProof 2 1.1.1.2 and 2.2.2.2

3 LinkProof 3 1.1.1.3 and 2.2.2.3

4 LinkProof 4 1.1.1.4 and 2.2.2.4

12) Create a new IP address for interface 2. Use the following command and substitute your teams appropriate values :

net ip-interface create 2

Team Device Interface Number 2 Address

1 LinkProof 1 192.168.200.1

2 LinkProof 2 192.168.200.2

3 LinkProof 3 192.168.200.3

4 LinkProof 4 192.168.200.4

When you are finished, use the command net ip-interface to make sure the unit shows the appropriate interface addresses.

Your device should look similar to the below (with your IP instead).

Team 1 LinkProof

IP Address Network Mask If Number VlanTag

1.1.1.1 255.255.255.0 1 0

2.2.2.1 255.255.255.0 1 0

192.168.200.1 255.255.255.0 2 0

10.10.243.1 255.255.248.0 MNG-1 0

Team 11 LinkProof

IP Address Network Mask If Number VlanTag

1.1.1.11 255.255.255.0 1 0

- 15 -



2.2.2.11 255.255.255.0 1 0

192.168.200.11 255.255.255.0 2 0

10.10.243.11 255.255.255.0 MNG-1 0

13) From the command line, ping various hosts on either side of the device to make sure you have basic network connectivity. Ping the LinkProof from your Management Station, and from the LinkProof ping the two routers it will be load-balancing.

Take a look at some of the CLI commands available. Feel free to ask your instructor questions about these functions.

14) Enable Telnet access on the device. From the CLI, enter the following command: manage telnet status set 1

15) Create a username and password so that you can access the device through Telnet or you can use the default username and password of radware: manage user table create team1 -pw team1 Use your teams name for the username and password (team1, team2, team3, etc.).

16) Open a Telnet session to your device and supply the appropriate username and password. Hit any key (except or ) and then hit the key. You should see a list of commands identical to those displayed through the CLI.

17) Enable Web Based Management. From the CLI or from your Telnet connection, enter the following command: manage web status set 1

18) You can now open a browser from your workstation and enter the ip address of your LinkProof. You should be prompted for a username and password. Use the username and password that you created in step 14.

- 16 -



19) Enter the following command on the LinkProof in order see traps not only through a serial connection to the unit, but also when you have a telnet or SSH connection.

manage terminal traps-output set 2

20) Configure the LinkProof with a DNS server to use for lookups:1

services dns client primary-server set 4.2.2.2

Note: As a general rule, you will find it helpful to leave one of your workstations connected to the LinkProof through the CLI for the duration of the labs. There are a number of traps and error messages that the device will generate through the CLI and these can useful for trouble-shooting.

Routing Table:

For the LinkProof to function a default gateway must be configured however, only one of the Routers needs to be a default gateway, once an Router is defined as a gateway ALL configured Router servers are gateways. A good practice is to define each Router as a default gateway in the event that the Router or the interface used is removed and the value is then deleted by accident. The routing table Can NOT be used to limit routing to one specific Router that feature will be discussed later.

21) To add a default gateway the syntax is: net route table create -i Enter the following two lines:

net route table create 0.0.0.0 0.0.0.0 1.1.1.100 i 1 net route table create 0.0.0.0 0.0.0.0 2.2.2.200 i 1

Global Settings:

The Following settings and recommended changes from the default values and should be set on all LinkProof installs. Please ask your instructor if you want more information on any of these settings, included in the training are two base CLI configurations files

1 The address you use may differ from the one listed here depending on the lab conditions.

- 17 -



that already include these commands. (Do Not reboot until you have entered all the commands)

Client Table:

To set the client table (Maximum number of concurrent sessions), if the LinkProof hits the maximum client table value no new sessions can be established through the LinkProof this value should be set high (The below value is a minimum). On ODS hardware the default value is already 250.000.

system tune client-table set 50000

Proximity Table:

To set the proximity table, used for both inbound and outbound proximity the maximum stored values (Will be discussed in more detail with lab 5)

system tune dynamic-proximity-table set 20000

NHR Tracking Table:

The NHR tracking table setting tracks all management traffic to the LinkProof and the NHRs themselves, setting it too low will generate an error message that the NHR tracking table is full, this will not affect traffic being load balanced by the LinkProof. On ODS hardware the default value is already 100,000.

system tune nhr-track-table set 2000

IP Forwarding Table:

The IP FFT is a fast forwarding table for established connections, having a larger table improves the processing performance of the CPU in larger network environments. system tune ip-fft-table set 32000

Optional Features (IPS and BWM):

- 18 -



If the Device includes the optional modules of IPS and Bandwidth Management (see system license get) they can be enabled with the following commands:

Enable Bandwidth Management bwm global classification-mode set 1

Enable Application Security (not be used later on only for your knowledge!)

LP version 6.x: security signatures-protection application-security global status set 1 At this Point you must Reboot

the device for the changes to take effect.

Chapter 1 Review:

Which type of Smart NAT (Dynamic or Static) could be described as a many-to-one network address translation process?

Which type of Smart NAT (Dynamic or Static) could be described as a one-to-one network address translation process?

On what system does the LinkProof rely in order to route external clients into a multi-homed network through many internet connections?

What is the default username and password for CLI access to a LinkProof?

Can you have more then one IP on a single physical interface?

What values are assigned to the default configuration after 30 seconds?

What does NMS stand for and what potential problems can occur if you specify an NMS address in the configuration menu?

- 19 -



Chapter 2 Basic Farm Configuration for the LinkProof The LinkProof acts as the default gateway for devices into and out of the network. Instead of sending client traffic to the interface address of a specific router, the clients gateway becomes the address of an interface on the Active LinkProof. The device makes real-time decisions about router availability as well as load and will route the clients request appropriately. The LinkProof can load balance up to 10 Next Hop Routers with proximity and up to 100 Routers without. LinkProof uses farms to interface with the Next-Hop-Routers. Essentially, a router farm is a logical collection of routing devices, grouped according to their functionality. In most cases, all routers within a given farm will be treated equally as candidates for load-balancing decisions. In other words, traffic leaving the LinkProof can be sent to any of the router servers in a specific farm. The same router server can belong to multiple farms. Farms are also dependent of Traffic Flows specific information that instructs the LinkProof which type of traffic should be redirected to the router servers within that farm. Different router farms can be based on different Traffic Flow policies to give administrators flexibility in varying circumstances. For example, administrators may wish to have Web traffic redirected out only one of their two available internet routers and all other traffic redirected out both available routers. To accomplish this, the administrator would need to create two farms one farm containing only the routing server for Web traffic and a second farm containing both router servers to be used for all other traffic. Once the farms and their appropriate router servers have been created, Flows and Flow Policies need to be configured to specifically redirect traffic to the appropriate farm and to the servers within it. This concept, known in previous versions of LinkProof code as Grouping, is essentially the same in theory but differs somewhat in the configuration details. This feature is discussed in more detail later in this manual. Dispatch Method

The LinkProof offers a variety of methods for dispatching (load balancing) traffic to routers: Cyclic (Round Robin)

- 20 -



Least Traffic (in Packets) Least Traffic local Least Number of Users Least Number of Users local Least Bytes Least Bytes local Hashing

Smart NAT

One of the fundamental functions of the LinkProof is the ability to redirect traffic to various ISP routers intelligently. The process by which this is accomplished is called Smart NAT and it may be easier to examine it in two different ways Inbound Smart NAT and Outbound Smart NAT.

Consider the following network configuration:

Figure 2 - Basic LinkProof Configuration for Outbound SmartNAT

- 21 -



The LinkProof sits between the internal network and two external ISP routers, each with a unique address space 100.100.100.0/24 for ISP A and 200.200.200.0/24 for ISP B. The default gateway for internal hosts is an interface on the LinkProof of 192.168.1.1, and the LinkProof itself has a connection to each ISP 100.100.100.2 for ISP A and 200.200.200.2 for ISP B. When an internal user initiates a session to an external host (i.e. an Internet site), the LinkProof will choose a ISP router based on the load-balancing metric in use and will then perform NAT (Network Address Translation) for the client using a pre-configured address specifically for that ISP router. In this example, the LinkProof is configured with a SmartNAT address of 100.100.100.50 to use for ISP A and a separate SmartNAT address of 200.200.200.50 to use for ISP B. The LinkProof tracks these outbound sessions internally so that when the response returns, the LinkProof can un-NAT the traffic and forward it back to the host that initiated the request. SmartNAT allows customers to connect their network to multiple ISP routers and use all of them simultaneously without complicated gateway protocols or address sharing. Adding additional Internet connections can be as simple as placing new entries in the LinkProofs Next Hop Router Table and configuring additional SmartNAT addresses. SmartNAT addresses are configured for ranges of addresses. For example, users within one range will be translated to a specific SmartNAT address when sent to a router; and users from a different range will be translated to a different SmartNAT address when sent to the same router. The LinkProof can also calculate the latency between itself and the destination hosts to which internal clients are going. This allows it to begin building a Proximity Table which the LinkProof will use to route users out the faster connection based on their destination.

Inbound Smart NAT

In addition to being able to route outbound traffic through multiple next hop routers, the LinkProof can also control how external users reach internal

- 22 -



resources through the available connections. The LinkProof utilizes DNS to accomplish this.

Consider the following network configuration

Figure 3 - Inbound Traffic Redirection

The customers internal hosts (web server, ftp server, etc.) need to be available through both ISP connections. The LinkProof can provide this service by acting as the authoritative name server for those specific hosts. When external users need to reach the customers web server (Step 1), for example, the DNS query to resolve the host name to an IP address is actually referred to the LinkProof (Step 2). This delegation is accomplished by placing NS (Name Server) records in the customers existing DNS server to refer queries to the LinkProof interfaces that reside on each ISP network.

- 23 -



The LinkProof is configured with the internal web servers host name, its corresponding internal IP address and with two public addresses that it can use to answer incoming queries a static address from ISP As network and a static address from ISP Bs network. When the query reaches the LinkProof through either network, it will respond with the address from the least loaded ISP connection (Step 3), which is passed back to the client (Step 4). The LinkProof can also be configured to respond to the query with two addresses. Should the connection to either ISP fail, incoming queries will still reach the LinkProof through the available ISP (thus the need for two NS records in the customers DNS zone file pointing to the two interfaces of the LinkProof). Additionally, the LinkProof can be configured to perform proximity calculations to determine which incoming link is better for different customers. The results of these calculations are stored in an internal table so that subsequent queries from DNS servers can be answered with an address that will be quicker to reach for the actual clients.

Smart NAT Types Newer versions of the LinkProof software provide several different types of NAT for use in different circumstances. The following explanations detail the differences. Basic Smart NAT Basic Smart NAT enables a one-to-one NAT mapping for occasional users, based on local IP ranges and destination applications. A pool of NAT addresses for each ISP is configured per range of local IP addresses and destination port. Whenever a client with an IP address within the range initiates a session to any host with the relevant application port, a NAT address is allocated to this session, and is used for all further sessions for the client with this application on this destination host.

Basic NAT is useful for any application which requires that source ports not be translated, and therefore cannot be used when the client's IP is translated using Dynamic NAT.

- 24 -



No NAT You can use No NAT to enable a simple configuration where internal hosts have IP addresses that belong to a range of one of the ISPs. Traffic from or to these hosts should not be NATed if the traffic is forwarded to the router of that ISP. If you do not configure any NAT address for a server via a firewall, that firewall will not be used by traffic from that server. In order to use a firewall for a server when NAT is not required, use the No NAT configuration.

- 25 -



LinkProof Lab 2 Creating a Farm and Router Servers (using CLI) Lab Goals:

Create the Farm and the router servers

Enable Smart NAT

Review various parameters and settings available for devices Step by Step:

Creating a basic NHR Farm:

1. The first step to working with NHRs is to create the farm use the following command to create a basic farm:

Syntax: lp farms table create -nm

-nm = NAT Mode, this Specifies whether LinkProof does network address translation on the packets.

(1) Enable

(2) Disable

-pt = Packet Translation, this setting lets the LinkProof know if a farm uses a special packet handling and has the following values:

(1) = NAT

(3) = Disable

(4) = Virtual Tunneling

(5) = VIP

For our lab use the flowing command:

lp farms table create mainfarm nm 1

2. When adding a new ISP/NHR you need some basic information before you can add it to the LinkProof.

a. The IP and Subnet of the ISP, the LinkProof must have an interface in the same subnet as the ISP (we created these interfaces in Lab 1).

- 26 -



b. The best practice is to make sure all interfaces that will be used in the configuration are up. Use the command net l2-interface to verify all interfaces have link.

3. To add the NHRs to the farms created above with default parameters type

the following command:

Syntax: lp servers router-servers create -ip Add two NHRs 1.1.1.100 and 2.2.2.200 lp servers router-servers create mainfarm ISP1 -ip 1.1.1.100 lp servers router-servers create mainfarm ISP2 -ip 2.2.2.200

4. Once you add the two ISP you should see in the CLI that they are up, the

LinkProof is by default doing an ICMP health check to verify connectivity. We will change these parameters in later labs.

25-07-2008 20:53:13 INFO Server mainfarm ISP1 up 25-07-2008 20:53:14 INFO Server mainfarm ISP2 up

At this point the LinkProof will load balance any traffic that passes through requiring routing to the default gateway. However to establish connectivity you must configure Dynamic NAT for outbound traffic (Dynamic NAT is the same as Hide NAT or PAT).

Note: Dynamic NAT is a layer 4 NAT therefore if the traffic is not TCP or UDP it will have issues with the NAT. 5. For each ISP use a single new IP address that is on the same Subnet as the

ISP for this lab we will use the following two IP address for each team (where # is the team number).

a. ISP1 = 1.1.1.10# b. ISP2 = 2.2.2.10#

Use the following command to add the NAT entries to the LP.

- 27 -



Syntax:

lp smartnat dynamic-nat create The Start IP and End IP is the range of IPs on the local network, you can not use 0.0.0.0 to say all IPs instead you need to create a range 0.0.0.1 255.255.255.254 or limit the range to just the space on your network. Dynamic NAT does not support non contiguous ranges.

For each team:

lp smartnat dynamic-nat create 0.0.0.1 255.255.255.254 1.1.1.100 1.1.1.10# lp smartnat dynamic-nat create 0.0.0.1 255.255.255.254 2.2.2.200 2.2.2.10# Some Examples Below:

Team From Local IP To Local IP Router IP Dynamic

Nat IP NAT Redundancy Mode

Team1 0.0.0.1 255.255.255.254 1.1.1.100 1.1.1.101 Regular 0.0.0.1 255.255.255.254 2.2.2.200 2.2.2.101 Regular Team2 0.0.0.1 255.255.255.254 1.1.1.100 1.1.1.102 Regular 0.0.0.1 255.255.255.254 2.2.2.200 2.2.2.102 Regular Team10 0.0.0.1 255.255.255.254 1.1.1.100 1.1.1.110 Regular 0.0.0.1 255.255.255.254 2.2.2.200 2.2.2.110 Regular Team11 0.0.0.1 255.255.255.254 1.1.1.100 1.1.1.111 Regular 0.0.0.1 255.255.255.254 2.2.2.200 2.2.2.111 Regular

When complete, to display the NAT table type:

Figure 4 Dynamic NAT Table

- 28 -



6. Make certain that your workstation gateways are set to the internal interface of the

LinkProof (192.168.200.# #=team number).

7. Open browser sessions from your remote workstation to external hosts, if available and you should be able to connect.

8. View the connection table on the LinkProof to see the active connections lp client table You should see something like the following:

Figure 5 Client Table

Changing the Dispatch Method:

9. The default dispatch method for the LinkProof is cyclic, this means that each session will be dispatched to the next router based on where the last session was sent. To test the different modes we will set the client aging time to a very low number (20 seconds) to age out from the table faster.

- 29 -



lp farms table set mainfarm -cl 20 10. Now find a simple website that opens few connections for example:

www.hithere.com, in the client table notice what NHR was selected. Wait to age out of the client table (20 seconds) and then refresh the browser you should be directed to the second ISP.

11. Change the dispatch method to Least Amount of traffic: Syntax:

lp farms table set mainfarm -dm

Allowed values for dispatch-method:

(1) Cyclic

(2) Least Amount Of Traffic

(3) Fewest Number Of Users

(8) Least Number Of Bytes

(9) Hashing

(10) Least Amount Of Local Traffic

(11) Fewest Number Of Local Users

(12) Least Number Of Local Bytes

(14) Customized Hash

(15) Multicast

(16) Source IP Hashing

(17) Layer-3 Hashing

lp farms table set mainfarm -dm 2 12. Test the new method and observe what happens in the client table.

lp client table

13. Change the Dispatch Method to Fewest Number of Users test this new method as above and observe the client table.

lp farms table set mainfarm -dm 3

- 30 -



Viewing and Saving the Configuration File:

14. At this point it will be a good idea to save the basic configuration created above. To view the configuration in CLI type in:

system config immediate

15. Although this configuration can be copied to a text file and saved, it can be hard to work with until you have more understanding of the CLI, to save the configuration from web based management:

File Configuration File Receive from Device Choose Configuration Type as Regular

End of Lab 2 Please continue with Lab 3.

- 31 -



LinkProof Chapter 2 Review How many devices (total) can the LinkProof load balance?

How Many ISPs can the LinkProof load balance (Routers with Proximity)

What load balancing methods are available on the LinkProof?

What is SmartNAT?

What types of SmartNAT are available on the LinkProof?

- 32 -



Chapter 3 Device Management for LinkProof The LinkProof has a number of features that allow administrators to control and adjust traffic to routers with minimum impact on services. Administrators can introduce routers into the load balancing cluster smoothly; a new router can be added with only few simple entries using ConfigWare or the CLI; and routers can be brought down gracefully for maintenance or upgrades with a single configuration change.

Server Priority Routers can be given varying priorities or weights. The LinkProof will redirect more traffic to those devices that are configured with a higher weight than those will a lower weight. This allows administrators to utilize a wider variety of equipment, some of which may be more or less capable when compared to other devices being load balanced. NHR weights also allow administrators to test new or questionable machines without worrying that these members will be subjected to high traffic loads.

Recovery Time When a router fails, the LinkProof will continue to check for its availability. When the device once again becomes available, the LinkProof can be configured to wait a period of time before sending any traffic to the router. This "Recovery Time" allows machines to finish their start-up processes before receiving any traffic from the LinkProof.

Warm Up Time Once the Recovery Time has ended, the LinkProof can be configured to send traffic to an NHR a little bit at a time, gradually increasing the traffic. This "Warm Up" time helps prevent swamping a device with traffic the moment that the LinkProof confirms its availability.

Connection Limits Should administrators wish to limit the total number of connections to a specific device, a connection limit can be set. Since LinkProof maintains information about traffic it has dispatched to each router, it will not direct any additional users to a device that has reached its Connection Limit. By default, the Connection Limit is not set for any router. Connection Limits may be useful for devices that are bound by licensing requirements or by physical capabilities.

- 33 -



Traffic Limits Administrators can limit the total amount of traffic for a given NHR by setting either the Kbits, Inbound Kbits, or Outbound Kbits Limits.

NHR Operational Mode Routers can be configured as either Active or Backup. An Active device is one which is immediately capable of receiving traffic. A Backup device is one which will not be sent any traffic unless all Active devices become unavailable. This feature allows administrators to place older, less powerful routers in the load balancing scenario to handle traffic in the event that all other primary devices become unavailable.

Client Management The LinkProofs client table keeps track of inbound and outbound traffic that has been redirected through each of the available router servers. The client table tracks the following:

Source Address the clients source IP when the request reaches the LinkProof

Destination Address the destination IP in the clients request

Source Port the clients source port the request reaches the LinkProof

Destination Port the destination port in the clients request

Flow the applicable traffic flow as defined by the client (or if no flows have been defined, a Default Flow is used)

Farm Name based on the Flow, the router farm used for a flow match

Server Name the name (as given by the administrator) of the router server contained within the Farm.

Index an internal tracking number

Action / Port Number Indicates the action which the LinkProof has taken

Type Indicates the packet handling of this request

DN Dynamic NAT

SN Static NAT

- 34 -



VPN Virtual Private Network

Ext ID an additional internal tracking number

Client Aging Time and aging by port The Client Aging Time is a mechanism used to maintain persistence between a client and the device he was load-balanced through. When the LinkProof receives traffic from a new client, it will make a load-balancing decision based on the Dispatch Method (Cyclic, Least Traffic, etc.) set on the farm and will put an entry in the Client Table for that client-router match. As long as there is traffic between the client and the destination host hes connected to (or vice versa), the LinkProof will continue to send that client through the same router.

After this traffic stops, the Client Aging Time begins. When the Client Aging Time expires, the LinkProof will remove that clients entry from the Client Table. If traffic resumes within the Client Aging Time window, the LinkProof will update the time stamp and start the counter over when traffic stops. If a client resumes traffic after the Client Aging Time has expired, the LinkProof will make a new load-balancing decision and may send the client to a different router.

The default setting for a Farms Client Aging Time is 60 seconds. This can be increased as needed, but it is a global setting, which means that all entries for traffic through that router farm are retained in the table for this additional amount of time. Conceivably, in a high traffic network, the Client Table might fill up (this is very unlikely); to counter this and to improve the aging process of client entries, it is now possible to configure the LinkProof to age entries out at different times for different application ports. For example, port 80 traffic (web) can be set to age out at 30 seconds, while Telnet traffic (port 23) might be set to age out after 2 hours.

For any application ports that are not specifically set, the LinkProof will apply the Client Aging Time in the Farm Settings configuration.

Health Checking and Full Path Health Monitoring

- 35 -



As important as load balancing traffic is the concept of router health checking. It does no good to load balance traffic to a device if that particular machine is unavailable to handle the request. For this reason, the LinkProof can be configured to monitor the status of routers in order to make certain they are available. By default, the LinkProof uses Ping to make certain that a given device is available, and by default, the Radware unit will simply ping a single interface on the router. Since this method doesnt indicate whether the device itself is passing traffic, Radware has introduced Remote Connectivity Checks or Full Path Health Monitoring that allows the LinkProof to ping through a given device to remote addresses beyond. Should the pings fail anywhere along this path, the LinkProof will take that device out of service.

Once a device is marked as unavailable, the Radware unit will continue to check for its availability and will resume sending traffic to it once it passes all Remote Connectivity Checks. Instead of Ping, administrators can configure the LinkProof to use either a TCP port or an SNMP OID (Simple Network Management Protocol Object Identifier) as the method for health checking available devices. Since this is a global setting, all devices in the health check path must be capable of responding to the TCP port or must be configured to reply to the request for an SNMP OID. The default OID used is for sysObjectID, and the default community string is public. The following diagram illustrates Remote Connectivity Checks for the LinkProof:

- 36 -



Figure 6 - LinkProof Full Path Checking through Router

For the LinkProof, the check intervals and the number of retries can be configured according to need.

Note: You can specify up to 10 individual devices in the Full Path Health Checks for each NHR.

- 37 -



LinkProof Lab 3a Router Management for LinkProof (using CLI)

Lab Goals: Modify various settings designed to help manage routers Configure Aging By Application Use Connectivity Checks and Enable Health Monitoring (Lab 3b) Step-by-step: Admin Status and Operation Mode: To view the effects of changing the operation mode to shutdown (no new sessions sent to the active NHR all existing sessions remain) we will set one of the NHRs to backup. 1) Change the second ISP to backup:

lp servers router-servers set mainfarm ISP2 om 2 -om = Operational Mode and it can ether be: (1) Active (2) Backup

2) Change the global aging time to 45 seconds:

lp farms table set mainfarm -cl 45

3) Browse to the internet and make sure you have client table entries all going to ISP1:

lp client table 4) Set the first ISP to shutdown mode:

lp servers physical-servers set ISP1 -as 2 -as = Administrative Status and it has the following 3 values: (1) Enable

(2) Shutdown (3) Disable

- 38 -



Wait to see a trap in the CLI that the ISP is ready for shutdown.

5) Change both ISP1 and ISP2 back to their normal modes:

ISP 2 set back to Regular and ISP 1 set back to Enabled.

lp servers router-servers set mainfarm ISP2 -om 1 lp servers physical-servers set ISP1 -as 1

Recovery Time: To avoid the situation where an ISP will flap (come into service and fail quickly after) its advisable to set the Recovery Time, the amount of time the LinkProof will wait after the ISP passes a health check before sending it traffic. Its important to note this timer can only be used if the ISP actually failed. If you disabled and re-enabled the ISP it will ignore this timer. 6) Setting the Recovery Time

on the ISPs to 60 seconds:

lp servers physical-servers set ISP1 -rt 60 lp servers physical-servers set ISP2 -rt 60

Aging By Port: 7) This table allows you to define different aging times for different applications. You

may wish to age some times of traffic out of the client table sooner than the global aging time of one hour; or you may wish to have the device retain traffic types in the table for a longer period of time.

8) Define an aging time of 15 seconds for HTTP and 5 seconds for DNS:

Anything that is not defined specifically in this table will use the global Client Aging Time

.

lp global client-table application-aging-time create 53 -at 5 lp global client-table application-aging-time create 80 -at 15

9) Using your client, ping an address (ICMP) and open browser sessions and check the

client table to determine how long entries for DNS and HTTP are retained, the ICMP should stay for a long time after both DNS and HTTP age out.

- 39 -



10) Restore the configuration from Lab 2. Using Web based Management:

i) File Configuration File Send to Device, browse

to where you saved the file and the click Apply and reboot.

- 40 -



LinkProof Lab 3b Connectivity checks and Health Monitoring (using CLI) Lab Goals:

Configure Full Path Health Monitoring. Health Monitoring Mandatory Checks Health Monitoring Non-Mandatory Checks

Connectivity Checks Lab: Configure your LinkProof to use Health Monitoring checks to verify the availability of the Next-Hop-Routers. Step-by-Step: 1) Change a few of the settings for connectivity checks:

a) Change the Polling Interval

from 10 to 5. This setting instructs the LinkProof to check each NHR once every 5 seconds.

lp farms table set mainfarm -ci 5

b) Change the Number of Retries

from 5 to 3. This setting means that a Router can fail three consecutive health checks before the LinkProof will confirm that it is unavailable and will no longer load-balance traffic to it.

lp farms table set mainfarm -cr 3

2) To test the full path we will configure each of the ISPs to ping an address beyond their external side in this case we will use 192.168.150.100 for both routers.

Syntax: lp servers remote-checks-table create lp servers remote-checks-table create mainfarm ISP1 192.168.150.100 lp servers remote-checks-table create mainfarm ISP2 192.168.150.100

- 41 -



3) Ask your instructor to unplug the external connection (Or disable it) from one of the Routers.

4) Type in lp servers router-servers get and repeat a few times until for one of them it will say not in service.

5) Plug the connections for the router back in before continuing to the next lab.

Health Monitoring Lab Health Monitoring Mandatory Checks: It is much easier to configure the health monitoring module from web based management, a CLI version follows in the next section (Non-Mandatory Checks) 1) To use health monitoring connectivity checks must be turned off on each farm

Syntax: lp farms table set -hm 3

lp farms table set mainfarm -hm 3

2) The next step enable is to enable Health Monitoring: health-monitoring status set 1

3) Once Health Monitoring is turned on the next step is to create the actual health

checks, we will start with basic checks for this part of the lab.

Syntax: health-monitoring check create -m -d -h -m = Method, this is the application that will be used, you must type in the Method ID number or the value. To view the application associated with the Method ID type in health-monitoring method In Our Lab:

- 42 -



health-monitoring check create ISP1-PING-Outside -m 0 -d 192.168.150.100 -h 1.1.1.100 health-monitoring check create ISP2-PING-Outside -m 0 -d 192.168.150.100 -h 2.2.2.200 health-monitoring check create ISP1-ARP-Inside -m 11 -d 1.1.1.100 health-monitoring check create ISP2-ARP-Inside -m 11 -d 2.2.2.200 4) Once the 4 checks are created (2 for each ISP; 1 Inside, 1 Outside) we have to bind

these checks to the NHR farm to fail the routers with a check fails.

Syntax: health-monitoring binding create -g To bind the Checks to the Servers you need to look up the Health Name ID and the NHR ID For the Health Check ID look in health-monitoring check The look in the second column for the ID For the NHR ID health-monitoring server And look for the value in the first column. In Our Lab the complete commands will be as follows (this can vary depending on the Health Check ID): health-monitoring binding create 0 0 -g 1 health-monitoring binding create 2 0 -g 1 health-monitoring binding create 1 1 -g 2 health-monitoring binding create 3 1 -g 2

5) Verify that the NHRs are up and that all checks are passed:

health-monitoring check

6) Once you are configured ask your instructor to take down the outside interface of one

of your routers, you should see it fail.

- 43 -



Have your instructor bring the NHR back online before proceeding. Health Monitoring Non-Mandatory Checks (CLI): 1) Remove all the health checks from the binding table.

health-monitoring binding del 0 0 health-monitoring binding del 2 0 health-monitoring binding del 1 1 health-monitoring binding del 3 1

2) Remove all the health checks health-monitoring check del ISP1-PING-Outside health-monitoring check del ISP2-PING-Outside health-monitoring check del ISP1-ARP-Inside health-monitoring check del ISP2-ARP-Inside

3) To add new health checks in the CLI the syntax is as follows:

health-monitoring check create -m -d -h -p -a -r

Name = The name of the check will be used later in the binding field, the name cant be changed and the best practice is to use the name of the ISP as part of the name of the check. For example ISP1-DNS-Yahoo

.

-m = Method, this is the application that will be used, you must type in the Method ID number (In our lab we will use 10 that is DNS). To view the application associated with the Method ID type in

health-monitoring method

-d = Destination, the IP address of the destination server. -h = NHR, the NHR that you want this check to go out of.

- 44 -



-p = Port, the TCP or UDP port used for this application. -a = Arguments, the values given for this application, for example HOST=, or REGEX=. -r = Retries, the number of consecutive failed checks before the check will be counted as failed.

4) Create 4 DNS checks going out 2 for each ISP. health-monitoring check create ISP1-DNS-yahoo -m 10 -d 4.2.2.2 -h 1.1.1.100 -p 53 -a HOST=www.yahoo.com -r 2 health-monitoring check create ISP1-DNS-google -m 10 -d 4.2.2.1 -h 1.1.1.100 -p 53 -a HOST=www.google.com -r 2 health-monitoring check create ISP2-DNS-yahoo -m 10 -d 4.2.2.2 -h 2.2.2.200 -p 53 -a HOST=www.yahoo.com -r 2 health-monitoring check create ISP2-DNS-google -m 10 -d 4.2.2.1 -h 2.2.2.200 -p 53 -a HOST=www.google.com -r 2 5) After creating the checks make sure they all pass you can view the health table with

the following command:

health-monitoring check

6) The next step is to bind the checks to the Routers the syntax is as follows: health-monitoring binding create "HMM Server Name -g -m

- 45 -



Health Check Name = The name you created in the check table. HMM Server Name is the name the LinkProof gives your combination of farm name and ISP. To find out the names you can type: health-monitoring server -g = Group, all the checks for the NHR should be part of the same group number. -m = Mode, has two options:

o Mandatory o Non-mandatory

7) Create 4 bindings one for each check to the two ISPs marking them all as Non-

mandatory. NOTE: Make sure your health check numbers are correct or use the health check name. health-monitoring binding create 5 "NHR: mainfarm/ISP1" -g 1 -m Non-mandatory health-monitoring binding create 4 "NHR: mainfarm/ISP1" -g 1 -m Non-mandatory health-monitoring binding create 7 "NHR: mainfarm/ISP2" -g 2 -m Non-mandatory health-monitoring binding create 6 "NHR: mainfarm/ISP2" -g 2 -m Non-mandatory

8) Test the failover by having your instructor fail the external link of one of the ISPs.

- 46 -



Chapter 3 Review:

For a router that is currently up and running, what is the smoothest way to take it out of service?

If you want more traffic sent to a particular router, what setting can you use?

What is Recovery Time? What is Warm Up Time?

If you set an application aging time for HTTP to 3600 and the farm aging time to 600, what will happen?

What setting allows administrators to restrict the number of users sent to a router?

What is the Backup setting for Operational mode and why would it be used?

How many points can be checked through a router using Full Path Health Monitoring?

In an active / backup configuration of LinkProofs, with 3 routers, how many health checks would be performed if you checked 10 devices through each routers?

End of Chapter 3 please wait for your instructor before continuing

- 47 -



Chapter 4 Flow Policies Flow Policies

Administrators can configure the LinkProof to redirect specific kinds of traffic to specific devices or groups of devices. This feature is based on the concept of Flows, introduced in version 5.10 and can be done based on the destination port, destination IP address, source IP address, or combinations. Administrators create flows that contain the router farm to which the LinkProof will send traffic. Flow Policies instruct the LinkProof what types of traffic to use for specific flows. For example, a customer has two specific subnets that he would like to send out different routers. He would like Subnet-1 to be redirected out Routers 1 and 2; while Subnet-2 should go out Router 3. Traffic from any other undefined subnets can use either routers 1, 2 or 3. To accomplish this goal, the customer would first create three farms:

Main Farm this contains all three Routers Subnet-1 Farm this contains routers 1 and 2 Subnet-2 Farm this contains only router 3

Figure 7 - Router Farms

Having defined the three farms, the administrators next step is to define the flows for traffic:

Subnet-1 Flow Use Subnet-1 Farm Subnet-2 Flow Use Subnet-2 Farm

Since there is also a default flow which is used for anything not matching a more specific flow, this is as far as he needs to go in the definition of flows.

- 48 -



Figure 8 - Flow Definitions

The final step is to define the Flow Policies that instruct the LinkProof to watch for certain types of traffic (in this case the source address from clients) and which Flow to use when a match is found:

- 49 -



Figure 9 - Flow Policies for Source Traffic

The same principals can be applied to other situations. For example, if a customer wanted to have Web traffic use only Router 1 and FTP traffic use only Router 2, he would start by creating two Router farms: Web Farm containing Router 1 FTP Farm containing Router 2

- 50 -



Figure 10 - Flows for Applications

The flow policies the administrators define would be instruct the LinkProof that HTTP service traffic is to use the Web Flow (and thus the Web Farm); while FTP service traffic is to use the FTP Flow (and thus the FTP Farm).

- 51 -



Figure 11 - Flow Policies for Applications

Flow Policies and the Flows they use can also be based on combinations of factors such as any source or destination network, as well as any service type (such as HTTP, HTTPS, FTP, DNS, etc.)

- 52 -



LinkProof Lab 4 Flow Policies (using CLI)

Lab Goals: Setup up network definitions Create a flow for source networks Create a flow for an application Create a flow for application and destination network

Step-by-Step:

Pre Configuration Before Flow Policies can be created all the farms needed for the different flow possibilities must be created first. In our Lab we will end up with 3 farms Mainfarm = Farm with both ISP1 and ISP2 active Farm-ISP1 = Farm with Just ISP1 active ISP2 is set to backup mode Farm-ISP2 = Farm with just ISP2 active ISP1 is backup Creating the two new farms use the following commands Farm Creation: lp farms table create Farm-ISP1 -nm 1 lp farms table create Farm-ISP2 -nm 1 Adding Servers: To Farm-ISP1 lp servers router-servers create Farm-ISP1 ISP1 -ip 1.1.1.100 lp servers router-servers create Farm-ISP1 ISP2 -ip 2.2.2.200 -om backup To Farm-ISP2 lp servers router-servers create Farm-ISP2 ISP1 -ip 1.1.1.100 -om backup lp servers router-servers create Farm-ISP2 ISP2 -ip 2.2.2.200 Setting up Networks:

- 53 -



The next step is to set the various networks we will use, there are two types of networks supported by Radware:

1) A Range of IP Address 2) A full Subnet

We will create both in the network table. Create a Range of IP Address Syntax: classes modify network create f -t -m Subindex can be any value but a good idea to go in order. -m = Mode can have one of two values depending on the network being created (1) IP Mask (2) IP Range For this lab create the following two Ranges: classes modify network create Internal 1 -f 192.168.200.1 -t 192.168.200.254 -m 2 classes modify network create DNS-IP 2 -f 4.2.2.2 -t 4.2.2.3 -m 2 Create an IP Mask Syntax: classes modify network create a -s -m Create the following two Networks: classes modify network create Outside 3 -a 198.6.1.0 -s 255.255.255.0 -m 1 classes modify network create DNS-Net 4 -a 4.2.2.0 -s 255.255.255.0 -m 1 The last step is to update the information Use the following to save these updates: bwm update-policies set 1 Flow Policies for Networks:

- 54 -



In some situations, customers may only want to use a subset of available routers for certain types of traffic. For example, a customer may want users from a certain internal subnet only to go out one of the available routers. Or another customer may want web traffic to go out a single router. In previous versions of LinkProof code, this was done by using Grouping. With the introduction of LinkProof version 5.10, this is now accomplished with Flow Policies. The following labs will introduce you to configuring Flow Policies. 1) The first step in actually creating a flow is the Flow Name, on the LinkProof the flow

will only contain one farm, on other devices it is possible to use multiple farms in a flow.

Syntax: lp flow-management farms-flow-table create For this lab we will create the following flows lp flow-management farms-flow-table create ISP1 Farm-ISP1 lp flow-management farms-flow-table create ISP2 Farm-ISP2 Once complete it should look like the following: lp flow-management farms-flow-table

Figure 12 Flow Table

2) Create the following flow to force all traffic going to the DNS IPs out ISP 1

Syntax:

- 55 -



lp flow-management modify-policy-table create -i -dst -src -fc -i = Index, this value will determine what policy will be processed first. Order is important and the policies are processed in numerical order (I.E. 1 2 3 ). -dst and src = The destination and source networks, you must have defined them already in the network table before using them here. -fc = Flow Cluster, as we defined in the first step of the lab.

lp flow-management modify-policy-table create DNS -i 1 -dst DNS-IP -src any -dr "Two Way" -fc ISP1

3) We will now create a second policy that will direct all traffic from the subnet of

192.168.200.0 to ISP 2. You will note since the index of this rule is 2, DNS traffic to 4.2.2.2 will still go out ISP 1.

lp flow-management modify-policy-table create Outbound -i 2 -dst any -src Internal -dr "Two Way" -fc ISP2

4) The last step is to activate the polices, use the command:

bwm update-policies set 1 5) Test the policy by browsing out and seeing the results in the client table. Then fail

one router and see that everything fails over. Flow Policies for Applications In this section, you will create flow policies to send web traffic out ISP1 and DNS traffic out ISP2. The first step is removing the policies we created above. 6) To Delete a Policy:

Syntax: lp flow-management modify-policy-table del

In Our Lab: lp flow-management modify-policy-table del DNS lp flow-management modify-policy-table del Outbound

- 56 -



The last part is to updated the active policies: bwm update-policies set 1

7) Next we will create two new policies, this time we will add a new flag for an

application:

Syntax: lp flow-management modify-policy-table create -i -pt filter p -dst -src -fc -pt = Service Type, this is used if you want to select a layer 4 7 Service to be used for the filter. The default is none. The values are as follows:

(1) none (2) filter = A single Policy (3) group = A group of Filters and Policies (4) policy = A group of filters with an And condition (Must match all filters at the same time)

-p = The Actual filter from the list, It is much easier to view this list in Web Based then CLI, the value after the p must be a filter on the list. To view the list use the CLI command: classes modify service basic In Our Lab: lp flow-management modify-policy-table create HTTP -i 2 -pt filter -p http -dst any -src Internal -fc ISP1 lp flow-management modify-policy-table create DNS -i 3 -pt filter -p DNS -dst any -src Internal -fc ISP2

8) To activate the new policies

bwm update-policies set 1 9) Now we can test the policy from the Virtual Appliance browse to the internet and a

few web pages then look at the client table, you should see all HTTP traffic go to ISP1 and DNS will go to ISP2

Practical Exercise for Chapter 4: 10) Remove the two policies above and create a policy for your workstation when it does

a DNS query it will be forced out ISP2, however all other traffic is load balanced. In addition any other client will be load balanced no matter what traffic is used.

- 57 -



11) Restore the configuration from Lab 2 before going on to the next lab. .

- 58 -



Chapter 4 Review Questions What is the default Client Aging Time on a LinkProof router farm? What is the Client Aging Time used for? What happens if a clients entry is removed from the table and the client resumes traffic to the same destination host?

- 59 -



LinkProof Practical Exercise #1

A customer just bought a LinkProof and has two ISP

ISP 1 = 3.3.3.50 /24

ISP 2 = 4.4.4.150 /24

He wants to just load balance outbound traffic through each one for Dynamic NAT use 3.10# and 4.10#

He has a Guest Network inside that for all HTTP traffic he wants it to go to ISP1 The network is 10.200.200.0/24

He also has a partner on the outside 128.177.28.44 that must go through ISP 2, even the Guest network must go to ISP 2 to reach this partner.

He wants the default aging time to be 300 seconds and application specific aging times to be

HTTP 60

DNS 15

HTTPS 600

He also wants to check DNS through each ISP create health monitoring checks to check www.cnn.com and www.radware.com to 4.2.2.2 and 4.2.2.3

- 60 -



Chapter 5 LinkProof Inbound Load-Balancing The LinkProof has the ability to act as a DNS Name Server so that it can answer DNS queries for specific internal hosts. This feature allows the LinkProof to return A Records to querying DNS servers from either network for which it is load-balancing Next Hop Routers.

A single internal host, such as a web server, can be statically mapped to two or more different external IP addresses (one on each of the Routers networks). The LinkProof is then configured to answer inbound queries by placing its Virtual DNS addresses in the main DNS servers table as NS Records. Any time a DNS server needs to have a particular host resolved, that query will be referred to the LinkProof. The LinkProof can then reply with an A record on any of its configured router networks.

Should a given link fail, the querying DNS server will fail over to the second NS Record in DNS and reach the LinkProof through the available network. The LinkProof will know that the failed link is unavailable and will only respond with A Records from the network of the active router.

The diagram below illustrates the concept:

Figure 13 LinkProof Inbound Load Balancing

- 61 -

Radware 2

radware linkproof user guide 200-101_lp_level1-v9

Documents

linkproof chapter

international radware

linkproof overview

product version linkproof

existing radware device

functions of radware

north america radware

radware sales person