Cisco ACNS Software Deployment and Configuration Guide, Release 5.1 - Chapter 4: Setting Up Content Request Routing in the ACNS Network [Cisco Application and Content Networking System (ACNS) Software]

Table Of Contents

Setting Up Content Request Routing in the ACNS Network

Understanding WCCP-Enabled Router Interception

Edge Interception and WCCP Service Group Features

Configuring WCCP

Prerequisites

Configuring the Content Engine

Enabling WCCP on the Router

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

Understanding Content Routing Using a Proxy

HTTP Proxy Caching

HTTP Transparent and Proxy Routing

FTP Proxy Caching

Examples

Understanding Simplified Hybrid Routing and Coverage Zones

Coverage Zones and Coverage Zone Files

Registering Coverage Zone Files

Choosing the Coverage Zone

Choosing a Default Coverage Zone

Registering and Applying a User-Defined Coverage Zone

Coverage Zone File Examples

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

Understanding Content Routing Using a Proxy Autoconfiguration File Server

Creating PAC File Templates

PAC File Example

Registering a PAC File Template and Assigning Coverage Zone Information

Configuring a Content Engine as a PAC File Server

Setting Up Content Request Routing in the ACNS Network

Cisco ACNS 5.1 software supports four methods of request handling to deliver content to the end user. These request handing methods are described in the following sections:

•Understanding WCCP-Enabled Router Interception

•Understanding Content Routing Using a Proxy

•Understanding Simplified Hybrid Routing and Coverage Zones

•Understanding Content Routing Using a Proxy Autoconfiguration File Server

Note For complete syntax and usage information for the CLI commands used in this chapter, refer to the Cisco ACNS Software Command Reference, Release 5.1 publication.

Understanding WCCP-Enabled Router Interception

In the WCCP transparent interception 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 number 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.

The WCCP transparent interception method delivers content to end users as shown in Figure 4-1.

Figure 4-1 Edge Interception Through WCCP

1. A user requests a web page from a browser.

2. The WCCP-enabled router intercepts the request, and based on the TCP destination port number, the router determines whether it should transparently redirect the request to a Content Engine. Access lists are used to control which requests can be redirected.

3. If the Content Engine does not have the requested content, it sets up a separate TCP connection to the end server to retrieve the content (3a in Figure 4-1). The content returns to, and is stored on, the
Content Engine (3b in Figure 4-1).

4. The Content Engine sends the content to the client. Upon subsequent requests for the same content, the Content Engine transparently fulfills the request from its local storage.

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:

•No end user configuration—Users do not have to point their browsers to the Content Engine.

•Fail-safe—Content Engines are automatically fault-tolerant and fail-safe. Any cache failure does not cause denial of service to the end user.

•Scalable—Cache services can be scaled by deploying multiple Content Engines.

•Automatic bypass—Sites which depend on end user authentication or which fail to conform to HTTP standards will automatically bypass a transparent cache.

Edge Interception and WCCP Service Group Features

You can configure the Content Engines to handle up to eight user-configurable or dynamic WCCP redirection services (90 to 97) on a Content Engine, provided that the services are also configured on the router.

The wccp service-number global configuration command can enable these services on the Content Engine. Each wccp service-number command specifies a router list, single port list (containing up to eight ports), application type (cache or streaming), hash parameters or mask assignment parameters for load-balancing purposes, password, and weight.

Table 4-1 lists the service group features supported by a WCCP-enabled router.

Table 4-1 WCCP Service Groups

Service Group Number

Description of Services

0

Web cache

50

Boomerang

80

HTTP, RTSP

81

MMST

82

MMSU

90-97

User-configurable

98

Custom

99

Reverse proxy

Note All service group numbers listed in Table 4-1 except for web cache services (service group 0) require WCCP Version 2.

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-2, 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-2 WCCP Service Group Feature

All ports receiving HTTP that are configured as members of the same WCCP service share the following characteristics:

