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 - 12:39:31 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:53:00 MST