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

At 08:47 AM 14/12/2000 +0100, Henrik Nordstrom wrote:
> > 17:24:28.880017 eth0 < gre-proto-0x883E (gre encap)
> > 17:24:29.183191 eth0 < truncated-ip - 24 bytes missing!gre-proto-0x883E
> (gre encap)
>
> > truncated packets start coming in - ip_wccp ignores them - no
> > unencapsulated packets come through.
>
>Your problem very much looks like the IOS problem another user found
>some month ago.
>
>He found WCCP a Cisco 2621 gave truncated packets when using certain IOS
>version, sometimes even down to the IP header of the encapsulated
>packet.
>
> From trying different IOS versions he found that:
> IOS 12.1-3a did not work and gave truncated packets
> IOS 12.0-7T and IOS 12.1-5 worked fine.

odd.

>And MTU should rarely cause problems like this. It might cause
>fragmented packets and performance loss, but not truncated packets. I
>don't know at which level Cisco performs the fragmentation when doing
>GRE encapsulation (i.e. if before encapsulation, or after), but it
>should work either way.

fragmentation will happen on after the packet has been encapsulated into
the GRE packet itself. ie. the GRE packet will be fragmented.

> From a TCP/IP point of view if would be best if
>the fragmentation was done on the original packet and honouring the DF
>bit. This way MSS detection would work just as usual.

the issue is one of ensuring that packets never get fragmented prior to
hitting the interception router.
if the packet is already fragmented, then the router has no layer-4 state
information in the second fragment of the packet from which to deduce "this
is a packet destined towards tcp port 80".

all i can state is that on cisco's caching products, we explicitly cap the
advertised MSS in order to ensure that this is never a problem.
it should be possible for squid to do the same via the use of an
appropriate setsockopt() with the TCP_MAXSEG option.

cheers,

lincoln.

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