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

[Mark Zipp]

Hi Lincoln,

On 18/05/06, Lincoln Dale (ltd) <ltd at cisco.com> wrote:
> I am not sure if the 'logging' from a c6k is accurate or not - it may
> well be that there is fragmentation taking place.
>

Yes, as much as distributed routing is great for performance, it's
much harder to see what is really going on, in particular without
impacting performance :-)

> 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.

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.

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.
>