Thanks. I figured as much... but was desperate. Thanks again.

Euh, really?

I would expect a vlan unaware bridge to simply forward frames that are 1Q tag, ignoring the tag (the 1Q tagged frame is a perfectly valid frame for a vlan unaware bridge). The fact that it would drop frames that are 1Q tagged would mean that the bridge is vlan aware (and configured to not accept tagged frames).

Regards,

Francois

I have to agree with Francois. At my workplace we have an 877 at all of our locations trunked to 2950s at the newer locations and unmanaged DLINKs in the older locations. We have also been told that should a 2950 break down at any time to just go to the closet computer shop and buy an unmanaged switch which will do the job until a replacement 2950 is sent out.

It may be possible, I haven't tried it, and I'm still trying to find some online docs.

It would certainly fail for packets that are alreay max size when they are tagged. 802.1q adds four bytes of tag immedaitely after the Source Address, displacing the frame type & size field.

While many/most unmanaged switches don't care about frame type, they may look for size, to dynamically adjust buffer .... or they may have a static max buffer size of 1518 ... the largest a standard Ethernet frame would be (that, with tag, is now 1522 ... it would be considered a "giant" and be discarded).

So, at the least, an unmanaged switch/bridge would discard full-size 802.1q tagged frames ... frequently seen in things like network database applications. You *might* be able to squeak by if it was a cut-through style switch ... but most, if not all, switches today are running store & forward.

If I can find anything relevent, I'll post it up. Here's a link to a Cisco document that describes (with diagrams) the structure of the Ethernet frame that has been tagged (ISL and 802.1q).

http://www.cisco.com/en/US/tech/tk389/tk390/technologies_tech_note09186a0080094665.shtml

Good Luck

Scott

In fact, 802.1Q was designed so that the tagging mechanism is transparent for vlan-unaware device. The fact that vlans can be sent untagged on a trunk allows communicating with host that don't support 1p or 1q tagging. Vlan unaware bridges just ignore the 1q tag as an unknown ethertype, just as they would have done with any other ethertype.

Indeed, as you mentioned, there are the issue of the tag insertion/removal. It is possible that a 64 byte tagged frame need to be sent untagged on a port. Extra padding is then added. If a full size untagged frame needs to be tagged, it seems that 802.3 was amended to add extra room in the frame so that it is possible. Otherwise, the frame is dropped as you said.

I've copied below the paragraph of 802.1Q-2005 mentioning this.

Regards,

Francois

C.4.4.2 Maximum PDU size

VLAN tagging of an untagged frame, or relaying frames in tagged frame format, can result in an increase in

the length of the original frame. If transmission of a given frame in tagged frame format through a given

destination Port would result in violation of the maximum PDU size for the destination MAC method, the

Bridge discards the frame for that destination Port.

NOTE?Violation of the maximum PDU sizes for destination MAC methods can produce undefined results in networks

that contain devices that adhere strictly to these maxima, or in MAC methods where these maxima are inherently

constrained by the operation of the MAC method itself (e.g., constrained by timing considerations in the MAC state

machines).

IEEE Std 802.3ac-1998 defines an extension to the normal IEEE 802.3 maximum frame size for the specific

purpose of accommodating the additional octets of the VLAN tag header. The example frame translations in

this annex make use of this extension to the IEEE 802.3 frame size.