From: ccie2be (ccie2be@nyc.rr.com)
Date: Wed Mar 12 2003 - 12:07:05 GMT-3
Hi David,
Thanks for your response to my queries.
First, let me wholeheartedly agree with your remarks concerning the Cisco
Lan Switching book. It is excellent but at this point there's enough new
technology that it's probably time for a new, updated edition.
Regarding 802.1q, can you point me to any sources of more detailed info?
I'm still not totally clear on a few questions (although your explanation
was a big step in the right direction).
For example, what happens if extended-range vlans are configured? Will
there be a problem when trunking is negotiated because by default, when both
802.1q and ISL are supported at both ends of the trunk link, ISL is choosen.
It seems to me that if extended-range vlans exist, you must use 802.1q
trunks because they support 4000 vlans where as ISL only supports 1000
vlans. But I don't know this for a fact.
Also, I'm confused about the distinction between vlan configuration mode
(accessed by entering vlan database) and config-vlan mode ( accessed by
entering vlan #). I know that normal range vlans can be created using
either mode and that for extended-range vlans you must use config-vlan mode
but which mode should be used for a normal range vlan? Does it make any
difference? Do I (or should I ) care whether or not the vlan info is saved
to the vlan.dat file?
As you can see I'm still trying to sort out the interaction between these
various things. So, any guidance you or groupstudy can provide will be
greatly appreciated.
Thanks, Jim
----- Original Message -----
From: "David Buechner" <dbuechn@attglobal.net>
To: "ccie2be" <ccie2be@nyc.rr.com>; "Group Study" <ccielab@groupstudy.com>
Sent: Tuesday, March 11, 2003 9:42 PM
Subject: Re: 3550 - native vlan and untagged packets
> 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:38 GMT-3