•They have the same load-balancing parameters (hash or mask), as configured with the wccp service-number command.

•The service on individual ports cannot be stopped or started individually (WCCP Version 2 restriction).

With Content Engines in a farm, the following restrictions apply:

•All Content Engines that use the same WCCP service are required to configure the same list of ports and the same load-balancing parameters.

•A Content Engine that tries to join the farm with the same WCCP service using a different list of ports or different load-balancing parameters is rejected by the router.

•To change the port list for a particular WCCP service, WCCP service must be stopped on all involved Content Engines, and then all must be restarted with the new parameters.

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.

Configuring WCCP

Use the following configuration guidelines to help you configure the Content Engine for edge interception using a WCCP-enabled router.

Prerequisites

To use a WCCP-enabled router, an IP address must be configured on the router interface that is connected to the Internet, and this interface must be visible to the Content Engine on the network.

Configuring the Content Engine

To use WCCP, the Content Engine must be properly configured. Keep these important points in mind:

•Versions of software on the Content Engines must be compatible with those installed on the router.

•The Content Engines must not have their packets encrypted or compressed and should be part of the "inside" Network Address Translation firewall if one is present.

•Placing a Content Engine beyond a web cache redirect-enabled interface and along the route to the server will not cause the IP route cache to be populated with an entry.

Note ACNS 5.x software currently emphasizes the use of WCCP Version 2. However, WCCP Version 1 is still supported by the ACNS 5.x release.

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:
Command

Purpose
Step 1
ip wccp enable
Enables the router to use WCCP.
Step 2
ip wccp redirect-list [number | name]
(Optional.) Specifies the redirect access list. Only packets that match this access list are redirected. If you do not configure this command, all packets are redirected.
Step 3
interface type number
Enters interface configuration mode.
Step 4
ip web-cache redirect
Configures the interface connected to the Internet to redirect web traffic to the Content Engine.
Step 5
ip route-cache same-interface
(Optional.) If the client and a Content Engine are located on the same network, configures the router to use the fast switching path on the interface.
Step 6
end
Exits configuration mode.
Step 7
copy running-config startup-config
Saves the configuration.
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-3.

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-3 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:
Command

Purpose
Step 1
ContentEngine(config)# wccp version 2
Ensures that the Content Engine is running WCCP Version 2.
Step 2
ContentEngine(config)# wccp router-list 1 10.10.10.1
Configures a router list.
Step 3
ContentEngine(config)# wccp web-cache 
router-list-num 1
Informs the routers in the specified router list that the Content Engine is accepting web cache service.
Step 4
ContentEngine(config)# exit
Exits global configuration mode.
Step 5
ContentEngine# copy running-config startup-config
Writes running configurations to nonvolatile memory.
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:
Command

Purpose
Step 1
Router(config)# ip wccp web-cache 
Instructs the router to run the web cache service.
Step 2
Router(config)# interface Ethernet0 
Specifies which router interface to configure. In this scenario, Ethernet0 is the router interface to which the Content Engine and clients are connected.
Step 3
Router(config-if)# ip route-cache 
same-interface 
Enables fast switching of redirected packets back through the interface on which they were received. Without this command, the router does not use the high-speed switching cache, and the packets are process-switched, a much slower method.
Step 4
Router(config)# interface Serial0 
Specifies which router interface to configure. In this scenario, Serial0 is the router interface to the Internet.
Step 5
Router(config-if)# ip wccp web-cache redirect 
out 
Instructs the router to redirect web cache traffic bound for the specified interface to Content Engines that accept web cache service. In this scenario there is only one router. Web cache traffic is defined as TCP port 80 traffic.
Step 6
Router(config-if)# exit 
Exits interface 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-3:

Content Engine
hostname Content_engine_4.2
!
clock timezone pst -8 0
!
ip domain-name cu.net
!
interface FastEthernet 0
ip address 10.10.20.10 255.255.255.0
no autosense
bandwidth 100
full-duplex
exit
interface FastEthernet 1
shutdown
exit
!
ip default-gateway 10.10.20.1
!
ip name-server 10.10.10.100
!
!
!
wccp router-list 1 10.10.20.1
wccp web-cache router-list-num 1
wccp version 2
!
!
!
. . . 
WCCP-Enabled Router
Building configuration...
Current configuration:
!
version 12.0
!
hostname WCCP-Router
!
!
ip wccp web-cache         
!
interface Ethernet0
 ip address 10.10.10.1 255.255.255.0
 ip route-cache same-interface
!
interface Serial0
ip address 192.168.1.2 255.255.255.252
no ip directed-broadcast
no ip mroute-cache
ip wccp web-cache redirect out
 !
end
Web 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-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 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:
Command

Purpose
Step 1
ContentEngine(config)# wccp version 2
Ensures that the Content Engine is running WCCP Version 2.
Step 2
ContentEngine(config)# wccp router-list 1 
10.10.20.1 
Configures a router list.
Step 3
ContentEngine(config)# wccp web-cache 
router-list-num 1
Informs the routers in the specified router list that the Content Engine is accepting web cache service.
Step 4
ContentEngine(config)# exit
Exits global configuration mode.
Step 5
ContentEngine# copy running-config startup-config
Writes running configurations to nonvolatile memory.
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:
Command

Purpose
Step 1
Router(config)# ip wccp web-cache
Instructs the router to run the web cache service.
Step 2
Router(config)# interface Serial0 
Specifies which router interface to configure. In this scenario, Serial0 is the router interface to the Internet.
Step 3
Router(config-if)# ip wccp web-cache redirect out 
Instructs the router to redirect web cache traffic bound for the specified interface to Content Engines that accept web cache service. In this scenario there is only one router. Web cache traffic is defined as HTTP packets on port 80.
Step 4
Router(config-if)# exit 
Exits interface 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-4:

Content Engine Configuration
. . .
hostname Content_engine_4.2
!
clock timezone pst -8 0
!
ip domain-name cisco.com
!
exec-timeout 20
!
interface FastEthernet 0
ip address 10.10.20.10 255.255.255.0
no autosense
bandwidth 100
full-duplex
exit
interface FastEthernet 1
shutdown
exit
!
ip default-gateway 10.10.20.1
!
ip name-server 10.10.10.100
!
!
wccp router-list 1 10.10.20.1
wccp web-cache router-list-num 1
wccp version 2
!
!
!
...
WCCP-Enabled Router Configuration
Building configuration...
Current configuration:
!
hostname WCCP-Router
!
!
ip subnet-zero
!
ip wccp web-cache         
!
interface Ethernet0
 ip address 10.10.10.1 255.255.255.0
!
interface Ethernet1
 ip address 10.10.20.1 255.255.255.0
!
interface Serial0
 ip address 192.168.1.2 255.255.255.252
 no ip directed-broadcast
 no ip mroute-cache
ip wccp web-cache redirect out
 !
end
Understanding Content Routing Using a Proxy

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 If proxy mode is used for content routing, then Windows Media Player (WMP) Version 6.4 cannot be used, because it does not have the option to set an MMS proxy.

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.

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 ip-address 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 Content Engine caches FTP traffic only when the client uses the Content Engine as a proxy server for FTP requests. All FTP traffic that was sent directly from the web client to an FTP server, if transparently intercepted by the Content Engine, is treated as non-HTTP traffic. If a web browser is not explicitly configured to use a proxy, then the browser will initiate an end-to-end FTP connection itself, and this will not be intercepted by the Content Engine.

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 and services FTP requests only on the ports configured to act as an FTP proxy. All FTP requests on other proxy-mode ports are rejected in accordance with the error-handling settings on the Content Engine.

The Content Engine accepts FTP requests when URLs specify the FTP protocol (for example, GET ftp://ftp.cisco.com/pub/cao/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 9090
This 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 8081
This example disables all the FTP proxy ports.
ContentEngine(config)# no ftp proxy incoming
This 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 8888
This 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@hostname
This 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 15000
This example forces the Content Engine to revalidate all objects for every FTP request.
ContentEngine(config)# ftp reval-each-request all
This 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 3
Understanding Simplified Hybrid Routing and Coverage Zones

Simplified hybrid routing (SHR) uses HTTP or RTSP redirection through a Content Router. The Content Router determines which Content Engine is best suited to deliver the desired content to the client, based on the requested content, 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 then sends the client a redirect response pointing to the selected Content Engine.

Simplified hybrid routing works in the following manner:

1. The client sends a Domain Name System (DNS) query for the IP address of the content to its local DNS proxy server.

2. The local DNS proxy sends the DNS query to a name server to resolve the domain name to an IP address.

3. The resolution process eventually ends up at the Content Router. The IP address of the Content Router is returned to the DNS proxy server.

4. The DNS proxy server returns the IP address of the Content Router to the client.

5. The client sends a request for the desired content to the Content Router.

6. The Content Router sends back a redirect response pointing to the DNS domain name of the closest Content Engine.

7. The client sends a request for the content to the best-suited Content Engine.

8. The best-suited Content Engine sends the content to the client.

In order for simplified hybrid routing to work properly, the following information must be configured:

•Coverage zone

The Content Router selects the Content Engine closest to the client end system based on the coverage zone. (See the next section, "Coverage Zones and Coverage Zone Files.")

•Website subscription

A Content Engine can only serve content for websites to which the Content Engine is subscribed. Content Engines are subscribed to websites through channels. (See the "Adding and Removing Content Engines from Channels" section.)

•DNS server

DNS entries for all fully qualified domain names (FQDNs) must be delegated to the Content Router. In the DNS server's zone database file (db), 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 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 are not assigned to Content Distribution Managers.

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-2) 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 that is determined by the IP address assigned to the Content Engine and its subnet mask. Network administrators can also create 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-2 defines the coverage zone file elements.

Table 4-2 Coverage Zone File Elements

Element

Value

Description

Network

IP address

Coverage zone IP address range.

Content Engine

Content Engine name

Specifies the Content Engines serving the coverage zone specified in the network element. This can have one or more elements.

Metric

Integer

Specifies the metric value of a Content Engine. The lower the value, the closer the Content Engine is to the end user.

Agent

Name of routing Content Engine

Optional field that specifies a Content Engine acting as the routing Content Engine. If not specified, the coverage zone entry is designated for a Content Router.

Registering Coverage Zone Files

The system administrator places a coverage zone file on a web server 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 in the ACNS network. If a coverage zone file is made global, then it is read and parsed by each Content Router. If the coverage zone is specified in an individual Content Router configuration, it is only applied to that particular Content Router.

Choosing the Coverage Zone

You have the choice of using two types of coverage zones:

•Default coverage zones

•User-defined 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 The metric value of a default coverage zone is set to 20. If a user-defined coverage zone is preferred for a particular Content Engine, the metric value in the coverage zone file should be set to a value less than 20. If a default coverage zone is preferred, then the metric value in the coverage zone file should be set to a value greater than 20.

Choosing a Default Coverage Zone

To choose a default coverage zone, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Content Engines.

Step 2 Click the Edit icon next to the name of the Content Engine that you want to modify. The Modifying Content Engine window appears with fields for editing the properties of the selected Content Engine. (See Figure 4-5.)

Figure 4-5 Modifying Content Engine Window

Step 3 Check the Set Default Coverage Zone File check box.

Step 4 Click Submit.

Registering and Applying a User-Defined Coverage Zone

To apply a custom coverage zone to a Content Router or routing Content Engine, you need to first 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 two ways:

•Globally—Deployed across the entire ACNS network

•Locally—Deployed on a specific Content Router or routing Content Engine

Note If you apply a coverage zone file locally for a device, this file will overwrite the ACNS network-wide coverage zone file for that device.

