Table Of Contents
Configuring the CSS
Domain Name Service
CSS Domain Name Service Overview
CSS Peering Protocol Overview
Configuring Application Peering Protocol
Configuring APP Frame Size
Configuring APP Port
Configuring an APP Session
Using the RCMD Command
Showing APP Configurations
Configuring a CSS as an Authoritative DNS Server
Configuring DNS-Server BufferCount
Configuring DNS-Server RespTasks
Configuring a DNS Server Forwarder
Show DNS Server Information
Displaying DNS Server Forwarder Statistics
Configuring CSS DNS Peering
Configuring DNS Peer-Interval
Configuring DNS Peer-Receive-Slots
Configuring DNS Peer-Send-Slots
Show DNS Peer Information
Configuring Owner DNS
Adding DNS Service to Owner-Content
Removing DNS from Owner-Content
Configuring Source Groups to Allow Servers to Internet-Resolve Domain Names
Showing Domain Summary Information
Configuring Client Side Accelerator
Overview
Example CSA Configurations
Single POP CSA Configuration
Multiple POP CSA Configuration
Client Side Accelerator Quick Start
Enabling the Client Side Accelerator
Configuring the Domain Cache
Configuring a DNS Server Forwarder
Configuring Accelerated Domains
Resetting the DNS Record Statistics
Configuring the CSA DNS Server Zones
Displaying Client Side Accelerator Information
Displaying the Client Side Accelerator Configuration
Displaying DNS Server Domain Cache Statistics
Displaying DNS Server Keepalive Information
Displaying Domain Acceleration Records Statistics
Configuring a CSS as a Content Routing Agent
Overview
Content Routing Agent Quick Start
Enabling the Content Routing Agent
Configuring the CPU Load Threshold
Configuring Domain Records
Configuring an Alias for an Existing Client Domain
Clearing Domain Statistics
Displaying Content Routing Agent Statistics
Configuring the CSS
Domain Name Service
This chapter provides an overview of the CSS Domain Name Service (DNS) feature and describes how to configure it for operation. Information in this chapter applies to all CSS models, except where noted.
Note
The CSS Domain Name Service feature is part of the CSS Enhanced feature set.
This chapter provides the following sections:
•
CSS Domain Name Service Overview
•
CSS Peering Protocol Overview
•
Configuring Application Peering Protocol
•
Configuring a CSS as an Authoritative DNS Server
•
Configuring CSS DNS Peering
•
Configuring Owner DNS
•
Configuring Source Groups to Allow Servers to Internet-Resolve Domain Names
•
Showing Domain Summary Information
•
Configuring Client Side Accelerator
•
Displaying Client Side Accelerator Information
•
Configuring a CSS as a Content Routing Agent
CSS Domain Name Service Overview
The CSS Domain Name Service (DNS) feature enables you to configure one or more CSSs together to construct highly available, distributed, and load-sensitive Web sites. Groups of CSSs may host many distributed Web sites concurrently. These groups make decisions that can be configured independently for each distributed Web site using local and remote load balancing information.
CSSs that are configured together for DNS form a content domain. Within the content domain, CSSs are known as peers. You can configure peers to exchange content rules, load balancing information, and service availability.
Each CSS becomes aware of all the locations for the content associated with a domain name and the operational state and load of the location. The CSS can then intelligently direct clients to a site where they can best obtain the desired content. In addition, a CSS never sends a client to a location that is overburdened or out of service.
You can use DNS to configure a CSS as a DNS authoritative server. A CSS defined as an authoritative DNS server resolves DNS names when requested by a client.
For example, when a user clicks on a URL on a Web page:
1.
The client asks the locally configured DNS server for a translation of a domain name to an IP address. The DNS server contains the CSS virtual IP address (VIP) and DNS names.
2.
The DNS server requests address resolution from the CSS DNS authoritative server.
3.
The CSS DNS authoritative server returns the VIP address of the best location (that is, server availability and load) where the client can retrieve the content.
4.
The DNS server responds to the client with the VIP.
5.
The client uses the VIP to access the content.
Note
The CSS implementation of DNS server functionality is a streamlined, endnode-only approach. The CSS does not support zone transfer among other DNS servers. However, each CSS configured in a content domain can act as the authoritative DNS server.
CSS Peering Protocol Overview
CSSs configured within the same content domain initiate communication over Application Peering Protocol (APP) sessions with their peers upon system bootup or when peers first become connected through an APP session. Thereafter, changes in local configurations are relayed to the peers automatically as they occur. When the APP session is up, the peers exchange owner names according to the DNS exchange policies configured for each owner.
For each owner that a CSS is configured to share with its peers, the CSS sends the locally configured content rules and DNS name information. Upon receiving a peer's content rule information, the CSS compares each DNS name and content rule to its local configuration.
Content rules that:
•
Match a locally configured content rule cause a dynamic service to be added automatically to the local content rule. The local content rule points to the peer for an alternate location for the content.
•
Do not have a corresponding local entry cause the CSS to automatically create a dynamic content rule containing a dynamic service that points to the peer that has the content rule configured.
The determination of whether or not a content rule matches is based strictly on content rule name. Peers having matching content rule names must have exact copies of rule definitions with the exception of VIP addresses. DNS names do not need to be identical.
Note
CSSs do not include dynamic services or dynamic content rules in their running- or startup-config files. Dynamic services and dynamic content rules are temporary and are removed when the peer connection terminates.
For example, when a client requests www.arrowpoint.com:
1.
The client browser asks the locally configured DNS server for a translation to an IP address.
2.
The DNS server round-robins an address resolution request to one of the CSSs.
3.
The selected CSS DNS authoritative server determines server availability based on the DNS balance type.
If the CSS is configured as DNS balance type dnsbalance preferlocal and is:
•
Able to locally handle the request for this DNS name, it returns the local VIP to the DNS server.
•
Not able to handle the request for this DNS name (the server has reached a defined load threshold or is unavailable), the CSS returns the dynamic content rule VIP to the DNS server.
If the CSS is configured as DNS balance type dnsbalance roundrobin the CSS resolves requests by evenly distributing the load to resolve domain names among local and remote content domain sites.
For information on configuring DNS balance types, refer to the Content Services Switch Basic Configuration Guide, Chapter 7, Configuring Content Rules.
4.
The DNS server forwards the resolved VIP to the client.
illustrates two peer CSSs configured as authoritative DNS servers. Each CSS knows its local content rule VIPs and dynamic content rule VIPs. The @ sign within a content rule VIP indicates a dynamic content rule. Owner www.arrowpoint.com is configured for dns both (push and accept owner www.arrowpoint.com and its content rule L3Rule). Even though CSS-Boston contains owners www.arrowpoint.com and www.dogs.com, only owner www.arrowpoint.com and content rule L3Rule are shared between the CSSs.
Figure 7-1 CSS Configured as Authoritative DNS
Configuring Application Peering Protocol
When two CSSs communicate, they use an Application Peering Protocol (APP) session. An APP session allows the exchange of content information between a pair of configured CSSs. APP provides a guaranteed and private communications channel for this exchange. Two or more CSSs that are configured to exchange content rules over APP sessions form a content domain and are considered peers.
Note
The Application Peering Protocol feature is part of the CSS Enhanced feature set.
To configure APP sessions, use the app command. The options for this global configuration mode command are:
•
app - Enable all APP sessions
•
app framesz - Set the maximum frame size allowed by the APP
•
app port - Set the TCP port that listens for APP connections
•
app session - Create an APP session
To enable all APP sessions, enter:
To disable all APP sessions, enter:
Configuring APP Frame Size
To set the maximum size allowed by the APP, use the app framesz command. Enter the maximum app frame size from 10240 to 65535. The default is 10240. Upon session establishment, peers select the smallest configured frame size to use for session communication. For example, CSS-A is configured for frame size 5000 and CSS-B is configured for frame size 6000. Once the session is established, CSS-B will use frame size 5000.
For example:
(config)# app framesz 5096
To restore the default frame size to 10240, enter:
Configuring APP Port
To set the TCP port number, use the app port command. This port listens for APP connections. Enter a port number from 1025 to 65535. The default TCP port is 5001.
For example:
To restore the default port number to 5001, enter:
Configuring an APP Session
To create an APP session between two CSSs, use the app session command. The CSSs use APP sessions to create a content domain that shares the same content rules, load, and DNS information with each other.
The syntax and options for this global configuration mode command are:
app session ip_address {keepalive frequency {authChallenge|authNone session_secret {encryptMd5hash|encryptNone {rcmdEnable|rcmdDisable}}}}
Note
The authChallenge|authNone and encryptMd5hash|encryptNone APP command options must be identical for both CSSs in an APP session or the session will not come up.
The keepalive and rcmd command options do not have to be identical between CSS peers.
The variables and options are:
•
ip_address - IP address for the peer CSS.
•
keepalive frequency - Optional time in seconds between sending keepalive messages to this peer CSS. Enter an integer from 14 to 900 (15 minutes). The default is 14.
•
authChallenge|authNone - Optional authentication method for the session. Enter either authChallenge for Challenge Handshake Authentication Protocol (CHAP) method or authNone for no authentication method. The default is no authentication.
•
session_secret - Secret used with AuthChallenge to authenticate a peer or used with encryptMd5hash to provide an MD5hash encryption scheme for the session. Enter an unquoted text string with a maximum of 32 characters.
•
encryptMd5hash|encryptNone - Optional encryption method for the packets. Enter either encryptMd5hash for MD5 base hashing method or encryptNone for no encryption method. The default is no encryption.
•
rcmdEnable|rcmdDisable - Optional setting for sending remote CLI commands to the peer through the rcmd command. Enter either rcmdEnable to allow the sending of CLI commands or rcmdDisable to disallow the sending of CLI commands. The default setting is enabled.
To terminate an APP session, enter the no app session command and an IP address:
(config)# no app session 192.2.2.2
For example, to configure a CSS in Boston (IP address 172.1.1.1) to be a peer of a CSS in Chicago (IP address 192.2.2.2), use the app command to configure:
CSS-Boston(config)# app session 192.2.2.2
CSS-Chicago(config)# app session 172.1.1.1
Using the RCMD Command
To issue remote CLI commands to a CSS peer, use the rcmd command. Before you can use this command, use the (config) app session command to configure an APP session. The rcmd command is available in SuperUser mode.
The syntax for this command is:
rcmd ip_address or host "CLI command {;CLI command...}" {timeout_response}
The variables are:
•
ip_address or hostname - The IP address or host name for the peer.
•
CLI command - One or more CLI commands you want to issue to the peer. Enter the command, its options, and variables exactly. Enclose the command text string in quotes (""). When entering multiple CLI commands, insert a semicolon (;) character to separate each command.
Note
You cannot issue grep, grep within a script command, or redirect commands.
•
timeout_response - The optional amount of time, in seconds, to wait for the output command response from the peer. Enter an integer from 3 to 300
(5 minutes). The default is 3 seconds.
Note
By default, the APP session is configured to allow sending remote commands to a CSS peer. If you disable this function using the no app session command, use the (config) app session command to enable it.
For example:
# rcmd 192.2.2.2 "show domain" 10
Showing APP Configurations
To display the APP configuration or session information, use the show app command. APP is the method in which private communications links are configured between CSSs in the same content domain. A content domain consists of group of CSSs configured to exchange content information.
The syntax and options for this command are:
•
show app - Display whether APP is enabled, its port number, and frame size setting. For example:
Table 7-1 describes the fields in the show app output.
Table 7-1 Field Descriptions for the show app Command
Field
|
Description
|
Enabled or Disabled
|
Whether all APP sessions are enabled or disabled.
|
PortNumber
|
The TCP port number that listens for APP connections. The port can be a number from 1 to 65535. The default is 5001.
|
MaxFrameSize
|
The maximum frame size allowed on an APP channel between CSSs. The frame size is a number from 10240 to 65535. The default is 10240.
|
•
show app session - Display all IP session information including the session ID, IP address, and state. For example:
(config)# show app session
•
show app session ip_address - Display the IP session information including the session ID, IP address, and state. For example:
(config)# show app session 192.168.10.10
•
show app session verbose - In addition to displaying the IP session information, the verbose keyword displays detailed information about the IP configuration parameters for the session including the local address, keepalive frequency, authorization and encryption type, frame size, and packet activity.
•
show app session ip_address verbose - Displays the same information as the show app session verbose command except that it displays information only for the specified IP address.
Table 7-2 describes the fields in the show app session output.
Table 7-2 Field Descriptions for the show app session Command
Field
|
Description
|
App Session Information
|
DNS-resolved hostname as defined through the host command.
|
Session ID
|
The unique identifier for the session.
|
IP Address
|
The IP address for the peer CSS.
|
State
|
The current state of the session. The possible states include:
• APP_SESSION_STOP, indicating that the session is about to be deleted
• APP_SESSION_INIT, indicating that the session is initializing
• APP_SESSION_OPEN indicating that the connection to the peer has been made
• APP_SESSION_AUTH indicating that the authentication is occurring
• APP_SESSION_UP indicating that the session is up
• APP_SESSION_DOWN indicating that the session is down
|
Local Address
|
The local interface address. If the session is down, no address is displayed.
|
rcmdEnable
|
The setting for the sending of remote CLI commands to the peer through the rcmd command. The Enabled setting allows the sending of CLI commands. The Disabled setting disallows the sending of CLI commands. The default setting is enabled.
|
KalFreq
|
The time in seconds between sending keepalive messages to this peer CSS. The time can be from 14 to 900 seconds (15 minutes). The default is 14.
|
Auth Type
|
The authentication method for the session. The method is either authChallenge for Challenge Handshake Authentication Protocol (CHAP) method or none for no authentication method. The default is no authentication.
|
Encrypt Type
|
The encryption method for the packets. The method is either encryptMd5hash for MD5 base hashing method or none for no encryption method. The default is no encryption.
|
MaxFrameSz
|
The maximum frame size allowed on an APP channel between CSSs. The frame size is a number from 10240 to 65535. The default is 10240.
|
Pkts Tx
|
The number of packets sent during the session.
|
Pkts Rx
|
The number of packets received during the session.
|
Pkts Rej
|
The number of packets rejected during the session.
|
Last UP event
|
The day and time of the most recent UP event.
|
Last DOWN event
|
The day and time of the most recent DOWN event.
|
FSM Events
|
Finite State Machine events as related to the state field.
|
STOP
|
The number of APP_SESSION_STOP events. This field will always be at 0.
|
INIT
|
The number of APP_SESSION_INIT events.
|
OPEN
|
The number of APP_SESSION_OPEN events.
|
AUTH
|
The number of APP_SESSION_AUTH events.
|
UP
|
The number of APP_SESSION_UP events.
|
DOWN
|
The number of APP_SESSION_DOWN events.
|
Attached Apl
|
The application identifier.
|
For example:
(config)# show app session 192.168.10.10 verbose
To display a list of IP addresses, enter show app ? or show app session verbose ?.
Configuring a CSS as an Authoritative DNS Server
Use the dns-server command and its options to enable DNS server functionality on a CSS. The syntax and options for this global configuration mode command are:
•
dns-server - Enable the DNS server function on the CSS
•
dns-server bufferCount - Modify the DNS response buffer count
•
dns-server respTasks - Modify the DNS responder task count
To enable DNS server functionality on the CSS, enter:
To disable DNS server functionality on the CSS, enter:
Configuring DNS-Server BufferCount
To change the DNS response buffer count on the CSS, use the dns-server bufferCount command. Enter the number of buffers allocated for query response from 2 to 1000. The default is 50.
Use this command to tune the CSS only if the CSS experiences buffer depletion during normal operation. If the number of NS Buffers drops below 2, use the dns-server bufferCount to increase the buffer count.
For example:
(config)# dns-server bufferCount 100
To set the DNS response buffer count to its default value of 50, enter:
(config)# no dns-server bufferCount
To display the minimum available name server buffers (NS Buffers), use the show dns-server command.
Configuring DNS-Server RespTasks
To change the DNS responder task count, use the dns-server respTasks command. Enter the number of tasks to handle DNS responses as an integer from 1 to 250. The default is 2.
For example:
(config)# dns-server respTasks 3
To set the DNS responder task count to its default value of 2, enter:
(config)# no dns-server respTasks
Configuring a DNS Server Forwarder
Use the dns-server forwarder command to configure a DNS server forwarder on a CSS. If the CSS cannot resolve a DNS request, it sends the request to another DNS server to obtain a suitable response. This server, called a DNS server forwarder, can be a fully functional Berkeley Internet Name Domain (BIND) DNS server or a CSS configured for DNS. The CSS sends to the forwarder DNS requests that:
•
Are unresolvable by the CSS
•
Contain an unsupported request or record type
Note
For Client Side Accelerator configurations, the forwarder must be a BIND DNS server. For details on CSA, refer to "Configuring Client Side Accelerator" later in this chapter.
The forwarder resolves the DNS requests and sends DNS responses to the client transparently through the CSS. To monitor forwarder health, a keepalive mechanism (internal to the CSS) sends queries periodically to the forwarder to validate its state.
The syntax for this global configuration mode command is:
dns-server forwarder [primary ip_address|secondary ip_address|zero]
The variables and options are:
•
primary - Specifies a CSS as the first choice forwarder. The CSS sends unresolvable requests to the primary forwarder unless it is unavailable, in which case, it uses the secondary forwarder. When the primary forwarder is available again, the CSS resumes sending requests to the primary forwarder.
•
secondary - Specifies a CSS as the second choice forwarder.
•
ip_address - Specifies the IP address of the forwarder. Enter the address in dotted-decimal notation (for example, 192.168.11.1).
•
zero - Resets the statistics of both forwarders on a CSS.
For example:
(config)# dns-server forwarder primary 192.168.11.1 secondary
192.168.11.2
To delete the primary forwarder on a CSS, enter:
(config)# no dns-server forwarder primary
Show DNS Server Information
To display DNS server configuration and database information, use the show dns-server command. The command provides the following options:
•
show dns-server - Display DNS server configuration information
•
show dns-server dbase - Display the DNS database information
•
show dns-server stats - Display the DNS database statistics
Table 7-3 describes the fields in the show dns-server output.
Table 7-3 Field Descriptions for the show dns-server Command
Field
|
Description
|
DNS Server Configuration
|
The enable or disable state of the DNS server function on the CSS. When enabled, the CSS acts as the authoritative name server for the content domain.
|
ACL Index
|
The ACL index number applied to the DNS server. If this field is 0, no ACL has been applied.
|
Responder Task Count
|
The configured DNS server responder task count. These tasks handle responses to incoming DNS query requests. The default is 2. The range is from 1 to 250.
|
Name Server Buffers
|
Total Count
|
The configured DNS server buffer count. The responder tasks share the buffers to handle incoming queries. The default is 50.
|
Current Free Count
|
The number of buffers available (not queried).
|
Minimum Free Count
|
The smallest number of buffers that will be available.
|
Reclaimed Count
|
The number of buffers forcibly reclaimed by the DNS server software.
|
Requests Accepted
|
The number of DNS queries accepted.
|
Responses Sent
|
The number of DNS responses sent.
|
No Error
|
The number of queries that the DNS server successfully answered.
|
Format Error
|
The number of queries received that had a packet format error.
|
Server Failure
|
The number of times that a referenced name server did not reply to a query.
|
Name Error
|
The number of queries received that the DNS server was not able to answer.
|
Not Implemented
|
The number of queries received requesting an operation that has not been implemented in the DNS server.
|
Operation Refused
|
The number of queries the DNS server received that it refused to answer.
|
Internal Resolver
|
Requests Sent
|
The number of queries sent to another name server for resolution.
|
Responses Accepted
|
The number of replies received from another name server.
|
Proximity Lookups
|
Requests Sent
|
The number of proximity lookups sent to the PDB.
|
Responses Accepted
|
The number of proximity lookups received from the PDB.
|

