1 Introduction

GEO offers the ability to move past the single data center, allowing for multi data center High Availability (HA). Even when a primary site is down, traffic is diverted to the disaster recovery site. Also included in GEO is the ability to ensure clients connect to their fastest performing and geographically closest data center.

The GEO product is available in two forms:

A standalone GEO product

A Global Server Load Balancing (GSLB) Feature Pack that is part of the Kemp load balancer (LoadMaster) product

Throughout this document, when we refer to the "GEO LoadMaster" we are referring to either the GEO LoadMaster or the LoadMaster with the GSLB Feature Pack enabled.

GEO has the same management interfaces as Kemp's Server LoadMaster hardware appliances, including all the foundation technology such as syslog logging, email notifications, interface bonding, and Gigabit support. GEO provides advanced application health checking, to ensure that unavailable services or data centers are not visible to clients. Health checking occurs at the site level, allowing for flexible decision making on when traffic should be diverted per Fully Qualified Domain Name (FQDN).

GEO can be deployed in a distributed (active/active) high availability configuration, with multiple GEO LoadMasters securely synchronizing information. Introducing GEO into existing Authoritative Domain Name Services (DNS) requires minimal integration work and risk, allowing you to fully leverage the existing DNS investment.

GEO securely and seamlessly integrates with core LoadMaster functionality to offer Real Server Load balancing, in which GEO uses local data center metrics provided by the LoadMaster, allowing clients to connect to the most available target. This is supported in both the GSLB feature pack and the standalone GEO product.

Currently, GEO only handles A (IPv4) and AAAA (IPv6) records.

1.1 Document Purpose

The purpose of this document is to give an overview of the GEO product and its functionality.

1.2 Intended Audience

This document is intended to be read by anyone who is interested in finding out more about Kemp's GEO product.

2 Benefits of GEO

There are a number of benefits to using GEO including speed, scalability, and manageability. For more information, refer to the sections below.

2.1 Speed

GEO ensures that mission-critical servers are continuously available and performing reliably. GEO can monitor server and application load. This information is then used to intelligently direct user requests to the cluster that is most available. By intelligently redirecting traffic, the LoadMaster eliminates server overload conditions and round trip propagation delays that may slow performance, allowing you to increasing end-user application speed.

2.2 Scalability

GEO solves the scalability dilemma in the common adage: "Growth is the challenge, scalability is the key". GEO solves this by continuing to support increasing network server workloads and still providing high reliability. GEO:

Intelligently distributes traffic across server arrays or data centers

Reduces the need for increasingly larger and more expensive servers to accommodate increases in network traffic

Enables many distributed application servers to function as a single, virtual server

Reduces the risks of all application resources deployed at a single geographical location

Allows for the orderly addition of new resources, or routine data center maintenance without disrupting service to the end user

Can be used with multiple heterogeneous hardware platforms allowing organizations to protect their investments in their legacy hardware installations, as well as integrate future hardware investments

2.3 Manageability

GEO is easy to set up, and easy to manage. Network management is made easy, administrators can deploy new servers and take individual data centers offline for routine maintenance without disrupting services to end-users. Integrating GEO into an existing DNS infrastructure can be done with no service impact and allows for distributed administration.

3 GEO Examples

Refer to the sections below for some examples of how GEO works.

3.1 How GEO Typically Works

This section describes how the GEO functionality typically works. Please note that within this configuration we are depicting the GEO LoadMaster as being located outside the data centers to make the flow clear. Though this can be the case, typically the GEO LoadMaster would be located within one or more of the data centers.

1. A public client tries to connect to FQDN test.domain.com.

2. The public client checks its local DNS.

3. The local DNS forwards the request to the public DNS.

4. The Public DNS forwards the request to GEO as it is the authoritative DNS for this record.

5. GEO checks persistence and scheduling and decides which site to return.

6. GEO returns the IP address for the client that made the request (in this case; the public DNS).

7. The public DNS returns the results to the Local DNS.

8. The local DNS returns the result to the client.

9. The client connects directly to the site.

The above diagram depicts a few scenarios:

• Two active/active sites with round robin/location/proximity scheduling
• Two sites - one active and one disaster recovery with fixed weight scheduling
• GEO LoadMasters set up as partners in active/active mode. Please refer to the Distributed LoadMaster Partners section for further information on GEO partners.

By default, if the client is private they are given a private address. If the client is public, they are given a public address.

3.2 GEO Answer to a DNS Query A or AAAA

This section provides examples of how GEO responds to various DNS requests from clients. These examples assume that DNSSEC is not enabled; see the next section for DNSSEC-related examples.

When a query is run against GEO, GEO gets the IP address of the client. The client could have a public IP or a private IP (meaning the client is in the same network as GEO).

The Public Requests and Private Requests drop-downs in the modify FQDN screen allows granular control of DNS responses. This provides finer control of DNS responses to configured FQDNs. Administrators may selectively respond with public or private sites based on whether the client is from a public or private IP. For example, administrators may wish to allow only private clients to be sent to private sites. For a table breaking down what site types are allowed depending on the client IP address type and the Public/Private Requests setting, refer to the Add an FQDN section.

For the examples in this section, we will assume the following settings in GEO:

Case 1: If the FQDN has a site defined in GEO, it answers with the configured site IP address.

In this case, the FQDN in the dig query below (fqdn.ZoneNameExample.com) is configured in the GEO configuration:

So, GEO responds with the configured IP address in a DNS response that looks like the example below:

$ dig A fqdn.ZoneNameExample.com @3.83.34.12

 

; <<>> DiG 9.10.3-P4-Ubuntu <<>> A fqdn.ZoneNameExample.com @3.83.34.12

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38017

;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; WARNING: recursion requested but not available

 

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 4096

;; QUESTION SECTION:

;fqdn.ZoneNameExample.com. IN A

 

;; ANSWER SECTION:

fqdn.ZoneNameExample.com. 10 IN A 1.1.1.1

 

;; AUTHORITY SECTION:

ZoneNameExample.com. 10 IN NS soa.ZoneNameExample.com.

 

;; ADDITIONAL SECTION:

soa.ZoneNameExample.com. 10 IN A 172.16.1.192

 

;; Query time: 232 msec

;; SERVER: 3.83.34.12#53(3.83.34.12)

;; WHEN: Tue Oct 08 11:02:44 IST 2019

;; MSG SIZE rcvd: 103

 

Case 2: The FQDN is either not defined (or is not given an IP address) in the GEO configuratiion, or the site is not available.

The answer from GEO will be NOERROR and will follow the general format shown below. The content of the authority section depends on whether the FQDN is defined on GEO:

• If the FQDN is defined on GEO, this section contains the SOA (Start of Authority) record from GEO's configuration.
• If the FQDN is defined in another zone that GEO knows about but is defined on another DNS server, the authority section in the response includes the SOA information GEO obtained from the authoritative DNS server for the domain.

The following is how an FQDN that was created but no IP address was assigned looks in the GEO UI:

The example below shows what GEO response to a query for the above FQDN would look like.

$ dig A fqdn.ZoneNameExample.com @3.83.34.12

; <<>> DiG 9.10.3-P4-Ubuntu <<>> A fqdn.ZoneNameExample.com @3.83.34.12

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54329

;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; WARNING: recursion requested but not available

 

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 4096

;; QUESTION SECTION:

;fqdn.ZoneNameExample.com. IN A

 

;; AUTHORITY SECTION:

ZoneNameExample.com. 10 IN SOA soa.ZoneNameExample.com. email.ZoneNameExample.com. 46 86400 7200 2419200 10

 

;; Query time: 225 msec

;; SERVER: 3.83.34.12#53(3.83.34.12)

;; WHEN: Tue Oct 08 11:03:51 IST 2019

;; MSG SIZE rcvd: 99

 

Case 3: The FQDN does not exist

In this case, the FQDN does not exist in the GEO configuration, nor in the configuration of any DNS server with which GEO is communicating.

The response is REFUSED and will look like the example below.

$ dig A fqdnDoesNotExist.com @3.83.34.12

 

; <<>> DiG 9.10.3-P4-Ubuntu <<>> A fqdnDoesNotExist.com @3.83.34.12

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 54387

;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; WARNING: recursion requested but not available

 

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 4096

;; QUESTION SECTION:

;fqdnDoesNotExist.com. IN A

 

;; Query time: 235 msec

;; SERVER: 3.83.34.12#53(3.83.34.12)

;; WHEN: Tue Oct 08 11:05:12 IST 2019

;; MSG SIZE rcvd: 49