To register a coverage zone file, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose System > Routing.

Step 2 In the Contents pane, choose Routing Management > Coverage Zone File Registration. The Coverage Zone File Registration window appears.

Step 3 Click the Create New Coverage Zone File icon. The Registering New Coverage Zone File window appears. (See Figure 4-6.)

Figure 4-6 Registering New Coverage Zone File Window

Step 4 In the Coverage Zone File URL field, enter the full path of the origin URL (including the coverage zone filename) where the coverage zone file can be accessed.

Step 5 In the Destination File Name field, enter a filename.

Step 6 In the Update Interval (minutes) field, enter the Time To Live value. The default value is 10 minutes.

Step 7 Click Submit to save the settings made.

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 From the Content Distribution Manager GUI, choose System > Routing.

Step 2 In the Contents pane, choose Routing Management > Global Routing Config. The Set Global Coverage Zone File window appears. (See Figure 4-7.)

Figure 4-7 Set Global Coverage Zone File Window

Step 3 From the Coverage Zone File drop-down list, choose a coverage zone file if one has been created.

Step 4 In the Keep Alive Port field, enter a port number that is used by the ACNS network-wide network to listen in on routing requests.

Step 5 Click Submit.

To apply a coverage zone file to an individual Content Router to be used locally, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Content Routers.

Step 2 Click the Edit icon next to the name of the Content Router to which you want to assign a coverage zone file. The Modifying Content Router window appears.

Step 3 Choose a coverage zone file from the Coverage Zone File drop-down list.

Step 4 Click Submit to apply the coverage zone file to the Content Router.

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. 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 give a metric value greater than 20 (entry 1 and entry 2).

Figure 4-8 Coverage Zone Scenario 1: No NAT

The following file is an example of a coverage zone file for scenario 1. (See Figure 4-8.)
<?xml version="1.0" ?>
<CDNNetwork>
<revision>1.0</revision>
<customerName>ent.com</customerName>

<coverageZone>
<network>172.29.248.0/24</network>
<CE>ent_sanfrancisco</CE>
<metric>20</metric>
</coverageZone>

<coverageZone>
<network >172.29.249.0/24</network>
<CE>ent_sanjose</CE>
<metric>20</metric>
</coverageZone>

<coverageZone>
<network>172.29.248.0/24</network>
<CE>ent_sanjose</CE>
<metric>10</metric>
</coverageZone>

<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 8-2), because the subnet 10.1.1.0/24 is private and is not known to the Content Router.

Figure 4-9 Coverage Zone Scenario 2: Behind a NAT Firewall

The following coverage zone file applies to Figure 4-9.
<?xml version="1.0" ?>

<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 "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 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-10 Scenario 3: Multiple Content Engines Behind a NAT Firewall

The following coverage zone file applies to Figure 4-10.
<?xml version="1.0" ?>

<CDNNetwork>
<customerName>ent3.com</customerName>

<coverageZone>
<network>171.29.1.1/32</network>
<CE>ent3_sanjose1</CE>
<metric> 10 </metric>
</coverageZone>


<coverageZone>
<network>10.1.1.0/24</network>
<CE>ent3_sanjose1</CE>
<metric> 10 </metric>
<agent> ent3_sanjose1</agent>
</coverageZone>

<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-11 Scenario 4: NAT Firewall with Multiple IP Addresses

The following coverage zone file applies to Figure 4-11.
<?xml version="1.0" ?>

<CDNNetwork>
<coverageZone>
<network>171.29.10.1/32</network>
<CE>ent4_sanfrancisco</CE>
<metric>10</metric>
</coverageZone>

<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.

Understanding Content Routing Using a Proxy Autoconfiguration File Server

Cisco ACNS 5.1 software supports dynamic proxy autoconfiguration (PAC). This routing method is 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 a PAC file template (see the "Creating PAC File Templates" section).

The dynamic PAC routing method supports the following features:

•It supports multiple PAC files.

