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

[Lincoln Dale (ltd)]

> > 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.
> >
> 
> I agree it should doing that.

the other part that makes this 'hard' to diagnose is that it isn't that
common to receive 'large' packets from the HTTP client.  i.e. typically
takes a large POST or PUT to see the issue..

I remember writing the code on the Cisco caching box oh about 10 years
ago and had to put in the MSS thing then. :)

> One thing that is confusing about this, which why it suggests an issue
> with the 6500, is that we don't have the problem at all with a 7301
> with the same WCCP settings, although it is running a 12.3 IOS verses
> a 12.2 variant on the 6500.

yes - 6500 and 7301 are quite different animals.  a 6500 will do almost
all of its forwarding in hardware (ideally it will do 100% - but since
CacheFlow don't support WCCP's "hash mask" operation, that won't be
possible).

another way of working around this would be to see if CacheFlow can use
"layer-2" (non-GRE) WCCP mode.
don't think they support that either unfortunately...


cheers,

lincoln.
> 
> Thanks,
> Mark.
> 
> 
> 
> >
> > 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.
> >