Re: Undersize errors on switch port

cisco-cg77 · ‎02-24-2012

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

acampbell · ‎02-24-2012

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

Regards, Alex. Please rate useful posts.

Peter Paluch · ‎02-24-2012

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

Peter Paluch · ‎02-24-2012

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

cisco-cg77 · ‎02-24-2012

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

Peter Paluch · ‎02-24-2012

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

cisco-cg77 · ‎02-29-2012

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

Peter Paluch · ‎03-05-2012

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

gagan0001 · ‎09-21-2017

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