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

At 08:47 AM 12/14/2000 +0100, you wrote:
>Nathan Lewis 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.

I'm running 12.1(3)T IP on a Cisco 2610 (Cisco part number
S26C-12103T)....hmmmmm. Smells fishy. I'd search the list, but I can't
seem to connect to it right now. Which month was this so I can look in the
archives a little more closely?

Lincoln - this seems like a viable alternative to the MTU problem (since it
is the actual GRE packet which is truncated, not the underlying www
request, as would be implied by an MTU problem). I think I requested the
latest version of IOS for my Cisco 2610. Would I have to go back down to
12.0, or is there a 12.1(5)T available for the 2600 series, as is implied
by the above message?

>One example of a serverely truncated packet:
>
>16:25:02.006781 < truncated-ip - 28 bytes missing!gre XX.XX.XX.XX
>XX.XX.XX.XX: [] gre-proto-0x883E (ttl 255, id 146)
> 4500 004a 0092 0000 ff2f 1af4 XXXX XXXX
> XXXX XXXX 0000 883e 4500 0028 c717 4000
> 7e06 9a62 XXXX XXXX 0000 0000 0000
>
>And the few packets that got thru the router non-truncated quite often
>had a couble of random garbage appended after the encapsulated packet.
>
>Example with 2 bytes of garbage:
>
>16:25:01.403410 < gre XX.XX.XX.XX > XX.XX.XX.XX: [] gre-proto-0x883E
>(ttl 255, id 144)
> 4500 0046 0090 0000 ff2f 1afa XXXX XXXX
> XXXX XXXX 0000 883e 4500 002c 5120 4000
> 1e06 db58 XXXX XXXX cff6 90ce 060a 0050
> 0072 f010 0000 0000 6002 2000 50f6 0000
> 0204 05b4 6a2f
>
>
>
>The above tcpdumps are using the -x option to have the received packet
>dumped, and -s 1600 to make sure all of the packet is captured.
>
>
>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. 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.
>
>--
>Henrik Nordstrom
>Squid hacker

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