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

[David Sinn]

Looking at gear I have running Jumbo's, this looks to be a counter  
bug and (more interestingly) only one where you've added a interface  
post boot that needs jumbo's.

On all of the interfaces I have on boxes that were configured prior  
to the last reload, the giant counters are small and not  
incrementing, yet the box is validly carrying Jumbo traffic.

On all of the interfaces I have on boxes where I have turned up the  
interface since the system last booted, the counters are  
incrementing.  And for these interfaces I know they are validly  
receiving jumbo's and that the traffic is not being dropped.

So if I had to guess I would say they have some masking/fix-up during  
boot that isn't run when you make a on-the-fly change.

David

On Jul 5, 2006, at 5:02 AM, 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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : https://puck.nether.net/pipermail/cisco-nsp/attachments/20060705/8f00eabd/attachment.bin