Incrementing Giants

Unanswered Question
Jun 4th, 2007

Hello, I am running a 6513 with a Sup 720 and several different types of linecards. On several modules in particular we have jumboframes enabled on various ports. The model of these modules is WS-X6748-GE-TX. For example here is a port config --


interface GigabitEthernet9/45

description xxxxxx


switchport access vlan 17

switchport mode access

mtu 9216

no ip address

speed 1000

duplex full

One thing I am noticing on these various ports is despite having jumboframes enabled we are logging giants on the port

igabitEthernet9/45 is up, line protocol is up (connected)

Hardware is C6k 1000Mb 802.3, address is 0018.7354.f10c (bia 0018.7354.f10c)

Description: xxxxxx

MTU 9216 bytes, BW 1000000 Kbit, DLY 10 usec,

reliability 255/255, txload 4/255, rxload 1/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 1000Mb/s

input flow-control is off, output flow-control is on

Clock mode is auto

ARP type: ARPA, ARP Timeout 04:00:00

Last input never, output 00:00:10, output hang never

Last clearing of "show interface" counters 00:12:51

Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 1242000 bits/sec, 438 packets/sec

5 minute output rate 17449000 bits/sec, 551 packets/sec

314333 packets input, 119296767 bytes, 0 no buffer

Received 11 broadcasts (0 multicasts)

0 runts, 8312 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

0 watchdog, 0 multicast, 0 pause input

0 input packets with dribble condition detected

381145 packets output, 1346288124 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier, 0 PAUSE output

0 output buffer failures, 0 output buffers swapped out

My question is should I view these incrementing Giants as errors? We are experiencing some slow SAP performance (both devices in question are in the same vlan) and my fear is that for some reason frames are being fragmented due to the fact that the switch views these packets as having a non standard MTU size.

I have read in a few places that the increasing giants counter is normal even if the port is configured for jumboframes though I would like to confirm this is in fact the case. Hopefully these packets are being forwarded as jumboframes. Any assistance would be greatly appreciated!

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
smalkeric Fri, 06/08/2007 - 10:03

A possible workaround is to force the switchport to accept an extra four bytes of data by configuring it as a trunk.

When a port is enabled for 802.1q trunking (Inter-Switch Link (ISL) encapsulation is not supported on Supervisor I and II based switches), the switch will automatically assume that there is an extra four bytes of data appended on, incrementing the frame size of the Layer 2 (L2) packet. Therefore, for implementations that require exactly only one tag to be carried (either 802.1q or Multiprotocol Label Switching (MPLS), but not both), it is possible to force the switchport to accept an extra four bytes of data by configuring it as a trunk port.

For example, if a port needs to carry an MPLS label, configure the port as an 802.1q trunk by changing the native VLAN to be the one desired to carry the traffic

asudog1080 Fri, 06/08/2007 - 10:19

I appreciate the information concerning a workaround.

I am still curious though, should I be concerned with these incrementing errors (ie. will it cause a discard etc.)?

If this is simply just an fyi on the port that a larger than standard mtu has been forwarded then I am not too concerned.


This Discussion