-
Cisco ACNS Software Configuration Guide for Centrally Managed Deployments, Release 5.4
-
Index
-
Preface
-
Chapter 1: Understanding the ACNS 5.4 Network
-
Chapter 2: Getting Started
-
Chapter 3: Using the Content Distribution Manager GUI
-
Chapter 4: Setting up Content Request Routing in the ACNS Network
-
Chapter 5: Configuring the ACNS Network for Content Distribution
-
Chapter 6: Configuring the ACNS Network for Content Acquisition
-
Chapter 7: Creating and Managing Programs
-
Chapter 8: Configuring Caching Services
-
Chapter 9: Configuring Streaming Media Services
-
Chapter 10: Managing Caching Performance and Differentiated Services
-
Chapter 11: Viewing Content Replication Status
-
Chapter 12: Configuring Login Authentication, Configuration Authorization, and Accounting
-
Chapter 13: Working with Device Configurations
-
Chapter 14: Configuring Network Interfaces
-
Chapter 15: Configuring Request Authentication and Authorization
-
Chapter 16: Configuring Request Processing Services
-
Chapter 17: Creating and Managing IP Access Control Lists
-
Chapter 18: Configuring Group Authorization Using an Access Control List
-
Chapter 19: Using the Transaction Logs
-
Chapter 20: Configuring Platform and System Settings
-
Chapter 21: Monitoring and Troubleshooting the ACNS Network
-
Chapter 22: Monitoring with SNMP
-
Appendix A: Creating Manifest Files
-
Appendix B: IP Multicast Addressing
-
Appendix C: Advanced Routing Configurations
-
Appendix D: Mapping ACNS Software CLI Commands to the Content Distribution Manager GUI
-
Table Of Contents
Setting Up Content Request Routing in the ACNS Network
Configuring WCCP Transparent Routing
About Dynamic WCCP Redirection Services
About WCCP Custom Web Cache Service
Configuring WCCP General Settings for the Content Engine
Configuring WCCP Service Settings for the Content Engine
Modifying WCCP Router Lists for the Content Engine
Viewing WCCP Router Lists for the Content Engine
Assigning Unique Router Lists to Content Engines in a Device Group
Configuring WCCP Port Lists for the Content Engine
Configuring WCCP Service Masks for the Content Engine
Configuring WCCP Transparent Routing Bypass Options
Configuring Authentication Traffic Bypass
Configuring WCCP Bypass Settings
Creating WCCP Bypass List Entries
Basic WCCP Router Configurations for Web Caching
Web Cache Service Configuration with Clients and Content Engine on the Same Subnet
Configuring the Content Engine for Web Cache Service—Clients and Content Engine on the Same Subnet
Configuring the Router for Web Cache Service—Clients and Content Engine on the Same Subnet
Configuration Examples—Web Cache Service with Clients and Content Engine on the Same Subnet
Web Cache Service Configuration with Clients and Content Engine on Different Subnets
Configuring the Content Engine for Web Cache Service—Clients and Content Engine on Different Subnets
Configuring the Router for Web Cache Service—Clients and Content Engine on Different Subnets
Configuration Examples—Web Cache Service with Clients and Content Engine on Different Subnets
Configuring Direct Proxy Routing
Using a Proxy Autoconfiguration File Server
Registering a PAC File Template and Assigning Coverage Zone Information
Configuring a Content Engine as a PAC File Server
Configuring Client Proxy Autoconfiguration Settings
Configuring Content Request Routing Using a Content Router or Routing Content Engine
Coverage Zones and Coverage Zone Files
Registering Coverage Zone Files
Using the Default Coverage Zone
Registering and Applying a User-Defined Coverage Zone
Scenario 1: No Network Address Translation Firewall
Scenario 2: Content Engine Behind a NAT Firewall
Scenario 3: Multiple Content Engines Behind a NAT Firewall
Scenario 4: NAT Firewall with Multiple IP Addresses
Configuring a Content Engine as a Routing Content Engine
Configuring Dynamic Content Routing Using a Content Router
Enabling Dynamic Content Routing
Changing the Content Engine Metric Value for Dynamic Content Routing in the Coverage Zone File
Configuring Load-Based Content Routing Using a Content Router
Enabling Load-Based Routing on the Content Router
Configuring Content Engine Threshold Limits for Load-Based Routing
Troubleshooting Content Router Configurations
Setting Up Content Request Routing in the ACNS Network
Cisco ACNS 5.4 software supports three methods of request handling to deliver content to the end user. These request handing methods are described in the following sections:
•
Configuring WCCP Transparent Routing
•
•
•
Note
Figure 4-1 shows the basic tasks involved in configuring each of the three request handling methods.
Figure 4-1 Choosing a Routing Method
Configuring WCCP Transparent Routing
In the WCCP transparent routing method, requests for content made to an origin server are intercepted by a WCCP-enabled router. The WCCP-enabled router transparently redirects the request to a Content Engine containing the content. This type of transparent redirection allows for traffic interception on any port for traffic that traverses this router. WCCP contains many fail-safe mechanisms to ensure that the request interception remains entirely transparent to the end user.
To use a WCCP-enabled router, an IP address must be configured on the interface connected to the Internet, and the interface must be connected to the Content Engine. A Content Engine and a WCCP-enabled router cannot be separated by a firewall. The firewall handles only packet traffic toward the origin web server and does not handle packet traffic sent to the client by the Content Engine on behalf of the server.
You can configure only a single router to run the web cache service (WCCP Version 1 service). To use WCCP Version 1 with the Content Engine, you must point the Content Engine to a designated home router.
However, WCCP Version 2 enables a series of Content Engines, called a Content Engine cluster, to connect to multiple routers. This feature provides redundancy and a more distributed architecture for instances when a Content Engine needs to connect to a large number of interfaces. WCCP Version 2 also balances traffic load across a cache cluster and ensures fault-tolerant and fail-safe operation. As Content Engines are added to or deleted from a cache cluster, the WCCP-aware router or switch dynamically adjusts its redirection map to reflect the currently available caches.
When operating with WCCP Version 2, the Content Engine performs a clean shutdown after reboot, enabling WCCP Version 1, or disabling WCCP Version 2. A clean shutdown prevents broken TCP connections. (See the "About WCCP Clean Shutdown" section.)
Figure 4-2 shows how requests for content are routed using the WCCP transparent interception method.
Figure 4-2 Request Interception Using WCCP
1.
2.
3.
4.
WCCP can also handle asymmetric packet flows and always maintains a consistent mapping of web servers to Content Engines regardless of the number of routers used in a WCCP service group (up to 32 routers communicating with up to 32 Content Engines in a cluster).
There are some significant advantages to using a WCCP-enabled router for request routing interception in transparent mode:
•
•
•
•
Figure 4-3 shows the packet flow between a Content Engine and a router.
Figure 4-3 Packet Flow Diagram
In Figure 4-3, if the Content Engine does not have the data, a cache miss occurs, and the Content Engine sends the request to the origin server. As the Content Engine receives the data from the origin server, it saves the data and forwards the data to the client.
About WCCP Services
WCCP uses the concept of a service group to define caching related services for a WCCP-enabled router and WCCP-enabled Content Engines in a cluster. Service groups are identified by a service group number. Each WCCP service group number specifies a router list, single port list (containing up to eight ports), application type, hash parameters, password, and weight (for load balancing).
Table 4-1 lists the service group numbers and describes the services supported by a WCCP-enabled router.
Table 4-1 WCCP Service Groups
0
Web cache
60
FTP
70
HTTPS
80
HTTP, RTSP
81
MMST
82
MMSU
90-97
Dynamic or user-configurable
98
Custom
99
Reverse proxy
Note
A WCCP-enabled Content Engine supports various Internet protocols depending on the style of the request URL. If the WCCP-enabled Content Engine receives a server-style URL, only HTTP and RTSP protocols are supported (if the RTSP user agent criteria is met). If the WCCP-enabled Content Engine receives a proxy-style URL, the HTTP, HTTPS, FTP, and RTSP protocols are supported, as long as the respective proxy services are configured on the Content Engine. Proxy-style request URLs include the protocol and host name, whereas server-style request URLs do not. The RTSP protocol is supported for both server-style and proxy-style requests.
For proxy-style requests, the Content Engine supports up to eight incoming ports each for FTP, HTTPS, HTTP, MMS, and RTSP proxy modes. The incoming proxy ports can be the same ports that are used by transparent mode services. The incoming proxy ports can be changed without stopping any WCCP services running on the Content Engine or on other Content Engines in the Content Engine farm.
The Content Engine WCCP implementation currently allows global settings that apply to all WCCP services, such as healing parameters, slow start, and others. The multiple service model does not change that, and the settings in question remain global for the whole WCCP system. (See the "Configuring WCCP General Settings for the Content Engine" section.)
About Dynamic WCCP Redirection Services
You can configure the Content Engines to handle up to eight user-configurable or dynamic WCCP redirection services (service group numbers 90 to 97) on a Content Engine, provided that the services are also configured on the router.
With 8 dynamic services using a maximum number of 8 ports each, the maximum number of ports that can be specified for transparent redirection is 64. In Figure 4-4, the two Content Engines on the left handle only HTTP traffic through port 80 and are defined as members of service group 90. The two Content Engines on the right handle only Microsoft Media Server (MMS) requests and are defined as members of service group 91.
Figure 4-4 WCCP Service Group Feature
About WCCP Service for HTTPS
WCCP service for HTTPS traffic (service number 70) instructs the corresponding router to intercept port 443 TCP traffic (port 443 is the default port) and forward it to the Content Engine. This service has a special filtering feature that a normal WCCP service does not have; it uses an accept list to selectively redirect traffic to an application instead of redirecting all traffic to related applications. The accept list is a list of destination IP addresses. When the destination server's IP address in a client request matches any of the destination IP addresses in the list, WCCP redirects HTTPS traffic to the proper listening application. All other traffic is redirected to the corresponding router (normal bypass behavior). If bypass lists are configured to permit traffic from specified sources to bypass the Content Engine, traffic is not intercepted but passes directly to the origin server. If an address is present in both the accept list and bypass list, the Content Engine can return traffic to the WCCP-enabled router or switch and inform the router or switch to forward the packets as if the Content Engine were not present.
For HTTPS filtering feature to work, ensure that the Accept all HTTPS traffic check box (Request Routing > WCCP > General Settings) in the Content Distribution Manager GUI is checked so that all HTTPS traffic will be intercepted by the Content Engine. The Content Engine can negotiate an SSL connection with the client and serve HTTPS requests if the corresponding destination HTTPS server is configured on the Content Engine. Otherwise, HTTPS traffic is tunneled through the Content Engine (Content Engine passes traffic from client to server without modifying anything, except for filtering). When the SmartFilter software or Websense filtering server is enabled on the Content Engine, the Content Engine will send URLs corresponding to tunneled HTTPS traffic to the filtering server. Filtering servers can decide to block or pass the traffic. If traffic needs to be blocked, the Content Engine closest to the connection with the client and the request is not served.
About WCCP Custom Web Cache Service
Custom web cache service (service number 98) causes the Content Engine to establish WCCP Version 2 redirection services automatically with a Cisco router on a user-specified port number. The Content Engine then performs transparent web caching for all HTTP requests over that port while port 80 transparent web caching continues without interruption. For custom web caching, service 98 must be enabled on the routers. WCCP Version 1 does not support custom web caching.
Transparent caching on ports other than port 80 can be performed by the Content Engine when WCCP is not enabled or when client browsers have previously been configured to use a legacy proxy server.
Configuring WCCP General Settings for the Content Engine
To use WCCP, the Content Engine must be properly configured. Use the following configuration guidelines to help you configure the Content Engine for edge interception using a WCCP-enabled router:
•
•
•
•
Note
To configure general WCCP settings for the Content Engine, follow these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
Both of the WCCP versions allow transparent caching of web content. It is not necessary to disable WCCP Version 1 before enabling WCCP Version 2, or to disable WCCP Version 2 before enabling WCCP Version 1. Be sure the routers used in the WCCP environment are running a software version that supports the WCCP version configured on the Content Engine.
Step 6
Note
Step 7
This configuration works with WCCP Version 2 only. This feature also has a slow start mechanism which enables a Content Engine to manage an amount of data that is appropriate for its capacity.
Step 8
Step 9
Step 10
Step 11
Step 12
About Client IP Spoofing
In transparent caching, when the Content Engine contacts the origin web server, it uses the Content Engine's own IP address instead of the client's IP address, on behalf of which the Content Engine is making the request. With IP spoofing, the transparent redirection process enables the Content Engine to send out the client's IP address for authentication purposes on origin web servers.
When the Content Engine is performing normal WCCP caching without IP spoofing, the Content Engine connects the origin servers using its own IP address. Routers identify the requests as coming from the Content Engine using its own source IP address in the request and forwards the requests out onto the WAN. The router forwards requests coming from the clients on the LAN to the Content Engine.
When configured for IP spoofing, the Content Engine connects to the origin server using the client IP address instead of its own IP address. At this point, the router cannot identify requests coming from the Content Engine because the source IP address of the request is not that of Content Engine. To prevent these Content Engine requests from being returned to the Content Engine unresolved, the ip wccp redirect exclude in command must be applied to the WCCP-enabled router interface to which the Content Engine is connecting.
The ip wccp redirect exclude in command prevents the WCCP-enabled router from intercepting any requests coming in on this interface. To allow interception of client requests, the ip wccp redirect out command must be configured on those interfaces connected to the client and the WAN.
About WCCP Slow Start
Within a cluster of Content Engines, TCP connections are redirected to other Content Engines as units are added or removed. A Content Engine can be overloaded if it is reassigned new traffic too quickly or introduced abruptly into a fat pipe.
WCCP slow start performs the following tasks to prevent a Content Engine from being overwhelmed when it comes online or is reassigned new traffic:
•
•
•
Slow start is applicable only in the following cases:
•
•
In all other cases slow start is not necessary and all the Content Engines can be assigned their share of traffic right away.
About WCCP Clean Shutdown
To prevent broken TCP connections, the Content Engine performs a clean shutdown of WCCP after a reload or WCCP version change. The Content Engine does not reboot until either all connections have been serviced or the configured maximum wait interval has elapsed.
During a clean shutdown, the Content Engine continues to service the flows it is handling but starts to bypass new flows. When the number of flows goes down to zero, the Content Engine takes itself out of the cluster by having its buckets reassigned to other Content Engines by the lead Content Engine. TCP connections can still be broken if the Content Engine crashes or is rebooted without WCCP being cleanly shut down. The clean shutdown can be aborted while in progress.
Configuring WCCP Service Settings for the Content Engine
To configure WCCP services, you need to configure four sets of settings:
•
•
•
•
To configure WCCP service settings for the Content Engine, follow these steps:
Step 1
Step 2
Step 3
Note
Step 4
You can configure a maximum of seventeen services. If seventeen services have already been defined, the icon is not visible in the taskbar.
Note
Step 5
a.
b.
Only configured router lists are displayed in the drop-down list. Router lists can be configured, modified, and viewed by following the links in the Creating New WCCP Service window. For more information about router lists, see these sections:
•
•
Step 6
a.
b.
c.
d.
e.
Step 7
a.
–
–
–
–
–
b.
c.
d.
Step 8
a.
b.
c.
Passwords must not exceed 8 characters in length. Reenter the password in the Confirm Password field.
d.
e.
Step 9
Step 10
Step 11
Step 12
About Load Balancing
WCCP Version 2 has the capability to adjust the load being offered to individual Content Engines to provide more effective use of the resources available and at the same time help to ensure high quality of service to clients. Load balancing allows the set of hash buckets assigned to a Content Engine to be adjusted so that the load can be shifted from an overwhelmed Content Engine to other Content Engines that have available capacity.
With the hash assignment method, the hash parameters specify how traffic should be load balanced among the different service groups. Specifically, hashing maps items from one item set to another, such as mapping destination IP addresses or destination ports to different Content Engines in a service group from the WCCP-enabled router for load-balancing purposes. Only one load-balancing method can be used per Content Engine farm.
Creating WCCP Router Lists
You can create up to 8 different router lists with up to 32 IP addresses per list for use with WCCP Version 2 services. For example, you can specify one router list for WCCP Version 2 web cache service and another router list for reverse proxy at the same time without needing to reconfigure groups of routers or Content Engines. A router list must be contain at least one IP address.
To create WCCP router lists, follow these steps:
Step 1
Step 2
Step 3
All IP addresses added must be unique within the router list. Otherwise, an error message is displayed on submit.
Step 4
The window refreshes and the addresses are listed in numerical order. The order might not match the order in which IP addresses were entered. IP addresses will be displayed in red until settings are saved.
Step 5
Modifying WCCP Router Lists for the Content Engine
To add or delete an IP address from a router list or to delete a router list, follow these steps:
Step 1
Step 2
Step 3
Step 4
Note
Step 5
Step 6
a.
b.
Step 7
a.
Note
b.
Viewing WCCP Router Lists for the Content Engine
To view all router lists configured for a WCCP Version 2 dynamic service, follow these steps:
Step 1
The List Number column displays all configured router list numbers. The Router IP Addresses column displays a list of IP addresses that were added to the router list. From this window you can perform the following actions:
•
•
•
Step 2
Step 3
Step 4
Assigning Unique Router Lists to Content Engines in a Device Group
When a device group contains devices that are in different branch locations, the devices cannot share the same router lists. In ACNS 5.4 software, you can configure router lists for all devices in a device group from a single window in the Content Distribution Manager GUI Device Groups configuration area. Having a single window from which you can assign unique router lists to Content Engines within a device group eliminates the tedious process of visiting separate windows to configure router lists for each device that is in a different location.
To work with router lists for devices in a device group, follow these steps:
Step 1
Step 2
Step 3
Step 4
•
•
The Modifying WCCP Router List window appears. (See Figure 4-5.)
Figure 4-5 Modifying WCCP Router List Window
Step 5
Note
Step 6
Step 7
Configuring WCCP Port Lists for the Content Engine
With eight custom services that use a maximum number of eight ports each, the maximum number of ports that can be specified for transparent redirection is 64.
The legacy custom web cache and reverse proxy services (service numbers 98 and 99) can be configured with only one port each. If only one legacy service is configured, the total maximum number of transparent redirection ports is 57. If both legacy services are configured, the maximum port total is 50.
All ports receiving HTTP that are configured as members of the same WCCP service share the following characteristics:
•
•
With Content Engines in a farm, the following restrictions apply:
•
•
•
To configure WCCP port lists for the Content Engine, follow these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
Alternatively, click the Edit WCCP Service Setting icon next to an existing WCCP service for which you want to configure router lists. The Modifying WCCP Service window appears.
Step 6
Step 7
Step 8
Each port number added must be unique among all configured port lists. Otherwise, an error message is displayed on submit.
For a port list, port numbers need not necessarily be entered in successive fields under the Ports column. Blank fields in between will be removed on submit and all added port numbers will be reordered and displayed in ascending order when you visit the window the next time.
Step 9
Modifying WCCP Port Lists for the Content Engine
To modify a port list, follow these steps:
Step 1
Step 2
a.
b.
Step 3
a.
b.
Configuring WCCP Service Masks for the Content Engine
You can configure up to 16 WCCP service masks. For FTP service, only IP masks can be configured, so port mask fields are disabled for entry.
Bit masks are specified as hexadecimal numbers. All the specified bit masks together cannot have more than 7 bits set. For example, a correct way of using three masks is OxF (4 bits), Ox1 (1 bit), and Ox3 (2 bits) for a total of 7 bits. In this case, you cannot configure any additional mask other than 0x0. Otherwise, an error message is displayed.
An example of using four masks could be 0xA (2 bits), 0x7 (3 bits), 0x8 (1 bit), 0x1 (1 bit) for a total of 7 bits.
To configure WCCP service masks for a WCCP service configured on the Content Engine, follow these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
Alternatively, click the Edit WCCP Service Setting icon next to an existing WCCP service for which you want to configure router lists. The Modifying WCCP Service window appears.
Step 6
Step 7
Step 8
Step 9
Step 10
Step 11
Step 12
Step 13
Modifying WCCP Service Masks for the Content Engine
To modify a service mask for a WCCP service configured on the Content Engine, follow these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
Alternatively, click the Edit WCCP Service Setting icon next to an existing WCCP service for which you want to configure router lists. The Modifying WCCP Service window appears.
Step 6
Step 7
The Edit Mask button toggles with the Create Mask button if a service mask has already been configured for a WCCP service.
Step 8
Step 9
Step 10
Step 11
Step 12
Step 13
To delete a service mask, follow these steps:
Step 1
Step 2
Step 3
Viewing WCCP Service Masks for the Content Engine
To view all masks configured for a WCCP service, follow these steps:
Step 1
Step 2
Step 3
Alternatively, click the Edit WCCP Service Mask Setting icon next to an existing WCCP service mask for which you want to change the mask settings. The Modifying WCCP Service Mask window appears.
Configuring WCCP Transparent Routing Bypass Options
One of the fundamental principles of transparent network request redirection is that the Content Engine must remain transparent to the end user at all times. A transparent caching solution in an ACNS network environment must not introduce any possible failure conditions or side effects in the network.
The Cisco ACNS transparent caching solution uses a WCCP-enabled router and various advanced techniques to ensure that the Content Engine remains transparent, even if web browsers are nonoperational or web servers are not HTTP-compliant.
If a Content Engine becomes overwhelmed with traffic, it can use the overload bypass feature to reroute the overload traffic. When the Content Engine is overloaded and the bypass load command is enabled, the Content Engine refuses additional requests and forwards them to the origin servers. If the load remains too high, more traffic is bypassed to the servers, and so on until the Content Engine can handle the load. The time interval between one bucket being bypassed and the next is set by the out-interval option. The default is 4 seconds. (See Figure 4-6.)
Figure 4-6 Overload Bypass
When the first bucket bypass occurs, a set interval must elapse before the Content Engine begins to again service the bypassed buckets. The duration of this interval is set by the time-interval option. The default is 10 minutes.
When the Content Engine begins to service the bypassed traffic again, it begins with a single bypassed bucket. If the load is serviceable, it picks up another bypassed bucket, and so on. The time interval between picking up one bucket and the next is set by the in-interval option. The default is 60 seconds.
Configuring Authentication Traffic Bypass
Because of IP authentication, some websites do not allow the Content Engine to connect directly on behalf of the client. In order to preserve cache transparency and avoid disruption of service, the Content Engine can use authentication traffic bypass to automatically generate a dynamic access list for the selected client/server pairs. Authentication bypass triggers are also propagated upstream and downstream in the case of hierarchical caching.
Note
Configuring WCCP Bypass Settings
To configure WCCP bypass settings, follow these steps:
Step 1
Step 2
Step 3
Step 4
Figure 4-7 WCCP Bypass Settings Window
Step 5
Step 6
Note
Step 7
Step 8
Step 9
Step 10
Step 11
When the Content Engine is overwhelmed with traffic and the bypass option is enabled, it bypasses traffic one bucket at a time until it is no longer overloaded.
Note
Step 12
Step 13
Once the time interval allotted to bypass mode has elapsed, the Content Engine begins to pick up bypassed traffic one bucket at a time.
Step 14
A "Click Submit to Save" message appears in red next to the current settings line when there are pending changes to be saved after you have applied default or device group settings. To revert to the previously configured window settings, click Reset. The Reset button appears only when you have applied default or group settings to change the current device settings but the settings have not yet been submitted.
Creating WCCP Bypass List Entries
The Content Engine can use authentication bypass to generate a dynamic access list for client/server pairs. To generate these lists with the Content Distribution Manager GUI, follow these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
To create a WCCP bypass list entry from the CLI, use the following global configuration command:
bypass static {clientip [serverip | any-server] | any-client serverip}
Note
Enabling WCCP on the Router
To enable an interface to redirect web traffic to the Content Engine using WCCP Version 2, perform the following tasks beginning in global configuration mode on the router:
Basic WCCP Router Configurations for Web Caching
When WCCP support is enabled on the router and on the Content Engines, the devices can communicate and deliver the services for which they are configured. To suspend these services, you can disable WCCP support on the router rather than powering off or otherwise disabling individual Content Engines. (For instance, use the no ip wccp router command to disable WCCP support on the router.)
Many WCCP Version 2 services also require a configuration of the appropriate wccp global configuration command. Refer to the Cisco ACNS Software Command Reference, Release 5.x publication and ACNS software release notes for more details.
Web Cache Service Configuration with Clients and Content Engine on the Same Subnet
In this scenario, the Content Engine and the requesting clients are on the same subnet, as shown in Figure 4-8.
A router running WCCP Version 2 transparently redirects client HTTP traffic bound for router interface s0/0 to the Content Engine. The web cache service redirects HTTP traffic on port 80 only.
Figure 4-8 Web Cache Service with Clients and Content Engine on Same Subnet
Configuring the Content Engine for Web Cache Service—Clients and Content Engine on the Same Subnet
To configure the Content Engine for web cache service, perform the following steps while logged in to the ACNS software in global configuration mode:
Configuring the Router for Web Cache Service—Clients and Content Engine on the Same Subnet
To configure the router for web cache service, perform the following steps while logged in to the router in global configuration mode:
Configuration Examples—Web Cache Service with Clients and Content Engine on the Same Subnet
This example shows a Content Engine and router configured for web cache service with the topology illustrated in Figure 4-8:
Content Engine
hostname Content_engine_4.2!clock timezone pst -8 0!ip domain-name cu.net!interface FastEthernet 0ip address 10.10.20.10 255.255.255.0no autosensebandwidth 100full-duplexexitinterface FastEthernet 1shutdownexit!ip default-gateway 10.10.20.1!ip name-server 10.10.10.100!!!wccp router-list 1 10.10.20.1wccp web-cache router-list-num 1wccp version 2!!!. . .WCCP-Enabled Router
Building configuration...Current configuration:!version 12.0!hostname WCCP-Router!!ip wccp web-cache!interface Ethernet0ip address 10.10.10.1 255.255.255.0ip route-cache same-interface!interface Serial0ip address 192.168.1.2 255.255.255.252no ip directed-broadcastno ip mroute-cacheip wccp web-cache redirect out!endWeb Cache Service Configuration with Clients and Content Engine on Different Subnets
In this scenario, the Content Engine and the requesting clients are on different subnets, as shown in Figure 4-9.
A router running WCCP Version 2 transparently redirects client HTTP traffic bound for router interface s0/0 to the Content Engine. The web cache service redirects HTTP traffic on port 80 only.
Figure 4-9 Web Cache Service with Content Engine and Clients on Different Subnets
Configuring the Content Engine for Web Cache Service—Clients and Content Engine on Different Subnets
To configure the Content Engine for web cache service, perform the following steps while logged in to the ACNS software in global configuration mode:
Configuring the Router for Web Cache Service—Clients and Content Engine on Different Subnets
To configure the router for web cache service, perform the following steps while logged in to the router in global configuration mode:
Configuration Examples—Web Cache Service with Clients and Content Engine on Different Subnets
This example shows a Content Engine and router configured for web cache service with the topology illustrated in Figure 4-9:
Content Engine Configuration
. . .hostname Content_engine_4.2!clock timezone pst -8 0!ip domain-name cisco.com!exec-timeout 20!interface FastEthernet 0ip address 10.10.20.10 255.255.255.0no autosensebandwidth 100full-duplexexitinterface FastEthernet 1shutdownexit!ip default-gateway 10.10.20.1!ip name-server 10.10.10.100!!wccp router-list 1 10.10.20.1wccp web-cache router-list-num 1wccp version 2!!!...WCCP-Enabled Router Configuration
Building configuration...Current configuration:!hostname WCCP-Router!!ip subnet-zero!ip wccp web-cache!interface Ethernet0ip address 10.10.10.1 255.255.255.0!interface Ethernet1ip address 10.10.20.1 255.255.255.0!interface Serial0ip address 192.168.1.2 255.255.255.252no ip directed-broadcastno ip mroute-cacheip wccp web-cache redirect out!endConfiguring Direct Proxy Routing
In a proxy configuration, the end user's browser must be configured with the IP address of the Content Engine; therefore, a proxy-style request arrives at the Content Engine after having been specifically routed to the Content Engine by the client.
Using a Proxy Autoconfiguration File Server
Cisco ACNS 5.4 software supports dynamic proxy autoconfiguration (PAC). This feature is a form of direct proxy routing that allows a browser to dynamically obtain proxy IP address and port configuration information from a special file called a PAC file template. The PAC feature is supported by the Microsoft Internet Explorer and Netscape Communicator browsers. Browsers must be manually configured for automatic proxy configuration.
The PAC feature can be configured through the Content Distribution Manager (see the "Registering a PAC File Template and Assigning Coverage Zone Information" section) and requires at least one Content Engine that is enabled as a PAC file server (see the "Configuring a Content Engine as a PAC File Server" section). The PAC file server dynamically chooses the proxy Content Engine that is closest to the client requesting the content, based on instructions contained in the PAC file template. (See the "Creating PAC File Templates" section.)
Dynamic PAC routing supports the following features:
•
•
•
•
Note
Creating PAC File Templates
The system administrator creates a PAC file template on a workstation and places it where the Content Distribution Manager can access the URL. The administrator then registers the PAC file template URL in the Content Distribution Manager GUI and assigns a coverage zone file to it.
The template is a complete PAC file except that the administrator inserts predefined macros where the PAC file server is to generate and insert dynamic information. The nearest proxies are determined by the metrics contained in the coverage zone file.
The Content Distribution Manager acquires the template and distributes it to all PAC file servers. For each Content Engine that is a PAC file server, the administrator must also configure the ports used for PAC file requests. Typically, port 80 is used.
The port can be configured in the CLI using the http proxy incoming port global configuration command. (There is no default.) Alternatively, you can use the Content Distribution Manager to configure the incoming proxy ports in the HTTP Connection Settings window (Devices > Devices > Applications > Web > HTTP > HTTP Connections).
The administrator then gives the PAC file URLs, including the desired servers, to end users. Users must configure their browsers to use the URL. When the browser first comes up, it requests the URL. The PAC file server dynamically replaces any ACNS software macros with the current information from the local coverage zone, if present, and from the default coverage zone based on the source IP address of the requester. The completed PAC file is returned to the requesting client.
When end users are behind a NAT device and the network administrator wants to direct end users to different proxies based on their IP address, then there must also be a PAC file server behind the NAT device for those users to use. The reason for this is because a PAC file server that is not behind the NAT would receive PAC requests for users behind the NAT with the source IP address of the NAT device rather than the source IP address of the end user.
Three macros are defined as follows:
•
•
•
where n can be a value of 1 to 5.
For CE_NAME_n, the PAC file server substitutes the name of the nth closest proxy. For CE_IPADDR_n, the PAC file server substitutes the IP address of the nth closest proxy. If there is no nth closest proxy, the PAC file server substitutes the empty string "" in place of the macro. The PAC template creator must keep this in mind when creating the PAC file templates.
For the NEAREST_PROXIES_n macro, the PAC file server substitutes the string "PROXY <ip address>;" for up to n closest proxies where <ip address> is the IP address of the proxy. If the template writer includes a port number with the macro, then this port number is appended to each proxy IP address.
For example, NEAREST_PROXIES_2:8080 might expand into a string such as "PROXY 192.30.120.12:8080; PROXY 168.10.10.1:8080;". If n is larger than the number of available proxies, then the PAC file server substitutes fewer than n proxies. For example, NEAREST_PROXIES_2 might expand into "PROXY 192.30.120.12;" or even just "" when there are no nearest proxies. Again, the PAC template creator must keep this in mind when creating the PAC file templates.
PAC File Example
Assume that CE1 serves subnet 10.1.1.0/24 and CE2 serves subnet 10.1.2.0/24. All clients on subnet 10.1.1.0/24 are directed to CE1 as the closest proxy, and all clients on subnet 10.1.2.0/24 are directed to to CE2 as the closest proxy.
The PAC file template would look like this:
Function FindProxyForURL(url, host){// handle plain host namesif (isPlainHostName(host) {return "DIRECT";// handle exception listif (myIpAddress() == "10.1.1.2") {return "DIRECT";}// handle special domain listif (shExpMatch(host, "specialdomain.com")) {return "PROXY specialDomainProxy.foo.com";}// handle direct domain listif (shExpMatch(host, "directdomain.com")) {return "DIRECT";}// closest proxies + defaultsp1 = CE_NAME_1;p2 = CE_NAME_2;if (p1 != "") {p1 = "PROXY " + p1 + ".proxy.foo.com:8080; ";}if (p2 != "") {p2 = "PROXY " + p2 + ".proxy.foo.com:8080; ";}return p1 + p2 + "DIRECT";}The coverage zone file looks like this:
<?xml version="1.0"?><CDNNetwork><!--No coverage zone file from CDM is available--><!--Default coverage zones, if any, follow this comment--><coverageZone><network>10.1.1.0/24</network><CE>CE1</CE><metric>20</metric></coverageZone><coverageZone><network>10.1.2.0/24</network><CE>CE2</CE><metric>20</metric></coverageZone></CDNNetwork>For a client source IP address of 10.1.1.20, the generated proxy.pac file would look like this:
function FindProxyForURL(url, host){// handle plain host namesif (isPlainHostName(host) {return "DIRECT";// handle exception listif (myIpAddress() == "10.1.1.2") {return "DIRECT";}// handle special domain listif (shExpMatch(host, "specialdomain.com")) {return "PROXY specialDomainProxy.foo.com";}// handle direct domain listif (shExpMatch(host, "directdomain.com")) {return "DIRECT";}// closest proxies + defaultsp1 = "CE1";p2 = "CE2";if (p1 != "") {p1 = "PROXY " + p1 + ".proxy.foo.com:8080; ";}if (p2 != "") {p2 = "PROXY " + p2 + ".proxy.foo.com:8080; ";}return p1 + p2 + "DIRECT";}Registering a PAC File Template and Assigning Coverage Zone Information
To register a PAC file template and assign coverage zone information, follow these steps:
Step 1
Step 2
Step 3
•
•
Figure 4-10 Registering New PAC File Window—Import Method
(For descriptions of the fields associated with the upload method, see Table 4-8. For descriptions of the fields associated with the import method, see Table 4-9.)
Step 4
Configuring a Content Engine as a PAC File Server
PAC file servers look for changes in their PAC file server status, coverage zone information, general PAC information, and PAC template information. If necessary, a PAC file server updates its information so that it can correctly serve dynamic PAC files. It also installs the PAC file templates and coverage zone files in a known location. The administrator can configure any number of Content Engines as PAC file servers.
To configure a Content Engine as a PAC file server, follow these steps:
Step 1
Step 2
Step 3
Step 4
Figure 4-11 Device Activation for Content Engine Window
Step 5
Step 6
Configuring Client Proxy Autoconfiguration Settings
ACNS 5.x software supports proxy automatic configuration files (.pac files). A browser obtains proxy IP address and port configuration information from the proxy automatic configuration file when the browser's autoconfiguration URL field is configured with the Content Engine IP address, incoming port number, file directory, and .pac filename.
Note
The Microsoft Internet Explorer and Netscape browsers support the proxy autoconfiguration feature. The browser must be manually configured for automatic proxy configuration.
This example demonstrates the URL syntax to enter in the proxy automatic configuration URL field of the browser:
http://ContentEngine-IPaddress:portnumber/proxy.pac
Note
To configure proxy autoconfiguration, follow these steps:
Step 1
Step 2
Step 3
Step 4
Figure 4-12 Client Proxy Auto Configuration Settings Window
Step 5
Step 6
Step 7
Step 8
Step 9
Step 10
Step 11
Configuring Content Request Routing Using a Content Router or Routing Content Engine
This routing method requires a Cisco Content Router or routing Content Engine. The Content Router or routing Content Engine uses HTTP or RTSP redirection to route requests to the Content Engine which the Content Router or routing Content Engine determines is best suited to deliver the desired content to the client. This determination is based on the requested FQDN, the client's IP address, and the responsiveness of a Content Engine. The Content Router compares the source IP address of the client end system against a table of address ranges assigned to Content Engines, known as the coverage zone. The Content Router or routing Content Engine then sends the client a redirect response pointing to the selected Content Engine. Subsequently, the Content Engine can be configured as a proxy caching server to serve content, or it can be configured to distribute pre-positioned content.
To configure the Content Engine for proxy caching, see Chapter 8, "Configuring Caching Services." To configure your network for pre-positioned content distribution, see Chapter 5, "Configuring the ACNS Network for Content Distribution."
Note
Content Router request routing works in the following manner:
1.
2.
3.
4.
5.
6.
7.
8.
For Content Router request routing to work properly, the following information must be configured:
•
The Content Router chooses the Content Engine closest to the client end system based on the coverage zone. (See the next section, "Coverage Zones and Coverage Zone Files.")
•
A Content Engine can only serve content for websites to which the Content Engine is assigned. Content Engines are assigned to websites through channels. (See the "Adding and Removing Content Engines from Channels" section on page 5-16.)
•
DNS entries for all fully qualified domain names (FQDNs) must be delegated to the Content Router. In the DNS server's zone database file, you must enter a name server (NS) record that delegates the FQDN to the Content Router, and then restart your DNS server.
In the following example, the FQDN www.cisco.com has been delegated to the Content Router named bali-cr:
www.cisco.com IN NS bali-cr
When you have configured an NS record on your DNS server, all requests for the FQDN and any of its subdomains are sent to the Content Router rather than to existing DNS servers. The Content Router automatically resolves DNS queries for the FQDN.
Coverage Zones and Coverage Zone Files
A coverage zone is a mapping of end system IP addresses to Content Engines. The Content Router uses the Content Engine IP addresses to create a static redirection table that maps end system IP addresses to Content Engines and provides information on the proximity of end systems to Content Engines. When content is requested by an end user, the Content Router checks the end user's IP address to find the coverage zone that contains that IP address. The Content Router then selects the Content Engine that is serving this coverage zone. If a specific IP address is in multiple coverage zones, then the one with the more specific range is selected. For example, the IP address 172.1.1.1 uses the data for coverage zone 172.1.0.0/16 instead of 172.0.0.0/8. If there is no match found in the coverage zone data, then the request is not redirected. The Content Router sends back an error response, and the content is not available.
A coverage zone can be associated with one or more than one Content Engine: each Content Engine can have its own unique coverage zone, or Content Engines can be associated with more than one coverage zone and have overlapping coverage zones. In ACNS 5.x software, coverage zones cannot be associated with Content Distribution Managers or Content Routers.
If a coverage zone is served by multiple Content Engines, the Content Engine with the lowest metric value is put in the routing table. The metric value (see Table 4-10) indicates the proximity of the Content Engine to the end user. When there are multiple Content Engines in a coverage zone that are on the same subnet and have the same metric value, the Content Router performs the redirect to the client in a round-robin fashion.
When a Content Engine is registered to the Content Distribution Manager, it is assigned a default coverage zone (by default) that is determined by the IP address assigned to the Content Engine and its subnet mask. The default coverage zone configuration can be unassigned and network administrators can create and assign their own custom coverage zones by defining the coverage zone in a coverage zone file.
A coverage zone file is an XML file used to specify a user-defined coverage zone. Each coverage zone entry in the file specifies the IP address range, the name of the Content Engine serving this subnet, metric value, and one or more optional agent fields, if the entry is designated for specific routing Content Engines. In addition to the coverage zone information, two optional elements are created for documentation purposes: a revision value to specify the version of the coverage zone file and a customer name.
Coverage zone files can be created using any ASCII text editing tool. You can use a single coverage zone text-format file to define all the coverage zones for your ACNS network.
Table 4-10 defines the coverage zone file elements.
Registering Coverage Zone Files
The system administrator places a coverage zone file where the Content Distribution Manager or individual devices can access the URL. The administrator then registers the coverage zone file URL in the Content Distribution Manager GUI. Coverage zone files can be applied globally to the entire ACNS network, or locally to a specific Content Router or routing Content Engine in the ACNS network. If a coverage zone file is made global, then it is read and parsed by each Content Router or routing Content Engine that does not have a coverage zone file assigned. If the coverage zone is specified in an individual Content Router or routing Content Engine configuration, it is only applied to that particular Content Router or routing Content Engine.
Choosing the Coverage Zone
You have the choice of using two types of coverage zones:
•
•
A default coverage zone consists of all the Content Engines that reside in the same local network segment, or subnet. The Content Distribution Manager GUI provides a check box to specify whether the default coverage zone is to be used.
A user-defined coverage zone consists of all the Content Engines that are specified in a coverage zone file. This file defines the network segments to be covered in the routing process. The coverage zone file is registered with the Content Distribution Manager and then applied to a Content Router or routing Content Engine for routing definitions.
Note
Using the Default Coverage Zone
To use the default coverage zone, follow these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Registering and Applying a User-Defined Coverage Zone
To apply a custom coverage zone to a Content Router or routing Content Engine, you first need to register a coverage zone file URL in the Content Distribution Manager GUI. After you have registered the coverage zone file URL with the Content Distribution Manager, you can apply the coverage zone file in one of two ways:
•
•
Note
To register a coverage zone file, follow these steps:
Step 1
Step 2
Step 3
Step 4
•
•
When you choose a method, the window refreshes and displays the configuration fields that are associated with the method that you chose. (For descriptions of the fields associated with the upload method, see Table 4-11. For descriptions of the fields associated with the import method, see Table 4-12.)
Step 5
After you have registered the coverage zone file URL with the Content Distribution Manager, you can use this file as your global routing configuration.
To set a global coverage zone file, follow these steps:
Step 1
Step 2
Figure 4-13 Set Global Coverage Zone File Window
Step 3
Step 4
Step 5
Step 6
To apply a coverage zone file to an individual Content Router to be used locally, follow these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Coverage Zone File Examples
The following sections show different coverage zone file examples in four different scenarios.
Scenario 1: No Network Address Translation Firewall
This is the simplest scenario. In this example, enterprise ent1.com is in the public address space with two Content Engines in different subnets, and each Content Engine backs up the other. There is no Network Address Translation (NAT) firewall. Both Content Engines use the default coverage zone. This configuration creates entry 3 and entry 4 of the coverage zone file (see the example) to be added by the Content Router.
To define a backup Content Engine in the coverage zone file, map the subnet to its backup Content Engine, and assign a metric value greater than 20 (entry 1 and entry 2).
Figure 4-14 Coverage Zone Scenario 1: No NAT
The following file is an example of a coverage zone file for scenario 1. (See Figure 4-14.)
<?xml version="1.0" ?><CDNNetwork><revision>1.0</revision><customerName>ent.com</customerName><!-- entry 1 --><coverageZone><network>172.29.248.0/24</network><CE>ent_sanfrancisco</CE><metric>20</metric></coverageZone><!-- entry 2: backup CE for the San Francisco office --><coverageZone><network >172.29.249.0/24</network><CE>ent_sanjose</CE><metric>20</metric></coverageZone><!-- entry 3 --><coverageZone><network>172.29.248.0/24</network><CE>ent_sanjose</CE><metric>10</metric></coverageZone><!-- entry 4 --><coverageZone><network>172.29.249.0/24</network><CE>ent_sanfrancisco</CE><metric>10</metric></coverageZone></CDNNetwork>Scenario 2: Content Engine Behind a NAT Firewall
Enterprise ent2.com is behind a NAT firewall with one Content Engine, and the Content Router is on the public Internet. All content requests from this public IP address are served by the Content Engine (ent2_sanfrancisco) behind the firewall. Because all content requests from the end systems behind the NAT have the same public IP address, there is one entry to map the public IP address to the Content Engine ent2_sanfrancisco in the coverage zone file. The Set Default Coverage Zone File check box should be unchecked in the General Configuration section in the Modifying Content Engine window (see Figure 13-3) because the subnet 10.1.1.0/24 is private and is not known to the Content Router.
Figure 4-15 Coverage Zone Scenario 2: Behind a NAT Firewall
The following coverage zone file applies to Figure 4-15.
<?xml version="1.0" ?><!-- CZ for ent2.com --><CDNNetwork><coverageZone><network>171.29.250.1/32</network><CE>ent2_sanfrancisco</CE><metric> 10 </metric></coverageZone></CDNNetwork>Scenario 3: Multiple Content Engines Behind a NAT Firewall
In this scenario, enterprise ent3.com is behind a NAT firewall with multiple subnets, and each subnet has one Content Engine. In this case, there must be at least one routing Content Engine behind the NAT firewall. See the "Modifying Content Engine Properties" section on page 13-9 for more information on how to reconfigure a Content Engine to act as a routing Content Engine. A routing Content Engine performs the routing process and is able to do content request routing. The Content Router redirects all content requests from behind the firewall to the routing Content Engine, and this routing Content Engine then performs the second redirect.
In this example, ent3_sanjose1 is the routing Content Engine. A coverage zone entry (CZ entry 1) must be defined to map all content requests from behind the NAT firewall to ent3_sanjose1. Coverage zone entries for routing Content Engine ent3_sanjose1 must also be defined to map all requests from 10.1.1.0/24 to itself (CZ entry 2) and requests from 10.1.2.0/24 to ent3_sanjose2 (CZ entry 3).
Figure 4-16 Scenario 3: Multiple Content Engines Behind a NAT Firewall
The following coverage zone file applies to Figure 4-16.
<?xml version="1.0" ?><!-- CZ for ent3.com --><CDNNetwork><customerName>ent3.com</customerName><!-- CZ entry 1 --><coverageZone><network>171.29.1.1/32</network><CE>ent3_sanjose1</CE><metric> 10 </metric></coverageZone><!-- CZ for routing CE --><!-- CZ entry 2 --><coverageZone><network>10.1.1.0/24</network><CE>ent3_sanjose1</CE><metric> 10 </metric><agent> ent3_sanjose1</agent></coverageZone><!-- CZ entry 3 --><coverageZone><network>10.1.2.0/24</network><CE>ent3_sanjose2</CE><metric> 10 </metric><agent>ent3_sanjose1</agent></coverageZone>Scenario 4: NAT Firewall with Multiple IP Addresses
Enterprise ent4.com is behind a NAT firewall with multiple public IP addresses. All content requests from behind the NAT firewall have one of these public IP addresses. Therefore, there must be one coverage zone data entry for each of these public IP addresses to map these IP addresses to the Content Engine behind the NAT firewall.
Figure 4-17 Scenario 4: NAT Firewall with Multiple IP Addresses
The following coverage zone file applies to Figure 4-17.
<?xml version="1.0" ?><!-- CZ for ent4.com --><CDNNetwork><coverageZone><network>171.29.10.1/32</network><CE>ent4_sanfrancisco</CE><metric>10</metric></coverageZone><!-- CZ for ent4.com --><coverageZone><network>171.29.10.2/32</network><CE>ent4_sanfrancisco</CE><metric>10</metric></coverageZone></CDNNetwork>Configuring a Content Engine as a Routing Content Engine
You can enable routing capabilities on a Content Engine to allow this Content Engine to also redirect content requests. A routing Content Engine is required when multiple Content Engines are located behind a NAT firewall to be able to serve content requests from the clients behind the same NAT firewall. In this case, a Content Router first redirects the content requests to a routing Content Engine rather than to the Content Engine best-suited to deliver the content. The routing Content Engine then performs a second redirect to find the best-suited Content Engine to serve the content. See the "Scenario 3: Multiple Content Engines Behind a NAT Firewall" section for an example that illustrates the need for a routing Content Engine.
See the "Modifying Content Engine Properties" section on page 13-9 for information on how to configure a Content Engine to serve as a routing Content Engine.
Configuring Dynamic Content Routing Using a Content Router
In previous releases of ACNS software, Content Routers used a static coverage zone file to describe the preferred routing path between Content Engines and client end systems.
A coverage zone is a mapping of client end-system IP addresses to Content Engines. The Content Router uses the Content Engine IP addresses to create a static redirection table that maps end-system IP addresses to Content Engines and provides information on the proximity of end systems to Content Engines. When content is requested by a client, the Content Router checks the client IP address to find the coverage zone that contains that IP address. The Content Router then selects the Content Engine that serves this coverage zone.
In some ACNS network environments, Content Engine IP addresses keep changing, and coverage zones are dynamic instead of static. In such cases, the Content Router cannot create a static routing table, and it cannot successfully route the content.
When the following conditions are present, the content cannot be routed successfully by using static coverage zone tables in the Content Router:
•
•
•
•
•
•
With multiple uplinks to the Internet, requests for content from clients and Content Engines that are in the same location can go out to the Content Router with different external IP addresses. The Content Router that is using static coverage zone files cannot accommodate sharing the same IP address pool among different locations.
In the ACNS 5.3.3 software release and later releases, the Content Router can detect changes in Content Engine coverage zones and can dynamically adjust its routing tables.
Enabling Dynamic Content Routing
For each Content Router that you want to configure for dynamic content routing, you must indicate that dynamic content routing will be used over static content routing.
To configure dynamic content routing, follow these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
Changing the Content Engine Metric Value for Dynamic Content Routing in the Coverage Zone File
In ACNS 5.3.3 software and later releases, a tag has been defined in the coverage zone file that allows you to change the metric that assigns a preference to a particular Content Engine in the routing table. This optional tag is the <dynamic> tag.
When a coverage zone file containing the <dynamic> tag and elements is assigned to a Content Router, the following applications are made:
•
•
The <dynamic> tag is a standalone tag; it is not defined as a subelement of the <coverageZone> tag. The subelements <CE> and <metric> must be defined within the <dynamic> tag. Table 4-13 describes the elements of the <dynamic> tag.
Table 4-13 Coverage Zone File Elements for Dynamic Content Routing
<dynamic>
<CE>1
Content Engine name
Specifies the Content Engine for which the metric value is to be applied. The <dynamic> tag can contain the names of multiple Content Engines.
<metric>1
Number
Value indicates the proximity of the Content Engine to the end user. The lower the value, the greater the preference given to the Content Engine.
If no metric is specified, the default value of 10 is applied.
1 This element is required.
The following example shows how the <dynamic> tag can be used in a coverage zone file:
<?xml version="1.0"?> <CDNNetwork> <revision>1.0</revision><dynamic> <CE>hostname_of_ce</CE>-----------> NOTE: The tag is <CE> and not <ce>. <metric>number</metric> </dynamic></CDNNetwork>The following example shows an invalid coverage zone file where the <dynamic> tag is written as a subelement of the <coverageZone> tag:
<?xml version="1.0"?> <CDNNetwork> <revision>1.0</revision><coverageZone> <dynamic> <CE>hostname_of_ce</CE> <metric>number</metric> </dynamic> </coverageZone></CDNNetwork>The following example shows that the <dynamic> tag and the <coverageZone> tag can exist together in a coverage zone file:
<?xml version="1.0"?> <CDNNetwork> <revision>1.0</revision><coverageZone> <network>a.b.c.d/mask</network> <CE>hostname_of CE</CE> <metric>0</metric> </coverageZone><dynamic> <CE>name_of_ce</CE> <metric>number</metric> </dynamic></CDNNetwork>The following example shows that the <dynamic> tag can appear multiple times in a coverage zone file:
<?xml version="1.0"?> <CDNNetwork><revision>1.0</revision><dynamic> <CE>hostname_of_ce1</CE> <metric>number</metric> </dynamic><dynamic> <CE>hostname_of_ce2</CE> <metric>number</metric> </dynamic></CDNNetwork>The following example shows that the <dynamic> tag can contain the names of multiple Content Engines:<?xml version="1.0"?> <CDNNetwork> <revision>1.0</revision><dynamic> <CE>hostname_of_ce1</CE> <CE>hostname_of_ce2</CE> <CE>hostname_of_ce3</CE> <metric>number</metric> </dynamic></CDNNetwork>You can use a coverage zone file with the <dynamic> tag, for example, when a preference order has to be given for a set of Content Engines that are serving the same client base. The following example shows that ce1 is preferred over ce2 because the metric value for ce1 is lower than that of ce2:
<?xml version="1.0"?> <CDNNetwork> <revision>1.0</revision><dynamic> <CE>hostname_of_ce1</CE> <metric>20</metric> </dynamic><dynamic> <CE>hostname_of_ce2</CE> <metric>30</metric> </dynamic></CDNNetwork>Configuring Load-Based Content Routing Using a Content Router
When you enable load-based content routing, the Content Router redirects client requests to the Content Engine that reports the lowest average CPU load, given that each Content Engine in the routing table has the same metric value (or weight).
When you have multiple Content Engines that are defined with unequal weighting, you can configure threshold limits for CPU load, disk usage, and WMT stream count so that the Content Router redirects the client requests to the next preferred Content Engine that has not exceeded its threshold.
When a configured threshold is exceeded, messages are sent to the Content Router. Content Router algorithms compare the Content Engine assigned weight and current load to the configured threshold values when making routing decisions.
Enabling Load-Based Routing on the Content Router
To enable the Content Router for load-based routing, follow these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
To enable load-based routing on the Content Router from the CLI, use the contentrouting leastloaded Content Router global configuration command.
Configuring Content Engine Threshold Limits for Load-Based Routing
To configure threshold limits on the Content Engine, follow these steps:
Step 1
Step 2
Step 3
Figure 4-18 Service Monitor Settings Window
Step 4
•
•
•
•
Step 5
•
•
•
Step 6
•
•
•
•
Step 7
Troubleshooting Content Router Configurations
Because there are quite a few configuration steps required for the Content Router to redirect the request properly, you might see some content request errors from the Content Router when the configuration is not quite complete. Here are some areas to look at when troubleshooting:
•
–
•
–
–
–
–
–
–
–
•
–
–
–
–
–
–
–
Where to Go Next
You have finished setting up the request routing infrastructure for your ACNS network so that client requests for content can be routed to the Content Engine that can best serve the content. You are now ready to configure your Content Engines to serve the content. Content Engines can be configured to serve content as proxy caching servers or they can be configured to distribute pre-positioned content. To configure the Content Engine for proxy caching, see Chapter 8, "Configuring Caching Services."
Configuring your network for pre-positioned content distribution includes the following tasks:
•
•
•
•
•
•
•
To accomplish these tasks, proceed to the next chapter, Chapter 5, "Configuring the ACNS Network for Content Distribution."
