alt.certification.cisco - Frame Tagging

Author

Frame Tagging

DarksideMP

2004-02-16, 5:25 pm

I know this is probably a dumb question, but can anyone please explain the
concept of Frame Tagging. I still don't have it completely understood yet.

Thanks

MP

ccna20

2004-02-16, 5:43 pm

In a nutshell frame tagging helps identify the frame as it transverses the switch fabric / VLANs.

Bernd Wacke

2004-02-16, 6:25 pm

DarksideMP wrote:

> I know this is probably a dumb question, but can anyone please
> explain the concept of Frame Tagging. I still don't have it
> completely understood yet.

First, I'm still a CCNA learner myself. But I think I understood 802.1q,
so here u go:

Assume you have 2 switches, each have VLAN 10 and VLAN 20 configured on
them respectively. These 2 switches are chained together by a backbone
(cat5e or fiber <-- that doesn't matter in this case)

Normally, if you would use the default configuration on the ports for
this switch-2-switch link (i.e. not change them), you would only be able
to assign them to either one of the 2 VLAN's. This effectively means
that - assuming you asign VLAN10 to them - only VLAN10-hosts on switch A
and switch B are in the same broadcast-domain.

Note that VLAN10-hosts are in one broadcast-domain on _both_ switches
once a line (dedicated to VLAN10) connects both switches. If no VLAN-
dedicated line connects the 2 switches, they will be _separate_
broadcast-domains, even when designated to the _same_ VLAN.

That would be comparable to you creating VLAN 10 in Kentucky and me
creating the same VLAN 10 in Moedling(near Vienna)/Austria... no
connect, naturally.

So, how could one overcome these connection issues of 2 VLAN's? One
possible solution would probably be to connect port1/sw1 to port1/sw2
and designating both of them to VLAN10. Second, connect port2/sw1 to
port2/sw2 via another cable and designate these ports to VLAN20.

Still with me? OK, lets go 4 it

The above solution probably seems logical, but isn't too practical
(imagine 5 VLAN's throughout maybe 8-10 switches...)

So here comes _trunking_ into play. That's nothing else than a method of
sharing all of those virtually necessary VLAN's inter-switch-connections
on _one_ physical line.

How should a switch then be able to distinguish a packet for VLAN10 from
one for VLAN20 when another switch sends it? Here comes Frame-tagging
into play: the sending switch (switchA) adds some information to a frame
(the 802.1q-tag). This added information tells switchB which VLAN the
frame is intended for. That simple. SwitchB then removes the tag and
forwards the frame to the appropriate node on it's segment.

Note that (1) tagging is not standardized (tho that fact seems to be a
standard question...) and (2) workstations an the like do not understand
the tagged-frame-format - it is only intended for the reception by
switches and routers which understand and can handle 802.1q. Therefore
you _need_ to configure your appropriate switch-ports for tagging, and
they better not be links to regular nodes like servers...

HTH, Bernd

Bernie

2004-02-17, 12:24 am

On Mon, 16 Feb 2004 22:42:36 GMT, "Bernd Wacke" <bernd@copyshop.at>
wrote:

>Note that (1) tagging is not standardized (tho that fact seems to be a
>standard question...) and (2) workstations an the like do not understand
>the tagged-frame-format - it is only intended for the reception by
>switches and routers which understand and can handle 802.1q. Therefore
>you _need_ to configure your appropriate switch-ports for tagging, and
>they better not be links to regular nodes like servers...

That isn't true on either account. 802.1q is an IEEE standard, so I
am not sure what you mean by not being standardized. ISL is not a
standard though.

As for workstations, many NICs these days can support tagging, but it
is not normally enabled. So in practice, that is generally true, but
not always.

--Bernie

Bernd Wacke

2004-02-17, 1:24 am

Bernie wrote:

> On Mon, 16 Feb 2004 22:42:36 GMT, "Bernd Wacke" <bernd@copyshop.at>
> wrote:
>
>
> That isn't true on either account. 802.1q is an IEEE standard, so I
> am not sure what you mean by not being standardized. ISL is not a
> standard though.

I'm sorry, I guess I confused two different things: according to the
curriculum I'm studying (Version 2.1.4), _VLANs_ are not standardized
(and NOT 802.1q, which is an IEEE-Number of course - shame on me). Maybe
VLAN is already standardized by now?

> As for workstations, many NICs these days can support tagging, but it
> is not normally enabled. So in practice, that is generally true, but
> not always.

Again, taught in 2.1.4: the switch should remove the tag before
forwarding a frame to a workstation. Probably outdated info...

Bernd

Hansang Bae

2004-02-17, 2:24 am

> Bernie wrote:

In article <vIhYb.10003$2h7.7075@news.chello.at>, bernd@copyshop.at[color=blue]
> Again, taught in 2.1.4: the switch should remove the tag before
> forwarding a frame to a workstation. Probably outdated info...

Not outdated. If you think about it, it will make sense. If the server
belongs in one VLAN only, then the server does not need to see the dot1q
tagging. But if the server needs to talk to multiple vlans, he will
need to see the tagging. This means that you have to turn on trunking
on the server port to carry multiple vlans. And when you carry multiple
vlans, dot1q tagging is required.

--

hsb

"Somehow I imagined this experience would be more rewarding" Calvin
*************** USE ROT13 TO SEE MY EMAIL ADDRESS ****************
******************************
******************************
********
Due to the volume of email that I receive, I may not not be able to
reply to emails sent to my account. Please post a followup instead.
******************************
******************************
********

Bernie

2004-02-17, 3:25 am

On Tue, 17 Feb 2004 05:33:15 GMT, "Bernd Wacke" <bernd@copyshop.at>
wrote:

>Bernie wrote:
>
>
>I'm sorry, I guess I confused two different things: according to the
>curriculum I'm studying (Version 2.1.4), _VLANs_ are not standardized
>(and NOT 802.1q, which is an IEEE-Number of course - shame on me). Maybe
>VLAN is already standardized by now?

I misunderstood then. I guess that is true that "VLANs" themselves
are not standardized, but that is something that doesn't need a
standard, IMO. What I mean is that there is no rule that says all
ports in a device must be bridged together, and therefore, there is
also no need for a standard on how to segregate ports in a switch.
The concept of a VLAN is just fundamental to modern networking.

But the concept of VLANs is implicit to tagging which is standardized.

>
>Again, taught in 2.1.4: the switch should remove the tag before
>forwarding a frame to a workstation. Probably outdated info...

No, that is still generally true, and for the purposes of a test
question, that is probably the answer to select because it is most
right. I was just pointing out that it is very possible to turn on
tagging on workstations and servers. In fact, there is another reason
to turn on tagging other than to join multiple VLANs. Suppose you
wanted to set the p-bits to mark some of your traffic as higher
priority in order to get QoS all the way to your PC. Without a tag,
there are no p-bits to set. So you could have a tagged port connected
to a user device in some cases. This is still rare.

I am just pointing out that reality is not so black and white on these
concepts.

--Bernie

Acer0001

2004-02-18, 8:24 am

BTW, with today's advanced NIC drivers, you can set a server or
workstation to send out VLAN tagged frames. We have done it to
deliver specific traffic from an image server to multiple
racks in our classroom lab. We use Broadcom NICS and it does work.

Acer

On Mon, 16 Feb 2004 22:42:36 +0000, Bernd Wacke wrote:

> DarksideMP wrote:
>
>
> First, I'm still a CCNA learner myself. But I think I understood 802.1q,
> so here u go:
>
> Assume you have 2 switches, each have VLAN 10 and VLAN 20 configured on
> them respectively. These 2 switches are chained together by a backbone
> (cat5e or fiber <-- that doesn't matter in this case)
>
> Normally, if you would use the default configuration on the ports for
> this switch-2-switch link (i.e. not change them), you would only be able
> to assign them to either one of the 2 VLAN's. This effectively means
> that - assuming you asign VLAN10 to them - only VLAN10-hosts on switch A
> and switch B are in the same broadcast-domain.
>
> Note that VLAN10-hosts are in one broadcast-domain on _both_ switches
> once a line (dedicated to VLAN10) connects both switches. If no VLAN-
> dedicated line connects the 2 switches, they will be _separate_
> broadcast-domains, even when designated to the _same_ VLAN.
>
> That would be comparable to you creating VLAN 10 in Kentucky and me
> creating the same VLAN 10 in Moedling(near Vienna)/Austria... no
> connect, naturally.
>
> So, how could one overcome these connection issues of 2 VLAN's? One
> possible solution would probably be to connect port1/sw1 to port1/sw2
> and designating both of them to VLAN10. Second, connect port2/sw1 to
> port2/sw2 via another cable and designate these ports to VLAN20.
>
> Still with me? OK, lets go 4 it

>
> The above solution probably seems logical, but isn't too practical
> (imagine 5 VLAN's throughout maybe 8-10 switches...)
>
> So here comes _trunking_ into play. That's nothing else than a method of
> sharing all of those virtually necessary VLAN's inter-switch-connections
> on _one_ physical line.
>
> How should a switch then be able to distinguish a packet for VLAN10 from
> one for VLAN20 when another switch sends it? Here comes Frame-tagging
> into play: the sending switch (switchA) adds some information to a frame
> (the 802.1q-tag). This added information tells switchB which VLAN the
> frame is intended for. That simple. SwitchB then removes the tag and
> forwards the frame to the appropriate node on it's segment.
>
> Note that (1) tagging is not standardized (tho that fact seems to be a
> standard question...) and (2) workstations an the like do not understand
> the tagged-frame-format - it is only intended for the reception by
> switches and routers which understand and can handle 802.1q. Therefore
> you _need_ to configure your appropriate switch-ports for tagging, and
> they better not be links to regular nodes like servers...
>
> HTH, Bernd

Sponsored Links