3.3 DNSSEC Examples

DNSSEC only works when a zone name is defined and it only works for the FQDNs that belong to the zone. FQDNs that do not belong to a defined zone will provide an answer without the DNSSEC signature.

Case 1: FQDN does not belong to a Zone Name

$ dig A foo.example.com +dnssec @3.83.34.12

 

; <<>> DiG 9.10.3-P4-Ubuntu <<>> A foo.example.com +dnssec @3.83.34.12

;; global options: +cmd

,

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24329

;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; WARNING: recursion requested but not available

 

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags: do; udp: 4096

;; QUESTION SECTION:

;foo.example.com. IN A

 

;; ANSWER SECTION:

foo.example.com. 10 IN A 1.1.1.1

 

;; AUTHORITY SECTION:

foo.example.com. 10 IN NS soa.ZoneNameExample.com.

 

;; Query time: 224 msec

;; SERVER: 3.83.34.12#53(3.83.34.12)

;; WHEN: Tue Oct 08 11:15:51 IST 2019

;; MSG SIZE rcvd: 94

 

Case 2: FQDN belongs to a Zone Name

$ dig A fqdn.ZoneNameExample.com +dnssec @3.83.34.12

 

; <<>> DiG 9.10.3-P4-Ubuntu <<>> A fqdn.ZoneNameExample.com +dnssec @3.83.34.12

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25994

;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 3

;; WARNING: recursion requested but not available

 

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags: do; udp: 4096

;; QUESTION SECTION:

;fqdn.ZoneNameExample.com. IN A

 

;; ANSWER SECTION:

fqdn.ZoneNameExample.com. 10 IN A 1.1.1.1

fqdn.ZoneNameExample.com. 10 IN RRSIG A 8 3 10 20191107054647 20191008044647 22641 zonenameexample.com. ZnBg0vsjOLK37x5ZH3o82o8Id5nCBT/IFP2rQTajtjF/zOV4UHHp5KBs 7CDFdFkyfyQ1vT3ZFyXaxFJ1GcxmOizzkgfwP4CqOdwQwMzWbvk9dlQ+ M33drzO7MzGQjQS3Mg8ptow9FLoNY3unc8+KgDJGxhJzIHY+okzJITZN cvM=

 

;; AUTHORITY SECTION:

ZoneNameExample.com. 10 IN NS soa.ZoneNameExample.com.

ZoneNameExample.com. 10 IN RRSIG NS 8 2 10 20191107050733 20191008044631 22641 zonenameexample.com. N0QLBBM55+TCVCQfk4cbYk5IY7L3jgp7O/Dv4yss1dqlO4z4EGhwbqul jsr4BzhZzqYnJvsZaTl+roEKdJAS8fgx24uXQpeDsBjiukJYsR5ZjDuT fhGnf9By7CdkEWr4rdU+Q7eDPmdigXWDvru2K6ui8Inzy1kEkCB5zYhU YJ8=

 

;; ADDITIONAL SECTION:

soa.ZoneNameExample.com. 10 IN A 172.16.1.192

soa.ZoneNameExample.com. 10 IN RRSIG A 8 3 10 20191107050733 20191008044631 22641 zonenameexample.com. N0RW69lu/7IWPY/Z9DufZlZuDVE0KmY8AgzLvo1JneicHF27wElKKVUa 0lSVD15yypeSD96T0hZIkqVhKrgv43UKTYu3khR7I+wl53gYie3qaLnA 0HmBG/GD1tmW8Pky7B7hCGz7DbpI+fqenZHzyCGdu7alYy0PhoQNcFRZ xlA=

 

;; Query time: 229 msec

;; SERVER: 3.83.34.12#53(3.83.34.12)

;; WHEN: Tue Oct 08 11:17:19 IST 2019

;; MSG SIZE rcvd: 640

Case 3: Zone name defined, FQDN that belongs to the zone but is not defined in GEO

In this case, GEO answers NXDOMAIN.

 

dig @172.16.0.65 A notexisting.fab.com

 

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-3.P2.fc27 <<>> @172.16.0.65 A notexisting.fab.com

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 44488

;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; WARNING: recursion requested but not available

 

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 4096

;; QUESTION SECTION:

;notexisting.fab.com. IN A

 

;; AUTHORITY SECTION:

fab.com. 10 IN SOA nameserver.fab.com. hostmaster.fab.com. 29 86400 7200 2419200 10

 

;; Query time: 1 msec

;; SERVER: 172.16.0.65#53(172.16.0.65)

;; WHEN: Tue Oct 08 08:32:16 EDT 2019

;; MSG SIZE rcvd: 97

4 Deploying GEO

The sections below refer to various aspects of GEO deployment.

4.1 Enable/Disable GEO

When using the GSLB Feature Pack, GEO can be enabled or disabled by clicking either the Enable GSLB or Disable GSLB menu option under Global Balancing in the main menu of the LoadMaster WUI. When GSLB capabilities are enabled on a LoadMaster, the Packet Routing Filter is also enabled and required. When GEO is disabled, it is possible to either enable or disable the Packet Routing Filter in System Configuration > Access Control > Packet Filter.

Disable GSLB can be performed by any user with the GEO Control permission. Enable GSLB can only be performed by the bal user.

4.2 GEO Homepage

Refer to the sections below for a description of the different parts of the home screen.

4.3 Login Information

After initially logging in to the LoadMaster, if Session Management is enabled - some login information is displayed:

The last login time and IP address of the current user

The number of successful logins by the current user in the last 30 days

The total number of failed login attempts by any user (including unknown usernames) since the last successful login

4.3.1 General Information

IP address: The IP address of the LoadMaster.

LoadMaster Version: The firmware version of the LoadMaster.

If the Allow Update Checks feature is enabled - when a new version of the LoadMaster firmware becomes available, a message is displayed at the top of the Home screen to inform you. To enable the auto-check feature, go to Certificates & Security > Remote Access.

Serial Number: The Serial Number of the LoadMaster.

Boot Time: The time of the last server reboot.

4.3.2 WAF Status

The WAF Status section will only appear on WAF-capable LoadMasters. For further information on WAF, please refer to the Kemp Web Application Firewall, Feature Description.

4.3.3 System Metrics

CPU Load: The percentage of load to the CPU of the LoadMaster appliances and to the CPU running a Virtual LoadMaster (VLM).

TPS [conn/s]: The total number of Transactions Per Second and the number of Secure Sockets Layer (SSL) transactions per second.

WAF Stats: Web Application Firewall (WAF) status - shows the total number of handled connections, and the total number of incidents.

Net Load:  Network load in megabits per second, shown for each configured interface.

CPU Temp.: Displays the temperature of the CPU.

The CPU Load and Net Load data is updated every 5 seconds.   

4.3.4 License Information

Clicking the View License link will display model, subscription, subscription expiry and subscription feature details, such as the activation date and end date of the LoadMaster license.

If the subscription has expired, a message is displayed in the License Information section. To renew the subscription, please contact Kemp.

Upgrade: Upgrade the LoadMaster by buying a license from the Kemp purchase portal.

4.3.5 About LoadMaster

On the About LoadMaster page, you can view licenses for third party software that is used in the LoadMaster.

To view a license, click the View button next to the relevant item.

4.3.6 Other Links

Other links are provided at the bottom of the home page:

Support & FAQ: A link to the Kemp Support site

Find Online Documentation: A link to the Kemp documentation page

4.4 GSLB Menu Options

When using the GSLB Feature Pack on a LoadMaster, the GEO-related options can be found by selecting the Global Balancing option in the main menu on the left of the WUI.

4.5 Specify what Interfaces to Use for GEO Responses and Requests

There is another GEO option which is not contained in the Global Balancing main menu option - Use for GEO Responses and Requests. You can get to this setting by going to System Configuration > Network Setup and selecting the relevant interface.

By default, only the default gateway interface is used to listen for and respond to DNS requests. This field gives you the option to listen on additional interfaces. When this option is enabled, GEO also listens on any Additional addresses that are configured for the interface.

4.6 Enable Alternate Gateway Support

If there is more than one interface enabled, there is an option which provides the ability to move the default gateway to a different interface.

Enabling this option adds another option to the Interfaces screen - Use for Default Gateway.

4.7 DNS Responder

LoadMaster connects to one or more networks. By default, a single interface (eth0) is used for DNS responses. In this documentation, eth0 is assumed to be used as the sole interface used for DNS responses.

In a one-armed configuration, the DNS responder service can be configured for any subnet. The LoadMaster connects to a Layer 2 network through a single interface, eth0.

If a firewall is already in place performing PAT to a DMZ in a non-routable (RFC1918) IP space (for example, 192.168.x.x or 10.x.x.x), please make sure a 1-to-1 PAT for port 53 UDP/TCP exists to the LoadMaster. 

Kemp does not recommend a Layer 3 source IP NAT to the LoadMaster as it will mask source IP visibility during geographical coding operations, all devices before the LoadMaster should be transparent.

The LoadMaster(s) can be located on the DMZ with no large-scale network changes required. As shown in the diagram above, the default gateway of LoadMaster should point to the firewall.

4.8 Client Source IP

When referring to client source IP, we are taking about the client resolver of the workstation, not the source IP of the workstation or its corresponding NAT to the Internet. This is an important concept to understand; client IPs are of the corresponding DNS resolver. The LoadMaster's geographical encoding operations are based on this client IP. A common deployment for client DNS resolvers is depicted in the diagram below.

In the illustration above, the following steps occur:

1. The client workstation asks the local DNS server for a translation of www.web.example.com.

2. The local DNS server forwards the request to an ISP or Internet DNS server.

3. The ISP/Internet server has the relevant A records and NS records pointing to the LoadMaster.

4. The GEO LoadMaster responds to the DNS query with an appropriate answer.

It is important to understand that it is step 3, within the described configuration, which defines the client IP address as presented to the LoadMaster, not step 1 or step 2.

If the firewall is transparent, the GEO LoadMaster will see the client as the ISP. If the firewall is NATing the traffic, the GEO will see the client IP address as the firewall.

The above diagram illustrates the difference between recursive and iterative DNS.

With recursive DNS:

1. A public client checks the local DNS server for the IP address of the FQDN.

2. If the Local DNS Server cannot provide the IP address, the local DNS requests the address from the ISP/internet DNS server.

3. If the ISP/internet DNS server cannot provide the IP address, it requests the address from the firewall.

4. If the firewall cannot provide the IP address, it requests the address from the GEO LoadMaster.

5. The return traffic sends answers back to each device along the chain in the network.

In recursive DNS, the GEO LoadMaster sees the client as the ISP server. Please bare this in mind when using location-based or proximity scheduling.

With iterative DNS:

1. The client checks the local DNS server for the IP address of the FQDN.

2. The local DNS server tells the client to contact the ISP/internet DNS server.

3. The client checks the ISP/internet DNS server for the IP address of the FQDN.

4. The ISP/internet DNS server tells the client to contact the firewall.

5. The client checks the firewall for the IP address of the FQDN.

6. The firewall tells the client to contact the GEO LoadMaster.

7. The client checks the GEO LoadMaster for the IP address of the FQDN.

8. The GEO LoadMaster answers the DNS query.

These are all separate connections.

4.9 DNS Integration/Delegation

You must create a DNS delegation for the client's DNS request to be forwarded to the LoadMaster. This must be done for both private and public clients. To avoid confusion, this is explained from two perspectives:

• The application user's point of view: From the application user's point of view, the FQDN is delegated to the GEO LoadMaster. A user delegates the FQDN mail.domain.com to the GEO LoadMaster.
• The DNS administrator user's point of view: From the DNS administrator's point of view, the sub-domain is delegated to the GEO LoadMaster. A DNS administrator delegates the subdomain *mail.domain.com to the GEO LoadMaster. Any request matching this is forwarded to the GEO LoadMaster. For example:
  • Sales.mail.domain.com
  • QA.mail.domain.com
  • support.mail.domain.com
  • *.mail.domain.com
  • mail.domain.com

All of the FQDNs in the sub-domain mail.domain.com are delegated to the GEO LoadMaster including the FQDN mail.domain.com itself. In most cases, the only FQDN that matters is mail.domain.com. In this scenario, there are no other records in this sub-domain, for example, Sales.mail.domain.com and QA.mail.domain.com.

You can integrate the LoadMaster with your authoritative DNS with only a few DNS records:

1. Create a new A record which is pointed to the LoadMaster, for example lm1.example.com. Create the corresponding PTR record for the reverse proxy lookup by IP. Forward-confirmed reverse DNS support is required.

2. For each hostname that must be delegated to the LoadMaster, create an NS record and set the value to the A record created for the LoadMaster in the previous step, for example, www.web.example.com to lm1.example.com.

When using GEO LoadMaster active/active configuration, repeat step 1 for the second LoadMaster using a unique hostname, for example lm2.example.com. Repeat step 2 using the second LoadMaster. This results in two NS records for www.example.com; one pointing to lm1.example.com and one to lm2.example.com.

Here are some steps with screenshots:

1. Open the DNS Manager. This shows existing records and records already created for GEO LoadMasters.

2. Right-click the domain and select New Delegation.

3. Click Next on the new delegation wizard.

4. Set this to the FQDN/sub-domain that you want to delegate.

5. In this example, the FQDN mail.kemptest.com (sub-domain *.mail.kemptest.com) is delegated.

6. Select what to delegate this FQDN/sub-domain to the GEO LoadMaster.

7. Add each GEO LoadMaster individually.

8. Delegate this FQDN/sub-domain to these GEO LoadMasters.

9. Click Finish.

Under the domain kemptest.com there is now a sub-domain that has a delegation and two NS records pointing to the two GEO LoadMasters.

4.10 GEO Miscellaneous Params

Miscellaneous GEO parameters can be configured by going to Global Balancing > Miscellaneous Params in the LoadMaster WUI.

4.10.1 Zone

Zone Name

The name of the zone when using DNSSEC. To configure a Zone Name appropriately, the DNS server must first be consulted. Once the Zone has been acquired, populate the Zone in this field to indicate the Authoritative Zone. Zone Names are required when configuring DNSSEC.

4.10.2 Source of Authority

Configuration of global parameters controls the behavior of the entire LoadMaster. The Source of Authority (otherwise known as Start of Authority) information is not required for basic functionality; however, it is recommended to populate this metadata to accurately represent the LoadMaster DNS server. 

Example Source of Authority values, and descriptions of each of the fields, are provided below:

Field	Example	Description
Apply to Zone Only		. If this option is enabled, the Source of Authority (SOA) parameters are applied only to the zone. If it is disabled, the SOA parameters apply to all Fully Qualified Domain Names (FQDNs). The Apply to Zone Only option is disabled by default.
Source of Authority	kemptechnologies.com	The name of the domain owner
Name Server	GEO1.kemptechnologies.com	The name of the DNS server
SOA Email	hostmaster.example.com	Email address of the person responsible for the zone and to which email may be sent to report errors or problems. This is the email address of a suitable DNS administrator but more commonly the technical contact for the domain. By convention (in RFC 2142) it is suggested that the reserved mailbox hostmaster is used for this purpose but any valid email address will work. The format is <MailboxName>.<Domain>.com, for example, hostmaster.example.com (uses a full stop (.) rather than the usual @ symbol because the @ symbol has other uses in the zone file) but mail is sent to hostmaster@example.com.

In LoadMaster firmware version 7.2.52, the Zone Name field moved to the new Zone section and a new Apply to Zone Only check box was added to the Source of Authority section.

4.10.3 Global

Glue Record IP

In LoadMaster firmware version 7.2.52, a new text box was introduced called Glue Record IP which allows you to set the IP address of the name server to return in additional records in a DNS response. If an IP address is not configured in the Glue Record IP text box, 0.0.0.0 is returned wherever an additional record is expected. Both IPv4 and IPv6 addresses are supported.

TTL

The Time To Live (TTL) value dictates how long the reply from the GEO LoadMaster can be cached by other DNS servers or client devices. This value should be as practically low as possible. The default value for this field is 10. The time interval is defined in seconds.

TXT Record

In LoadMaster firmware version 7.2.52, support for the TXT (Text) record type was added to the GEO functionality. A TXT (text) record is essentially unformatted data that can be used for almost any purpose, but typically contain information to be consumed by clients to classify a domain in some way, provide details about a domain, or specify resources available within a domain.

The configured record is returned for a TXT request on any Fully Qualified Domain Name (FQDN).

A maximum of 127 characters can be entered as the global TXT record.

The following are not currently supported:

• Multiple strings within the record: Some DNS providers allow you to put multiple strings in one entry using quotes, for example, "string 1" "string 2" "string 3". Kemp does not currently allow this , so you can only have "string 1".

• Non-ASCII characters.

4.10.4 Resource Check Parameters

Resource Check Parameters define the GEO health checking that occurs from LoadMaster to GEO Clusters and Real Servers. For more information on clusters, refer to the Scheduling Methods section. The default values for the Resource Check Parameters are as follows:

• Check Interval: 120
• Connection Timeout: 20
• Retry attempts: 2

Depending on the behavior, the wait can take up to (<Retries>+1)*<Timeout>:

• If there is no response at all, it waits the maximum duration as stated above
• If the service returns a rejection of some form, it may take significantly less time to fail

4.10.5 Stickiness

Global Server Load Balancing (GSLB) Persistence, also known as 'Stickiness', is the property that enables all name resolution requests from an individual client to be sent to the same set of resources until a specified period of time has elapsed. This ensures that users are able to retrieve and interact with session-specific data. Stickiness can be set globally in the Miscellaneous Params section, or for an individual FQDN.

If connecting from a client to the GEO LoadMaster directly, the GEO LoadMaster keeps a persistence entry for the request. If connecting from a DNS server to the GEO LoadMaster directly, the GEO will keep a persistence entry for the request, as will the DNS server. When troubleshooting, ensure to set Stickiness to 0 and clear the DNS cache on the DNS server (Dnscmd /clearcache on Windows Server).

For further information, refer to the GEO Sticky DNS, Feature Description.

4.10.6 Location Data Update

You can update the GEO location database with the latest data by doing the following:

1. Go to the Other Downloads page to download the latest GEO database ZIP archive to your local system (for example, your laptop).

2. After download, extract the ZIP archive using the appropriate utility on your local system. The archive contains several files. The file without any extension contains the database update; the other files can be used to check the correctness of the downloaded update file.

3. Open the LoadMaster Web User Interface (WUI) and go to Global Balancing > Miscellaneous Params.

4. Click Choose File and use the pop-up controls to select the GEO data file from the extracted ZIP file contents on your laptop. Look for the file that does not have a file extension, as in this example: geodata.patch_2007_03_01_0104.

5. After the GEO data file has been uploaded and verified by the LoadMaster, click the Install Update button to add it to the running system.

The legacy MaxMind GeoLite database is only supported on LoadMaster version 7.2.44 and below. The new MaxMind GeoLite2 database is only supported on LoadMaster version 7.2.45 and above.

4.11 Fully Qualified Domain Name (FQDN)

A Fully Qualified Domain Name (FQDN) is the hostname in which you need to perform load balancing. The FQDN can be any hostname in the top-level domain or a hostname that is nested as a sub-domain. Each FQDN can be an A (IPv4) or AAAA (IPv6) record.

Each distinct hostname must be configured in the LoadMaster individually.

You can create an FQDN for www.example.com and also www.kemptechnologies.com.

4.11.1 Add an FQDN

To add an FQDN, follow the steps below:

1. In the main menu, select Global Balancing and Manage FQDNs.

2. Click the Add FQDN button.

3. Enter an FQDN name, for example www.example.com in the New Fully Qualified Domain Name textbox.

Wildcards are supported here, for example *.example.com matches anything with .example.com ending.

4. Click the Add FQDN button.

5. Click OK on the message that appears.

6. Select the relevant load balancing algorithm from the Selection Criteria drop-down list. For more information on the selection criteria, refer to the GEO, Feature Description on the Kemp Documentation Page.

7. If the Selection Criteria is set to Location Based, you can specify whether or not to allow Fail Over.

When the Fail Over option is enabled, if a request comes from a specific region and the target is down, the connection will fail over and be answered with the next level in the hierarchy. For example, if the Selection Criteria is Location Based - the country comes first in the hierarchy, then continent. If this is not available, the connection is answered by the nearest (by proximity) target. If this is not possible, the target with the lowest requests is picked. The Fail Over setting affects all targets.

Select the relevant options for the Public Requests and Private Requests drop-down lists.

8. The Isolate Public/Private Sites setting has been enhanced as of version 7.1-30. The checkbox has been migrated to two separate dropdown menus to allow more granular control of DNS responses. Existing behavior has been preserved and is migrated from your current setting, ensuring that no change in DNS responses is experienced. These new settings allow administrators finer control of DNS responses to configured FQDNs. Administrators may selectively respond with public or private sites based on whether the client is from a public or private IP. For example, administrators may wish to allow only private clients to be sent to private sites.

The following table outlines settings and their configurable values:

Setting	Value	Client Type	Site Types Allowed
Public Requests	Public Only Prefer Public Prefer Private All Sites	Public Public Public Public	Public Public, Private if no public Private, Public if no private Private and Public
Private Requests	Private Only Prefer Private Prefer Public All Sites	Private Private Private Private	Private Private, Public if no private Public, Private if no public Private and Public

9. A Failure Delay (minutes) can be set if needed. If a Failure Delay is set, another option called Site Recovery Mode becomes available. Refer to the Enabling Fail Over section for further information on these options.

Following a completely failed health check, the GEO LoadMaster waits for the specified number of minutes before taking the site out of rotation.

10. Enable/disable the Enable Local Settings check box, as needed. If enabled, configure the TTL and Stickiness options.

11. Enable or disable Unanimous Cluster Health Checks. If this option is enabled, if any IP addresses fail health checking - the other FQDN IP addresses in the same cluster is forced down. For further information, please refer to the Scheduling Methods section.

12. Enter the IP address of the domain in the IP address text box.

In LoadMaster firmware versions prior to 7.2.50, there is an entry limit of 16 IP addresses per FQDN. If you attempt to add more than this, you get an error message saying Too many IP addresses already specified.

The entry limit was increased to 64 IP addresses in LoadMaster firmware version 7.2.50.

13. If needed, select the Cluster name.

14. Click Add Address.

15. Select the type of health checking to be performed from the Checker drop-down list. For further information regarding health checking options, refer to the FQDN Health Check Options section.

4.11.2 FQDN Health Check Options

The Checker options in the Configure FQDN screen defines the type of health checking that is performed. The options include:

• None: This implies that no health check is performed to check the health status of the machine (IP address) associated to the current FQDN.

• ICMP Ping: This tests the health status by pinging the IP address.

• TCP Connect: This will test the health by trying to connect to the IP address on a specified port.

• Cluster Checks: When this is selected, the health status check is performed using the method associated with the selected cluster.

•  

4.11.3 Scheduling Methods

The GEO LoadMaster load balances DNS requests - it does not load balance traffic. GEO offers many load balancing algorithms including round robin, weighted round robin, fixed weighting, real server load, location based, proximity , and all available.

The selection criterion chosen determines how GEO distributes the incoming requests across the IP address end-points for the FQDN.

The selection criterion can be altered in real-time; previously configured information is retained during a change. Only a single selection criterion is permitted per FQDN and each FQDN can have a unique selection criterion. The following sections outline the selection criteria that are available on the LoadMaster.

Each of these scheduling methods are described below.

4.11.3.1 Round Robin

With the Round Robin method, incoming requests are distributed sequentially across the IP address end-points.

IP address end-points for an FQDN could be Real Servers, LoadMasters or even Data Centers depending on how the FQDN is configured.

If this method is selected, all the IP address end-points assigned to an FQDN should have similar resource capacity and host identical applications. Subject to this precondition, the round robin system is a simple and effective method of distribution.

However, if the IP address end-points have different capacities, the use of the round robin system can mean that a less powerful IP address end-points receives the next inquiry even though it has not yet been able to process the current one. This could cause a weaker IP address end-points to become overloaded.

This selection criterion is not dependent on the geographical IP database.

Round Robin load balancing can be used for all active data centers, which includes support for weights and a chained failover option for disaster recovery. Round robin scheduling in GEO LoadMasters works the same way as the normal LoadMaster with one exception; when using nslookup, by default it will check for both IPv4 (A) records and IPv6 (AAAA) records which actually sends out two requests.

For example, if you have two sites:

• Request 1 IPv4 A record hits Site 1,
• Request 2 IPv6 record AAAA hits Site 2,
• Request 3 IPv4 A record hits Site 1,
• Request 4 IPv6 AAAA record hits Site 2

When testing:

• Clients looking for IPv4 will always connect to Site 1.
• Clients looking for IPv6 will always connect to Site 2.

To help prevent this during testing - add an odd number of sites.

4.11.3.2 Weighted Round Robin

This method balances out the weakness of the simple round robin: incoming requests are distributed across the cluster in a sequential manner, while taking account of a static "weighting" that can be pre-assigned per server.

The administrator simply defines the capacities of the servers available by weighting the servers. The most efficient server, A for example, is given the weighting 100, whilst a much less powerful server (B) is weighted at 50. This means that Server A would always receive two consecutive requests before Server B receives its first one, and so on.

