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

[Mark Zipp]

Hi,

We've just recently put in production a 6504, which were were
intending to have perform WCCP towards some existing cacheflows we
have. We're running ADVIPSERVICESK9_WAN-M, 12.2(18)SXF4.

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.

We're having strange connection timeouts, which looks like MTU issues
(quite experienced with them, have them all the time with our PPPoE /
PPPoA connected DSL customers). While my desktop PC doesn't work with
a default 1500 byte MTU, if I manually set the MTU down to 1400 bytes
on my desktop PC, everything works correctly, further pointing to MTU
issues.

I'm going to log a TAC case about this, however I though I'd ask here
as well to see if anybody knows of a work around or has also had this
problem. I've looked up the bugs against this IOS release, and can't
see anything relevant.

By enabling some debugging, we've managed to capture the following (IP
addresses replaced) :

--
000604: May 16 13:52:04.832: IP: s=1.1.1.1 (GigabitEthernet3/47),
d=3.3.3.3 (GigabitEthernet3/47), g=2.2.2.2, len 1528, forward
000605: May 16 13:52:04.832: IP: s=1.1.1.1 (GigabitEthernet3/47),
d=3.3.3.3 (GigabitEthernet3/47), len 1500, sending fragment
000606: May 16 13:52:04.832: IP: s=1.1.1.1 (GigabitEthernet3/47),
d=3.3.3.3 (GigabitEthernet3/47), len 48, sending last fragment
--

We think the "len1528" entry is a problem - it seems to suggest that
the 6500 is issuing packets that are larger than the 1500 byte MTU of
the outgoing interface. Possibly it using the hardware's true MTU
value (e.g. 9KB) as the outgoing limit, rather than the 1500 byte MTU
set on the interface. 1528 would approximately correspond with a
standard 1500 byte packet plus another IP and GRE header.

Anybody else seen this before ?

Thanks,
Mark.