[c-nsp] jumbo MTU on WS-X6704-10GE

[Charles Spurgeon]

I would expect to see the Ethernet oversized error counter increment
for every frame received that was larger than 1518 bytes (make that
1522 bytes for frames with a VLAN tag in them).  The Ethernet standard
specifies that any frame larger than the max in the standard is an
oversize error.

Jumbo frames are not part of the Ethernet standard. Therefore, the
frame counters below are correctly incrementing for non-standard
oversized frames.

Presumably the 1GigE interface should have been incrementing the
oversized counters as well.  But since you report in a followup that
the counter isn't incrementing, then perhaps it's a bug in the 1GigE
int code.

Or it might be that when a non-standard Ethernet MTU is configured
they decided not to increment the oversized frame error counter to
avoid getting worried calls from the customers. Only Cisco knows for
sure...

Thanks,

-Charles

Charles E. Spurgeon / UTnet
UT Austin ITS / Networking
c.spurgeon at its.utexas.edu / 512.475.9265

On Wed, Jul 05, 2006 at 01:02:07PM +0100, A.L.M.Buxey at lboro.ac.uk wrote:
> hi,
> 
> run into an interesting one, wonder if someone can help. 
> 
> we have several 10GbE links, run from WS-X6704-10GE modules
> on Sup720 powered 6509e chassis.  2 of them dont have any requirement
> to carry jumbo frames...and on those we see no problem. however,
> one of the links is taking over from a 1GbE link (fed from WS-X6724-SFP
> modules) which had 9000 MTU traffic running through it. from the
> specs, the 10GbE module has a max of 9216..which is what the 
> system jumbomtu has been set for..as well as an instruction on the
> interface to handle...so, the config for the interface looks like:
> 
> interface TenGigabitEthernet2/1
>  description 10GbE jumbomtu interlink
>  mtu 9216
>  no ip address
>  logging event link-status
>  switchport
>  switchport trunk encapsulation dot1q
>  switchport trunk native vlan 708
>  switchport trunk allowed vlan 100,120,280,708,736
>  switchport mode trunk
> 
> however, in the counters, we see this:
> 
> 32 bit counters:
>  0.                   rxCRCAlignErrors = 0
>  1.                   rxUndersizedPkts = 0
>  2.                    rxOversizedPkts = 203234
>  3.                     rxFragmentPkts = 0
>  4.                          rxJabbers = 0
>  5.                       txCollisions = 0
>  6.                         ifInErrors = 37
>  7.                        ifOutErrors = 0
>  8.                       ifInDiscards = 37
>  9.                  ifInUnknownProtos = 37
> 10.                      ifOutDiscards = 0
> 11.            txDelayExceededDiscards = 0
> 12.                              txCRC = 0
> 13.                         linkChange = 0
> 14.                   wrongEncapFrames = 37
> 
> 
> on our other links, which dont have jumbo/mtu , all these values are
> a nice , beautiful '0'..which is exactly what we like to see :-)
> 
> can anyone shed some info on this peculiarity?  IOS is 12.2(17d)SXB
> on all involved routers (ie those with happy 10GbE and those with errors)
> 
> alan
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/