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

[Mark Zipp]

Hi Lincoln,

Thanks for getting back to me. I've realised I cut-and-pasted the
wrong debug output, probably because I was starting to get sleepy from
the 5.00am start yesterday :-)

On 16/05/06, Lincoln Dale (ltd) <ltd at cisco.com> wrote:
> > 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.
> >

Here's the debug output I should have posted. 1.1.1.1 represents the
IP address of the loopback of the 6500, the destination address is one
of the cacheflow proxy servers. This was the odd length one, where
there was no fragmentation :

--
000590: May 16 13:51:27.780: IP: tableid=0, s=1.1.1.1
(GigabitEthernet3/47), d=3.3.3.3 (GigabitEthernet3/47), routed via FIB
000591: May 16 13:51:27.780: IP: s=1.1.1.1 (GigabitEthernet3/47),
d=3.3.3.3 (GigabitEthernet3/47), len 1528, rcvd local pkt
--

>
>
> 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.......
>
Thanks, we'll keep that in mind. The Cacheflows don't seem to support
this option. I have come across a statement somewhere that with the
Sup7203BXL we have, there is a level of GRE hardware acceleration. One
thought we've had is that this hardware acceleration is using the
interface hardware MTU i.e. 9K rather than the IOS layer 2 MTU, which
is why it thinks it is okay to send >1500 byte payload ethernet
frames.

We've come up with a work around - we've made the 6500 policy route /
forward TCP port 80 port towards the 7300 we decomissioned and are
then having that perform the WCCP.

Regards,
Mark.