Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
New Member

802.1q tagged to untagged VLAN frame padding

When a 64 byte 802.1q tagged Ethernet framed is received over a trunk port on a L2/L3 6509 and is routed/forwarded to an untagged access port the 802.1q tag is reduced and frame size reduced by 4 bytes. Should the 6509 switch be adding the additional 4 bytes of padding to meet the ieee 64 byte spec minimum OR should the originating host pad to 68 bytes so that the frame remains valid after removing tagging. I've read the 802.1Q IEEE spec and find the information somewhat contradictory.

This is not hypothetical, I actually have a device transmitting 64 byte tagged frames as described that are being dropped by the switch. I've attached an inline network tap and can see the frame being transmitted over the wire however a sniffer connected to a span port on the 6509 does not record the frame, it simply appears as though it's never been received. In addition there are no errors on the port including runts.

Cisco Employee

Re: 802.1q tagged to untagged VLAN frame padding

Hello Scott,

A most interesting question! :) I don't know the answer right away. In a couple of hours I'll be in lab so I'll give it a try on some of our switches and tell you the results. And perhaps somebody here will be able to answer you even sooner.

Best regards,


New Member

Re: 802.1q tagged to untagged VLAN frame padding

I can assure you with IOS 12.2(27)S2 these 64 byte tagged frames get dropped when they are untagged but I am very curious what you find your in lab and appreciative of the effort.

In doing some additional research I found the following statement in the Cisco ISL and IEEE 802.1q frame format document.

Frame Size

The 802.1Q tag is 4 bytes. Therefore, the resulting Ethernet frame can be as large as 1522 bytes. The minimum size of the Ethernet frame with 802.1Q tagging is 68 bytes.

But in the IEEE 802.1Q-2005 spec I find this.

C.4.4.3 Minimum PDU size

VLAN untagging of a tagged frame results in the original frame decreasing in length.

Where the destination MAC is CSMA/CD:

a) If untagging a given frame would result in violation of the minimum frame length requirements of

CSMA/CD, the Bridge is required to adjust the PAD field to ensure that the frame length equals the

minimum length of 64 octets (7.2 and C.4.4.1);

Which gives me the impression the switch should be padding the frame. Hence my confusion.

I have a bad feeling this is boiling down to conflicting interpretations of the spec by Cisco and vendor of the wireless controller that is sending 64 byte tagged frames.


Cisco Employee

Re: 802.1q tagged to untagged VLAN frame padding


I have done tests with an 1841 router and Cat2960 running 12.2(50)SE1. I have configured a subinterface on the 1841 in the VLAN20 and linked it to a trunk port on the Cat2960. On another trunk port on the same Cat2960, I have configured the VLAN20 as the native VLAN.

Then, I have pinged a non-existent IP address from the router. The router started sending ARPs encapsulated into 802.1Q-tagged frames. These frames were exactly 64B long and they contained a fairly large trailer part (around 18B). After this frame was sent out the second trunk from the switch, the frames got cut down to 60B - just the 802.1Q tag was removed but the trailer was not extended to maintain the minimum frame size. Essentially, the Cat2960 produced an undersized frame.

Subsequently, I have connected the trunk with the native VLAN20 to yet another switch (the same type and the same IOS version). That switch happily accepted the undersized frames and forwarded them further. No runts or undersized frame counters increased - all remained at 0. However, the frames also remained at 60B length.

So now I am confused - and I'm afraid I have just added to your confusion as well. How does Cisco define "a runt"? Is it correct for a Catalyst switch to produce undersized frames by untagging them?

And we owe all this to the native VLAN concept... it brings far more trouble than solves things.

Best regards,


New Member

Re: 802.1q tagged to untagged VLAN frame padding

one of our customer was also having this issue.

we looked further into it and was able to duplicate the problem.

( pc -- 1841 --[802.1Q]-- 2960 --[802.1Q]-- traffic generator (

pc was sending 59 bytes (on the wire) with command, ping -l 17 -t

i'll attach traces from both ends - pc (sender) and traffic generator (receiver)


New Member

Re: 802.1q tagged to untagged VLAN frame padding

here is a trace.

New Member

Re: 802.1q tagged to untagged VLAN frame padding

and the sender trace

New Member

Re: 802.1q tagged to untagged VLAN frame padding

here's my guess.

the switchport does not include the trailer (ie, padding) when calculating the minimum frame size of 60 bytes without CRC. the counters increment, yet traffic is still forwarded.

looks to be a cosmetic issue.

Super Bronze

Re: 802.1q tagged to untagged VLAN frame padding

The IEEE info Scott provided makes sense, I think. The contradiction appears to be from Cisco information. I would go with the IEEE information.

From both Scott's in-the-field and Peter's lab results; smells to me like incorrect VLAN tag and frame size processing to handle a "corner case" on different equipment.

Assuming this is indeed a "software defect", and knowing even Cisco occasionally has them, these results might brought to their attention (TAC). At least Cisco usually corrects them.

New Member

Re: 802.1q tagged to untagged VLAN frame padding

My issue was resolved today by a TAC escalation engineer. Our problem was a known bug in Cisco 6509 modules WS-X6148 HW rev <3.0 and WS-X6548 HW rev <4.0 modules as noted in 2004 Field Notice CSCeb67650. In our case we had a rev 3.0 WS-X6548.

Based on this information and the information I learned from the TAC escalation engineer that if during the process of untagging a frame the frame no longer meets the 64 byte minimum MTU as specified in the IEEE 802.1q spec the switch should pad the frame back to 64 bytes.

Thanks to all that responded to my question.

CreatePlease to create content