Content Request Routing

To send client requests to the best-suited CE, you have three options using ACNS:

• Web Cache Communication Protocol (WCCP) You learned how to configure WCCP to redirect clients to their local CE in Chapter 13. With this method of request routing, you can configure the user's branch router to direct their requests to the CE located in their branch.

• Simplified Hybrid Routing (SHR) SHR uses HTTP redirection and coverage zones to determine the best-suited CE. With coverage zones, you have the flexibility to assign users manually to any CE in your ACNS network.

• Dynamic Proxy Autoconfiguration (PAC) Dynamic PAC also uses coverage zones to determine the best-suited CE, and dynamically adjusts client's proxy settings with the best-suited CE URL or IP address.

Simplified Hybrid Routing

With SHR, your CR decides which CE to route client requests to, using coverage zone information you specify with an XML file. The coverage zone file includes the mapping of source IP subnets to CE IP address. When you register your CEs with the CDM, the CDM creates a default coverage zone file including the subnet that the CE resides on and the IP address of the CE. For example, based on the zones in Figure 14-15, the CDM will create the coverage zone file in Example 14-2. You can manually adjust the default coverage zones in the coverage zone XML file if you need toin this example, the second entry for 10..30.0/24 with metric 30 was manually added as a backup to the entry with metric 20. This way, the central branch CE can server Branch 2, if necessary.

Figure 14-15. Simplified Hybrid Routing

Example 14-2. Sample Coverage File

 <?xml version="1.0"?> <CDNNetwork>   <coverageZone>     <network>10.1.10.0/24</network>     <CE>hq-ce.cisco.com</CE>     <metric>20</metric>   </coverageZone>   <coverageZone>     <network>10.1.20.0/24</network>     <CE>b1-ce.cisco.com</CE>     <metric>20</metric>   </coverageZone>   <coverageZone>     <network>10.1.30.0/24</network>     <CE>b2-ce.cisco.com</CE>    <metric>20</metric>  </coverageZone>  <coverageZone>    <network>10.1.30.0/24</network>    <CE>cb-ce.cisco.com</CE>    <metric>30</metric>  </coverageZone>  <coverageZone>    <network>10.1.40.0/24</network>    <CE>cb-ce.cisco.com</CE>    <metric>20</metric>  </coverageZone> </CDNNetwork> 

Note

In order for your CR at the headquarters to receive the client A record requests, you must delegate authority to the CR for the appropriate subdomains.

Based on Figure 14-16, the following sequence takes place:

1. With SHR, the client sends its DNS request to its local DNS server.

2. The DNS server sends an iterative DNS request to the root DNS server, which eventually ends up at the CR delegated to the pre-positioned subdomain. The CR responds to the local DNS server with its own IP address in an A record response.

3. The local DNS server responds to the client with the A record of the CR.

4. The client sends the HTTP GET request to the CR, which determines the most suitable CE for the requesting client from the coverage zone file.

5. The CR sends an HTTP 302 redirect for the selected CE.

6. The client reissues the request to the CE.

Figure 14-16. Dynamic PAC

Recall from Chapter 12, "Exploring Global Server Load Balancing," that most GSLB solutions use the client DNS server to select a site to it, which sends the client's request. GSLB assumes that the client DNS server is in close proximity to the requesting clients. However, SHR does not make this assumption, because most often clients issue DNS requests to the organization's DNS server, which is located in the corporate headquartersthe same location as the CR. This is why the CR uses the HTTP GET request from the client to determine which CE to redirect to.

Dynamic Proxy Auto-Configuration

Recall from Chapter 13 that you can configure your client browsers with direct proxy routing, by specifying the proxy that the client should use for requests. With Dynamic Proxy Autoconfiguration (PAC), you instead specify the IP address of the PAC proxy server in client browsers or media players. The PAC proxy server returns a script that the browser executes to determine which proxy to use for requests.

