Table Of Contents
Configuring Content Rules
Service, Owner, and Content Rule Overview
Content Rule Configuration Quick Start
Naming and Assigning a Content Rule to an Owner
Configuring a Virtual IP Address
Configuring a Domain Name Content Rule
Disabling a Domain Name System in a Content Rule
Matching Content Rules on Multiple Domain Names
Configuring a Content Rule using a Domain Name and a Virtual IP Address
Using Wildcards in Domain Name Content Rules
General Guidelines for Domain Name Wildcards in Content Rules
Adding Services to a Content Rule
Adding a Service to a Content Rule
Specifying a Service Weight
Adding a Primary Sorry Server to a Content Rule
Adding a Secondary Sorry Server to a Content Rule
Adding a Domain Name System to a Content Rule
Activating a Content Rule
Suspending a Content Rule
Removing a Content Rule
Removing a Service from a Content Rule
Configuring a Protocol
Configuring Port Information
Configuring Load Balancing
Configuring a DNS Balance Type
Configuring Hotlists
Configuring a Domain Hotlist
Specifying a Uniform Resource Locator
Specifying an Extension Qualifier List in a Uniform Resource Locator
Specifying a Load Threshold
Redirecting Requests for Content
Configuring Persistence, Remapping, and Redirection
Content Rule Persistence
Configuring Bypass Persistence
Configuring HTTP Redirection and Service Remapping
Specifying an HTTP Redirect String
Using Show Remap
Defining Failover
Specifying an Application Type
Enabling Content Requests to Bypass Transparent Caches
Showing Content
Showing Content Rules
Configuring Content Rules
This chapter describes how to create and configure content rules. Services, which are added to content rules, are discussed in <Xref_Color>Chapter 5, Configuring Services. Configuring owners is discussed in Chapter 6, Configuring Owners. Information in this chapter applies to all CSS models except where noted.
This chapter contains the following sections:
•
Service, Owner, and Content Rule Overview
•Naming and Assigning a Content Rule to an Owner
•Configuring a Virtual IP Address
•Configuring a Domain Name Content Rule
•Adding Services to a Content Rule
•Activating a Content Rule
•Suspending a Content Rule
•Removing a Content Rule
•Removing a Service from a Content Rule
•Configuring a Protocol
•Configuring Port Information
•Configuring Load Balancing
•Configuring a DNS Balance Type
•Configuring Hotlists
•Specifying a Uniform Resource Locator
•Specifying a Load Threshold
•Redirecting Requests for Content
•Configuring Persistence, Remapping, and Redirection
•Defining Failover
•Specifying an Application Type
•Showing Content
•Showing Content Rules
Service, Owner, and Content Rule Overview
The CSS enables you to configure services, owners, and content rules to direct requests for content to a specific destination service (for example, a server or a port on a server). By configuring services, owners, and content rules, you optimize and control how the CSS handles each request for specific content.
•A service is a destination location where a piece of content physically resides
(a local or remote server and port). You add services to content rules. Adding a service to a content rule includes it in the resource pool that the CSS uses for load balancing requests for content. A service may belong to multiple content rules.
•An owner is generally the person or company who contracts the web hosting service to host their web content and allocate bandwidth as required.
•A content rule is a hierarchical rule set containing individual rules that describe which content (for example, .html files) is accessible by visitors to the web site, how the content is mirrored, on which server the content resides, and how the CSS should process requests for the content. Each rule set must have an owner.
When a request for content is made, the CSS:
1. Uses the owner content rule to translate the owner Virtual IP address (VIP) or domain name using Network Address Translation (NAT) to the corresponding service IP address and port.
2. Checks for available services that match the content request.
3. Uses content rules to choose which service can best process the request for content.
4. Applies all content rules to service the request for content (for example, load-balancing method, redirects, failover, stickiness).
The CSS uses content rules to determine:
•Where the content physically resides, whether local or remote.
•Where to direct the request for content (which service or services).
•Which load-balancing method to use.
The type of rule also implies the Layer at which the rule functions.
•A Layer 3 content rule implies a destination IP address of the host or network.
•A Layer 4 content rule implies a combination of destination IP address, protocol, and port.
•A Layer 5 content rule implies a combination of destination IP address, protocol, port, and URL that may or may not contain an HTTP cookie or a domain name.
Note A Layer 5 content rule supports the HTTP CONNECT, GET, HEAD, POST, PUSH, and PUT methods.
Content rules are hierarchical. If a request for content matches more than one rule, the characteristics of the most specific rule apply to the flow. The hierarchy is shown below. The CSS uses this order of precedence to process requests for the content, with 1 being the highest match and 9 being the lowest match.
1. Domain name, IP address, protocol, port, URL
2. Domain name, protocol, port, URL
3. IP address, protocol, port, URL
4. IP address, protocol, port
5. IP address, protocol
6. IP address
7. Protocol, port, URL
8. Protocol, port
9. Protocol
Note The CSS evaluates the content rule hierachary before it evaluates the Layer 5 rule URL, cookie strings, or HTTP header information.
illustrates the CSS service, owner, and content rule concepts.
Figure 7-1 Services, Owners, and Content Rules Concepts
.
Content Rule Configuration Quick Start
Table 7-1 provides a quick overview of the steps required to create and configure a Layer 3 content rule. Each step includes the CLI command required to complete the task. For a complete description of each feature and all the content rule configuration options, refer to the sections following Table 7-1.
Ensure that you have already created and configured a service and owner for the content rules. The command examples in Table 7-1 create a Layer 3 content rule for owner arrowpoint.
Table 7-1 Content Rule Configuration Quick Start
Task and Command Example
|
1. Enter into config mode by typing config.
|
2. Enter into the owner mode for which you wish to create content rules.
(config)# owner arrowpoint
|
3. Create the content rule for the owner.
(config-owner[arrowpoint])# content rule1
The CSS enters into the owner-content rule mode.
(config-owner-content[arrowpoint-rule1]#
|
4. Configure a Virtual IP address (VIP) or domain name for the owner content. This example configures a VIP.
(config-owner-content[arrowpoint-rule1]# vip address 192.168.3.6
This example configures a domain name.
(config-owner-content[arrowpoint-rule1]# url
"//www.arrowpoint.com/*"
|
5. Specify a load balancing type.
(config-owner-content[arrowpoint-rule1]# balance aca
|
6. Add previously configured services to the content rule.
(config-owner-content[arrowpoint-rule1]# add service serv1
(config-owner-content[arrowpoint-rule1]# add service serv2
|
7. Activate the content rule.
(config-owner-content[arrowpoint-rule1]# active
|
8. Display the content rules (optional).
(config-owner-content[arrowpoint-rule1]# show rule
|
Naming and Assigning a Content Rule to an Owner
To name a content rule and assign it to an owner, use the content command. By assigning content rules to an owner, you can manage access to the content. Assign content rules to an owner by creating the content rule in the mode for that owner. The CSS identifies content rules by the names you assign. Enter a content rule name from 1 to 31 characters.
The example below assigns:
•The name rule1 to the content rule
•Content rule rule1 to owner arrowpoint
(config-owner[arrowpoint])# content rule1
Once you assign a content rule to an owner, the CLI prompt changes to reflect the specific owner and content rule mode.
(config-owner-content[arrowpoint-rule1])#
Within owner and content mode, you can configure how the CSS will handle requests for the content. To remove an existing content rule from an owner, issue the no content command from owner mode:
(config-owner[arrowpoint])# no content rule1
Configuring a Virtual IP Address
Note The CSS supports stateless redundancy failover on CSSs operating in an IP redundancy or a VIP/interface redundancy configuration. Stateless redundancy failover requires a very specific redundant CSS configuration, which includes content rule VIP addresses. For details, refer to the Content Services Switch Advanced Configuration Guide, Chapter 5, Configuring Redundant Content Services Switches.
A Virtual IP address (VIP) is an address that an Internet Domain Name System (DNS) provides when asked to resolve a domain name. For example, www.arrowpoint.com may be translated to the VIP 192.217.4.15 by a DNS server. VIPs are generally assigned by Internet Service Providers (ISPs), who request them from the Internet Assigned Name Authority (IANA).
Assigning a VIP to owner content enables the CSS to translate (using Network Address Translation [NAT]) the VIP to the IP address of the service where the content resides.
Note The CSS allows you to configure a domain name instead of a VIP. See the next section for information on configuring a domain name. You may configure either a VIP, a domain name, or both in a content rule.
To enable the CSS to translate an owner's Internet IP address to the IP address of the service where the content resides, configure a VIP to the owner content. By translating a VIP to the service IP address, the CSS enhances network security because it prevents users from accessing your private network IP addresses.
Caution Ensure that all VIPs are unique IP addresses. Do not configure a VIP to the same address as an existing IP address on your network or a static ARP entry.
Note When you configure a rule without a VIP, the rule will match on any VIP that matches the other configured rule attributes (for example, port and protocol). If you have a configuration that requires this type of rule (called a wildcard VIP rule), be aware that the client request will match on this rule when the client request attempts to connect directly to a server IP address.
The variables and options for the vip address command include:
•ip_address or host - The IP address or name for the content rule. Enter the address in either dotted-decimal IP notation (for example, 192.168.11.1) or mnemonic host-name format (for example, myhost.mydomain.com).
•range number - The range option and variable allows you to specify a range of IP addresses starting with the VIP address. Enter a number from 1 to 65535. The default range is 1. The ip_or_host variable is the first address in the range. For example, if you enter a VIP of 172.16.3.6 with a range of 10, the VIP addresses will range from 172.16.3.6 to 172.16.3.15.
Note When you use an FTP content rule with a configured VIP address range, be sure to configure the corresponding source group with the same VIP address range (refer to the Content Services Switch Advanced Configuration Guide, Chapter 3, Configuring Source Groups, ACLs, EQLs, URQLs, NQLs, and DQLs).
To configure a Virtual IP address (VIP), issue the vip address command and specify either an IP address or a host name. For example:
(config-owner-content[arrowpoint-rule1])# vip address 192.168.3.6
To configure a Virtual IP address (VIP) with a range of 10, issue the vip address command with the range option. For example:
(config-owner-content[arrowpoint-rule1])# vip address 192.168.3.6
range 10
When using the vip address range command, use IP addresses that are within the subnet you are using. The CSS does not arp for IP addresses that are not on the circuit subnet. For example, if you configure the circuit for 10.10.10.1/24 and configure the VIP range as 10.10.10.2 range 400, the CSS will not arp for any IP addresses beyond 10.10.10.254. Using the same example with a VIP range of 200, the CSS will arp for all IP addresses in the range.
To remove a VIP from a content rule, enter:
(config-owner-content[arrowpoint-rule1])# no vip address
Note When you ping a VIP, the CSS only responds if there is at least one live service, live sorry server, or redirect string configured for the VIP. If the services or sorry servers are down and you have not defined a redirect string for the VIP, the CSS does not respond to the ping.
shows an example of configuring a VIP. In this example, a user requests content from arrowpoint. The content physically resides on the server with IP address 10.3.6.1. By configuring VIP 158.37.6.0 to the content, the CSS translates the VIP to the server IP address where the content actually resides without exposing internal IP addresses.
Figure 7-2 Example of Configuring a Virtual IP Address
Configuring a Domain Name Content Rule
The CSS allows you to use a domain name in place of, or in conjunction with, a VIP in a content rule. Using a domain name in a content rule enables you to:
•Enable service provisioning to be independent of IP-to-domain name mappings
•Provision cache bandwidth as needed based on domain names
Note Domain names in content rules are case-insensitive, regardless of the case command setting.
To configure a domain name in a content rule, use the url command and place two slash characters (//) at the front of the quoted url_name or url_path.
For example:
(config-owner-content[arrowpoint-rule1])# url
"//www.arrowpoint.com/*"
Use domain name rules rather than VIP rules when you have several transparent caches and you want certain domains to use the most powerful cache server. You want all other domains load balanced among the remaining cache servers. For this configuration, set up a domain name rule for the specific domains you want directed to the powerful cache server. Then configure a wildcard VIP rule (specify port 80 and no VIP) to balance all other HTTP traffic among the remaining caches.
You may use a single VIP in front of a server that is hosting many domain names. Over time, some of the domain names may receive more traffic and could benefit from having their content on a separate server. To segregate the traffic, configure the domain names you want directed to specific services. You do not need to configure additional VIPs for the domain names because the CSS will use the domain names as the matching criteria in the content rules.
Disabling a Domain Name System in a Content Rule
To disable DNS in a content rule, use the dns-disable-local command. The CSS informs other CSSs through APP that the services related to the content rule are not available for DNS activities. However, the services remain active for other functions.
For example to disable DNS for a specific content rule, enter:
(config-owner-content[arrowpoint-rule1])# dns-disable-local
To enable DNS in the content rule, use the no dns-disable-local command. For example:
(config-owner-content[arrowpoint-rule1])# no dns-disable-local
Matching Content Rules on Multiple Domain Names
When you have a requirement for a content rule to match on multiple domain names, you can associate a Domain Qualifier List (DQL) to the rule. A DQL is a list of domain names that you configure. You can use a DQL on a rule to specify that content requests for each domain in the list will match on the rule.
You can determine the order that the domain names are listed in the DQL. You can arrange the names in a DQL by assigning an index number as you add the name to the list.
DQLs exist independently of any range mapping. You can use them as matching criteria to balance across servers that do not have IP addresses or port ranges. If you want to use range mapping when using a service range, you need to consider the index of any domain name in the DQL. If you are not using service ranges with DQLs, you do not need to configure any index and the default index is 1.
For example, you could configure a DQL named Woodworker.
The domain names you could add as part of the DQL include www.wood.com, www.woodworker.com, www.maple.com, www.oak.com. You could configure www.wood.com and www.woodworker.com to have the same mapping index. You can enter indexes from 1 to 1000 and provide an optional quoted description for each index.
For example:
(config-dql[Woodworker]# domain www.wood.com index 1 "This is the
same as the woodworker domain"
(config-dql[Woodworker]# domain www.woodworker.com index 1
(config-dql[Woodworker]# domain www.maple.com index 2
(config-dql[Woodworker]# domain www.oak.com index 3
If you specify a DQL as a matching criteria for content rule WoodSites, and there are two services, S1 and S2, associated with the rule, the CSS checks the services at mapping time for ranges. To add a DQL to a content rule, use the url command as shown:
(config-owner-content[WoodSites])# url "/*" dql Woodworker
For example, if the CSS receives a request for www.oak.com along with other criteria, a match on the WoodSites rule occurs on DQL index 3. If the rule has the roundrobin load balancing method, the CSS examines a service (S2 for this example) to determine the backend connection mapping parameters. If you configured S2 with a VIP address of 10.0.0.1 with a range of 5, the addresses include 10.0.0.1 through 10.0.0.5. Because this service has a range of addresses and any as its port, the DQL index of 3 matches the service VIP range index of 3, which is address 10.0.0.3.
To delete a DQL, use the no dql command. For example:
(config)# no dql Woodworker
Note You cannot delete a DQL currently in use by a content rule.
For a complete description of DQLs, refer to the Content Services Switch Advanced Configuration Guide.
Configuring a Content Rule using a Domain Name and a Virtual IP Address
Use a domain name and a virtual IP address (VIP) in a content rule when you want the CSS to match content requests going to a specific domain at a specific VIP. If the CSS is serving more than one VIP at the domain name, configure two domain name content rules and specify the different VIPs.
This configuration is shown in the sample running-config below. Note that because the IP addresses in the example below are contiguous, you could use the vip address range command to specify a VIP range of 2.
If your network topology does not require that the CSS ARP-reply for VIPs, you do not need to configure separate content rules for the domain name and VIP. In this situation, a domain name content rule without a VIP is sufficient because it will match on all content requests going to the domain regardless of the VIP.
An example of a topology where ARP-replying is not required is when an upstream router has the CSS statically configured as the next hop router for the VIPs. A domain name content rule is shown below.
Using Wildcards in Domain Name Content Rules
You can use wildcards in domain names as part of the matching criteria for a content rule. Domain name wildcards work within the content rule hierarchy. That is, if a request for content matches more than one rule (including a wildcard domain name), the characteristics of the most specific rule determine how the CSS sets up the flow.
Note You cannot use wildcards with either a Domain Qualifier List (DQL) or a Uniform Resource Locator Qualifier List (URQL).
For example, the following content rule criteria have the highest precedence because, as a set, they provide the greatest specificity in matching content:
Domain name, IP address, protocol, port, URL
If you want to create a content rule using all these criteria, such as the configuration shown below, then the content rule matches only on the JPEG files that are found in the domain whose name starts with "arr", as well as the other criteria, including VIP address, protocol, and port number.
(config-owner-content[arrowpoint-rule1])# vip address 192.168.3.6
(config-owner-content[arrowpoint-rule1])# protocol tcp
(config-owner-content[arrowpoint-rule1])# port 80
(config-owner-content[arrowpoint-rule1])# url "//arr*.com/*.jpg"
When the CSS encounters a content rule with a wildcard domain name and matches according to the content rule hierarchy, it stops the search at that point. This behavior is consistent with the way that the CSS manages content rules in general.
For example, if the content request matches on the rule with VIP address 192.168.3.6 and URL /*, the CSS does not continue the search to match on a second rule with a wildcard VIP address (no address specified) and an URL of /*.jpg. The specific address match makes the first rule more specific than the second rule.
To further clarify, if the match occurs on a rule with //arrowpoint*.com/*, the search stops at that point and does not continue to match on a rule with //arr*.com/*.gif, because the first rule is a more specific match. Also note that a fully-specified domain name rule (arrowpoint.com) is more specific than a wildcard domain name rule (arr*.com).
For example, to have the content rule match on all instances of the text string "arr" in the domain name portion of the content rule, issue the following command:
(config-owner-content[arrowpoint-rule1])# url "//www.arr*.com/*"
General Guidelines for Domain Name Wildcards in Content Rules
A domain name is made up of text strings called "words" and word separators called "dots" (.). The CSS parses the domain name from right word to left word. The CSS allows wildcards to be used as part of the domain name in one word or more than one word, but the wildcard cannot start the word.
For example, the CSS supports the following domain names:
•www.arr*.com
•arr*.com
•*.arr*.com
•arr*.home.com
Notice that the wildcard character either appears by itself as a domain word, or appears to the right of any characters that start a domain word. However, a wildcard character cannot start a domain name word.
For example, point.com:
•*point.com
•*.*point.com
•*point.home.com
Note You cannot use wildcards on the rightmost portion (for example, .com, .org, .gov) of the domain name. For this reason, the wildcard domain name syntax f* is not supported. You can use wildcards in any other words that make up the domain name.
Adding Services to a Content Rule
To add an existing service to a content rule, use the add command. Adding a service to a content rule includes it in the resource pool that the CSS uses for load balancing requests for content. The maximum number of services that you can add into a single content rule is 64. Note that a service may belong to multiple content rules. To see a list of services you can add to a content rule, enter add service ?.
Note You can only add local services to a content rule that contains either a Domain Qualifier List (DQL) or a service port range.
The add service command enables you to add the following types of services to a content rule:
•Service
•Primary Sorry Server
•Secondary Sorry Server
When you configure a Layer 3 or 4 content rule, the rule hits the local services. If:
•The local services are not active or configured, the rule hits the primary sorry server.
•The primary sorry server fails, the rule hits the secondary sorry server.
Redirect services and redirect content strings cannot be used with Layer 3 or 4 rules because they use the HTTP protocol.
When you configure a Layer 5 content rule, the CSS directs content requests to local services. If:
•The local services are not active or configured, the rule sends the HTTP redirects with the location of the redirect services to the clients.
•The local and redirect services are not active or configured, the rule forwards the HTTP requests to the primary sorry server.
•All services are down except the secondary sorry server, the rule forwards the HTTP requests to the secondary sorry server.
For information on configuring service types, refer to "Specifying a Service Type" in <Xref_Color>Chapter 5, Configuring Services.
Adding a Service to a Content Rule
Use the add service command to add a service to a content rule. The maximum number of services that you can add into a single content rule is 64.
For example:
(config-owner-content[arrowpoint-rule1])# add service serv2
Specifying a Service Weight
When you add a service to a content rule, you can assign a weight for the service using the add service weight option. The CSS uses this weight when you configure weighted roundrobin load balancing on the content rule. When you assign a higher weight to the service, the CSS redirects more requests to the service.
To set the weight for a service, enter a number from 1 to 10. The default is the weight configured for this service through the (config-service) weight command. By default, all services have a weight of 1.
For example:
(config-owner-content[arrowpoint-rule1])# add service serv2 weight 3
Note When you add a service to content rules, the service weight as configured in service mode is applied to each rule as a server-specific attribute. Use the add service weight command to define a content rule-specific server weight. This command overrides the server-specific weight and applies only to the content rule to which you add the service. For information on the (config-service)# weight command, refer to <Xref_Color>Chapter 5, Configuring Services.
Adding a Primary Sorry Server to a Content Rule
Use the primarySorryServer command to configure the primary sorry service for a content rule. The CSS directs content requests to the primary sorry server when all other services are unavailable. You can configure this service to contain content, or to provide a drop or redirect message. This service is not used in load balancing.
Note Once the CSS directs requests to a primary sorry server, it will continue to use the primary sorry server even when the original server becomes functional again. To force the connection back to the original server you must either suspend the primary sorry server or wait until the connection is dropped or times out. When a new session is initiated by the CSS it should go back to the original server.
Enter the server name as a case-sensitive unquoted text string with no spaces.
Note You can only add a primary sorry server to a rule if its range for the IP address or port is equal to the range for the IP address or port of each service on the rule. For example, if the rule has two services each with a range of three addresses, the primary sorry server must have a range of three addresses.
For example:
(config-owner-content[arrowpoint-rule1])# primarySorryServer
slowserver
To remove a primary sorry service, enter:
(config-owner-content[arrowpoint-rule1])# no primarySorryServer
Adding a Secondary Sorry Server to a Content Rule
Use the secondarySorryServer command to configure the secondary sorry service for a content rule. A secondary sorry service is a backup service the CSS uses when the primary sorry service is unavailable. You can configure this service to contain content, or to provide a drop or redirect message. This service is not used in load balancing.
Enter the server name as a case-sensitive unquoted text string with no spaces.
Note You can only add a secondary sorry server to a rule if its range for the IP address or port is equal to the range for the IP address or port of each service on the rule. For example, if the rule has two services each with a range of three addresses, the secondary sorry server must have a range of three addresses.
For example:
(config-owner-content[arrowpoint-rule1])# secondarySorryServer
slowestserver
To remove a secondary sorry service, enter:
(config-owner-content[arrowpoint-rule1])# no secondarySorryServer
Adding a Domain Name System to a Content Rule
To specify a DNS name that maps to a content rule, use the add dns command. The options for this command are:
•add dns dns_name - The DNS name mapped to the content rule. Enter the name as a case-sensitive unquoted text string with no spaces and a length of
1 to 31 characters.
•add dns dns_name ttl_value - The DNS name mapped to the content rule with the optional Time to Live (TTL) value in seconds. This value sets how long the DNS client remembers the IP address response to the query. Enter a value from 0 to 255. The default is 0.
For example:
(config-owner-content[arrowpoint-rule1])# add dns arrowpoint 120
To remove a DNS name mapped to the content rule, enter:
(config-owner-content[arrowpoint-rule1])# remove dns arrowpoint
Note To configure DNS server functionality on the CSS, use the (config) dns-server command.
Activating a Content Rule
Activating content enables the CSS to provide access to the content. To activate content, use the active command in the content mode to activate specific content.
For example:
(config-owner-content[arrowpoint-rule1])# active
Suspending a Content Rule
Suspending a content rule deactivates it. Suspending a content rule:
•Prevents the CSS from providing access to the content
•Does not affect existing flows to the content
To suspend a content rule, use the suspend command in content mode. For example:
(config-owner-content[arrowpoint-rule1])# suspend
Removing a Content Rule
To remove an existing content rule, issue the no content command from owner mode:
(config-owner[arrowpoint])# no content rule1
Removing a Service from a Content Rule
To remove an existing service from a content rule, use the remove command from owner-content mode. Removing a service removes it from the resource pool that the CSS uses for balancing the load of requests for content governed by a rule. When you remove a service, the remaining services are rebalanced.
For example:
(config-owner-content[arrowpoint-rule1])# remove service serv1
Configuring a Protocol
Specifying a protocol in a content rule enables the CSS to direct requests for content associated with the content rule to use a specific protocol.
You may specify the following protocols for content:
•any (default, meaning the rule will match on a tcp or udp port)
•tcp
•udp
To configure the TCP protocol for content, enter:
(config-owner-content[arrowpoint-rule1])# protocol tcp
To reset the protocol to the default of any, enter:
(config-owner-content[arrowpoint-rule1])# no protocol
Configuring Port Information
Specifying a port enables the CSS to associate a content rule with a specific TCP/UDP port number. Specify a port number ranging from 0 to 65535.
To configure a port for content, enter:
(config-owner-content[arrowpoint-rule1])# port 80
To reset the port number to the default of 0, enter:
(config-owner-content[arrowpoint-rule1])# no port
Configuring Load Balancing
Note The CSS supports stateless redundancy failover on CSSs operating in an IP redundancy or a VIP/interface redundancy configuration. Stateless redundancy failover requires a very specific redundant CSS configuration. In regards to load-balancing, balance srcip is the only supported load-balancing method. For details on configuring stateless redundancy failover, refer to the Content Services Switch Advanced Configuration Guide, Chapter 5, Configuring Redundant Content Services Switches.
To specify the load-balancing algorithm for a content rule, use the balance command available in content configuration mode. The options are:
•balance aca - ArrowPoint Content Awareness algorithm. The CSS uses the normalized response time from client to server to determine the load on each service. ACA balances the traffic over the services based on load.
•balance destip - Destination IP address division algorithm. The CSS directs all client requests with the same destination IP address to the same service. This option is typically used in a caching environment.
•balance domain - Domain name division algorithm. The CSS divides the alphabet evenly across the number of caches. It parses the host tag for the first four letters following the first dot and then uses these characters of the domain name to determine to which server it should forward the request. This option is typically used in a caching environment.
•balance domainhash - Internal CSS hash algorithm based on the domain string. The CSS parses the host tag and does an exclusive XOR hash across the entire host name. It then uses the XOR hash value to determine to which server to forward the request. This method guarantees that all requests with the same host tag will be sent to the same server in order to increase the probability of a cache hit. This option is typically used in a caching environment.
•balance leastconn - Least connection algorithm. This balance method chooses a running service that has the least number of connections.
We do not recommend that you use UDP content rules with the leastconn load-balancing algorithm. The service connection counters do not increment and remain at 0 because UDP is a connectionless protocol. Because the counters remain at 0, the CSS will give inconsistent results.
•balance roundrobin - Roundrobin algorithm (default). The CSS resolves the request by evenly distributing the load to resolve domain names among local and remote content domain sites.
•balance srcip - Source IP address division algorithm. The CSS directs all client requests coming from the same source IP address to the same service. This option is generally used in a caching configuration.
•balance url - URL division algorithm. The CSS divides the alphabet evenly across the number of caches. It then parses the URL for the first four characters located after the portion of the URL matched on by the rule. For example, if the URL in a content rule is configured for "/news/*", the CSS will balance on the first four characters following "/news/". This option is typically used in a caching environment.
•balance weightedrr - Weighted roundrobin algorithm. The CSS uses roundrobin but weighs some services more heavily than others depending on the server's configured weight. All servers have a default weight of 1. To set a server weight, use the add service weight command in owner-content mode.
•balance urlhash - Internal CSS hash algorithm based on the URL string. The CSS parses the URL and performs an XOR hash across the URL. It then uses the XOR hash value to determine to which server to forward the request. This method guarantees that all requests for the same URL will be sent to the same server in order to increase the probability of a cache hit. This option is typically used in a caching environment.
For example, to specify weightedrr load balancing, enter:
(config-owner-content[arrowpoint-rule1])# balance weightedrr
To revert the balance type to the default of roundrobin, enter:
(config-owner-content[arrowpoint-rule1])# no balance
Configuring a DNS Balance Type
Use the dnsbalance command to determine where to resolve a request for a domain name into an IP address. The syntax and options for this content mode command are:
•dnsbalance preferlocal - Resolve the request to a local VIP address. If all local systems exceed their load threshold, the CSS chooses the least loaded remote system VIP address as the resolved address for the domain name.
•dnsbalance roundrobin - Resolve the request by evenly distributing the load to resolve domain names among local and remote content domain sites. The CSS does not include sites that exceed their local load threshold.
•dnsbalance leastloaded - Resolve the request to the least-loaded of all local or remote domain sites. The CSS first compares load numbers. If the load number between domain sites is within 50, then the CSS compares their response times. The site with the faster response time is considered the least-loaded site.
•dnsbalance useownerdnsbalance - Resolve the request by using the DNS load balancing method assigned to the owner. This is the default method for the content rule. If you do not configure an owner method, the CSS uses the default owner DNS load-balancing method of roundrobin. To configure a DNS balancing method for an owner, refer to "Configuring an Owner DNS Balance Type" in Chapter 6, Configuring Owners.
For example:
(config-owner-content[arrowpoint-rule1])# dnsbalance roundrobin
To restore the DNS balance type to the default setting of using the owner's method, enter:
(config-owner-content[arrowpoint-rule1])# no dnsbalance
Configuring Hotlists
Use the hotlist command to define a hotlist that lists the content most requested (hot content) during a user-defined period of time. The CSS enables you to configure hotlist attributes for content rules. Defining hotlist attributes for a content rule enables you to determine which content is heavily accessed. With this information, you can accurately determine which content should be replicated.
Note You must configure and enable a hotlist for replication-store and replication-cache to work.
You can configure the following attributes for hotlists for specific content from config-owner-content mode:
•hotlist - Enable the hotlist. To enable a hotlist for a specific content rule, enter the hotlist command from the corresponding owner-content mode. For example:
(config-owner-content[arrowpoint-rule1])# hotlist
To disable a hotlist, enter:
(config-owner-content[arrowpoint-rule1])# no hotlist
•hotlist interval - Set the hotlist refresh interval. Enter the interval time in minutes from 1 to 60. The default is 1. For example:
(config-owner-content[arrowpoint-rule1])# hotlist interval 10
To restore the hotlist interval to the default of 1, enter:
(config-owner-content[arrowpoint-rule1])# no hotlist interval
•hotlist size - Set the size of the hotlist. Enter the total number of entries maintained for this rule from 1 to 100. The default is 10. For example:
(config-owner-content[arrowpoint-rule1])# hotlist size 10
To restore the hotlist size to the default of 10, enter:
(config-owner-content[arrowpoint-rule1])# no hotlist size
•hotlist threshold - Set the hotlist threshold. Enter an integer from 0 to 65535 to specify the threshold above which a piece of content is considered hot. The default is 0. For example:
(config-owner-content[arrowpoint-rule1])# hotlist threshold 9
To restore the hotlist threshold default of 0, enter:
(config-owner-content[arrowpoint-rule1])# no hotlist threshold
•hitCount - Set the hotlist type to hit count, how may times the content was accessed. For example:
(config-owner-content[arrowpoint-rule1])# hotlist type hitcount
To restore the hotlist type to the default setting hitCount, enter:
(config-owner-content[arrowpoint-rule1])# no hotlist type
To display hotlist information, use the show domain hotlist command. Table 7-2 describes the fields in the show domain hotlist output.
Table 7-2 Field Descriptions for the show domain hotlist Command
Field
|
Description
|
Hotlist Enabled/Disabled
|
Enable the domain hotlist. The domain hotlist is disabled by default.
|
Size
|
The configured maximum number of domain entries contained in the hotlist. The default is 10. The number can be from 1 to 100.
|
Interval
|
The configured interval, in minutes, to refresh the domain hotlist and start a new list. The default is 1. The interval can be from 1 to 60.
|
Threshold
|
The configured number of domain hits per interval, which must be exceeded for a domain to be considered hot and added to the list. The default is 0 which indicates that the threshold is disabled. The threshold can be from 0 to 65535.
|
# Hot Domains
|
The total number of hot domains.
|
Hits
|
The number of hits for a hot domain.
|
Domain
|
The name of the hot domain associated with the Hits field.
|
Configuring a Domain Hotlist
Use the domain command to enable the domain hotlist and configure domain hotlist parameters. A domain hotlist lists the most accessed domains on a CSS during a user-defined period of time. The syntax and options are:
•domain hotlist - Enable the domain hotlist. The domain hotlist is disabled by default.
•domain hotlist interval minutes - Configure the interval to refresh the domain hotlist and start a new list. Enter the interval from 1 to 60 minutes. The default is 1 minute.
•domain hotlist size max_entries - Configure the maximum number of domain entries contained in the hotlist. Enter the maximum number of entries from 1 to 100. The default is 10 entries.
•domain hotlist threshold number - Configure the threshold, which is the number of domain hits per interval that must be exceeded for a domain to be considered hot and added to the list. Enter the threshold from 0 to 65535. The default is 0, which disables the threshold.
To enable a domain hotlist, enter:
To disable the domain hotlist, enter:
(config)# no domain hotlist
To display the domain hotlist and its configuration, use the show domain hotlist command (see Table 7-2).
Specifying a Uniform Resource Locator
Use the url command to specify the Uniform Resource Locator (URL) for content and enable the CSS to access a remote service when a request for content matches the rule. Enter the URL as a quoted text string with a maximum length of 252 characters. Before you can change the URL for the content rule, you must remove the current URL first.
Note Do not include the ? or # parameter character in the URL string. The CSS terminates the URL at these parameter characters.
The syntax and options for this content mode command are:
•url "/url_name" - Specify the URL for the content as a quoted text string with a maximum length of 252 characters.
•url "/{url_path}/*" eql eql_name - Specify the URL for any content file that has its file extension defined in the specified Extension Qualifier List (EQL).
•url "/{url_path}/*" dql dql_name {eql_name} - Specify the URL for any content file that has its domain name defined in the specified Domain Qualifier List (DQL). You cannot use a DQL in conjunction with a domain name in a URL. You may optionally include an EQL after the DQL name to specify file extensions as part of the DQL matching criteria.
•url urql urql_name - Specify a URQL consisting of a group of URLs to this content rule. Note that you cannot specify both url urql and application ssl for the same content rule.
The variables are:
•url_name - The URL for the content. Enter a quoted text string with a maximum length of 252 characters. You must place a slash character (/) at the beginning of the URL (for example, "/announcements/prize.html").
To specify a domain name, place two slashes (//) at the beginning of the URl. For example, "//www.arrowpoint.com/*" allows the rule to match on HTTP traffic that contains the www.arrowpoint.com domain name in the HTTP host tag.
To use stickiness based on Secure Socket Layer (SSL) session ID, set the URL to /*. Also, set the port to 443 with the (config-owner-content) port command and enable stickiness with the (config-owner-content) advanced-balance ssl command. Then specify an SSL application type.
You can specify certain wildcard operations for wildcard matching. Use a "*" character to specify a wildcard match. You can specify a maximum of eight directories. Each directory name can be a maximum of 32 characters with a total maximum of 252 characters in the URL. You can specify only one wildcard per URL.
Examples of supported wildcards are:
•/*.html - Matches all requests with the .html extension.
•/announcements/* - Matches all requests for files in the announcements directory.
•/announcements/*.html - Matches requests for files in the announcements directory having .html extensions.
•/announcements/new/*.jpg - Matches requests for all files in the announcements/new directory that contain the .jpg extension.
•url_path - An optional path to any content file that has its file extension defined in the EQL. Enter a quoted text string. You must place:
–A slash character (/) at the beginning of the quoted path
–/* characters at the end of the quoted path
For example, "/announcements/new/*".
•eql_name - The name of the EQL. To see a list of EQLs, enter eql ?.
•urql_name - The name of the URQL. You can only assign one URQL per rule. To see a list of URQLs, enter urql ?.
Note For caching environments, you can configure a domain content rule by placing two slash characters (//) at the front of the url_name or url_path. The rule matches HTTP traffic that contains the domain name in the HTTP host tag.
For example, to specify a URL that matches all requests for content in the announcements directory with .html extensions, enter:
(config-owner-content[arrowpoint-products.html])# url
"/announcements/*.html"
To remove an URL, enter:
(config-owner-content[arrowpoint-products.html])# no url
To remove a URQL from an URL, enter:
(config-owner-content[arrowpoint-products.html])# no url urql
To display a URL for a content rule, enter the show rule command for the content rule.
Specifying an Extension Qualifier List in a Uniform Resource Locator
Server selections are based on the Uniform Resource Locator (URL) specified in the owner content rule. To enable the CSS to access a service when a request for content matches the extensions contained in a previously defined EQL, specify the URL and EQL name for the content. For information on creating an EQL, refer to the Content Services Switch Advanced Configuration Guide.
Specify a URL as a quoted text string with a maximum of 252 characters followed by eql and the EQL name.
Note Do not specify a file extension in the URL when you use an EQL in the URL or the CSS will return an error message. For example, the CSS will return an error message for the command url "/*.txt" eql Cacheable. The following command is valid; url "/*" eql Cacheable.
For example:
(config-owner-content[arrowpoint-products.html])# url "/*" eql
graphics
The following example enables the CSS to direct all requests to the correct service for content that matches:
•Pathnames (/customers/products)
•Extensions listed in the EQL (graphics)
(config-owner-content[arrowpoint-products.html])# url
"/customers/products/*" eql graphics
To display a content rule EQL, enter show rule.
Specifying a Load Threshold
Use the load-threshold command to set the normalized load threshold for the availability of each local service on a content rule. When the service load metric exceeds this threshold, the local service becomes unavailable and is redirected to remote services. To define a remote service, use the service mode type redirect command (refer to "Specifying a Service Type" in <Xref_Color>Chapter 5, Configuring Services).
Enter the load threshold as an integer from 2 through 254. The default is 254, which is the maximum threshold a service can reach before becoming unavailable. To view the load on services, enter show service. For example:
(config-owner-content[arrowpoint-rule1])# load-threshold 100
To reset the load threshold to its default value of 254, enter:
(config-owner-content[arrowpoint-rule1])# no load-threshold
Redirecting Requests for Content
Use the redirect command to set HTTP status code 302 for a content rule and specify the alternate location of the content governed by a rule. Use this command to:
•Make the content unavailable to subsequent requests at its current address.
•Provide an URL to send back to the requestor. You must add an URL to the content rule for redirect to force the HTTP request. For example, url "/*". Enter the URL as a quoted text string with a maximum of 64 characters.
Note If you also set status code 404 (drop message) for content, code 302 takes priority.
Do not configure a service for a redirect-only content rule.
For example:
(config-owner-content[arrowpoint-rule1])# redirect
"//www.arrowpoint.com/newlocation.html"
To delete the redirect URL, enter:
(config-owner-content[arrowpoint-rule1])# no redirect
Configuring Persistence, Remapping, and Redirection
During the life of a persistent connection, a CSS must determine if it needs to move a client connection to a new service based on content rules, load balancing, and service availability. In some situations, moving the client connection is not necessary; in other situations, it is mandatory. This section describes how to configure the CSS to make these decisions using:
•Content rule persistence
•Bypass persistence
•HTTP Redirection
•Service Remapping
Content Rule Persistence
When a CSS receives a request for content from a client, the software checks if the request matches on a content rule to determine the best service to handle the request. If the request matches on a content rule, the CSS establishes a client connection to the best service specified by the content rule. By default, the CSS keeps the client on the same connection for an entire flow session as long as a new content request:
•Matches on the same content rule that specified the current service.
•Matches on a new content rule that contains the current service, even if a different best service is specified by the content rule.
This CSS behavior is known as content rule persistence. If you are using transparent caches (which prefetch content) or mirrored-content servers, this scheme works well because the same content is available on each service.
Use the persistent command in content configuration mode to maintain a persistent connection with a server as long as the above criteria are met. By default, persistence is enabled. Disabling persistence allows the CSS to move a connection to a better service on the same rule or to use cache bypass functionality (EQLs or failover bypass).
For example:
(config-owner-content[arrowpoint-rule1])# persistent
Use the no persistent command on a content rule with:
•A balance method of domain or domain hash when using proxy caches
•A balance method of url or urlhash when using transparent caches
•A failover method of bypass when using transparent caches
•An EQL bypass with a transparent cache
•Adding a sorry server to a content rule
To disable persistence:
(config-owner-content[arrowpoint-rule1])# no persistent
Note If a request for content on a persistent connection matches on a new content rule that does not contain the current service, or persistence is disabled and there is a better service configured in the content rule, the CSS redirects or remaps the current connection to a new best service based on the setting of the persistence reset command, if configured. If you do not configure persistence reset, the CSS performs an HTTP redirect by default. For details, refer to "Configuring HTTP Redirection and Service Remapping" later in this chapter.
Configuring Bypass Persistence
If a CSS bypasses a service (for example, a transparent cache is down and failover bypass is configured) and the next content request on the same TCP connection matches on a content rule that contains the transparent cache that was down, the CSS will continue to bypass the cache, by default, even after the bypassed cache is back online. In this case, the CSS typically sends the content request to the origin server. This behavior is called bypass persistence.
You can configure the CSS to redirect or remap a bypassed connection using the bypass persistence global config command in conjunction with the persistence reset command.
Use the bypass persistence command to determine if the CSS performs either a remapping or redirection operation to reset a bypassed service when a content request matches on a content rule, but a previous request caused the bypass. This global command affects all flows. By default, bypass persistence is enabled.
For example:
(config)# bypass persistence disable
The CSS uses remapping or redirection to reset the connection according to the setting of the persistence reset method.
(config)# bypass persistence enable
The CSS does not use remapping or redirection to reset the connection and continues to bypass a service.
Configuring HTTP Redirection and Service Remapping
If you need to place different content on different servers (for example, to conserve server disk space, for load balancing considerations, or when using proxy caches), content rule persistence is not useful. In this case, you can disable persistence by issuing the no persistent command described in "Content Rule Persistence" earlier in this section.
When the CSS receives a request for content that is not available on the current service, it must reset the current connection to the service and establish a new connection to another service (for example, a different proxy cache or the origin server) that contains the requested content. You can accomplish this in either of the following ways:
•Redirection - An HTTP technique that resets both the client-to-CSS (front-end) connection and the CSS-to-service (back-end) connection, then establishes a new flow to the best service that contains the requested content.
•Service Remapping - A technique that resets only the back-end connection to the current service and then creates a new back-end connection to the best service that contains the requested content. This technique is faster and more efficient than redirection because the CSS does not need to reset and then reestablish the front-end connection. With Service Remapping, the CSS strictly manages port mapping to prevent the occurrence of duplicate port numbers.
Use the persistence reset command with the content rule no persistent command to cause an HTTP redirection or perform a back-end remapping operation when resetting a connection to a new back-end service. The global persistence reset command affects all flow setups that require redirection or remapping.
For example, to enable redirection:
(config)# persistence reset redirect
For example, to enable Service Remapping:
(config)# persistence reset remap
Note The CSS does not use remapping when selecting redirect type services. Refer to "Specifying a Service Type" in <Xref_Color>Chapter 5, Configuring Services.
If your topology consists of a CSS 11800 using ECMP to the servers and server port NAT configured on the services, to ensure the correct processing of packets either:
•Enable Service Remapping with the persistence reset remap command.
•Create source groups for the services in the content rule with the add destination service command.
Specifying an HTTP Redirect String
Use the redirect-string command to specify an HTTP redirect string to be used when an HTTP redirect service generates an "object moved" message for the service. The CSS uses the entire configured redirect string as the new location for the requested content. If no string is configured, the CSS prepends the domain configured with the (config-service) domain command to the original request. If neither the redirect string or domain name are configured, the CSS uses the domain in the host-tag field from the original request combined with the requested HTTP content. If no host tag is found, the CSS uses the IP address of the service to generate the redirect.
Note You can only use a redirect string on a service type redirect.
Note The redirect-string and (config-service) domain commands are similar. The CSS returns the redirect-string command string verbatim as configured. However, the CSS prepends the domain configured with the (config-service) domain command to the original requested URL.
Note You cannot configure the redirect-string and (config-service) domain commands simultaneously on the same service.
The syntax for this service mode command is:
redirect-string string
Enter the HTTP redirect string as an unquoted text string with no spaces and a maximum length of 64 characters.
For example:
(config-service[serv1])# redirect-string www.arrowpoint.com
To remove the redirect string from the service, enter:
(config-service[serv1])# no redirect-string www.arrowpoint.com
Using Show Remap
Use the show remap command to display the configured persistence reset and bypass persistence settings. This command is available in all modes.
Table 7-3 describes the fields in the show remap output.
Table 7-3 Field Descriptions for the show remap Command
Field
|
Description
|
Group SFP Port Map Info
|
This field is currently not used.
|
Persistence Reset Method
|
The configured persistence reset method when resetting a connection to a new back-end service. The possible methods are:
•redirect - Causing an HTTP redirection when resetting a connection to a new back-end service. An HTTP redirection resets both sides of the connection.
•remap - Using a back-end remapping operation when resetting a connection to a new back-end service.
|
Bypass Persistence
|
The configured bypass persistence setting. The possible settings are:
•disable - The CSS performs either a service remapping or HTTP redirection operation to reset a bypassed service when a content request matches on a content rule, but a previous request caused the bypass.
•enable - The CSS does not perform remapping or redirection to reset the connection and continue to bypass a service. By default, bypass persistence is enabled.
|
Defining Failover
Note The CSS supports stateless redundancy failover on CSSs operating in an IP redundancy or a VIP/interface redundancy configuration. Stateless redundancy failover requires a very specific redundant CSS configuration, which includes either failover linear or failover next as the failover method. For details, refer to the Content Services Switch Advanced Configuration Guide, Chapter 5, Configuring Redundant Content Services Switches.
To define how the CSS handles content requests when a service fails or is suspended, use the failover command. For the CSS to use this setting, ensure that you configure a keepalive for each service; that is, do not set the keepalive type to none (the keepalive default is ICMP). The CSS uses the keepalive settings to monitor the services to determine server health and availability.
The failover command applies to the following caching load balancing types:
•balance domain
•balance url
•balance srcip
•balance destip
•balance domainhash
•balance urlhash
Note If you remove a service (using the remove service command), the CSS rebalances the remaining services. The CSS does not use the failover setting.
This command supports the following options:
•failover bypass - Bypass all failed services and send the content request directly to the origin server. This option is used in a proxy or transparent cache environment when you want to bypass the failed cache and send the content request directly to the server that contains the content.
•failover linear (default) - Distribute the content request evenly between the remaining services.
•failover next - Send the content requests to the cache service next to the failed service. The CSS selects the service to redirect content requests to by referring to the order in which you configured the services.
For example:
(config-owner-content[arrowpoint-rule1])# failover bypass
To restore the default setting of failover linear, enter:
(config-owner-content[arrowpoint-rule1])# no failover
shows three cache services configured for failover next. If ServerB fails, the CSS sends ServerB content requests to ServerC, which was configured after ServerB in the content rule.
Figure 7-3 ServerB Configured for Failover Next
As shown in , if ServerC fails, the CSS sends ServerC content requests to ServerA because no other services were configured after ServerC.
Figure 7-4 ServerC Configured for Failover Next
shows three cache services configured for failover linear. If you suspend ServerB or if it fails, the CSS does not rebalance the services. It evenly distribute ServerB cache workload between servers A and C.
Note that and use the alphabet to illustrate division balance.
Figure 7-5 Suspended or Failed Service Configured for Failover Linear
also shows three cache services configured for failover linear, but in this example, you remove ServerB using the remove service command from owner-content mode. Because the CSS does not apply the failover setting when you remove a service, it rebalances the remaining services.
Figure 7-6 Removing a Service Configured for Failover Linear
Specifying an Application Type
To specify the application type associated with a content rule, use the application command. The application type enables the CSS to correctly interpret the data stream to match and parse the content rule. Otherwise, the data stream packets are rejected. Define an application type for non-standard ports.
When configuring Layer 5 content rules for an application other than HTTP, enter the appropriate application type to enable the Layer 5 rule to function.
Note A Layer 5 content rule supports the HTTP CONNECT, GET, HEAD, POST, PUSH, and PUT methods.
The application command enables you to specify the following application types:
•bypass - Bypass the matching of a content rule and sends the request directly to the origin server.
•ftp-control - Process FTP data streams.
•http (default) - Process HTTP data streams.
•realaudio-control - Process RealAudio Control data streams.
•ssl - Process Secure Socket Layer (SSL) protocol data streams. Note that you cannot specify both url urql and application ssl for the same content rule.
For example, in a content rule that specifies port 21, you may want to configure the application type as ftp-control. Configuring the content rule to application type ftp-control instructs the CSS to process only FTP requests coming into port 21.
(config-owner-content[arrowpoint-rule1])# application type
ftp-control
Note When you configure the CSS to support passive FTP on non-standard FTP control or data ports, the CSS inspects the PASV 227 server response payload in order to NAT the embedded server IP address and server TCP port number. If you configure the CSS to perform this NAT through an ACL clause with a preferred source group, then you must configure the ACL clause to match on the FTP control port. The CSS does not perform ACL clause matching based on the embedded FTP PASV payload IP address or TCP port number.
For example, the following owner portion of a startup-config shows a content rule configured for application ftp-control.
!************************** OWNER **************************
To remove an application type, enter:
(config-owner-content[arrowpoint-rule1])# no application
Enabling Content Requests to Bypass Transparent Caches
Use the param-bypass command to enable content requests to bypass transparent caches when the CSS detects special terminators in the requests. These terminators include "#" and "?" which indicate that the content is dependent on the arguments that follow the terminators. Because the content returned by the server is dependent on the content request itself, the returned content is deemed as not cacheable, and the content request is directed to the origin server.
This command contains the following options:
•param-bypass disable (default) - Content requests with special terminators do not bypass transparent caches.
•param-bypass enable - Content requests with special terminators bypass transparent caches and are forwarded to the origin server.
For example, to enable the param-bypass command, enter:
(config-owner-content[arrowpoint-rule1])# param-bypass enable
Showing Content
The show content command enables you to display all configured content in the CSS. You can issue the show content command from any mode.
To display content information, enter:
There are 2 pieces of content:
Index: 0 <173.168.128.11> TCP Port 80 Best Effort
Index: 1 <173.168.128.11> TCP Port 80 Best Effort
The CSS 11800 provides two additional options to the show content command:
•all
•sfp_number
These options display all content entries in the Switch Fabric Processors (SFP) on a specific SFP. Each SFM has two SFPs, for a maximum of four SFPs in a CSS 11800.
For example:
(config)# show content all
Total pieces of content: 22
Pieces of content for SFP 6/1: 3
Pieces of content for SFP 9/1: 6
Pieces of content for SFP 6/2: 5
Pieces of content for SFP 9/2: 8
Table 7-4 describes the fields in the show content output.
Table 7-4 Field Descriptions for the show content Command
Field
|
Description
|
Index
|
CSD unique index for a known piece of content.
|
<address>
|
The IP address of this known piece of content.
|
Protocol
|
The IP Protocol of this known piece of content.
|
Port
|
Protocol port of this known piece of content.
|
Best Effort
|
The QOS class of this known piece of content. This field is not used by the CSS at this time.
|
Showing Content Rules
The show rule command displays content rule information for specific content rules or all content rules currently configured in the CSS. Issue the following show rule commands from any mode:
•show rule - Display all owners and content rules currently configured in the CSS
•show rule-summary - Display a summary of owner content information
•show rule owner_name - Display information identical to the show rule command, but only for the specified owner's content
•show rule owner_name content_rule_name - Display information identical to the show rule command, but only for a specific owner and content
•show rule owner_name content_rule_name acl - Display the ACL attributes for the specified content rule
•show rule owner_name content_rule_name all - Displays all attributes for the specified content rule
•show rule owner_name content_rule_name dns - Display the DNS attributes for the specified content rule
•show rule owner_name content_rule_name header-field - Display the header-field attributes for the specified content rule
•show rule owner_name content_rule_name hot-list - Display the hotlist attributes for the specified content rule
•show rule owner_name content_rule_name services - Display the services for the specified content rule
•show rule owner_name content_rule_name statistics - Display the statistics for the specified content rule
•show rule owner_name content_rule_name sticky - Display the sticky attributes for the specified content rule
To display all content rule information, enter:
To display the summary for all content rules, enter:
To display all rule attributes for an owner, enter:
# show rule owner content_rule all
Note The CntRuleName and OwnerName fields display the first 16 characters of the configured data. The Url field displays the first 10 characters of configured data.
Table 7-5 describes the fields in the show rule output.
Table 7-5 Field Descriptions for the show rule Command
Field
|
Description
|
Name
|
The name of the content rule.
|
Owner
|
The owner of the rule.
|
Author
|
The author (Local CSS or remote CSS peer) of the rule.
|
Index
|
A CSS assigned unique index for the rule. The number is based in the order that the rule was created.
|
State
|
The state of the rule (active or suspend).
|
Type
|
The application type associated with the rule. The possible values are:
•bypass, to bypass the matching of the content rule and send the request directly to the origin server.
•http (default), to process HTTP data streams.
•ftp-control, to process FTP data streams.
•realaudio-control, to process RealAudio Control data streams.
•ssl, to process Secure Socket Layer (SSL) protocol data streams.
|
L3
|
Destination IP address.
|
L4
|
Destination protocol and port.
|
Url
|
The URL for the content.
|
URQL
|
The name of the associated URL Qualifier list.
|
EQL
|
The name of the associated EQL.
|
DQL
|
The name of the associated DQL.
|
Header Field Group
|
The name of the associated header-field group.
|
Total Bytes
|
The total bytes to the content rule.
|
Total Frames
|
The total frames to the content rule.
|
Total Redirects
|
The total redirects by the content rule.
|
Total Rejects
|
The total rejects by the content rule.
|
Overload Rejects
|
Total rejects on the content rule due to overload on the rule's available services.
|
Balance
|
The load-balancing algorithm for the content rule. The possible values are:
•ACA - ArrowPoint Content Awareness algorithm. The CSS correlates content request frequency with the server's cache sizes to improve cache hit rates for that server.
•destip - Destination IP address division. The CSS directs all client requests with the same destination IP address to the same service.
•domain - Domain name division. The CSS uses the domain name in the request URI to direct the client request to the appropriate service.
•domainhash - Internal CSS hash algorithm based on the domain string. The CSS uses the algorithm to hash the entire domain string. Then, the CSS uses the hash result to choose the server.
|
Balance (continued)
|
•leastconn - Least connections. The CSS chooses a running service that has the least number of connections.
•roundrobin - Roundrobin algorithm (default).
•srcip - Source IP address division. The CSS directs all client requests with the same source IP address to the same service.
•url - URL division. The CSS uses the URL (omitting the leading slash) in the redirect URL to direct the client requests to the appropriate service.
•urlhash - Internal CSS hash algorithm based on the URL string. The CSS uses the algorithm to hash the entire URL string. Then, the CSS uses the hash result to choose the server.
•weightedrr - Weighted roundrobin algorithm. The CSS uses the roundrobin algorithm but weighs some services more heavily than others. You can configure the weight of a service when you add it to the rule.
|
Advanced Balance
|
The advanced load balancing method for the content rule, including stickiness. The possible values are:
•arrowpoint-cookie - Enables the content rule to stick the client to the server based on the unique service identifier information of the selected server in the ArrowPoint-generated cookie.
•cookies - Enables the content rule to stick the client to the server based on the configured string found in the HTTP cookie header. You must specify a port in the content rule to use this option. The CSS will then spoof the connection.
•cookieurl - This is the same as advanced-balance cookies, but if the CSS cannot find the cookie header in the HTTP packet, this type of failover looks up the URL extensions (that is, the portion after the "?" in the URL) based on the same string criteria. You can use this option with any Layer 5 HTTP content rule.
|
Advanced Balance (continued)
|
•none - Disables the advanced-balancing method for the rule. This is the default setting.
•sticky-srcip - Enables the content rule to stick a client to a server based on the client IP address, also known as Layer 3 stickiness. You can use this option with Layer 3, 4, or 5 content rules.
•sticky-srcip-dstport - Enables the content rule to stick a client to a server based on both the client IP address and the server destination port number, also known as Layer 4 stickiness. You can use this option with Layer 4 or 5 content rules.
•ssl - Enables the content rule to stick the client to the server based on the Secure Socket Layer (SSL) version 3 session ID assigned by the server. The application type must be SSL for the content rule. You must specify a port in the content rule to use this option. The CSS will then spoof the connection.
•url - Enables the content rule to stick a client to a server based on a configured string found in the URL of the HTTP request. You must specify a port in the content rule to use this option. The CSS will then spoof the connection.
|
Sticky Mask
|
The subnet mask used for stickiness. The default is 255.255.255.255.
|
Sticky Inactivity timeout
|
The inactivity timeout period on a sticky connection for a content rule before the CSS removes the sticky entry from the sticky table. The default value is 0, which means this feature is disabled. The range is from 0 to 65535 minutes.
|
Sticky No Cookie Found Action
|
The action the CSS should take for a sticky cookie content rule when it cannot locate the cookie header or the specified cookie string in the client request. The possible values are:
•loadbalance - The CSS uses the configured balanced method when no cookie is found in the client request. This is the default setting.
•redirect "URL" - The CSS redirect the client request to a specified URL string when no cookie found in the client request. When using this option, you must also specify a redirect URL. Enter the redirect URL as a quoted text string from 0 to 64 characters.
•reject - The CSS reject the client request when no cookie is found in the request.
•service name - The CSS sends the no cookie client request to the specified service when no cookie is found in the request.
|
Sticky Server Down Failover
|
The action that the CSS should take when a sticky string is found but the associated service has failed or is suspended. The possible values are:
•Balance - The failover method uses a service based on the configured load balancing method (default).
•Redirect - The failover method uses a service based on the currently configured redirect string. If a redirect string is not configured, the load balancing method is used.
•Reject - The failover method rejects the content request.
•Sticky-srcip - The failover method uses a service based on the client IP address. This is dependent on the sticky configuration.
•Sticky-srcip-dstport - The failover method uses a service based on the client IP address and the server destination port. This is dependent on the sticky configuration.
|
ArrowPoint Cookie Path
|
The pathname where you want to send the ArrowPoint cookie. The default path of the cookie is "/".
|
ArrowPoint Cookie Expiration
|
The expiration time that the CSS compares with the time associated with the ArrowPoint cookie. If you do not set an expiration time, the cookie expires when the client exits the browser.
|
String Match Criteria
|
The string criteria to derive string results and the method to choose a destination server for the result. The string result is a sticky string in the cookie header, URL, or URL extension based on a sticky type being configured. Refer to the following fields.
|
String Range
|
The starting and ending byte positions within a cookie, URL, or URL extension from a client. By specifying the range of bytes, the CSS processes the information located only within the range.
•The default starting byte position is 1. The range is from 1 to 1999.
•The default ending byte position is 100. The range is from 2 to 2000.
|
String Prefix
|
The string prefix located in the sticky range. If you do not configure the string prefix, the string functions start from the beginning of the cookie, URL, or URL extension, depending on the sticky type. If the string prefix is configured but is not found in the specified sticky range, load balancing defaults to the round robin method. The default has no prefix ("").
|
String Eos-Char
|
The ASCII characters as the delimiters for the sticky string.
|
String Ascii-Conversion
|
Whether to enable or disable the ASCII conversion of escaped special characters within the specified sticky range before applying any processing to the string. By default, ACSII conversion is enabled.
|
String Skip-Len
|
The number of bytes to skip after the end of the prefix to find the string result. The default is 0. The range is from 0 to 64.
|
String Process-Len
|
The number of bytes, after the end of the prefix designated by the string prefix command and skipping the bytes designated by the string skip-length command, that the string operation will use. The default is 0. The range is from 0 to 64.
|
String Operation
|
The method to choose a destination server for a string result; derived from the settings of the string criteria commands. The possible values are:
•match-service-cookie - Choose a server by matching a service cookie in the sticky string. This is the default setting. When a match is not found, the server is chosen by using the configured balance method (for example, roundrobin). This is the default method.
•hash-a - Apply a basic hash algorithm on the hash string to generate the hash key.
•hash-crc32 - Apply the CRC32 algorithm on the hash string to generate a hash key.
•hash-xor - Exclusive OR (XOR) each byte of the hash string to derive the final hash key.
|
Redirect
|
Text used to build an HTTP 302 redirect message that is sent to the client when the rule is matched.
|
Persistence
|
Whether or not a persistent connection with a server is maintained. By default, persistence is enabled.
|
Param-Bypass
|
Whether or not content requests bypass transparent caches when the CSS detects special terminators in the requests. These terminators include "#" and "?" which indicate that the content is dependent on the arguments that follow the terminators. Bypass is disabled by default.
|
Services
|
Content rule services to configuration and statistic information, as follows.
|
Local Load Threshold
|
The normalized load threshold for the availability of each local service on the content rule. When the service load metric exceeds this threshold, the local service becomes unavailable and is redirected to the remote services. The default is 254, which is the maximum load. The range is from 2 through 254. A load of 255 indicates that the service is down
|
PrimarySorryServer
|
The primary service to be used when all other services for the content rule are unavailable.
|
SecondSorryServer
|
The secondary service to be used when all other services for the content rule are unavailable.
|
Name
|
The names of the services.
|
Hits
|
The number of content hits on the service.
|
Wgt
|
The weight for the service used when you configure ACA and weighted roundrobin load balancing on the content rule. With a higher weight, the CSS redirects more requests to the service.
|
State
|
The state of the service.
|
Ld
|
The service load. The range is from 2 to 255. 255 indicates that the service is unavailable.
|
KAlive
|
The service keepalive type.
|
Conn
|
The number of connections currently mapped to the service.
|
DNS
|
The number of times that the CSS DNS resolver chose the service as the answer to a DNS client query.
|
DNS Names
|
Domain Name Server names.
|
DNS TTL
|
The time to Live value in seconds, which determines how long the DNS client remembers the IP address response to the query.
|
DNS Balance
|
Where the CSS resolves a request for a domain name into an IP address. The possible values are:
•leastloaded - Resolves the request to the least-loaded local or remote domain site. The CSS first compares load numbers. If the load number between domain sites is within 50, then the CSS compares their response times. The site with the faster response time is considered the least loaded site.
•Preferlocal - Resolves the request to a local VIP address. If all local systems exceed their load threshold, the CSS chooses the least-loaded remote system VIP address as the resolved address for the domain name.
•roundrobin - Resolves the request by evenly distributing the load to resolve domain names amongst content domain sites, local and remote. The CSS does not include sites that exceed their local load threshold.
•useownerdnsbalance - Resolves the request by using the DNS load balancing method assigned to the owner. This is the default method for the content rule. If you do not implicitly set an owner method, the CSS uses the default owner DNS load balancing method of roundrobin.
|
Hotlist
|
Whether or not hotlist is enabled.
|
Size
|
The total number of hotlist entries that is maintained for the rule. The default is 10. The range is from 1 to 100.
|
Type
|
The hotlist type. Currently, the CSS supports only the hit count hotlist type, which is the default setting. Hit count is the number of times that the content is accessed.
|
Threshold
|
The hit count per interval threshold below which content is not considered hot. The default is 0. The range is from 0 to 65535.
|
Interval
|
The interval, in minutes, for refreshing the hotlist. The default is 1. The range is from 1 to 60.
|
Associated ACLs
|
The associated ACLs.
|
