RE: [SQU] More on WCCP and truncated GRE packets. --HELP

From: Lincoln Dale <ltd@dont-contact.us>
Date: Wed, 13 Dec 2000 14:43:36 -0800

yes, you could just increase the MTU on the cisco router to something
larger than 1500.
but remember that the MTU is at 1500 for a _reason_.

it all has to do with what the "standard" for ethernet allows.

note that i'm NOT suggesting that you "implement a company-wide policy
MTU"; far from it.
i'm suggesting that _squid_ or your unix host running squid could enforce
the MSS (maximum-segment-size) in tcp for tcp flows destined for your cache
to ensure that tcp frames cannot be fragmented.

the TCP MSS is a negotiated tcp option during the tcp 3-way handshake. no
[company-wide] client configuration would be required.

cheers,

liincoln.

At 04:34 PM 13/12/2000 -0600, Nathan Lewis wrote:
>Isn't there a way to just set the MTU on the Cisco router to at least
>(size of clientMTU) + 24? This would be easier than trying to implement a
>company-wide policy MTU....
>
>>actually, that highlights part of the issue.
>>
>>in the case of a 'large packet' where adding a GRE header + new IP header
>>causes the frame size to exceed the MTU, the router will have to fragment
>>the packet.
>>that then means that the GRE-tunnel-termination point (the ip_wccp module
>>in linux) would need to be capable of handling reassembly of tcp
>>fragments when the fragments are received inside a GRE tunnel.
>>
>>i am not familiar with the ip_wccp code to know if this is the case or
>>not. given the failure condition, i'm guessing that it isn't.
>>
>>if this is the case, the workaround stated above (squid enforce the
>>client-side MSS to something such that fragmentation cannot occur) will
>>cause the problem to go away.
>>
>>
>>cheers,
>>
>>lincoln.

--
To unsubscribe, see http://www.squid-cache.org/mailing-lists.html
Received on Wed Dec 13 2000 - 15:47:49 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:56:57 MST