With Dynamic PAC in ACNS, you configure a CE as a PAC file server, create a PAC file template, and associate a coverage zone file to the template. When a user opens a browser, the browser sends a request for the PAC file to the PAC file server CE, which populates the PAC file on-the-fly with edge-CE IP addresses from the coverage zone file, based on the source IP address of the requesting client. The client browser executes the script in the PAC file for each request that the client makes, to select the CE to which it sends the request. Figure 14-16 illustrates the traffic flow for Dynamic PAC.

When you write the PAC file template for the PAC file server, you must specify a function called FindProxyForURL. When executed by the client browser, FindProxyForURL returns a list of the closest IP addresses to use as the proxy for all browser requests. Two examples of resulting strings returned from this function are

PROXY 10.1.30.1:80; 10.1.40.1:80; DIRECT

PROXY b2-ce.domain.com:80; cb-ce.domain.com:80; DIRECT

The client attempts to connect to the entries from left to right until it finds a CE that is available or when it reaches the DIRECT keyword. Then the browser sends the request directly to the origin server. These sample strings are based on the two coverages for clients that are located within Branch 2 subnet 10.1.30.0/24, in Example 14-2. The coverage with the lower metric is listed first in the "PROXY" string, and therefore the client browser attempts to connect to this CE first.

You can use the following macros in the PAC template that the PAC file server substitutes with CEs from the coverage zone file, where n can be a value between 1 and 5.

• CE_NAME_n The hostname of the CE in nth closest proximity to the requesting client. For example, CE_NAME_1 would generate "b2-ce" for the previous example.

• CE_IPADDR_n The IP Address of the CE in nth closest proximity to the requesting client. For example, CE_IPADDR_1 would give "10.1.30.1."

• NEAREST_PROXIES_n The PAC server generates a string including a list of IP address of CEs up to the nth closest CE. For example, NEAREST_PROXIES_2 would give "PROXY 10.1.30.1; 10.1.40.1."

You can use these macros in the template as literal constants within the FindProxyForURL function. For example, you can use the simple function in Example 14-3 to return the IP addresses of CEs that are ranked in terms of proximity to the client. If no proxy is available, clients go directly to the origin server.

Example 14-3. Sample PAC File Template

 function FindProxyForURL (url, host) ce1 = CE_NAME_1; ce2 = CE_NAME_2; if (ce1 != "") {   ce1 = "PROXY " + ce1 + ".cisco.com:80; "; } if (ce2 != "") {   ce2 = ce2 + ".cisco.com:80; "; } return ce1 + ce2 + "DIRECT"; 

The parameter called url is the requested URL within the client's HTTP GET request. The host parameter is the domain name within the requested URL (for example, http://www.cisco.com is a URL, and www.cisco.com is the associated host). You can use these parameters if you need to handle certain URLs differently from others, but you may not need to use these parameters at all in your PAC file template, as demonstrated with Example 14-3.

If a client browser in Branch 2 requests the PAC file, the headquarters CE returns the file in Example 14-4 based on the source IP address of the client.

Example 14-4. Sample PAC File

 function FindProxyForURL (url, host) ce1 = "b2-ce"; ce2 = "cb-ce"; if (ce1 != "") {   ce1 = "PROXY " + ce1 + ".cisco.com:80; "; } if (ce2 != "") {   ce2 = ce2 + ".cisco.com:80; "; } return ce1 + ce2 + "DIRECT"; 

When the client at Branch 2 runs this function, the following value is returned:

PROXY b2-ce.cisco.com:80; cb-ce.cisco.com:80; DIRECT

You should include checks in the script to ensure that the PAC file server populates the macros with data from the coverage file (that is, "if (ce2 != "")"). For example, if you did not include these checks and the coverage had only a single entry for the specific requesting source, the resultant PROXY string would contain an erroneous entry:

PROXY b2-ce.cisco.com:80; .cisco.com:80; DIRECT

Dynamic PAC is useful in roaming office environments, where clients move from office-to-office or home-to-office but still require pre-positioned content. A disadvantage with Dynamic PAC is that you still have to configure all browsers with the central PAC file server URL.