This selection criterion is not dependent on the geographical IP database.

4.11.3.3 Fixed Weighted

 Fixed weighted scheduling is usually used in Disaster Recovery (DR) sites. The highest weight Real Server is only used when other Real Server(s) are given lower weight values. However, if the highest weighted server fails, the Real Server with the next highest priority number is available to serve clients. The weight for each Real Server should be assigned based on the priority among the remaining Real Servers. When the failed Real Server becomes available, it automatically starts receiving requests.

This selection criterion is not dependent on the geographical IP database.

4.11.3.4 Real Server Load

Requires integration with LoadMaster, this allows you to obtain datacenter-level metrics from LoadMaster which are used in real-time to direct clients to the cluster that's least busy.  The GEO LoadMaster will poll the connection statistics of LoadMaster and use a portion or all of the available data to determine overall level of busyness for the relevant Virtual Service. The cluster with the lowest value receives the requests. Each IP address end-points must be attached to a Cluster and the Checker option must be Cluster Checks.

This selection criterion is not dependent on the geographical IP database but does require a LoadMaster cluster.

4.11.3.5 Proximity and Location Based

Location Based load balancing allows GEO to direct a client to a data center based on the client's country, continent or IP address range as defined by the created policies. If there is more than one site with the same country code, requests are distributed in a round robin fashion to each of the sites. Location Based load balancing can be used for granularity, for example, if a site in Germany fails - send traffic to the next site in Europe (not the next closest proximity site).

Proximity takes Location Based one step further and allows for longitude and latitude granularity for definition of proximity. When using Proximity scheduling, new public sites are automatically mapped to geographic coordinates based on the GEO database. New private sites are mapped to 0o0'0" and function as expected. This coordinate should be overridden with accurate values to ensure correct balancing.

In LoadMaster firmware version 7.2.52, a bug was fixed which had previously caused GEO location coordinates to be changed after creating or modifying an FQDN when using Proximity as the Selection Criteria. This issue no longer occurs in versions 7.2.52 and above. However, if this issue occurred on a version previous to 7.2.52 and you upgrade to 7.2.52 or above, the coordinates do not get automatically fixed. Therefore, if the incorrect coordinates are already in the LoadMaster, you must manually correct them.

The client source IP address is geocoded in real-time by the LoadMaster then matched against the geocoded longitude and latitude of the cluster or FQDN Real Server definitions. The closest cluster or IP address end-points to the client is the IP address provided to the client. The longitude and latitude of a cluster or IP address end-point is auto-populated and can be manually overridden. 

This selection criterion is dependent on the geographical IP database.

To use the Proximity selection criteria with private IP addresses, the IP Range Selection Criteria must be completed for all private subnets. In addition to this, both the coordinates and country must be configured. If they are not configured, requests from private IP addresses are rejected.

For more information on the IP Range Selection Criteria, refer to the IP Range Selection Criteria section.

In the example above, either proximity or location-based scheduling could be used. If proximity scheduling is used, the client is directed towards the German domain because it is geographically closer to it than the French domain. If location-based scheduling is used, the client is directed towards the French domain because it is in the same country. Using proximity scheduling here may result in a faster connection. However, if users need to be directed towards the French version of a website - it may be better to use location-based scheduling.

4.11.3.6 All Available

The All Available selection criteria returns all possible healthy targets for an A (IPv4) or AAAA (IPv6) query request. The GEO LoadMaster will still refuse other records, for example MX. The contents of the returned list is also controlled by the Public Requests and Private Requests settings:

For Public Sites Only the list can only contain public addresses. Likewise, for Private Sites Only the list can only contain private addresses.

For Prefer Public the list only contains public addresses, unless no public addresses are available - in which case the list contains private addresses (if any are available). Likewise, for Prefer Private the list only contains private addresses, unless no private addresses are available - in which case the list contains public addresses (if any are available).

For All Sites the list contains all available addresses

The purpose of this is to provide a list of preferred addresses, if they are available. Otherwise, provide a list of non-preferred addresses as a failback measure for improved availability.

4.12 IP Range Selection Criteria

In the IP Range Selection Criteria menu option, you can specify coordinates or a location that apply to an IP address or range. Custom locations can also be added. This allows users to be routed to services based on private IP addresses/ranges as defined manually. It allows the definition of up to 64 IP ranges per data center. The range is limited by the IPv4 or IPv6 native range. You can specify an IP address or network. Valid entries here are either a single IP, for example 192.168.0.1, or a network in Classless Inter-Domain Routing (CIDR) format, for example 192.168.0.0/24.

GEO supports subnet precedence for custom-defined IP address ranges in IP Range Selection Criteria. For example:

172.16.0.0/12 - United States

172.16.100.0/21 - United Kingdom

172.16.200.0/21 - Germany

GEO uses the longest prefix for resolution when multiple entries are matched. So, using the example above, 172.16.100.1 should match the /21 United Kingdom resolution rules.

 

To do this, follow the steps below:

1. In the main menu of the LoadMaster WUI, select Global Balancing.

2. Select IP Range Selection Criteria.

3. Enter the IP Address or network. Valid entries here are either a single IP, for example 10.154.11.10, or a network in Classless Inter-Domain Routing (CIDR) format, for example 10.154.11.10/32.

Do not overlap subnets because this can have unpredictable results.

4. Click Add Address.

5. Click Modify.

6. Specify the coordinates click Save.

7. Alternatively, select the country from the Location drop-down list.

The existing IP ranges can be modified or deleted using the buttons provided on the IP Range Selection Criteria screen.

8. In the main menu of the LoadMaster WUI, select Manage FQDNs.

9. Click Modify on the relevant FQDN.

10. If you entered a Proximity using the coordinates in the IP Range Selection Criteria screen, select Proximity in the Selection Criteria drop-down list.

11. If you selected a location, select Location Based.

12. Fill out the remaining details as needed.

4.13 Unanimous Cluster Health Checks

When configuring an FQDN, one of the options which can be configured is Unanimous Cluster Health Checks. If this option is enabled, if any IP addresses fail health checking - other FQDN IP addresses which belong to the same cluster is marked as down. When Unanimous Cluster Health Checks is enabled, the IP addresses which belong to the same cluster within a specific FQDN are either all up or all down. For example, example.com has addresses 172.21.58.101, 172.21.58.102 and 172.21.58.103 which all belong to cluster cl58:

If 172.21.58.101 fails, the unanimous policy forces 172.21.58.102 and 172.21.58.103 down as well.

When 172.21.58.101 comes back, the unanimous policy brings back 172.21.58.102 and 172.21.58.103 along with it.

At any given time - either all three addresses are available or all three addresses are down.

The same approach applies for site failure mode with manual recovery. Manual recovery causes a failed address to be disabled, so the administrator can re-enable it after fixing the problem. When Unanimous Cluster Health Checks is enabled, all three addresses are disabled.

The unanimous policy ignores disabled addresses. So, if you know that an address is down, and for whatever reason you want to continue using the other addresses that belong to the same cluster, you can disable the failed address and the unanimous policy will not force down the other addresses with it.

When Unanimous Cluster Health Checks are enabled, some configuration changes may cause FQDN addresses to be forced down or brought back up. For example, if an address is forced down and you remove it from the cluster while the unanimous policy is in effect, the address should come back up. Similarly, if you add an address to a cluster where the unanimous policy is in effect and one of the addresses is down, the new address should be forced down. This change may not occur immediately, but it should happen the next time health checking occurs.

If there are addresses with the Checker set to None combined with addresses that have health checking configured - addresses with no health checking will not be forced down, but they can be forcibly disabled if the Site Recovery Mode is set to Manual. For example, say there are three addresses:

172.21.58.101 with a Checker of Cluster Checks

172.21.58.102 with a Checker of Cluster Checks

172.21.58.103 with a Checker of None

If site failure handling is off or automatic, the failure of 172.21.58.101 causes 172.21.58.102 to be forced down, but 172.21.58.103 remains up. The rationale is that if you do not want health checking on 172.21.58.103 then it should remain up.

However, if the Site Recovery Mode is set to Manual, failure of 172.21.58.101 causes both 172.21.58.102 and 172.21.58.103 to be disabled, along with 172.21.58.101. For site recovery - all addresses are disabled, even the ones with no health checking configured. This is to keep traffic away from the problem data center until the system administrators fix it. This does not conflict with having addresses with no health checking because you can have an address that is up but disabled.

4.14 Manage Clusters

