Guest

Cisco ACE GSS 4400 Series Global Site Selector Appliances

Release Note for the Cisco Global Site Selector, Release 2.0(x)

  • Viewing Options

  • PDF (527.2 KB)
  • Feedback
Release Note for the Cisco Global Site Selector, Release 2.0(x)

Table Of Contents

Release Note for the Cisco Global Site Selector, Release 2.0(x)

Contents

Cisco-Supported Hardware and Software Compatibility

Before Upgrading to Software Version 2.0(x)

Removing Double Quotes from Object or Description Names

Backing Up Your Current Primary GSSM Database

Upgrading Sequence to Software Version 2.0(5)

Operating Consideration for Software Version 2.0(x)

Downgrading from Software Version 2.0(x) Rules

Downgrading Software Versions on GSS Devices

Downgrading to Version 1.3(2) or Higher

Downgrading a GSS 4490 or GSS 4491 to Version 1.3 (1) or Lower

Obtaining a Recovery Image and Creating a Recovery CD

Downgrading GSS 4490 Devices to Version 1.3(1) or Lower

Downgrading GSS 4491 Devices to Version 1.3(1) or Lower

Additional Information on CNR and DDoS Installation

New Features in Software Version 2.0(3)

GSS Supports Name Server Forwarding when CNR is Loaded

GSS Supports Both Scripted and KAL-AP Keepalives in a Multi-port Keepalive Answer

GSS Supports HTTPS Access for CNR GUI

Creating a Keystore File on a Linux Server

Copying a Keystore File to the GSS and Configuring the CNR GUI Access Mode

Troubleshooting Access Mode Change Problems

Understanding the CNR Access Mode when Enabling/Disabling or Upgrading/Downgrading the GSS

New Features and Performance Enhancements in Software Version 2.0(2)

Multiple NS Responses

Anycast Network Addressing and Routing Scheme

Anycast and the GSS Loopback Interface

Disabling Anti-Spoofing in the GSS

New Features in Software Version 2.0(1)

Software Version 2.0(5) Open and Resolved Caveats

Open Caveats for Software Version 2.0(5)

Resolved Caveats for Software Version 2.0(5)

Software Version 2.0(4) Open and Resolved Caveats

Open Caveats for Software Version 2.0(4)

Resolved Caveats for Software Version 2.0(4)

Software Version 2.0(3.0.31) Open Caveats, Resolved Caveats, and Command Changes

Open Caveats for Software Version 2.0(3.0.31)

Resolved Caveat for Software Version 2.0(3.0.31)

Software Version 2.0(3) Open Caveats, Resolved Caveats, and Command Changes

Open Caveats for Software Version 2.0(3)

Resolved Caveats for Software Version 2.0(3)

CLI Command Changes in Software Version 2.0(3)

GUI Changes in Software Version 2.0(3)

Software Version 2.0(2.1) Open Caveats and Resolved Caveat

Open Caveats for Software Version 2.0(2.1)

Resolved Caveat for Software Version 2.0(2.1)

Software Version 2.0(2) Open Caveats, Resolved Caveats, and Command Changes

Open Caveats for Software Version 2.0(2)

Resolved Caveats for Software Version 2.0(2)

CLI Command Changes in Software Version 2.0(2)

Software Version 2.0(1) Open Caveats, Resolved Caveats, and Command Changes

Open Caveat for Software Version 2.0(1)

Resolved Caveats for Software Version 2.0(1)

CLI Command Changes in Software Version 2.0(1)

Obtaining Documentation and Submitting a Service Request


Release Note for the Cisco Global Site Selector, Release 2.0(x)


February 2, 2009


Note The most current documentation for released products is available on cisco.com.


Contents

This release note applies to the following software versions for the Cisco Global Site Selector (GSS):

2.0(5)

2.0(4)

2.0(3.0.31)

2.0(3)

2.0(2.1)

2.0(2)

2.0(1)

For information on version 2.0 commands and features, refer to the GSS documentation located on cisco.com.

This document contains the following sections:

Cisco-Supported Hardware and Software Compatibility

Before Upgrading to Software Version 2.0(x)

Upgrading Sequence to Software Version 2.0(5)

Operating Consideration for Software Version 2.0(x)

Downgrading from Software Version 2.0(x) Rules

Downgrading Software Versions on GSS Devices

Additional Information on CNR and DDoS Installation

New Features in Software Version 2.0(3)

New Features and Performance Enhancements in Software Version 2.0(2)

New Features in Software Version 2.0(1)

Software Version 2.0(5) Open and Resolved Caveats

Software Version 2.0(4) Open and Resolved Caveats

Software Version 2.0(3.0.31) Open Caveats, Resolved Caveats, and Command Changes

Software Version 2.0(3) Open Caveats, Resolved Caveats, and Command Changes

Software Version 2.0(2.1) Open Caveats and Resolved Caveat

Software Version 2.0(2) Open Caveats, Resolved Caveats, and Command Changes

Software Version 2.0(1) Open Caveats, Resolved Caveats, and Command Changes

Obtaining Documentation and Submitting a Service Request

Cisco-Supported Hardware and Software Compatibility

GSS software version 2.0(x) installed on a GSS 4492R, GSS 4491, GSS 4490, or GSS 4480 operates with all load balancers if ICMP, TCP, or HTTP-HEAD-type keepalives are used. In addition, KAL-AP-type keepalives can be used with a Cisco Content Services Switch (CSS) or Catalyst 6500 Series Content Switching Module (CSM) to support more effective load balancing.

GSS software version 2.0(x) operates with the following Cisco hardware:

Cisco Content Services Switch (CSS) running the following WebNS software releases:

Cisco CSS Platform
Recommended WebNS Versions
Minimum Supported WebNS Versions

Cisco 11500 Series CSS

Software releases:

7.40.0.04 or greater

7.30.2.03 or greater

Software releases:

7.20.1.04

7.10.3.05

Cisco 11000 Series CSS

Software releases:

6.10.4.05 or greater

5.00.6.05 or greater

Software releases:

6.10.1.07

5.00.3.09


Catalyst 6500 Series Content Switching Module (CSM) running the following software releases:

Platform
Recommended CSM Versions 1
Minimum Supported CSM Versions

Catalyst 6500 Series

Software releases:

3.1(10) or greater

3.2(1)

4.1(4) or greater

4.2(1) or greater

Software releases:

3.1(4)

3.2(1)

4.1(4)

4.2(1)

1 CSM software versions 3.2(2), 3.2(3), and 4.1(2) are not supported by the GSS when using the KAL-AP by tag keepalive method.


In addition, you can use scripted keepalives with the following Cisco and non-Cisco hardware.

Device
Scripted Keepalive Types
Platform
Recommended Software Version

CSS

CSS wrapper

Cisco 11500 series CSS

SLB: 7.40.0.04 or higher

SNMP_mib_not_index_by_vip

Cisco 11000/11500 series CSS

SLB: 6.10.4.05 or higher for 11000 series

SLB: 7.40.0.04 or higher for the 11500 series

Snmp-scalar

CSM

CSM wrapper

Cisco Catalyst 6500 CSM

IOS: 12.2

CSM: 4.2(1)

SNMP_mib_not_index_by_vip

Snmp-scalar

Note: Non-Cisco SLBs are supported for scripted keepalives. For more information, see Chapter 5, Configuring Keepalives, in the Cisco Global Site Selector CLI-Based Global Server Load- Balancing Configuration Guide.


Before Upgrading to Software Version 2.0(x)

Before you upgrade the GSS to software version 2.0(x), perform the following tasks:

Determine if you need to perform the steps to remove double quotes from names and associated description strings. GSS software versions 1.3(1) and 1.3(2) do allow the use of double quotes for names and associated description strings; however, version 2.0(x) does not support the use of double quotes. Follow the steps in the "Removing Double Quotes from Object or Description Names" section.

Perform a full backup of your primary GSSM database using the links provided in the "Backing Up Your Current Primary GSSM Database" section.

This section contains the following topics:

Removing Double Quotes from Object or Description Names

Backing Up Your Current Primary GSSM Database

Removing Double Quotes from Object or Description Names

If you are upgrading from GSS software version 1.3(3) to version 2.0(x), you can disregard the information in this section. However, if you are upgrading directly from versions 1.3(1) or 1.3(2), be aware that these software versions allow the use of double quotes for names and associated description strings, which version 2.0(x) does not allow. Remove double quotes (for example, dns rule "01" or dns rule "02") before upgrading to software version 2.0(x). Otherwise, the CLI may contain objects that you cannot delete unless you restore the factory defaults.

Perform these steps to remove double quotes:

1. Perform a full backup of your primary GSSM database. For details on performing a full backup, see Chapter 7, Backing Up, Restoring, and Downgrading the GSSM, the "Backing Up the Primary GSSM" section in the Cisco Global Site Selector Administration Guide. Provide a unique name for the backup file (this is the backup file that includes double quotes). If you need to downgrade in the future, you can use this file to restore your unmodified 1.3(1) and 1.3(2) database.

2. In GSS software versions 1.3(1) and 1.3(2), access the GUI at the primary GSSM. Locate and remove the double quotes from any object names or associated descriptions.

3. Perform a full backup of your modified primary GSSM database. Provide a unique name for the modified backup file. If you need to downgrade in the future, you can use this file to restore your modified 1.3(1) and 1.3(2) database.

4. Upgrade to GSS software version 2.0(x) as described in the Cisco Global Site Selector Administration Guide, Appendix A, Upgrading the GSS Software.

Backing Up Your Current Primary GSSM Database

Before you upgrade, you must back up your current primary GSSM database in the event that you need to restore your database. If you have CNR loaded on the primary GSSM, you must disable CNR before you back up your current primary GSSM database and then enable CNR when you complete the upgrade. To disable CNR, use the no cnr enable command in configuration mode. To enable CNR, use the cnr enable command in configuration mode

Refer to the appropriate instructions for backing up your version of GSS software:

For software version 2.0(x), see Chapter 7, Backing Up, Restoring, and Downgrading the GSSM, the "Backing Up the Primary GSSM" section in the Cisco Global Site Selector Administration Guide. Also, review the software version 2.0(x) software upgrade sequence as described in the Cisco Global Site Selector Administration Guide, Appendix A, Upgrading the GSS Software.

For software version 1.2 and 1.3, see Chapter 7, Backing Up and Restoring the GSSM, the "Backing Up the Primary GSSM" section in the Cisco Global Site Selector Administration Guide.

For software version 1.1, see Chapter 9, GSS Administration and Troubleshooting, the "Backing Up the GSSM" section in the Cisco Global Site Selector Configuration Guide.

For software version 1.0, see Chapter 3, GSS Administration and Troubleshooting, the "Backing Up the GSSM" section in the Cisco Global Site Selector Configuration Guide.

Upgrading Sequence to Software Version 2.0(5)

When upgrading your GSS devices to software version 2.0(5), you must complete the applicable upgrade sequence upgrade on each GSS device in the network. You must also complete an upgrade before you change the role of a GSS device.

Refer to Table 1 for information on the upgrade sequence for previous software versions before you upgrade to software version 2.0(5). For more information on upgrading to GSS software version 2.0(5), see Appendix A, "Upgrading the GSS Software" in the Cisco Global Site Selector Administration Guide.

Table 1 GSS Software Upgrade Sequence

From version . . .
To version . . .

1.0(x) or

