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

>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.

I think there may be too many layers here to do that. All of my clients
are running behind a freeBSD firewall, doing NAT. In front of the firewall
is the cache box (squid) and the router. So all web requests actually come
from the firewall, after being NAT'd. If you have a suggestion on how to
implement the MSS in this situation, I'd be grateful. Otherwise, where is
the MTU setting in Cisco IOS 12?

>did you look at my email address.
>"they" happens to be "me".

Yes. I caught that (after I hit Send, of course).

>i can tell you that you are most definitely mistaken if you believe that
>the failure is caused by cisco breaking the published protocol specification.

Fair enough.

>i can't see any problems with that. i'm not aware of any issues with that
>release of IOS regarding this..
>therefore, i think that the problem is as below

>you are thinking of something else.
>
>think about it. what should a router do if it receives an IP frame that
>is 1500 bytes long and it needs to put a 4-byte GRE header and a 40-byte
>IP frame on the front? that would make the packet 1544 bytes long.
>given that exceeds the MTU, what options are available?
>
>
>the answer is as follows:
> 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.

The author described the ip_wccp as a "hack". I've looked at the code - it
surely is. However, I have to deal with what I have here.

Nathan Lewis

Senior Network Administrator
nathan_lewis@uclid.com

----------------------------------------------------------------------
CONFIDENTIALITY NOTICE -- This email is ONLY for the person(s) named in
the message header. Unless otherwise indicated, it contains information
that is confidential, privileged or exempt from disclosure under applicable
law.

If you have received it in error, please notify the sender of the error and
delete the message. Thank you.
--------------------------------------------------------------------------

--
To unsubscribe, see http://www.squid-cache.org/mailing-lists.html