Radware Linkproof User Guide 200-101_LP_Level1-v9

C o u r s e Co d e : 200 - 1 01 L i n kP r o o f – L e ve l 1 T r a i n i n g M an u al October 2010

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

-2-

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 – indicates an option or entry within Web Based Management screen or window

•

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

•

Courier – indicates CLI or telnet commands

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

-3-

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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

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

-4-

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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)......................................................................160 LAB B – CREATING A SIMPLE BLOCK POLICY IN BWM...................................................................................165 LAB C – CREATING A SIMPLE MINIMUM AND MAXIMUM POLICY .......................................................................166

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

-5-

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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:

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

-6-

LinkProof Training Manual – Level 1 Date: October 2010 Page - 6 -

Figure 1 – Sample LinkProof Configuration

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

-7-

LinkProof Training Manual – Level 1 Date: October 2010 Page - 7 -

Chapter 1 – LinkProof Overview Radware’s 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 router’s network. Static Smart NAT allows the LinkProof to translate an internal host’s requests out one or more next-hop-routers using a single, static address on each router’s 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. © Radware 2010. All rights reserved. Distribution of this document needs approval from Radware Knowledge & Education Services.

-8-

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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 LinkProof’s calculations.

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

-9-

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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#

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

- 10 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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):

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

- 11 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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)

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

- 12 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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 = 10.10.243.# b) 1. IP subnet mask = 255.255.248.0 c) 2. Port Number = MNG-1 d) Hit for ALL the other values to set them to default.

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:

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

- 13 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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 team’s 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

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

- 14 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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 team’s 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

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

- 15 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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 team’s 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.

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

- 16 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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.

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

- 17 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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):

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

- 18 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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 multihomed 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?

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

- 19 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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 loadbalancing 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)

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

- 20 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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

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

- 21 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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 loadbalancing 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 LinkProof’s 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

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

- 22 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 22 -

resources through the available connections. The LinkProof utilizes DNS to accomplish this. Consider the following network configuration

Figure 3 - Inbound Traffic Redirection

The customer’s 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 customer’s 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 customer’s existing DNS server to refer queries to the LinkProof interfaces that reside on each ISP network.

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

- 23 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 23 -

The LinkProof is configured with the internal web server’s host name, it’s corresponding internal IP address and with two public addresses that it can use to answer incoming queries – a static address from ISP A’s network and a static address from ISP B’s 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 customer’s 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.

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

- 24 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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.

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

- 25 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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).

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

- 26 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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.

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

- 27 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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

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

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

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

Team2 Team10 Team11

When complete, to display the NAT table type:

Figure 4 – Dynamic NAT Table

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

- 28 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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.

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

- 29 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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

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

- 30 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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.

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

- 31 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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?

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

- 32 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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.

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

- 33 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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 LinkProof’s 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 client’s source IP when the request reaches the LinkProof Destination Address – the destination IP in the client’s request Source Port – the client’s source port the request reaches the LinkProof Destination Port – the destination port in the client’s 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

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

- 34 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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 he’s 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 client’s 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 Farm’s 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

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

- 35 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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 doesn’t 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:

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

- 36 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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.

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

- 37 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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 © Radware 2010. All rights reserved. Distribution of this document needs approval from Radware Knowledge & Education Services.

- 38 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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. It’s 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.

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

- 39 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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.

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

- 40 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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

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

- 41 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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: © Radware 2010. All rights reserved. Distribution of this document needs approval from Radware Knowledge & Education Services.

- 42 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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 health-monitoring health-monitoring health-monitoring

binding binding binding binding

create create create create

0 2 1 3

0 0 1 1

-g -g -g -g

1 1 2 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.

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

- 43 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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 health-monitoring health-monitoring health-monitoring

binding binding binding binding

del del del del

0 2 1 3

0 0 1 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 can’t 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.

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

- 44 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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 4.2.2.1 -h 1.1.1.100 -p health-monitoring check 4.2.2.2 -h 2.2.2.200 -p

create ISP1-DNS-google -m 10 -d 53 -a HOST=www.google.com -r 2 create ISP2-DNS-yahoo -m 10 -d 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

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

- 45 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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 Nonmandatory. NOTE: Make sure your health check numbers are correct or use the health check name.

health-monitoring binding g 1 -m Non-mandatory health-monitoring binding g 1 -m Non-mandatory health-monitoring binding g 2 -m Non-mandatory health-monitoring binding g 2 -m Non-mandatory

create 5 "NHR: mainfarm/ISP1" create 4 "NHR: mainfarm/ISP1" create 7 "NHR: mainfarm/ISP2" create 6 "NHR: mainfarm/ISP2" -

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

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

- 46 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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

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

- 47 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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 administrator’s 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. © Radware 2010. All rights reserved. Distribution of this document needs approval from Radware Knowledge & Education Services.

- 48 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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:

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

- 49 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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

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

- 50 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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).

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

- 51 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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.)

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

- 52 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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:

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

- 53 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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: © Radware 2010. All rights reserved. Distribution of this document needs approval from Radware Knowledge & Education Services.

- 54 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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:

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

- 55 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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

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

- 56 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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.

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

- 57 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 57 -

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

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

- 58 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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 client’s entry is removed from the table and the client resumes traffic to the same destination host?

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

- 59 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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

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

- 60 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 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 Router’s networks). The LinkProof is then configured to answer inbound queries by placing its Virtual DNS addresses in the main DNS server’s 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

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

- 61 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 61 -

Queries from external DNS servers for www.Radware.com will be referred to either Virtual DNS Address on the LinkProof (usually by round-robin distribution). Should a link fail and the querying DNS server can’t reach the LinkProof name server, the DNS server will fail over to its second NS Record (also the LinkProof). When the LinkProof receives a query to either Virtual DNS Address, it can respond with an A Record on either network (in this case, either 100.100.100.50 or 200.200.200.50). Since both external addresses are bound to the same internal web host, an outside client will be able to get to the site through either link.

•

Proximity Settings Proximity is the process of determining which available network path (i.e. which ISP router) is the “best” one to use in a given situation. “Best” depends on a customer’s needs, but more often than not, the path with the least amount of latency is usually the optimal one. Over time, the LinkProof will build a detailed Proximity Table that lists destination networks and ranks the available ISP routers in order of preference from fastest to slowest. If a given router fails, the LinkProof won’t use that path even if it is listed first in the Proximity Table. The LinkProof calculates Proximity in the background by initiating various types of traffic through each link to the same destination host. Based on the round-trip time and other information gathered from the response, the LinkProof can then build and entry in its Proximity Table for that host’s destination network. Each entry typically remains in the Proximity Table for 2 days, though that value can be increased or decreased as needed; additionally, there are internal LinkProof mechanisms that can initiate recalculations of existing entries. Outbound Proximity If an internal user generates traffic to an external destination host, and that external hosts’ network is not listed in the Proximity Table, the LinkProof will load balance that user’s traffic out the least-loaded router. It may not necessarily be the “best” one to use, but the LinkProof has no data yet about the distance and latency to that destination network through the available routers.

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

- 62 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 62 -

Once the internal user’s session has been forwarded, in the background the LinkProof will begin generating its Proximity traffic and calculating the values necessary to place an entry for that destination network in its Proximity Table. Inbound Proximity The LinkProof can determine which is the “best” link to use for particular DNS servers based on Proximity calculations. For example, if the LinkProof is load-balancing two NHRs and has an internal host for which it is acting as the Name Server, the LinkProof can return an A Record which is closer, faster or less loaded for the querying DNS server. When it receives a query from an outside DNS server, the LinkProof will first return an A Record for the network that is least loaded (since the LinkProof knows how much traffic is on each link). Once the initial query has been answered, the LinkProof will initiate traffic back to the same querying DNS server using several different methods. The purpose is not to initiate a session, but only to determine latency and actual router hops. The LinkProof will initiate traffic through each of its links back to the DNS server and then build a table based on the results. This “Proximity Table” is used for future reference, and any subsequent queries from the same DNS server (or any other DNS servers on the same 24-bit network), the LinkProof will know that the “best” record to return is one from the faster or closer network, according to its table. By default, the LinkProof will retain these entries in its Proximity Table for 2 days before they are dropped out. This value can be adjusted as can the TTL (Time to Live) for the DNS responses that the LinkProof generates. The LinkProof can also be configured to respond with two A Records and will order them according to its proximity table. Additionally, administrators can adjust the weight that the LinkProof gives to Latency, Hops and Load, increasing or decreasing their relative importance. The diagram below illustrates the proximity calculations:

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

- 63 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 63 -

Figure 14 – LinkProof Proximity Overview

For inbound traffic, the LinkProof will receive a name query from a client’s DNS server first. The LinkProof will respond with an A-Record IP address belonging to the ISP router that is currently the least loaded. Once the query has been answered, the LinkProof will then generate Proximity Traffic in the background to the DNS server that made the initial query. The LinkProof can be configured to consider three factors when making Proximity determinations: Latency, Hops and Load. Typically, most customers are concerned with providing users the most responsive service both inbound to and outbound from their network. In such cases, Latency should be given a higher weight (on a scale of 1 to 99).

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

- 64 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 64 -

Hops, the number of actual router hops for a given route, may not make a great deal of difference as long as the latency is low, so this is often given a lower weight. Load is the amount of traffic into and out of a particular Next Hop Router and can affect how quickly a user gets into or out of a network. If an NHR is heavily loaded, the LinkProof can take this into consideration and select another router that is less loaded. For Outbound traffic (internal users headed to external hosts), the LinkProof can calculate Proximity to the destination host itself). For Inbound traffic (external users headed to internal hosts like www, ftp etc.), the LinkProof calculates Proximity to the client’s DNS server that made the name query. In both cases, entries are stored in the Proximity Table based on the 24-bit destination network (255.255.255.0). The LinkProof can be configured to perform only Outbound Proximity, Inbound Proximity or Both:

Figure 15 - LinkProof Proximity Parameters

•

Selective Proximity Checks By default, the LinkProof will perform proximity calculations using several different internal mechanisms. In some cases, these proximity calculations may trigger IDS systems at the destination network. With version 3.30 and later, administrators now have to flexibility to choose which proximity methods the LinkProof uses:

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

- 65 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 65 -

Figure 16 - LinkProof Proximity Check Settings

Basic - This is a simple test; not related to an application. This test typically applies to inbound traffic. Advanced - This test simulates standard applications and is used for both inbound and outbound traffic. Client Side - Used for outbound traffic, this test simulates a client application. Server Side - This test simulates the server side of an application and is used for inbound traffic. Additionally, administrators can either Enable or Disable proximity calculations for specific routers (right-hand column – NHR Proximity Check Status):

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

- 66 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 66 -

Figure 17 - LinkProof Proximity Check Status per NHR

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

- 67 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 67 -

•

LinkProof Lab 5 – Inbound Load Balancing and Proximity (using CLI)

Lab Goals: • • •

Configure the LinkProof to perform inbound load balancing Test using a DNS lookup utility Configure the LinkProof to perform Proximity calculations

Use the configuration from the previous labs. Step by Step: Static NAT 1. The first step for inbound is to create static Smart NAT addresses to represent an internal server behind your LinkProofs. You will create two external addresses for this server, one from each Router network space. Syntax:

lp smartnat static-nat create NHR-ISP Notes: Internal Range = Range of internal server IPs that you want to define a public IP for, if you have only one server the Start and End have to be the same IP. External Range = Range of Public IPs for the Internal Range, the external range maps one to one in sequence for example: 192.168.200.101 192.168.200.105 1.1.1.100(NHR) 1.1.1.31 1.1.1.35 This means 101 = 31, 102 = 32 and so on. In our lab we will set the following two entries (one for each NHR): lp smartnat static-nat create 192.168.200.10# 192.168.200.10# 1.1.1.100 1.1.1.20# 1.1.1.20# lp smartnat static-nat create 192.168.200.10# 192.168.200.10# 2.2.2.200 2.2.2.20# 2.2.2.20#

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

- 68 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 68 -

2. When complete, you can check your static NAT table: lp smartnat static-nat

3. Once done, browse out with your Client and notice in the client table you are going out with the Static NAT.

DNS Configuration 4. The next step in inbound configuration is the DNS configuration there are two main parts of this configuration the first one is Name To Local IP, this table contains all the host names that the LinkProof will resolve and their Local IP address. This address is the same as the Local Address in the Static NAT configuration. Syntax:

lp dns host-to-ip-tables name-to-ip create -lia In Our Lab we will use the following:

lp dns host-to-ip-tables name-to-ip create www.team#.com -lia 192.168.200.10# 5. The next part is the DNS Virtual IP, this IP address is used as the NS record on the SOA DNS server, the best practice is to configure one DNS VIP per ISP, and to also have one on the internal interface (We will explain that one with redundancy). Syntax:

lp dns virtual-ip create In Our Lab we will use the following two addresses (50+# means add your team number to 50):

lp dns virtual-ip create 1.1.1.50+# lp dns virtual-ip create 2.2.2.50+#

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

- 69 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 69 -

6. To verify the table type in lp dns virtual-ip 7. It is recommended to change the TTL from default of zero to at least 5 seconds up to 30 seconds.

lp dns response-ttl set 5 8. The last step is to enable the two records in reply feature, this can be used to avoid DNS caching issues and to give clients an alternate address. This feature is also useful in the lab to demonstrate failover. lp dns two-records set enable 9. To test the response, from the VNC remote desktop use a terminal and the nslookup command type in nslookup www.team#.com 192.168.200.# Note: If you are using Linux then you would use the host command host www.team#.com 192.168.200.#

10. At this point you can now fail one of the two ISPs (Disable it) and run the lookup again you should now only get one A record back. To disable (as = 3) and enable (as = 1) you can use the following command: lp servers router-servers set mainfarm ISP1 -as 3

Optional Components Proximity: Note: Proximity is difficult to simulate in the lab since the difference in hops and latency is minimal. This lab is designed to illustrate the principals behind proximity. 11. The first step is to enable proximity on the LinkProof, there are a few options you can enable it only for Inbound or Outbound traffic, or enable it both ways, in our lab we will enable both ways. lp proximity mode set 5 12. The next step is to choose the importance of three variables Hops, Latency, and Load. Depending on the desired result or the network you can modify what is more important then the other on a scale of 1  100 with 100 being highest.

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

- 70 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 70 -

lp load-balancing-weights hops-weight set 60 lp load-balancing-weights latency-weight set 20 lp load-balancing-weights load-weight set 80 13. It’s possible to enable statistics on the proximity lp proximity statistics status set 1 14. Open browser connections to various sites from your remote desktop (If you changed the IP before change it back to 192.168.200.10#). Connect to the LinkProof through the CLI and type in the following command: lp proximity dynamic-table This will display the LinkProof’s dynamic proximity table: Subnet

Farm name

Server 1

Latency 1

Hops 1

Server 2

Latency 2

Hops 2

Server 3

Latency 3

Hops 3

......................................... 64.236. 16.

0

MainFarm

Hits counter 0 1.

1.

1.100

65

213

2.

2.

2.200

85

213

69. 44.123.

0

MainFarm

Hits counter 0 1.

1.

1.100

25

202

2.

2.

2.200

35

202

By typing the following command you can see the proximity statistics:

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

- 71 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 71 -

•

Chapter 5 Review:

What system does the LinkProof rely on for redirecting external clients to internal hosts through various next hop routers? What kind of records should be placed in a customer’s DNS server to redirect DNS queries to the LinkProof? What are Virtual DNS Addresses used for? What actual addresses should be placed in a customer’s DNS server to redirect DNS queries to the LinkProof? What features can the LinkProof use to help overcome DNS lookup caching? True or False: If a Next Hop Router is down, the LinkProof will not respond to incoming DNS queries by giving out an address that belongs to the failed router? In general terms, what is Proximity on the LinkProof? The LinkProof calculates outbound proximity to what devices? The LinkProof calculates inbound proximity to what devices?

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

- 72 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 72 -

How does the LinkProof store entries in the Proximity Table? When configuring proximity, what three factors can be tuned to determine the “best” NHR to use? Why would load be an important factor to consider? By default, how long are entries stored in the proximity table on the LP?

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

- 73 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 73 -

Chapter 6 LinkProof Redundancy Radware recommends that its LinkProof units be installed in pairs to provide fault tolerance in the case of a single unit's failure. Each pair of devices functions in an Active / Backup configuration; the backup unit will come online should the primary unit fail. Note: LinkProof pairs do not use a dedicated connection or cable to monitor one another's status.

•

VRRP Redundancy

VRRP (Virtual Router Redundancy Protocol) is available on the LinkProof running version 3.61 or later. This fairly common standard is often used between various pairs networking devices such as firewalls or routers. It provides for a “shared” VR or Virtual Router, with one device acting as the master for this VR and a second device configured as backup for the same VR. When discussing VRRP, it may be less confusing to think of the “virtual router” as a “virtual MAC address,” since that is essentially how the protocol operates. By configuring VRRP, administrators actually create a shared MAC address on the Radware device, with one unit acting as the Master and the second as the Backup for this virtual MAC. Once the shared MAC address has been created, administrators associate IP addresses to it. This typically includes the interface addresses, virtual IPs, virtual DNS addresses, etc. that reside on the Active LinkProof. The backup device is also configured with the same IP associations as its active partner so that it can take over all associated IP addresses should the primary device fail. For more information regarding the VRRP protocol, see RFC 2338.

•

Configuration In the case of an Active / Backup configuration, the Active LinkProof unit is configured to handle all traffic. The Backup device is configured with an identical NHR table containing the exact same devices and settings. The only difference between this unit and the Active unit is that the backup unit is set with an Operation Status of Backup. The Backup LinkProof will periodically send out ARPs to verify that the Active unit is available. If it fails to get responses from the active device, the Backup unit will advertise it's MAC addresses for the IP address of its Active partner, letting all

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

- 74 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 74 -

devices on the networks know that it is now responsible for its failed partner's IP addresses. The Backup device will continue to listen for it's downed partner and will release these IP addresses should the Active unit come back online.

•

Table Mirroring When a backup LinkProof is used to provide redundancy for a primary unit, it is possible for the backup device to share the primary device’s client table. Portions or all of the table are periodically shared between the 2 devices so that in case of a primary device failure, the secondary device can maintain the client sessions as accurately as possible, with minimum or no client connectivity loss.

Figure 18 - Redundant LinkProofs

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

- 75 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 75 -

LinkProof Lab 6 – VRRP Redundancy (using CLI) Lab Goals: • •

Configure a pair of LinkProofs in an Active / Backup Configuration using the VRRP Redundancy method Test Failover by disconnecting the Active device

Note: For this lab you will partner with another team, however there is very little that needs to be changed on the backup device, almost all the configuration is on the primary. Pre-Configuration: MASTER device only: On the MASTER device we will remove the 192.168.200.# interface, as stated above we want to change the default gateway of the internal network to a DNS VIP.

net ip del 192.168.200.# Now add a new IP

net ip create 192.168.200.20# 255.255.255.0 2 The last step is create the DNS VIP as the default gateway

lp dns virtual-ip create 192.168.200.# You can now reach the internet from your Client as you did before. Redundancy Configuration MASTER device (# is your team number): 1) To configure VRRP it first must be enabled. redundancy mode set vrrp

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

- 76 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 76 -

2) Now the next step is creating the VRs, we will create a VR per network the LinkProof is on with the exception of the management network (10.10.243.x) Syntax: redundancy vrrp virtual-routers create -p -pip VR ID = A number from 1  255, you have to make sure the number is unique on the network to the Radware devices. -p = Priority a value from 1  255 with 255 being the highest and absolute master for a VR. -pip = Interface IP, this is the IP that is configured on the physical interface that reflects what network the VR belongs to (For example VR ID of 111 will be on the 192.168.200.x network). In Our Lab use the following 3 VR IDs (Remember # is your Team number): redundancy vrrp virtual-routers create 2 #0 -p 254 -pip 192.168.200.20# redundancy vrrp virtual-routers create 1 #1 -p 254 -pip 1.1.1.# redundancy vrrp virtual-routers create 1 #2 -p 254 -pip 2.2.2.#

3) Once the VRs are created we can now associate all the IPs to these VRs, we need to associate ALL Smart NAT IPs and ALL DNS VIPs Syntax: redundancy vrrp associated-ip create IP = IP you want to bind to the VR ID In Our Lab we will associate the following IPs See table on the next page:

Port Index

VR ID

Associated IP

Description

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

- 77 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 77 -

F-2

#0

192.168.200.#

F-1

#1

1.1.1.10#

F-1

#2

2.2.2.10#

F-1

#1

1.1.1.20#

F-1

#2

2.2.2.20#

F-1

#1

1.1.1.50+#

F-1

#2

2.2.2.50+#

DNS VIP on Port 1 Dynamic NAT IPs Static NAT IPs DNS Virtual IPs

redundancy vrrp associated-ip create 2 #0 192.168.200.# redundancy vrrp associated-ip create 1 #1 1.1.1.50+# redundancy vrrp associated-ip create 1 #1 1.1.1.10# redundancy vrrp associated-ip create 1 #1 1.1.1.20# redundancy vrrp associated-ip create 1 #2 2.2.2.50+# redundancy vrrp associated-ip create 1 #2 2.2.2.10# redundancy vrrp associated-ip create 1 #2 2.2.2.20# 4) At this point we are ready to enable the virtual routers on the Master device. redundancy vrrp virtual-routers set 2 #0 -as 1 redundancy vrrp virtual-routers set 1 #1 -as 1 redundancy vrrp virtual-routers set 1 #2 -as 1 5) The last two steps on the primary device is to enable interface grouping this will allow the LinkProof to failover if one of the interfaces go down however we want to make sure the management port is not taken down when this happens. To enable interface grouping:

redundancy interface-group set 1 To exclude the management port 16 from interface grouping: NOTE: On the ODS hardware the MNG-1 port is excluded by default!

redundancy master-interface-group set 16 -s 2

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

- 78 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 78 -

6) Now, the peer addresses must be configured on the Master device. The peer addresses allow the Master device to automatically create a configuration for the Backup device. The command is: net ip-interface set -pac In our lab we will use the following commands: net net net net