1.1 (prior to 1.1.(1.7.0))

1.1.(1.7.0)

1.1.(1.7.0)

1.2.(2.2.0)

1.2 (x) where x = 1 or 2

1.3(x) where x = 1, 2,or 3

1.3(x)

2.0(x) where x = 1 or 2

2.0(1)

2.0(x) where x = 2, 3, 4, or 5

2.0(2)

2.0(x) where x = 3, 4, or 5

2.0(3)

2.0(x) where x = 4 or 5

2.0(4)

2.0(5)


Note that beginning with version 1.(3), alternate sequential paths may exist that provide a more direct path to the targeted upgrade version. For example, to upgrade from version 2.0(3) to version 2.0(5), you can use either the sequential upgrade path 2.0(3) > 2.0(4) > 2.0(5) or the more direct 2.0(3) > 2.0(5) path.

Operating Consideration for Software Version 2.0(x)

Cisco LocalDirector does not reply properly to TCP keepalives sent on port 23 from a GSS device. To correct this behavior, specify a different keepalive method with LocalDirector or directly probe the servers located behind LocalDirector. Refer to the LocalDirector documentation for more information.

Downgrading from Software Version 2.0(x) Rules

Observe the following rules when downgrading from version 2.0(4):

When downgrading from software versions 2.0(3) or 2.0(4) to 1.3(x), be aware that if you configured the RTT value to greater than 500 milliseconds (ms) in versions 2.0(3) or 2.0(4), the RTT value may display incorrectly in the GUI. For example, if you configure 1234 in version 2.0(4) and then downgrade to version 1.3(x), the value shown in the GUI is 123 because the last character is dropped from the entry.

When downgrading from versions 2.0(3) or 2.0(4) to 2.0(1.0.7), be aware that if you configured the RTT value to greater than 1500 ms in versions 2.0(3) or 2.0(4), the RTT value may display incorrectly in the GUI due to the increase of the acceptable-rtt range from 50 to 1500 ms to 50 to 2000 ms implemented in version 2.0(3). For more information on this enhancement, see Table 4.

After the downgrade, you must restore the backup of the primary GSSM database that corresponds to the downgrade software version. For example, if you wish to downgrade to version 1.3(2), you must have a software release version 1.3(2) database backup that you can restore.

Downgrading Software Versions on GSS Devices

Observe the following hardware platform-dependent rules when downgrading your GSS devices to a software version lower than 2.0(4):

Model 4492 platform—Supports software downgrades to version 1.3(2) or higher only. This model does not support the versions lower than version 1.3(2) because of a change to the OS kernel.

Model 4491 platform—Supports software downgrades to version 1.2(2) or higher only. This model does not support the versions lower than version 1.2(2) because of a change to the OS kernel.

Model 4490 platform—Supports software downgrades to version 1.2(2) or higher only. This model does not support the versions lower than version 1.2(2) because of a change to the OS kernel.

Model 4480 platform—Supports all software downgrade versions. To downgrade the software on a 4480 device to a version lower than version 1.3(2), you must make RMA arrangements to return the devices to Cisco for the downgrade.


Note If the GSS has CNR loaded on it, the lowest software version that you can downgrade to is version 2.0(1); however, we recommend that you do not downgrade lower than GSS version 2.0(3) when using CNR.


To perform a downgrade, you must disable the entire GSS network.

If you have any questions about the need to downgrade your system, contact Cisco Technical Assistance Center (TAC). See the "Obtaining Documentation and Submitting a Service Request" section for more information.

This section contains the following topics:

Downgrading to Version 1.3(2) or Higher

Downgrading a GSS 4490 or GSS 4491 to Version 1.3 (1) or Lower

Downgrading to Version 1.3(2) or Higher

Use the procedure in this section to downgrade to software version 1.3(2) or higher on any of the four GSS models. If you are downgrading a 4491 or 4490 to a version lower than version 1.3(2), see the "Downgrading a GSS 4490 or GSS 4491 to Version 1.3 (1) or Lower" section.

To downgrade to version 1.3(2) or higher, perform the following steps:

1. Obtain a copy of the downgrade software version from cisco.com.

2. Ensure that you have a copy of the database that was saved when the version of software that you are downgrading to was running on the GSS.

3. Disable the GSS network by performing the following steps in privileged EXEC mode on each GSS:

a. Stop the GSS software by using the gss stop command in privileged EXEC mode.

gssm1.example.com# gss stop

b. If CNR is loaded on any of the GSS devices, enter configuration mode and disable CNR by using the no cnr enable command.

gssm1.example.com (config)# no cnr enable

If CNR is not loaded on the GSS, skip ahead to Step d.

c. Type exit to exit configuration mode.

d. Disable the GSS by using the gss disable command in privileged EXEC mode.

gssm1.example.com# gss disable

4. Install the downgrade by using the install command in privileged EXEC mode.

gssm1.example.com# install gss.upg

This command performs a validation check on the upgrade file, unpacks the upgrade archive, and installs the software upgrade.

5. At the Proceed with install (the device will reboot)? (y/n): prompt, type y to reboot the GSS device. After the GSS reboots, you lose any network CLI connections. Console connections remain active.


Note If you did not previously save changes to the startup-config file, the Save current configuration? [y/n]: prompt appears. At the prompt, type n to continue. The GSS then reboots.


6. After the GSS device reboots, log in to the GSS device and enable privileged EXEC mode.

7. Verify that the GSS device reaches a normal operation state of runmode 4 or 5 by using the gss status command in privileged EXEC mode.

8. Restore the database (see the Cisco Global Site Selector Administration Guide, Chapter 7, Backing Up and Restoring the GSSM Database).

9. Enable CNR if the GSS has CNR loaded on it by using the cnr enable command in configuration mode.

gssm1.example.com (config)# cnr enable 

10. Repeat Steps 2 through 10 for the remaining GSS devices in your network.

Downgrading a GSS 4490 or GSS 4491 to Version 1.3 (1) or Lower

Use the procedures in this section to downgrade a GSS 4491 or GSS 4490 to a version of software that is version 1.3(1) or lower, with the lowest supported version being version 1.2(2). For all other types of GSS downgrades, see the "Downgrading to Version 1.3(2) or Higher" section.


Note If the GSS has CNR loaded on it, the lowest software version that you can downgrade to is version 2.0(1); however, we recommend that you do not downgrade lower than GSS version 2.0(3) when using CNR.


The requirements to downgrade a GSS 4491 or GSS 4490 to a version of software that is version 1.3(1) or lower are as follows:

Full backup of your primary GSSM database—You need the database backup that corresponds to the software version to which you wish to restore. Use the backup to restore the database on the primary GSSM after the downgrade.

Recovery image and associated recovery CD—You obtain a recovery image for the specific downgrade version from Cisco and then create a CD from the image.

Keyboard, mouse, and monitor—You must connect locally to the GSS to perform the types of software downgrades described in this section.

This section contains the following topics:

Obtaining a Recovery Image and Creating a Recovery CD

Downgrading GSS 4490 Devices to Version 1.3(1) or Lower

Downgrading GSS 4491 Devices to Version 1.3(1) or Lower

Obtaining a Recovery Image and Creating a Recovery CD

This section describes how to obtain the recovery image from Cisco and create a recovery CD. If necessary, contact Cisco Technical Assistance Center (TAC) for more information about obtaining the recovery image.

You must have a Cisco.com username and password to download a software update from Cisco.com. To acquire a Cisco.com login, go to http://www.cisco.com and click the Register link. You also need a service contract number, Cisco.com registration number and verification key, Partner Initiated Customer Access (PICA) registration number and verification key, or packaged service registration number to obtain a Cisco.com username and password.

To obtain the recovery image and create a CD, perform the following steps:

1. Use your preferred web browser to access the recovery image at https://upload.cisco.com/cgi-bin/swc/fileexg/main.cgi?CONTYPES=GSS_Forum

2. Locate the GSSRecoverySoftware.iso file. Confirm these file properties:

owner: rongole

date: 16-MAY-2006

size: 194117632 bytes

3. Click on the file. If prompted by the software, reenter your username and password, and then click OK.


Note The GSS recovery software is considered a strong encryption image. If you are not eligible to receive strong encryption images, you will be prompted to complete the Encryption Software Distribution Authorization Form. Complete the form to access and download the GSS recovery software.


4. If prompted, complete the Encryption Software Distribution Authorization Form (see the previous Note).

5. When the End User License Agreement opens, read the license agreement, and then click I agree. The File Download page opens.

6. Click Save, and then choose a location on your workstation to temporarily store the recovery file.

7. Use your preferred CD-creation software to burn the recovery file to a CD.

8. Before attempting to use the recovery CD, run an md5 checksum on the file using a tool, such as md5sum on Linux, and confirm that the value is b84ff87e04f7b2a95dcf2afe06b02f01.

Downgrading GSS 4490 Devices to Version 1.3(1) or Lower

Before you downgrade, perform the following steps:

1. Verify the role of the primary GSSM in the GSS network (see the Cisco Global Site Selector Administration Guide, Appendix A, Upgrading the GSS Software).

2. Connect your keyboard and mouse to their corresponding ports on the GSS 4490 device.

3. Connect the monitor to the GSS console port.

To use the recovery CD to downgrade each GSS 4490 device on your network, perform the following steps:

1. Insert the recovery CD into the CD-ROM drive on the GSS.

2. Power cycle the GSS and press F1 during the initial startup sequence to enter the BIOS Setup.

3. Choose Start Options, and then press Enter.

4. Choose Startup Sequence, and then press Enter.

5. Navigate to First Startup Device, and then change the state to Disabled.

6. Navigate to Second Startup Device, and then change the state to Disabled.

7. Navigate to First Startup Device again, and then choose CD-ROM.

8. Navigate to Second Startup Device again, and then choose Hard Disk 0.

9. Press Esc three times. When prompted, choose If yes, Save and Exit the Setup Utility, and then press Enter. The GSS boots from the recovery CD and displays the Rescue prompt.

10. Enter gss-rescue at the prompt, and then press Enter.

11. When "Sleeping..." displays, press the Ctrl, Alt, and Delete keys or power cycle by pressing the power button to reboot the GSS, and then press F1 during the initial startup sequence to reenter the BIOS Setup.

12. Power cycle the GSS and press F1 during the initial startup sequence to enter the BIOS Setup.

13. Choose Start Options, and then press Enter.

14. Press Enter again to select Startup Sequence.

15. Navigate to First Startup Device, and then change the state to Disabled.

16. Navigate to Second Startup Device, and then change the state to Disabled.

17. Navigate to First Startup Device again, and then choose Hard Disk 0.

18. Navigate to Second Startup Device again, and then choose CD-ROM.

19. Press Esc three times. When prompted, choose If yes, Save and Exit the Setup Utility, and then press Enter. The GSS boots.

20. Restore your primary GSSM (see the Cisco Global Site Selector Administration Guide, Chapter 7, Backing Up and Restoring the GSSM Database).

Downgrading GSS 4491 Devices to Version 1.3(1) or Lower

Before you downgrade, perform the following steps:

1. Verify the role of the primary GSSM in the GSS network (see the Cisco Global Site Selector Administration Guide, Appendix A, Upgrading the GSS Software).

2. Connect your keyboard and mouse to their corresponding ports on the GSS 4491 device.

3. Connect the monitor to the GSS console port.

To use the recovery CD to downgrade each GSS 4491 device on your network, perform the following steps:

