Transparent proxy deployment examples

Types of examples

This section provides several examples of transparency deployments. The deployments are essentially the same whether you are using an L4 or L7 switch or a WCCP router. The examples discuss the strategy for each deployment and the effects of the deployment on traffic. This section includes the following examples:

Some scenarios in other chapters in this guide show deployments that use transparent proxying.

Example 1: transparent deployment of a DNS proxy cache

In this example, an enterprise company wants to improve the speed of DNS lookups and decrease the amount of bandwidth that is consumed by sending DNS requests to remote servers. Additionally, the managers want to reduce the load on the DNS nameservers. They do so by configuring the NetCache appliance as a transparent DNS proxy cache.

Note
Alternatively, DNS caching can be set up for nontransparent access to the NetCache appliance.

The following illustration shows a transparent proxying topology consisting of one NetCache appliance and one L4 or L7 switch or one WCCP router.

In this deployment

The switch or router is located where it can intercept streaming requests from clients.
The NetCache appliance was configured as a transparent DNS proxy cache.
For deployment with an L4 or L7 switch, the DNS proxy cache was explicitly identified in the switch configuration and the switch was configured to redirect DNS (UDP port 53) traffic to the DNS proxy cache.
For deployment with a WCCP router, a WCCP service group was configured on both the router and the DNS proxy cache to enable the router to redirect DNS (UDP port 53) traffic to the DNS proxy cache.

If the DNS proxy cache has the host name to IP addresses mapping in its cache, NetCache can resolve the DNS query without contacting the remote DNS nameserver. If the DNS proxy cache cannot resolve a DNS query, it contacts a remote DNS nameserver to resolve the query, caches the host name and IP addresses resulting from the query, and returns the host's IP addresses to the client.

Example 2: deployment of a streaming media cache

In this example, an enterprise company has deployed streaming media service by configuring a NetCache appliance to run as a streaming media cache and by configuring an L4 or L7 switch or a WCCP router to be aware of the streaming media cache.

Note
Although this illustration shows a single streaming server, MMS and RTSP traffic might be handled by different streaming servers.

In this deployment

The switch or router is located where it can intercept streaming requests from clients.
For deployment with an L4 or L7 switch, the streaming media cache was explicitly identified on the switch and the switch was configured to redirect MMS (port 1755) and RTSP (port 554) traffic to the streaming media cache. HTTP (port 80) traffic was also redirected so that streaming traffic from clients whose media players are set for HTTP only can be handled.
For deployment with a WCCP router, WCCP service groups were configured on both the router and the streaming media cache to enable the router to redirect MMS (port 1755) and RTSP (port 554) traffic to the streaming media cache. HTTP (port 80) traffic was also redirected so that streaming traffic from clients whose media players are set for HTTP only can be handled.
Requests for live streams
In this example, both clients are requesting the same unique live (real-time) stream and the stream is being transmitted over unicast. When the streaming media cache receives the first of the two requests for the same stream, the proxy connects to the streaming server to obtain the stream.

When the proxy receives a second request for the same unique stream, the proxy splits the stream that it is already delivering to the first client and delivers the same unique stream to the second client also.

NetCache also supports streaming over multicast transmission. See NetCache support for live streams over multicast for more information.
Requests for on-demand streams
When an on-demand stream is requested by a client, NetCache determines whether the stream is already in the cache. If the stream is in the cache, NetCache serves it directly to the client from the cache. If the stream is not in the cache, NetCache fetches the on-demand stream from the streaming server and delivers the stream to the client while caching it for future clients.

See Chapter 5, Deploying NetCache as a Streaming Media Cache, for more information about the NetCache streaming media feature.

Example 3: transparent proxying site with NNTP and HTTP service

The following illustration shows a transparent proxying deployment consisting of three NetCache appliances and one switch or one WCCP router.

For the organization in this example, three NetCache appliances are required to handle the number of client HTTP and NNTP requests expected. All appliances handle requests of both protocols. The traffic load was not considered to be heavy enough that the cache hit rate or bandwidth savings would be adversely affected by multiple protocols being handled on the same NetCache appliance.

