Kemp Support, how can we help?

The latest application delivery knowledge and expertise at your fingertips.

GEO Version 2.3.58.0 Release Notes

GEO Version 2.3.58.0 is a feature and bug fix update for the General Availability (GA) branch, made available on 27 October 2022. Please read the sections below before installing or upgrading to this release.

These notes list the fixes related directly to GEO product functionality. For a list of the new features, changes, and fixes in the base LMOS system on which GEO is running, please see the LoadMaster Release Notes for LMOS 7.2.58.0.

Upgrade Notes

Please see the LoadMaster Release Notes for LMOS 7.2.58.0 for a list of supported models for this release as well as for other upgrade notes, including how to validate the update image's digital signature.

Change Notices

GEO: Ignore ECS for Public/Private Decisions

Extended DNS (EDNS) Client Subnet (or ECS) is a GEO feature introduced in LMOS 7.2.57.0. This feature leverages a new field in Etended DNS packets that provides a client subnet value set by the client that provide better geographic location of the client compared to earlier versions of DNS without this capability.

Problem: When ECS in 7.2.57.0 is enabled, An incoming request that contains an ECS value always uses the ECS field value (and not the source IP of the request) to determine if a public or private IP should be returned to the client. With the default settings for Public and Private addresses, a private address is returned to the client that is likely not reachable from the client’s network.

Example: A client with a private IP address on Site A makes a DNS request to the local DNS server which forwards it to a public DNS server and then on to GEO. If all hops support ECS, then GEO sees the private IP address/subnet in the ECS field and so returns a private IP address. The client, however, will be unable to reach the expected application using that address.

Solution: The desired behavior is that GEO would instead use the source IP address of the request (which will be the last-hop public DNS server) to determine whether to return a public or private address.

  • Change the ECS default behavior so that ECS is ignored and the source IP is checked when the public/private settings are not both set to “all sites”.
  • Provide a switch (per FQDN) that allows the customer to opt-out of this new default behavior and honor the ECS instead.

The settings and corresponding behavior is summarized in the table below.

 

ECS Setting

Public & Private Settings

Public / Private Behavior Determined By …

New FQDN Option Effect when Enabled

OFF

Any

Request source IP

When ECS is disabled, the new option is ignored.

ON

!= "all sites"

Request source IP (ECS ignored)

The new FQDN option overrides the behavior at left, so that the request ECS value is used.

ON

= "all sites"

Request ECS value
(source IP ignored)

When the Public & Private settings are both “All Sites”, the new option is ignored.

Issues Resolved

LM-1503

GEO: Fixed an issue with high CPU consumption on units with a free license and GEO enabled.

LM-1134

GEO EDNS Client Subnet (ECS): It has been observed that with ECS enabled and an FQDN with the default private/public behavior selected, a private-network client may receive a non-routable DNS response in certain scenarios. This issue has ben addressed as described in the Change Notices section, above.

LM-864

GEO Performance: Starting with LMOS 7.2.55.0, a performance degradation has been seen where Queries per Second (QPS) can be up to 50% lower than with version 7.2.54 and previous releases. This issue has been addressed and performance levels have been returned to the levels stated in the data sheet.

New Known Issues

LM-1723 GEO Partnering: There is a small window of time during a partner sync where concurrent changes on the partners may not be reflected on both systems. The only workaround is to repeat the modification.
LM-1527 GEO Cluster Checks: GEO cluster checks against LoadMasters configured in Clustering mode do not work.

Existing Known Issues

LM-477

GEO Downgrade: When downgrading from a release that supports more than 64 IPs per FQDN to a release that only supports up to 64 IPs per FQDN, the GEO configuration may become corrupted if there is at least one FQDN in the configuration that contains more than 64 IP addresses. The corruption will likely be evidenced by errors in the UI/API when you list the FQDNs.

To avoid this issue entirely, reduce the number of IPs per FQDN to 64 or less for all FQDNs defined before you downgrade.

If you have already downgraded, you can switch back to the previous boot partition to go back to the newer release (which supports > 64 IPs per FQDN); you can then reduce the number of IPs as above and downgrade again.

If neither of these options is possible, please contact Kemp Support who will consult with engineering on a solution to your issues.      

PD-19704

GEO Cluster Status: When adding a Cluster that is unavailable (DOWN) to a Site, the Site may reflect the Cluster's status as available (UP) for a short time before changing to DOWN.  

PD-19108

LM-127

GEO: Modifying an FQDN entry displays a spurious error on the system console, similar to the one shown below. The FQDN is modified properly.

<FQDN>:794 Uncaught ReferenceError: disp_addrr_elements is not defined

    at <FQDN>:794

(anonymous) @ <FQDN>:794

PD-19093

LM-127

GEO: Cannot configure GEO into partnering mode unless there is at least one FQDN already defined.

PD-18615

LM-134

GEO: No statistics (queries per second, etc.) are displayed for a site if the FQDN is configured to use the "All Available" Selection Criteria.

PD-15633

GEO: If you add a Zone Name to GEO after you have created working FQDNs, GEO may no longer respond to queries for one or more of the FQDNs after the Zone Name is added. The workaround is to remove and then re-add the FQDNs that are no longer working.

PD-9765

GEO: DNS TCP requests from unknown sources are not supported.

 

 


Was this article helpful?
0 out of 0 found this helpful

Comments