1. Insert the recovery CD into the CD-ROM drive on the GSS.

2. Power cycle the GSS and press F4 during the initial startup sequence to enter the BIOS Setup.

3. At the BIOS Setup screen, choose the Boot menu.

4. Choose the Boot Device Priority menu.

5. Choose ATAPI CD-ROM as the first device from which to boot.

6. Save the settings and exit from the BIOS. The GSS boots from the recovery CD and displays the Rescue prompt.

7. Enter gss-rescue at the prompt, and then press Enter.

8. When "Sleeping..." displays, press the Ctrl, Alt, and Delete keys or power cycle by pressing the power button to reboot the GSS, and then press F4 during the initial startup sequence to reenter the BIOS Setup.

9. At the BIOS Setup screen, choose the Boot menu, choose the Boot Device Priority menu, and then choose Hard Drive as the first device from which to boot.

10. Save the settings.

11. Remove the recovery CD and then exit from the BIOS. The GSS boots.

12. Restore your primary GSSM (see the Cisco Global Site Selector Administration Guide, Chapter 7, Backing Up and Restoring the GSSM Database).

Additional Information on CNR and DDoS Installation

Figure 1 and Figure 2 provide flowcharts showing the steps you need to follow when installing and enabling the CNR and DDoS licenses, respectively. These figures augment the material provided in Chapter 2, Managing the GSS from the CLI, in the Cisco GSS Administration Guide.

Figure 1 Installing and Enabling CNR

Figure 2 Installing and Enabling DDoS

New Features in Software Version 2.0(3)

This section describes the new features of software version 2.0(3) and contains the following topics:

GSS Supports Name Server Forwarding when CNR is Loaded

GSS Supports Both Scripted and KAL-AP Keepalives in a Multi-port Keepalive Answer

GSS Supports HTTPS Access for CNR GUI

GSS Supports Name Server Forwarding when CNR is Loaded

When a GSS is operating with a software version prior to version 2.0(3) and you have the Cisco Network Registrar (CNR) software loaded on it, the Name Server Forwarding operation does not work. The software allows you to configure Name Server Forwarding, but the GSS is unable to perform the operation.

GSS versions 2.0(3) and higher remove this restriction and enables a GSS administrator to support more complex deployments where they can control which DNS request will be forward to the internal CNR code or to an external DNS name server. This feature adds in the migration of general DNS configuration to the GSS/CNR solution.

The type of deployments supported by this enhancement are as follows:

DNS deployments (improves co-existence with the deployed DNS products)

GSS/CNR as a client facing DNS name server

GSS/CNR as a top level domain (TLD)

GSS/CNR as a secondary to an existing primary DNS name server

GSS/CNR as a primary to an existing DNS name server


Note This new feature does not require any changes to the CLI or GUI and is transparent to the GSS user. For example, to configure a name server (NS)-type answer using the CLI, use the existing answer ns ip_address command in global server load-balancing configuration mode. For details about configuring Name Server Forwarding on the GSS, see the Cisco Global Site Selector CLI-Based Global Server Load-Balancing Configuration Guide or the Cisco Global Site Selector GUI-Based Global Server Load-Balancing Configuration Guide.


When a client D-proxy sends query to the GSS that has CNR loaded and is also configured to use external name servers, the following sequence of actions occur:

1. The GSS performs a global server load balancing (GSLB) lookup on the query to see if the answer is contained within its database. The GSS performs one of the following actions depending on the answer type and the answer operating state:

If the answer type is VIP and the answer is online, the GSS sends the answer to the client D-proxy.

If the answer type is VIP and the answer is offline, the GSS retrieves and sends a fallback answer to the client D-proxy.

If the last clause answer type is VIP and the answer is offline, the GSS sends a SERVFAIL response to the client D-proxy.

If the answer type is NS, the GSS forwards the query to the name server called for in the NS Forwarding definition. The name server responds to the D-proxy through the GSS (the GSS acts as a proxy).

2. If the GSS performs a GSLB lookup and cannot find an answer to the query, the GSS behaves as follows depending on the CNR operating state:

CNR enabled—The GSS forwards the query to the CNR and the CNR, which forwards the response to the client D-proxy.

CNR disabled—The GSS sends a negative response (NXDOMAIN) to the client D-proxy.

GSS Supports Both Scripted and KAL-AP Keepalives in a Multi-port Keepalive Answer

Prior to GSS version 2.0(3), the software did not allow you to configure both a KeepAlive-Application Protocol (KAL-AP) keepalive and a Scripted keepalive in a Multi-port keepalive answer. Versions 2.0(3) and higher allow you to configure a multi-port keepalive answer with the following:

Both keepalive types: KAL-AP keepalive and Scripted keepalive

Multiple Scripted keepalives

If you attach a KAL-AP and Scripted keepalive to an answer, you cannot use the Scripted keepalive to return the load value from a MIB object (you must configure it as a 'use-load disable' Scripted keepalive type). The KAL-AP keepalive returns the load value while the Scripted keepalive is used to probe the device for status (online or offline) only. The Answer status depends on all of the keepalives that you attach to an answer.

If you attach more than one Scripted keepalive to an answer, you can use only one of them to retrieve the load value. You must configure one Scripted keepalive as a 'use-load enable' Scripted keepalive type to retrieve the load value and configure all of the remaining Scripted keepalives as 'use-load disable'. The use-load disable Scripted keepalives are used to probe for device status (online or offline) only. The Answer status depends on all of the keepalives that you attach to an answer.

When configuring a Multi-port keepalive answer, observe the following rules:

A multi-port keepalive answer can contain one KAL-AP keepalive only.

When using a combination of KAL-AP and a Scripted keepalives, do not configure the Scripted keepalives for load enable. For this application, only the KAL-AP keepalive is used to retrieve the load value.

When the Multi-port keepalive answer is to contain multiple Scripted keepalives and no KAL-AP keepalive, configure only one Scripted keepalive for load enable to retrieve the load value. Configure the remaining Scripted keepalives for device status retrieval only.

Prior to 2.0(3), the GSS could not monitor the MIBs on a third-party SLB or VPN concentrator that used different values to represent the online and offline status of the device. For example, one device might use the values 10 to indicate an online status and 11 to indicate an offline status. Another device might use 25 for the online status and 26 for the offline status. Using different status values prevented the GSS from monitoring the device status. Installing version 2.0.(3) on the GSS allows you to define the online and offline status values that correspond to the third-party MIB.

Use a KAL-AP keepalive and Scripted keepalive combination to perform the following operations:

Globally load balance a SLB (such as a CSS, CSM, or an ACE) using KAL-AP.

Check the performance of the back-end server cluster using Scripted keepalives if the back-end server cluster supports performance MIB objects. The Scripted keepalive uses the SNMP get request to fetch the load information from the target device.

For details about the associated changes made to the CLI and GUI interfaces for this new feature, see the "CLI Command Changes in Software Version 2.0(3)" and "GUI Changes in Software Version 2.0(3)" sections.

GSS Supports HTTPS Access for CNR GUI

Prior to GSS version 2.0(3), the GSS software permitted HTTP access only for the CNR GUI. Installing version 2.0(3) allows you to enable HTTP, HTTPS, or both HTTP and HTTPS access for the CNR GUI. By default, only HTTP access on port 8080 is enabled when you install CNR on the GSS. The procedures in this section describes how generate a required keystore file and then enable HTTPS access on port 8443.

To perform the following procedures, you must have the following items in place:

Separate Linux server for generating a keystore file (the GSS does not have the capability to generate a keystore file).

Access to a Certificate Authority (CA) to submit a Certificate Signing Request (CSR).

Administrative access to the GSS.

CNR installed on the GSS.

This section contains the following topics:

Creating a Keystore File on a Linux Server

Copying a Keystore File to the GSS and Configuring the CNR GUI Access Mode

Troubleshooting Access Mode Change Problems

Understanding the CNR Access Mode when Enabling/Disabling or Upgrading/Downgrading the GSS

Creating a Keystore File on a Linux Server

To create a keystore file on a Linux server, perform the following steps:

1. Log in to the Linux server using an account that has administrative privileges.

2. If necessary, download and install Java Runtime Environment (JRE) 1.4.2 or later, or the equivalent Java Development Kit (JDK). These are available from Sun Microsystems at its download website.

3. Create a keystore file containing a self-signed certificate by entering the following command and responding to the system prompts that define the certificate distinguished name attributes:

keytool -genkey -alias tomcat -keyalg RSA -keystore k-file

The k-file argument is the keystore filename and its fully qualified path.

For example:

> keytool -genkey -alias tomcat -keyalg RSA -keystore gss_keystore

. . .

Enter keystore password: password

What is your first and last name? [Unknown]: name

What is the name of your organizational unit? [Unknown]: org-unit

What is the name of your organization? [Unknown]: org-name

What is the name of your City or Locality? [Unknown]: local

What is the name of your State or Province? [Unknown]: state

What is the two-letter country code for this unit? [Unknown]: cc

Is CN=name, OU=org-unit, O=org-name, L=local, ST=state, C=cc correct? [no]: yes

Enter key password for <tomcat> (RETURN if same as keystore password):

The arguments for the distinguished name attributes are as follows:

password—Keystore password.

name—Name (or common name) of the person assigned to the certificate.

org-unit—The name of the organizational unit within the organization.

org-name—Name of the organization.

local—Location (city) of the organization.

state—State (or province) where the organization is located.

cc—Country code where the organization is located.

4. Create a CSR to submit to the CA when you request a certificate by entering the following command:

keytool -certreq -keyalg RSA -alias tomcat -file certreq.cer -keystore k-file

The k-file argument is the keystore filename and its fully qualified path.

5. Submit the resulting certreq.cer file to the CA.

6. When you receive the certificate from the CA, download the Chain Certificate from the CA and then import the Chain Certificate and your new Certificate into the keystore file using the following commands:

keytool -import -alias root -keystore k-file -trustcacerts -file chain-cert-file

keytool -import -alias tomcat -keystore k-file -trustcacerts -file new-cert-file

The arguments are as follows:

k-file—Keystore filename and its fully qualified path.

chain-cert-file—Chain Certificate filename and its fully qualified path.

new-cert-file—Certificate filename and its fully qualified path.

Copying a Keystore File to the GSS and Configuring the CNR GUI Access Mode

To copy the keystore file from the Linux server to the GSS and enable HTTPS access, perform the following steps from the GSS:

1. Copy the keystore file to the GSS using one of the following command in exec mode:

Using Secure Copy Protocol (SCP):

scp {user@source_host:/source_path[source_filename] target_path}

The keywords are as follows:

user@target_host:target_path—Login account name and hostname for the device to which you are copying files.

source_filename—(Optional) Name of the file to be copied.

target_path—Relative directory path on the target device to which the file is being copied.

Using File Transfer Protocol (FTP):

ftp ip_or_host

The ip_or_host argument is the IP address or hostname of the FTP server that you want to access. Enter an IP address in dotted-decimal notation (for example, 192.168.11.1) or a mnemonic hostname (for example, myhost.mydomain.com).

2. Disable CNR using the following command in configuration mode:

no cnr enable

For example:

gss.example.com# config
gss.example.com(config)#  no cnr enable

3. Configure the CNR GUI access mode using the following command in exec mode:

cnr access-mode enable {http | https | both}

For example:

gssm1.example.com# cnr access-mode enable https

