Re: Cisco Cache Director (Was RE: Does Squid beat the rest?

In message <9709201423.ZM5667@renard.watching.org>, "James R Grinter" writes:
>>You can install multiple ones in a group to sit alongside each other and
>>load share - but the way the sharing is done is extremely simple (takes
>>a hash of the hostname) - so all of www.microsoft.com would go to the same
>>box.
>
>Are you sure? It implied that it did it based upon allocated chunks of address
>space to different units. (which would make more sense. It's the router that
>does the distribution.) So as Microsoft use many addresses for their
>servers it could get very messy. Questions I'd like to have answered are 1.
>Does it look at Host headers to achieve better/ more efficient caching? 2.

i asked this question at the release of it, our local friendly cisco person
came back with the explanation from the developers.

it works like this:
 - it does a hash of the ip address of the request, to determine which
   cisco cache director to feed the request to, in the event of there being
   a pool of them.

 - the cisco cache directors have a protocol that they can talk between them,
   asking if the other ones have an item. this is obviously based on the URL.

   by default, this is only enabled when the number of caches in the pool
   changes (ie. a new cache deployed / brought online / took offline), and is
   dynamic, but this is a configurable parameter.

when it comes down to is that it is an order of magnitude harder for a router
to parse a HTTP request header than to just pick out a web request (given its in
the fast-switch path, it would be extremely difficult to implement it in a
manner that scales).

in relation to someone elses question on the list: is this the same as squid/netapp
cache with transparent proxying?

no, it is not. you needed a method to get the request fed to the cache machine in
the first place. this either meant the packet naturally flowing through the proxy
box (it acting as a router), or a means to get the packet to the box in the first
place (read: on a cisco, policy-based routing. ie. something that is process-
switched == doesn't scale). cisco have now implemented something in the fast-switch
path that can do this.

hopefully they will make their protocol public-knowledge, so people who have
already invested in large-cache technology don't need to throw away their existing
investment. (i've suggested that cisco make the cisco local-director product
know the technology in some way, via some configuration item.

ideally, they'll make the WCCP protocol public-knowledge.

cheers,

lincoln.
Received on Sat Sep 20 1997 - 07:25:30 MDT