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
Course Code: 200-101
LinkProof – Level 1
Training Manual
October 2010This document is protected by United States and International copyright laws. Neither this document nor any material contained within it may be duplicated, copied or reproduced, in whole or part, without the expressed written consent of Radware, Inc. The features and functions of Radware devices discussed in this document are based on the following firmware version.
Product Version
LinkProof 6.12.xx (ODS hardware)
If your Radware device is running an older version of firmware some of the features and implementations discussed in this manual may not be available.
To upgrade your existing Radware device, please contact your Radware sales person.
Conventions
The following font conventions are used in this manual:
• Bold – indicates the series of menu items in Web Based Management used to reach a particular screen or window
• Underline
• Italics – indicates the value or setting supplied in a window or screen
– indicates an option or entry within Web Based Management screen or window
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 1REVIEW: ...18
CHAPTER 2 – BASIC FARM CONFIGURATION FOR THE LINKPROOF ...19
• LINKPROOF LAB 2–CREATING A FARM AND ROUTER SERVERS (USING CLI) ...25
• LINKPROOF CHAPTER 2REVIEW ...31
CHAPTER 3 – DEVICE MANAGEMENT FOR LINKPROOF ...32
• SERVER PRIORITY ...32 • RECOVERY TIME ...32 • WARM UP TIME ...32 • CONNECTION LIMITS ...32 • TRAFFIC LIMITS ...33 • NHROPERATIONAL 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 3REVIEW: ...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 5REVIEW: ...71
CHAPTER 6 LINKPROOF REDUNDANCY ...73
• VRRPREDUNDANCY ...73
• CONFIGURATION...73
• TABLE MIRRORING ...74
CHAPTER 7 ONE IP CONFIGURATION ...81
• LINKPROOF LAB 7–ONE IPCONFIGURATION (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 2REVIEW ...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 3REVIEW: ...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 5REVIEW: ...135
CHAPTER 6 LINKPROOF REDUNDANCY ...136
LINKPROOF LAB 6 – VRRP REDUNDANCY ...136
CHAPTER 7 ONE IP CONFIGURATION ...143
• LINKPROOF LAB 7–ONE IPCONFIGURATION (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
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.
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.
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
• 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 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):
• 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)
Startup Configuration
0. IP address 1. IP subnet mask 2. Port number 3. Default router IP address 4. RIP version (0,1,2) [0] 5. Enable OSPF (y/n) [n] 6. OSPF aread ID 7. User Name 8. User Password 9. Enable Web Access (y/n) [n] 10. Enable Secure Web Access (y/n) [n] 11. Enable Telnet Access (y/n) [n] 12. Enable SSH Access (y/n) [n] 13. SNMP Configuration
7) Assign the values based on your teams topology for the management port (MNGT-1 or Port 16) of 10.10.243.# where # is your team number.
a) 0. IP address b) = 10.10.243.# 1. IP subnet mask c) = 255.255.248.0 2. Port Number
d) Hit <Enter> for ALL the other values to set them to default. = MNG-1
Note: For those items on the list that are not applicable for this initial startup phase,
you can hit the <Enter> 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 <Enter> to accept all default values:
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 <ip> <mask> 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
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 <192.168.200.# where # is your team number>:
net ip-interface create <ip> <mask> 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
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 <Space> or <Enter>) and then hit the <Enter> 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.
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 <IP net> <Mask> <Next Hop> -i <Interface>
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
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
If the Device includes the optional modules of IPS and Bandwidth Management (see system license get) they can be enabled with the following commands:
Enable Bandwidth Management
bwm global classification-mode set 1
Enable Application Security (not be used later on only for your knowledge!) LP version 6.x:
security signatures-protection application-security global status set 1
At this Point you must Reboot the device for the changes to take effect.
• Chapter 1 Review:
Which type of Smart NAT (Dynamic or Static) could be described as a “many-to-one” network address translation process?
Which type of Smart NAT (Dynamic or Static) could be described as a “one-to-one” network address translation process?
On what system does the LinkProof rely in order to route external clients into a multi-homed network through many internet connections?
What is the default username and password for CLI access to a LinkProof? Can you have more then one IP on a single physical interface?
What values are assigned to the default configuration after 30 seconds?
What does NMS stand for and what potential problems can occur if you specify an NMS address in the configuration menu?
Chapter 2 – Basic Farm Configuration for the LinkProof
The LinkProof acts as the default gateway for devices into and out of the network. Instead of sending client traffic to the interface address of a specific router, the clients’ gateway becomes the address of an interface on the Active LinkProof. The device makes real-time decisions about router availability as well as load and will route the clients’ request appropriately.
The LinkProof can load balance up to 10 Next Hop Routers with proximity and up to 100 Routers without.
LinkProof uses farms to interface with the Next-Hop-Routers. Essentially, a router farm is a logical collection of routing devices, grouped according to their functionality. In most cases, all routers within a given farm will be treated equally as candidates for load-balancing decisions. In other words, traffic leaving the LinkProof can be sent to any of the router servers in a specific farm. The same router server can belong to multiple farms. Farms are also dependent of Traffic Flows – specific information that instructs the LinkProof which type of traffic should be redirected to the router servers within that farm. Different router farms can be based on different Traffic Flow policies to give administrators flexibility in varying circumstances. For example, administrators may wish to have Web traffic redirected out only one of their two available internet routers and all other traffic redirected out both available routers. To accomplish this, the administrator would need to create two farms – one farm containing only the routing server for Web traffic and a second farm containing both router servers to be used for all other traffic. Once the farms and their appropriate router servers have been created, Flows and Flow Policies need to be configured to specifically redirect traffic to the appropriate farm and to the servers within it.
This concept, known in previous versions of LinkProof code as Grouping, is essentially the same in theory but differs somewhat in the configuration details. This feature is discussed in more detail later in this manual.
Dispatch Method
The LinkProof offers a variety of methods for dispatching (load balancing) traffic to routers:
• 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:
The LinkProof sits between the internal network and two external ISP routers, each with a unique address space – 100.100.100.0/24 for ISP A and 200.200.200.0/24 for ISP B. The default gateway for internal hosts is an interface on the LinkProof of 192.168.1.1, and the LinkProof itself has a connection to each ISP – 100.100.100.2 for ISP A and 200.200.200.2 for ISP B.
When an internal user initiates a session to an external host (i.e. an Internet site), the LinkProof will choose a ISP router based on the load-balancing metric in use and will then perform NAT (Network Address Translation) for the client using a pre-configured address specifically for that ISP router.
In this example, the LinkProof is configured with a SmartNAT address of 100.100.100.50 to use for ISP A and a separate SmartNAT address of 200.200.200.50 to use for ISP B. The LinkProof tracks these outbound sessions internally so that when the response returns, the LinkProof can “un-NAT” the traffic and forward it back to the host that initiated the request.
SmartNAT allows customers to connect their network to multiple ISP routers and use all of them simultaneously without complicated gateway protocols or address sharing. Adding additional Internet connections can be as simple as placing new entries in the 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
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.
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.
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.
• 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 <Farm Name> -nm <1>
-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).
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 <Farm Name> <Router Name> -ip <IP of ISP>
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#
Syntax:
lp smartnat dynamic-nat create <Start IP> <End IP> <NHR IP/ISP> <Dynamic NAT>
The Start IP and End IP is the range of IPs on the local network, you can not use 0.0.0.0 to say all IPs instead you need to create a range 0.0.0.1 255.255.255.254 or limit the range to just the space on your network. Dynamic NAT does not support non contiguous ranges.
For each team:
lp smartnat dynamic-nat create 0.0.0.1 255.255.255.254 1.1.1.100 1.1.1.10#
lp smartnat dynamic-nat create 0.0.0.1 255.255.255.254 2.2.2.200 2.2.2.10#
Some Examples Below:
Team From Local IP To Local IP Router IP Dynamic Nat IP NAT Redundancy Mode Team1 0.0.0.1 255.255.255.254 1.1.1.100 1.1.1.101 Regular 0.0.0.1 255.255.255.254 2.2.2.200 2.2.2.101 Regular Team2 0.0.0.1 255.255.255.254 1.1.1.100 1.1.1.102 Regular 0.0.0.1 255.255.255.254 2.2.2.200 2.2.2.102 Regular Team10 0.0.0.1 255.255.255.254 1.1.1.100 1.1.1.110 Regular 0.0.0.1 255.255.255.254 2.2.2.200 2.2.2.110 Regular Team11 0.0.0.1 255.255.255.254 1.1.1.100 1.1.1.111 Regular 0.0.0.1 255.255.255.254 2.2.2.200 2.2.2.111 Regular
When complete, to display the NAT table type:
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.
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 <Value>
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.
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
• 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?
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.
• 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
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.
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.”
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
• 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
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.
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.
• 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 <Farm Name> <NHR By Name> <Remote Address>
lp servers remote-checks-table create mainfarm ISP1 192.168.150.100
lp servers remote-checks-table create mainfarm ISP2 192.168.150.100
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 <Farm Name> -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 <Name> -m <Method> -d <Destination Address> -h <NHR>
-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
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 <Health Check ID> <NHR ID> -g <Group Number>
To bind the Checks to the Servers you need to look up the Health Name ID and the NHR ID
For the Health Check ID look in
health-monitoring check
The look in the second column for the ID
For the NHR ID
health-monitoring server
And look for the value in the first column.
In Our Lab the complete commands will be as follows (this can vary depending on the Health Check ID):
health-monitoring binding create 0 0 -g 1 health-monitoring binding create 2 0 -g 1 health-monitoring binding create 1 1 -g 2 health-monitoring binding create 3 1 -g 2
5) Verify that the NHRs are up and that all checks are passed:
health-monitoring check
6) Once you are configured ask your instructor to take down the outside interface of one of your routers, you should see it fail.
• Have your instructor bring the NHR back online before proceeding.
Health Monitoring Non-Mandatory Checks (CLI):
1) Remove all the health checks from the binding table.
health-monitoring binding del 0 0 health-monitoring binding del 2 0 health-monitoring binding del 1 1 health-monitoring binding del 3 1
2) Remove all the health checks
health-monitoring check del ISP1-PING-Outside health-monitoring check del ISP2-PING-Outside health-monitoring check del ISP1-ARP-Inside health-monitoring check del ISP2-ARP-Inside
3) To add new health checks in the CLI the syntax is as follows:
health-monitoring check create <Name> -m <Method> -d <Destination> -h <NHR> -p <Port> -a <Arguments> -r <Retries>
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.
-p = Port, the TCP or UDP port used for this application.
-a = Arguments, the values given for this application, for example HOST=, or REGEX=.
-r = Retries, the number of consecutive failed checks before the check will be counted as failed.
4) Create 4 DNS checks going out 2 for each ISP.
health-monitoring check create ISP1-DNS-yahoo -m 10 -d 4.2.2.2 -h 1.1.1.100 -p 53 -a HOST=www.yahoo.com -r 2
health-monitoring check create ISP1-DNS-google -m 10 -d 4.2.2.1 -h 1.1.1.100 -p 53 -a HOST=www.google.com -r 2 health-monitoring check create ISP2-DNS-yahoo -m 10 -d 4.2.2.2 -h 2.2.2.200 -p 53 -a HOST=www.yahoo.com -r 2
health-monitoring check create ISP2-DNS-google -m 10 -d 4.2.2.1 -h 2.2.2.200 -p 53 -a HOST=www.google.com -r 2
5) After creating the checks make sure they all pass you can view the health table with the following command:
health-monitoring check
6) The next step is to bind the checks to the Routers the syntax is as follows: health-monitoring binding create <Health Check ID> "HMM Server Name” -g <Group Number> -m <Mode>
Health Check Name = The name you created in the check table.
HMM Server Name is the name the LinkProof gives your combination of farm name and ISP. To find out the names you can type:
health-monitoring server
-g = Group, all the checks for the NHR should be part of the same group number. -m = Mode, has two options:
o Mandatory o Non-mandatory
7) Create 4 bindings one for each check to the two ISPs marking them all as Non-mandatory.
NOTE: Make sure your health check numbers are correct or use the health check name.
healthmonitoring binding create 5 "NHR: mainfarm/ISP1" -g 1 -m Non-mandatory
healthmonitoring binding create 4 "NHR: mainfarm/ISP1" -g 1 -m Non-mandatory
healthmonitoring binding create 7 "NHR: mainfarm/ISP2" -g 2 -m Non-mandatory
healthmonitoring binding create 6 "NHR: mainfarm/ISP2" -g 2 -m Non-mandatory
• 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?
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.
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:
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
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).
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,
• 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
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 <Name> <Subindex> –f <From Address> -t <To Address> -m <Mode>
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 <Name> <Subindex> –a <Network ID> -s <Subnet Mask> -m <Mode>
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
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 <Flow Name> <Farm Name>
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:
lp flow-management modify-policy-table create <Name> -i <Index Value> -dst <Destination> -src <Source> -fc
<Cluster Name>
-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 flowmanagement modifypolicytable 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 <Policy Name>
In Our Lab:
lp flow-management modify-policy-table del DNS
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 <Name> -i <Index Value> -pt filter –p <Filter Name> -dst
<Destination> -src <Source> -fc <Cluster Name>
-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 flowmanagement modifypolicytable create HTTP i 2 -pt filter -p http -dst any -src Internal -fc ISP1
lp flowmanagement modifypolicytable 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.
11) 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?
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
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:
