From: Joe Mama (jsmith1234550@gmail.com)
Date: Tue May 29 2007 - 13:21:27 ART
On 5/29/07, Joe Mama <jsmith1234550@gmail.com> wrote:
> Confirmed!
>
> On 5/29/07, Cisco certification <ccielab@groupstudy.com> wrote:
> > Hi,
> >
> > You have tried to post to a GroupStudy.com certification mailing list. Because
> > the server does not recognize you as a confirmed poster, you will be required
> > to authenticate that you are using a valid e-mail address and are not a
> > spammer. By confirming this e-mail you certify that you are not sending
> > Unsolicited Bulk Email (UBE).
> >
> > PLEASE DO NOT SEND YOUR ORIGINAL MESSAGE AGAIN! BY CONFIRMING THIS EMAIL
> > YOUR ORIGINAL MESSAGE (WHICH IS NOW QUEUED IN THE SERVER) WILL BE POSTED.
> >
> >
> > By confirming this e-mail you also certify the following:
> >
> > 1. The message does NOT break Cisco's Non-Disclosure requirements.
> >
> > 2. The message is NOT designed to advertise a commercial product.
> >
> > 3. You understand all postings become property of GroupStudy.com
> >
> > 4. You have searched the archives prior to posting.
> >
> > 5. The message is NOT inflammatory.
> >
> > 6. The message is NOT a test message.
> >
> > To confirm, simply reply to this message. No editing is necessary. Once
> > confirmed, you will be able to post without additional confirmations.
> >
> >
> > Welcome to GroupStudy.com!
> >
> >
> > First time posters to GroupStudy.com are required to agree to the GroupStudy terms and conditions.
> > Replying to this email, certifies you have read and agree to the GroupStudy posting guidelines and terms and conditions.
> >
> > --- Original Message Follows ---
> >
> > Date: Tue, 29 May 2007 11:55:34 -0400
> > From: "Joe Mama" <jsmith1234550@gmail.com>
> > To: ccielab@groupstudy.com
> > Subject: ? on Frame Tagging
> >
> > Hello all,
> >
> > Any examples and information would be greatly appreciated. I've
> > looked through the archives and various books,but would still
> > appreciate more clarification.
> > Here's the requirement: The trunk link in should allow all VLANs to
> > travel across with their VLAN ID intact. You cannot use the Cisco
> > proprietary protocol to achieve this. Every packet that traverses the
> > link must have the VLAN ID, no exceptions.
> >
> > The most likely answer is to use the following command on all 3550/60's.
> >
> > sw2(config)#vlan dot1q tag native
> >
> > Here's my basic understanding:
> > Using "vlan dot1q tag native" - All traffic that is not tagged will be
> > accepted and tagged in to the vative VLAN (VLAN1 by default) and go
> > over the trunk port. All traffic that is already tagged will continue
> > to keep its VLAN ID through the trunk. The switch accepts untagged
> > packets, but sends only tagged packets.
> >
> >
> > Without "vlan dot1q tag native", the data on the trunk will not be
> > tagged but will still be on the native vlan (untagged).
> >
> > "802.1Q is the IEEE standard for tagging frames on a trunk and
> > supports up to 4096 VLANs. In 802.1Q, the trunking device inserts a
> > 4-byte tag into the original frame and recomputes the frame check
> > sequence (FCS) before the device sends the frame over the trunk link.
> > At the receiving end, the tag is removed and the frame is forwarded to
> > the assigned VLAN. 802.1Q does not tag frames on the native VLAN."
> >
> > My questions:
> > 1 - vlan dot1q tag native - is there another solution besides this command?
> >
> > 2 - Before using vlan dot1q tag native, how does the switch process
> > tagged and untagged incoming and outgoing frames? My understanding is
> > that dot1q encapsulation on a trunk will tag all the VLANs except the
> > native
> > vlan. So then vlan dot1q tag native tags even native traffic where
> > normally the switch would not tag the info. - Is this correct?
> >
> > 3 - When is traffic dropped due to a tag not being or being present?
> > What are some practical scenarios and reasons related to tagging /
> > untagging? I'm trying to get a deeper understanding. I do understand
> > that untagged frames can be placed in a VLAN that is more restrictive,
> > etc. and do understand how having different Native VLAN in a switching
> > domain can result in leakage and different results but some other
> > practical examples would be nice.
> >
> >
> > (Original message truncated)
This archive was generated by hypermail 2.1.4 : Fri Jun 01 2007 - 06:55:22 ART