[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:
> > > 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 idea I had was to perform the MSS hack on TCP Port 80, by policy
routing _only_ TCP SYNs destined to port 80 to a loopback, and then
have the MSS hack applied as they looped back into the loopback
interface e.g.

--
int loopback0
  ip address 1.1.1.1 255.255.255.252
  ip tcp adjust-mss 1430

access-list 100 permit tcp any any eq 80 syn

route-map WCCP_MSS_HACK permit
  match ip address 100
  set ip next-hop 1.1.1.2
--

As the TCP Syns were looped back into the router after having being
"sent" out to 1.1.1.2, the MSS hack would be applied to it on the way
back in. Probably a RP CPU hit for those packets, however I figured it
wouldn't be too many for it to handle, at least as a work around.
Unfortunately the 6500's IOS doesn't seem to support that command,
which dashed my hopes for a neat hack to fix it, at least temporarily
:-(



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

Well, the work around we've come up with while the TAC are looking
into it is to put the 7300 back in place, directly attached to the
6500, running WCCP, and have the just 6500 policy route TCP port 80
traffic to it. That's been working for the last 18 hours or so, so we
at least have the caching back in place.

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