07-02-2007 02:44 PM - edited 03-05-2019 05:05 PM
Is it possible to connect a trunk port (off of a 2950) to an unmanaged 10/100/1000 switch? I know it is never a good idea to introduce an unmanaged switch into a managed environment, but I need to test a device in our environment that will only connect at 1Gb.
Basically, will an unmanaged switch pass a 802.1q trunk link?
Solved! Go to Solution.
07-02-2007 03:42 PM
No, it won't. It doesn't know how to interpret the dot1q information, so it will call the frame "damaged" and drops it.
Virtually all of the switches these days are store-and-forward, even the unmanaged ones. They expect to see specific information in specific places, starting with, and referencing from, with the first octet.
Good Luck
Scott
07-02-2007 03:42 PM
No, it won't. It doesn't know how to interpret the dot1q information, so it will call the frame "damaged" and drops it.
Virtually all of the switches these days are store-and-forward, even the unmanaged ones. They expect to see specific information in specific places, starting with, and referencing from, with the first octet.
Good Luck
Scott
07-02-2007 03:47 PM
Thanks. I figured as much... but was desperate. Thanks again.
07-02-2007 04:22 PM
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
07-02-2007 06:26 PM
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.
07-06-2007 09:40 AM
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
07-06-2007 10:21 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide