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
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
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.
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:
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).
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:
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):
Figure 17 - LinkProof Proximity Check Status per NHR
• 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 <Internal Start Range>
<Internal End Range> NHR-ISP <External Start Range>
<External End Range>
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#
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 <Host Name>
-lia <Local IP Address>
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 <IP Address>
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+#
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.
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:
• 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?
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
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