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

[Lincoln Dale (ltd)]

I am not sure if the 'logging' from a c6k is accurate or not - it may
well be that there is fragmentation taking place.

in either case, it is still a CacheFlow bug.  in the TCP 3-way handshake
for the HTTP connection they are intercepting, they should be
negotiating a TCP MSS such that fragmentation shouldn't occur.


cheers,

lincoln.

> -----Original Message-----
> From: Mark Zipp [mailto:mark.r.zipp at gmail.com]
> Sent: Thursday, 18 May 2006 11:03 AM
> To: Lincoln Dale (ltd)
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] 6500, WCCPv2 (over GRE),GRE packets generated not
> obeying the outgoing interface MTU ?
> 
> 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.