For details about using the cnr access-mode enable command, see the "CLI Command Changes in Software Version 2.0(3)" section.

4. If you enable HTTPS access using the https or both keywords, answer the CLI prompts that request the keystore filename (including the path) and password.

5. Enable CNR using the following command in configuration mode:

cnr enable

For example:

gss.example.com# config
gss.example.com(config)# cnr enable


Caution If you enable HTTPS access and then move or modify the keystore file, HTTPS access will not work.

To display the current CNR access mode setting, use the following command in enable mode:

show cnr access-mode

Troubleshooting Access Mode Change Problems

Table 2 provides a list of the error conditions that the GSS CLI displays when it encounters a problem attempting to make a requested change to the CNR GUI access mode.

Table 2 Troubleshooting Access Mode Change Problems

Error Message
Description

% ERROR: CNR is not installed

You attempted to change the access mode on a GSS that does not have CNR installed.

% ERROR: CNR is enabled. Please disable CNR before changing the access modes

You attempted to change the access mode before disabling CNR.

Keystore file not found. Failed to change access mode.

While attempting to enable HTTPS access, you entered an invalid keystore file path.

The GSS does not change the access mode (the previously enabled access mode remains in effect).

Keystore file is tampered, or invalid keystore password. Failed to change the access mode

While attempting to enable HTTPS access, you entered an invalid keystore file or invalid password.

The GSS does not change the access mode (the previously enabled access mode remains in effect).


Understanding the CNR Access Mode when Enabling/Disabling or Upgrading/Downgrading the GSS

CNR access mode operating characteristics include the following:

Disabling the GSS has no affect on the CNR access mode, which remains as you have it configured even after disabling the GSS.

If you enable HTTPS access and then downgrade the GSS to a version of software older than 2.0(3), the HTTPS access mode remains enabled; however, the cnr access-mode enable command is no longer available, making it impossible to change the CNR access mode. The show cnr access-mode command is also unavailable in the older software version.