ip-interface ip-interface ip-interface ip-interface

set set set set

192.168.200.20# -pac 192.168.200.X 1.1.1.# -pac 1.1.1.X 2.2.2.# -pac 2.2.2.X 10.10.243.# -pac 10.10.243.X

Redundancy Configuration BACKUP device: (# is the MASTER team number X is the Backup team number):

7) The only thing that is needed on the backup devices is the management interface. If the Backup LinkProof is already configured for one of the previous labs, then nothing further needs to be done. IP Addresses for Backup (if needed) net ip create 10.10.243.x 255.255.248.0 mng-1 Web Based Management Configuration Download/Upload 8) At this point we have to switch to Web Based Management to finish the redundancy configuration. Open up Internet Explorer on your remote desktop (VNC session) and browse to the primary device at http://10.10.243.#. The user name will be team# and the password will be team# 9) Go to File  Configuration  Receive from Device. Choose Backup (ActiveBackup) and press the Set button. Change the name of the file so that you can recognize it as the backup redundancy configuration and save it to the remote desktop. . 10) Browse to the Backup linkproof at http://10.10.243.X. Go to File Configuration  Send to Device on the Backup linkproof and choose Replace configuration file as the Upload mode. Press the Set button and press the Set button on the popup message to reset the backup LinkProof (If you don’t see the pop-up message, go to

Device  Reset Device in order to reboot the backup LinkProof).

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

- 79 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 79 -

Test of the Redundancy At this point the backup up is now configured to take over in the event of the master device failing. We will simulate a failover in the class we will take down one of the interfaces of the primary unit. Since we have the Management Port excluded from Interface grouping you should still have connectivity to the Master device. 11) From the Remote Desktop (VNC session), ping an outside address continuously (4.2.2.2 for example) and ping the default gateway 192.168.200.# 12) On the Master device use the following command to force failover:

net port down 1 13) On the Backup you should see messages that it has taken over and the Pings should still be working, with maybe 1 missed ping. LinkProof#19-09-2008 17:03:03 INFO VRRP: now master of VR ID 12 14) Fail back to the Master:

net port up 1 Chapter 6 Review Questions: True or False - Generally speaking, a backup LinkProof should be configured identically to its active partner. What settings are different on a backup device than on an active device? What is Mirroring and what is it designed to accomplish? What is Interface Grouping and should it be enabled on an Active or Backup Unit? True or False: when a backup device takes over for an active device, entries in the IP Redundancy Table on a Backup device should have an Operating Status of “InActive” How can you verify that a backup LinkProof has taken over for a failed active LinkProof? What does VRRP stand for?

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

- 80 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 80 -

What are VRs? What are Associated IP Addresses? How does a backup device monitor the status of an active device using VRRP? What is different about VRRP from the Proprietary redundancy method? What setting determines which device is master in an Active/Backup VRRP configuration? What should you do before implementing VRRP on a pair of LinkProof in an existing network? If you have four physical interfaces with 8 different networks in use on a pair of LinkProofs, at least how many VRs would you need to configure on each unit?

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

- 81 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 81 -

Chapter 7 One IP Configuration In some cases when installing the LinkProof there is only one IP available or a customer wants to only use a single IP for multiple servers accepting inbound traffic. One IP configuration has two main parts Outbound Dynamic NAT Inbound Static PAT For outbound Dynamic NAT the physical interface IP can also be used as the Dynamic NAT IP thus there is no need to configure another IP address for Dynamic NAT. Inbound Static PAT allows a user to configure the LinkProof to accept traffic for multiple backend systems on a single external IP. For example a network might have a resource server on HTTP and an email server on port 25, they can now use the same external IP address for both systems. This feature can be combined with the Outbound NAT to use a single IP for all inbound and outbound traffic or it can be used on its own without the one IP configuration.

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

- 82 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 82 -

•

LinkProof Lab 7 – One IP Configuration (using CLI)

Lab Goals: •

Configure the LinkProof to only use its interface for outbound dynamic NAT

•

Configure inbound SPAT

•

One IP can only be configured from the CLI or WBM

Step-by-Step NOTE: Single IP configuration and redundancy are not fully supported at this time please be aware that this configuration is for locations were a redundant LinkProof will not be used or is not needed. 1) Restore the configuration saved at the end of Lab 2 2) From the CLI to enable the Interface for 1 IP use the following command: net ip-interface set -oi net ip-interface set 1.1.1.# -oi enable net ip-interface set 2.2.2.# -oi enable 3) Delete the previously configured dynamic NAT (In Lab 2) and you will create a new dynamic NAT using the IP of the interface: 4) Create a new Dynamic NAT to the interface IP (Where # is your team number) lp smartnat dynamic-nat create 0.0.0.1 255.255.255.254 1.1.1.100 1.1.1.# lp smartnat dynamic-nat create 0.0.0.1 255.255.255.254 2.2.2.200 2.2.2.#

5) Create a SPAT for a web server and email server: a) First you have to change the web based management port manage web server-port set 8080

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

- 83 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 83 -

b) Then configure the Static NAT lp smartnat static-pat add 192.168.200.10# 80 tcp 1.1.1.100 1.1.1.# 80 lp smartnat static-pat add 192.168.200.10# 80 tcp 2.2.2.200 2.2.2.# 80 lp smartnat static-pat add 192.168.200.10# 25 tcp 1.1.1.100 1.1.1.# 25 lp smartnat static-pat add 192.168.200.10# 25 tcp 2.2.2.200 2.2.2.# 25

6) Test Outbound Traffic, and if you have a web service running on your Client you can test it from the outside. End of Lab 7 Please wait for your Instructor before Continuing

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

- 84 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 84 -

LinkProof Management LinkProof Lab 8 – Managing the LinkProof (using CLI) Lab Goals: •

Enable and configure various options related to managing the AppDirector itself

Step By Step: Enabling Management Traffic: manage manage manage manage

web status set enable secure-web status set enable telnet status set enable ssh status set enable

Enabling Management Traffic by port (Default All Ports Enabled): 1. From the CLI you can type Syntax: manage management-port set The Mangement Types are: -sn : SNMP -t : TELNET -sh : SSH -w : WEB -sl : SSL Disable Port 2 for all management:

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

- 85 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 85 -

manage manage manage manage manage

management-port management-port management-port management-port management-port

set set set set set

2 2 2 2 2

–sn 2 –t 2 –sh 2 –w 2 –sl 2

Note that each management method (telnet, web, etc.) must be enabled globally regardless of the port status for that method.

Enabling Different Traps Outputs: 2. There are three different systems that can be configured to receive event traps from the device; SNMP, SYSLOG, SMTP. Each one will be discussed. 3. To Enable a device to receive SNMP: Syntax: manage snmp target-address create -a -tl -p -tm Example: manage snmp target-address create ManagePro -a 192.168.150.254-162 -tl v3Traps -p radware-authPriv -tm 255.255.255.0 4. To Enable Syslog: a. manage syslog status set 1 b. manage syslog server set 5. To Enable SMTP: a. First a user must be created with an email address and severity of the traps to send: Syntax:

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

- 86 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 86 -

manage user table create -pw -e -sv -sv can have one of the following values: (1) none (2) info (3) warning (4) error (5) fatal Example user with all traps Info and above manage user table create team# -pw team# -e team#@team#.com –sv 2 Note: If the user already exists use set instead of create. b. Second the SMTP Service needs to be configured: services smtp status set enable services smtp send-emails-on-error set enable services smtp main-smtp-address set services smtp own-addr set radware@team#.com Changing the SNMP community for SNMP v1 (See page 110 for SNMP v3) 6. To change the community use the following commands in sequence: manage snmp users create manage snmp groups create SNMPv1 -gn manage snmp access create SNMPv1 noAuthNoPriv -rvn iso -wvn iso -nvn iso manage snmp community create -n -sn In our Lab we will do the following: © Radware 2010. All rights reserved. Distribution of this document needs approval from Radware Knowledge & Education Services.

- 87 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 87 -

manage snmp users create Team# manage snmp groups create SNMPv1 Team# -gn V1 manage snmp access create V1 SNMPv1 noAuthNoPriv -rvn iso -wvn iso -nvn iso manage snmp community create 10 -n team# -sn Team# .

Interface Configuration: 7. In many circumstances you need to set the speed and duplex of the port. To change the Layer 2 status: a. Port Status: Net port up/down b. Force duplex/speed net physical-interface set -s -d -a Values for –s are: (1) Ethernet (2) Fast Ethernet (3) Giga Ethernet (4) XG Ethernet Example: Setting Interface 3 to 100/Full net physical-interface set 3 –s 2 –d Full –a off Saving and viewing the Configuration: 8. The configuration file can be saved CLI or Web based management. It is a little tricky to save the configuration in CLI (See Below).

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

- 88 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 88 -

9. To view the running configuration: system config immediate

Collect trouble-shooting information about the type of unit itself.

10. Use the following CLI commands to gather additional information about the device: system device-info Device Information ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Type:

LinkProof Application Switch

Platform:

PPC 7410 processor

Ports:

21

Ports Config:

16 Fast Ethernet + 5 Giga Ethernet

HW version:

1.10

SW version:

3.61.02

Build:

Feb 13 2003, 15:30:41

Version State:

Final

BWM version:

2.30.04 RAM size:

Flash size:

8 MB

Registered:

No

Date:

29.10.2002

Time:

16:34:59

Up time:

0 days, 1 hour, 1 minute, 23 seconds

Base MAC:

00:03:b2:0c:58:00

256 MB

system logfile Log file is empty

system os cpu

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

- 89 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 89 -

Device Resource Utilization ---------------------------RS Resource Utilzation : 0 RE Resource Utilzation : 0 Last 5 sec. Average Utilzation : 0 Last 60 sec. Average Utilzation : 0 Maximum Utilization

: 0

statistics ip ------------ IP Counters -----------ipInReceives

573

ipInHdrErrors

0

ipInAddrErrors

0

ipForwDatagrams

0

ipInUnknownProtos

0

ipInDiscards

0

ipInDelivers

563

ipOutRequests

543

ipOutDiscards

0

ipOutNoRoutes

0

ipReasmReqds

0

ipReasmOKs

0

ipReasmFails

0

ipFragOKs

0

ipFragFails

0

ipFragCreates

0

net arp table Arp Table Interface Index IP Address

MAC Address

Type

1

00e0987b5c08

dynamic

192.168.1.100

net l2-information Interface Table ifIndex

mac_addr

adm

1 0003b20c5800 up

oper

InUcastPkt InNUcastPkt OutUcastPkt OutNUcastPkt

up

4291523310

13

4291523310

14

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

- 90 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 90 -

2 0003b20c5801 up

up

3039383792

1103

3039383792

16

3 0003b20c5802 up

down

3236458074

0

3236458074

0

4 0003b20c5803 up

down

2878078969

0

2878078969

0

5 0003b20c5804 up

down

0

0

0

0

6 0003b20c5805 up

down

4050775923

0

4050775923

0

7 0003b20c5806 up

down

4225863528

0

4225863528

0

net l2-interface interface Table ───────────────────┬───────────────────┬───────────────────┬─────────────────── Interface Index

│MAC Address

│Interface Admin

│

│Status

│Operational Status │

───────────────────┼───────────────────┼───────────────────┼─────────────────── 1

│0003b2174540

│up

│up

│0003b2174541

│up

│up

│0003b2174542

│up

│down

│0003b2174543

│up

│down

│0003b2174544

│up

│down

│0003b2174545

│up

│down

│0003b2174546

│up

│down

│0003b2174547

│up

│down

───────────────────┼───────────────────┼───────────────────┼─────────────────── 2

───────────────────┼───────────────────┼───────────────────┼─────────────────── 3

───────────────────┼───────────────────┼───────────────────┼─────────────────── 4

───────────────────┼───────────────────┼───────────────────┼─────────────────── 5

───────────────────┼───────────────────┼───────────────────┼─────────────────── 6

───────────────────┼───────────────────┼───────────────────┼─────────────────── 7

───────────────────┼───────────────────┼───────────────────┼─────────────────── 8

net physical-interface Physical Interface Table

Port Index

Speed

Duplex

Auto Negotiate

1

Ethernet

Half

Off

2

Ethernet

Half

On

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

- 91 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 91 -

3

Ethernet

Half

On

4

Ethernet

Half

On

5

Ethernet

Half

On

6

Ethernet

Half

On

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

- 92 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 92 -

Bandwidth Management This component of Radware’ APSolute OS architecture requires an additional license for each device. The Bandwidth Management module extends comprehensive control over bandwidth resource allocation, to prioritize all network traffic and guarantee service levels for mission critical applications. Bandwidth management policies enable the classification of traffic by user, applications, and service pricing models for the configuration and full enforcement of premium services, and differentiating application performance by business requirements, while regulating site-wide bandwidth consumption and costs. Bandwidth Management offers a robust classification engine. Users may be differentiated between types of traffic according to any of the above parameters and to define the appropriate handing of the traffic class. This ensures that the quality of service and allocated bandwidth is appropriate for each identified type of traffic, ensuring that service is consistent and reliable. Functionality of the bandwidth management module includes •

Prioritizing traffic based on source IP, destination IP, addresses, and range of addresses, application, port, and content/URL.

•

Bandwidth limitation by source and destination IP addresses and groups of addresses, application, port, content/URL, and cookies.

•

Guaranteed bandwidth per class of traffic.

•

Bandwidth borrowing may be invoked when the allocated bandwidth for certain priority queues reaches its limit. In such cases, if bandwidth for other queues is not being utilized, it can be “borrowed” in order to alleviate potential bottlenecks during traffic bursts.

•

A combination of prioritization and bandwidth limitation can be assigned to each class of traffic, ensuring the optimal implementation of traffic policies.

•

Allows differentiating services for groups of users by content.

•

Dynamic priority setting through the session.

•

Diff-Serv support including fulfillment and honoring of an assigned priority.

•

Multiple scheduling dispatch mechanisms including Weighted Round Robin, Class Based Queuing and Random Early Drop ensure a flexible, configurable, and optimized scheduling mechanism. o

Weighted Round Robin (WRR) – This scheduling algorithm forwards packets from each queue according to its priority until bandwidth limitation

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

- 93 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 93 -

is met. It is most used when the user wants to tune bandwidth management according to the priority of each class. o

Class Based Queuing (CBQ) – According to CBQ algorithm, within each priority queue, packets are scheduled from each class of traffic ensuring that there is no starvation of any class. This ensures that all classes within the same priority queue evenly share the bandwidth and that bandwidth limitation and guarantees are met. This algorithm is more suitable for management by bandwidth limitations. Support for borrowing bandwidth between queues is built into the CBQ algorithm and ensures overall optimization of bandwidth usage. The user can specify which classes are entitled to borrow traffic and which classes can be borrowed from.

o

Random Early Drop (RED) – When queues overflow, this is mechanism randomly drops packets from lower priority queues. Because of the nature of the traffic, dropped packets are resent.

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

- 94 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 94 -

LinkProof Lab 9 – Bandwidth Management on the LinkProof (using CLI) Lab Goals:

•

•

Lab A – Bandwidth Management Setup

•

Lab B – Basic Block Policy

•

Lab C – Working with queues and bandwidth limits

•

Lab D – Advanced Bandwidth Management Policies

•

Lab E – Bandwidth per flow

Lab A – Bandwidth Management Setup

Lab Goals: •

Setting up Initial Bandwidth Management components.

•

Working with Classes a. Setting Up Networks b. Viewing Filters c. Port Groups

Note: It is difficult to generate enough traffic in a lab environment to saturate the bandwidth available. In order to illustrate the features detailed in this lab, the guaranteed minimum and borrowing bandwidth limits have been set artificially low

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

- 95 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 95 -

Step By Step:

1. Create several network entities following the guidelines below. Network Name

Network Mode

IP Address or From

Mask or To IP

LAN

Mask

192.168.0.0

255.255.0.0

LAN

IP Range

10.10.110.1

10.10.110.50

DNS

Mask

4.2.2.0

255.255.255.0

ISP 1

IP Range

1.1.1.20

1.1.1.254

ISP 2

IP Range

2.2.2.20

2.2.2.254

Classes modify network create Switches: -a -s -f -t -m

: : : : :

Address Mask From IP To IP Mode

In our case: classes modify network create LAN 0 -a 192.168.0.0 -s 255.255.0.0 -m "IP Mask" classes modify network create LAN 1 -f 10.10.110.1 -t 10.10.110.50 -m "IP Range" classes modify network create DNS 0 -a 4.2.2.0 -s 255.255.255.0 -m "IP Mask" classes modify network create ISP1 0 -a 1.1.1.20 -f 1.1.1.20 -t 1.1.1.254 -m "IP Range" classes modify network create ISP2 0 -f 2.2.2.20 -t 2.2.2.254 -m "IP Range"

2. Update the policies to activate the settings: bwm update-policies set 1

3. Once complete it should look like the following:

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

- 96 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 96 -

4. We create a physical port group named MyPorts using port 1-4. classes modify physical-port-groups create MyPorts 1 classes modify physical-port-groups create MyPorts 2 classes modify physical-port-groups create MyPorts 3 classes modify physical-port-groups create MyPorts 4 bwm update-policies set 1

5. Now we adapt the global BWM Parameters. Set the following parameters: a. RED = Global bwm global red-mode set global

b. Check Dynamic Borrowing bwm global dynamic-borrowing set enable

c. Set the SRP management IP address to 192.168.150.254 LP 6.x: statistics protocol management-ip set 192.168.150.254 LP 5.x: statistics reporting management-ip set 192.168.150.254 statistics protocol status set enabled

d. Enable ALL the reporting options bwm statistics reporting set true bwm statistics status set enabled

e. Reboot the device to activate the changes reboot

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

- 97 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 97 -

•

Lab B – Creating a Simple Block Policy in BWM

Lab Goals: •

Create a Bandwidth Management policy to block pings to the target server.

•

Test the policy.

Step By Step 1. Ping an external address to make sure you get a response for example 4.2.2.2. 2. Create a new policy to block outbound ping traffic. 3. Use the information below to create the policy: Policy Name

Block-Ping

Source

LAN

Destination

any

Direction

One Way

Action

Block

Service Type

Basic Filter

Service Name

icmp

Reporting

Report Block Packets

LP 6.x: bwm modify policy create Block-Ping -dst any -src LAN -ac Block dr "One Way" -pt "Basic Filter" -p icmp -rep "Report Blocked Packets" bwm modify policy-extensions set Block-Ping -cp "Before Changes" bwm update-policies set 1

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

- 98 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 98 -

LP 5.x: bwm modify policy create Block-Ping -dst any -src LAN -ac Block dr "One Way" -pt "filter" -p icmp -rbp 1 bwm global nat-handling dynamic-nat set "Local Address Classification" bwm global nat-handling static-nat set "Local Address Classification" bwm update-policies set 1

4. Try to ping the same address from step1 and it should now fail.

If you have the console connected you should also have a trap saying the session was blocked.

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

- 99 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 99 -

•

Lab C – Creating a simple minimum and maximum policy

Lab Goals: •

Create multiple policies using existing services.

•

Test the policy.

Step By Step: 1. Open up an HTTP session to some website and FTP sites to verify connection speed or gauge how fast the connections will load. 2. Create a policy for FTP traffic. Policy Name

FTP

Service Type

Regular Service

Service Name

ftp-session

Source

LAN

Destination

any

Direction

Two Way

Action

Forward

Priority

0

Maximum Bandwidth

100

Borrowing Limit or Maximal Bandwidth

150

LP 6.x: bwm modify policy create FTP -dst any -src LAN -pr 0 -gbw 100 -pt "Basic Filter" -p ftp-session -mbw 150 bwm modify policy-extensions set FTP -cp "Before Changes" LP 5.x: bwm modify policy create FTP -dst any -src LAN -pr 0 -gbw 100 -pt "filter" -p ftp-session -bl 150

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

- 100 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 100 -

3. Add a second entry for HTTP, with the following parameters: Policy Name

HTTP

Service Type

Regular Service

Service Name

HTTP

Source

LAN

Destination

any

Direction

Two Way

Action

Forward

Priority

1

Guaranteed Bandwidth

100

Borrowing Limit or Maximal Bandwidth

150

LP 6.x: bwm modify policy create HTTP -dst any -src LAN -pr 0 -gbw 100 -pt "Basic Filter" -p http -mbw 150 bwm modify policy-extensions set HTTP -cp "Before Changes" LP 5.x: bwm modify policy create HTTP -dst any -src LAN -pr 0 -gbw 100 -pt "filter" -p http -bl 150

4. Now we have to Update Active Policies bwm update-policies set 1

5. To verify if the policy is configured correctly issue bwm active policy

And you should see these new policies in the list.

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

- 101 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 101 -

6. From your Client, FTP to a site and download a file, also go to various web pages for about 2 minutes. 7. Issue the following command during this period to monitor the bandwidth policies. bwm monitor policy-bandwidth

8. Stop the FTP session. 9. If time permits, repeat this lab using other guaranteed and maximal values to see the different behavior. End of Radware LinkProof Training Thank you

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

- 102 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 102 -

Web Based Management Lab Steps The following information provides details on how to configure each lab using the Web interface. Note that screen shots based on version 5.22 and only provide examples of what the configuration should look like on a single device in many cases. In version 6.x the Web Based Management is looking different, but you have the same menu structure. The Web Based Management (WBM) section describes only the configuration steps. For more details go to the corresponding chapter of the CLI configuration above.

WBM Chapter 2 – Farm Configuration for the LinkProof •

LinkProof Lab 2 – Creating a Farm and adding NHRs (using WBM)

Lab Goals: •

Configure the next hop routers

•

Enable Smart NAT

•

Review various parameters and settings available for devices

Step by Step: Creating a basic NHR Farm: 1. First browse to your LinkProof and put in your user name and password to get to the main menu. 2. The first step to working with NHRs is to create the farm, use the following command to create a basic farm: LinkProof  Farms  Farm Table, click Create and fill in the following: a. Farm Name = mainfarm b. NAT Mode = Enable

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

