cisco systems advanced services...gss best practices 7 gss deployment best practices overview of gss...

Cisco Systems Advanced Services

Cisco Global Site Selector (GSS) Deployment Best Practices

Version 1.2

Corporate Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Tel: 408 526-4000 800 553-NETS (6387) Fax: 408 526-4100

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS. THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY. The following information is for FCC compliance of Class A devices: This equipment has been tested and found to comply with the limits for a Class A digital device, pursuant to part 15 of the FCC rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. This equipment generates, uses, and can radiate radio-frequency energy and, if not installed and used in accordance with the instruction manual, may cause harmful interference to radio communications. Operation of this equipment in a residential area is likely to cause harmful interference, in which case users will be required to correct the interference at their own expense. The following information is for FCC compliance of Class B devices: The equipment described in this manual generates and may radiate radio-frequency energy. If it is not installed in accordance with Cisco’s installation instructions, it may cause interference with radio and television reception. This equipment has been tested and found to comply with the limits for a Class B digital device in accordance with the specifications in part 15 of the FCC rules. These specifications are designed to provide reasonable protection against such interference in a residential installation. However, there is no guarantee that interference will not occur in a particular installation. You can determine whether your equipment is causing interference by turning it off. If the interference stops, it was probably caused by the Cisco equipment or one of its peripheral devices. If the equipment causes interference to radio or television reception, try to correct the interference by using one or more of the following measures: Turn the television or radio antenna until the interference stops. Move the equipment to one side or the other of the television or radio. Move the equipment farther away from the television or radio. Plug the equipment into an outlet that is on a different circuit from the television or radio. (That is, make certain the equipment and the television or radio are on circuits controlled by different circuit breakers or fuses.) Modifications to this product not authorized by Cisco Systems, Inc. could void the FCC approval and negate your authority to operate the product. The following third-party software may be included with your product and will be subject to the software license agreement: CiscoWorks software and documentation are based in part on HP OpenView under license from the Hewlett-Packard Company. HP OpenView is a trademark of the Hewlett-Packard Company. Copyright © 1992, 1993 Hewlett-Packard Company. The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California. Network Time Protocol (NTP). Copyright © 1992, David L. Mills. The University of Delaware makes no representations about the suitability of this software for any purpose. Point-to-Point Protocol. Copyright © 1989, Carnegie-Mellon University. All rights reserved. The name of the University may not be used to endorse or promote products derived from this software without specific prior written permission. The Cisco implementation of TN3270 is an adaptation of the TN3270, curses, and termcap programs developed by the University of California, Berkeley (UCB) as part of the UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright © 1981-1988, Regents of the University of California. Cisco incorporates Fastmac and TrueView software and the RingRunner chip in some Token Ring products. Fastmac software is licensed to Cisco by Madge Networks Limited, and the RingRunner chip is licensed to Cisco by Madge NV. Fastmac, RingRunner, and TrueView are trademarks and in some jurisdictions registered trademarks of Madge Networks Limited. Copyright © 1995, Madge Networks Limited. All rights reserved. Xremote is a trademark of Network Computing Devices, Inc. Copyright © 1989, Network Computing Devices, Inc., Mountain View, California. NCD makes no representations about the suitability of this software for any purpose. The X Window System is a trademark of the X Consortium, Cambridge, Massachusetts. All rights reserved. NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PRACTICAL PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. AccessPath, AtmDirector, Browse with Me, CCIP, CCSI, CD-PAC, CiscoLink, the Cisco Powered Network logo, Cisco Systems Networking Academy, the Cisco Systems Networking Academy logo, Cisco Unity, Fast Step, Follow Me Browsing, FormShare, FrameShare, IGX, Internet Quotient, IP/VC, iQ Breakthrough, iQ Expertise, iQ FastTrack, the iQ logo, iQ Net Readiness Scorecard, MGX, the Networkers logo, ScriptBuilder, ScriptShare, SMARTnet, TransPath, Voice LAN, Wavelength Router, and WebViewer, Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherSwitch, FastHub, FastSwitch, GigaStack, IOS, IP/TV, LightStream, MICA, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, SlideCast, StrataView Plus, Stratm, SwitchProbe, TeleRouter, and VCO are trademarks or registered trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain other countries. All other trademarks mentioned in this document or Web site are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0110R). Please refer to http://www.cisco.com/logo/ for the latest information on Cisco logos, branding and trademarks. INTELLECTUAL PROPERTY RIGHTS: THIS DOCUMENT CONTAINS VALUABLE TRADE SECRETS AND CONFIDENTIAL INFORMATION OF CISCO SYSTEMS, INC. AND IT’S SUPPLIERS, AND SHALL NOT BE DISCLOSED TO ANY PERSON, ORGANIZATION, OR ENTITY UNLESS SUCH DISCLOSURE IS SUBJECT TO THE PROVISIONS OF A WRITTEN NON-DISCLOSURE AND PROPRIETARY RIGHTS AGREEMENT OR INTELLECTUAL PROPERTY LICENSE AGREEMENT APPROVED BY CISCO SYSTEMS, INC. THE DISTRIBUTION OF THIS DOCUMENT DOES NOT GRANT ANY LICENSE IN OR RIGHTS, IN WHOLE OR IN PART, TO THE CONTENT, THE PRODUCT(S), TECHNOLOGY OF INTELLECTUAL PROPERTY DESCRIBED HEREIN. Software Upgrade Strategy Report Copyright © 2003, Cisco Systems, Inc. All rights reserved. COMMERCIAL IN CONFIDENCE. A PRINTED COPY OF THIS DOCUMENT IS CONSIDERED UNCONTROLLED.

GSS Best Practices 3

Contents

Contents 3

Document Control 5

History 5 Review 5

Document Overview 6

GSS Deployment Best Practices 7

Overview of GSS functionality 7 GSS & DNS 8 Domain Names 10 DNS Caching and TTL 11 DNS Sticky 12 Round Trip Time (RTT) and BIND 12 GSS Shared Keepalives 13 Testing 14 GSS Hierarchy 15 GSS system resilience 15 GSS deployment topology 16 GSS NS Forwarder 17 GSS Interfaces, protocols and ports 17 Extended DNS (EDNS0) 19 IPv6 19 Software upgrades 19 Changing the GSSM Role 20 Removing GSS’s from the network 20 Management - Remote Access 21 SYSLOG 21 SNMP 22

Contents

GSS Best Practices

4

TACACS+ 22 Database Backups 22 Performance monitoring 23 TAC Support 24 Password recovery 24

Appendix – Reference Materials 26


Document Control

This section of the report is to be used by the NCE for review and edit purposes prior to customer delivery. The document control section should be deleted from the report before customer delivery.

