[c-nsp] 6500, WCCPv2 (over GRE), GRE packets generated not obeying the outgoing interface MTU ?

[Lincoln Dale (ltd)]

> While the interfaces on the 6504 are GigE, they currently have their
> MTUs set to 1500 bytes. The cacheflows also have 1500 byte MTUs as
> they only have Fast Ethernet interfaces.
> 
> We're having strange connection timeouts, which looks like MTU issues
> (quite experienced with them, have them all the time with our PPPoE /
> PPPoA connected DSL customers). While my desktop PC doesn't work with
> a default 1500 byte MTU, if I manually set the MTU down to 1400 bytes
> on my desktop PC, everything works correctly, further pointing to MTU
> issues.
[..]
> By enabling some debugging, we've managed to capture the following (IP
> addresses replaced) :
> 
> --
> 000604: May 16 13:52:04.832: IP: s=1.1.1.1 (GigabitEthernet3/47),
> d=3.3.3.3 (GigabitEthernet3/47), g=2.2.2.2, len 1528, forward
> 000605: May 16 13:52:04.832: IP: s=1.1.1.1 (GigabitEthernet3/47),
> d=3.3.3.3 (GigabitEthernet3/47), len 1500, sending fragment
> 000606: May 16 13:52:04.832: IP: s=1.1.1.1 (GigabitEthernet3/47),
> d=3.3.3.3 (GigabitEthernet3/47), len 48, sending last fragment
> --

the problem lies with CacheFlow and their WCCP implementation.
it is a CacheFlow bug not a Cisco one.

the debugs show you that the cat6k is correctly 'fragmenting' the packet
as it should.  very likely that the CacheFlow TCP stack can't deal with
those fragmented packets ...

over the course of the last 6 years, CacheFlow have been told of this
numerous times both by various Cisco representatives and by many
customers ...


cheers,

lincoln.
NB. wouldn't recommend using GRE method with WCCP on cat6k.  it results
in SOFTWARE-based forwarding of those packets.  you'd be best using the
hardware-accelerated WCCP modes available on the cat6k.  of course, I'm
not so sure CacheFlow support those.......