HTTPS is available on GSS version 2.0.3 and above only. If you have CNR installed on a GSS using an earlier software version, you can enable HTTPS access for the CNR GUI by upgrading to 2.0.3. After upgrading to 2.0.3, you can then use the cnr access-mode enable command to enable HTTPS access for the CNR GUI (see the "Copying a Keystore File to the GSS and Configuring the CNR GUI Access Mode" section.

New Features and Performance Enhancements in Software Version 2.0(2)

The following new features have been added to software version 2.0(2): Multiple NS responses and Anycast network addressing and routing scheme. In addition, there have been a number of enhancements that improve performance on the GSS 4492 device by a maximum of 40 percent.

This section contains the following topics:

Multiple NS Responses

Anycast Network Addressing and Routing Scheme

Multiple NS Responses

When the GSS global server load balancer (GSLB) returns multiple records for a domain, the load-balancing algorithm in GSS software version 2.0(1) considered only the first record and load balanced it. With multiple name server (NS) responses, all of the records sent by the GSLB are considered in software version 2.0(2) and load balanced when the Cisco Network Registrar (CNR) is enabled.

When a query is forwarded to CNR and it responds with A-records in the additional section of the answer, these A-records are load balanced. For each A-record in the additional section, a query is sent to the GSS global server load balancer (GSLB) to have it load balanced.

If the GSLB returns more than one record for a specific domain, the load-balancing algorithm considers all records and appropriately changes the additional section. The number of answers the GSLB can return for a domain varies from one to eight.

For example, consider the following GSS and CNR configuration and the effect that multiple NS responses have on the additional section of the answer:

GSS

ns2.example.com A 1.2.3.4 
ns2.example.com A 5.6.7.8 
ns2.example.com A 9.0.1.2 (multiple answers are configured for the same domain.) 

The return count for the domain ns2.example.com is increased to three.

CNR

ns1.example.com NS ns2.example.com. 
ns2.example.com A 11.22.33.44 

Without multiple NS responses, when the GSS is queried for "ns1.example.com query type NS," the answer is similar to the following:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 

;; QUERY SECTION:
;; ns1.example.com, type = NS, class = IN

;; ANSWER SECTION:
ns1.example.com. 1m40s IN NS ns2.example.com.

;; ADDITIONAL SECTION:
ns2.example.com. 1m40s IN A 1.2.3.4

Note that the load-balancing algorithm load balances the record in the additional section, but only considers the first answer.

With multiple NS responses, when the GSS is queried for "ns1.example.com query type NS", the answer is similar to the following:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 3

;; QUERY SECTION:
;; ns1.example.com, type = NS, class = IN

;; ANSWER SECTION:
ns1.example.com. 1m40s IN NS ns2.example.com.
;; ADDITIONAL SECTION:
ns2.example.com. 1m40s IN A 1.2.3.4
ns2.example.com. 1m40s IN A 5.6.7.8
ns2.example.com. 1m40s IN A 9.0.1.2

Note that the load-balancing algorithm considers all of the answers from the GSLB and changes the header to reflect the increased number of records in the additional section.

Anycast Network Addressing and Routing Scheme

The anycast network addressing and routing scheme (anycast) provides high availability and load balancing for stateless services, such as access to replicated data. For example, the Domain Name Service (DNS) is a distributed service over multiple geographically dispersed servers.

Anycast works with the routing topology to route data to the nearest or best destination. There is also a one-to-many association between network addresses and network endpoints, which means that each destination address identifies a set of receiver endpoints, only one of which receives information from a sender at any time.

On the Internet, anycast is usually implemented by using the Border Gateway Protocol (BGP) to simultaneously announce the same destination IP address range from many different devices. This allows packets addressed to destination IP addresses in a specific range to be routed to the nearest point announcing the given destination IP address.

Anycast is best suited to connectionless protocols (generally built on the User Datagram Protocol (UDP)), rather than connection-oriented protocols such as the Transmission Control Protocol (TCP) that keep their own state. Thus, the designated receiving device may change from time to time as optimal routes change, terminating any connections currently in progress without sending out broadcast messages indicating the connections have been terminated.

IP anycast allows the use of the same public IP address for multiple devices (in this case, multiple GSSs). In IPv4, an IP anycast IP address is treated the same as any other routable, public IP addresses. The difference is the anycast IP address is announced from multiple sites and the service provider with multiple routes finds the closest exit. It is critical that core sites be paired with Solution Provider (SP) routers or Points Of Presence (POPs) within the same city or region. Otherwise, anycast may degrade system performance.

The sections that follow discuss how the GSS uses the loopback interface and how to disable anti-spoofing in the Distributed Denial of Service (DDoS) function:

Anycast and the GSS Loopback Interface

Disabling Anti-Spoofing in the GSS

Anycast and the GSS Loopback Interface

The GSS uses the loopback interface (lo:1) internally to assign an anycast IP address to a GSS device. The advantage of the loopback interface is the anycast IP address is not broadcast on the network, so you can easily deploy multiple GSSs in the same data center, or across multiple data centers, without an IP address conflict. Because IP anycast configuration is performed per GSS, you must configure IP anycast individually on each GSS. To configure the anycast IP address, use the new ip anycast command as described in Table 4.

The GSLB listens on an anycast IP address in addition to the following Ethernet interfaces:

TCP: port 53

UDP: port 53, port 5300 (AS), port 5301 (NS)

The anycast IP interface is not supported on the following features:

Director Response Protocol (DRP) agent

Inter-GSS communications

All types of keepalives

Administration, including programs such as TELNET, SSH, SNMP, FTP, NTP, and HTTPS

CNR zone transfer

DDoS with anti-spoofing enabled

Disabling Anti-Spoofing in the GSS

The Distributed Denial of Service (DDoS) function performs anti-spoofing (AS) by redirecting a DNS request over TCP. In GSS version 2.0(2), you can optionally turn off AS to allow the DDoS function to provide protection through rate limiting, even when TCP traffic cannot reach the GSS.

To disable AS, use the new ddos disable-as configuration command described in Table 4. When you disable anti-spoofing, the unknown rate limit is also disabled. The individual rate limit per D-proxy will work as expected, however.

New Features in Software Version 2.0(1)

The new features in software version 2.0(1) are as follows:

Unique Device Identifier (UDI)—Provides a hardware product identification standard that is consistent across Cisco products. It allows you to uniquely identify and track your Cisco products through your business and network operations.

Scripted Keepalive—Allows you to probe non-Cisco devices and obtain the load information by using the SNMP get request to fetch the load information from the target device.

Path-probing proximity enhancement—Makes a best effort to calculate the relative round-trip time (RTT) for the D-proxies behind the firewall. This method involves tracing the path to all intermediate gateways between the probing device and the D-proxy to calculate relative RTT. The calculated path information is then returned to the querying GSS.

Two new licensed features that are purchased separately including:

A DDoS attack detection and mitigation function—Prevents DDoS attacks that deny legitimate users access to Domain Name System (DNS) service on the GSS. These attacks are originated by malicious attackers who send several thousand spoofed DNS requests to a device, overwhelming the device, and causing it to drop valid DNS requests from legitimate D-proxies.

A product coupling with CNR—Allows the GSS to provide more standard DNS server functions that permit the GSS to function as a DNS appliance. This feature simplifies the process of managing and configuring the DNS infrastructure.

Both the CNR and DDoS licensed features are purchased as separate license add-ons and involve upgrading the existing GSS software license. For detailed overviews and descriptions of the CNR and DDoS features, see the Cisco Global Site Selector CLI-Based Global Server Load Balancing Configuration Guide.

Software Version 2.0(5) Open and Resolved Caveats

The following sections contain the open and resolved caveats in software version 2.0(5):

Open Caveats for Software Version 2.0(5)

Resolved Caveats for Software Version 2.0(5)

Open Caveats for Software Version 2.0(5)

The open caveats for software version 2.0(5) are the same as those for software version 2.0(4). For details, see the "Open Caveats for Software Version 2.0(4)" section.

Resolved Caveats for Software Version 2.0(5)

This section lists the resolved caveat for software version 2.0(5).

CSCsj70093—The GSS Domain Name System (DNS) service may become unresponsive when processing specific DNS requests. The GSS does not experience this problem when it is configured with the optional Cisco Network Registrar (CNR) software.

Software Version 2.0(4) Open and Resolved Caveats

The following sections contain the open caveats and resolved caveats in software version 2.0(4):

Open Caveats for Software Version 2.0(4)

Resolved Caveats for Software Version 2.0(4)

Open Caveats for Software Version 2.0(4)

This section lists the open caveats for software version 2.0(4).

CSCsg53791—The primary GSSM creates core files due to defect CSCsg44186. When the primary GSSM comes back up, its global sticky database cannot synchronize with the standby GSSM. Workaround: Reboot both the primary GSSM and the standby GSSM. After they boot up, the global sticky database should synchronize.

CSCsq06966—A GSS may not respond with the correct answer for some domain requests because not all of the configured domain names propagate from the primary GSSM to the GSS. Workaround: Restart the GSS by using the gss stop command followed by the gss start command.

CSCsq75812—During the decompression and compression of a CNR DNS response that contains additional section records, the GSS may experience an error condition that causes the outgoing UDP packet size to increase beyond 512 bytes in size. This problem can occur even when the GSS does not have a matching GSLB configuration for the additional section records and does not perform additional section load balancing on the DNS response from the CNR.

CSCsq75894—When the GSS needs to perform additional server load balancing on a CNR response, it may add new information that causes the outgoing UDP packet size to increase beyond 512 bytes in size.

CSCsr78339—The GSS may stop forwarding requests to the CNR. When this problem occurs, subsequent requests are not forwarded to the CNR until you restart the GSS. Workaround: Restart the GSS by using the gss stop command followed by the gss start command.

CSCsl06617—Several commands are missing from the CNR shell of the GSS. The required Linux commands are cat, cp, ftp, more, mv, tail, and top. These commands are file operations to edit, read, or rename the file and are required for ease of use.

CSCsu49213—Running multiple CNR shells may cause the CNR shell to fail intermittently.

Resolved Caveats for Software Version 2.0(4)

This section lists the resolved caveats for software version 2.0(4).

CSCsq31840—HTTP-HEAD keepalives on the GSS show an offline status for an answer even when the TCP KALs are working. This issue occurs when both interfaces on the GSS are configured with an IP address and the KALs can be sent from either interface.

CSCsq45987—The DNS server component of a GSS becomes unresponsive and generates a core dump at the time of processing a reply packet from sticky.

CSCsq47889—The GSS configuration server (CRM) reports memory leaks and cores while the GSS show commands are run in a loop.

CSCsu08179—The authoritative bit does not get set in a GSS negative response in which the query matches the domain configured in the domain-list but the query type is unsupported.

CSCsu56599—TCP traffic, such as full zone transfers and bulk zone data, to CNR fail.

Software Version 2.0(3.0.31) Open Caveats, Resolved Caveats, and Command Changes

The following sections contain the open caveats and resolved caveats in software version 2.0(3.0.31):

Open Caveats for Software Version 2.0(3.0.31)

Resolved Caveat for Software Version 2.0(3.0.31)

Open Caveats for Software Version 2.0(3.0.31)

This section lists the open caveats for software version 2.0(3.0.31).

CSCsf17052—When a GSS is connected to a CAT6500 and both the devices are hard set to 1000/full, the Ethernet link does not come up. If you set the GSS to auto speed/duplex, the link does come up and remains up even after you change the interface configuration back to 1000/full. This is not ideal behavior because once the cable is unplugged/plugged, the link will again go down and remain down as both devices are set to 1000/full.

Workaround: Set both devices to autonegotiate.

CSCsg53791—Core files observed on PGSSM due to defect CSCsg44186. After the primary GSS came back up, the global sticky database could not sync up between the primary GSS and the standby GSS.

Work around: Reboot the primary GSS and standby GSS. After they both come up, the global sticky database should work fine

CSCsj30473—The GSS fails to initiate the boomerang race after changing the `server delay' value in the DNS rule. This results in the DNS proxy always receiving the IP address configured in the boomerang `last gasp answer' because there won't be any replies back from the CRA agents.

Workaround: To start the boomerang race, stop then start the GSS.

CSCsk08483—When changing an answer group in a DNS rule to a different address, the change does not take effect the first time. If the answer is re-applied, it will then take effect. It appears that it is only the first time that the answer group address is changed that the problem occurs.

Workaround: Reapply the answer.

CSCsl06617—A few commands are missing from the 'cnr shell' of the GSS. The required Linux commands are cat, cp, ftp, more, mv, tail, and top. These commands are file operations to edit, read, or rename the file and are required for ease of use.

Workaround: Copy the file from the GSS to an external device that supports these operations, perform the required operation on the external device, and then use FTP to copy the file back to the GSS.

CSCsl73310—The PGSSM GUI may not be accessible at times. During a GUI communication outage, the GSLB services continue to function as expected.

Workaround: Use the CLI for operating the GSS or restore GUI access by using the CLI to enter the gss stop command followed by the gss start command.

CSCsl85176— The stale sticky information is improperly updating the newer sticky in global sticky.

Workaround: The following procedure is applicable for 2 to 8 GSSs in the GSS network. In this example, the link to GSS_1 is down and GSS_2 is currently being accessed by a client.

1. Create a sticky database file backup of GSS_2 (sticky database dump backup1 format binary).

2. Restore the link to the GSS_1 and copy its sticky database file immediately (sticky database dump backup2 format binary).

3. Delete the GSS_1 sticky database.

4. Copy the GSS_2 sticky database backup1 to GSS_1 (sticky database load backup1).

Note that after the links come up and the original GSS mesh topology is restored, the network will reconverge and all sticky data will resynchronize as this is a transient failure.

CSCsq06966—Not all of the domain names that you define on the primary GSSM may propagate to the DNS server component of a GSS on the GSS mesh, which would prevent it from providing the correct answers for some of the domains. Though the show gslb-config domain-list command displays all of the configured domain names, the DNS server component may not contain all of them.

Workaround: Restart the affected GSS using the gss stop and gss start commands.

CSCsq45987—The DNS server component of a GSS may fail when processing a reply packet from a DNS sticky.

Workaround: Restart the GSS using the gss stop and gss start commands.

CSCsq75812—During the decompression ad compression of a CNR response, the GSS may experience an error condition that causes the outgoing UDP packet size to increase in size beyond 512 bytes. When CNR is installed on the GSS, all responses from the CNR pass through the GSS. A CNR response always contains compressed data, which the GSS uncompresses for data processing and then compresses again before issuing the response.

Workaround: None.

CSCsq75894—When the GSS needs to perform additional server load balancing (ASLB) on a CNR response, it may add new information that causes the outgoing UDP packet size to increase in size beyond 512 bytes. When CNR is installed on the GSS, all responses from the CNR pass through the GSS for processing.

Workaround: None.

Resolved Caveat for Software Version 2.0(3.0.31)

This section lists the resolved caveat for software version 2.0(3.0.31).

CSCsm96859—In software versions prior to 2.0(3.0.31), when a user logs in to the GSS through a TACACS+ server without using the correct case-sensitive format, the GSS is unable to match the user name with its associated custom user view and assigns the user the unrestricted View All user view. In software version 2.0(3.0.31), the GSS is able to match the user account with the associated custom user view even if the user does not use the correct case-sensitive format when entering their user name and password.

When creating a user account on the GSS, you can associate a custom user view with the account that enables the GSS to restrict user access to specific GSS operations. The user name and password that you assign to a user account created on the GSS are case sensitive. However, when you configure a TACACS+ server to perform user authentication for the GSS, a GSS GUI user can log in to the GSS without entering their user name in the correct case-sensitive format because the TACACS+ server is case insensitive.

For example, a user with a user name defined as "userABC" on the GSS is able to log in through a TACACS+ server by entering the user name as "userabc" or "USERABC."

Software Version 2.0(3) Open Caveats, Resolved Caveats, and Command Changes

The following sections contain the open caveats and resolved caveats in software version 2.0(3):

Open Caveats for Software Version 2.0(3)

Resolved Caveats for Software Version 2.0(3)

CLI Command Changes in Software Version 2.0(3)

GUI Changes in Software Version 2.0(3)

Open Caveats for Software Version 2.0(3)

This section lists the open caveats for software version 2.0(3).

CSCsl73310—The PGSSM GUI may not be accessible at times. During a GUI communication outage, the GSLB services continue to function as expected.

Workaround: Use the CLI for operating the GSS or restore GUI access by using the CLI to enter the gss stop command followed by the gss start command.

CSCsf17052—When a GSS is connected to a CAT6500 and both the devices are hard set to 1000/full, the Ethernet link does not come up. If you set the GSS to auto speed/duplex, the link does come up and remains up even after you change the interface configuration back to 1000/full. This is not ideal behavior because once the cable is unplugged/plugged, the link will again go down and remain down as both devices are set to 1000/full.

Workaround: Set both devices to autonegotiate.

CSCsg53791—Core files observed on PGSSM due to defect CSCsg44186. After the primary GSS came back up, the global sticky database could not sync up between the primary GSS and the standby GSS.

Work around: Reboot the primary GSS and standby GSS. After they both come up, the global sticky database should work fine.

CSCsj30473—The GSS fails to initiate the boomerang race after changing the `server delay' value in the DNS rule. This results in the DNS proxy always receiving the IP address configured in the boomerang `last gasp answer' because there won't be any replies back from the CRA agents.

Workaround: To start the boomerang race, stop then start the GSS.

CSCsk08483—When changing an answer group in a DNS rule to a different address, the change does not take effect the first time. If the answer is reapplied, it will then take effect. It appears that it is only the first time that the answer group address is changed that the problem occurs.

Workaround: Re-apply the answer.

CSCsl06617—A few commands are missing from the 'cnr shell' of the GSS. The required Linux commands are cat, cp, ftp, more, mv, tail, and top. These commands are file operations to edit, read, or rename the file and are required for ease of use.

Workaround: Copy the file from the GSS to an external device that supports these operations, perform the required operation on the external device, and then use FTP to copy the file back to the GSS.

CSCsl85176— The stale sticky information is improperly updating the newer sticky in global sticky.

Workaround: The following procedure is applicable for 2 to 8 GSSs in the GSS network. In this example, the link to GSS_1 is down and GSS_2 is currently being accessed by a client.

1. Create a sticky database file backup of GSS_2 (sticky database dump backup1 format binary).

2. Restore the link to the GSS_1 and copy its sticky database file immediately (sticky database dump backup2 format binary).

3. Delete the GSS_1 sticky database.

4. Copy the GSS_2 sticky database backup1 to GSS_1 (sticky database load backup1).

Note that after the links come up and the original GSS mesh topology is restored, the network will re-converge and all sticky data will resynchronize as this is a transient failure.

Resolved Caveats for Software Version 2.0(3)

This section lists the resolved caveats for software version 2.0(3).

CSCsl08359—The gss stop command also stops the CNR servers. It should not stop CNR servers. To prevent potential corruption of the CNR data, the CNR servers need to be stopped gracefully before shutting down or rebooting the GSS appliance using the following commands: reload, shutdown, or install.

CSCsk69528—The GSS SNMPv1 TRAP message should include the GSS interface address as the Agent-Address, but instead, it reports the Agent-Address as being 0.0.0.0.

CSCsl21882—When making a change to the weight of an answer in an answer-group, and proximity is enabled in the dns rule clause associated with that answer-group, the weight change does not take effect. When there are multiple answers in a particular zone and that particular answer becomes the proximate zone, then the balance clause come into play. If the balance clause is weighted-RR and we change the answer weights dynamically, there is no effect. Without proximity in the balance clause, this works fine. Proximity enabled in the balance clause and balance method is weighted round robin. The proximate zone should host multiple answers.

CSCsk88478—Venezuela has decided to have their own time zone, which means that the GSS must be able to adjust to the new time zone. The GSS uses the underlying OS for getting local time. To account for the Venezuela Time Zone, the RHEL OS has to be updated with the appropriate TMZ patch.

CSCsk30656—The GSS sends a request for LOAD via the KAL-AP keepalive to the CSM or CSS even when the KAL-AP circuit KAL is OFFLINE. This creates a problem when using the FAST method and the Load Balancer initially comes alive. The GSS is expecting the replies to seq space, but the replies get out of order quickly and the GSS issues the following messages:

sequence# mismatch (seq#: [xxx]?) (DROPPING)

The GSS should use the status of the circuit as the key as to whether or not to send LOAD requests out.

CSCsj08942—If the GSS is running as a DRP agent, changes to the logging level do not take effect. Workaround: Enter the gss stop command and then the gss start command to make the logging level changes take effect.

CSCsi68935—To make sure GSS doesn't respond to queries with something appended to a configured wildcard domain, regular expressions with '^' and '$' should be supported as well for configuring domain names. Regex domains configured with '$' - for ending match and '^' - for beginning match are not supported currently. Support for these should also be available.

CSCs189399—A memory leak in the JNI code causes the CRDirector process to restart frequently, which brings down the GSS.

CSCsk70723—The original fix for http://www.openssl.org/news/secadv_20060928.txt was provided as part of the OpenSSL upgrade in Cisco Bug ID: CSCsg22734, which was available in GSS software version 2.0(1). This fix was not 100% complete as per http://www.securityfocus.com/archive/1/480855. This DDTS is opened purely to track product upgrade of OpenSSL version. No Cisco Security Response or Advisory is currently intended to be issued for this vulnerability.

CSCsk19608—After performing a reload, the GSS may become administratively inaccessible from hosts outside the GSS IP subnet. The GSS interfaces are administratively up, but are not configured with IP addresses. Communicating with the GSS through a console session, you may notice that the hostname of the GSS is 'localhost.localdomain' even though the running-config shows the correct hostname and properly configured default gateway.

CSCsj70165—When DNS traffic is sent to the GSS at a rate of 30-50 packets per second from different D-proxies (during testing of this bug, 10k src-ips were used), the GSS does not initiate the proximity process for a considerable number of D-proxies. This issue can be observed only in post 2.0 images and happens with both the IOS router and GSS acting as DRP agents. In 1.3.3.0.0, this issue is not present.

CSCsl79092—There is a database error when a GSS running software version 2.0(2) is upgraded to a 2.0(3) internal build. This error occurs only when an answer of type NS is present in the configuration.

CSCsl58611—There is a performance drop in servicing DNS requests compared to GSS software version 2.0(2).

CLI Command Changes in Software Version 2.0(3)

Table 3 lists the new CLI command keywords and arguments available in software version 2.0(3) for the new software features described in the "GSS Supports Both Scripted and KAL-AP Keepalives in a Multi-port Keepalive Answer" and "GSS Supports HTTPS Access for CNR GUI" sections.

Table 3 New CLI Commands and Keywords in Software Version 2.0(3) 

Mode
Command and Syntax
Description

global server load-balancing configuration

shared-keepalive scripted-kal ip_address kal-name name snmp-scalar community community name oid oid {return-load | return-online-value value | return-offline-value value}]

The following option has been added to the shared-keepalive scripted-kal command to link the load value that the GSS obtained using SNMP to the algorithm used in the GSS load-balancing algorithm.

snmp-scalar community community name oid oid {return-load | return-online-value value | return-offline-value value}

The keywords and arguments are as follows:

snmp-scalar community community name—SNMP community name defined on the target device (for example, Public/Private).

oid oid—Object identifier of the table to which the SNMP request is sent. Enter an integer (special characters are not allowed).

return-load—Returns the load of the answer.

return-online-value value—Returns the status of the answer, depending on the online value that you provide. If the load retrieved matches the value that you entered, then the answer status is ONLINE. For the value keyword, enter a maximum of 10 alphanumeric characters.

return-offline-value value—Returns the status of the answer depending on the offline value that you provide. If the load retrieved matches the value that you entered, then the answer status is OFFLINE. For the value keyword, enter a maximum of 10 alphanumeric characters.

answer vip configuration

keepalive type scripted-kal kal-name name max-load max load value match-string matchstring [use-load {enable | disable}]

The following option has been added to the keepalive type scripted-kal command to define a character string that the keepalive is to match to determine the online/offline status of the device being monitored:

match-string matchstring

The matchstring argument is the character string used match the OID value for the online status (all non-matching strings indicate an offline status). Enter 1 to 16 alphanumeric characters (special characters are allowed, but spaces are not allowed).

The following option has been added to the keepalive type scripted-kal command to determine load from a Scripted keepalive:

use-load {enable | disable}

The keywords are as follows:

use-load—Specifies whether or not the load value obtained by the Scripted keepalive is used by the GSS.

enable—Specifies that the GSS uses the load value of the defined Scripted KAL (scripted-kal kal-name name).

disable—Specifies that the GSS ignores the load value of the defined Scripted KAL (scripted-kal kal-name name) and uses a static value to determine online/offline status of the device.

privileged exec, global configuration, and interface

show statistics keepalive scripted-kal [all | name | list]

The output of this command has been modified to display the Scripted keepalives statistics of all answers and/or individual answer VIP.

The keywords and argument are as follows:

all—Displays detailed statistical information for all Scripted keepalives.

name—Displays detailed statistical information for the specified Scripted keepalive only.

list—Displays only the load and online/offline status of the answers that are being monitored by the Scripted keepalives using the use-load option of the keepalive type scripted-kal command.

privileged exec

cnr access-mode enable {http | https | both}

Enable HTTP and/or HTTPS access to CNR. The keywords for the cnr access-mode enable command are as follows:

http—HTTP access only is enabled. This is the default.

https—HTTPS access only is enabled.

both—HTTP and HTTPS access are enabled.

When you enable HTTPS access using the https or both keywords, the CLI prompts you to enter the keystore filename (including the path) and password.

When you enable a different access mode setting, the GSS automatically disables the previous setting. For example, if you change the access mode from HTTP to HTTPS, the GSS disables HTTP access.

privileged exec

show cnr access-mode

Displays the current CNR access mode setting (HTTP, HTTPS, or Both)

configuration

snmp-server trap-source ethernet {0 | 1}

Specifies the interface IP address to use in the agent address field of SNMP V1 notifications. The IP address configured on the Ethernet port that you select is the address applied to the agent address field.

configuration

snmp {community-string | contact | enable | location}

This version of the snmp command has been deprecated in software version 2.0(3).

configuration

snmp-server enable-traps snmp cold-start

Command hierarchy for configuring cold-start traps has been changed from snmp-server enable-traps cold-start to snmp-server enable-traps snmp cold-start.


GUI Changes in Software Version 2.0(3)

The Answers and Shared Keepalive screens under the DNS Rules tab have been modified for the version 2.0(3) software feature described in the "GSS Supports Both Scripted and KAL-AP Keepalives in a Multi-port Keepalive Answer" section. When you use the GUI to define a multi-port keepalive answer, each keepalive that you define allows you to select either the KAL-AP or Scripted KAL options. Prior to version 2.0(3), you could define only one of these keepalive types in a multi-port keepalive answer. With version 2.0(3), you can also attach more than one scripted keepalive to same answer.

The Shared Keepalive screen now allows you to choose the Scripted keepalive return type as follows:

Return Load—Returns the load of the answer.

Return Online Value—Returns the status of the answer, depending on the online value that you enter from this screen. If the load retrieved matches the value that you entered, then the answer status is ONLINE.

Return Offline Value—Returns the status of the answer depending on the offline value that you enter from this screen. If the load retrieved matches the value that you entered, then the answer status is OFFLINE.

The Answers screen now allows you to attach both KAL-AP and Scripted keepalives to the same multi-port keepalive answer. When configuring a Scripted keepalive, this screen also includes the following configuration options:

Use Load—When you check (enable) this option, the GSS uses the load value of the Scripted keepalive. If you do not check this option, the GSS ignores the load value of the Scripted keepalive.

Matching String—Character string used for MIB tables with OID values that can be accessed using a string specific to their tables. Enter 1 to 16 alphanumeric characters (special characters are allowed, but spaces are not allowed).

Software Version 2.0(2.1) Open Caveats and Resolved Caveat

The following sections contain the open caveats and resolved caveat in software version 2.0(2.1):

Open Caveats for Software Version 2.0(2.1)

Resolved Caveat for Software Version 2.0(2.1)

Open Caveats for Software Version 2.0(2.1)

This section lists the open caveats for software version 2.0(2.1).

CSCsf17052—The GSS 4492 interface link does not come up when speed and duplex are configured. When a GSS is connected to a Catalyst 6500 series switch and both devices are configured to 1000/full, the Ethernet link will not come up. If you set the GSS to auto speed/duplex, the link will come up. The link stays up if you set it back to 1000/full. Workaround: Set both devices to autonegotiate.

CSCsi68935—Configuring a DNS domain name list with a regular expression (regex) having special regex characters such as "$" and "^" does not work. Workaround: None.

CSCsj08942—If you attempt to change the logging level in the DRP subsystem while the GSS is running, the change does not take effect. Workaround: Execute a gss stop CLI command followed by a gss start to change the logging level.

CSCsj56574—After the proximity database reaches its maximum limit of 500K dynamic entries, database pruning is initially successful if DNS queries from new D-proxies continue to arrive. Query servicing quickly stops, however. Workaround: Delete several thousand D-proxy entries from the proximity database.

CSCsj70165—Under stress, when the GSS receives DNS queries from several thousand D-proxies, it does not initiate the proximity process for some D-proxies. After the refresh interval, the entries populate with the correct RTT values. Workaround: None.

Resolved Caveat for Software Version 2.0(2.1)

This section lists the resolved caveats for software version 2.0(2.1).

CSCsl08359—The GSS does not gracefully shut down the CNR processes when the following GSS commands were entered; reload, shutdown or install. Entering these commands may corrupt the CNR database.

Software Version 2.0(2) Open Caveats, Resolved Caveats, and Command Changes

The following sections contain the open caveats, resolved caveats, and command changes in software version 2.0(2):

Open Caveats for Software Version 2.0(2)

Resolved Caveats for Software Version 2.0(2)

CLI Command Changes in Software Version 2.0(2)

Open Caveats for Software Version 2.0(2)

This section lists the open caveats for software version 2.0(2).

CSCsf17052—The GSS 4492 interface link does not come up when speed and duplex are configured. When a GSS is connected to a Catalyst 6500 series switch and both devices are configured to 1000/full, the Ethernet link will not come up. If you set the GSS to auto speed/duplex, the link will come up. The link stays up if you set it back to 1000/full. Workaround: Set both devices to autonegotiate.

CSCsi68935—Configuring a DNS domain name list with a regular expression (regex) having special regex characters such as "$" and "^" does not work. Workaround: None.

CSCsj08942—If you attempt to change the logging level in the DRP subsystem while the GSS is running, the change does not take effect. Workaround: Execute a gss stop CLI command followed by a gss start to change the logging level.

CSCsj56574—After the proximity database reaches its maximum limit of 500K dynamic entries, database pruning is initially successful if DNS queries from new D-proxies continue to arrive. Query servicing quickly stops, however. Workaround: Delete several thousand D-proxy entries from the proximity database.

CSCsj70165—Under stress, when the GSS receives DNS queries from several thousand D-proxies, it does not initiate the proximity process for some D-proxies. After the refresh interval, the entries populate with the correct RTT values. Workaround: None.

Resolved Caveats for Software Version 2.0(2)

This section lists the resolved caveats for software version 2.0(2).

CSCsi63680—Access to engineering mode in the GSS is protected only by a static or hard-coded password. The supportpass CLI command (see Table 4) has been added to version 2.0(2).

CSCsi68443—When you execute a clear gslb-config CLI command or delete a domain list using the no domain-list <listname> CLI command, the DNS server core-dumps if the domain-list (or any domain-list in the case of clear gslb-config) contains non-wildcard domains. Should you attempt to clear the GSLB configuration or delete a domain list in the GUI, a similar result occurs.

CSCsj09206—When the GSS acts as a DRP agent and receives a large number of DRP requests, memory leaks occur.