Author: Andrew Holding

EMEA Technology Practices - Data Centre Networking

Change Authority: Advanced Services

Reference Number: KBMS AS-98367

History Table 1 Revision History

Version No. Issue Date Status Reason for Change

1.1 15th July 2005 Draft First Release

1.2 2nd August 2005 First Release Ports/protocols updated as per CSCei43464. Password recovery section amended. Domain Name section added. Updated with comments from reviewers listed below.

Review Table 2 Revision Review

Reviewer’s Details Version No. Date

Lance McCallum, Yi Xue, Peter Marchand, Steven Petlock

1.1 1st August 2005


Document Overview

The purpose of this document is to present best practice deployment guidelines for the Cisco Global Site Selector (GSS).

There are a variety of configuration options, and variables associated with deploying a GSS solution, including client browser behaviour, DNS caching, DNS BIND server configuration, CSS and/or CSM configuration. The purpose of this document is to present a single document which will cover much of the scenarios likely to be encountered by the network designer/engineer.

Best practice configuration can also help improve the security of a network, decrease resource utilization, improve manageability, and reduce complexity.


GSS Deployment Best Practices

Overview of GSS functionality

The Global Site Selector (GSS) leverages the Domain Name System (DNS) to provide clients with reliable and efficient content services. Domain to IP address mapping is performed, with consideration for availability, location and load of content servers. Using the GSS in combination with Cisco’s Content Services Switch (CSS) or Cisco’s Catalyst 6000 Content Switching Module (CSM) allows users to create Global Server Load Balancing (GSLB) networks.

The GSS may be deployed in a variety of locations in a customer’s network to serve DNS requests, providing answers based on availability and preference. The GSS combines basic concepts of DNS with monitoring of answer status and providing users with IP addresses that are most appropriate for their content requests.

The GSS provides configuration and monitoring services through a central configuration manager, the Global Site Selector Manager (GSSM), and through a CLI1 that is available on each GSS. Configuration for a GSS network is mostly identical on all devices (global config model) and is entered by the user on a single GSS (central configuration model). For standard features the customer may choose to create a network of up to 8 GSSs with global/central configuration. The customer may instead choose to configure and monitor individual devices (local configuration model), in which case the GUI runs independently on each GSS and configuration is not shared.

The GSS receives DNS queries from client DNS proxies (D-Proxy), and matches these requests with a user-defined set of DNS Rules. A match on a DNS rule provides the list of 1st, 2nd and 3rd choice sets of answers that should be considered for the request.

Within a GSS network an answer is a host address which identifies a resource within a network that the GSS can direct a user to in order to respond to a content request. GSS answers are either a Virtual IP (VIP) Address associated with a server load balancer (SLB), a Name Server which can answer queries that the GSS cannot, or a Content Routing Agent (CRA) that use a resolution process called DNS race to send identical and simultaneous responses back to a user’s D-proxy.

The DNS rule also defines the balancing methods that should be applied for choosing from each set of possible answers, and can be combined with advanced features including checking for answers with the closest network proximity to the client’s requesting D-proxy, and use of a sticky database.

In addition to answering queries directly, the GSS offers the feature of forwarding requests to NS Forwarders, which will return a DNS response packet to the GSS, which in turn returns the exact same response packet to the originally requesting D-Proxy. This can be used for any query type on any domain, and is not limited to the record types supported by the GSS.

All of these options are user-configurable, and their suitability depends upon the customers requirements. Please refer to the GSS Configuration Guide for more information on the latest features available.

1 CLI configuration is only available for local network parameters.


GSS & DNS Although the GSS can be configured to be authoritative for an entire domain, e.g. cisco.com, the GSS is designed to be integrated into an existing traditional BIND-based DNS system. The GSS operates as an A-record DNS server for Hosted Domains (HD) for which it has been delegated authority from a higher-level name server, which generally would be a name server (NS) controlled by an Enterprise or ISP. In addition to A-record support, the GSS is able to proxy for other query types using NS Forwarding and a back-end name server such as BIND.

Cisco best-practice recommends that the GSS be delegated authority for a fully qualified domain name (FQDN), e.g. www.cisco.com, or an entire sub-domain (*.gss.cisco.com). See examples later in this section.

Clients (web browsers, streaming media players) make recursive DNS requests to their DNS proxies (local name servers) for web pages, or for linked content embedded within web pages. Through normal iterative DNS processing and caching, the D-Proxy will query the root name server, the high-level domain name server (e.g. a public .com NS), possibly other intermediate name servers (e.g. corporate cisco.com NS) and ultimately the GSS.

Figure 1 Client resolver iterative DNS process using Cisco GSS


Figure 1 summarises how the GSS interacts with the client in the Website selection process:

1. A client (DSL, Mobile user etc) wants to access the CCO website “www.cisco.com”. The resolver (client) sends a recursive query for www.cisco.com to the local client DNS name server (D-proxy).

2. The local D-proxy does not have an IP address for www.cisco.com, so it sends an iterative query to a root name server. The root name server replies2 with the address of the intermediate (a.k.a. Top Level Domain – TLD) name servers responsible for the .com domain.

3. The local D-proxy sends a query to the .com name server, which responds2, referring the D-proxy to the authoritative name server for cisco.com.

4. When the local D-proxy sends a query to the authoritative name server for cisco.com, it responds2 with the IP addresses of the two GSS’s, which tells the D-proxy to ask the GSS’s for the IP address for www.cisco.com.

5. The local D-proxy sends its final request directly to one of the two GSS’s. The GSS is authoritative for the www.cisco.com subdomain, so it sends the IP address to the D-proxy. The GSS sends the intelligent IP address of the "best" SLB at a specific data center-in this case, the SLB at data center 1.

6. The DNS global load-balancing process is complete; the client is directed to the SLB at data center 1 by the IP control or forwarding plane.

Figure 2 Example BIND configurations delegating two GSS’s (10.1.1.254 and 10.1.2.254) as authoritative for the www.cisco.com sub-domain.

Option 1 – Direct delegation of A records to GSS

$TTL 3h

cisco.com. IN SOA nameserver1.cisco.com. adminemail.cisco.com. (

2003070801 ; Serial

3h ; Refresh after 3 hours

1h ; Retry after 1 hour

1w ; Expire after 1 week

1h ) ; Negative caching TTL of 1 hour

;

; Name servers

;

cisco.com. IN NS nameserver1.cisco.com.

www.cisco.com. IN NS gss1.cisco.com. NS record for www.cisco.com via GSS1

www.cisco.com. IN NS gss2.cisco.com. NS record for www.cisco.com via GSS2

;

; Addresses

;

localhost.cisco.com. IN A 127.0.0.1

nameserver1.cisco.com. IN A 10.10.10.1

gss1.cisco.com. IN A 10.1.1.254 A record for GSS1

gss2.cisco.com. IN A 10.1.2.254 A record for GSS2

2 The name server can be configured to support either recursion or non-recursion, or both. A request from a client resolver is normally a recursive request (because it's simple "stub" implementation does not give the intelligence to follow a referral) and a request from a D-proxy is usually an iterative request (to reduce the load of name servers). If the name servers are perform a recursive query then they will ask on behalf of the requester, reply directly and then cache the answer.


;

Option 2 – Delegate subdomain to GSS’s using CNAME’s

CNAME’s can be used to reduce the number of NS Records configured within the DNS database. Here, the client still asks for www.cisco.com, however, the Name server converts this to www.gslb.cisco.com, using a CNAME record. The Name server then responds to the client D-proxy with the addresses of the GSS’s. The client D-proxy will cache these NS records, and then send a query for www.gslb.cisco.com to the GSS’s in a round-robin fashion.

Note: If the D-proxy sends a request to gss1 and it does not respond within 5 seconds it will automatically try gss2. The D-proxy will then double the polling rate to 10, 20 and 40 seconds to see if gss1 has recovered. However, once it finds a responding GSS it will lock on to it but if both are available then it will round robin

$TTL 3h

cisco.com. IN SOA nameserver1.cisco.com. adminemail.cisco.com. (

2003070801 ; Serial

3h ; Refresh after 3 hours

1h ; Retry after 1 hour

1w ; Expire after 1 week

1h ) ; Negative caching TTL of 1 hour

;

; Name servers

;

cisco.com. IN NS nameserver1.cisco.com.

gslb.cisco.com. IN NS gss1.gslb.cisco.com. delegates authority for gslb.cisco.com via GSS1

gslb.cisco.com . IN NS gss2.gslb.cisco.com. delegates authority for gslb.cisco.com via GSS2

;

; Addresses

;

localhost.cisco.com. IN A 127.0.0.1

nameserver1.cisco.com. IN A 10.10.10.1

gss1.gslb.cisco.com. IN A 10.1.1.254 A record for GSS1

gss2.gslb.cisco.com. IN A 10.1.2.254 A record for GSS2

;

; Aliases

;

www.cisco.com. IN CNAME www.gslb.cisco.com. client can use either name

Domain Names Domain names (RFC 1034) must follow the rules for ARPANET host names. They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. There are also some restrictions on the length. Names must be 63 characters or less. Domain names are case in-sensitive, and use both upper and lower case are allowed.

The GSS uses Domain Lists in order to identify relevant domain names. Within these Domain Lists, wildcards are supported (POSIX 1003.2 format), and square brackets are required to be placed around numeric characters.

E.g.


www.cisco.com; www2.cisco.com

.*\.fred\.cisco\.com

.*\.fred[2]\.cisco\.com

DNS Caching and TTL One important point to remember when configuring a GSS system is the role that the GSS plays when a client initially tries to communicate with a server.

A client trying to access www.cisco.com will send a recursive query to its D-proxy asking for the A-record for www.cisco.com. On receiving the query, the D-proxy will do one of the following;

• Check to see if has a cached resource record for www.cisco.com. If it has, then it will return the A-record(s) to the client, with the Authoritative Answer (AA) bit not set.

• If the D-proxy does not have a cached answer, then it will check to see if it has a cached NS Record for the cisco.com domain. If it has, then it will send an A-record query to the cisco.com name server, asking for the A-record(s) for www.cisco.com. On receiving a reply, the D-proxy will cache the answer(s) and send the reply to the client, this time with the AA bit set.

• If the D-proxy does not have a cached answer or cached NS Record, then it will consult the root name servers and proceed with the iterative queries as discussed previously - each time, caching any NS or A-records received.

Two important points to consider here, are the use of caching, and the number of A-records returned to the client.

• Caching occurs at all levels within the DNS process:

• By the client application (e.g. browser)

• By the client resolver (e.g. Windows 2000 and later)

• By the client’s D-proxy

When the client application receives more than one A-record it can choose which one it should connect to. If caching is supported (application and O/S specific), and the first IP address fails, then the second (third, fourth etc) can be used, thus providing an element of resilience at the application layer.

The application type (e-commerce etc), the application (e.g. browser) connection timeout, and the resolver cache timer must be considered when deciding on the number of A-records and the TTL that the GSS should return. If the cache timer is too long, there is the possibility of a dead-time when the IP Address is still cached, however, the IP address is no longer alive.

The time in which a record should be cached, is set by the Time to Live (TTL) parameter, which is set by a name server when returning an answer.

Normally, the client resolver and the D-proxy3 will honour the received TTL, however, applications rarely do by default. Cache timers vary considerably, depending upon the browser and operating system, the following list will provide pointers;

• Internet Explorer 4.x and later, caches DNS records for 30 minutes, no matter what the received TTL is. IE 6.x on Windows 2000, XP, and Server 2003 does not cache A-record responses (but does cache the CNAME). With Windows 2000, modifying the Registry settings allows IE to use either (whichever is lower) the Registry setting or the received TTL. See Microsoft Knowledge Base article 263558 for further information.

• Firefox and current Mozilla/Netscape versions caches A-records for 1 minute by default and ignores the received TTL. Netscape 4.x defaults to 15 minutes.

• Windows 2000 and later, use a DNS cache which is independent from the Browser cache, and which will honour the TTL Set by the D-proxy. The current cache is viewable using the “ipconfig /displaydns” and can be flushed using the “ipconfig /flushdns” at the command prompt. With Windows XP and 2003 the cacheing behaviour can be temporarily stopped using the “net stop

3 Versions of BIND prior to 4.8.3 ignore the received TTL and default to a value of 5 minutes.


dnscache” command, and permanently disabled at the Service Controller tool. See Microsoft Knowledge Base article 318803 for further information.

The GSS allows independent configuration of TTL’s for all A-record answers that are configured. The range is from 0 to 604,800 seconds (1 week) – the default TTL timer is 20 seconds. Using a zero TTL is not recommended since it is very likely that this will not be honoured by most devices.

One workaround for the difficulty in setting the most appropriate TTL is to use multiple A-records. This would allow the application to use an alternative IP Address should the first one it tries be unavailable. This method although attractive at first is problematic, since the client D-proxy will likely change the order in which the A-records are returned. This issue can be mitigated by using DNS sticky in combination with location cookies4 on the CSS, which will allow the CSS to redirect the user to the correct site.

Obviously, there is no one-size-fits-all recommendation for the length of the TTL. If the value is too high then you risk stale records; if the value is too small then you may affect application performance5 and increase the load on the DNS Servers.

DNS Sticky When a client re-issues a DNS request, either due to the application cache time or DNS resolver TTL expiring, then it is possible/likely that a different A-record will be returned by the DNS server. As we have already seen, some versions of Internet Explorer will automatically re-resolve the hostname after 30 minutes. Most e-commerce applications will break when a client is directed to another site.

Let us consider an example of a user connecting to an e-commerce web-site, who then goes for a cup of tea for 25 minutes. When he comes back he fills his shopping cart and is about to complete his purchase by logging in and being redirected to the site’s secure HTTPS pages when the browser’s 30 minute timer expires. The browser may re-resolve to a different IP address, meaning the user loses his shopping cart.

The GSS provides a feature called DNS sticky which will ensure that an identical A-record (assuming that VIP continues to be available) is always returned to a client’s D-proxy for the period of a configurable timeout. Using the Global sticky feature, the sticky table can be shared amongst GSS’s in a system ensuring that all GSS’s will return the same A-records.

If the application is intranet facing (the D-proxy is known), then pre-populating the sticky table (static sticky) is the recommendation.

If the application is Internet facing, then it is likely that the client will change his D-proxy server (known as Proxy-hopping) mid-session, and in this case source IP and destination domain hash with a subnet mask is recommended.

Round Trip Time (RTT) and BIND Back to our example of a client requesting the A-record for www.cisco.com: Assuming the client’s D-proxy does not have either the A-record (www.cisco.com) or the NS record (.cisco.com) cached, then the D-proxy will ask the .com name server for the name servers that are authoritative for the .cisco.com domain. It is likely that he will receive a list of name servers, but which one will he ask?

BIND6 has a feature (not mentioned in the DNS RFC) that it will measure the RTT between it and each of the name servers listed in the reply. Once it has asked all of the servers, subsequent requests will only be sent to the server which has the lowest RTT7.

4 Since cookies reside in the HTTP header, SSL-based sessions will require decrypting before cookies can be read. 5 A very low TTL will also impact the performance of a webpage loading, because of the overhead of looking up every embedded object. 6 the de-facto DNS process running on the D-proxy server 7 This does not mean only one NS server will ever be used. BIND will increase the RTT each time it asks a particular server. If that server becomes unresponsive then the RTT will be increased significantly. For a server to remain first choice, it has to keep on answering quickly and consistently


What this means is that when you consult the GSS statistics, you may find that there is not an even spread between the number of answers served by the GSS’s for a particular DNS rule.

GSS Shared Keepalives As well as individual keepalives (KAL) per answer, the GSS supports shared keepalives. Shared keepalives are used in order to minimize the traffic between the GSS and the server load-balancers (CSS, CSM etc) that the GSS is monitoring.

These shared keepalives allow the GSS to send one request packet, that queries the status of many answers. These answers are identified either using the IP address of the VIP or a “tag”. The recommendation is to use the “tag” option, since this allows greater granularity, since it is entirely likely that the CSS/CSM will have multiple VIP’s using the same IP Address.

The “tag” method is also required if the GSS and SLB device are separated by a NATing device such as a firewall.

It is also recommended that the APP sessions be encrypted using an MD5 hash. All keepalive configurations on the GSS is performed from the GUI, and example configurations for the CSM and CSS can be seen in Figure 3 and Figure 4

Figure 3 KAL-AP by tag CSM configuration module ContentSwitchingModule x

…

!

vserver CSM1

virtual 192.168.1.1 tcp www

serverfarm fredservers

domain fred.com tag identified here persistent rebalance

inservice

!

capp udp enable APP protocol

secure enable MD5 hashing

options <GSS IP Address>8 encryption md5 <key> set the hash key

Figure 4 KAL-AP by tag CSS configuration CSS1# show running-‐config

!*************************** GLOBAL ***************************

app-‐udp enable APP protocol

app-udp secure enable MD5 hashing

app-udp options <GSS IP Address>9 encrypt-md5hash <key> set the hash key …

owner fred

8 The IP address can be set to 0.0.0.0 meaning all peers will use this hash


content fred

vip address 192.168.1.1

add service icmpkal-‐s1

add dns fred.com tag identified here active

…

Note: unlike APP peering between SLB’s, no peer configuration is required.

Testing Use a resolver tool such as NSLOOKUP9 to query a particular domain name, specifying the GSS IP Address as the NS if required, as follows;

D:\ >nslookup www.cisco.com. 10.1.1.1

Server: gss1.test.com

Address: 10.1.1.1

Name: www.cisco.com

Address: 192.168.1.10

With Windows 2000 and XP, you can query the DNS Cache (and watch it decrement) using the IPCONFIG command line tool. In the following example, the client has asked the cisco.com NS, which has the www.cisco.com subdomain delegated to the GSS (gss1.cisco.com);

C:\>ipconfig /displaydns

….

www.cisco.com.

-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐

Record Name . . . . . : www.cisco.com

Record Type . . . . . : 1

Time To Live . . . . : 18

Data Length . . . . . : 4

Section . . . . . . . : Answer

A (Host) Record . . . : 192.168.1.10 A-record answer

Record Name . . . . . : cisco.com




Section . . . . . . . : Authority

NS Record . . . . . : gss1.cisco.com Authoritative NS

Record Name . . . . . : gss1.cisco.com

9 With Windows 2000 & IE5, without Registry modification, using the browser to resolve a domain name will NOT populate the resolver cache. If the Registry has been modified then the browser and resolver are synchronised.





Section . . . . . . . : Additional

A (Host) Record . . . : 10.1.1.1 A-‐record for NS

… etc

15 seconds later repeat the command and see the TTL decrease…


…

www.cisco.com.

-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐

Record Name . . . . . : www.cisco.com


Time To Live . . . . : 3 TTL reduced by 15


Section . . . . . . . : Answer

A (Host) Record . . . : 192.168.1.10

… etc

5 seconds later the entry is no longer in the cache


… etc

C:\>

The client’s DNS cache can be manually flushed using the ipconfig /flushdns command. Closing and re-opening the browser will refresh its cache.

GSS Hierarchy A GSS system comprises of between one (two recommended as a minimum for redundancy, and as specified in RFC1912) and eight GSS’s, each interacting with geographically dispersed SLB’s, and independently answering DNS queries.

A GSS can run in one of three modes;

• Primary GSS Manager (GSSM) – Performs DNS functions as normal, along with providing a centralized GUI for configuration and statistics gathering for the GSS system

• Standby GSSM – Performs DNS functions as well as acting as a backup to the Primary GSSM, in the event of failure of that device. All changes to the GSS database, made on the Primary GSSM, are synchronized with the Standby GSSM.

• GSS – Performs DNS functions according to the configurations made on the Primary GSSM.

GSS system resilience All GSS’s in a system, are statically configured with the IP Addresses of the Primary GSSM and the Standby GSSM. The GSS will poll the IP Address of the Primary GSSM in order to gather configuration updates and report statistics, and will poll the Standby GSSM if the Primary GSSM is unreachable.


On failure of the Primary GSSM, all other GSS’s (including the Standby GSSM) continue to answer DNS requests as normal, however, at this point it is impossible to make configuration changes or retrieve statistical information.

You enable the Standby GSSM as the primary GSSM through the “gssm standby-‐to-‐primary” CLI command.

Note: Ensure that your original primary GSSM is offline before you attempt to enable the standby GSSM as the new primary GSSM. Having two primary GSSMs active at the same time may result in the inadvertent loss of configuration changes for your GSS network. If this dual primary GSSM configuration occurs, the two primary GSSMs revert to standby mode and you must reconfigure one of the GSSMs as the primary GSSM.

The standby GSSM can temporarily take over the role as the primary GSSM in the event that the primary GSSM is unavailable (for example, you need to move the primary GSSM or you want to take it offline for repair or maintenance). The switching of roles between the designated primary GSSM and the standby GSSM is intended to be a temporary GSS network configuration until the original primary GSSM can be brought back online. Once the original primary GSSM is available, reassign the two GSSMs to their original roles.

GSS deployment topology GSS’s providing DNS Services for internet facing applications, are typically deployed within an externally accessible, firewalled DMZ which also hosts the enterprise delegating DNS name servers. For internal applications, there is no strict rule as to where the GSS should reside in the network.

Note: The Primary and Standby GSSM’s cannot be separated by a NATing firewall – CSCea28410 refers.

Split DNS can be deployed within an enterprise using separate internal and externally accessible name servers, each performing a distinct role. Here, the internal name servers are configured10 to forward queries they can't resolve to the external name server. The external DNS servers are then configured to contain only a small number of resource records for the domain, listing things such as Web and FTP server addresses and any translated server addresses that are published to the world. The internal name servers hold only the DNS records for internal networks. When internal users look up host names, the query is answered by internal DNS servers, even if the request is forwarded to an external DNS server for resolution. Internet users who look up host names in your domain are answered by external DNS servers that only know about the publicly accessible resources.

If GSS’s are deployed to perform both roles in a Split DNS scenario, they would be setup in different GSS systems – that is there would be one Primary GSSM (and Standby GSSM etc) for the external GSS system and another one for the internal GSS system.

The firewalls should be configured to prevent unauthorized access to your GSS network and thwart common denial of service (DoS) attacks on your GSS devices. Additionally, the GSS packet-filtering features can enable GSS administrators to permit and disallow traffic to any GSS device.

When positioning your GSS behind a firewall or enabling packet filtering on the GSS itself, you must properly configure each device (the firewall and the GSS) to allow valid network traffic to reach the GSS device on specific ports. In addition to requiring HTTPS traffic to access the primary GSS graphical user interface, you may want to configure your GSSs to allow FTP, Telnet, and SSH access through certain ports. In addition, GSSs must be able to communicate their status to and receive configuration information from the GSSM. Finally, primary and standby GSSMs must be able to communicate and synchronize with one another. See Figure 5 Inbound Traffic Going Through a Firewall to the GSS and Figure 6 Outbound Traffic Originating from the GSS for a list of all relevant protocols and ports.

Note: The GSS supports UDP-based DNS traffic on both interfaces concurrently. TCP-based DNS is only supported on the interface configured for “gss-communications”, meaning out-of-band GSS-to-GSS communications and TCP-based DNS cannot co-exist.

10 Under Berkeley Internet Name Domain (BIND) 4, use the "forwarders" directive. In BIND 8 systems, use the "forwarders" sub-statement to configure forwarding


GSS NS Forwarder As well as supporting A-records, the GSS can also be configured to forward unknown queries to a traditional BIND-based name server. Using this feature, the GSS acts as a proxy, requesting the resource record on behalf of the querier.

Note: The GSS does not cache the answers received.

The use of the NS forwarder feature is configured either by adding a second clause to an all ready configured rule to forward all non-A records requests to a separate DNS or by creating a new domain list to use “.*” in a new separate rule which will forward all requests matching that rule.

The first way forwards all Non-A records (select “All” in the DNS Rule builder “Match DNS Query type” window) for configured domains that are delegated to the GSS and the second forwards ALL record types and domains that do not match the configuration on the GSS.

The recommended GSS deployment is for the GSS system to be delegated authority only for those FQDN’s that it is authoritative for. The use of the NS forwarder feature can be used as a “catch-all” in case there is any mis-configuration within the DNS system, such as typographical errors, client is using IPv6 etc in order to prevent black-holing or negative caching.

GSS Interfaces, protocols and ports The GSS has two physical Ethernet ports (eth0 and eth1), and by default, will accept all traffic (DNS11, Telnet, HTTPS etc) on both interfaces. TCP (incl HTTP) keepalives can only use one interface (default is eth0). The interface used can be changed using the “gss-tcp-keepalives” CLI interface command. All inter-GSS communications can only use one interface (default is eth0). The interface used can be changed using the “gss-communications” CLI interface command. Where an out of band management network exists, it is recommended to assign eth112 to this role, by applying appropriate security access-lists to the two interfaces. For example, deny HTTPS, SSH, Telnet, SNMP, NTP, FTP on the eth0 interface, but permit those protocols on the eth1 interface. Note: Security ACL’s have an implicit “deny any any” statement which will drop all traffic that has not been explicitly permitted. Note: An ACL cannot be applied to two interfaces. In order to do this, two separate ACL’s would be required. Please refer to the “GSS Configuration Guide”, “Configuring Access Lists and Filtering” for further information. There is no requirement for the GSS’s within the same system to be within the same physical network or subnet. The only requirement is that they be able to communicate with each other for exchanges of such things as configuration updates, global sticky table updates, and performance statistics. Note: When there are multiple GSS’s within a GSS System, those GSS’s must not be deployed behind a device performing NAT. The communication between the GSS devices cannot include an intermediate device behind a NAT because the actual IP address of the devices is embedded in the payload of the packets.

Figure 5 & Figure 6 show the protocols and ports that are used by the GSS.

Figure 5 Inbound Traffic Going Through a Firewall to the GSS

Source Port

(External Device)

Destination Port (GSS) Protocol Details

11 TCP-based DNS is only supported on the interface configured for gss-communications 12 Eth0 is the default interface used for GSS-to-GSS Communications, which usually occurs over the public interface. This behaviour can be changed by configuring “gss-communications” within the interface CLI.


ICMP ICMP ping keepalives from GSS to VIP

user-defined TCP TCP keepalives

* 20-23 TCP FTP, SSH, and Telnet services

* 53 UDP, TCP GSS DNS server traffic

53 * UDP GSS software reverse lookup and "dnslookup" queries

123 123 UDP Network Time Protocol (NTP) updates

161 UDP Simple Network Management Protocol (SNMP) traffic

443 TCP Primary GSSM GUI

1304 1304 UDP CRA keepalives

1974 1974 UDP DRP-based proximity packets between GSS and DRP-agent

* 2000 UDP GSS reporting to GSSM

* 2001-2005 TCP Configuration updates from GSSM

3002-3008 * TCP GSS statistics reporting and requests for configuration updates

* 5001 TCP Global sticky table traffic

500213 5002 UDP KAL-AP keepalives

* 53760-65535 TCP Java RMI (Java servers - dynamically open upto 5 ports in this range)

Figure 6 Outbound Traffic Originating from the GSS

Source Port (GSS)

Destination Port (Remote Device) Protocol Details

20-23 * TCP Return traffic of FTP, SSH, and telnet server services on the GSS

* 20, 21, 23 TCP Traffic of FTP, and Telnet GSS CLI commands

53 * UDP, TCP GSS DNS server traffic

* 53 UDP GSS software reverse lookup and "dnslookup" queries

123 123 UDP Network Time Protocol (NTP) updates

161 * UDP Simple Network Management Protocol (SNMP) traffic

443 * TCP Primary GSSM GUI

1304 1304 UDP CRA keepalives

1974 1974 UDP DRP-based proximity packets between GSS and DRP-agent

* 2000 UDP GSS reporting to GSSM

* 2001-2005 TCP Configuration updates from GSSM

2001-2005 * TCP Configuration updates from GSSM

13 KAL-AP’s port number can be changed at the GSS GUI, and on the SLB (CSS command is “app-udp port 1025-65535”


* 3002-3008 TCP GSS statistics reporting and requests for configuration updates

* 5001 TCP Global sticky table traffic

* 5002 UDP KAL-AP keepalives

53760-65535 * TCP

Java RMI (Java servers - dynamically open upto 5 ports in this range)

Extended DNS (EDNS0) The GSS does not (as of software version 1.2) support EDNS (RFC2671). By default, the GSS will reject a DNS query with a FORMERR, if it contains an EDNS RR. When the GSS rejects a DNS query that contains an EDNS RR in the additional record section, the client’s D-proxy has to query again without having the EDNS RR which will slow down the overall DNS process. To enable support of EDNS RR, use the CLI property set ServerConfig.dnsserver.enableEDNS 1 command. To restore to default value, use CLI no property set ServerConfig.dnsserver.enableEDNS 1 command. gss restart must be issued after either of these commands in order to take effect. CSCeb19861 refers.

IPv6 The GSS does not (as of software version 1.2) support AAAA records, however it is RFC2308 compliant in that it will respond with a NODATA (NOERROR) return code with Answer count 0 in order to prevent negative caching of DNS records.

Software upgrades Please follow the GSS Administration Guide “Upgrading the GSS Software” for full software upgrade procedures.

The best-practice recommendations to ensure a painless upgrade are as follows;

1. Console access is preferred (though not essential), in case problems occur.

2. Note that the software images are large, and the upgrade procedure can cause a GSS to be offline for up to ten minutes. Note: The DNS delegation process should automatically take care of a non-responding GSS.

3. Verify the role of the current Primary and Standby GSSM.

4. During the upgrades, it is strongly recommended that no configuration changes are made. Also, it is not recommended to change the GSSM roles (e.g. from Standby GSSM to Primary GSSM) meaning configurations and statistic monitoring will not be possible during the upgrade of the Primary GSSM.

5. Take a Full Backup of the Primary GSSM database. This can be taken at anytime, and does not interfere with the functions of the Primary GSSM or other GSS’s in the system.

6. Archive the GSSM database backup file

7. Archive all the startup (CLI) config files of all GSS’s in the system

8. Download the new GSS software from www.cisco.com, and place the files on an FTP or SCP server which is accessible from your GSS’s.14

14 If you are currently running GSS software version 1.0 on your GSS 4480 and you want to have the opportunity to downgrade back to version 1.0, you must first upgrade to software version 1.1 before loading software version 1.2. Downgrading directly from software version 1.2 to version 1.0 is not supported at this time.


9. Starting with the Primary GSSM, and then continuing with the other GSS’s in the system, copy (FTP or SCP) the new software from the server.

10. Stop the GSS system, and then install the upgrade.

11. Reboot the GSS, and proceed with the other GSS’s in the system

12. Use the Primary GSSM GUI Monitoring tab to monitor the status of the GSS’s in the system to ensure they come back online.

13. Issue test DNS queries to each GSS after they are back online to ensure they are functioning correctly.

Changing the GSSM Role The GSS software supports two GSSMs in a single GSS network, with one GSSM acting as the primary GSSM and a second GSSM acting as a standby device. The standby GSSM is capable of temporarily taking over the role of the primary GSSM in the event that the primary GSSM is unavailable (for example, you need to move the primary GSSM or you want to take it offline for repair or maintenance).

Note: The switching of roles between the designated primary GSSM and the standby GSSM is intended to be a temporary GSS network configuration until the original primary GSSM is back online. If necessary, use the primary GSSM to monitor GSS behaviour and make configuration changes.

Using the CLI, you can manually switch the roles of your primary and standby GSSMs at any time. Before switching GSSM roles, note the following guidelines:

1. There must be an existing Primary and Standby GSSM in the network

2. Ensure that the designated primary GSSM is offline before you attempt to enable the standby GSSM as the new primary GSSM. Having two primary GSSMs active at the same time may result in the inadvertent loss of configuration changes for your GSS network. If this dual primary GSSM configuration occurs, the two primary GSSMs change to standby mode. You must then reconfigure the original deployed primary GSSM as the primary GSSM.

Removing GSS’s from the network You may need to logically remove a GSS from your network when you:

• Move a GSS device between GSS networks

• Physically remove or replace a GSS or standby GSSM

• Send the GSS or standby GSSM out for repair or replacement

Note: Do not logically remove the primary GSSM from the GSS network. If you need to take the primary GSSM offline for either maintenance or repair, temporarily switch the roles of the primary and standby GSSMs as outlined in the section “Changing the GSSM Role”.

The procedure for gracefully removing a GSS from the network is as follows;

1. Access the GSS CLI

2. Backup the startup configuration

3. Archive the startup configuration to an FTP or SCP Server

4. Stop the GSS process

5. Disable the GSS process to delete all configuration and database files


6. Shutdown the GSS

7. Access the GSSM GUI Resources Tab and delete the GSS from the list

Please see the GSS Administration Guide for full information.

Management - Remote Access

The GSS Supports remote management access using a directly connected console lead, Telnet, SSH or HTTPS (Primary GSSM only).

Basic device setup, logging configuration, file transfer and other network management functions are offered exclusively via the CLI, including the extensive monitoring that is available. High-level activity and status monitoring is also offered via the GUI.

GSS v1.2 supports three user roles – Administrator, Operator and a read-only Observer mode. The operator role has limited control to activate and suspend answers but without the ability to change the configuration. These modes are available from the GUI only.

For complete details about multiple user roles refer to the GSS Administration guide.

SYSLOG The GSS supports extensive SYSLOG capabilities to allow the user to monitor the GSS operations. The format of the host syslog messages generated by a GSS, is now CiscoWorks RME Syslog Analyzer compliant.

These system logs can be monitored from the GUI (Tools/System Logs) of the GSSM, as well as via the CLI when accessing the gss.log file, using the show logs {follow | tail} command.

Additionally, the GSS logs subsystem (dnsserver, keepalive, sticky, tacacs+, etc) events in the system.log file, and the levels of these messages are determined by the configured logging level (0 = emergency, 1 = alert, 2 = critical, 3 = error, 4 = warning, 5 = notification, 6 = information, 7 = debugging). You can view these subsystem log files from the CLI using the type command (you will need to change to the appropriate directory for that subsystem first).

Decisions about what level of GSS logging to use can be made globally, or configured on a subsystem-by-subsystem basis. For example, you can configure the primary GSSM to log all error-level messages, but also configure the sticky manager (sticky) to log all information-level messages using the logging disk {enable | priority loglevel | subsystem name priority loglevel}

By default, the GSS logs system messages to the /state/gss.log file on the GSS hard-disk, however, SYSLOG messages can be sent to a remote host using the logging host {enable | ip ip_address | priority loglevel | subsystem name priority loglevel} command. Logging to a host is disabled by default.

Use the show logging command to verify the current setup of your device, as follows; gss1.cisco.com# show logging

Logging to disk is enabled.

Priority for disk logging is Informational(6).

Logging to host is disabled.

Priority for host logging is Warning(4).

It is possible to clear these system logs using the CLI gssm database purge-‐log-‐records {count number_records_to_keep | days number_days_to_keep} command. Use the GSSM GUI Tools/System Logs to verify the SYSLOG’s have been purged.


SNMP GSS software v1.2 supports the standard MIB-II and HOST-RESOURCES-MIB. From the GSS CLI issue the “dir /mibs” command to list all of the currently supported MIB’s.

Note: The GSS does not support SNMP trap functionality, though the format of the host SYSLOG messages generated by a GSS, is now CiscoWorks RME Syslog Analyzer compliant.

TACACS+ TACACS+ accounting, authorisation authentication is supported in all GSS modes (P-GSSM, S-GSSM and GSS). This allows the system administrator to control who can access a GSS, control which CLI Commands that user can use and log which commands are actually entered.

Please consult the GSS Administration guide for full information on how TACACS+ can be configured.

Be aware of caveat CSCee29158 – Shouldn’t need to configure users both on Tacacs server and GSS. Users wishing to access the CLI of the GSS via telnet, SSH, console, and FTP with TACACS authentication enabled, will need to configure the username/password in the TACACS server and also locally on the GSS in order for authentication to work. If they do not configure this locally on the GSS users will not be granted access to the GSS even though the GSS statistics show it passed. (see the note below on unmatched passwords). This limitation does not exist for users trying to access the GSS GUI when with web based authentication configured.

Note: that while the usernames must match exactly15, the password on the GSS is not used unless the TACACS server is down and "local" authentication is enabled. Since “local” is always enabled for the login service (telnet and console), a bogus GSS password unknown to the user can be used to keep the user from logging into the GSS should the server be down.

Database Backups The GSSM database maintains all network and device configuration information, as well the DNS rules used by the GSS devices to route DNS queries from users to available hosts.

Because the primary GSSM database is so important to the continued operation of your GSS network, it is important that you make frequent backups of your primary GSSM and its database. Frequent backups ensure that if a sudden and unexpected power loss or media failure occurs, your GSSM configuration and database survive, and your GSSM can be quickly restored to operation.

Perform a backup of your primary GSSM:

• Before switching GSSM roles and before making the standby GSSM your primary GSSM on your network

• Before you perform a GSS software upgrade

• After you make any changes in the device or network configuration of your GSSM

During the backup process, the GSS software performs a full backup of the GSSM network configuration settings as well as the GSSM database that contains global server load-balancing configuration information. A full backup of the primary GSSM provides you with the flexibility to pick and choose the specific GSSM configuration information you wish to later restore on the primary GSSM.

Whenever you execute a backup on your primary GSSM, the GSS software automatically creates a tar archive (“tarball”) of the necessary files. A tar archive is a group of files collected together as a single file. This file has the .full extension.

Use the following command to perform a full database backup on the GSSM; gssm1.example.com# gssm backup full gssmfullbk

GSSM database backup succeeded [gssmfullbk.full]

15 Username cannot be numeric


Use either SCP or FTP to archive the backup file to a remote host, for example; gssm1.example.com# scp gssfullbk.full server.example.com:~/

Note: The primary GSSM backup does not include user files that reside in the /home directory. If you have important files in the /home directory that you want to save, use either the secure copy (scp) or ftp commands to copy those files.

You may need to restore a previous primary GSSM backup for the following reasons:

• You have replaced your primary GSSM with a new device and wish to restore a previous backup to that primary GSSM.

• You are downgrading the GSS software to an earlier release.

• You have made a number of configuration changes to the primary GSSM and would like to return to the previous backup of the GSSM.

When restoring the primary GSSM from a previous backup, use the last backup to restore the GSS device network configuration settings as well as the encryption keys used to communicate with other GSS devices. Restoring the primary GSSM from a backup returns the device to its exact configuration as of the last backup.

Stop the GSS software on the primary GSSM, then use the gss status command to confirm that the primary GSSM has stopped.

atcr1.cisco.com# gss stop

atcr1.cisco.com# gss status

Cisco GSS -‐ 1.2(1.0.0) -‐ [Mon Sep 15 11:33:47 UTC 2003]

gss is not running.

After the GSSM software stops, use the gssm restore command to restore the GSSM from the backup file. For example, to restore the file gssmfullbk.ful l,enter:

gss1.example.com# gssm restore gssmfullbk.full

See the GSS Administration guide for more information.

Performance monitoring It is possible to monitor the operation of the GSS system, both from the GSSM GUI and the CLI of each GSS in the system. View the GUI Resources/Global Site Selectors/ Modify GSS page to get system information about the GSS’s in the system. Use the CLI gss status verbose command to show the running processes and the CPU utilisation.

The state of the GSSM database can be checked by issuing the CLI gssm database status command, and verified by the gssm database validate command. If database validation fails, then generate a validation log using the gssm database report command, which can be viewed with the following command: type /home/validation.log.

You can use the show statistics CLI command to display content routing and load balancing statistics for each component of your GSS global server load balancing operation: Boomerang (CRAs), DNS, DNS sticky, network proximity, and keepalives.Refer to the Cisco Global Server Load-Balancing Configuration Guide for details on displaying statistics using the show statistics command.

It is not possible to clear the statistics using the GUI, however, it is possible to clear the global statistics, using the CLI Command "clear statistics dns". This is global, and cannot be done on a per-rule basis for example.

Configuration updates are pushed to the other GSS's in a system within a matter of seconds (no definite value I'm afraid). In case this does not happen there is also a "pull" mechanism, where the GSS will actively poll the Primary GSSM for any configuration updates, by default (configurable) every 5 minutes.


Statistics are retrieved by the Primary GSSM at the same time that it pushes the configuration updates. These updates are then retrieved by the GSSM GUI from the statistical database every 60 (configurable) seconds, or manually refreshed by clicking on the circular arrow at the top right of the monitoring pages (not the browser's refresh button).

TAC Support The GSS software includes two CLI commands to assist a Cisco Technical Assistance Center (TAC) representative in troubleshooting potential problems on your GSS network.

Use the following CLI commands:

• show tech-‐support [config | core-‐files] —Displays a report on the current operating configuration of your GSS device that can be used by a Cisco TAC representative in troubleshooting problems on your GSS network. The config option exports the output of all configured fields from the primary GSSM GUI, and can also be useful for hard-copy archiving of the GSS database. Enter the show tech-‐support config command to display a listing of all core files useful to Cisco TAC.

• gss tech-‐report filename —Generates a detailed report for use by a Cisco TAC representative in troubleshooting persistent GSS problems. The file generated is a compressed tar- format archive file with a .tgz extension. The filename variable identifies a user-assigned name for the report generated by the gss tech-report command.

Password recovery To restore the default administrator password used to log in to the primary GSSM GUI, or if you want to change the administrator password, use the reset-‐gui-‐admin-‐password command. The GSS stores the administrator username and password in a safe partition of the hard disk to prevent loss of data due to power failures. If you change the administrator password, and then either lose or forget the password, you can reset the password back to default by using the reset-‐gui-‐admin-‐password command on the primary GSSM.

Only users with the administrator privilege can remove or change the administrator’s GUI password.

The syntax for this command is: reset-‐gui-‐admin-‐password [password text]

The password text option allows you to change the administrator password used to log in to the primary GSSM GUI. Enter an unquoted text string with no spaces and a length of 6 to 16 characters.

For example, to change the change the administrator password to mynewpassword, enter: gssm1.example.com# reset-‐gui-‐admin-‐password password mynewpassword

If you forget the CLI administrator password, then you can reset it from the CLI (this requires console access) as follows;

enter the reload command to halt and perform a cold restart of your GSS device. gssm1.example.com# reload

As the GSS reboots, output appears on the console terminal. After the BIOS boots and the LILO boot: prompt appears, enter ? (a question mark) to determine which software version the GSS device is running and to enter boot mode.

LILO boot: ?

gss

boot:

Note: Enter the ? command within a few seconds of seeing the LILO boot prompt or the GSS device continues to boot. If you miss the time window to enter the ? command, wait for the GSS to properly complete booting, enter the reload command, and try again.


At the boot: prompt, enter gss RESETADMINCLIPW=1. Use care when entering this command; this CLI command is case-sensitive.

boot: gss RESETADMINCLIPW=1

If you successfully reset the administrator password, the Resetting admin account CLI password message appears. If the message does not appear, repeat steps 2 through 4 again. Pay close attention when you enter the gss RESETADMINCLIPW=1 command.


Appendix – Reference Materials

• Release Note for the Cisco Global Site Selector, Release 1.2(2) available from http://www.cisco.com/en/US/partner/products/hw/contnetw/ps4162/prod_release_note09186a008044bc0a.html

• Configuration Guides available from http://www.cisco.com/en/US/partner/products/hw/contnetw/ps4162/products_installation_and_configuration_guides_list.html

• Business Case for Global Server Load Balancing http://www.cisco.com/en/US/partner/products/hw/contnetw/ps4162/products_white_paper09186a00801b7725.shtml

• RFC1034 - DOMAIN NAMES - CONCEPTS AND FACILITIES, RFC1912 - Common DNS Operational and Configuration Errors etc

• Data Centre Fundamentals – Cisco Press

• The Concise Guide to DNS and BIND Nicolai Langfeldt

• Cisco internal collateral and Knowledge Base

Corporate Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA www.cisco.com Tel: 408 526-4000 800 553-NETS (6387) Fax: 408 526-4100

European Headquarters Cisco Systems Europe 11 Rue Camille Desmoulins 92782 Issy-Les-Moulineaux Cedex 9 France www-europe.cisco.com Tel: 33 1 58 04 60 00 Fax: 33 1 58 04 61 00

Americas Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA www.cisco.com Tel: 408 526-7660 Fax: 408 527-0883

Asia Pacific Headquarters Cisco Systems Australia, Pty., Ltd Level 9, 80 Pacific Highway P.O. Box 469 North Sydney NSW 2060 Australia www.cisco.com Tel: +61 2 8448 7100 Fax: +61 2 9957 4350

Cisco Systems has more than 200 offices in the following countries and regions. Addresses, phone numbers, and fax numbers are listed on the

Cisco Web site at www.cisco.com/go/offices.

Argentina • Australia • Austria • Belgium • Brazil • Bulgaria • Canada • Chile • China • Colombia • Costa Rica • Croatia • Czech Republic Denmark • Dubai, UAE Finland • France • Germany • Greece • Hong Kong SAR • Hungary • India • Indonesia • Ireland • Israel • Italy • Japan • Korea • Luxembourg • Malaysia • Mexico The Netherlands • New Zealand • Norway • Peru • Philippines • Poland • Portugal • Puerto Rico • Romania • Russia • Saudi Arabia • Singapore • Slovakia • Slovenia South Africa • Spain • Sweden • Switzerland • Taiwan • Thailand • Turkey • Ukraine • United Kingdom • United States • Venezuela • Vietnam • Zimbabwe

cisco systems advanced services...gss best practices 7 gss deployment best practices overview of gss...

Documents