06-04-2007 04:29 AM - edited 03-05-2019 04:28 PM
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
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!
06-08-2007 10:03 AM
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
06-08-2007 10:19 AM
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.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: