Undersize errors
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-24-2012 03:18 AM - edited 03-07-2019 05:09 AM
Hello
I have one 2950 switch that concentrate three other 2960 switches. On each 2960 I observe "Undersize" errors on the uplink interfaces that connect to the 2950.
DEE-SR1L-S1#sh int counters errors
Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize
Fa0/46 0 0 0 5 0
Fa0/47 0 0 0 0 0
Fa0/48 0 0 0 0 0
Gi0/1 0 0 0 0 7065589
and five seconds later
Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize
Fa0/46 0 0 0 5 0
Fa0/47 0 0 0 0 0
Fa0/48 0 0 0 0 0
Gi0/1 0 0 0 0 7065634
From what I've read, It seems that "undersize" packets will be dropped by the switch. I've read that it should came from some dot1q encapsulation behavior.
Here is some details, (configs, and sh commands output)s from the switches:
Hostname "DEE-RGI-S1" --> 2950
Hostname "DEE-SR1L-S1" --> One of the 2960
DEE-RGI-S1#sh interface FastEthernet0/7
interface FastEthernet0/7
description Lien vers DEE-SR1L-S1
switchport mode trunk
switchport nonegotiate
no ip address
spanning-tree portfast
DEE-RGI-S1#sh int FA0/7 switchport
Name: Fa0/7
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: trunk
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
Negotiation of Trunking: Off
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Protected: false
Voice VLAN: none (Inactive)
Appliance trust: none
DEE-SR1L-S1# sh int gi 0/1 sw
Name: Gi0/1
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: trunk
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
Negotiation of Trunking: Off
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: enabled
Voice VLAN: none
Administrative private-vlan host-association: none
Administrative private-vlan mapping: none
Administrative private-vlan trunk native VLAN: none
Administrative private-vlan trunk Native VLAN tagging: enabled
Administrative private-vlan trunk encapsulation: dot1q
Administrative private-vlan trunk normal VLANs: none
Administrative private-vlan trunk private VLANs: none
Operational private-vlan: none
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL
Protected: false
Unknown unicast blocked: disabled
Unknown multicast blocked: disabled
Appliance trust: none
As anyone an advice, or some ideas to solve this problem? This problem impacts small packets so I've read that It can obviously impacts TCP Ack. In fact, I have users that experienced very large application delay.
Thanks for any help
- Labels:
-
Other Switching
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-24-2012 04:04 AM
Hi,
This may be being caused by duplex mismatch on the Gigabit interfaces.
Can you
show interface g0/X status
at both ends of your links
Regards
Alex
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-24-2012 04:12 AM
Hello Alex,
Good point! However, the counters as displayed do not support this assumption in this particular case. The duplex mismatches would be shown as
- undersized frames + FCS-err + Align-err on the full-duplex side
- excessive collisions including late collisions on the half-duplex size (no undersized frames on the half-duplex size should show up)
However, the state of the error counters as posted by Jean-Claude does not fit within these symptoms.
Best regards,
Peter
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-24-2012 04:09 AM
Hi Jean-Claude,
It is quite probable that this problem is indeed caused by frame untagging. A scenario when that can happen is:
- An end station emits a tagged frame - either because it is using CoS priority marking or because it uses VLAN subinterfaces itself. Assume that this frame, including the 802.1Q, is padded to the minimum size of 64 bytes. This appears to be a common mistake in many 802.1Q implementations to not to pad tagged frames to 68 bytes instead of 64 - I've seen even Cisco devices "forgetting" that a the frame will be eventually untagged, and producing a 64-byte tagged frame. From a software point of view, it is quite natural, though: tagging the frame is just adding a couple of bytes into the frame's payload, and the bigger the payload, the smaller the resulting padding needs to be.
- The frame is delivered via a switch. The switch will remove this tag under these circumstances:
- The frame is sent out via another access port
- The frame is sent out via a trunk port and the frame's VLAN is identical to the native VLAN on this trunk
Do you see any of these situations happening?
Preventing the untagging on a trunk port due to native VLAN can be easily remedied: the native VLAN on trunks should be a separate VLAN which is not used for any data traffic, i.e. a separate VLAN created just for the sake of being the native VLAN but otherwise absolutely unused.
However, if it is an end device that produces tagged frames between 64-67 bytes of length then it is this device's operating system or NIC driver that must be corrected. Optionally, the device should be reconfigured to not use any tagging itself.
Best regards,
Peter
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-24-2012 05:34 AM
Hello Peter,
Thanks for your response. My native VLAN (1) is not the same as my Data Vlan (144). Have an idea about How can I detect an end device that produces tagged frames between 64-67 bytes?
Thx
Jc
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-24-2012 08:49 AM
Hello Jean-Claude,
This is not going to be easy, unfortunately.
You should verify each port X on each of your switches using the show interface X controller command: in this output, look for the following lines:
Transmit GigabitEthernet0/1 Receive
547 Bytes 186 Bytes
0 Unicast frames 0 Unicast frames
2 Multicast frames 1 Multicast frames
0 Broadcast frames 1 Broadcast frames
0 Too old frames 0 Unicast bytes
0 Deferred frames 90 Multicast bytes
0 MTU exceeded frames 96 Broadcast bytes
0 1 collision frames 0 Alignment errors
0 2 collision frames 0 FCS errors
0 3 collision frames 0 Oversize frames
0 4 collision frames 0 Undersize frames
0 5 collision frames 0 Collision fragments
0 6 collision frames
0 7 collision frames 0 Minimum size frames
0 8 collision frames 2 65 to 127 byte frames
0 9 collision frames 0 128 to 255 byte frames
0 10 collision frames 0 256 to 511 byte frames
0 11 collision frames 0 512 to 1023 byte frames
0 12 collision frames 0 1024 to 1518 byte frames
0 13 collision frames 0 Overrun frames
0 14 collision frames 0 Pause frames
0 15 collision frames
0 Excessive collisions 0 Symbol error frames
0 Late collisions 0 Invalid frames, too large
0 VLAN discard frames 0 Valid frames, too large
0 Excess defer frames 0 Invalid frames, too small
1 64 byte frames 0 Valid frames, too small
0 127 byte frames
0 255 byte frames 0 Too old frames
1 511 byte frames 0 Valid oversize frames
0 1023 byte frames 0 System FCS error frames
0 1518 byte frames 0 RxPortFifoFull drop frame
0 Too large frames
0 Good (1 coll) frames
0 Good (>1 coll) frames
Follow the ports that show non-zero or large counts of small frames to find out what devices are they connected to. Obviously, this has to be verified on each and every port of all your switches. Quite a detective work on your hands here...
Also, are you aware of any of your end devices using 802.1Q tagging or sending QoS-marked data? You should preferentially verify those.
Best regards,
Peter
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-29-2012 03:01 AM
Thx Peter,
I have identified the source of these "Undersize packets". They comes from the CE router connected to the FA0/1 int of the 2950 switch, that I have replaced yesterday by a 3560.
I think it is a config issue (related to the trunk vlan config you mentionned before). I will ask our provider.
Can you confirm that these packets are dropped by the switch?
I noticed that after replacing the 2950 by a 3560, these Undersized packets doesn't appear anymore on the uplink interfaces of the 2960 switch, like they are no more forwarded by the 3560. Any idea about that?
Best regards,
Jc
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-05-2012 08:20 AM
Hello Jean-Claude,
I am not sure how the switches actually react to undersized frames - whether they drop them, pad them to minimum length or forward them unmodified.
In any case, what is the exact type of the CE router producing these undersized frames, and what exact IOS version and feature set does it run? I have performed tests with 1841 running 15.1(4)M2 and 12.4(24)d IOSes and they properly pad their tagged frames so that if they are untagged, they are never smaller than 64 bytes. Perhaps an appropriate IOS upgrade on the CE router could solve the issue here.
Best regards,
Peter
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-21-2017 04:14 AM
HI,
I am getting undersize error on port that is going towards router.I am not sure what is the reason behind it.Please guide me how can i stop increasing undersize error on port & what is the reason behind it.
Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize
Gi1/0/1 0 0 0 0 5525
