Re: WCCP - cache only , no proxy

I have not done it completely But I am working to add this feature in my
squid so that it can talk to multiple router. Let see.:-))

With Regards
Ahsan Khan
Sr. System Admin
Internet Division (OneNet)
Sun Communication Pvt. Ltd.
Pakistan
http://www.one.net.pk

----- Original Message -----
From: "Garlic" <garlic@garlic.com>
To: "Lincoln Dale" <ltd@cisco.com>; <squid-users@ircache.net>
Sent: Saturday, April 22, 2000 11:37 PM
Subject: Re: WCCP - cache only , no proxy

>
> The problem is that a single squid cache can only communicate with one
router
> since its stuck in WCCP V1. It would be nice if Cisco gave a license for
V2 to
> the squid developers!
>
> Lincoln Dale wrote:
>
> > At 01:06 20/04/00, fooler wrote:
> > >if i understand you correctly what you mean here, to avoid ip
> > >fragmentation in a
> > >transparent environment, im using a cisco switch using
_store_and_forward_ in
> > >switching mode to solve this problem.
> >
> > it is less of an issue on (say) a L2 ethernet switch, given there's no
> > reason to fragment at layer-2.
> > (when did you last use an ethernet switch that forced you to a MTU of
576
> > bytes? :-) )
> >
> > the issue is more one of (say) dial-up users whose IP stacks have set a
MTU
> > of 576 on a dial connection.
> >
> > the absolute 'recommended' configuration would be to run WCCP on that
> > access-edge.
> >
> > ie.
> > a typical PoP would look something like this:
> >
> > ...............
> > : core router :
> > :.............:
> > | (switched {fast}ethernet)
> > -------------------------------------------------------
> > | (fastethernet) | |
> > .................... ................. ....................
> > :dial access-server: :DSL aggregation: ... :cable/wireless agg:
> > :..................: :...............: :..................:
> > | (ppp) | | | (atm) | | | (ppp) | |
> > | | | | | | | | |
> > dial dial isdn DSL DSL DSL HFC wireless
> > user user user user user user user users
> >
> > our recommendation would be to _always_ run WCCP on the access-servers
> > themselves (dial, DSL, cable, leased-line, ...) -- and thus any
> > 'fragmentation' is limited to the per-hop link between the customer and
the
> > interception/redirection point.
> >
> > any potential IP fragmentation issues will be taken care of
automatically,
> > since TCP MSS negotiation will be taking into account the path MTU.
> >
> > of course, there is still the potential for problems if those end-users
are
> > actually a network, and are using a lower MTU in their own network
cloud,
> > but i'm yet to see a 'problem' case yet.
> >
> > cheers,
> >
> > lincoln.
> >
> > --
> > Lincoln Dale Content Switching
> > ltd@cisco.com Cisco Systems Inc. | |
> > || ||
> > +1 (408) 525-1274 bldg G, 170 West Tasman |||| ||||
> > +61 (3) 9659-4294 << San Jose CA 95134 ..:||||||:..:||||||:..
>
Received on Sat Apr 22 2000 - 18:40:31 MDT