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

[Ian Cox]

At 01:52 PM 7/5/2006 -0500, Charles Spurgeon wrote:
>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...

If a frame is greater than 1518 / 1522 with a 1q tag, the giant 
counter is incremented. Only the WS-X6148 cards at present have 
additional counters that take into configured MTU on the interface.


Ian

>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/
>_______________________________________________
>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/