- 103 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 103 -

c. Persistency Mode = Client Table d. Click Set to save the changes.

3. 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). 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. 4. To add the NHRs to the farms created above with default parameters do the following: LinkProof  Servers  Logical Routers Table, click Create. a. Farm Name = mainfarm b. Router Name = ISP1 c. IP Address = 1.1.1.100 d. Click Set to save the information, then Create the second ISP e. Farm Name = mainfarm f. Router Name = ISP2 g. IP Address = 2.2.2.200 h. Click Set to save and you should have two routers in the table.

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

- 104 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 104 -

5. 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 a later lab. 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. 6. 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). ISP1 = 1.1.1.10# ISP2 = 2.2.2.10# Use the following command to add the NAT entries to the LP. LinkProof  Smart NAT  Dynamic NAT Table, click Create ISP1 a. From Local IP = 0.0.0.1 b. To Local IP = 255.255.255.254 c. Server IP = 1.1.1.100

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

- 105 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 105 -

d. Dynamic NAT IP = 1.1.1.10# e. Click Set to save the changes and click Create for the second entry. ISP2 f. From Local IP = 0.0.0.1 g. To Local IP = 255.255.255.254 h. Server IP = 2.2.2.200 i.

Dynamic NAT IP = 2.2.2.10#

j. Click Set to save the changes

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

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

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

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

Team2 Team10 Team11

You can always get a summary of all the NAT addresses in use with: LinkProof  Smart NAT  NAT Parameter Summary

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

- 106 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 106 -

7. Make certain that your Virtual Appliance gateways are set to the internal interface of the LinkProof (See Pre-configuration) 8. Open browser sessions from your Virtual Appliance Session to external hosts, if available and you should be able to connect. 9. View the connection table on the LinkProof CLI to see the active connections lp client table You should see something like the following:

Figure 19 – Client Table

Changing the Dispatch Method:

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

- 107 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 107 -

10. 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. LinkProof  Farms  Farm Table, click on mainfarm Change Client Aging Time to 20 and click Set. 11. Now find a simple website that opens few connections for example: http://www.igga.org, 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. 12. Change the dispatch method to Least Amount of traffic: LinkProof  Farms  Farm Table, click on mainfarm Change Dispatch Method to Least Amount of Traffic and click Set. 13. Test the new method by browsing to some websites and observe what happens in the client table. (Hint the majority of connections should end up on ISP1) 14. Change the Dispatch Method to Fewest Number of Users. Test this new method as above and observe the client table. Viewing and Saving the Configuration File: 15. 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 16. 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

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

- 108 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 108 -

Keep the Configuration Type as Regular and hit the Set button to save the configuration to the desktop. You can re-name the configuration file if you like.

End of Lab 2 Please continue with Lab 3. •

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?

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

- 109 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 109 -

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. •

LinkProof Lab 3a – Device Management for LinkProof (using WBM)

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: LinkProof  Servers  Logical Routers Table, click on the link next to ISP 2. Change OperMode to Backup, and click Set to save. 2) Change the Farm global aging time to 45 seconds: LinkProof  Farms  Farm Table, click on mainfarm Change Client Aging Time to 45 and click Set to save. 3) Browse to the internet and make sure you have client table entries all going to ISP1:

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

- 110 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 110 -

lp client table 4) Set the first ISP to shutdown mode: LinkProof  Servers  Physical Servers Table, click on ISP1. Change the Admin Status to Shutdown, click Set to save. Wait to see a trap in the CLI that the ISP is ready for shutdown (you may not get the trap if there is no traffic on ISP1. 5) Change both ISP1 and ISP2 back to their normal modes: ISP 2 set back to Regular and ISP 1 set back to Enabled. LinkProof  Servers  Physical Servers Table, click on ISP1. Change the Admin Status to Enable, click Set to save. LinkProof  Servers  Logical Routers Table, click on the link next to ISP 2. Change OperMode to Regular, and click Set to save.

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 would ignore this timer. 6) Setting the Recovery Time on the ISPs to 60 seconds: LinkProof  Servers  Physical Servers Table, click on ISP1. Change the Recovery Time to 60, click Set to save. LinkProof  Servers  Physical Servers Table, click on ISP2. Change the Recovery Time to 60, click Set to save. Aging By Port:

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

- 111 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 111 -

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 Farm Client Aging Time. LinkProof  Global Configuration  Client Table  Aging By Application Port, click Create HTTP: Application Port = 80 Aging Time = 15 Click Set to Save, click Create for the DNS DNS Application Port = 53 Aging Time = 5 9) Using the Virtual Appliance, 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.

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 then click Set. A small pop-up window will appear, prompting you to reboot. If a pop-up blocker keeps the window from opening, then go to DeviceReset Device and click the Set button.

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

- 112 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 112 -

•

LinkProof Lab 3b – Connectivity checks and Health Monitoring (using WBM)

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: 6) Change a few of the settings for connectivity checks: a) Change the Connectivity Check Interval from 10 to 5. This setting instructs the LinkProof to check each NHR once every 5 seconds. b) Change the Connectivity Check Retries from 5 to 3. This setting means that a NHR can fail three consecutive health checks before the LinkProof will confirm that it is unavailable and will no longer load-balance traffic to it. LinkProof  Farms  Farm Table, click on mainfarm. Change Connectivity Check Interval to 5 Change Connectivity Check Retries to 3 Click Set to save. 7) 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. LinkProof  Servers  Full Path Health Monitor Table, click on Create. a) Farm Name = mainfarm b) Server Name = ISP1 c) Check Address = 192.168.150.100 d) Click Set then Create to create one for ISP2 e) Farm Name = mainfarm

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

- 113 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 113 -

f) Server Name = ISP2 g) Check Address = 192.168.150.100 h) Click Set to save and you should have the following table:

8) Ask your instructor to unplug the external connection (Or disable it) from one of the Routers. 9) Type in “lp servers router-servers get” in the CLI and repeat a few times until one of the routers shows “not in service”-- or click on the Green Refresh button in the top right of the Web Based Management screen until one of the routers shows “not in service” 10) Plug the connections for the router back in before continuing to the next lab.

Health Monitoring Lab Health Monitoring Mandatory Checks:

7) To use health monitoring connectivity checks must be turned off on each farm LinkProof  Farms  Farm Table, click on mainfarm. Change Connectivity Check Status to Health Monitoring Click Set to save 8) The next step enable is to enable Health Monitoring: Health Monitoring  Global Parameters Change Health Monitoring Status to Enable Click Set to save.

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

- 114 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 114 -

9) Once Health Monitoring is turned on the next step is to create the actual health checks, we will start with basic checks of Ping and ARP for this part of the lab. To create the first check: Health Monitoring  Checks Table, click Create a) b) c) d) e) f) g)

Check Name = ISP1-ARP-Inside Method = ARP Dest. Host = 1.1.1.100 Interval = 5 Retries = 2 Timout = 3 Click Set

10) Now we will create an additional 3 checks 1 ARP to ISP 2 and two pings tests to the outside: ARP ISP2 a) Check Name = ISP2-ARP-Inside b) Method = ARP c) Dest. Host = 2.2.2.200 d) Interval = 5 e) Retries = 2 f) Timout = 3 g) Click Set Ping ISP 1 h) Check Name = ISP1-Ping-Outside i) Method = Ping j) Dest. Host = 192.168.150.100 k) Next Hop = 1.1.1.100 l) Interval = 5 m) Retries = 2 n) Timout = 3 © Radware 2010. All rights reserved. Distribution of this document needs approval from Radware Knowledge & Education Services.

- 115 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 115 -

o) Click Set Ping ISP 2 p) Check Name = ISP2-Ping-Outside q) Method = Ping r) Dest. Host = 192.168.150.100 s) Next Hop = 2.2.2.200 t) Interval = 5 u) Retries = 2 v) Timout = 3 w) Click Set

Note: If they do not all say pass, click on the refresh button in the right hand side of the screen 11) 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 when a check fails. Health Monitoring  Binding Table, click Create. ISP1-ARP a) b) c) d)

Check = ISP1-ARP-Inside Server= NHR: mainfarm/ISP1 Group = 1 Click Set to save

ISP2-ARP e) Check = ISP2-ARP-Inside f) Server= NHR: mainfarm/ISP2 g) Group = 1

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

- 116 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 116 -

h) Click Set to save ISP1-Ping i) Check = ISP1-Ping-Outside j) Server= NHR: mainfarm/ISP1 k) Group = 1 l) Click Set to save ISP2-Ping m) Check = ISP2-Ping-Outside n) Server= NHR: mainfarm/ISP2 o) Group = 1 p) Click Set to save

12) Once you are configured ask your instructor to take down the outside interface of one of your routers, you should see it fail the check after a few seconds. •

Have your instructor bring the NHR back online before proceeding.

Health Monitoring Non-Mandatory Checks: 9) Remove all the health checks form the binding table. Health Monitoring  Binding Table Click on the box under the X column and click Delete. 10) Create 4 DNS checks going out 2 for each ISP.

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

- 117 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 117 -

Health Monitoring  Checks Table, click Create DNS to Yahoo ISP 1 a) Check Name = ISP1-DNS-Yahoo b) Method = DNS c) Dest. IP = 4.2.2.2 d) Next Hop = 1.1.1.100 e) Destination Port = 53 f) Interval = 5 g) Retries = 2 h) Timout = 3 i) Arguments = HOST=www.yahoo.com| Note: you can also click on the … next to Arguments and put in the Host Name j) Click Set then click Create for the next one DNS to Google ISP 1 k) Check Name = ISP1-DNS-Google l) Method = DNS m) Dest. IP = 4.2.2.3 n) Next Hop = 1.1.1.100 o) Destination Port = 53 p) Interval = 5 q) Retries = 2 r) Timout = 3 s) Arguments = HOST=www.google.com| Note: you can also click on the … next to Arguments and put in the Host Name t) Click Set then click Create for the next one DNS to Yahoo ISP 2 u) Check Name = ISP1-DNS-Yahoo v) Method = DNS w) Dest. IP = 4.2.2.2 x) Next Hop = 2.2.2.200 y) Destination Port = 53 z) Interval = 5 aa) Retries = 2 bb) Timout = 3 cc) Arguments = HOST=www.yahoo.com|

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

- 118 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 118 -

Note: you can also click on the … next to Arguments and put in the Host Name dd) Click Set then click Create for the next one DNS to Google ISP 2 ee) Check Name = ISP1-DNS-Google ff) Method = DNS gg) Dest. IP = 4.2.2.3 hh) Next Hop = 2.2.2.200 ii) Destination Port = 53 jj) Retries = 2 kk) Arguments = HOST=www.google.com| Note: you can also click on the … next to Arguments and put in the Host Name ll) Click Set

11) The next step is to bind the checks to the NHRs the syntax is as follows: Health Monitoring  Binding Table, click Create ISP 1 Check = ISP1-DNS-Yahoo Server = NHR: mainfarm/ISP1 Group = 1 Mandatory = Non-Mandatory Click Set to save and Create for the next entry Check = ISP1-DNS-Google

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

- 119 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 119 -

