[c-nsp] jumbo MTU on WS-X6704-10GE
David Sinn
dsinn at dsinn.com
Wed Jul 5 16:49:10 EDT 2006
So, your comments made me re-look at what I'm seeing and while it may
not be related to configuration changes as I first thought, I'm not
seeing giant's incrementing where I would expect based on the comments.
I have two interfaces that are .1q'ed and neither are showing giant
counters incrementing. One is with dot-sub-interfaces, the other is
a more traditional trunk going to VLAN interfaces. One is currently
pushing 40Kpps of 9k packets, and the other was receiving 9k packets
earlier in the week (troubleshooting a jumbo clean path... ;)
TenGigabitEthernet2/2 is up, line protocol is up (connected)
5 minute input rate 1604184000 bits/sec, 41687 packets/sec
5 minute output rate 255314000 bits/sec, 21001 packets/sec
0 runts, 29065 giants, 0 throttles <----- Not incrementing.
Vlan60 is up, line protocol is up
5 minute input rate 1617612000 bits/sec, 42076 packets/sec
5 minute output rate 1000 bits/sec, 1 packets/sec
L2 Switched: ucast: 161486 pkt, 850433676 bytes - mcast: 4441382
pkt, 299456186 bytes
L3 in Switched: ucast: 45629470992 pkt, 176148351510954 bytes -
mcast: 7271147944 pkt, 59289495996248 bytes mcast
L3 out Switched: ucast: 60201400 pkt, 20653413425 bytes mcast:
4054464289 pkt, 33087720212902 bytes
0 runts, 0 giants, 48 throttles
Vlan61 is up, line protocol is up
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 248949000 bits/sec, 20531 packets/sec
L2 Switched: ucast: 715 pkt, 47876 bytes - mcast: 752824 pkt,
51563616 bytes
L3 in Switched: ucast: 127053321 pkt, 13294286484 bytes - mcast:
7229010760 pkt, 58960443776240 bytes mcast
L3 out Switched: ucast: 36734974702 pkt, 103607468431523 bytes
mcast: 0 pkt, 0 bytes
0 runts, 0 giants, 48 throttles
The interfaces I earlier attributed to having been "modified" are
also different because they are routed, not trunk interfaces:
(The next router "up the stack: from the router above)
TenGigabitEthernet3/4 is up, line protocol is up (connected)
5 minute input rate 1348287000 bits/sec, 20685 packets/sec
5 minute output rate 4000 bits/sec, 4 packets/sec
L2 Switched: ucast: 16565 pkt, 1887327 bytes - mcast: 985198 pkt,
98077197 bytes
L3 in Switched: ucast: 9163641553 pkt, 72704490444324 bytes -
mcast: 3740031 pkt, 30495654993 bytes mcast
L3 out Switched: ucast: 180121319 pkt, 41103115390 bytes mcast:
7889315942 pkt, 10759980763094 bytes
0 runts, 317600238 giants, 20 throttles <--- Incrementing at
20KPPS
All of these are 6704-10GE ports.
Are the giants on the VLAN ports being masked?
David
On Jul 5, 2006, at 1:11 PM, Ian Cox wrote:
> 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/
> _______________________________________________
> 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/fc606de6/attachment.bin
More information about the cisco-nsp
mailing list