From: David Buechner (dbuechn@attglobal.net)
Date: Tue Mar 11 2003 - 23:42:25 GMT-3
Jim,
I realize it's been several days since you posed your question, but it
seems like you've not gotten a response so I'll take a crack at it.
First, let me recommend the Cisco LAN Switching book by Clark and Hamilton
available from Cisco Press to you. Chapter 8 has a very good description
of all sorts of issues involved in trunking.
That said, let me give you a shorter answer than all of chapter 8. I'll
assume that you understand the basics of VLANs and why you'd want/need to
trunk them in the first place.
In ISL trunking all VLANs are created equal when it comes to trunking. No
matter what the source VLAN, frames sent over a trunk interface are
encapsulated in an ISL trunk frame by adding the tag information at the
front of the frame and a new CRC at the back. The tag contains the VLAN ID
(among other things). This information is used by the receiving device to
unpack the payload and send it on its way.
802.1q trunking works similarly, but with some differences. The first
difference is that the tag is inserted internally into the frame (after the
source and destination addresses). The second difference is that in 802.1q
trunking all VLANs are not created equal. There is one lone stand-out -
the native VLAN. For each 802.1q trunk line you configure the native VLAN
which leads to two things: 1. Packets from the native VLAN which are going
to be sent over the 802.1q trunk are not tagged, but are sent in their
normal format. 2. If you receive a frame which is not tagged then you
conclude that the frame is for the native VLAN.
Some things come to mind as a result of this. First, one would assume that
the switch spends less CPU on frames in the native VLAN as you don't have
to insert tags and recompute FCS. Second, I suspect that if you have a
802.1q trunking port defined you could attach a workstation to the port and
it's traffic would go out over the native VLAN. I further suspect that
this is how the IP Phones do their thing over ports defined as "switchport
access vlan/voice vlan xxx". If you take your PC off the port and plug a
phone in, then plug your PC into the phone the PC frames are still untagged
as they always have been while the voice frames are tagged. Third, it is
critical that the native VLAN configuration match from one end of the trunk
to the other.
So, "untagged" frames come from the native VLAN on the other device.
You won't get "untagged" frames on ISL trunks.
As for your DTP question, I don't know the answer to that (and a quick
glance - all I have time for right now - at LAN Switching didn't tell
me). There are several options you can use to configure DTP and I suspect
that there are some combinations that would allow you to dynamically change
things by manually configuring one end of the trunk, but I've not verified
that.
I hope this helps! If I'm mistaken on any of this I hope someone will
correct me!!
David
At 01:32 pm 3/6/2003 -0500, ccie2be wrote:
>the 3550 documentation says that all untagged packets arriving at a 802.1q
>trunk will be forwarded with the native vlan.
>
>Where do "untagged" packets come from?
>
>What happens if it's an ISL trunk?
>
>On a different but related topic, if the trunking encap (802.1q or ISL) is
>negotiated by DTP, what happens if one side of the link is subsequently
>manually set to a different encap?
>
>Will the link stop passing traffic? Will the new encap be negotiated with the
>other end? Will you be allowed to manually enter the encap type if it's
>already been negotiated?
>
>Thanks in advance. Jim
This archive was generated by hypermail 2.1.4 : Sat Apr 05 2003 - 08:51:37 GMT-3