•The user can specify the names of the PAC files instead of being limited to preset names.

•The PAC file server dynamically adds a set of "nearest proxies" to a PAC file template based on coverage zone information and the source IP address of the requester.

•The Content Distribution Manager acquires the PAC file templates and distributes them to Content Engines that are PAC file servers rather than the Content Engines themselves acquiring the PAC file templates.

Note This new feature is not an extension of the proxy-auto-config EXEC command feature supported in ACNS 5.0 software, nor does it replace that feature. Both features are supported in ACNS 5.1 software.

Creating PAC File Templates

The system administrator creates a PAC file template on a workstation and places it on a web server 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 using HTTP 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 the end users. The 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 the 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:

•CE_NAME_n

•CE_IPADDR_n

•NEAREST_PROXIES_n

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 proxy first to CE1 and all clients on subnet 10.1.2.0/24 proxy first to CE2.

The PAC file template would look like this:
Function FindProxyForURL(url, host)
{
// handle plain host names
if (isPlainHostName(host) {
    return "DIRECT";
// handle exception list 
         if (myIpAddress() == "10.1.1.2") {
             return "DIRECT";
         }
// handle special domain list 
         if (shExpMatch(host, "specialdomain.com")) {
             return "PROXY specialDomainProxy.foo.com";
}
// handle direct domain list 
         if (shExpMatch(host, "directdomain.com")) {
             return "DIRECT";
}
// closest proxies + defaults
	  p1 = 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>


<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 names
if (isPlainHostName(host) {
    return "DIRECT";
// handle exception list 
         if (myIpAddress() == "10.1.1.2") {
             return "DIRECT";
         }
// handle special domain list 
         if (shExpMatch(host, "specialdomain.com")) {
             return "PROXY specialDomainProxy.foo.com";
}
// handle direct domain list 
         if (shExpMatch(host, "directdomain.com")) {
             return "DIRECT";
}
// closest proxies + defaults
	  p1 = "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 In the Content Distribution Manger GUI, choose System > Routing > PAC File Management > PAC File Registration. The PAC File Registration window appears.

Step 2 Click the Create New PAC File icon. The Registering New PAC File window appears. (See Figure 4-12.)

Figure 4-12 Registering New PAC File Window

Step 3 In the PAC File URL field, enter the full location of the PAC file. This tells the CDM where to locate the PAC file so that it can be distributed to the PAC file servers.

Step 4 Enter a destination filename. This is the name of the PAC file being distributed to the PAC file server.

Note The PAC file with this destination filename is copied into the /state/pacFile directory on the PAC file server.

Step 5 Enter the end user request URL. This is the URL that an end user would use to configure the browser to obtain the PAC file from a PAC file server. (The file specified by the URL should end with ".pac")

Note If a port number other than 80 is to be used to obtain the file, it must be specified in the URL. For example, if port 8080 is to be used, the URL would look like this: http://10.5.1.151:8080/sample.pac

Step 6 Choose a coverage zone file from the Coverage Zone File drop-down list or choose None.

Step 7 If you want the nearest proxy to be calculated based on the default coverage zone, check the Use the default Coverage Zone check box.

Note If only a coverage zone file is entered (see Step 6), the nearest proxies are calculated using the information in the specified coverage zone file. If only the default coverage zone is indicated, the nearest proxies are calculated using only the default coverage zone. If both a coverage zone file is specified and the default coverage zone check box is checked, the nearest proxies are calculated based on the union of the coverage zone file and default coverage zone.

Step 8 Enter a value in minutes for the update interval. This sets the frequency with which the Content Distribution Manager looks for changes to the PAC file located at the PAC file URL.

Step 9 Click Submit to save the settings.

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 into 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 In the Content Distribution Manager GUI, choose Devices > Content Engines.

Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure as a PAC file server. The Modifying Content Engine window appears.

Step 3 In the Request Routing section, check the Enable PAC File Server check box.

Step 4 Click Submit to save the changes.