Server = NHR: mainfarm/ISP1 Group = 1 Mandatory = Non-Mandatory Click Set to save and Create for the next entry ISP 2 Check = ISP2-DNS-Yahoo Server = NHR: mainfarm/ISP2 Group = 1 Mandatory = Non-Mandatory Click Set to save and Create for the next entry Check = ISP2-DNS-Google Server = NHR: mainfarm/ISP2 Group = 1 Mandatory = Non-Mandatory Click Set to save

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

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?

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

- 120 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 120 -

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?

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

- 121 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 121 -

Chapter 4 – Flow Policies •

LinkProof Lab 4 – Flow Policies (using WBM)

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 Farm Creation: LinkProof  Farms  Farm Table, click Create Set the following Parameters: Farm Name = Farm-ISP1 Nat Mode = Enable Click Set to save and Create to add a second Farm. Farm Name = Farm-ISP2 Packet Translation = NAT Click Set to save.

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

- 122 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 122 -

Adding Routers: LinkProof  Servers  Logical Routers Table, click Create. Farm Name = Farm-ISP1 Router Name = ISP1 IP Address = 1.1.1.100 Click Set to save and click Create to add the next one Farm Name = Farm-ISP1 Router Name = ISP2 IP Address = 2.2.2.200 OperMode = Backup Click Set to save and click Create to add the next one Farm Name = Farm-ISP2 Router Name = ISP2 IP Address = 2.2.2.200 Click Set to save and click Create to add the next one Farm Name = Farm-ISP2 Router Name = ISP1 IP Address = 1.1.1.100 OperMode = Backup Click Set to save

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

- 123 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 123 -

Setting up Networks: 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 Classes  Modify  Networks, click Create Name = Internal Sub Index = 1 Mode = IP Range From IP = 192.168.200.1 To IP = 192.168.200.254 Click Set to save and click Create to add the next entry. Name = DNS-IP Sub Index = 2 Mode = IP Range From IP = 4.2.2.2 To IP = 4.2.2.3 Click Set to save and click Create to add the next entry.

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

- 124 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 124 -

Name = Outside Sub Index = 3 Mode = IP Mask Address = 198.6.1.0 Mask = 255.255.255.0 Click Set to save and click Create to add the next entry. Name = DNS-Net Sub Index = 3 Mode = IP Mask Address = 198.6.1.0 Mask = 255.255.255.0 Click Set to save. The last step is to update the information Use the following to save these updates: Classes  Update Policies click Set Verify that the networks are now active: Classes  View Active Networks.

Flow Policies for Networks: 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 © Radware 2010. All rights reserved. Distribution of this document needs approval from Radware Knowledge & Education Services.

- 125 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 125 -

subnet only to go out one of the available routers. Or another customer may want web traffic to go out a single router. 12) 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. LinkProof  Flow Management  Farms Flow Table, click Create. Flow Name = ISP1 (Type this in) Farm Name = Farm-ISP1 Click Set to save and Create to add a second entry. Flow Name = ISP2 Farm Name = Farm-ISP2 Click Set to save

Once complete it should look like the following:

Important note: The Default Flow can not be removed and although it says no farm it means it goes to the default farm. The default farm is the first farm that was created with a NHR that was a default gateway. 13) Create the following flow to force all traffic going to the DNS IPs out ISP 1 LinkProof  Flow Management  Modify Policies, click Create. Name = Outbound DNS Destination = DNS-IP Source = Inside

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

- 126 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 126 -

Farm Flow = ISP1 Click Set to save and then click Create to add a second policy. 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. Name = Outbound Traffic Index = 2 Destination = any Source = Inside Direction = Two Way Farm Flow = ISP2 Click Set to save 14) The last step is to activate the polices, use the command: LinkProof  Flow Management  Update Policies, click Set 15) Test the policy by browsing out and seeing the results in the client table. Then fail one router and see that everything fails over to a single ISP. 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. 16) To Delete a Policy: LinkProof  Flow Management  Modify Policies Click on a box next to the policy you want to delete and then click Delete. The last part is to updated the active policies: LinkProof  Flow Management  Update Policies, click Set 17) Next we will create two new policies one for DNS and another for HTTP, this time we will add a new flag for an application:

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

- 127 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 127 -

LinkProof  Flow Management  Modify Policies, click Create. Name = DNS Destination = any Source = Inside Direction = Two Way Service Type = Basic Filter Service = dns Farm Flow = ISP2 Click Set to save and then click Create to add a second policy. Name = HTTP Index = 2 Destination = any Source = Inside Direction = Two Way Service Type = Basic Filter Service = http Farm Flow = ISP1 Click Set to save You should have a table like the following:

18) To activate the new policies LinkProof  Flow Management  Update Policies, click Set 19) Now we can test the policy. From the browser on your VNC Connection, 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

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

- 128 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 128 -

Practical Exercise for Chapter 4: 20) 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. 21) Restore the configuration from Lab 2 before going on to the next lab. . 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 client’s entry is removed from the table and the client resumes traffic to the same destination host?

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

- 129 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 129 -

LinkProof Practical Exercise #1 (optional) 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

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

- 130 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 130 -

Chapter 5 – LinkProof Inbound Load-Balancing •

LinkProof Lab 5 – Inbound Load Balancing and Proximity (using WBM)

Lab Goals: • • •

Configure the LinkProof to perform inbound load balancing Test using a DNS lookup utility Configure the LinkProof to perform Proximity calculations

Use the configuration from the previous labs. Step by Step: Static NAT 1. The first step for inbound is to create static Smart NAT addresses to represent an internal server behind your LinkProofs. You will create two external addresses for this server, one from each Router network space. LinkProof  Smart NAT  Static NAT Table, click Create: (# Is your team number) From Local Server IP = 192.168.200.10# To Local Server IP = 192.168.200.10# Server IP = 1.1.1.100 From Static NAT IP = 1.1.1.20# To Static NAT IP = 1.1.1.20# Click Set to save and Create to add the second entry. From Local Server IP = 192.168.200.10# To Local Server IP = 192.168.200.10# Server IP = 2.2.2.200

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

- 131 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 131 -

From Static NAT IP = 2.2.2.20# To Static NAT IP = 2.2.2.20# Click Set to save.

Notes: Internal Range = Range of internal server IPs that you want to define a public IP for, if you have only one server the Start and End have to be the same IP. Eternal Range = Range of Public IPs for the Internal Range, the external range maps one to one in sequence for example: 192.168.200.101 192.168.200.105 1.1.1.100(NHR) 1.1.1.31 1.1.1.35 This means 101 = 31, 102 = 32 and so on. 2. When complete, you can check your NAT table: (It should have 4 entries-- the 2 Dynamic NAT and the two new Static NAT entries) LinkProof  Smart NAT  NAT Parameter Summary:

3. Once done, browse out from your VNC remote desktop and notice in the client table you are going out with the Static NAT. DNS Configuration

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

- 132 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 132 -

4. The next step in inbound configuration is the DNS configuration. There are two main parts of this configuration. The first part is th Name To Local IP table -- this table contains all the host names that the LinkProof will resolve and their Local IP address. The Local IP address needs to be the same as the Local Address in the Static NAT configuration. LinkProof  DNS Configuration  Name to Local IP, click Create Host Name = www.team#.com Local IP = 192.168.200.10# Click Set to save

5. The next part is the DNS Virtual IP, this IP address is used as the NS record on the SOA DNS server, the best practice is to configure one DNS VIP per ISP, and to also have one on the internal interface (We will explain that one with redundancy). In Our Lab we will use the do the following (50+# means add your team number to 50): LinkProof  DNS Configuration  DNS Virtual IP, click Create. DNS IP Address = 1.1.1.50+# Click Set to save and Create to add another DNS IP Address = 2.2.2.50+# Click Set to save

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

- 133 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 133 -

6. The last step is to enable the two records in reply feature, this can be used to avoid DNS caching issues and to give clients an alternate address. This feature is also useful in the lab to demonstrate failover. In addition it is recommended to change the TTL from default of zero to at least 5 seconds up to 30 seconds. LinkProof  DNS Configuration  Response: DNS Response TTL = 5 Two Records in DNS Reply = enable Click Set to save changes. 7. To test the response, from the Virtual Client use a terminal and the host command type in nslookup www.team#.com 192.168.200.# 8. At this point you can now fail one of the two ISPs (Disable it) and run the lookup again you should now only get one A record back. Optional Components Proximity: Note: Proximity is difficult to simulate in the lab since the difference in hops and latency is minimal. This lab is designed to illustrate the principals behind proximity. 9. The first step is to enable proximity on the LinkProof, there are a few options you can enable it only for Inbound or Outbound traffic, or enable it both ways, in our lab we will enable both ways. LinkProof  Proximity  Proximity Parameters  General

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

- 134 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 134 -

Change Proximity Mode = Full Proximity Both Click Set to save 10. The next step is to choose the importance of three variables Hops, Latency, and Load. Depending on the desired result or the network you can modify what is more important then the other on a scale of 1  100 with 100 being highest. LinkProof  Load Balancing Weights Hops Weight = 60 Latency Weight = 20 Load Weight = 80 Click Set to save. 11. Open browser connections to various sites from your Virtual Machine (If you changed the IP before change it back to 192.168.200.10#). Connect to the LinkProof through the CLI and type in the following command: lp proximity dynamic-table This will display the LinkProof’s dynamic proximity table: Subnet

Farm name

Server 1

Latency 1

Hops 1

Server 2

Latency 2

Hops 2

Server 3

Latency 3

Hops 3

......................................... 64.236. 16.

0

MainFarm

Hits counter 0 1.

1.

1.100

65

213

2.

2.

2.200

85

213

69. 44.123.

0

MainFarm

Hits counter 0 1.

1.

1.100

25

202

2.

2.

2.200

35

202

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

- 135 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 135 -

•

Chapter 5 Review:

What system does the LinkProof rely on for redirecting external clients to internal hosts through various next hop routers? What kind of records should be placed in a customer’s DNS server to redirect DNS queries to the LinkProof? What are Virtual DNS Addresses used for? What actual addresses should be placed in a customer’s DNS server to redirect DNS queries to the LinkProof? What features can the LinkProof use to help overcome DNS lookup caching? True or False: If a Next Hop Router is down, the LinkProof will not respond to incoming DNS queries by giving out an address that belongs to the failed router? In general terms, what is Proximity on the LinkProof? The LinkProof calculates outbound proximity to what devices? The LinkProof calculates inbound proximity to what devices? How does the LinkProof store entries in the Proximity Table? When configuring proximity, what three factors can be tuned to determine the “best” NHR to use? Why would load be an important factor to consider? By default, how long are entries stored in the proximity table on the LP?

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

- 136 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 136 -

Chapter 6 LinkProof Redundancy Radware recommends that its LinkProof units be installed in pairs to provide fault tolerance in the case of a single unit's failure. Each pair of devices functions in an Active / Backup configuration; the backup unit will come online should the primary unit fail.

LinkProof Lab 6 – VRRP Redundancy Lab Goals: • •

Configure a pair of LinkProofs in an Active / Backup Configuration using the VRRP Redundancy method Test Failover by disconnecting the Active device

Note: For this lab you will partner with another team, however there is very little that needs to be changed on the backup device, almost all the configuration is on the primary. Pre-Configuration: MASTER device only: On the MASTER device we will remove the 192.168.200.# interface, as stated above we want to change the default gateway of the internal network to a DNS VIP. From the CLI net ip del 192.168.200.# Now add a new IP Router  IP Router  Interface Parameters, click Create. IP Address = 192.168.200.20# Network Mask = 255.255.255.0 If Number = 2 Click Set to save.

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

- 137 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 137 -

The last step is create the DNS VIP as the default gateway LinkProof  DNS Configuration  DNS Virtual IP, click Create. DNS IP Address = 192.168.200.# Click Set to save You can now reach the internet from your Virtual Desktop as you did before. Redundancy Configuration MASTER device (# is your team number): 15) Configure the peer (Backup LinkProof’s) IP’s on the LinkProof. Router  IP Router  Interface Parameters Click on each entry and add the Backup LinkProof’s corresponding IP address in the Peer Address field and hit Set to save the changes. Repeat this for all the entries in the Interface Parameters table.

16) Next, set a few global options first including enabling VRRP. Redundancy  Global Configuration IP Redundancy Admin Status = VRRP Interface Grouping = Enable Trap VRRP Associated Addresses = Summary

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

- 138 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 138 -

Click Set to save changes

17) Now create the VRs. We will create a VR per network the LinkProof is on with the exception of the management network (10.10.243.x) Redundancy  VRRP  VR Table, click Create VR ID = A number from 1  255, you have to make sure the number is unique on the network to the Radware devices. Priority = Priority a value from 1  255 with 255 being the highest and absolute master for a VR. Primary IP = Interface IP, this is the IP that is configured on the physical interface that reflects what network the VR belongs to (For example VR ID of 111 will be on the 192.168.200.x network). First Entry If Index = G-2 VR ID = #0 Priority = 254 Primary IP = 192.168.200.20# (or leave as 0.0.0.0) Click Set to save and click Create to add another entry.

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

- 139 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 139 -

Second Entry If Index =G-1 VR ID = #1 Priority = 254 Primary IP = 1.1.1.# Click Set to save and click Create to add another entry. Third Entry If Index = G-1 VR ID = #2 Priority = 254 Primary IP = 2.2.2.# Click Set to save and you should have three entries

Note: The VRs are supposed to be down. Until you associate IPs to the VRs you cannot enable them. 18) Once the VRs are created we can associate all the IPs to these VRs. We need to associate ALL Smart NAT IPs and ALL DNS VIPs Redundancy  VRRP  Associated IP Address, click Create Remember to click Set after each one. If Index

