-
Cisco GSS GUI-Based Global Server Load-Balancing Configuration Guide (Software Version 1.3)
-
Index
-
Preface
-
Introducing the Global Site Selector
-
Configuring Resources
-
Configuring Source Address Lists
-
Configuring Domain Lists
-
Configuring Keepalives
-
Configuring Answers and Answer Groups
-
Building and Modifying DNS Rules
-
Configuring DNS Sticky
-
Configuring Network Proximity
-
Monitoring GSS Global Server Load-Balancing Operation
-
Primary GSSM Global Server Load-Balancing Error Messages
-
Sticky and Proximity XML Schema Files
-
Glossary
-
Table Of Contents
Sticky Mesh Conflict Resolution
Communicating in the Sticky Peer Mesh
Synchronizing the GSS System Clock with an NTP Server
Configuring Sticky Using the Primary GSSM GUI
Configuring the Global Sticky Mesh
Using the DNS Rule Builder to Add Sticky to a DNS Rule
Configuring Sticky Using the GSS CLI
Logging in to the CLI and Enabling Privileged EXEC Mode
Deleting a Sticky Group IP Address Block
Deleting Entries from the Sticky Database
Dumping Sticky Database Entries
Running a Periodic Sticky Database Backup
Loading Sticky Database Entries
Disabling DNS Sticky Locally on a GSS for Troubleshooting
Configuring DNS Sticky
This chapter describes how to configure a GSS to support DNS stickiness to answer requests received from client D-proxies. The GSS supports DNS sticky locally and also globally between GSS peers in the network.
This chapter contains the following major sections:
•
Configuring Sticky Using the Primary GSSM GUI
•
•
Note
DNS Sticky Overview
Stickiness, also known as persistent answers or answer caching, 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 stickiness in a DNS rule, the GSS makes a best effort to always provide identical A-record responses to the requesting client D-proxy, assuming that the original VIP continues to be available.
For many users browsing a site, being redirected to a new site is transparent. However, customers performing e-commerce or other transactions may experience a break in the connection when redirected, which results in a loss of the e-commerce transaction. Having DNS sticky enabled on a GSS helps to ensure 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 lifetime of the browser instance or for several hours, other browsers may impose a connection limit of 30 minutes before requiring a DNS re-resolution. This time period may not be long enough for a client to complete an e-commerce transaction. A new DNS resolution can then cause the client to connect to a server that is different from the original server, which can disrupt the transaction. DNS sticky helps to ensure that a client completes a transaction if a DNS re-resolution occurs.
This section includes the following topics on DNS sticky in the GSS:
Local DNS Sticky
With local DNS sticky, each GSS device attempts to ensure that subsequent client D-proxy requests to the same domain name from 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 sticky inactivity time interval, assuming the answer is still valid.
Each GSS dynamically builds and maintains a local sticky database that is based on the answers that the GSS sends to the requesting client D-proxies. If a subsequent request comes from the same client D-proxy, and the answer in the database is valid, the GSS returns the cached answer to the client D-proxy.
You configure the GSS to perform sticky load-balancing operations through the configuration of options on DNS rules and balance clauses. You identify the sticky method used by the DNS rule: matching a hosted domain or matching a hosted domain list. When sticking on a domain, the GSS provides the same sticky answer to all requests from a client D-proxy for that domain. When sticking on a domain list, the GSS provides the same sticky answer to all requests from a client D-proxy for all domains in that domain list.
Before returning a sticky answer to a client, the GSS verifies the keepalive status. The resource responds as follows:
•
•
•
Sticky Database
The sticky database provides the core intelligence for all DNS sticky-based decisions made by a GSS, on a local or global level. The GSS collects requests from the client D-proxies and stores these requests in memory as the sticky database. Requests may be identified by the IP address of the client D-proxy or a database ID representing a list of D-proxy IP addresses (configured as a sticky group, see the "Creating Sticky Groups" section). The D-proxy IP address may also be some form of a sticky global netmask if the global subnet mask is set to a value other than the default of 255.255.255.255.
The sticky database stores the answer to each request that the DNS rule matches, which may be for a single domain (including wildcard expressions) or a configured list of domains. These components make up each sticky database key that the GSS uses for the look up, storage, and persistence of stickiness for DNS responses.
The primary GSSM supports the creation of sticky groups which allow you to configure multiple blocks of D-proxy IP addresses that each GSS device stores in its sticky database as a single entry. Instead of multiple sticky database entries, the GSS uses only one entry in the sticky database for multiple D-proxies. The GSS treats all D-proxies in a sticky group as a single D-proxy.
All entries in the sticky database age-out respectively based on a user-specified global sticky inactivity timeout value. The sticky inactivity timeout value identifies the time period that an answer remains valid in the sticky database. Every time the GSS returns an answer to the requesting client, the GSS resets the expiration time of the answer to this value. When the sticky inactivity timeout value elapses without the client again requesting the answer, the GSS identifies the answer as invalid and purges it from the sticky database. You can specify a global sticky inactivity timeout default value for the GSS or modify the inactivity timeout value for each DNS rule.
Note
Upon receiving a DNS request, the GSS looks in the sticky database for a matched entry based on the combination of D-proxy IP address (or sticky group ID) and requested hosted domain or domain list information in the request. If the GSS finds a matched entry (a hit), the GSS returns the original DNS answer to the requesting D-proxy and the GSS resets the user-configured sticky inactivity timeout to its starting value. If the GSS does not find a matched entry (a miss), the GSS does not return a sticky answer but, instead, performs normal load balancing for the request to locate a new answer and add the new entry into the sticky database.
The GSS supports a maximum of 400,000 entries in the sticky database. When the total number of entries in the sticky database reaches 400,000, the GSS automatically removes entries from the database based on the lowest percentage of time remaining.
Global DNS Sticky
This section provides an overview of the global DNS sticky function and the behavior of GSS devices operating in a peer mesh. It includes the following topics:
•
•
GSS Sticky Peer Mesh
With global DNS sticky enabled, each GSS device in the network shares sticky database 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 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".
When one GSS device in the mesh receives a query from a client for a hosted domain or domain list, global sticky enables each GSS in the network to make a best effort attempt to return the same answer to the requesting client. This action is performed regardless of which GSS in the network is selected to answer the first and subsequent requests. The individual GSS devices work together to maintain a global sticky database across the network.
Each GSS in the peer mesh receives updates from the other peers and sends local changes to its remote peers. The GSS devices share the following information with the other GSS devices in the peer mesh:
•
•
•
Each GSS communicates updates to its remote GSS peers when any of the following situations occur:
•
•
•
•
A GSS does not send information to its peers when purging an answer from the sticky database due to reaching the normal sticky inactivity timeout or due to a sticky database overflow because it is expected that each GSS in the mesh performs this task independently.
When a local GSS node receives information from one of its peers in the network, that GSS performs a lookup of each received data entry in its local sticky database. Based on the results of the lookup, the GSS performs one of the following actions:
•
•
The GSS supports encryption of all inter-GSS communications to maintain the integrity of the sticky database information transferred among the mesh peers. Each GSS uses the Message Digest 5 (MD5) based hashing method to encrypt the application data sent throughout the mesh.
To authenticate communication between GSS devices in the mesh to prevent unauthorized device access, you can specify a secret string that is used by all GSS devices in the mesh. The secret string provides a key for authentication between GSS devices as well as for encryption (if enabled). Each local GSS uses the Challenge Handshake Authentication Protocol (CHAP) method to establish a connection with a remote peer.
Sticky Mesh Conflict Resolution
In some instances, two or more GSS devices in the mesh may answer the same sticky request at the same time. When the GSS devices communicate their updates to each peer, the recipient detects a conflict. Conflicts are resolved in the peer network by each GSS keeping the record with the greatest expiration time stamp, that is, the newest record. If the conflicting entries have identical time stamps, the GSS uses the entry containing the most recently configured answer based on configuration ID.
Conflicts are far more likely to occur when multiple requests are grouped by domain list, or when you group D-proxy clients by a sticky mask or by sticky group. For example, if you configure a DNS rule for domains A and B, one client may request GSS 1 for domain A, while a second client may make a request for domain B. If the GSS receives both requests at the same time, the two clients may receive different answers.
You can reduce global sticky mesh conflicts if you:
•
•
•
Communicating in the Sticky Peer Mesh
To successfully pass packets between GSS peers in the sticky mesh, ensure the following requirements are met:
•
•
•
If these conditions are not met, a GSS cannot properly receive or send packets with the other GSS peers in the sticky mesh.
A GSS leaves and rejoins the global sticky mesh when you perform one of the following actions:
•
•
•
•
Upon reentry into the mesh, the GSS attempts to load the sticky database from a peer GSS. The GSS uses the shortest round-trip time (RTT) to prioritize from which peer to request the database update. If a GSS peer is unavailable, the GSS locally restores the sticky database from the last available periodic database dump file. The GSS restores the sticky database from the database dump file anytime it rejoins the mesh and cannot retrieve a database from a GSS peer in the mesh. When the load is complete, the local database on the GSS device contains a full version of the sticky database.
If you want the local GSS node to attempt synchronization with a specific GSS peer upon reentry into the sticky mesh, you can identify a favored GSS peer for that GSS device. By identifying a favored GSS peer, you can also reduce network issues with peer synchronization, which typically generates a burst of network traffic. In this case, you direct network traffic to a different peer other than the GSS identified as being the closest (with the shortest round-trip time).
When you identify a favored peer, upon reentry into the mesh, the local GSS node always attempts to first synchronize its sticky database entries with the favored GSS peer. If the GSS peer is unavailable, the local GSS node queries the remaining mesh peers to find the closest up-to-date sticky database.
Network connectivity issues, GSS devices leaving and rejoining the mesh, and GSS device restarts have a minor impact on the synchronization of the sticky database. Sticky database entries always reconverge based on their usage and the user-configurable sticky inactivity timeout values.
DNS Sticky Quick Start Guide
Table 8-1 provides a quick overview of the steps required to configure the GSS for DNS sticky operation, both local and global DNS sticky. Each step includes the primary GSSM GUI page or the GSS CLI command required to complete the task. For the procedures to configure the GSS for DNS sticky, see the sections following the table.
Synchronizing the GSS System Clock with an NTP Server
If you are using global sticky in your GSS network, you must synchronize the clocks of all GSS devices in the mesh for a GSS to be able to communicate with the other GSS devices in the peer mesh. If the clock of a GSS device is out of synchronization with the other GSS peers (greater than a three minute difference), that GSS will ignore update messages from other GSS devices until you synchronize its system clock.
We strongly recommend that you synchronize the system clock of each GSS in the mesh with a Network Time Protocol (NTP) server. NTP is a protocol designed to synchronize the clocks of computers over a network with a dedicated time server.
You must specify the NTP server(s) for each GSS device operating in the global mesh before you enable DNS sticky for those devices from the primary GSSM GUI. This sequence ensures that the clocks of each GSS device are synchronized before they join the global sticky peer mesh.
Note
Use the ntp-server global configuration mode command to specify one or more NTP servers for GSS clock synchronization. The syntax for this CLI command is:
ntp-server ip_or_host
The ip_or_host variable specifies the IP address or host name of the NTP time server in your network that provides the clock synchronization. You can specify a maximum of four IP addresses or host names. Enter the IP address in dotted-decimal notation (for example, 172.16.1.2) or a mnemonic host name (for example, myhost.mydomain.com).
Use the ntp enable global configuration mode command to enable the NTP service. The syntax of this CLI command is:
ntp enable
This example shows how to specify the IP addresses of two NTP time servers for a GSS device and to enable the NTP service:
gss1.example.com> enablegss1.example.com# configgss1.example.com(config)# ntp-server 172.16.1.2 172.16.1.3gss1.example.com(config)# ntp enableConfiguring Sticky Using the Primary GSSM GUI
This section describes how to configure GSS devices for DNS sticky operation from the primary GSSM GUI and how to add stickiness to a DNS rule using the DNS Rule Builder. It includes the following procedures:
•
•
Configuring DNS Sticky
The GSS includes a set of DNS sticky settings that function as the default values used by the GSS network when you enable sticky in a DNS rule. You enable sticky and configure the DNS sticky settings for the GSS network through the Global Sticky Configuration details page of the Traffic Mgmt tab. Changing a DNS sticky setting and applying that change is immediate and modifies the default values of the DNS sticky settings used by the DNS Rule Builder.
To configure DNS sticky from the primary GSSM GUI:
1.
2.
Figure 8-1 Global Sticky Configuration Details Page—Sticky Configuration Fields
3.
•
•
•
4.
When you define a DNS sticky group for incoming D-proxy addresses (see the "Creating Sticky Groups" section), if the incoming D-proxy address does not match any of the entries in a defined DNS sticky group, then the GSS uses this global netmask value to calculate a grouped D-proxy network address.
5.
The Inactivity Timeout value can also be set individually for each DNS rule. When you set an Inactivity Timeout value for a DNS rule, that value overrides the global Entry Inactivity Timeout value.
Note
6.
To configure inter-GSS operation in the global sticky mesh through the Global Sticky Configuration details page, proceed to the "Configuring the Global Sticky Mesh" section.
Configuring the Global Sticky Mesh
The GSS includes a set of parameters to configure inter-GSS global sticky mesh operation. You configure mesh operation through the Global Sticky Configuration details page of the Traffic Mgmt tab.
To configure the inter-GSS device mesh operation from the primary GSSM GUI:
1.
2.
Figure 8-2 Global Sticky Configuration Details Page—Global Sticky Configuration Fields
3.
4.
•
•
5.
6.
A GSS joins the mesh upon a:
•
•
•
•
•
•
Upon reentry into the mesh, the local GSS node first attempts to synchronize its sticky database entries with the favored GSS peer. If the favored peer is unavailable, the GSS queries the remaining mesh peers to find the closest up-to-date sticky database (with the shortest round-trip time).
For example, assume there are four GSS devices in a mesh (gss_1, gss_2, gss_3, and gss_4), and both gss_1 and gss_2 are in the bootup process. You can direct local node gss_1 to gss_3 as its favored peer, and direct local node gss_2 to gss_4 as its favored peer. The identification of favored peers in the mesh can prevent those GSS devices that are booting from waiting for another database request to complete before their database synchronization request can be serviced.
If you want a GSS to automatically query all mesh peers to find the closest up-to-date sticky database, leave the individual GSS device selection at Unspecified. The GSS uses the shortest round-trip time to prioritize which peers to request a database update.
7.
Enabling Sticky in a DNS Rule
This section includes the following topics:
•
Note
Sticky DNS Rule Overview
After you enable DNS sticky from the Global Sticky Configuration details page, add stickiness to a DNS rule using the DNS Rule Builder. The GSS supports DNS stickiness in a DNS rule on either a matching domain (By Domain) or on a matching domain list (By Domain List). The By Domain and By Domain List sticky methods instruct the GSS that all requests from a client D-proxy for a matching hosted domain or domain list are to be given the same answer for the duration of a user-configurable sticky time period.
Enabling sticky in a DNS rule clause causes the GSS to look up in the sticky database for a matched entry based on a combination of D-proxy IP address and requested domain information, and, if the answer is found, to return the answer as the DNS response to the requesting D-proxy. If the answer is in the offline state, or the GSS does not find the answer, it evaluates the balance method clauses in the DNS rule to choose a new answer.
You can configure sticky individually for each balance clause in a DNS rule. However, the GSS prevents you from enabling sticky on Balance Clause 2 if you do not first enable sticky on Balance Clause 1. This restriction is also true if you attempt to enable sticky on Balance Clause 3 without first configuring sticky on Balance Clause 2.
Note
Using the DNS Rule Builder to Add Sticky to a DNS Rule
To use the DNS Rule Builder to add sticky to a DNS rule:
1.
2.
Figure 8-3 DNS Rules List Page
3.
Figure 8-4 Create New DNS Rule Window
4.
5.
•
•
•
6.
Note
7.
•
•
•
8.
Note
9.
Configuring Sticky Using the GSS CLI
This section discusses how to configure a GSS device for DNS sticky operation from the CLI. From the primary GSSM CLI, you can obtain better scalability of your GSS DNS sticky configuration and allow for ease of sticky y group creation through automation scripts. You can also use the CLI of each GSS in your network to perform sticky database activities on an individual GSS basis, such as removing sticky database entries from GSS memory, dumping entries from the sticky database to a named file, forcing an immediate backup of the sticky database, or loading and merging sticky database entries from a file.
The section includes the following procedures:
•
•
•
•
•
Logging in to the CLI and Enabling Privileged EXEC Mode
Note
To log in to a GSS device and enable privileged EXEC mode at the CLI:
1.
2.
Otherwise, if you are using a direct serial connection between your terminal and the GSS device, use a terminal emulation program to access the GSS CLI.
For details about making a direct connection to the GSS device using a dedicated terminal and about establishing a remote connection using SSH or Telnet, refer to the Cisco Global Site Selector Getting Started Guide.
3.
gss1.example.com>4.
gss1.example.com> enablegss1.example.com#Creating Sticky Groups
The primary GSSM supports the creation of sticky groups. A sticky group allows you to configure multiple blocks of D-proxy IP addresses that each GSS device stores in its sticky database as a single entry. Instead of multiple sticky database entries, the GSS uses only one entry in the sticky database for multiple D-proxies. The GSS treats all D-proxies in a sticky group as a single D-proxy.
This section includes the following topics:
•
DNS Sticky Group Overview
You create sticky groups from the primary GSSM CLI to obtain better scalability of your configuration and to allow for ease of sticky group creation through automation scripts. The primary GSSM supports a maximum of 800 sticky groups. Each sticky group contains one to 30 blocks of IP addresses and subnet masks (in dotted-decimal notation).
The grouping of D-proxy IP addresses in the sticky database provides you with a method to address proxy hopping. Certain ISPs rotate their D-proxies. A user's browser may use DNS server A to resolve a hostname, and later use DNS server B to resolve the same name. This technique, referred to as proxy hopping, has implications for sticky because the DNS sticky function remembers the client's D-proxy IP address and not the IP address of the actual client. In this case, rotating D-proxies appear to the GSS as unique clients. Sticky grouping provides you with a mechanism to globally group sets of D-proxies together to solve this proxy hopping problem.
In addition to creating DNS sticky groups of multiple D-proxy IP addresses from the CLI, you can configure a global netmask from the primary GSSM GUI to uniformly group contiguous D-proxies (see the "Configuring DNS Sticky" section). The global netmask is used by the GSS device when no DNS sticky group matches the incoming D-proxy address. The GSS uses the full incoming D-proxy IP address (255.255.255.255) and the global netmask as the key to look up in the DNS sticky database. The default global mask is 255.255.255.255.
Figure 8-5 illustrates how through DNS sticky group entries 192.168.9.0 255.255.255.0 and 172.16.5.1 255.255.255.255, the DNS requests from D-proxies 192.168.9.2, 192.168.9.3, and 172.16.5.1 all map to the identified group name, StickyGroup1. If no match is found in the sticky group table for an incoming D-proxy IP address, the GSS applies a user-specified global netmask to calculate a network address as the database key. In this example, DNS requests from 192.168.2.1 and 192.168.7.2 use the database entries keyed as 192.168.2.0 and 192.168.7.0 with a specified global netmask of 255.255.255.0.
Figure 8-5 Locating a Grouped Sticky Database Entry
Creating a DNS Sticky Group
To create a DNS sticky group, use the sticky group global server load-balancing command from the primary GSSM CLI to identify the name of the DNS sticky group and add an IP address block to the group. Use the no form of the command to delete a previously configured IP address block from a sticky group or to delete a sticky group.
You create sticky groups at the CLI of the primary GSSM to obtain better scalability of your configuration and to allow for ease of sticky group creation through automation scripts. The sticky groups are saved in the primary GSSM database and all GSS devices in the network receive the same sticky group configuration. You cannot create sticky groups at the CLI of a standby GSSM or individual GSS devices.
The syntax for this command is:
sticky group groupname ip ip-address netmask netmask
The options and variables are:
•
•
•
This example shows how to create a sticky group called StickyGroup1 with an IP address block of 192.168.9.0 255.255.255.0:
gssm1.example.com# configgssm1.example.com(config)# gslbgssm1.example.com(config-gslb)# sticky group StickyGroup1 ip 192.168.9.0 netmask 255.255.255.0Reenter the sticky group command if you want to perform one of the following tasks:
•
•
Each sticky group can have a maximum of 30 blocks of defined IP addresses and subnet masks. The GSS prohibits duplication of IP addresses and subnet masks among DNS sticky groups.
Deleting a Sticky Group IP Address Block
To delete a previously configured IP address block from a sticky group, use the no form of the sticky group ip command. For example:
gssm1.example.com# configgssm1.example.com(config)# gslbgssm1.example.com(config-gslb)# no sticky group StickyGroup1 ip 192.168.3.0 netmask 255.255.255.0Deleting a Sticky Group
To delete a sticky group, use the no form of the sticky group command. For example:
gssm1.example.com# configgssm1.example.com(config)# gslbgssm1.example.com(config-gslb)# no sticky group StickyGroup1Deleting Entries from the Sticky Database
You can remove entries from the sticky database of each GSS device by using the sticky database delete CLI command. When operating in a global sticky configuration, the result of the sticky database delete command propagates throughout the GSS mesh to maintain synchronization between the peers in the GSS network.
Caution
To view the entries in the sticky database to identify the sticky entries that you want to delete, use the show sticky database command (refer to the "Displaying Sticky Database Status" section in Chapter 10, Monitoring GSS Global Server Load-Balancing Operation).
Use the sticky database delete command to remove entries from the sticky database. The syntax for this command is:
sticky database delete {all | answer {name/ip_address} | domain {name} | domain-list {name} | group {name} | inactive minimum {minutes} maximum {minutes} | ip {ip_address} netmask {netmask} | rule {rule_name}}
The options and variables are:
•
•
•
•
•
•
–
–
Valid entries are 0 to 10100 minutes.
•
•
For example, to remove the D-proxy IP address 192.168.8.0 and subnet mask 255.255.255.0, enter:
gss1.example.com# sticky database delete ip 192.168.8.0 netmask 255.255.255.0Dumping Sticky Database Entries
The GSS automatically dumps sticky database entries to a backup file on disk approximately every 20 minutes. The GSS uses this backup file to initialize the sticky database upon system restart or reboot to enable the GSS to recover the contents of the database. When global sticky is enabled, the GSS restores from the database dump file anytime it reenters the mesh and cannot retrieve the sticky database contents from a GSS peer in the mesh.
If desired, you can dump all or selected entries from the sticky database to a named file as a user-initiated backup file. You can then use the ftp command in EXEC or global configuration mode to launch the FTP client and transfer the file to and from remote machines.
To view the entire contents of a sticky database XML output file from the GSS, use the type command. Refer to the Cisco Global Site Selector Administration Guide for details about displaying the contents of a file.
The GSS includes a number of options to provide a level of granularity for dumping entries from the sticky database. The GSS supports binary and XML output formats. Optionally, you can specify the entry type filter to clarify the information dumped from the sticky database.
If you do specify a format but do not specify an entry type, the GSS automatically dumps all entries from the sticky database.
If you attempt to overwrite an existing sticky database dump file with the same filename, the GSS displays the following messsage: Sticky Database dump failed, a file with that name already exists.
Use the sticky database dump command to output entries from the sticky database. The syntax for this command is:
sticky database dump {filename} format {binary | xml} entry-type {all | group | ip}
The options and variables are:
•
•
–
–
Note
•
–
–
–
This example shows how to dump the D-proxy source IP addresses from the sticky database to the sdb2004_06_30 file in XML format. If the dump is large, progress messages appear.
gss1.example.com# sticky database dump sdb2004_06_30 format xml entry-type ipStarting Sticky Database dump.gss1.example.com# sticky database dump sdb2004_06_30 format xml entry-type ipSticky Database dump is in progress...Sticky Database has dumped 15678 of 34512 entriesgss1.example.com# sticky database dump sdb2004_06_30 format xml entry-type ipSticky Database dump completed. The number of dumped entries: 34512gss1.example.com#When the dump finishes, a "completed" message displays and the CLI prompt reappears.
Running a Periodic Sticky Database Backup
You can instruct the GSS to dump sticky database entries to an output file on the GSS disk prior to the scheduled time. You may want to initiate a sticky database dump as a database recovery method to ensure you store the latest sticky database entries prior to shutting down the GSS.
To force an immediate backup of the sticky database residing in GSS memory, use the sticky database periodic-backup now command. The GSS sends the sticky database entries to the system dump file as the sticky database file. Upon a reboot or restart, the GSS reads this file and loads the contents to initialize the sticky database at boot time.
The syntax for this command is:
sticky database periodic-backup now
For example, enter:
gss1.example.com# sticky database periodic-backup nowLoading Sticky Database Entries
The GSS supports the loading and merging of sticky database entries from a file into the existing sticky database in GSS memory. The sticky database merge capability supports the addition of entries from one GSS into another GSS. The file must be in binary format for loading into GSS memory.
The GSS validates the loaded database entries, checks the software version for compatibility, and then adds the sticky database entries in memory. The GSS does not overwrite existing, duplicate entries in the sticky database.
Use the sticky database load command to load and merge a sticky database from disk into the existing sticky database in GSS memory. The syntax for this command is:
sticky database load filename
Note
Specify the name of the sticky database file to load and merge with the existing sticky database on the GSS device. The file must be in binary format for loading into GSS memory (see the "Dumping Sticky Database Entries" section). Use the ftp command in EXEC or global configuration mode to launch the FTP client and transfer the sticky database file to the GSS from a remote GSS.
This example shows how to load and merge the entries from the GSS3SDB file with the existing entries in the GSS sticky database:
gss1.example.com# sticky database load GSS3SDBDisabling DNS Sticky Locally on a GSS for Troubleshooting
You can disable DNS sticky for a single GSS when you need to locally override the GUI-enabled sticky option.You may need to locally disable sticky on a GSS when you need to troubleshoot or debug the device. The GSS does not store the local-disable setting in its running-configuration file. When you restart the device and sticky has been enabled from the primary GSSM GUI, the GSS reenables DNS sticky.
Use the sticky stop and sticky start commands to locally override the sticky enable option of the primary GSSM GUI.
When you enter the sticky stop command, the GSS immediately stops the following operations:
•
•
•
•
The GSS continues to answer DNS requests according to the DNS rules and keepalive status.
When you locally disable sticky on a GSS, sticky remains disabled until you perform one of the following actions:
•
•
•
If you are using global DNS sticky in your network, upon reentry of the GSS device into the peer mesh, the GSS attempts to synchronize the database entries with the other peers in the mesh. The GSS queries each peer to find the closest up-to-date sticky database. If no update is available from a peer, the GSS initializes the sticky database entries from the previously saved database on disk if a file is present and valid. Otherwise, the GSS starts with an empty sticky database.
This example shows how to locally disable DNS sticky on a GSS device using the sticky stop command:
gss1.example.com# sticky stopThis example shows how to locally reenable DNS on the GSS device using the sticky start command:
gss1.example.com# sticky start