A cluster is a group of LoadMasters working in conjunction. Clusters can also be non-LoadMaster entities using TCP or ICMP health checks. GEO clustering is a feature mainly used inside data centers. Health checks are performed on a machine (IP address) associated to a specific FQDN, using the containing cluster server, rather than the machine itself.

You can add a maximum of 18 GEO clusters.

In terms of GEO, a cluster is a GEO LoadMaster polling another device for health checks. For example, a GEO LoadMaster can poll a firewall on a site in front of Real Servers. If the firewall is up, it is assumed that everything behind the firewall is up too. If the health check to the firewall fails, the Real Servers behind the firewall are marked as down.

GEO LoadMasters can be used with a normal LoadMaster as a cluster. There are two methods for clusters:

First, the LoadMaster can be polled for health checks (same as a firewall or any other device). If this LoadMaster health check fails, everything behind the LoadMaster is marked as down.

Second, you can use cluster checks. In this case, the GEO LoadMaster polls the LoadMaster and the LoadMaster informs the GEO LoadMaster which Virtual Services are up.

Clusters can be added, modified and deleted from the Global Balancing > Manage Clusters menu option.

The following diagram helps identify common cluster devices, which include edge routers, firewalls or load balancers. Health checking these devices can summarize the availability of the devices behind their services.

ISP Router: Checking the ISP's edge router will quickly allow the detection of loss of ISP network connectivity

Firewall: Checking the firewall will confirm that the ISP network is available and provides visibility to the first arm of equipment located at the data center

LoadMaster: Checking a load balancer will confirm if the ISP is available, the network infrastructure is available and the Real Servers are responding as expected

4.14.1 Cluster Types

When a cluster is defined, it is possible to set its type. The available cluster types are described below:

Default: When the type of cluster is set to Default, the check is performed against the cluster using one of the following three available health checks:

- None: No health check is performed. Therefore, the machine always appears to be up.

- ICMP Ping: The health check is performed by pinging against the cluster IP address.

- TCP Connect: The health check is performed by connecting to the cluster IP address on the port specified.

The frequency of the health checks can be specified in the Miscellaneous Params screen.

Local LM: When Local LM is selected as the Type, the Checkers field is automatically set to Not Needed. This is because the health check is not necessary because the cluster is the local machine.

Remote LM: The health check for this type of cluster is Implicit (it is performed by SSH).

4.14.2 Real Server/Cluster Health Checking

GEO utilizes Layer 3, Layer 4 and Layer 7 health checks to monitor the availability of the IP address end-points and clusters. In the case that one of the servers does not respond to a health check within the defined time interval, for a defined number of times, the weighting of this server will be reduced to zero. This zero weighting has the effect of removing the Real Server from the Virtual Service configuration until the Real Server is back online.

Health checks occur from the LoadMaster. Therefore, it is important to make sure that the LoadMaster has access to each cluster and IP address. If all checks fail, ensure that the default gateway is correctly operating.

The following table describes the different health check options available for GEO FQDNs:

Layer	Type	Description
None	None	No check occurs
Layer 3	ICMP	The LoadMaster sends ICMP echo requests (pings) to the Real Servers. An IP address end-point fails this check when it does not respond with an ICMP echo response in the configured response time for the configured number of retries. This is only a relevant health check when the endpoint target is not a LoadMaster.
Layer 4	TCP	The LoadMaster attempts to open a TCP connection to the IP address end-point on the configured service port. The server passes the check if it responds with a TCP SYN ACK in the response time interval. In this case, the LoadMaster closes the connection by sending a TCP RESET. If the server fails to respond within the configured response time for the configured number of times, it is assumed dead.
Layer 7	Cluster Checks	A health check is performed on the IP address of the cluster. Different types of clusters can be defined. The health checks differ for each type: Default Cluster Type: An ICMP Ping or TCP Connect health check (depending on what is selected in the Manage Cluster options) is performed. Remote LM Cluster Type: An SSH connection is attempted. The native LoadMaster statistics are obtained and matched against the FQDN Real Server. If a matching Virtual Service IP is not found, the list of Real Servers cluster is marked as down. Permission to connect must be granted on the LoadMaster. Local LM: This method is required if a LoadMaster is co-located with the GSLB Feature Pack for health checks to function correctly. If the Checker type is set to Cluster Checks and the cluster Type (in Global Balancing > Manage Clusters > Modify > Type) is set to Remote LM, you must also select the associated Virtual Service from the Mapping Menu drop-down list. If Virtual Services are not displayed in the drop-down list, ensure that both LoadMasters are able to access each other. The remote GEO partner must be configured in Certificates & Security > Remote Access. The Mapping Menu drop-down list displays a list of Virtual Service names (where available) and Virtual Service IP addresses from that LoadMaster. It lists each Virtual Service IP address with no port, as well as all of the Virtual IP address and port combinations. Select the Virtual IP address that is associated with this mapping. If a Virtual Service with no port is selected, the health check checks all Virtual Services with the same IP address as the one selected. If one of them is in an "Up" status, the FQDN shows as "Up". The port does not come in to consideration. If a Virtual Service with a port is selected, the health check only checks against the health of that specific Virtual Service when updating the health of the FQDN.

4.14.3 Add a Cluster

In this example, here are the IP addresses being added:

GEO LoadMaster: 10.113.0.54

Regular LoadMaster: 10.113.0.28

Virtual Service IP address: 10.113.0.37

To add a cluster, follow the steps below on a GEO LoadMaster:

1. Enter the IP address of the cluster (in this example it is the LoadMaster with IP address 10.113.0.28).

2. Enter a Name for the cluster.

3. Click Add Cluster.

4.14.4 Connect a LoadMaster to a GEO LoadMaster

In the example, the LoadMaster (10.113.0.28) must be connected to the GEO LoadMaster (10.113.0.54). To do this, follow the steps below in the LoadMaster:

1. In the main menu of the LoadMaster WUI, go to Certificates & Security > Remote Access.

2. Type the IP address of the GEO LoadMaster (10.113.0.54 in this case) and click Set GEO LoadMaster access.

4.14.5 Add the FQDN and the Virtual Service IP Address

To add the FQDN and Virtual Service IP address, follow the steps below in the GEO LoadMaster:

1. In the main menu of the LoadMaster WUI, go to Global Balancing > Manage FQDNs.

2. Enter the FQDN and click Add FQDN.

3. Enter the IP address of the Virtual Service (10.113.0.37 in this example).

4. Select the relevant Cluster (LM28 in this example).

5. Click Add Address.

6. Configure any other settings as needed.

4.14.6 Modify a Cluster

To modify an existing cluster, follow the steps below:

1. Click Modify on the relevant cluster.

2. Change the settings as needed.

The Type can be Default, Remote LM or Local LM:

Default: When the type of cluster is set to Default, the check is performed against the cluster using one of the following three available health checks:

- None: No health check is performed. Therefore, the machine always appears to be up.

- ICMP Ping: The health check is performed by pinging against the cluster IP address.

- TCP Connect: The health check is performed by connecting to the cluster IP address on the port specified.

Local LM: When Local LM is selected as the Type, the Checkers field is automatically set to Not Needed. This is because the health check is not necessary because the cluster is the local machine.

Remote LM: The health check for this type of cluster is Implicit (it is performed using SSH).

The only difference between Remote LM and Local LM is that Local LM saves a TCP connection because it gets the information locally and not over TCP. Otherwise, the functionality is the same. Default is a generic cluster type that does not communicate with a LoadMaster. It uses TCP or ICMP health checks.

Remote LM and Local LM are only used when the target is a LoadMaster as opposed to a server or another resource. Local LM is used by GEO to check the LoadMaster it is enabled on.

When Default is selected, either ICMP Ping or TCP Connect can be selected as the health check type in the Checkers drop-down list.

When Remote LM or Local LM is selected, no health check options are available. Remote LM health checks are performed using SSH on port 22.

If needed, click Show Locations to enter the latitude and longitude of the location of the IP address.

After a cluster is initially added, the health check marks it as Up by default. The status is updated after the next health check cycle.

4.14.7 Delete a Cluster

To delete a cluster, click Delete in the Configured Clusters screen.

There is no "undo" function here. Delete with care.

4.14.8 Clustering Configuration Advice

When setting up clustering in a multi-GEO environment, all LoadMaster clusters must be of the type Remote LM.

Each LoadMaster which is to be used as a cluster must have all GEO IP addresses listed in the Remote GEO LoadMaster Access field, which is in Certificates & Security > Remote Access in the WUI.