CSCsj15936—Some DRP log messages and their logging levels are incorrect.

CSCsj19531—Attempting to install CNR version 6.2.3.1 (cnr_6_2_3_1-linux.gtar.gz) fails with the message "CNR installation failed."

CSCsj21589—A GSS failure occurs in a specific proximity-enabled scenario.

CSCsj35870—The DNS server is not operational after a CNR installation.

CSCsj38027—The Director Response Protocol (DRP) agent in the GSS does not trigger a D-proxy session for each DRP request.

CSCsj38125—Sending a TCP device interface generation (DiG) request for a name server forwarding (NSFwd) domain results in a GSS failure.

CSCsj45791—Multiple issues occur on the GSS while sending NSFwd TCP DNS requests. For example:

All show statistics dns commands display the following error message "Jun 27 20:38:26 SYSDB_ITEM_FAIL prox rc=4, mConnId=7" on the first attempt.

DNS requests time out.

The GSS becomes non-operational after approximately two to three hours of traffic.

The system logs display some odd error messages such as "Jun 27 20:42:53 gss2 DNS-7-SELNSFWDFAIL[12111] NSFWD failed to process response with id:50943 for client 0.0.0.0 with request id 50943."

CSCsj48486—Deleting or modifying answers that have associated scripted keepalive probes may result in a crash in the keepalive process.

CSCsj58453—The DRP agent is unable to calculate the RTT using the path-probe method.

CSCsj60114—The DRP agent may not return the correct RTT value to the GSS for the path-probe method.

CSCsj62020—The path-probe method fails when the number of D-proxies is greater than 400 and traffic from the D-proxies is greater than 30 queries per second.

CSCsj62181—The DNS server fails when a high rate of DNS traffic is sent over TCP to a GSS device that has CNR enabled.

CSCsj63954—Memory leaks occur during the DRP path-probe process in the GSS.

CLI Command Changes in Software Version 2.0(2)

Table 4 lists the new CLI commands and keywords available in software version 2.0(2).

Table 4 New CLI Commands and Keywords in Software Version 2.0(2) 

Command and Syntax
Description

ip anycast

The ip anycast command has been added to allow you to configure the anycast IP address. The no form of this command allows you to remove the configuration of an anycast IP address.

The syntax of this command is as follows:

ip anycast ipaddress

no ip anycast ipaddress

The ipaddress variable specifies the anycast IP address. The netmask for the anycast IP address is always 255.255.255.255.

For example, to configure 16.2.2.2 as the anycast IP address, enter:

gss1.example.com(config)#ip anycast 16.2.2.2 

You cannot enter ip anycast when the GSS is running. You must first enter gss stop as shown in the following example:

gss1.example.com# gss stop
gss1.example.com(config)# ip anycast 16.2.2.2

The interface lo:1 is configured with the anycast IP address in addition to the other interface configurations during system startup and also when you change the anycast IP address by entering the ip anycast command.

The anycast IP configuration is stored on the GSS in the platform.cfg file in the following format: anycast.ip=<ipaddress>

Use the show running-config command to display the anycast IP address as follows:

gss1.example.com# show running-config
interface ethernet 0
   ip address 16.1.1.118 255.0.0.0
   gss-communications
interface ethernet 1
   ip address 1.2.3.4 255.255.255.252
hostname gss-badboy.cisco.com
ip default-gateway 16.1.1.1
ip anycast 16.2.2.2 
ip name-server 16.1.1.118

ddos disable-as

The ddos disable-as command has been introduced to allow you to disable the anti-spoofing (AS) capability on the GSS. This allows the Distributed Denial of Service (DDoS) functionality to provide protection through rate limiting even if TCP traffic cannot reach the GSS.

The syntax of this command is as follows:

ddos disable-as

For example, to disable AS on the GSS, enter:

gss1.example.com(config)# ddos disable-as

Use the show ddos-config command to display the AS status on the GSS as follows:

gss1.example.com# show ddos-config
ddos
   disable-as

When you disable AS, the DDoS functionality:

Ignores the configured "Unknown Rate Limit."

Does not trigger any new AS checks.

Does not allow Spoofed packet drops or AS ongoing packet drops.

Does not support spoofed or trusted D-proxy configuration from the DDoS CLI.

Produces the following message when you enter the show ddos dproxy and show ddos dproxy 16.1.1.21 CLI commands:

gss1.example.com# show ddos-dproxy
Anti-Spoofing is turned off currently. DDoS anti-spoofing values cannot be 
shown.

logging disk subsystem name priority loglevel

logging host subsystem name priority loglevel

The snmp keyword has been added to enable disk and host logging for the SNMP agent subsystem on the GSS.

The syntax of this command is as follows:

logging disk subsystem snmp priority loglevel

logging host subsystem snmp priority loglevel

For example, to enable SNMP agent subsystem logging on a disk and set the priority level for error conditions, enter:

gss1.example.com(config)# logging disk subsystem snmp priority errors

To enable SNMP agent subsystem logging on a host set the priority level for error conditions, enter:

gss1.example.com(config)# logging host subsystem snmp priority errors

Use the logging disk subsystem (or logging host subsystem) command followed by a question mark (?) to display the new SNMP agent disk (or host) logging subsystem:

gss1.example.com(config)# logging disk subsystem ?
boomerang 	Boomerang logging
crdirector 	CrDirector logging
crm 	GSS GUI server logging
ddos 	DDoS logging
dnsserver 	DNS Server logging
drpagent 	DRP Agent logging
keepalive 	Keepalive Engine logging
lm 	license manager logging
nodemgr 	Node Manager logging
proximity 	Proximity logging
snmp 	SNMP Agent logging
sticky 	Sticky logging 
system 	System logging 
tacacs 	Tacacs+ logging

supportpass

show supportpass-status

The supportpass command has been introduced for debugging purposes. The GSS support team team may ask you to set the GSS support password using supportpass and then communicate that password to the support engineer. The support engineer will be able to access the engineering mode only if you have set the support password and provided it to the engineer.

The syntax of this command is as follows:

supportpass

Note Admin-privilege users can set or change the supportpass once they provide the "admin" password.

For example, to set the GSS support password, enter:

gss1.example.com# supportpass
gss1.example.com#

You can use the show supportpass-status command to see whether the GSS support password has been set. For example, enter:

gss1.example.com# show supportpass-status
GSS support password is set.

proximity properties
acceptable-rtt number

The maximum acceptable RTT value that the GSS uses when determining the most proximate answer has been increased from 1500 ms to 2000 ms in proximity properties configuration mode. The range is 50 to 2000 ms and the default is 100 ms.

The syntax of this command is as follows:

acceptable-rtt number

You must use the enable command to enable proximity properties configuration mode before entering the acceptable-rtt number command. For example, to access and enable proximity properties configuration mode and then specify the maximum RTT value, enter:

gssm1.example.com(config-gslb)# proximity-properties
gssm1.example.com(config-gslb-proxprop)# enable
gssm1.example.com(config-gslb-proxprop)# acceptable-rtt 2000


Software Version 2.0(1) Open Caveats, Resolved Caveats, and Command Changes

The following sections contain the open caveats, resolved caveats, and command changes in software version 2.0(1):

Open Caveat for Software Version 2.0(1)

Resolved Caveats for Software Version 2.0(1)

CLI Command Changes in Software Version 2.0(1)

Open Caveat for Software Version 2.0(1)

CSCsf17052—The GSS 4492 interface link does not come up when speed and duplex are hard set. When a GSS is connected to a Catalyst 6500 series switch and both devices are hard set to 1000/full, the Ethernet link will not come up. If you set the GSS to auto speed/duplex, the link will come up. The link stays up if you set it back to 1000/full. Workaround: Set both devices to autonegotiate.

Resolved Caveats for Software Version 2.0(1)

This section lists the resolved caveats for software version 2.0(1).

CSCse79659—DNS query processing is case sensitive. However, it should not be case sensitive. For example, when a domain is configured as .*foo\.com\.au, the GSS only matches all lowercase characters.

CSCsf16497—In the GSS v2.0(1) software, the number of answer groups has been increased to 2000.

CSCsh02316—When you upgrade the GSS from 1.3(3) to 2.0(1) or install and uninstall a license file, the CRM subsystem becomes nonoperational.

CSCsh06756—If you delete NS answer groups, all references to the deleted objects are not removed. This action permits illegal access to freed memory objects.

CSCsh12016—When a steady stream of DNS requests are sent, the DNS server on the GSS fails.

CSCsh12031—Each GSS in the GSS mesh requires a unique license file.

CSCsh13543—The DDoS detection and mitigation feature performs anti-spoofing for all DNS reply packets that have a source port of 53. This results in false negatives on the GSS.

CSCsh14099—With the DDoS feature enabled, the GSS becomes unresponsive to DNS requests after receiving a mixed profile of DNS requests from several D-proxies. Typically, a mixed profile includes some TCP requests, some UDP requests, and some spoofed requests.

CSCsh15426—The GSS does not support CNR utilities.

CSCsh17143—You cannot enter the CNR license key from the CLI on the GSS.

CSCsh18514—If a GSS DRP agent receives a burst of gateway responses that have the start TTL set to a number greater than 31, and the probe type of that DRP agent is set to UDP, the GSS DRP agent fails and restarts every time it receives queries from multiple D-proxies.

CSCsh18823—GSS uses path-probing only when D-proxies do not respond to legacy probes. After a path-probe is successful, if D-proxies become reachable and respond to legacy (ICMP, TCP) probes, the GSS switches to using legacy probes on refresh or active probing.

CSCsh31864—After you install CNR on the GSS, the DHCP server cannot start.

CSCsh39476—On the GSS, DDoS does not invoke anti-spoofing checks for non-A DNS records while CNR is enabled.

CSCsh39684—When proximity is enabled, new GSLB configurations (for example, zone, location, and answer) are added to the existing configuration on a GSS that is also acting as a DRP agent. If a new proximate answer is available as a result of that new configuration, the GSS does not return the new proximate answer.

CSCsh41186—The number of retries and successful counters do not work for fast-rate scripted keepalives.

CSCsh53247—When you install CNR on the GSS, the GSS is disabled when it receives traffic of the following types: 3000-byte DNS requests and 2000-byte domain names.

CSCsh54590—If you use certain authentication keys (for example, 1, 253, 254, and 255), the GSS DRP feature does not work.

CSCsg21239—When you upgrade the GSS from 1.3(3) to 2.0(1), an exception appears and the DNS service never reaches the ready state to service requests.

CSCsg22734—In response to multiple security advisories published by the OpenSSL project, Cisco has upgraded openSSL to openssl-0.9.7a-43.11.i386.rpm.

CSCsg27494—The keepalive engine (KALE) becomes disabled when detaching a scripted keepalive from an answer.

CSCsg29505—After performing an SNMP GET request on OID=.1.3.6.1.2.1.25.2.3.1.7.1 (hrStorageAllocationFailures), the SNMP daemon stops responding. All subsequent SNMP GET requests either timeout or fail.

CSCsg42065—By default, you should not enable the DDoS feature on the GSS unless it was previously enabled and a DDoS license is present.

CSCsg43747—When you attempt to save DDoS peacetime learned values, it causes the GSS to produce debugging information on the kernel stack where the error occurred and then freeze.

CSCsg44186—A core dump occurred on the primary GSSM preceded by the STK-4-STATERROR[988] poller error.

