Home | Skip to Content | Skip to Search | Skip to Navigation | Skip to Footer |
Worldwide [change] |Register |About Cisco
Guest

Hierarchical Navigation

Cisco ACE GSS 4400 Series Global Site Selector Appliances

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

Downloads

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)

Disabling and Enabling CNR when Performing an Upgrade

Removing Double Quotes from Object or Description Names

Backing Up Your Current Primary GSSM Database

Upgrading Sequence to Software Version 2.0(4)

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(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

New Features in Software Version 2.0(1)

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)

September 30, 2008

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(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(4)

•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(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 Versions1
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:

•If you have Cisco Network Registrar (CNR) loaded on your GSS, disable CNR before upgrading to 2.0(x) and then enable CNR after the upgrade (see the "Disabling and Enabling CNR when Performing an Upgrade" section).

•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:

•Disabling and Enabling CNR when Performing an Upgrade

•Removing Double Quotes from Object or Description Names

•Backing Up Your Current Primary GSSM Database

Disabling and Enabling CNR when Performing an Upgrade

To disable CNR before upgrading to 2.0(x), enter the following command in global configuration mode:

no cnr enable

For example: 

gssm1.example.com# config

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

To enable CNR after the upgrade, enter the following command in global configuration mode:

cnr enable

For example: 

gssm1.example.com# config

gssm1.example.com (config)# cnr enable

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 (see the "Disabling and Enabling CNR when Performing an Upgrade" section).

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(4)

When upgrading your GSS devices to software version 2.0(4), 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(4). For more information on upgrading to GSS software version 2.0(4), see Appendix A, "Upgrading the GSS Software" in the Cisco Global Site Selector Administration Guide.

Table 1 Upgrade Sequence for Previous GSS Software Versions 

From Version
To Version
 

2.0(2)

2.0(2.1)

2.0(3)

2.0(4)

2.0(2)

2.0(2.1)

2.0(3)

 
 
To Version

1.3(1)

1.3(2)

1.3(3)

2.0(1)

2.0(2)

2.0(2.1)

2.0(3)

 
To Version

1.2(x)

1.3(x)

2.0(2)

2.0(2.1)

2.0(3)

     
To Version

1.0(x)

or

1.1 (prior to 1.7)

1.1(1.7.0)

1.2(2.2.0)

1.3(x)

2.0(2)

2.0(2.1)

2.0(3)


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. If CNR is loaded on any of the GSS devices, disable it by using the no cnr enable command in configuration mode. 

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

Note If you use CNR with your GSS devices, the lowest software version that you can downgrade the GSS mesh to is version 2.0(1); however, we recommend that you do not downgrade lower than GSS version 2.0(3) when using CNR.

4. 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. Disable the GSS by using the gss disable command in privileged EXEC mode. 

gssm1.example.com# gss disable

5. 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.

6. 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.

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

8. 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.

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

10. 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

11. 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(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 becaus