When LoadMaster and GEO HA pairs are used, the shared IP address must be listed in the Remote GEO LoadMaster Access field.

4.15 Configure DNSSEC

DNSSEC verification of signed responses was included in the DNS client in LoadMaster firmware version 7.1.34.

DNSSEC digital signing (2K key) support for DNS responses was added to the GSLB LoadMaster in firmware version 7.2.37.

DNSSEC helps protect against cache poisoning using a set of extensions that provide origin authentication of DNS data, data integrity and authenticated denial of existence. DNSSEC provides a mechanism to sign requests and prove the validity of records in a given zone and does this through a process called zone signing.

DNSSEC adds four new resource record types:

• Resource Record Signature (RRSIG)
• DNS Public Key (DNSKEY)
• Delegation Signer (DS)
• Next Secure (NSEC)

These resource record types are described in RFC 4034.

There are also two new DNS header flags, which are:

• Checking Disabled (CD)
• Authenticated Data (AD)

Before configuring DNSSEC, a zone must be defined. You can configure the zone settings in the Global Balancing > Miscellaneous Params screen of the WUI. For further details on the Miscellaneous Params screen, refer to the GEO Miscellaneous Params section. A zone is a single unique part of a DNS namespace hierarchy that serves as the authoritative source for information about a select set of DNS domain names.

To group FQDNs within a zone, the FQDN must be the sub-domain of the zone. Otherwise, each FQDN defines a zone.

To define a zone, go to Global Balancing > Miscellaneous Params and specify a Zone Name.

To enable DNSSEC in the LoadMaster, follow the steps below:

1. Go to Global Balancing > Configure DNSSEC to configure the DNSSEC options.

2. You can either import the Key Signing Keys (KSKs), or generate them. To import them, click Import and browse to and select the files. If generating, go to the next step.

A KSK is a type of DNSKEY that is used to sign the keys contained within a DNS zone and are leveraged to validate resolvers. The KSK also signs the Zone Signing Key (ZSK).

3. If generating the KSKs, click Generate. Select the Algorithm and Key Size and click Generate.

4. The KSK details are displayed.

5. Select the Enable DNSSEC check box.

There is no user interface for ZSK files. A ZSK is used to generate Resource Record Signatures (RRSIG) for each set of resource records in a zone and sign these records. GEO creates the ZSK files automatically when DNSSEC is enabled. The same algorithm is used as specified for the KSK files. A key size of 1024 is used. If DNSSEC is disabled, the KSK files are deleted.

4.16 GSLB Statistics

The GSLB Statistics screen (accessible from under the Global Balancing section in the main menu) is a centralized snapshot of the GSLB components that enable site resiliency and hybrid traffic distribution.

The following sections display on the GSLB Statistics screen:

• GSLB Service Status: Displays the Boot time (the start time of the bind device) and the Last configuration (the date and time when the configuration was last modified).
• FQDN statistics: Displays the FQDN configuration with IP address information.
• Queries: Displays the different DNS query types received.
• DNS Request Information: Displays the type of DNS requests with a description and request count.

If you disable and re-enable GSLB, the GSLB statistics reset to zero.

4.17 Remote Administration

Full remote administration occurs over HTTPS using the default 443 SSL port. Limited remote administration can be performed over SSH using the default port 22. This includes system level configuration, debugging/advanced troubleshooting but not DNS administration. The recommended graphical user interface for remote administration is HTTPS.

When negotiating a HTTPS connection with the LoadMaster you may be required to acknowledge security warnings, for example, acknowledging a discrepancy between the hostname and IP or the signer of the certificate. It is safe to allow/permit overrides, all LoadMaster occurs over a secure channel regardless of these warnings.  To permanently remove the warning about signing authority you can download the Root certificate by clicking Download Root Cert in the main menu.

4.18 IP Blacklist Settings

It is possible to download blacklist rules from Kemp to block access from IP addresses that are on the blacklist. A whitelist can be manually specified that overrides the blacklist. These rules can be set to automatically download and install or they can be manually downloaded and installed.

This is a subscription-based feature. If you cannot see these options, or if any fields are grayed out, please contact Kemp to upgrade your subscription.

To configure the IP blacklist settings, follow the steps below:

1. In the main menu of the LoadMaster WUI, go to Global Balancing > IP Blacklist Settings.

2. Select whether or not to Enable Automated GEO IP Blacklist data Updates.

3. In the Last Updated section, you can manually download the rule updates now. You can also view changes, that is, what are the differences between the latest downloaded rules and the previously downloaded rules.

4. Select whether or not to Enable Automated Installs. When enabled, you can specify what time to install the updates at.

5. You can Manually Install the GEO IP Blacklist data by clicking Install Now.

If the GEO blacklist data is not updated for more than 7 days, a message appears.

6. View the GEO IP Blacklist data file by clicking View. This displays a full list of the blacklisted IP addresses.

7. Addresses and networks can be added to the whitelist by entering them into the Address/Network text box and clicking Add. The whitelist overrides the blacklist.

4.19 Certificates

The Certificates & Security option in the main menu of the LoadMaster WUI enables you to import and manage SSL certificates. It also gives the ability to generate a Certificate Signing Request (CSR). This option is only relevant for the GEO LoadMaster WUI access.

4.20 Distributed LoadMaster Partners

When there are multiple LoadMaster boxes, where each box could be a single LoadMaster or a HA pair, they can be linked together to act as a single resource.

When a HA LoadMaster pair is configured to do GEO synchronization, all of the shared IP addresses must be added to each partner configuration correctly.

All of the boxes remain synchronized with each other and share their DNS Configurations, FQDN information, 'Stickiness' information and health checking updates. Any updates are automatically shared with all the other Distributed Partners.

The Geographical IP Database used for the Proximity and Location Based load balancing methods is not distributed between the LoadMaster partners. Any updates to the Geographical IP Database must be configured on each LoadMaster individually.

4.20.1 HA Versus Partners

HA is the same for GEO LoadMasters as it is for regular LoadMasters - it is an active-passive pair of units.

Partners are two or more GEO units in an active-active mode.

It is possible to have both HA and partners.

In the example diagram above, public and private addresses are used. The partner address should be the NATed addresses if the GEOs are connecting externally.

4.20.2 Set Up GEO LoadMaster Partners

Before partnering GEO LoadMasters, backup the relevant GEO LoadMaster that has the correct/preferred configuration. This backup should then be restored to the other LoadMasters that are partnered with the original LoadMaster. This is a prerequisite because GEO partners are active-active and share the same configuration. As a result of this, you mustensure that the settings are in sync before adding a partner.

4.20.2.1 Backup and Restore the Correct Configuration

To perform a backup, follow the steps below in the WUI of the GEO LoadMaster that has the correct/preferred configuration settings:

1. In the main menu, go to System Configuration > System Administration > Backup/Restore.

2. Click Create Backup File. The file downloads.

Then, on the GEO LoadMaster(s) that are partnered - follow the steps below to restore the configuration:

3. In the main menu, go to System Configuration > System Administration > Backup/Restore.

4. Click Choose File.

5. Browse to and select the backup file.

6. Select the GEO Configuration check box.

7. Click Restore Configuration.

Now that the correct configuration is applied, the GEO LoadMasters can be partnered.

4.20.2.2 Partner the GEO LoadMasters

When configuring two GEO units as partners, the communication between the two units occurs through the Admin Default Gateway if one is configured on the Certificates & Security > Remote Access page. Otherwise, communication occurs through the system Default Gateway on the System Configuration > Network Setup > Default Gateway page. If this behavior does not match the needs of your configuration, a static route can be created to send partner responses out of the required interface.

To partner the GEO LoadMasters, follow the steps below:

1. Select the Certificates & Security > Remote Access option from the main menu.

2. Ensure the Allow Remote SSH Access check box is selected.

3. In the GEO LoadMaster Partners text box, enter the IP address of the LoadMaster to partner with. If there is more than one box, enter the IP addresses but separate them with a space.

The maximum number of GEO partners allowed is 64.

4. Click Set GEO LoadMaster Partners.

5. Enter the port number that the LoadMasters use to communicate in the GEO LoadMaster Port text box.

6. Click Set GEO LoadMaster Port.

7. In the GEO update interface drop-down list, select the GEO interface that the GEO partners will communicate through.

8. Repeat the above steps for all other GEO LoadMasters to be partnered.

4.20.2.3 GEO Partners Status

After a GEO LoadMaster is partnered, its status is indicated in the GEO Partners section of the Remote Access screen.

Figure 3-22 shows GEO Partner status of Green indicating the two partners can see each other.