Note
If your NetCache appliance must handle a heavy load, Network Appliance recommends that you do not set up the same appliance to handle more than one type of traffic.

In this deployment

The switch or router is located so that it can intercept HTTP and NNTP client traffic that is to be redirected to the NetCache appliances.
Transparent proxying for HTTP and NNTP was enabled on each NetCache appliance.
For deployment with an L4 or L7 switch, the NetCache appliance was explicitly identified in the switch configuration and the switch was configured to redirect HTTP (TCP port 80) and NNTP (TCP port 119) traffic to the NetCache appliances.
For deployment with a WCCP router, a WCCP service group was configured on both the router and the NetCache appliance to enable the router to redirect HTTP (TCP port 80) and NNTP (TCP port 119) traffic to the NetCache appliances.
The switch or router bypasses the NetCache appliance for all traffic other than HTTP and NNTP.
The switch or router distributes HTTP and NNTP requests over the NetCache appliances to ensure the maximum possible hit rate.
If the NetCache appliance to which the switch or router redirects a request does not have the requested object, NetCache fetches objects from the Web server or news server, as applicable.

Example 4: POP and data center using HTTP transparent proxying

In this example, an ISP has two POPs (points of presence) and a data center. Three NetCache appliances are required at the data center to handle the expected load. One NetCache appliance is required at each POP to handle the expected load.

This ISP wants cache misses at the POPs redirected to the data center, instead of having the NetCache appliances at the POPs fetch the objects directly from the Internet. One advantage of this deployment is that the two POPs can share the data cached in the data center NetCache appliances. Additionally, if a NetCache appliance at a POP goes down, the ISP wants the data center switch to intercept HTTP traffic.

The following illustration shows deployment for the ISP using L4 switches to redirect HTTP traffic to the NetCache appliances. Deployment with a WCCP router is essentially the same, with the WCCP software installed on the router on the same subnet as the NetCache appliances. Although the WCCP router and NetCache appliances do not have to be on the same subnet, the most efficient approach is to have the routers at the POPs redirect traffic to the NetCache appliances at the POPs.

At each POP:

Configuration is as follows:

An L4 switch is placed in front of the NetCache appliance at the POP.
Transparency is enabled on the NetCache appliance for HTTP.
The switch at the POP is configured to be aware of only the NetCache appliance at the POP. The NetCache appliances at the data center are not on the same subnet, so the switch at the POP cannot be made aware of them.

Traffic is handled as follows:

The switch redirects all HTTP traffic from the modem pool to the NetCache appliance at the POP.
If a NetCache appliance has the object in its cache, it returns the object to the client. Otherwise, the NetCache appliance redirects the request to the data center.

At the data center

Configuration is as follows:

In this case, one switch is sufficient for the number of routers and NetCache appliances.
Transparency is enabled on all the NetCache appliances at the data center.
The switch at the data center is configured to be aware of all the NetCache appliances at the data center.

Traffic is handled as follows:

The switch distributes requests over all the NetCache appliances at the data center.
If none of the NetCache appliances at the data center has the requested object, NetCache sends the request directly to the Internet.

Disadvantage of the topology in Example 3

Noncacheable objects requested through the POP's NetCache appliance are also transparently processed by the proxying set up at the data center. Therefore, noncacheable objects are processed by two proxying sites before the object is requested from the Internet, resulting in an increased load on the NetCache appliances at the data center, an increased response time, and lower hit rates.

Because all clients connect to the POP, enabling transparent proxying at the data center is not necessary, unless the NetCache appliance at the POP fails.

How to avoid the disadvantage of the topology in Example 3

Ways to avoid the disadvantage noted for Example 3 are as follows:

Use an L7 switch instead of an L4 switch, configuring it so that requests for noncacheable objects are sent directly to the origin server, thus bypassing the NetCache appliance completely. For this approach to be successful, your firewall must be configured to allow direct access to origin servers from clients on your network.
Use a NetCache logical hierarchy to query caches and distribute requests. See Section A, Request resolution hierarchies and Example 2: some clients connect directly to the ISP, network hub, or data center for variations of the deployment in Example 3.