VR ID

Associated IP

G-2

#0

192.168.200.#

G-1

#1

1.1.1.10#

G-1

#2

2.2.2.10#

G-1

#1

1.1.1.20#

G-1

#2

2.2.2.20#

G-1

#1

1.1.1.50+#

Description DNS VIP on Port 1 Dynamic NAT IPs Static NAT IPs DNS Virtual IPs

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

- 140 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 140 -

G-1

#2

2.2.2.50+#

19) At this point we are ready to enable the virtual routers on the Master device. Redundancy  VRRP  VR Table, click on each VR ID Change the Admin Status to Up, then click Set, once all three are done click on the Yellow Refresh button in the top right. All the VRs should be Master.

20) The last step on the primary device is to exclude the management port from interface grouping. NOTE: On the ODS hardware platform the Management Ports are excluded by default. When using other platforms, use the step below to exclude a port. Redundancy  Master Interface Grouping Table, click on the management port and change Port Status to Excluded, then click Set to save. 21) The only thing that is needed on the backup devices is an interface IP for management. If the Backup team already has a configuration on their LinkProof, there is nothing further to configure on the Backup Linkproof. 22) Go to File  Configuration  Receive from Device. Choose Backup (ActiveBackup) and press the Set button. Change the name of the file so that you can recognize it as the backup redundancy configuration and save it to the remote desktop. . 23) Browse to the Backup linkproof at http://10.10.243.X. Go to File Configuration  Send to Device on the Backup linkproof and choose Replace configuration file as the Upload mode. Press the Set button and press the Set button on the popup message to reset the backup LinkProof (If you don’t see the pop-up message, go to

Device  Reset Device in order to reboot the backup LinkProof).

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

- 141 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 141 -

24) On the BACKUP device do the following: Redundancy  VRRP  VR Table, click on each VR ID Change the Admin Status to Up, then click Set, once all three are done click on the Yellow Refresh button in the top right. All the VRs should be Backup At this point the backup up is now configured to take over in the event of the master device failing. We will simulate a failover in the class we will take down one of the interfaces of the primary unit. 25) From the Virtual Desktop, ping an outside address continuously (4.2.2.2 for example) and ping the default gateway 192.168.200.# 26) On the Master device use the following command to force failover: net port down 1 27) On the Backup you should see messages that it has taken over and the Pings should still be working, with maybe 1 missed ping. LinkProof#19-09-2008 17:03:03 INFO VRRP: now master of VR ID 12 28) Fail back to the Master: net port up 1

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

- 142 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 142 -

Chapter 6 Review Questions: True or False - Generally speaking, a backup LinkProof should be configured identically to its active partner. What settings are different on a backup device than on an active device? What is Mirroring and what is it designed to accomplish? What is Interface Grouping and should it be enabled on an Active or Backup Unit? True or False: when a backup device takes over for an active device, entries in the IP Redundancy Table on a Backup device should have an Operating Status of “InActive” How can you verify that a backup LinkProof has taken over for a failed active LinkProof? What does VRRP stand for? What are VRs? What are Associated IP Addresses? How does a backup device monitor the status of an active device using VRRP? What is different about VRRP from the Proprietary redundancy method? What setting determines which device is master in an Active/Backup VRRP configuration? What should you do before implementing VRRP on a pair of LinkProof in an existing network? If you have four physical interfaces with 8 different networks in use on a pair of LinkProofs, at least how many VRs would you need to configure on each unit?

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

- 143 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 143 -

Chapter 7 One IP Configuration In some cases when installing the LinkProof there is only one IP available or a customer wants to only use a single IP for multiple servers accepting inbound traffic. One IP configuration has two main parts Outbound Dynamic NAT Inbound Static PAT For outbound Dynamic NAT the physical interface IP can also be used as the Dynamic NAT IP thus there is no need to configure another IP address for Dynamic NAT. Inbound Static PAT allows a user to configure the LinkProof to accept traffic for multiple backend systems on a single external IP. For example a network might have a resource server on HTTP and an email server on port 25, they can now use the same external IP address for both systems. This feature can be combined with the Outbound NAT to use a single IP for all inbound and outbound traffic or it can be used on its own without the one IP configuration. •

LinkProof Lab 7 – One IP Configuration (using WBM)

Lab Goals: •

Configure the LinkProof to only use its interface for outbound dynamic NAT

•

Configure inbound SPAT

•

One IP can only be configured from the CLI or WBM

Step-by-Step

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

- 144 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 144 -

NOTE: Single IP configuration and redundancy are not fully supported at this time please be aware that this configuration is for locations were a redundant LinkProof will not be used or is not needed. 7) Restore the configuration saved at the end of Lab 2 8) Enable the two external Interface IPs for 1 IP use the following command: Router  IP Router  Interface Parameters click on 1.1.1.# One IP = Enable Click Set then click on 2.2.2.# One IP = Enable Click Set to save 9) Delete the previously configured dynamic NAT (In Lab 2) and you will create a new dynamic NAT using the IP of the interface: LinkProof  Smart NAT  Dynamic NAT Table, select both NAT addresses and click Delete. 10) Create a new Dynamic NAT to the interface IP (Where # is your team number) ISP1 a. From Local IP = 0.0.0.1 b. To Local IP = 255.255.255.254 c. Server IP = 1.1.1.100 d. Dynamic NAT IP = 1.1.1.# e. Click Set to save the changes and click Create for the second entry. ISP2 f. From Local IP = 0.0.0.1 g. To Local IP = 255.255.255.254 h. Server IP = 2.2.2.200 i.

Dynamic NAT IP = 2.2.2.#

j. Click Set to save the changes © Radware 2010. All rights reserved. Distribution of this document needs approval from Radware Knowledge & Education Services.

- 145 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 145 -

11) Create a SPAT for a web server and email server: a) First you have to change the web based management port Services  Web Server  Web Web Server Port = 8080 Click Set to save. b) Then configure the Static NAT LinkProof  Smart NAT  Static PAT Table, click Create Web ISP1 i) Internal IP = 192.168.200.10# ii) Internal Port = 80 iii) Protocol = tcp iv) Server IP = 1.1.1.100 v) External IP = 1.1.1.# vi) Eternal Port = 80 vii) Static PAT Name = WebISP1 Click Set to save then click Create to add another entry Web ISP2 viii) Internal IP = 192.168.200.10# ix) Internal Port = 80 x) Protocol = tcp xi) Server IP = 2.2.2.200 xii) External IP = 2.2.2.# xiii) Eternal Port = 80 xiv) Static PAT Name = WebISP2 Click Set to save then click Create to add another entry Email ISP1 xv) Internal IP = 192.168.200.10# © Radware 2010. All rights reserved. Distribution of this document needs approval from Radware Knowledge & Education Services.

- 146 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 146 -

xvi) Internal Port = 25 xvii)

Protocol = tcp

xviii)

Server IP = 1.1.1.100

xix) External IP = 1.1.1.# xx) Eternal Port = 25 xxi) Static PAT Name = EmailISP1 Click Set to save then click Create to add another entry Email ISP2 xxii)

Internal IP = 192.168.200.10#

xxiii)

Internal Port = 25

xxiv)

Protocol = tcp

xxv)

Server IP = 2.2.2.200

xxvi)

External IP = 2.2.2.#

xxvii) Eternal Port = 25 xxviii) Static PAT Name = EmailISP2 Click Set to save then click Create to add another entry 12) Test Outbound Traffic, and if you have a web service running on your Virtual Appliance you can test it from the outside. End of Lab 7 Please wait for your Instructor before Continuing

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

- 147 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 147 -

LinkProof Management LinkProof Lab 8 – Managing the LinkProof (using WBM) Lab Goals: •

Enable and configure various options related to managing the AppDirector itself

Step By Step: Enabling Management Traffic: To Enable web and secure web based management access Go to Services  Web Server  Web:

Figure 20 - Web Based Management Configuration

Go to Services  Web Server  Secure Web:

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

- 148 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 148 -

Figure 21 - Secure Web Management Configuration

To enable telnet and SSH Go to Services  Telnet

Figure 22 - Telnet Access Parameters

Go to Services  SSH  Server:

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

- 149 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 149 -

Figure 23 - SSH Access Parameters

Disabling Management Traffic by port (Default All Ports Enabled):

Go to Security  Management Ports. Selecting a specific port, and enable or disable management methods to the device through that port:

Figure 24 - Example of Port Restrictions

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

- 150 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 150 -

Enabling Different Traps Outputs: There are three different systems that can be configured to receive event traps from the device; SNMP, SYSLOG, SMTP. Each one will be discussed. To configure syslog notification 1. Go to Services  Syslog Reporting, and configure the appropriate information. Any traps generated by the Radware device will be mirrored to the syslog server specified:

Figure 25 - Syslog Reporting Configuration Window

To Configure email notification First a user must be created with an email address and severity of the traps to send:

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

- 151 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 151 -

Device Security  Users, either create a new user or edit an existing user.

Severity can have one of the following values: (1) none (2) info (3) warning (4) error (5) fatal Email Address must be put in and Severity has to be info or above. To configure the email sever go to Services  SMTP

To configure SNMP notification To enable SNMP notification a system has to be configured to receive SNMP traps.

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

- 152 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 152 -

Security  SNMP  Target Address Table, click Create.

Changing the SNMP community for SNMP v1 (See page 110 for SNMP v3) 11. To change the community use the following commands in sequence: manage snmp users create manage snmp groups create SNMPv1 -gn manage snmp access create SNMPv1 noAuthNoPriv -rvn iso -wvn iso -nvn iso manage snmp community create -n -sn In our Lab we will do the following: manage snmp users create Team# manage snmp groups create SNMPv1 Team# -gn V1 manage snmp access create V1 SNMPv1 noAuthNoPriv -rvn iso -wvn iso -nvn iso manage snmp community create 10 -n team# -sn Team#

Interface Configuration:

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

- 153 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 153 -

12. In many circumstances you need to set the speed and duplex of the port. To change the Layer 2 status: a. Port Status: Net port up/down b. Force duplex/speed Device  Physical Interface, click on an Interface.

Click Set when done with changes. To save a configuration file 1. Go to File  Configuration  Receive From Device:

Figure 26 - Configuration File Save Window

2. When prompted, save the file to your workstation (*.ber is the binary format of the file). To upload a saved configuration file © Radware 2010. All rights reserved. Distribution of this document needs approval from Radware Knowledge & Education Services.

- 154 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 154 -

1. Go to File  Configuration  Send to Device:

Figure 27 - Restoring Configuration File

When restoring a configuration file to a Radware device, you will have to reboot the unit after the file has been applied. To upgrade the device 1. Go to File  Software Update, you will see the following screen:

Figure 28 - Upgrade Screen

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

- 155 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 155 -

The File section allows you to select the appropriate firmware file. The Password section is for the case-sensitive password you have gotten from Technical Support for this upgrade (you have gotten this password ahead of time, right?). The Software version section requires you to specify the actual version to be loaded. Since the filename is usually listed the version, this part is fairly easy to figure out. Upgrades through Web Based Management take only a few moments though they do require a device reboot. 13. Disable Ping Response to one interface of your device. manage ping-ports set 1 -s disable

Collect trouble-shooting information about the type of unit itself.

1. Go to Device  Device Information:

Figure 29 - Device Information Screen

Note the Platform, Flash Memory and Flash RAM, SW Version, SW Build, Version Status, and the Base MAC Address.

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

- 156 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 156 -

1. Verify network settings for each interface by double-clicking the unit, and selecting Device  Physical Interface:

Figure 30 - Physical Port Settings

2. Use the following CLI commands to gather additional information about the device: system device-info Device Information ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Type:

LinkProof Application Switch

Platform:

PPC 7410 processor

Ports:

21

Ports Config:

16 Fast Ethernet + 5 Giga Ethernet

HW version:

1.10

SW version:

3.61.02

Build:

Feb 13 2003, 15:30:41

Version State:

Final

BWM version:

2.30.04 RAM size:

256 MB

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

- 157 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 157 -

Flash size:

8 MB

Registered:

No

Date:

29.10.2002

Time:

16:34:59

Up time:

0 days, 1 hour, 1 minute, 23 seconds

Base MAC:

00:03:b2:0c:58:00

system logfile Log file is empty

system os cpu Device Resource Utilization ---------------------------RS Resource Utilzation : 0 RE Resource Utilzation : 0 Last 5 sec. Average Utilzation : 0 Last 60 sec. Average Utilzation : 0 Maximum Utilization

: 0

statistics ip ------------ IP Counters -----------ipInReceives

573

ipInHdrErrors

0

ipInAddrErrors

0

ipForwDatagrams

0

ipInUnknownProtos

0

ipInDiscards

0

ipInDelivers

563

ipOutRequests

543

ipOutDiscards

0

ipOutNoRoutes

0

ipReasmReqds

0

ipReasmOKs

0

ipReasmFails

0

ipFragOKs

0

ipFragFails

0

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

- 158 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 158 -

ipFragCreates

0

net arp table Arp Table Interface Index IP Address

MAC Address

Type

1

00e0987b5c08

dynamic

192.168.1.100

net l2-information Interface Table ifIndex

mac_addr

adm

oper

InUcastPkt InNUcastPkt OutUcastPkt OutNUcastPkt

1 0003b20c5800 up

up

4291523310

13

4291523310

14

2 0003b20c5801 up

up

3039383792

1103

3039383792

16

3 0003b20c5802 up

down

3236458074

0

3236458074

0

4 0003b20c5803 up

down

2878078969

0

2878078969

0

5 0003b20c5804 up

down

0

0

0

0

6 0003b20c5805 up

down

4050775923

0

4050775923

0

7 0003b20c5806 up

down

4225863528

0

4225863528

0

net l2-interface interface Table ───────────────────┬───────────────────┬───────────────────┬─────────────────── Interface Index

│MAC Address │

│Interface Admin │Status

│Operational Status │

───────────────────┼───────────────────┼───────────────────┼─────────────────── 1

│0003b2174540

│up

│up

│0003b2174541

│up

│up

│0003b2174542

│up

│down

│0003b2174543

│up

│down

│0003b2174544

│up

│down

│0003b2174545

│up

│down

───────────────────┼───────────────────┼───────────────────┼─────────────────── 2

───────────────────┼───────────────────┼───────────────────┼─────────────────── 3

───────────────────┼───────────────────┼───────────────────┼─────────────────── 4

───────────────────┼───────────────────┼───────────────────┼─────────────────── 5

───────────────────┼───────────────────┼───────────────────┼─────────────────── 6

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

- 159 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 159 -

───────────────────┼───────────────────┼───────────────────┼─────────────────── 7

│0003b2174546

│up

│down

│0003b2174547

│up

│down

───────────────────┼───────────────────┼───────────────────┼─────────────────── 8

net physical-interface Physical Interface Table

Port Index

Speed

Duplex

Auto Negotiate

1

Ethernet

Half

Off

2

Ethernet

Half

On

3

Ethernet

Half

On

4

Ethernet

Half

On

5

Ethernet

Half

On

6

Ethernet

Half

On

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

- 160 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 160 -

Bandwidth Management LinkProof Lab 9 – Bandwidth Management (using WBM) 6. Create several network entities following the guidelines below.

Name

Mode

Address or From IP

Mask or To IP

LAN

Mask

192.168.0.0

255.255.0.0

LAN

IP Range

10.10.110.1

10.10.110.50

DNS

Mask

4.2.2.0

255.255.255.0

ISP 1

IP Range

1.1.1.20

1.1.1.254

ISP 2

IP Range

2.2.2.20

2.2.2.254

Classes  Modify  Networks and click on the Create button. Enter the information as it appears in the image below and complete all five entries based on the information above

Once you have completed all five entries above, your Modify Network Table should look like the image below:

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

- 161 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 161 -

7. Update the policies to activate the settings:

Classes  Update Policies 8. Once complete, go to Classes  View Active Networks and it should look like

the following:

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

- 162 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 162 -

9. We create a physical port group named MyPorts using port 1-4. Go to Classes  Modify Port Groups and click Create. The Group Name will be MyPorts and the Inbound Port will be G-1. Repeat for Inbound Ports G-2 through G4. Update the Policies to activate the settings: Classes  Update Policies Go to Classes  ActivePort Groups and the table should look like the following:

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

- 163 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 163 -

10. Now we adapt the global BWM Parameters. Go to BWM  Global Parameters and use the settings in the image below:

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

- 164 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 164 -

You will need to reboot the LinkProof once you click the Set button.

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

- 165 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 165 -

Lab B – Creating a Simple Block Policy in BWM Lab Goals: •

Create a Bandwidth Management policy to block pings to the target server.

•

Test the policy.

Step By Step 5. Ping an external address to make sure you get a response for example 4.2.2.2. 6. Create a new policy to block outbound ping traffic. 7. Use the information below to create the policy: Go to BWM  Modify Policies and click Create at the bottom of the list. Use the information below to create a new filter named “Block-Ping” Name

Block-Ping

Destination

Any

Source

LAN

Action

Block

Direction

One Way

Service Type

Basic Filter

Service

icmp

Reporting

Report Block Packets

Next, click on BWM  Modify Policy Extensions. Click on the Block-Ping policy to edit it and change the Classification Point to Before Changes. Update changes BWM  Update Policies

Try to ping the same address from step1 and it should now fail. If you have the console connected you should also have a trap saying the session was blocked.

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

- 166 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 166 -

Lab C – Creating a simple minimum and maximum policy Lab Goals: •

Create multiple policies using existing services.

•

Test the policy.

Step By Step: 10. Open up an HTTP session to some website and an FTP download (ie:

ftp://ftp.mozilla.org/pub/firefox/nightly) to verify connection speed or gauge how fast the connections will load.

11. Create a policy for FTP traffic.

Go to BWM  Modify Policies and click Create at the bottom of the list. Use the information below to create a new filter named “FTP” Name

FTP

Destination

any

Source

LAN

Action

Forward

Direction

Two Way

Priority

0

Guaranteed Bandwidth

128

Service Type

Basic Filter

Service

ftp-session

Maximum Bandwidth

150

Next, click on BWM  Modify Policy Extensions. Click on the FTP policy to

edit it and change the Classification Point to Before Changes.

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

- 167 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 167 -

12. Add a second entry for HTTP: 13. Go to BWM  Modify Policies and click Create at the bottom of the list. Use the information below to create a new filter named “HTTP” Name

HTTP

Destination

Any

Source

LAN

Action

Forward

Direction

Two Way

Priority

1

Guaranteed Bandwidth

128

Service Type

Basic Filter

Service

http

Maximum Bandwidth

150

Next, click on BWM  Modify Policy Extensions. Click on the FTP policy to edit it and change the Classification Point to Before Changes. Update changes BWM  Update Policies

14. To verify if the policies are configured correctly go to BWM  View Active Policies And you should see these new policies in the list.

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

- 168 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 168 -

15. Turn on BWM Policy Statistics Monitoring. Go to Performance  BWM Policy Statistics Global Parameters and enable Policy Statistics Monitoring 16. From Firefox on your remote desktop, go to ftp://ftp.mozilla.org/pub/firefox/nightly and click on a large file to download, also go to various web pages for about 2 minutes.

17. Go to Performance  BWM Policy Statistics View Active Last Second Statistics Click the green Refresh button on the upper right corner of the browser window ( ) to update the statistics Stop the FTP session.

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

- 169 -

LinkProof Training Manual – Level 1 Date: October 2010 Page - 169 -

18. If time permits, repeat this lab using other guaranteed and maximal values to see

the different behavior.

End of Web Based Management for LinkProof

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