Figure 3-22 also shows GEO Partner status of Red indicating the LoadMasters cannot communicate. The reasons for this include (among other possibilities); one of the partners is powered down, there may be a power outage or a cable disconnected.

A red status could also appear because when initially set, the status of the GEO Partner on the first GEO LoadMaster displays as red. When you set the GEO Partner on the second GEO LoadMaster, the status displays as green on the second LoadMaster but remains red on the first GEO LoadMaster for approximately three minutes until the first GEO LoadMaster updates. As a workaround, click Set GEO LoadMaster Partners on the first LoadMaster again and the status changes to green.

If there is a failure to update the GEO partner, the logs display an error message saying the GEO update to the partner failed. The message displays the IP address of the partner.

If you experience any issues with partnering the GEO LoadMasters, check the SSH settings and do a TCP dump to confirm that SSH connections are being sent and received by all parties.

4.20.3 Upgrading GEO Partners

When upgrading GEO partners, it is strongly recommended that all nodes are upgraded simultaneously. Because GEO partners operate in active-active mode, upgrading at the same time ensures that consistent behavior is experienced across all nodes.

If you must operate a GEO cluster with mixed versions, be sure to make all changes from the most recent version. This prevents configuration loss due to incompatible configurations. Additionally, changing configuration options not present in older versions results in disparate behavior.

4.21 Configuring GEO for Exchange Site Resiliency

Microsoft Exchange data center or site failures require a combination of both automatic and manual steps to be completed before client service is fully restored and for the outage to end. The manual steps, mainly centred on the administration of the mailbox databases, pose some unique issues regarding an Exchange data center failover which are not found in other types of site failures.

GEO functionality provides options to Exchange administrators to assist in dealing with the unique issues posed by an Exchange data center failover.

4.22 Enabling Fail Over

Kemp recommends enabling the Fail Over option in Exchange environments.

Enabling the Fail Over option enables Location Based FQDNs to select the most appropriate site for requests in the event that the best match is not available. When the Fail Over option is enabled, if a request comes from a specific region and the target is down, the connection will fail over and be answered with the next level in the hierarchy. If this is not available, the connection is answered by the nearest (by proximity) target. If this is not possible, the target with the lowest requests are picked. For example, if a request from Ireland is received, but the site assigned to Ireland is unavailable, a site assigned to Europe is selected. If the site assigned to Europe is also unavailable, a site assigned to Everywhere is selected. If this too is unavailable, the site with the lowest requests of the available sites in the same continent is selected using the round robin method. The Fail Over setting affects all targets. The Fail Over option is only available when the Selection Criteria is set to Location Based.

Fail Over is set on all GEO nodes. If a partner GEO unit has been configured, you can assume that all nodes are operating on the same configuration. The settings in one GEO is synced to all other GEO nodes.

4.23 Delaying a Failover

By default, if a target is unavailable (that a request would typically be directed to) - that is, the server is down - the request is directed to the next best available alternative target. When the original target becomes available, it is set into rotation after the specified timeout or failover. However, if needed it is possible to set a Failure Delay. Failure Delay is very important in Exchange data centers.

Implementing an Exchange data center failover is not a trivial event - it is not recommended to automatically failover upon detection of a site failure. Delaying the failover for a short period ensures that failovers do not occur because of trivial and temporary failures.

Delaying the failover can also provide the Exchange administrators time to ensure that the secondary site is ready to provide the requisite levels of service.

The LoadMaster provides a Failure Delay option which, when enabled, delays a failover occurring for a configurable period of time after a site failure is detected. If, after the delay, the site recovers, the failover is not initiated. If the site has not recovered, the failover is initiated as per normal.

If a Failure Delay is set, another option becomes available underneath it - Site Recovery Mode. Two modes are available:

Automatic: The site is brought back into operation immediately upon site recovery

Manual: After the site has failed, disable the site. Manual intervention is required to restore normal operation.

4.24 Requiring Manual Intervention Before Failback Occurs

It is recommended that when a failed data center recovers, attempting to restore services to the recovered data center is not initiated (a failback) before the application failover process is complete and until the recovered data center is deemed to be healthy. In addition, the mailbox databases should beready for use.

If the failback is initiated before these are complete, then issues may arise with the mailbox databases and prolong the outage.

Kemp recommends not to allow automatic failbacks when a failed data center recovers in the case of Microsoft Exchange. Requiring some manual intervention before a recovered data center is deemed available for a failback means that administrators can ensure that the optimal conditions exist before a failback occurs.

The LoadMaster provides Site Recovery Mode options that determine how a failed data center becomes available for failback upon recovery. Selecting the manual option configures the LoadMaster to administratively disable the failed data center upon the initiation of a failover. This ensures that, even if the failed data center recovers, administrator intervention would be required before the data center is available for a failback to occur.

4.25 Configuring Site Resiliency Options for Exchange

GEO functionality provides options to Exchange administrators to assist in dealing with the unique issues posed by an Exchange data center failover. These options can be found within the Site Failure Handling section of the FQDN configuration page, which is accessed as follows:

1. In the main menu, go to Global Balancing > Manage FQDNs.

2. Click Modify for the relevant FQDN.

Failure Delay

This setting determines how long (in minutes) the LoadMaster waits until it designates a site as having failed, thereby initiating a site failover.

It is recommended that this setting is enabled when configuring multi-site Exchange deployments. The optimal value given to the delay depends on the configuration of the Exchange deployment.

Site Recovery Mode

This determines what recovery options are implemented when a failed site recovers.

Automatic - when the data center recovers, the LoadMaster automatically performs a failback (restores services to the recovered data center)

Manual - upon failure, the data center is administratively disabled and is not available for a failback until the admin clicks the Enable button for the relevant data center

The Manual option is recommended for multi-site Exchange deployments to ensure that failbacks do not occur until the administrators ensure that the optimal conditions for a failback exist.

The Lockdown option has been deprecated and will only be available to people who upgrade with this configuration enabled. If you do not have the configuration enabled or if you change any of the Site Failure Handling options, then it will not be available. The Lockdown option is not recommended as a Site Recovery Mode option.

5 Troubleshooting

5.1 Persistence/Stickiness

If connecting from a client to the GEO LoadMaster directly the GEO LoadMaster keeps a persistence entry for the request. If connecting from a DNS server to the GEO LoadMaster directly, the GEO LoadMaster keeps a persistence entry for the request as does the DNS server. For troubleshooting, ensure to set stickiness on the GEO LoadMaster to 0 and clear the DNS cache on the DNS server.

To clear the DNS cache on a Windows server, run the following command:

c:\> Dnscmd /clearcache

Always test with the nslookup command or the dig command directly against the GEO LoadMaster to confirm the results.

5.2 Scheduling

Round Robin

This is the same principle as the normal LoadMaster with one exception - when using the nslookup command, by default, it checks for both IPv4 (A) records and IPv6 (AAAA) records, which actually sends out two requests.

If you have two sites:

• Request 1 - IPv4 A round robin to Site 1
• Request 2 - IPv6 AAAA round robin to Site 2
• Request 3 - IPv4 A round robin to Site 1
• Request 4 - IPv6 AAAA round robin to Site 2

When testing, clients looking for IPv4 always connect to Site 1 and clients looking for IPv6 always connect to Site 2. To help prevent this from occurring during testing, you can add an odd number of sites.

nslookup Troubleshooting

nslookup command:

c:\> nslookup <FQDN> <GEO address>

For example:

c:\> nslookup geotest.lan 10.113.0.52

Response is:

Name: geotest.lan

Address: 10.10.10.10

Commands for further testing:

Changes request type to IPv4 A record:

nslookup -query=A

Changes request type to IPv6 AAAA record:

nslookup -query=AAAA

DIG command:

user@linux: dig <domain>

user@linux: dig test.domain.com

Search for an FQDN:

user@linux: dig -t <record type> <FQDN>

user@linux: dig -t A test.domain.com

Search for an A record type:

user@linux: dig -t <record type> <FQDN>

user@linux: dig -t AAAA test.domain.com

Search for an AAAA record type:

user@linux: dig -t A <DNS server/ GEO> <domain>

user@linux: dig -t A @10.113.0.54 test.domain.com

Search for an A record type against this DNS server or GEO (10.113.0.52).

References

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

Web User Interface (WUI), Configuration Guide

GEO Sticky DNS, Feature Description

SSL Accelerated Services, Feature Description

Kemp Web Application Firewall, Feature Description

Last Updated Date

This document was last updated on 21 February 2022.