Note
Proximity lookup information is displayed only when you configure a Proximity Database (PDB) IP address. For information on configuring a PDB, refer to Chapter 10, Configuring Network Proximity, in the section "Configuring the Proximity Database".
The database contains DNS names that are configured locally or learned from peers and Time to Live (TTL) information for each DNS name.
For example:
(config)# show dns-server dbase
Table 7-4 describes the fields in the show dns-server dbase output.
Table 7-4 Field Descriptions for the show dns-server dbase Command
Field
|
Description
|
DN
|
The domain name of the entry.
|
DNSCB
|
The address of the DNS control block structure to return a DNS query response for the entry. This address is the location best suited to handle the request.
|
PROX
|
The address for the proximity record.
|
Note
When DNSCB and PROX have null values (0x0), this indicates a host table mapping.
To display the DNS database statistics, enter:
Table 7-5 describes the fields in the show dns-server stats output.
Table 7-5 Field Descriptions for the show dns-server stats Command
Field
|
Description
|
DNS Name
|
The domain name entry
|
Content Name
|
Where the domain entry is mapped (A-record, NS-record, or host table), or a content rule name
|
Location
|
The IP address associated with the entry
|
Resolve Local
|
The number of local resolutions performed for the entry
|
Remote
|
The number of remote resolutions performed for the entry
|
Displaying DNS Server Forwarder Statistics
Use the show dns-server forwarder command to display statistics on the CSS for the DNS server forwarders. The syntax for this global configuration mode command is:
show dns-server forwarder
Table 7-6 describes the fields in the show dns-server forwarder output.
Table 7-6 Field Descriptions for the show dns-server forwarder Command
Field
|
Description
|
DNS Server Forwarder Primary
|
The state of the primary forwarder. The states are:
• Not Configured
• Up
• Down
|
DNS Server Forwarder Secondary
|
The state of the secondary forwarder. The states are:
• Not Configured
• Up
• Down
|
State Changes
|
The number of times that the forwarder's state changed.
|
Requests Sent
|
The total number of requests sent to a particular forwarder.
|
Responses Accepted
|
The total number of responses received from a particular forwarder.
|
Totals:
|
Request Sent
|
The total number of requests sent to forwarders (primary and secondary).
|
Responses Accepted
|
The total number of responses received from forwarders (primary and secondary).
|
Configuring CSS DNS Peering
Use the dns-peer command and its options to enable DNS peer functionality on a CSS. The syntax and options for this global configuration mode command are:
•
dns-peer interval - Set the time between the load reports to the CSS DNS peers
•
dns-peer receive-slots - Set the maximum number of DNS names that the CSS can receive from each CSS DNS peer
•
dns-peer send-slots - Set the maximum number of DNS names that the CSS can send to each CSS DNS peer
Configuring DNS Peer-Interval
To set the time between generating load reports to the CSS DNS peers, use the dns-peer interval command. Enter the peer interval time from 5 to 120 seconds. The default is 5.
For example:
(config)# dns-peer interval 60
To reset the DNS peer interval to its default value of 5 seconds, enter:
(config)# no dns-peer interval
Configuring DNS Peer-Receive-Slots
To set the maximum number of DNS names that the CSS can receive from each CSS DNS peer, use the dns-peer receive-slots command. Enter a number from 128 to 1024. The default is 128. Use this command to tune a heavily-accessed CSS that is resolving more than 128 DNS names.
For example:
(config)# dns-peer receive-slots 200
To reset the DNS peer receive slots number to its default of 128, enter:
(config)# no dns-peer receive-slots
Configuring DNS Peer-Send-Slots
To set the maximum number of DNS names that the CSS can send to each CSS DNS peer, use the dns-peer send-slots command. Enter a number from 128 to 1024. The default is 128. Use this command to tune a CSS that is reporting over
128 DNS names to the peer.
For example:
(config)# dns-peer send-slots 200
To reset the DNS peer send slots number to its default of 128, enter:
(config)# no dns-peer send-slots
Show DNS Peer Information
To display the DNS peering configuration, use the show dns-peer command.
For example:
Table 7-7 describes the fields in the show dns-peer output.
Table 7-7 Field Descriptions for the show dns-peer Command
Field
|
Description
|
CSD Peer Rcv Slots
|
The configured maximum number of DNS names that the CSS can receive from each CSS DNS peer over an APP connection. The default is 128. The range is from 128 to 1024.
|
CSD Peer Snd Slots
|
The configured maximum DNS names that the CSS can send to each CSS DNS peer. The default is 128. The range is from 128 to 1024.
|
Peer Report Interval
|
The configured time in seconds between sending load reports to CSS DNS peers over an APP connection. The default is 5. The range is from 5 to 120.
|
Configuring Owner DNS
To set the DNS exchange policy for an owner, use the dns command. The syntax and options for this owner mode command are:
•
no dns - Set no DNS exchange policy for this owner (default). This owner is hidden from the CSS peer.
•
dns accept - Accept all content rules for this owner proposed by the CSS peer.
•
dns push - Advertise the owner and push all its content rules to the CSS peer.
•
dns both - Advertise the owner and push all its content rules to the CSS peer, and accept all this owner's content rules proposed by the CSS peer.
For example:
(config-owner-content[arrowpoint.com])# dns both
Adding DNS Service to Owner-Content
To specify a DNS name that maps to a content rule, use the add dns command. Enter the DNS name as a case-sensitive unquoted text string with no spaces and a length of 1 to 31 characters.
When you add the DNS name to the content rule, you may also enter an optional Time to Live (TTL) value in seconds. This value specifies how long the DNS client remembers the IP address response to the query. Enter a value from 0 to 255. The default is 0.
Note
You must configure the TTL when you add the DNS name to the content rule. To add a TTL to an existing rule, use the remove dns command to remove the dns name. Then use the add dns command to reconfigure the DNS name with a TTL value.
For example:
(config-owner-content[arrowpoint.com-rule1])# add dns
www.arrowpoint.com 36
Use the (config) dns-server command to configure the DNS server functionality on a CSS.
Removing DNS from Owner-Content
To remove a DNS name from a content rule, use the remove dns command with the DNS name you wish to remove. Enter the DNS name as a case-sensitive unquoted text string with no spaces and a maximum of 32 characters.
For example:
(config-owner-content[arrowpoint.com-rule1])# remove dns
www.arrowpoint.com
To display a list of DNS names, enter:
(config-owner-content[arrowpoint.com-rule1])# remove dns ?
Configuring Source Groups to Allow Servers to Internet-Resolve Domain Names
The CSS provides support to enable servers to resolve domain names using the Internet. If you are using private IP addresses for your servers and wish to have the servers resolve domain names using domain name servers that are located on the Internet, you must configure a content rule and source group. The content rule and source group are required to specify a public Internet-routable IP address (Virtual IP address) for the servers to allow them to resolve domain names.
To configure a server to resolve domain names:
1.
Configure the server, if you have not already done so.
The following example creates Server1 and configures it with a private IP address 10.0.3.251 and activates it.
(config)# service Server1
(config-service[Server1])# ip address 10.0.3.251
(config-service[Server1])# active
2.
Create a content rule to process DNS replies. This content rule is in addition to the content rules you created to process Web traffic. The content rule enables the CSS to perform Network Address Translation to translate inbound DNS replies from the public VIP address (192.200.200.200) to the server's private IP address (10.0.3.251).
The following example creates content rule dns1 with a public Virtual IP address (VIP) 192.200.200.200 and adds server Server1.
(config-owner[arrowpoint.com])# content dns1
(config-owner-content[arrowpoint.com-dns1])# vip address
192.200.200.200
(config-owner-content[arrowpoint.com-dns1])# add service Server1
(config-owner-content[arrowpoint.com-dns1])# active
3.
Create a source group to process DNS requests. The source group enables the CSS to perform Network Address Translation to translate outbound traffic source IP addresses from the server's private IP address (10.0.3.251) to the public VIP address (192.200.200.200).
To prevent server source port collisions, the CSS performs Network Address Translation on the server's source IP address and port by translating the:
•
Source IP address to the IP address defined in the source group.
•
Port to the port selected by the source group. The source group assigns each server a unique port for a DNS query so that the CSS can match the DNS reply with the assigned port. This port mapping enables the CSS to direct the DNS reply to the correct server.
The following example creates source group dns1 with public VIP address 192.200.200.200 and adds server Server1.
(config)# group dns1
(config-group[dns1])# vip address 192.200.200.200
(config-group[dns1])# add service Server1
(config-group[dns1])# active
Showing Domain Summary Information
To display content domain summary information, use the show domain command. The syntax and options are listed below. For options that require an IP address, specify the IP address for the peer.
•
show domain - Display content domain summary information including the number of domain peers and information about each peer.
•
show domain ip_address send|receive - Display content domain summary information including the number of domain peers and information for the specified peer IP address. To see a list of addresses, enter show domain ?.
–
Include the send option to display only the send load reports and transmit message statistics.
–
Include the receive option to display only the receive load reports and receive message statistics.
•
show domain hotlist - Display configuration information about domain hotlists.
•
show domain owners - Display shared owner names.
•
show domain owners ip_address - Display shared owner names for the specified peer IP address.
•
show domain rules - Display locally created or negotiated names.
•
show domain rules ip_address - Display locally created or negotiated names for the specified peer IP address.
Table 7-8 describes the fields in the show domain output.
Table 7-8 Field Descriptions for the show domain Command
Field
|
Description
|
Content Domain Summary
|
The number of domain peers.
|
Peer
|
The address for the peer.
|
CCC State
|
The state of the master FSM (finite state machine) that negotiates the CAPP (CCC) link.
|
OWN State
|
The state of the owner policy negotiation FSM that determines the owners about whom the peers will share domain name and rule information.
|
Rule State
|
The state of the rule policy negotiation FSM that exchanges individual domain name and rule matching criteria and load report information.
|
SendSlots
|
The number of individual domain name rules on which the CSS will send load reports to the peer.
|
ReceiveSlots
|
The number of individual domain name rules on which the CSS will receive load reports from the peer.
|
Interval
|
The time interval in seconds that load reports are sent to the peer.
|
MinRespTime
|
The minimum local flow response time. This number is shared with the peer to be used in conjunction with load numbers to normalize the load numbers shared between peers.
|
MaxRespTime
|
The maximum local flow response time. This number is shared with the peer to be used in conjunction with load numbers to normalize the load numbers shared between peers.
|
Policy
|
The negotiated load report send and receive policies.
|
Sending Load Reports for
|
The list of domain names for which the CSS is sending load reports to the peer.
|
Receiving Load Reports for
|
The list of domain names for which the CSS is receiving load reports from the peer.
|
CCC Msg stats
|
The number of times each of the message types used in the CCC/OWN/Rule FSM negotiations with the peer has been sent or received.
|
Configuring Client Side Accelerator
Overview
To accelerate the retrieval of domain content, configure a CSS as a Client Side Accelerator (CSA), using transparent caches (TCs) to store content locally. This feature improves a user's experience by reducing the time for content to arrive in a browser.
A CSA resides on the client side of the Internet and is the first DNS server to which clients send a DNS request. When a CSA receives a DNS request for content located in a domain configured for acceleration and the number of requests exceeds the configured threshold, the CSA returns an address record (A-record) of the local virtual IP address (VIP) to the client. The client uses the IP address in the A-record to connect to the service in a local TC farm.
For non-accelerated content or unresolvable DNS requests, the CSA sends the DNS request to a DNS server forwarder. The forwarder, which is not a CSS, is a fully-functional Berkeley Internet Name Domain (BIND) DNS server. The forwarder returns a DNS response to the client transparently through the CSA.
You can configure a peer mesh of multiple CSAs that belong to one service provider but are located at various points of presence (POPs). Using Application Peering Protocol (APP), the CSAs in a peer mesh share accelerated domain records. This allows you to leverage content available at a cache farm in one POP to provide content to clients located at another POP. Once the same candidate domain has been accelerated at two POPs, cache backup can occur if a cache at one of those POPs fails.
Service providers can use CSAs to bill-back domain acceleration to content providers. You can configure certain domains for acceleration, then bill-back content providers based on the number of hits on the accelerated domains.
Note
The CSA feature is part of the CSS Enhanced feature set.
Example CSA Configurations
This section describes two possible CSA configurations: the first, a single POP () and the second, two POPs using an APP peer mesh ().
Single POP CSA Configuration
The following narrative describes the steps depicted in :
1.
The Client population sends DNS requests to the CSA for DNS resolution of the domain name www.acme.com.
2.
The CSA is configured to accelerate the domain www.acme.com.
3.
When the number of requests for www.acme.com exceed the configured threshold (or the threshold has already been exceeded), the CSA returns the accelerated VIP in an A-record to the clients.
4.
For all other requests, the CSS forwards the queries to the DNS server forwarder for resolution.
5.
Clients initiate a connection with the CSA for www.acme.com using the VIP in the A-record.
6.
The CSA matches the request on a layer 5 content rule that has transparent caches configured as the services. The CSA performs destination NATing based on the host tag and performs MAC forwarding.
7.
If the cache contains the content, the CSA returns it to the clients.
8.
If the cache does not contain the content, the cache fetches the content from the origin server.
Figure 7-2 Example of a Client Side Accelerator Configuration Example
Multiple POP CSA Configuration
The following narrative describes the steps depicted in .
1.
An APP mesh is configured for the CSAs in POP1 and POP2.
2.
CSA1 in POP1 is configured to accelerate the domains abc.com and cbs.com.
3.
CSA2 in POP2 is configured to accelerate the domain abc.com.
4.
Client A population sends DNS requests to CSA1 in POP1 for abc.com.
5.
When the number of requests for abc.com exceeds the configured threshold, CSA1 creates an A-record for abc.com and returns it to the clients. Clients in POP1 initiate a connection with CSA1 using the VIP in the A-record.
6.
CSA1 also sends the A-record for abc.com out on the APP mesh.
7.
Client B population sends DNS requests for abc.com to CSA2 in POP2. If CSA2 is configured to accelerate abc.com in multiple locations and if the domain becomes hot (requests exceed configured threshold), repeat steps 5 and 6 for CSA2 in POP2.
8.
If abc.com is not yet hot in POP2 or if CSA2 is configured to accelerate the domain in a single location, CSA2 sends the A-record in its domain database (learned in step 6) to the Client B population.
9.
The clients in POP2 request content in abc.com from CSA1 in POP1.
Figure 7-3 Example of a Client Side Accelerator APP Mesh Configuration
Client Side Accelerator Quick Start
Table 7-9 provides a quick overview of the steps required to configure the Client Side Accelerator feature on a CSS. Each step includes the CLI command required to complete the task. For a complete description of each feature and all the options associated with the CLI command, refer to the following sections.
Table 7-9 Client Side Accelerator Configuration Quick Start
Task and Command Example
|
1. Enter config mode.
|
2. Enable Application Peering Protocol (APP).
|
3. Configure an APP session with each remote CSA peer to create a peer mesh. Refer to "Configuring an APP Session" earlier in this chapter.
(config)# app session 192.160.1.2
|
4. Configure back-end remapping as the preferred connection reset method. Refer to the Content Services Switch Basic Configuration Guide, Chapter 7, Configuring Content Rules. This step is recommended, but not required.
(config)# persistence reset remap
(config)# bypass persistence disable
|
5. Configure candidate domains for acceleration. Refer to "Configuring Accelerated Domains" later in this chapter.
(config)# dns-record accel abc.com 192.168.1.1
(config)# dns-record accel cbs.com 192.168.1.1
|
6. Configure CSA and enable sharing of content between peer CSAs. Refer to "Enabling the Client Side Accelerator" later in this chapter.
(config)# dns-server accelerate domains 50 30 256 single_location
|
7. Configure the DNS server and the number of CSA peers. Refer to Chapter 10, "Enabling the Proximity Domain Name Server".
(config)# dns-server zone 1 tier2
|
8. Configure the DNS server forwarder. Refer to "Configuring a DNS Server Forwarder" earlier in this chapter.
(config)# dns-server forwarder primary 192.168.1.10
|
9. Enable the DNS server.
|
10. Configure the transparent caches as services. Refer to Chapter 6, Configuring Caching, in the section "Using Transparent Caching" and in the section "Configuring Network Address Translation for Transparent Caches".
(config)# service transHosttag1
(config-service[transHosttag])# ip address 10.1.2.1
(config-service[transHosttag])# protocol tcp
(config-service[transHosttag])# port 80
(config-service[transHosttag])# type transparent
(config-service[transHosttag])# transparent-hosttag
(config-service[transHosttag])# active
Repeat for each additional cache.
|
11. Configure a content rule with the same VIP address as that used for the accelerated records. Add the transparent caches as services. Refer to the Content Services Switch Basic Configuration Guide, Chapter 7, Configuring Content Rules.
(config)# owner accelerate
(config-owner[accelerate])# content l5-accel
(config-owner-content[accelerate-15-accel])# VIP address
192.168.1.1
(config-owner-content[accelerate-15-accel])# protocol TCP
(config-owner-content[accelerate-15-accel])# port 80
(config-owner-content[accelerate-15-accel])# url "/*" eql
cacheable
(config-owner-content[accelerate-15-accel])# add service
transHosttag1
(config-owner-content[accelerate-15-accel])# add service
transHosttagn
(config-owner-content[accelerate-15-accel])# no persistent
(config-owner-content[accelerate-15-accel])# balance url
(config-owner-content[accelerate-15-accel])# active
|
12. Configure a service to bypass the cache farm for non-cacheable content. Refer to the Content Services Switch Basic Configuration Guide, Chapter 5, Configuring Services and Chapter 6, Configuring Caching, in the section "Enabling Content Requests to Bypass Caches", in this guide.
(config)# service bypassCache
(config-service[bypassCache])# ip address 0.0.0.0
(config-service[bypassCache])# protocol tcp
(config-service[bypassCache])# port 80
(config-service[bypassCache])# keepalive type none
(config-service[bypassCache])# bypass-hosttag
(config-service[bypassCache])# active
|
13. Configure a content rule for non-cacheable content on domains that you want to accelerate. Add the bypass cache as the only service. Refer to the Content Services Switch Basic Configuration Guide, Chapter 7, Configuring Content Rules.
(config)# owner accelerate
(config-owner[accelerate])# content nonCacheable
(config-owner-content[accelerate-nonCacheable])# VIP address
192.168.1.1
(config-owner-content[accelerate-nonCacheable])# protocol TCP
(config-owner-content[accelerate-nonCacheable])# port 80
(config-owner-content[accelerate-nonCacheable])# url "/*"
(config-owner-content[accelerate-nonCacheable])# add service
bypassCache
(config-owner-content[accelerate-nonCacheable])# no persistent
(config-owner-content[accelerate-nonCacheable])# active
|
Enabling the Client Side Accelerator
Use the dns-server accelerate domains command to enable the CSA functionality on a CSS. This command enables the acceleration of domains that have been or will be configured for acceleration using the dns-record accel command. The CSA uses the threshold variable to determine if it should accelerate a candidate domain. You can also configure whether or not the CSA shares content with peer CSAs.
The syntax for this global configuration mode command is:
dns-server accelerate domains threshold interval max_number
[single_location|multi_location]
The variables and options for this command are:
•
threshold - The number of hits per interval below which the CSA does not accelerate a domain. When the number of hits equals or exceeds the threshold during the configured interval, the CSA accelerates the domain. Enter an integer from 0 to 65535. The default is 0, indicating immediate acceleration.
•
interval - The time period in minutes over which the CSA samples the hits on a domain and compares the number of hits with the configured threshold value to determine hot content and domain acceleration. Enter an integer from 1 to 60 minutes. The default is 5 minutes.
•
max_number - The maximum number of domains that the CSA can accelerate. Enter an integer from 0 to 4096. The default is 1024.
•
single_location - Allows the acceleration of a domain at one cache farm (POP) at a time. This is the default behavior.
•
multi_location - Allows multiple CSAs to accelerate the same domain, possibly resulting in multiple cache farms maintaining the same content. This can occur when two or more CSAs (located in different POPs) are configured for multi_location and accelerate the same domain. Each cache farm will maintain the same content after:
–
The CSAs accelerate the same domain
–
A cache in each POP retrieves the same content from the origin server
The following command example:
•
Accelerates domains that are accessed at least at the rate of 50 hits per minute.
•
Accelerates a maximum of 100 candidate domains at any given time.
•
Forces this CSA to allow acceleration of a given domain to occur in only one cache farm at a time.
(config)# dns-server accelerate domains 50 1 100 single_location
To disable CSA functionality on a CSS, enter:
(config)# no dns-server accelerate domains
Configuring the Domain Cache
Use the dns-server domain-cache command to enable the tracking of DNS request counts and to configure the domain cache on the CSA. As requests arrive at the CSA, entries are created or updated in the domain cache with the hit counts. You can use this command with the show dns-server domain-cache command to determine which domains you want to accelerate.
Note
Do not use this command during normal CSA operation. It causes unnecessary overhead on the CSA.
The syntax for this global configuration command is:
dns-server domain-cache {cache_size ageout|purge {dns_name}|zero
{dns_name}}
The variables and options for this command are:
•
cache_size - Specifies the number of domains that the CSA can cache. Enter an integer from 1 to 4096. The default is 1024.
•
ageout - The maximum number of seconds that the domain entry remains in cache. Enter an integer from 0 to 60. The default is 10 seconds. A value of zero causes the domain entry to never age out.
•
purge - Removes all entries or the specified entries in the domain cache.
•
dns_name - The DNS entry in the domain cache.
To see a list of entries, enter:
(config)# dns-server domain-cache [purge|zero] ?
•
zero - Resets all counters for all entries or the specified entry in the domain cache to zero.
For example:
(config)# dns-server domain-cache 512
The above command creates a domain cache that can hold up to 512 most recently requested domain entries. The entries will age out and be removed from the domain cache after 10 seconds (the default).
Note
The operation of the domain cache can impact the DNS request/response rate performance. Use the domain cache only when you need to identify potential acceleration candidates.
Configuring a DNS Server Forwarder
Use the dns-server forwarder command to configure a DNS server forwarder on a CSS configured as a CSA. If the CSA cannot resolve a DNS request, it sends the request to the DNS server forwarder to obtain a suitable response. For details, refer to "Configuring a DNS Server Forwarder" earlier in this chapter.
Configuring Accelerated Domains
Use the dns-record accel command to specify the domains you want to accelerate. Map the domain name to a content rule using an IP address.
Note
If the content rule bound to the acceleration candidate domain is suspended or cannot provide service for content requests, the CSA does not accelerate the domain.
The syntax for this global configuration mode command is:
dns-record accel dns_name ip_address {ageout}
Note
You cannot configure a domain name as two different DNS record types on the same CSS. For example, if you have configured abc.com as dns-record accel, you cannot configure it as
dns-record a or dns-record ns on the same CSS. For information on the other types of DNS records, refer to Chapter 10, Configuring Network Proximity, in the section "Configuring Domain Records".
The variables and options for this command are:
•
dns_name - The domain name that you want to map to the acceleration record. Enter the name as a case-sensitive unquoted text string with no spaces and a maximum of 63 characters.
•
ip_address - The IP address of the local content rule that will handle content requests for the DNS name during content acceleration.
•
ageout - The optional number of minutes that the domain remains accelerated. Enter an integer from 0 to 525600. The default is 180 minutes. If you enter 0, the accelerated domain record never ages out.
The following command example creates an acceleration record for the domain abc.com. When the number of requests for the domain exceeds the threshold specified in the dns-server accelerate domains command, the CSA accelerates the domain for six minutes. Clients can access the domain's content based on the content rule with the IP address 192.168.11.1.
(config)# dns-record accel abc.com 192.168.11.1 6
To delete a domain acceleration record, enter:
(config)# no dns-record accel dns_name
Resetting the DNS Record Statistics
Use the dns-record zero command to reset the DNS record statistics displayed by the show dns-record command. The syntax for this global configuration mode command is:
dns-record zero [a/ns {dns_name}|accel {dns_name}]
The options and variables for this command are:
•
a/ns - Resets the statistics to zero for the domain records that are displayed by the show dns-record statistics command and the show dns-record proximity command.
•
dns_name - Resets the statistics for the specified domain name mapped to the DNS record. To view a list of domain names, enter:
dns-record zero [a/ns|accel] ?
•
accel - Resets the counters to zero for the accelerated records that are displayed by the show dns-record accel command.
Configuring the CSA DNS Server Zones
Use the dns-server zone command to configure the number of DNS server zones on a CSA. The syntax for this global configuration command is:
dns-server zone zoneIndex {tier1|tier2 {"description"
{roundrobin|preferlocal}}
The options and variables for this command are:
•
zoneIndex - The unique numerical identifier of the CSA zone. Enter an integer from 0 to 6 for tier1 or 0 to 15 for tier2. There is no default.
Note
The zoneIndex value must be a unique zone number on the network.
•
tier1|tier2 - The optional maximum number of zones (peers) the CSA expects to participate in its peer mesh. Enter tier1 for a maximum of 6 zones. Enter tier2 for a maximum of 16 zones. The default is tier1.
Note
The tier you select must be the same as the tier for the other CSAs participating in the mesh.
•
description - The optional text description of the CSA zone. Enter a quoted text string with a maximum of 20 characters.
•
roundrobin|preferlocal - The optional load-balancing method that the DNS server uses to select returned records when a Proximity Database is not configured or is unavailable.
–
roundrobin - The server cycles among records available at the different zones. This is the default method.
–
preferlocal - The server returns a record from the local zone whenever possible, using roundrobin when it is not possible.
Displaying Client Side Accelerator Information
Use the show commands in this section to display information and statistics for your CSA configuration.
Displaying the Client Side Accelerator Configuration
Use the show dns-server accelerate domains command to display the CSA configuration on a CSS. The syntax for this global configuration mode command is:
show dns-server accelerate domains
Table 7-10 describes the fields in the show dns-server accelerate domains output.
Table 7-10 Field Descriptions for the show dns-server accelerate domains Command
Field
|
Description
|
Current CSA Config
|
The state of the CSA configuration: disabled or enabled.
|
Threshold
|
The configured hits threshold used to determine whether or not a domain is accelerated. When the hits on the domain are greater than or equal to the threshold, the CSA accelerates the domain. The range is from 0 to 65535. The default is 0, indicating that the candidate domains are always accelerated.
|
Interval
|
The configured time interval, in minutes, over which the CSS samples the hits on the domain and compares it with the threshold. The range is from 1 to 60 minutes. The default is 5 minutes.
|
Expirations
|
The number of times that the configured interval expired. You can use this value to determine whether domains are being accelerated or decelerated as expected. The CSA decelerates an accelerated domain only after the interval expires.
|
Max. to Accel
|
The maximum number of domains that can be accelerated. The range is 0 to 4096. The default is 1024.
|
Location
|
Indicates whether a single or multiple CSAs maintain the same content.
• Single-location, the default setting, allows the acceleration of a domain at one cache farm (POP) at a time.
• Multi-location allows multiple CSAs to accelerate the same domain resulting in multiple cache farms maintaining the same content.
|
Candidates Total
|
The total number of candidate domains that are configured on the CSA.
|
Candidates Accelerated
|
The total number of domains that are currently accelerated.
|
Displaying DNS Server Domain Cache Statistics
Us the show dns-server domain-cache command to display statistics for the DNS server domain cache. Use this command with the dns-server domain-cache command to help you determine which domains you want to accelerate. The syntax for this global configuration mode command is:
show dns-server domain-cache {summary}
Table 7-11 describes the fields in the show dns-server domain-cache output.
Table 7-11 Field Descriptions for the show dns-server domain-cache Command
Field
|
Description
|
Domain
|
The domain name of the entry
|
Counter
|
The number of DNS requests
|
Note
If you include the summary option, the command output displays the domain cache configuration and state only.
Displaying DNS Server Keepalive Information
Use the show dns-record keepalive command to display DNS record keepalive information. The syntax for this global configuration mode command is:
show dns-record keepalive (dns-name)
The variable for this command is dns-name, the domain name associated with the DNS record.
Table 7-12 describes the fields in the show dns-record keepalive output.
Table 7-12 Field Descriptions for the show dns-record keepalive Command
Field
|
Description
|
Name
|
The domain name for the record.
|
Type
|
The keepalive message type for the record, Accel, AP, ICMP, or none.
|
IP
|
The destination IP address of the keepalive message.
|
State
|
The state of the record, either UP or DOWN.
|
Transitions
|
The number of state transitions.
|
Load
|
The load for the record. This applies only to an AP record type. All other types always have a load of 2.
|
Threshold
|
The configured load threshold for the record. This threshold applies only to an AP record type. Record types of ICMP and none do not use the threshold value.
|
Displaying Domain Acceleration Records Statistics
Use the show dns-record accel command to view statistics associated with domain acceleration records. The syntax and options for this global configuration mode command are:
show dns-record accel dns-name
The variable for this command is dns_name, the domain name mapped to the acceleration record that you want to display. Enter the name as a case-sensitive unquoted text string with no spaces and a maximum of 63 characters.
Table 7-13 describes the fields in the show dns-record accel output.
Table 7-13 Field Descriptions for the show dns-record accel Command
Field
|
Description
|
<Name>
|
The domain name for the acceleration record.
|
State
|
The state of the acceleration record, either ACCEL or NOT ACCEL.
• ACCEL indicates that the record is currently accelerated
• NOT ACCEL indicates the record is currently not accelerated
|
Vip Address
|
The virtual IP address of the local content rule that handles the content requests for the domain name during content acceleration.
|
Secs til Ageout
|
The number of seconds remaining until the CSA decelerates the domain record. The range is from 0 to 525600. The default is 180 seconds.
|
Interval Hits
|
The number of content hits that occurred during the interval set with the dns-server domain-cache command.
|
Total Hits
|
The total number of DNS hits for this record.
|
AccelCount
|
The number of times that content was accelerated.
|
Configuring a CSS as a Content Routing Agent
Overview
To improve a client's overall browser experience by decreasing the response times for content requests, configure a CSS as a Content Routing Agent (CRA). A Cisco Content Router 4430-B (Content Router) redirects a client to the closest (best) replicated-content site represented by a CRA, based on network delay using a software process called boomerang. For details on the Cisco Content Router software and boomerang, refer to the Cisco Content Routing Software Configuration Guide and Command Reference, Release 1.1.
Configure a CRA at each content site within each domain that you want to support. This configuration also requires a Content Router.
The Content Router intercepts DNS requests from a client, then routes them to a CRA. For example, to route www.foo.com, the address record (A-record) in the primary DNS server for www.foo.com is changed to a name server record (NS-record) pointing to the Content Router. The Content Router and its CRAs handle all requests for the IP address of www.foo.com. When the CRAs receive a DNS request from the Content Router, the CRAs respond to the client's local name server at the same time. The first response through the network is used and the local name server discards all other responses. The CRA with the winning response is the site to which the client connects.
Figure 7-4 shows an example of the boomerang process in direct mode. A CSS configured as a CRA also works with a Content Router operating in WCCP mode. For more information on Content Router modes, refer to the Cisco Content Routing Software Configuration Guide and Command Reference, Release 1.1.
Figure 7-4 Example of Boomerang Content Routing Process - Direct Mode
Content Routing Agent Quick Start
Table 7-14 provides a quick overview of the steps required to configure the Content Routing Agent feature on a CSS. Each step includes the CLI command required to complete the task. For a complete description of each feature and all the options associated with the CLI command, refer to the following sections.
Table 7-14 Content Routing Agent Configuration Quick Start
Task and Command Example
|
1. Configure a Cisco Content Router 4430-B. Configure Content Routing Agents (CRAs) and the domains associated with them on the Content Router. For details, refer to the Cisco Content Routing Software Configuration Guide and Command Reference, Release 1.1.
|
2. On a CSS that you want to configure as a CRA, enter config mode.
|
3. Enable the CRA feature on a CSS.
(config)# dns-boomerang client enable
|
4. Create a domain record in the CRA for each domain with which you associated the CRA when you configured the Content Router.
(config)# dns-boomerang client domain www.sample.com 192.168.1.1
|
5. Optionally, configure an alias for each configured domain to reduce administrative overhead.
(config)# dns-boomerang client domain www.sample.com alias
gif.www.sample.com
|
6. Display CRA statistics.
(config)# show dns-boomerang client
|
Enabling the Content Routing Agent
Use the dns-boomerang client enable command to enable the CRA functionality on the CSS. There are no options for this global configuration mode command.
For example:
(config)# dns-boomerang client enable
To disable the CRA, enter:
(config)# no dns-boomerang client enable
Configuring the CPU Load Threshold
Use the dns-boomerang client cpu-threshold command to set the CSS CPU load threshold for domains configured to use or return a local virtual IP address (VIP). If the CPU load exceeds the configured threshold value, then the CSS drops subsequent incoming DNS requests from the Content Router until the load is lower than the threshold.
The syntax for this global configuration mode command is:
dns-boomerang client cpu-threshold threshold
The variable for this command is threshold. Enter an integer from 1 to 99. The default is 99.
For example:
(config)# dns-boomerang client cpu-threshold 50
To reset the CSS CPU threshold to the default value, enter:
(config)# no dns-boomerang client cpu-threshold
Note
To display the CPU load, use the show system-resources command.
Configuring Domain Records
Use the dns-boomerang client domain command to create a domain record in the Content Routing Agent DNS server for each of the domains you associated the agent with when you configured domains on the Content Router. If the matching domain record keepalive messaging succeeds, the CSS uses this record for DNS resolutions. There is no Content Routing Agent configuration mode. Unlike other dns-record commands on the CSS, this command requires keywords for specifying options.
The syntax for this global configuration mode command is:
dns-boomerang client domain dns_name ip_address {"uri" [key
"secret"|des-encrypted password]} {dns-ttl number} {ip-ttl number}
{threshold number}
The variables and options for this command are:
•
dns_name - The domain name mapped to the client record. Enter the name as a case-sensitive, unquoted text string with no spaces and a maximum length of 72 characters. For example, www.sample.com.
•
ip_address - The IP address or the host name of the content server or web cache bound to the domain name on the CSS. This IP address can be a local VIP. Enter the address in dotted-decimal notation (for example, 192.168.11.1).
•
uri - The URI used for the keepalive probe that the CRA sends to the content server for a domain. Enter the URI as a quoted text string and a maximum of 255 characters. The default is TCP handshake.
•
key - The optional keyword that defines the shared RC4 secret on the Content Router. Refer to Table 7-15 for a comparison of how you configure a password on a CSS (configured as a CRA) and on a Content Router.
•
secret - The optional clear-text Content Router secret for encrypting packets sent between a Content Router and a CRA. The secret you specify here must match the secret configured on the Content Router. Enter the secret as a case-sensitive quoted text string with no spaces and a maximum of 64 characters (not including the quotes). For example, if MySecret is the secret configured on the Content Router for this domain, then enter "MySecret".
•
des-encrypted - The optional keyword that specifies that a Data Encryption Standard (DES)-encrypted password follows.
•
password - The optional DES-encrypted password derived from the CR secret. If the CSS has already encrypted the CR password in the running-config, enter the encrypted password as an unquoted case-sensitive text string with no spaces and a maximum of 64 characters. If the CSS has not previously encrypted the CR password and you want to encrypt it, enter the password as a quoted case-sensitive text string with no spaces and a maximum of 16 characters (not including the quotes). The CSS encrypts the password in the running-config.
Table 7-15 Configuring a Password on a CSS (CRA) Versus a Content Router
CSS Password Commands
|
Content Router Password Commands
|
key "secret"
|
no equivalent
|
key des-encrypt "password"
|
key word or key 0 word
|
key des-encrypt password
|
key 7 word
|
Note
The DES encryption algorithm on the CSS is different from the Cisco Type 7 encryption algorithm on the Content Router. Therefore, encrypted passwords are displayed differently on the CSS and on the CR.
•
dns-ttl number - The optional DNS time-to-live keyword and value in seconds returned in the CRA's DNS responses. This option determines the length of time a DNS server caches the returned information for reuse. Enter an integer from 10 to 2147483647 seconds. The default is the dns-ttl value configured on the Content Router.
•
ip-ttl number - The optional IP routing time-to-live keyword and value in router hops returned in the CRA's DNS responses. This option determines how many router hops a response packet traverses enroute to the D-Proxy before it is discarded. This helps to eliminate the CRA from longer response routes. Enter an integer from 1 to 255. The default is the ip-ttl value configured on the Content Router.
•
threshold number - The optional load threshold for testing the keepalive state of a local VIP. If the load on the dns-record associated with the content rule is greater than the threshold value, then the CSS drops subsequent Content Router requests for that record until the load is lower than the threshold. Enter an integer from 2 to 254. The default value is 254.
Note
You must also configure the add dns command in the VIP's content rule. Refer to the Content Services Switch Basic Configuration Guide, Chapter 7, Configuring Content Rules, in the section "Adding a Domain Name System to a Content Rule".
For example:
(config)# dns-boomerang client domain www.foo.com 192.168.11.1 key
"MySecret" dns-ttl 240 ip-ttl 5 threshold 175
To remove a CRA domain, enter:
(config)# no dns-boomerang client domain www.foo.com
Configuring an Alias for an Existing Client Domain
Use the dns-boomerang client domain alias command to create an alias for an existing client domain. The alias behaves exactly the same as the configured domain name. This command reduces administrative overhead by allowing you to use the shorter alias name instead of the domain name, IP address, and all the other options and variables for the configured record. The syntax for this global configuration mode command is:
dns-boomerang client domain dns_name alias alias_name
The variables and options are:
•
dns_name - The domain name of a configured client record. Enter the name as a case-sensitive, unquoted text string with no spaces and a maximum of 72 characters. For example, www.sample.com.
•
alias - The keyword required to create an alias name.
•
alias_name - The domain name that the CSS treats exactly the same as the associated dns-name. Enter the name as a case-sensitive, unquoted text string with no spaces and a maximum of 72 characters. For example, gif.www.sample.com.
For example:
(config)# dns-boomerang client domain www.sample.com alias
gif.www.sample.com
To remove the alias, enter:
(config)# no dns-boomerang client domain alias www.sample.com
Clearing Domain Statistics
Use the dns-boomerang client zero command to clear the statistics for one or all configured domains. If you do not specify a domain name, the CSS clears the statistics for all configured domains. The syntax for this SuperUser and all-configuration-mode command is:
dns-boomerang client zero dns-name
The variable for this command is dns_name, the domain name mapped to the client record statistics that you want to clear. Enter the name as a case-sensitive, unquoted text string with no spaces and a maximum of 72 characters.
For example:
(config)# dns-boomerang client zero www.sample.com
Displaying Content Routing Agent Statistics
Use the show dns-boomerang client command to display information for all configured domains. The syntax for this SuperUser and all-configuration-mode command is:
show dns-boomerang client {all|global|domain {domain_name}}
The options and variable for this global configuration mode command are:
•
all - Displays all information (global and domain-related) for all domains mapped to a client record. Same as the show dns-boomerang client command.
•
global - Displays global information only for all domains mapped to a client record.
•
domain - Displays domain-related information for all domains mapped to a client record.
•
domain_name - Displays domain-related information for the specified domain.
For example:
(config)# show dns-boomerang client global
Table 7-16 describes the fields in the show dns-boomerang client output.
Table 7-16 Field Descriptions for the show dns-boomerang
client Command
Field
|
Description
|
Total DNS A-record requests
|
The total number of address record requests from the Content Server.
|
Total packets dropped
|
|
Unknown domain
|
The number of DNS packets with domains not configured on this CSS (for Content Routing).
|
Invalid source address
|
The number of packets with invalid source addresses.
|
Excess length
|
The number of packets that had lengths longer than what the CR could send.
|
CPU threshold exceeded
|
The number of packets dropped because the CPU threshold was exceeded.
|
Configured CPU threshold
|
The configured threshold value above which the CSS drops requests from the Content Router.
|
Rule load threshold exceeded
|
The number of requests from the Content Router that were dropped because the load on a local rule exceeded the configured threshold.
|
Keepalive state Down
|
The number of packets dropped because the keepalive failed.
|
Security failure
|
The number of requests for this domain that were dropped due to security errors (key/secret failure or mismatch).
|
Domain
|
The DNS name mapped to the client record.
|
Content server
|
The address of the content server bound to the domain.
|
Origin server
|
The address for the most recently used origin server that was passed from the Content Router.
|
Bad probes
|
The number of times (in percent) that the keepalive message failed to find the service Up.
|
DNS A-record requests
|
The number of DNS address record requests for this domain from the Content Router.
|
Dropped (server down)
|
The number of requests for this domain that were dropped because the server was down.
|
Dropped (CPU busy)
|
The number of requests for this domain that were dropped because the CPU threshold was exceeded.
|
Dropped (rule load exceeded)
|
The number of requests from the Content Router that were dropped because the load on a local rule exceeded the configured threshold.
|
Configured threshold
|
The load threshold value you configured with the dns-boomerang client domain command to test the keepalive state of a local VIP.
|
Security failures
|
The number of requests for this domain that were dropped due to security errors (key/secret failure or mismatch).
|
Alias
|
The alias that maps to the configured domain name.
|
DNS A-record requests
|
The number of DNS address record requests for this alias from the Content Router.
|