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

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

Yes. Quite. I'm running 12.1(3) T IP. Doesn't the T designate an
early-release (aka beta?) I'm working on getting and installing a
different IOS version to test this.

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

Fragmented yes, but not truncated. Fragmented or not, the GRE packet
should be 1500 bytes, no? It wouldn't surprise me if the underlying packet
ended up truncated - but even if I disable ip_wccp, and only let the raw
GRE packets come through, tcpdump still complains that they are truncated.

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