Cisco ACNS Software Deployment and Configuration Guide, Release 5.0 - Chapter 4: Setting up Content Routing in the CDN [Cisco Application and Content Networking System (ACNS) Software]

Table Of Contents

Setting Up Content Request Routing in the CDN

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

Importing Coverage Zone Files

Selecting the Coverage Zone

Selecting 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

Setting Up Content Request Routing in the CDN

Cisco ACNS 5.0 software supports three 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

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.0 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 in the following manner:

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

2. The WCCP-enabled router intercepts the request, and based on 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.

Figure 4-1 Edge Interception Through WCCP

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 eight dynamic services using a maximum number of eight 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.0 software currently emphasizes the use of WCCP Version 2. However, WCCP Version 1 is still supported by the ACNS 5.0 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.

Note If you are using a redirect access list with dCEF on the Cisco 7500 Series, then you must use a numbered access list instead of a named access list.
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.0 publication and 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 as it does not have the option to set 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 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.0 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 CDN.

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.

Importing 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 CDN, or locally to a specific Content Router in the CDN. 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.

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

Selecting a Default Coverage Zone

To select 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 CDN 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 CDN-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 file name) where the coverage zone file can be accessed.

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

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

The following coverage zone file applies to Figure 4-11.
<?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.