-
Cisco ACNS Software Configuration Guide for Centrally Managed Deployments, Release 5.2
-
Index
-
Title Page
-
Preface
-
Chapter 1: Understanding the ACNS 5.2 Network
-
Chapter 2: Using the Content Distribution Manager GUI
-
Chapter 3: Getting Started
-
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: Working with Device Configurations
-
Chapter 11: Configuring Network Interfaces
-
Chapter 12: Configuring Request Processing Services
-
Chapter 13: Configuring Request Authentication and Authorization
-
Chapter 14: Configuring Login Authentication and Authorization
-
Chapter 15: Creating and Managing IP Access Control Lists
-
Chapter 16: Configuring Platform and System Settings
-
Chapter 17: Upgrading and Downgrading the Software
-
Chapter 18: Monitoring the ACNS Network
-
Chapter 19: Backup and Recovery Procedures
-
Appendix A: Creating Manifest Files
-
Appendix B: Configuring Disk Space
-
Appendix C: IP Multicast Addressing
-
Appendix D: Advanced Routing Configurations
-
Appendix E: 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
Configuring WCCP Port Lists for the Content Engine
Configuring WCCP Service Masks for the Content Engine
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 DNS Caching Name Service for WCCP
Configuring DNS Caching Server Settings for the Content Engine
Cacheable Resource Records in the Content Engine DNS Cache
Configuring DNS Server Bindings for the Content Engine
Configuring DNS Address Record Mappings for the Content Engine
Configuring DNS Canonical Name Record Mappings for the Content Engine
Configuring Direct Proxy Routing
HTTP Transparent and 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 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
Troubleshooting Content Router Configurations
Setting Up Content Request Routing in the ACNS Network
Cisco ACNS 5.2 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.
Content Engine (3b in Figure 4-2).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:
•
•
•
•
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-3, 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-3 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
Note
Step 6
Step 7
Step 8
Step 9
Step 10
Step 11
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 sixteen services. If sixteen services have already been defined, the icon is not visible in the taskbar.
Note
Step 5
a.
b.
c.
d.
e.
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 configure various router lists for use with WCCP Version 2 services. For example, you can specify one router list for WCCP Version 2 web cache service and another list for reverse proxy at the same time without having to reconfigure groups of routers or Content Engines. You can add up to 8 router lists and up to 32 IP addresses per list. A router list must be associated with at least one IP address.
To create WCCP router lists, follow these steps:
Step 1
Step 2
Step 3
Step 4
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 5
Step 6
Step 7
Step 8
All IP addresses added must be unique within the router list. Otherwise, an error message is displayed on submit.
Step 9
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 10
Modifying WCCP Router Lists for the Content Engine
To modify 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
Step 2
Alternatively, click the Edit WCCP Router List Configuration icon next to the router list that you want to modify. The Modifying WCCP Router window appears. You can add, update, or delete IP addresses.
Configuring WCCP Port Lists for the Content Engine
With eight custom services using 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
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 5
Step 6
Step 7
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 8
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 and therefore 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
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 5
Step 6
Step 7
Step 8
Step 9
Step 10
Step 11
Step 12
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
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 5
Step 6
The Edit Mask button toggles with the Create Mask button if a service mask has already been configured for a WCCP service.
Step 7
Step 8
Step 9
Step 10
Step 11
Step 12
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.
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-4.
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-4 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-4:
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-5.
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-5 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-5:
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 DNS Caching Name Service for WCCP
For transparent interception of DNS requests using WCCP, administrators must configure the DNS caching name service (WCCP service group number 53) on the Content Engine and on a router that supports WCCP Version 2.
The DNS process interacts with the WCCP process in these ways:
•
•
•
In centrally managed ACNS networks, configuring the DNS caching name service with WCCP interception on a centrally managed Content Engine causes a conflict with the Content Router, because they will be listening for DNS requests on the same port. The Content Router and a Content Engine will both be listening on port 53. Consequently, they are mutually exclusive and you should not configure DNS cache support with WCCP interception in such environments. You can, however, enable the standard DNS caching name service (without WCCP interception support) in centrally managed ACNS networks.
The advantages of having the Content Engines intercept DNS requests include the following:
•
•
•
You can partition your network with a series of forwarders each with its own DNS cache, which results in the following:
•
•
Typically, this partitioning also results in a performance improvement if a cluster of requests occurs, especially on high-latency interconnections.
Configuring DNS Caching Server Settings for the Content Engine
To configure the DNS caching server settings for the Content Engine, follow these steps:
Step 1
Step 2
In the Contents pane, choose Request Routing > DNS Caching > DNS Caching Server. The DNS Caching Server Settings for Content Engine window appears. Table 4-7 describes the fields in this window and provides the corresponding CLI global configuration commands.
Step 3
Note
Step 4
Step 5
When checked, the DNS cache uses an expired resource record, if it resides in its cache, to serve the user request. At the same time, the DNS cache initiates a new lookup to revalidate the cached object. This is particularly useful where the upstream DNS is slow or unresponsive. The expired response will continue to be used until the entry is updated by a new response, or is purged from the cache using the Least Recently Used (LRU) algorithm.
Step 6
You can configure the method that the DNS caching name server uses to handle transparent DNS requests redirected from a WCCP-enabled router. These transparent DNS requests contain the original destination server in the packet headers. However, because the Content Engine can have more than one DNS name server configured, the DNS caching name server can be configured to use either the original DNS server specified in the original request packet headers or the DNS name servers configured on the Content Engine, or a combination of both.
Step 7
Step 8
Step 9
Because the DNS protocol is using UDP, packets can be lost or dropped. The burden of retransmitting DNS requests is on the requester. Typically, a retransmit is initiated every 3 seconds until a response is received, or if a response is not received, the request times out after 90 seconds. If a DNS server times out, then a new upstream server is selected to query. If there are no more servers to query upstream, then the server returns a DNS failed response to the requesting client.
Step 10
Step 11
Step 12
Cacheable Resource Records in the Content Engine DNS Cache
Content Engines with ACNS software can intercept DNS requests that have been issued to DNS servers (forwarders or recursive) that traverse the interception device. Upon receiving a request, the Content Engine transmits that response to the client if it has a current cached response. For a cached response to be valid, it must have all the appropriate resource records for the required sections (Answer, Authority, Additional). If any of these resource records have been purged or have expired the request is queued for transmission.
Table 4-8 describes the resource records that can be cached in the Content Engine DNS cache.
Although other resource records are not cached, they are passed through to the client requesting them. The DNS caching name service does support compression of the DNS response as defined by RFC 1035, including those responses generated by the cache. If the cache does not understand the server response to the query, it does not cache that response but passes it through to the client. This reduces the chance of a nonstandard client or server being disrupted.
Configuring DNS Server Bindings for the Content Engine
To configure DNS server bindings for the Content Engine, follow these steps:
Step 1
Step 2
Step 3
Step 4
Note
If the DNS server is already listening on all the interface IP addresses, then the following warning message appears: "DNS Service is already listening on all IP Addresses."
If the DNS server binding entries have already reached their maximum limit of 16, then the following warning message appears: "DNS Server Binding Entries have reached their maximum limit of 16."Step 5
•
•
Step 6
Note
Step 7
Step 8
If you have configured Listen on All IP Addresses, a dialog box alerts you that configuring the DNS cache server to listen on all IP addresses for client requests will remove all other DNS server binding settings. Click OK to confirm.
The DNS Server Bindings for Content Engine window appears with the configured DNS cache listener settings.
To configure the DNS caching name server to listen either on a specific interface IP address or to listen on all the IP addresses configured on the Content Engine from the CLI, use the following global configuration command:
dns listen {all | ipaddress} port port_num hostname hostname
Configuring DNS Address Record Mappings for the Content Engine
The DNS server must know the DNS name of the host on which it is being enabled and map the name to an IP address within its own cache. If the DNS cache listener does not match a DNS name, use the mapping type to pin an IP address to name mapping
To configure the DNS host name to IP address mapping for the Content Engine, follow these steps:
Step 1
Step 2
Step 3
Step 4
When you try to configure either a host name or a canonical name (Canonical names are configured from the DNS CNAME Record Mappings window) and the total number of pinning configurations has reached its maximum limit of 256, an error message is displayed.
Step 5
Table 4-9 Mapping Type Options
Forward
Maps the host name to the IP address
Reverse
Maps the IP address to the host name
Both
Maps in both forward and reverse directions
Step 6
Exceptions to host name duplication are as follows:
•
•
Step 7
Note
Step 8
If you click the Delete DNS A-Record Mapping icon to delete an address record mapped to a canonical name, an error message appears. You need to remove the mapping before you attempt to delete the address record.
To configure the DNS host name to IP address mappings from the CLI, use the following global configuration command:
dns pin {forward hostname ipaddress | reverse hostname ipaddress | both hostname ipaddress}
Configuring DNS Canonical Name Record Mappings for the Content Engine
The DNS server must know the DNS name of the host on which it is being enabled and map the name to an IP address within its own cache. If the DNS cache listener does not match a DNS name, map the canonical name resource record to the address record after pinning an IP address to name mapping.
To configure the mapping of DNS canonical name to address records for the Content Engine, follow these steps:
Step 1
Step 2
Step 3
Step 4
Note
Step 5
Step 6
The A-record drop-down list contains all configured forward and bidirectional mapping type address records. You can associate one or more unique A-records with the CNAME record.
Note
Step 7
To configure the mapping of DNS canonical name to address records from the CLI, use the dns pin cname records global configuration command.
Configuring 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.
In proxy mode, the Content Engine services any protocols for which it has been configured. The supported protocols are HTTP, Hypertext Protocol Secure (HTTPS), File Transfer Protocol (FTP), Microsoft Media Services (MMS), and Real-Time Transport Protocol (RTSP). If the Content Engine is not configured to support a received protocol, the proxy server returns an error. For example, if port 8080 is configured to run an HTTP and HTTPS proxy service, an FTP request coming to this port is rejected.
Note
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 farm.
TCP ports reserved for system or network services should not be used for proxying services (for example, DNS or FTP) in edge interception mode or in proxy mode. If more than eight ports for a protocol are required, the administrator can configure multiple dynamic WCCP services. Intercepted FTP, HTTP, and HTTPS requests addressed to other proxy servers (received on transparent mode ports) are serviced according to the proxy-protocols transparent command parameters.
Note
HTTP Proxy Caching
The Content Engine accepts proxy-style requests in nontransparent mode from a web browser when the incoming proxy ports are configured with the http proxy incoming ports option. Up to eight incoming proxy ports can be specified on a single command line or on multiple command lines.
To configure the Content Engine to direct all HTTP cache miss traffic to a parent cache (without using ICP or WCCP), use the http proxy outgoing host ipaddress port primary option, where host is the system name or IP address of the outgoing proxy server, and port is the port number designated by the outgoing (upstream) server to accept proxy requests. Use the primary option to set this host as the primary proxy.
HTTP Transparent and Proxy Routing
Certain scenarios involve the deployment of a Content Engine in proxy mode at company headquarters and a Content Engine in transparent mode at remote locations in branch offices. In these scenarios, if a cache miss occurs at the remote Content Engine, company policy requires that the request be routed to the Content Engine at headquarters.
When an HTTP request intended for the Content Engine acting as a proxy server is intercepted by the Content Engine in transparent mode at the remote location and a cache miss occurs, the Content Engine forwards the request to the intended proxy server if the proxy-protocols transparent original-proxy command was entered. If this command was not entered, then the Content Engine forwards the request to the origin server where the initial HTTP request was made.
FTP Proxy Caching
FTP proxy caching in a Content Engine refers to the ability to service FTP-over-HTTP requests. The transport between the web browser and the cache is over HTTP, and the cache initiates an FTP transfer to the origin FTP server.
Note
The ftp proxy command enables the Content Engine to operate in environments where WCCP is not enabled, or where client browsers have previously been configured to use a legacy FTP proxy server.
The ftp proxy incoming port option specifies a port number used by the proxy server to receive requests. This number can range from 1 to 65535. A maximum of eight incoming proxy ports can be configured. You can share these incoming proxy ports with transparent-mode services and also with the other proxy-mode protocols supported by the Content Engine, such as HTTP and HTTPS. The ftp proxy incoming port option is disabled by default.
Note
The Content Engine accepts FTP requests when URLs specify the FTP protocol (for example, GET ftp://ftp.cisco.com/pub/biff/READM). For these requests, the client uses HTTP as the transport protocol with the Content Engine, whereas the Content Engine uses FTP with the FTP server.
The Content Engine caches both FTP file objects and directory listings in the cache file system (cfs). The Content Engine transforms the regular directory listings from the FTP server into HTML, with links that the client users can point to and click to download files.
When the Content Engine receives an FTP request from the web client, it first looks in its cache. If the object is not in its cache, it fetches the object from an upstream FTP proxy server (if one is configured), or directly from the origin FTP server.
The FTP proxy supports anonymous as well as authenticated FTP requests. Only base64 encoding is supported for authentication. The FTP proxy accepts all FTP URL schemes defined in RFC 1738. In the case of a URL in the form ftp://user@site/dir/file, the proxy sends back an authentication failure reply and the browser supplies a popup window for the user to enter login information.
The Content Engine can apply the Rules Template to FTP requests based on server name, domain name, server IP address and port, client IP address, and URL.
The Content Engine logs FTP transactions in the transaction log, in accordance with Squid syntax.
Examples
This example configures an incoming FTP proxy on ports 8080, 8081, and 9090. Up to eight incoming proxy ports can be configured on the same command line.
ContentEngine(config)# ftp proxy incoming 8080 8081 9090This example removes one FTP proxy port from the list entered in the previous example. Ports 8080 and 9090 remain FTP proxy ports.
ContentEngine(config)# no ftp proxy incoming 8081This example disables all the FTP proxy ports.
ContentEngine(config)# no ftp proxy incomingThis example configures an upstream FTP proxy with the IP address 172.31.76.76 on port 8888.
ContentEngine(config)# ftp proxy outgoing host 172.31.76.76 8888This example specifies an anonymous password string for the Content Engine to use when contacting FTP servers. The default password string is anonymous@hostname.
ContentEngine(config)# ftp proxy anonymous-pswd newstring@hostnameThis example configures the maximum size in kilobytes of an FTP object that the Content Engine will cache. By default, the maximum size of a cacheable object is not limited.
ContentEngine(config)# ftp object max-size 15000This example forces the Content Engine to revalidate all objects for every FTP request.
ContentEngine(config)# ftp reval-each-request allThis example configures a maximum Time To Live of 3 days in cache for directory listing objects and file objects.
ContentEngine(config)# ftp max-ttl days directory-listing 3 file 3Using a Proxy Autoconfiguration File Server
Cisco ACNS 5.2 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 > Content Engines > HTTP/S > 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:
•
•
•
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-6 Registering New PAC File Window—Import Method
For descriptions of the fields associated with the upload method, see Table 4-10. For descriptions of the fields associated with the import method, see Table 4-11.
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
Figure 4-7 Device Activation for Content Engine Window
Step 4
Step 5
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 aliveness 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 "Configuring Caching Services." To configure your network for pre-positioned content distribution, see "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.
In order 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.)
•
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 therefore 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-12) 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-12 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
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
Figure 4-8 Registering New Coverage Zone File Window
Step 4
•
•
For descriptions of the fields associated with the upload method, see Table 4-13. For descriptions of the fields associated with the import method, see Table 4-14.
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-9 Set Global Coverage Zone File Window
Step 3
Step 4
Step 5
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
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 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-10 Coverage Zone Scenario 1: No NAT
The following file is an example of a coverage zone file for scenario 1. (See Figure 4-10.)
<?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 10-3), because the subnet 10.1.1.0/24 is private and is not known to the Content Router.
Figure 4-11 Coverage Zone Scenario 2: Behind a NAT Firewall
The following coverage zone file applies to Figure 4-11.
<?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 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-12 Scenario 3: Multiple Content Engines Behind a NAT Firewall
The following coverage zone file applies to Figure 4-12.
<?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-13 Scenario 4: NAT Firewall with Multiple IP Addresses
The following coverage zone file applies to Figure 4-13.
<?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 for information on how to configure a Content Engine to serve as a routing Content Engine.
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. Some areas to look at when troubleshooting are:
•
–
•
–
–
–
–
–
–
–
•
–
–
–
–
–
–
–
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 "Configuring Caching Services."
Configuring your network for pre-positioned content distribution includes the following tasks:
•
•
•
•
•
•
•
To accomplish these tasks, proceed to the next chapter, "Configuring the ACNS Network for Content Distribution."