CSCsg45032—When you set the DDoS global rate limit to zero, the GSS is unable to handle DNS UDP or DNS TCP requests from the Dig tool. Such requests cause the GSS to fail.

CSCsg45152—The GSS snmpd utility does not respond to the snmpbulkget command.

CSCsg45255—SNMP configurations, such as location, community and contact, are not retained when you perform the following operations:

Upgrade to 2.0

Downgrade from 2.0

Copy the running-config file to the startup-config and then reload the GSS

CSCsg45277—Once you configure snmp-server host related configurations, they cannot be changed.

CSCsg46902—SNMP traps on the GSS are not generated.

CSCsg50622—When multiple D-proxies query any GSS in a GSS mesh with path-probe enabled on each device, the DRP agent on the Primary GSSM fails.

CSCsg60165—You cannot access CNR configuration mode on the GSS unless both the CNR and DDoS licenses are installed on the GSS.

CSCsg61951—If you attempt an unsupported upgrade sequence (for example, 1.2(2) to 2.0(1)), the GSS boot-up process should terminate gracefully by producing an error message. It should not enter a state where processes are continuously restarting.

CSCsg65378—When you enter the gss enable gssm-standby primary_GSSM_IP_address CLI command, it disables the non-GSSM.

CSCsg65589—After you install the DDoS license and enable DDoS, the GSS kernel fails.

CSCsg76245—While processing a path-probe, if a DRP agent on a GSS receives a delayed ICMP Time Exceeded packet from an intermediate router in the network, the GSS DRP agent fails with a segmentation fault.

CSCsg79558—When DDoS peacetime learning is active on a GSS serving DNS requests, the GSS becomes disabled immediately after it executes the show ddos dproxy command.

CSCsg83182—If you install the same license file on multiple GSSs in a mesh, the primary GSSM should not deregister itself. Instead, it should deregister the other GSSs.

CSCsg83184—After you perform an upgrade from 1.3(3) to 2.0(1), the DNS server on the standby GSSM fails to become operational.

CSCsg84882—After you install the CNR license, the cnr exec mode command fails to execute on the GSS.

CSCsg87046—There are two possible scenarios that may occur here:

The GSS configuration agent (crdirector) restarts while modifying the default global configuration for Fast-rate KAL-AP keepalive configuration. This takes place during performance keepalive testing.

The GUI on the primary GSSM may become unresponsive when any of the GSSs have an unreachable name server.

CSCsg90808—On the GSS, the GSS should forward all A requests that do not match the configured DNS rules to the CNR for processing. This expected behavior does not occur.

CSCsg92588—When acting as a primary name server, the GSS fails to reply with the zone information for a zone transfer request.

CSCsg92636—If a DNS response consists of records in the additional section, DNS requests to the GSS fail to produce a response.

CSCsg97884—The primary GSSM must support a GSS mesh that has license files containing different PAK numbers.

CSCsh12078—The range of acceptable round-trip time (RTT) values has been extended from 50-500 milliseconds (ms) to 50-1500 ms for proximity configuration.

CSCsh14213—After you enter the show tech-support command, only one answer displays in the output despite the fact that multiple answers are configured.

CSCsh30630—After the GSS has been operational for a certain time period, the internal counter monitoring the time that has elapsed since the system was booted can wrap and reset the uptime GSS counter to zero. If this happens, you see the following message in the system log:

KAL-4-SYSCALLERROR[962] call to times() returned an error (ie -1) last message 
repeated x times 

CSCsh53247—When multiple TCP requests are received on the same TCP connection, the GSS fails.

CSCsh53358—GSS name server (NS) keepalives are no longer sent on both the primary and secondary GSSMs when the server sends back incorrect UDP checksums.

CSCsh67603—When queried by the CNR, the following features do not return the correct GSLB answer:

DNS rule with a source address list element other than "Anywhere"

Proximity (both dynamic and static)

Sticky

Boomerang

Balance method Hash

This results in a load-balancing failure of the records in the additional section of a DNS reply.

CSCsh72856—When spoofed DNS requests are sent at the rate of 60 per second and DDoS is enabled, the GSS fails.

CSCsh74448—The GSS fails if you execute the max-database-entries command in config-ddos mode and the GSS is stopped and started.

CSCsh82650—When the GSS is configured for NS forwarding for a particular domain and the same domain is hosted on the CNR, the DNS server on the GSS fails if a non A-record request is sent to the GSS.

CSCsh82770—Even when a GSLB configuration does not exist on the GSS, the selector uses 99.8 percent of the available CPU capacity.

CSCsi22242—The database on the primary GSSM does not synchronize with the secondary GSSM under both of the following conditions:

If you execute the gss disable command followed by gss enable.

If you perform a certain configuration on the primary GSSM and then remove that configuration within 2 to 3 seconds.

CSCsi25588—CNR stops responding to DNS queries after it receives a query for a non-existent domain with a query type of ANY.

CSCsi33558—The GSS stops responding to DNS queries after it receives about 100 queries per second for a domain that is specified using a regular expression (regexp) containing wild card characters.

CSCsi45116—With a large number of regular expression-based domains configured in the domain-list, GSS performance degrades to about 200 queries per second if the DNS requests domain name matches a corresponding domain list.

CLI Command Changes in Software Version 2.0(1)

Table 5 lists the new CLI commands and keywords available in software version 2.0(1).

Table 5 New CLI Commands and Keywords in Software Version 2.0(1) 

Command and Syntax
Description

Authority Domain Command

auth-domain domain-name

Adds an authority domain to an answer group.

CNR Commands

cnr

Enters the CNR command line interface (the nrcmd program).

cnr enable

Enables CNR on your GSS.

cnr install cnr-package

Installs CNR on your GSS.

cnr uninstall

Uninstalls CNR from your GSS.

cnr shell

Enters the restricted CNR shell and executes the available CNR utilities.

DDoS Commands

clear ddos-config

Clears the configuration from the DDoS detection and mitigation subsystem.

ddos peacetime apply [increment | overwrite]

Applies the values learned during the peacetime learning process to the rate-limit database.

ddos peacetime database erase

Erases peacetime learning.

ddos peacetime save filename

Saves peacetime learning to memory or to a file on disk.

ddos peacetime show [filename | status]

Shows the values learned during the peacetime learning process or shows the peacetime learning status.

ddos peacetime start

Starts the peacetime learning process.

ddos peacetime stop

Stop the peacetime learning process.

ddos restore-defaults ipaddress

Restores the default rate-limit values in the rate-limit database.

dproxy [trusted ipaddress | spoofed ipaddress]

Configures trusted or spoofed D-proxies.

enable

Enables the DDoS detection and mitigation function in the GSS.

global-domain domain-name

Configure a global domain name.

max-database-entries number

Configures the maximum number of entries stored in the DDoS database.

mitigation-rule [response | request] enable

Enables migration rule checks in the GSS.

peacetime database file

Sets the location or file that the peacetime file uses in a ddos peacetime apply operation.

rate-limit [ipaddress | global | unknown] rate-limit

Configures or modifies the rate limit for a particular D-proxy or sets a global rate limit.

scaling-factor d-proxy value

Configures the value by which the rate limit is scaled. The final rate limit is calculated and displayed with the show ddos rate-limit command.

script play-config filename

Executes a saved DDoS configuration file.

show [ddos] attacks

Displays DNS attacks detected by the GSS.

show ddos-config

Displays the contents of the DDoS running configuration file.

show [ddos] dproxy [ipaddress | trusted | spoofed]

Shows spoofed and non-spoofed D-proxies on the GSS.

show [ddos] failed-dns [failed-domains | global-domain-rules | gslb-rules]

Shows the last x number of domain names that caused failed DNS queries at the GSS or the number of failed DNS queries per D-proxy.

show [ddos] rate-limit [ipaddress | global | unknown]

Shows the rate limits per D-proxy and the number of packets dropped per source.

show statistics [ddos] [attacks | global]

Displays DDoS global or attack statistics.

show [ddos] status

Displays the status of the DDoS detection and mitigation function on the GSS.

Director Response Protocol (DRP) Agent Commands

authentication key key id 0-255

Enables DRP authentication key chain IDs.

enable

Enables the GSS as a DRP agent.

probe icmp-rtt timeout

Configures parameters related to the ICMP probe.

probe path-rtt

Configures parameters related to the path probe.

probe tcp-rtt

Configures parameters related to TCP probing.

timeout 1-5

Configures a timeout value for the ICMP probe.

burst-size 1-20

Configures the number of TCP-SYN-ACK packets sent at one time.

destination-port 1-65535

Configures the path probe destination port.

init ttl 1-32

Configures an initial Time-to-Live (TTL) for path probing.

max-failure-ttl 1-32

Configures an acceptable number of last successive failure packets.

max-ttl 1-255

Configures a maximum TTL for path probing.

probe-type {tcp | udp}

Configures the type of packet (UDP or TCP) to be used for path probing.

show statistics drpagent

Displays statistics about the DRP agent.

sourceport dynamic | static 1-65535

Configures the path probe source port.

timeout 1-10

Configures the timeout value for the path probe.

destination-port 1-65535

Configures a TCP destination port.

sourceport dynamic | static 1-65535

Configures a TCP probe source port.

timeout value

Configures the timeout value for the TCP probe.

Inventory Command

show inventory

Displays GSS Unique Device Identifier (UDI) data,.

Licensing Commands

license install filename | uninstall filename

Installs or uninstalls a license file on your GSS device.

show license active | file-name [list | filename] | installed | gss-all

Displays GSS system license data.

Proximity Commands

fallback-probe-method {path-probe}

Configures a fallback probe method for proximity.

proximity group-summary dump filename

Dumps the proximity group summary to the specified text file.

proximity play-config filename

Plays the proximity commands more efficiently than script play-config if the size of the proximity group configuration is very large.

proximity statistics group-summary dump filename

Dumps the proximity group summary statistics to the specified text file.

Scripted Keepalive Commands

keepalive-properties scripted-kal {standard min-interval number | fast retries number successful-probes number}

Changes the Scripted keepalive global keepalive configuration settings.

shared-keepalive scripted-kal ip_address kal-name name
[csm community community name | css community community name | ios-slb community community name | snmp-mib-not-indexed-by-vip oid oid community community name address-filter string load-filter string | snmp-mib-indexed-by-vip oid oid community community name load-filter string | snmp-scalar oid oid community community name] [retries number] | [successful-probes number]

Configures a Scripted keepalive shared keepalive.

show statistics keepalive scripted-kal [name | all | list]

Displays statistics for configured Scripted keepalive types managed by the GSS and used with VIP-type answers.

Simple Network Management Protocol (SNMP) Commands

snmp-server {community string [ro |
rw] | contact name | location location}

Configures contact, location, and community string with the read/write option.

snmp-server enable-traps [core | gslb
[dns | kal | peer-status] | snmp [authentication]

Enables or disables individual traps.

snmp-server host host-address community-string [traps] [version {1 | 2}] [udp-port port]

Specifies the recipient of a Simple Network Management Protocol notification operation.

snmp-server trap-limit {answer-trap value | dns-clause-trap value | keepalive-trap value}

Specifies the maximum number of answer, keepalive, or dns-clause traps that should be sent to the management station.


Obtaining Documentation and Submitting a Service Request

For information on obtaining documentation, submitting a service request, and gathering additional information, see the monthly What's New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation, at:

http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html