Table Of Contents
Release Note for the Cisco Global Site Selector, Release 1.2(1)
Cisco-Supported Hardware and Software Compatibility
Before Upgrading to Version 1.2(1)
New Features in Software Version 1.2(1)
User Privilege Roles and Custom User Views
New Documentation Set for GSS Software Version 1.2(1)
Operating Conditions for Software Version 1.2(1)
Software Version 1.2(1) Open Caveats, Resolved Caveats, and Command Changes
Open Caveats for Software Version 1.2(1)
Resolved Caveats for Software Version 1.2(1)
CLI Command Changes in Software Version 1.2(1)
Software Version 1.1(1) Open Caveats
Obtaining Documentation, Obtaining Support, and Security Guidelines
Release Note for the Cisco Global Site Selector, Release 1.2(1)
May 11, 2005
Note
The most current Cisco GSS documentation for released products is available on Cisco.com.
Contents
This release note applies to software version 1.2(1) for the Cisco Global Site Selector (GSS). It contains the following sections:
•
Cisco-Supported Hardware and Software Compatibility
•
Before Upgrading to Version 1.2(1)
•
New Features in Software Version 1.2(1)
•
New Documentation Set for GSS Software Version 1.2(1)
•
Operating Conditions for Software Version 1.2(1)
•
Software Version 1.2(1) Open Caveats, Resolved Caveats, and Command Changes
•
Software Version 1.1(1) Open Caveats
•
Obtaining Documentation, Obtaining Support, and Security Guidelines
Cisco-Supported Hardware and Software Compatibility
The GSS software version 1.2.(1) operates with the following Cisco hardware:
•
GSS 4480, GSS 4490, and GSS 4491 (scheduled for future availability), configured in software as the primary GSSM, the standby GSSM, or as a GSS device.
•
Cisco Content Services Switch running the following WebNS software releases:
•
Cisco Catalyst 6500 Content Switching Module (CSM) running the following software releases:
Platform Recommended CSM Versions1 Minimum Supported CSM VersionsCisco Catalyst 6500 Content Switching Module (CSM)
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.
The GSS software version 1.2.(1) network proximity and TACACS+ server features operate with the following Cisco software releases:
•
For network proximity, use a Cisco IOS-based router that supports Director Response Protocol (DRP) as the probing device in each proximity zone. DRP is supported in the following Cisco IOS release trains: 12.1, 12.1E, 12.2T, 12.2, 12.3, and later releases. ICMP probing is only supported in Cisco IOS releases 12.2T, 12.3, and later releases.
The GSS operates with Cisco IOS-based routers using the following DRP RTT probing methods: TCP ("DRP Server Agent") and ICMP ("ICMP ECHO-based RTT probing by DRP agents"). "DRP Server Agent" and "ICMP ECHO-based RTT probing by DRP agents" are the Cisco IOS feature names as shown in the Cisco Feature Navigator. The Cisco Feature Navigator is located on Cisco.com at:
http://tools.cisco.com/ITDIT/CFN/jsp/index.jsp
•
For TACACS+ server authentication, authorization, and accounting (AAA) services, use Cisco Secure Access Control Server (ACS) version 3.2 or greater.
Before Upgrading to Version 1.2(1)
You can directly upgrade to GSS software version 1.2(1) from the GSS version 1.1 and 1.0 software releases. Before you upgrade your GSS software, be sure that you:
•
Perform a full backup of your primary GSSM database as described in the Cisco Global Site Selector Configuration Guide:
–
For software version 1.1, refer to Chapter 9, GSS Administration and Troubleshooting, the "Backing Up the GSSM" section.
–
For software version 1.0, refer to Chapter 3, GSS Administration and Troubleshooting, the "Backing Up the GSSM" section.
•
Review the software version 1.2(1) software upgrade sequence as described in the new Cisco Global Site Selector Administration Guide, Appendix A, Upgrading the GSS Software.
If you are currently running GSS software version 1.0 on your GSS 4480 and intend to downgrade back to version 1.0, you must first upgrade to software version 1.1 before loading software version 1.2(1). Downgrading directly from software version 1.2(1) to version 1.0 is not supported at this time.
New Features in Software Version 1.2(1)
GSS software version 1.2(1) provides the following new features and enhancements. For details on these new features and enhancements, refer to the Cisco Global Site Selector Getting Started Guide, Cisco Global Site Selector Administration Guide, and Cisco Global Site Selector Global Server Load-Balancing Configuration Guide.
Local and Global DNS Sticky
Stickiness enables a GSS to remember the DNS response returned for a client D-proxy and to later return that same answer when the client D-proxy makes the same request. When you enable sticky in a DNS rule, the GSS makes a best effort to always provide identical A-record responses to the requesting client D-proxy. The GSS collects requests from the client D-proxies and stores these requests in memory as the sticky database.
DNS sticky on a GSS ensures that e-commerce clients remain connected to a particular server for the duration of a transaction even when the client's browser refreshes the DNS mapping. While some browsers allow client connections to remain for the life time of the browser instance or for several hours, other browsers impose a connection limit of 30 minutes before requiring a DNS re-resolution. This time may not be long enough for a client to complete an e-commerce transaction.
With local DNS sticky, each GSS device attempts to ensure that subsequent client D-proxy requests to the same domain name to the same GSS device will be "stuck" to the same location as the first request. DNS sticky guarantees that all requests from a client D-proxy to a particular hosted domain or domain list are given the same answer by the GSS for the duration of a user-configurable inactivity time interval, assuming the answer is still available.
With global DNS sticky, each GSS device in the network shares answers with the other GSS devices in the network, operating as a fully connected peer-to-peer mesh. Each GSS device in the mesh stores the requests and responses from client D-proxies in its own local sticky database, as well as shares this information with the other GSS devices in the network. As a result, subsequent client D-proxy requests to the same domain name to any GSS in the network causes the client to be "stuck".
Network Proximity
Network proximity enables a GSS to select the closest or most proximate answers (resources) based on measurements of round-trip time (RTT) from an available answer to the requesting client's D-proxy location. To determine the most proximate answer, the GSS communicates with a probing device, a Cisco IOS-based router running IOS version 12.1 or greater, that is located in each proximity zone. The Cisco IOS-based router gathers RTT metric information that is measured between the requesting client's D-proxy and the associated zone. Each GSS directs client requests to an available server with the lowest RTT value.
The GSS uses Director Response Protocol (DRP) to communicate probe requests and receive responses with the probing devices, called DRP agents, in each proximity zone. RTT metrics are temporarily cached in GSS memory (the proximity database). A user-configurable inactivity time interval defines the maximum time period that can occur without an entry receiving a lookup request, after which the GSS deletes the entry from the proximity database.
TACACS+
TACACS+ provides for separate authentication, authorization, and accounting (AAA) facilities between a GSS and a TACACS+ server, such as the Cisco Secure Access Control Server (ACS). TACACS+ allows for multiple access control servers to provide the AAA services. A TACACS+ server provides the following AAA independent services to a GSS operating as a TACACS+ client:
•
Authentication—Identifies users attempting to access a GSS. GSS users are authenticated against the TACACS+ server when remotely accessing a GSS through the console, Telnet, SSH, FTP, or the primary GSSM GUI interfaces. A denied authentication attempt prohibits the user from accessing the GSS.
•
Authorization—Controls which GSS CLI commands a user can access on a GSS or on a GSSM (primary or standby), providing per-command control and filtering.
•
Accounting—Records the specific CLI commands and GUI pages accessed by a GSS user. Accounting enables system managers to monitor the activities of GSS users to better understand which users executed specific commands and navigated to specific GUI pages.
User Privilege Roles and Custom User Views
You may control the primary GSSM GUI pages that a user accesses and the functions that a user performs from the GUI through the assignment of one of the three user privilege levels, called "roles." Each role grants specific access to the primary GSSM GUI based on the assigned role. The three supported user roles include:
•
Administrator—Full configuration privileges and complete access to the primary GSSM GUI.
•
Operator—Limited configuration privileges in the primary GSSM GUI, but the operator can view list pages, view detail pages, and monitor global server load-balancing statistics.
•
Observer—No configuration privileges in the primary GSSM GUI, but the observer can monitor global server load-balancing statistics.
To further control what a user with an operator or observer role can access in primary GSSM GUI, you can define and assign custom views for that user. A custom view limits the data (configuration and statistics) visible on a primary GSSM GUI page to a user by specifying the answers, shared keepalives, locations, and owners associated with the view. When you assign a custom view to a user, the user can see only the specified data and statistics in the primary GSSM GUI.
Additional Enhancements
The GSS software version 1.2(1) also includes the following additional enhancements:
•
Additional GSS Logging Subsystems—Additional logging subsystem support for proximity log messages, sticky log messages, and TACACS+ log messages.
•
Time Zone—Expanded number of options available in the clock time zone CLI command to provide a greater level of flexibility when setting the local time zone for your GSS. Selections now include standard time zones, countries, parts of continents, and specific cities.
•
Show Boot Configuration—Ability to display information about the current boot image and the boot device.
•
Show Service—Ability to display the current state of the GSS services: FTP, NTP, SSH, TACACS+, Telnet, and SNMP.
New Documentation Set for GSS Software Version 1.2(1)
The documentation set for GSS software version 1.2(1) now includes the Cisco Global Site Selector Getting Started Guide, Cisco Global Site Selector Administration Guide, and Cisco Global Site Selector Global Server Load-Balancing Configuration Guide. The complete documentation set contains the publications listed below.
Operating Conditions for Software Version 1.2(1)
The following operating conditions exist for software version 1.2(1):
•
When you upgrade the GSS to software version 1.2(1), the default primary GSSM GUI privilege level for each GSS user is "administrator". The assignment of the operator or observer privilege level to a primary GSSM GUI user is a new feature for GSS software version 1.2(1). To change the user privilege level to either operator or observer, modify the GUI user account and change the role of the user. Refer to the Cisco Global Site Selector Administration Guide, Chapter 3, Creating and Managing User Accounts, for details.
•
If you use a GSS in a proximity zone configuration containing a Cisco router running IOS release 12.1, you must ensure that the DRP authentication configuration is identical on both devices. For example, to perform DRP authentication between a GSS and a Cisco IOS 12.1 router, ensure that you properly enable and configure authentication on both devices. The same is true if you choose not to use DRP authentication; you must disable authentication on both devices. In the case that you disable DRP authentication on a Cisco IOS 12.1 router but enable DRP authentication on a GSS, all measurement probes sent by a GSS to the Cisco IOS-based router will fail. This condition occurs because the Cisco IOS 12.1 router fails to recognize the DRP echo query packets sent by a GSS and the GSS is unable to detect a potential failure of measurement packets sent to the router. In this case, the GSS identifies the Cisco IOS-based router as being ONLINE in the show statistics proximity probes detailed output, yet the measurement response packets monitored in the Measure Rx field do not increment. Together, these two conditions may indicate a DRP authentication mismatch.
If DRP probe requests fail between the GSS and a Cisco router running IOS release 12.1, even when the GSS indicates that the router is ONLINE, verify the DRP authentication configurations on both the Cisco router and the GSS.
–
To verify the Cisco router running IOS release 12.1, enter the show ip drp command. If the line Authentication is enabled, using "test" key-chain appears in the output (where "test" is the name of your key-chain), DRP authentication is configured on the router. If this line does not appear in the output, DRP authentication is not configured.
–
To verify GSS version 1.2(1), access the Global Proximity Configuration details page (Traffic Mgmt tab) on the primary GSSM GUI and observe if the DRP Authentication selection is set to Enabled or Disabled (see the Cisco Global Site Selector Global Server Load-Balancing Configuration Guide, Chapter 9, Configuring Network Proximity).
Modify the DRP authentication configuration on either the Cisco router running IOS release 12.1 or the primary GSSM GUI and make them consistent to avoid a DRP authentication mismatch.
Software Version 1.2(1) Open Caveats, Resolved Caveats, and Command Changes
The following sections contain the open caveats, resolved caveats, and command changes in GSS software version 1.2(1):
•
Open Caveats for Software Version 1.2(1)
•
Resolved Caveats for Software Version 1.2(1)
•
CLI Command Changes in Software Version 1.2(1)
Open Caveats for Software Version 1.2(1)
This section lists the open caveats for Cisco Global Site Selector Version 1.2(1).
•
CSCeg03056—With global sticky enabled, each GSS in a sticky peer mesh uses only the Lookup Fast queue and does not use the Lookup Slow queue. The output of the show statistics sticky global and show sticky global commands include Lookup Fast and Lookup Slow fields in their show output, however no value will appear in the Lookup Slow field.
For the version 1.2(1) software release, the GSS does not use the Lookup Slow queue. In this case, the GSS sends all inter-GSS global sticky messages to the Lookup Fast queue, including all sticky lookups with transmission interval greater than five seconds. Note that this behavior does not impact global sticky operation. The use of the lower priority Lookup Slow queue is most beneficial when operating under a very heavy DNS request rate load with four or more GSS devices in a global sticky peer mesh.
•
CSCeg10406—The use of the gssm restore command to restore the primary GSSM from the backup file can sometimes result in a misconfiguration or malfunction of the keepalive engine and DNS server on the standby GSSM or GSS devices. This behavior is caused as a result of the newly restored configuration not properly overwriting the previous configuration on the primary GSSM.
The following logs are symptoms of a misconfiguration in either the keepalive engine or DNS server:
KAL-4-KALSTATSNOGID[916] Could not find KAL-GID [208]KAL-4-KALGIDNOTFOUND[20077] kalDeleteVip: No KAL-GID found, removing based on GID [88]: successCRD-4-ANSWERNOTEXT[912] answer id 214 doesn't exist in selector but in kaleThe presence of a core file in the /core-files/keepalive and /core-files/dnsserver is evidence of this problem.
Workaround: Ensure the standby GSSM and all GSS devices have network connectivity with the primary GSSM and perform the following procedure:
a.
Log on to the CLI of the standby GSSM or a GSS.
b.
Enable privileged EXEC mode.
gss1.yourdomain.com> enablegss1.yourdomain.com#
c.
Enter the gss stop command to stop your GSS server.
gss1.yourdomain.com# gss stopd.
Navigate to the / directory to locate the node.state file. If you locate the node.state file in the directory, delete it.
gss1.yourdomain.com# cd /gss1.yourdomain.com# del node.stategss1.yourdomain.com# cd /homee.
Enter the gss start command to force the standby GSSM or GSS to retrieve a fresh and complete configuration from the primary GSSM.
gss1.yourdomain.com# gss startf.
Repeat this procedure for each GSS device in your network.
•
CSCeg27309—With global sticky enabled, when you use an option in the sticky database delete CLI global configuration command other than the all option to remove a large number of entries from the sticky database of a GSS device, the following two error messages may appear on the CLI:
Nov 9 19:00:01 SYSDB_ITEM_FAIL prox rc=50, mConnId=7, on the 1 attemptNov 9 19:00:02 SYS-4-CLIDSNODATA[18919] No buffer from DataServer for delete requestThese two messages indicate that the GSS CLI timed out prior to instructing you that the GSS successfully deleted the sticky entries. Although these two messages appear, the GSS did successfully delete the specified sticky database entries. You may ignore these two messages if you choose.
If you want to verify the status of the sticky database delete command, perform one of the following actions:
–
If you have logging enabled (log level 6) for the sticky subsystem, you can display the contents of the log file and see a similar set of log messages regarding the success with the sticky entry deletion process:
STK-6-STATSTATUSOK[17985] stickyDelete success, created response messageSTK-6-SDUMPRUN[17985] Dumping database, file:/local/brethomp/p4/acr/main/derived/ merlot/state/db_backup/stickydb_x–
Use the show sticky database command with the appropriate entry option. In the show sticky database output, no sticky entries should appear for the associated entry type, assuming that the GSS did not add additional entries with this attribute to the sticky database since the deletion.
•
CSCeg13386—With proximity enabled, if you do not enable authentication on the primary GSSM GUI but you do enable authentication on a Cisco IOS-based router, DNS requests sent to the GSS will fail. The DNS request failures are a direct result of a DRP authentication misconfiguration between the GSS and the router. The DNS requests may continue to fail even if you later enable authentication on the primary GSSM.
To verify a DRP authentication misconfiguration, use the following tools for monitoring network proximity status and statistics:
–
Primary GSSM GUI—Access the Proximity Probe Mgmt Statistics list page, located in the Traffic Mgmt section of the Monitoring tab. Review the DRP echo and measurement packets sent and received by each GSS device. If the statistics on the list page do not increment, this can indicate a DRP authentication misconfiguration.
–
GSS CLI—Enter the show statistics proximity probes detailed CLI command for each GSS in your network and view the output. Verify if DRP authentication is enabled and review the DRP echo and measurement requests sent and received by the GSS device per probe device. If the statistics on the show output do not increment, this can indicate a DRP authentication misconfiguration.
Workaround: Perform the following procedure to modify the key chain on the Cisco IOS-based router and resolve this DRP authentication misconfiguration issue:
a.
Set up a DRP authentication key chain on the Cisco IOS-based router using the same key number and key string that you configured in the original key chain.
b.
Enable the new DRP authentication key chain.
c.
On the GSS, enter the show statistics proximity probes detailed CLI command on the GSS and observe that successful DRP measurement probes occur between the GSS and Cisco IOS-based router.
d.
On the Cisco IOS-based router, enable the original DRP authentication key chain.
If this procedure fails to resolve the DRP authentication misconfiguration issue, use the proximity database delete all CLI command to remove all proximity database entries from GSS memory.
•
CSCeg14268—When you enter the Help prompt (?) after including either the | (pipe) or the > (redirect) command with a GSS CLI command, the CLI command may fail to execute and the % Invalid pipe. Allowed commands... message, or a similar error message, appears.
For example:
gss1# show version >?verbose Display additional system information<cr>gss1# show versionsh: -c: line 1: syntax error near unexpected token `|'sh: -c: line 1: `/cisco/merlot/bin/spen cli-show --version > |more -40'or
gss1# show version | ?verbose Display additional system information<cr>gss1# show version% Invalid pipe. Allowed commands are: grep, sort, wc, monitorWorkaround: Perform one of the following actions to remove the error message:
•
Execute the same GSS CLI command using the | (pipe) with the valid command following the | (pipe).
•
Log out of the current GSS session, then log back in to the GSS. If possible, avoid using the | (pipe) or the > (redirect) commands followed by the Help prompt (?).
•
CSCeg17971—When the GSS operates as a client with a TACACS+ server, the GSS may restrict user access to all CLI commands. This behavior may occur when you specify an encryption key on the GSS using the tacacs-server host command but do not specify the same encryption key on the TACACS+ server. In this case, the CLI command restriction takes place immediately on the GSS once you enter the aaa authorization commands CLI command.
Workaround: Enter the tacacs-server host command on the GSS, then specify the same encryption key on the TACACS+ server before you enter the aaa authorization commands CLI command on the GSS. If the GSS fails authorization on all CLI commands and you are unable to change the encryption key on the TACACS+ server, press the power button on the GSS to cycle power. Since the CLI commands entered prior to the power cycle were not saved in the GSS startup-configuration file, you can regain access to the GSS CLI and redo the TACACS+ configuration.
•
CSCef26505—Downgrading directly from software version 1.2(1) to version 1.0 is not supported at this time. If you attempt to downgrade from GSS version 1.2(1) to a GSS version 1.0 on a GSS 4480, the version 1.0 downgrade installation fails as follows:
4480.cisco.com#install gss-1.0.0.24.3-k9.upgFile: gss-1.0.0.24.3-k9.upgSize: 102389802Md5sum: eea463f81a298db8b21769fac7baea05Proceed with install (the device will reboot)? (y/n): yPerforming software install. This will take a few minutes.If you close this session, the installation will still complete.% Upgrade failed: The install script from the upgrade file failed.% The GSS is not running.Workaround: If you are currently running GSS software version 1.0 on your GSS 4480 and intend to downgrade to version 1.0, you must first install software version 1.1 or greater on the GSS 4480 before downloading the GSS software.
•
CSCef27479—When the GSS operates as a client with a TACACS+ server, the GSS fails to use the TACACS+ server for authentication when a user performs a remote SSH login using private and public key pairs. In this case, the SSH private and public keys on the GSS perform the user authentication and take priority over a TACACS+ server. If SSH private and public key pair authentication fails, then the TACACS+ server performs user authentication.
Workaround: To use a TACACS+ server for user authentication, disable the use of SSH key pairs on the GSS. Use the ssh keys CLI command to enable and disable SSH private and public key pairs. Refer to the Cisco Global Site Selector Getting Started Guide for details about configuring the GSS for remote over an SSH session that uses private and public key pairs for authentication.
•
CSCef58474—A GSS CLI session may become unresponsive when you enter the enable command to access privileged EXEC mode from user EXEC mode. This condition can occur when there are seven or more concurrent CLI sessions running on the same GSS.
Workaround: Reduce the number of concurrent sessions running on the same GSS to less than seven by logging out of one or more CLI sessions.
•
CSCee59028—When the GSS operates as a client with a TACACS+ server, it may prompt you for your TACACS+ password followed by your local password. This dual password prompting occurs when all configured TACACS+ servers are down and you attempt to perform local authentication with the GSS using either the console port or a Telnet connection.
Workaround: Enter your TACACS+ password followed by your local password to successfully log in to GSS.
•
CSCef93973—If you set up an NTP server after enabling NTP on a GSS, the following message may appear:
% Failed to set the clock via NTP using 192.168.0.1This message appears erroneously even though you properly enabled and configured the NTP server on the GSS and the NTP service is functioning properly. You may ignore this message if you choose.
Workaround: To remove this message:
a.
Enter the no ntp enable command to disable the NTP service
gss1.yourdomain.com# no ntp enableb.
Enter the ntp-server command to reconfigure all NTP servers.
gss1.example.com(config)# ntp-server 192.168.0.1 92.168.0.2c.
Enter the ntp enable command to reenable NTP.
gss1.yourdomain.com# ntp enable•
CSCef94037—The NTP service remains enabled in a GSS even if you disable the service before performing a GSS reboot. With software version 1.2(1), there is a new ntp enable command to enable the NTP service on the GSS. The ntp enable command is used with the ntp-server command to synchronize the GSS system clock with an NTP time server. To preserve backwards compatibility with previous versions of GSS software, software version 1.2(1) automatically adds the line ntp enable to the startup-configuration file created by a pre-GSS version 1.2(1) version of software. The re-occurrence of the line ntp enable in the GSS startup-configuration file happens when you define one or more NTP servers through the ntp-server command. Each time you reboot the GSS, the GSS automatically enables the NTP service if it detects an NTP server in the startup-configuration file.
Workaround: If you do not plan to use the GSS with an NTP server:
a.
Enter the no ntp enable command to disable the NTP service.
gss1.yourdomain.com# no ntp enableb.
Enter the no ntp-server command to disable all configured NTP servers.
gss1.example.com(config)# no ntp-server 192.168.0.1 92.168.0.2Resolved Caveats for Software Version 1.2(1)
This section lists the resolved caveats for Cisco Global Site Selector Version 1.2(1).
•
CSCec01715—When creating a VIP-type answer for a TCP or HTTP-HEAD keepalive in the Creating New Answer details page of the primary GSSM GUI, configuration issues may occur when you perform the following sequence:
a.
Deselect the VIP Address check box.
b.
Choose a Shared Keepalive from the drop-down list.
In this instance, the GSS still allows you to specify entries in the Port Number, Connection Termination Method, and the Host Tag and Path fields (for HTTP HEAD keepalive only), but ignores these values. This behavior occurs with Netscape Navigator 4.78, but is not reproducible with Microsoft Internet Explorer. The GSS supports only Netscape 4.79 browsers and above, which do not exhibit this behavior.
•
CSCec34850—On rare occasions, the FTP client on the GSS software may perform a core dump to the GSS /home directory and terminate the FTP process. This behavior has no impact on GSS performance or on subsequent FTP attempts. This defect is unreproducible.
•
CSCef41313—The GSS may sometimes perform an unnecessary reordering of answers included in a VIP-type answer group that uses the KAL-AP keepalive and round-robin balance method. Typically, when the GSS uses the round-robin balance method, each resource within an answer group is tried in turn. In this case, when the load on the answers changes, the GSS automatically sorts the order of the answers in the group and uses the top of the sorted list for the next answer. This action is unnecessary for round-robin load balancing.
•
CSCec46406—Restoring the database backup file from one primary GSSM to another primary GSSM may cause the latter primary GSSM to malfunction if you incorrectly answer certain restore questions. When moving a primary GSSM backup file from one primary GSSM to a different primary GSSM, even in a different GSS network configuration, it is important to properly answer the following network restore question: Do you want to replace your current GSS network configuration with the one specified in the backup file? (y/n):
–
Answer y (yes) at the prompt if you intend for the new primary GSSM to completely replace the primary GSSM on which the backup was created.
–
Answer n (no) at the prompt if the backup is being copied onto a different primary GSSM in a different GSS network configuration.
Incorrectly answering y (yes) for the wrong GSS configuration may result in improper behavior of the other GSSs in the network after you enter the gss enable command to register those devices with the new primary GSSM. As a general rule, if you intend to copy only elements such as DNS rules, keepalives, answers, and answer groups from the primary GSSM backup file, and not the GSS network relationships, always answer n to the database network restore question. This defect is unreproducible.
•
CSCeb46763—When you change an Ethernet interface configuration to either the bandwidth speed or duplex operation of one of the two Ethernet interfaces (0 or 1) on a Cisco GSS 4490, both interfaces are temporarily brought offline and then back online. This behavior occurs because the two Ethernet interfaces on the Cisco GSS 4490 are not independent of one another when configuring the link bandwidth speed or a duplex operation. The temporary offline state does not interfere with the GSS 4490 servicing DNS requests because interface commands cannot be executed while the GSS is running. You must issue the gss stop command before executing the interface command. The Cisco GSS 4480 does not exhibit this behavior.
CLI Command Changes in Software Version 1.2(1)
Table 1 lists the commands and options that have been added in GSS software version 1.2(1). For detailed information about the new CLI commands, refer to the book identified in the Book Title column of the table.
Table 2 lists the commands and options that have been changed in GSS software version 1.2(1). For detailed information about the modified CLI commands, refer to the book identified in the Book Title column of the table.
Software Version 1.1(1) Open Caveats
•
CSCeb24053—Attempting to log in to the GSS by Telnet, SSH, or FTP may take several minutes if an associated name server is unreachable. The GSS requires an operating name server to function properly. If you do not configure the name server using ip name-server commands or the configured name servers are not reachable for any reason (for example, name server down, network loss, firewall issues), the GSS is unable to perform DNS resolutions when users log in. When this problem occurs, the timeout may take several minutes to occur. This caveat was found in version 1.1(1).
Workaround: There is no workaround; the GSS requires a functioning name server. To avoid problems, always configure more than one name server. For example:
gss.yourdomain.com(config)#ip name-server 192.168.1.1gss.yourdomain.com(config)#ip name-server 192.168.2.2If the GSS has access lists configured, this problem may also occur. To avoid this issue, create access lists that allow the DNS responses from a name server. This can be done through the access-list command. For example:
gss.yourdomain.com(config)#access-list <name> permit udp any eq 53Another method is to allow only DNS response packets received from your configured name servers. For example:
gss.yourdomain.com(config)#access-list <name> permit udp 192.168.1.1 255.255.255.255 eq 53gss.yourdomain.com(config)#access-list <name> permit udp 192.168.1.2 255.255.255.255 eq 53gss.yourdomain.com(config)#access-list <name> permit udp 192.168.1.3 255.255.255.255 eq 53•
CSCec45409—The RSA libraries in the GSS are potentially vulnerable to an SSL exploit. It is unknown whether the RSA BSAFE SSL-J libraries are exploitable. This caveat was found in version 1.1(1).
Refer to the following link for information:
http://www-tac.cisco.com/Teams/PSIRT/HOT/ssl1003_status.html
•
CSCec46317—Attempting to enable a standby GSSM or GSS devices on the network immediately after enabling the primary GSSM may result in the primary GSSM failing to register the other GSS devices. Symptoms of this problem include: the standby GSSM or GSS devices not appearing in the primary GSSM GUI Global Site Selectors list page (Resources tab) and errors reported in the log files of the standby GSSM or GSS device. If this problem occurs, enter the gss disable command, followed by the gss enable command on the other GSS devices. This caveat was found in version 1.1(1).
Workaround: Perform the following sequence to enable the primary GSSM and other GSS devices and properly register those devices with the primary GSSM:
a.
Enable the primary GSSM using the gss enable gssm-primary command.
b.
Enter the gss status command and observe when the primary GSSM reaches the
Normal Operation [runmode = 5] state, then wait an additional minute. If necessary, repeat entering the command until the Normal Operation [runmode = 5] message appears. The primary GSSM is now ready to properly register the other GSSs devices within the network.c.
Register the other GSSs in the network with the primary GSSM using the gss enable gssm-standby primary_GSSM_IP_address or gss enable gss primary_GSSM_IP_address commands.
•
CSCdx58395—Content and Application Peering Protocol (CAPP) may not recognize dropped fragments when a KAL-AP keepalive spans multiple packets. When the KAL-AP keepalive spans multiple datagrams due to large payloads and one of the spanned packets is dropped, the GSS does not `retry' the request. This results in the dropped datagram not getting updated load values on the VIPs that are expecting them. Instead, the GSS waits until the next period and sends the packets again. This behavior occurs only in situations where the GSS consumes the full datagram (roughly 1.4 K) with tag names or VIPs. Otherwise, all data fits in one single datagram. This caveat was found in version 1.1(1).
Workaround: Use the KAL-AP by VIP format if there is a need to query the load on hundreds of VIPs configured to a single primary or secondary IP address. Alternately, use the KAL-AP by Tag format, but limit the length of Tag Names so that the packets do not exceed 1.4K.
•
CSCeb67314—The GSS does not allow you to assign the same pre-existing access list to the two Ethernet interfaces. If you attempt to use the access-group CLI command to assign the same access list to Ethernet 0 and Ethernet 1, the following error message appears: %access-list list1 is already assigned to interface eth1. This caveat was found in version 1.1(1).
Workaround: To resolve this issue, generate an identical access list for the second Ethernet interface.
Obtaining Documentation, Obtaining Support, and Security Guidelines
For information on obtaining documentation, obtaining support, providing documentation feedback, security guidelines, and also recommended aliases and general Cisco documents, 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
Copyright © 2004 Cisco Systems, Inc. All rights reserved.


