3Com untagged vs. 802.1Q VLANs

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

Hi,
In a SuperStack II 3300 switch (model 3C16980), firmware 2.71, there are
untagged and tagged VLANs. Am I correct to assume that ports defined in
an untagged VLAN are partitioned off from other ports, into their own
broadcast domain? What will the switch do with packets destined for a
host not in the untagged VLAN? Will it forward? I can see in the admin
GUI where you can control forwarding of tagged packets but nothing
specific to untagged.

thanks for clarifying the behavior of 3Com untagged VLANs.

-Jonathan

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <1MidnQA6RdSgzobfRVn-ow@speakeasy.net>,
Jonathan Sturges <nobody@nowhere.com> wrote:
:In a SuperStack II 3300 switch (model 3C16980), firmware 2.71, there are
:untagged and tagged VLANs. Am I correct to assume that ports defined in
:an untagged VLAN are partitioned off from other ports, into their own
:broadcast domain?

Yes, but...

: What will the switch do with packets destined for a
:host not in the untagged VLAN? Will it forward? I can see in the admin
:GUI where you can control forwarding of tagged packets but nothing
:specific to untagged.

Tagged or untagged is not a property of the VLAN, but rather a
property of a port. Unless 3Com is using terminology a very different
way than everyone else, all ports, tagged or untagged, that are
given the same VLAN number will be in the same broadcast domain;
the ports that are marked as tagged will actually send the tag
number as part of the packet when emitting a packet on the port,
whereas ports that are marked as untagged will strip the tag number
before emitting a packet on the port.

Tagged ports are used when mostly communicating between switches (or
between switches and routers), and untagged ports are mostly used for
communicating with hosts; most hosts are not able to process the
tag number [but it is becoming increasingly common to be able to.]

Often a tagged port will be marked as being part of several VLANs;
packets for all those VLANs can be sent on the same port, with
the tag number being used on the remote end to figure out what goes
where.

--
Scintillate, scintillate, globule vivific
Fain would I fathom thy nature specific.
Loftily poised on ether capacious
Strongly resembling a gem carbonaceous. -- Anon

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

Walter Roberson wrote:
> In article <1MidnQA6RdSgzobfRVn-ow@speakeasy.net>,
> Jonathan Sturges <nobody@nowhere.com> wrote:
> :In a SuperStack II 3300 switch (model 3C16980), firmware 2.71, there are
> :untagged and tagged VLANs. Am I correct to assume that ports defined in
> :an untagged VLAN are partitioned off from other ports, into their own
> :broadcast domain?
>
> Yes, but...
>
> : What will the switch do with packets destined for a
> :host not in the untagged VLAN? Will it forward? I can see in the admin
> :GUI where you can control forwarding of tagged packets but nothing
> :specific to untagged.
>
> Tagged or untagged is not a property of the VLAN, but rather a
> property of a port. Unless 3Com is using terminology a very different
> way than everyone else, all ports, tagged or untagged, that are
> given the same VLAN number will be in the same broadcast domain;
> the ports that are marked as tagged will actually send the tag
> number as part of the packet when emitting a packet on the port,
> whereas ports that are marked as untagged will strip the tag number
> before emitting a packet on the port.
>
> Tagged ports are used when mostly communicating between switches (or
> between switches and routers), and untagged ports are mostly used for
> communicating with hosts; most hosts are not able to process the
> tag number [but it is becoming increasingly common to be able to.]
>
> Often a tagged port will be marked as being part of several VLANs;
> packets for all those VLANs can be sent on the same port, with
> the tag number being used on the remote end to figure out what goes
> where.
>

Thanks for this very clear explanation.

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <1MidnQA6RdSgzobfRVn-ow@speakeasy.net>,
Jonathan Sturges <nobody@nowhere.com> writes:
>Hi,
>In a SuperStack II 3300 switch (model 3C16980), firmware 2.71, there are
>untagged and tagged VLANs. ...

No. There are VLANs. You decide if a port will transmit and receive
packets for one or more of them. To distinguish the VLAN meberbership
you can use explicit tags or implicitly agree on one for untagged
packets.
> ... Am I correct to assume that ports defined in
>an untagged VLAN are partitioned off from other ports, into their own
>broadcast domain? What will the switch do with packets destined for a
>host not in the untagged VLAN? Will it forward?

It will establish a VLAN correspondance for every packet and
then forward the packet accordingly.

--
Manfred Kwiatkowski kwiatkowski@zrz.tu-berlin.de

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

Manfred Kwiatkowski wrote:
> In article <1MidnQA6RdSgzobfRVn-ow@speakeasy.net>,
> Jonathan Sturges <nobody@nowhere.com> writes:
>
>>Hi,
>>In a SuperStack II 3300 switch (model 3C16980), firmware 2.71, there are
>>untagged and tagged VLANs. ...
>
>
> No. There are VLANs. You decide if a port will transmit and receive
> packets for one or more of them. To distinguish the VLAN meberbership
> you can use explicit tags or implicitly agree on one for untagged
> packets.
>
>> ... Am I correct to assume that ports defined in
>>an untagged VLAN are partitioned off from other ports, into their own
>>broadcast domain? What will the switch do with packets destined for a
>>host not in the untagged VLAN? Will it forward?
>
>
> It will establish a VLAN correspondance for every packet and
> then forward the packet accordingly.

No. It will drop pacekets intended for other VLANS.

(That's sort of the whole point of VLANS)

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <111n0g6gucqa1de@news.supernews.com>,
"T. Sean Weintz" <strap@hanh-ct.org> writes:
>Manfred Kwiatkowski wrote:
>> In article <1MidnQA6RdSgzobfRVn-ow@speakeasy.net>,
>> Jonathan Sturges <nobody@nowhere.com> writes:
>>
>>> ... Am I correct to assume that ports defined in
>>>an untagged VLAN are partitioned off from other ports, into their own
>>>broadcast domain? What will the switch do with packets destined for a
>>>host not in the untagged VLAN? Will it forward?
>>
>>
>> It will establish a VLAN correspondance for every packet and
>> then forward the packet accordingly.
>
>No. It will drop pacekets intended for other VLANS.

And what does this have to do with the untagged VLAN of a port?
There may be several tagged VLANs defined on this port.
In addition, forwarding of unknown VLANs may be set for this port.
Thus, "other" VLANs is totally meaningless in this context.
>
>(That's sort of the whole point of VLANS)

Sort of.

--
Manfred Kwiatkowski kwiatkowski@zrz.tu-berlin.de

 

[Sean]

Archived from groups: comp.dcom.lans.ethernet (More info?)

Manfred Kwiatkowski wrote:

> In article <111n0g6gucqa1de@news.supernews.com>,
> "T. Sean Weintz" <strap@hanh-ct.org> writes:
>
>>Manfred Kwiatkowski wrote:
>>
>>>In article <1MidnQA6RdSgzobfRVn-ow@speakeasy.net>,
>>> Jonathan Sturges <nobody@nowhere.com> writes:
>>>
>>>
>>>> ... Am I correct to assume that ports defined in
>>>>an untagged VLAN are partitioned off from other ports, into their own
>>>>broadcast domain? What will the switch do with packets destined for a
>>>>host not in the untagged VLAN? Will it forward?
>>>
>>>
>>>It will establish a VLAN correspondance for every packet and
>>>then forward the packet accordingly.
>>
>>No. It will drop pacekets intended for other VLANS.
>
>
> And what does this have to do with the untagged VLAN of a port?
> There may be several tagged VLANs defined on this port.
> In addition, forwarding of unknown VLANs may be set for this port.
> Thus, "other" VLANs is totally meaningless in this context.

Yes. My bad. He said ports defined in an untagged vlan. I thought he had
said ports that were not tagged, implying they aren't also members of
any tagged vlans. Some switches don't allow that anyway (my baystack
450's are a good example of a fairly common non-low end switch that fits
that description) - port must be tagged member of all vlans it belongs
to or an untagged member of all vlans it belongs to. Can't be tagged on
one vlan it is a member of and not tagged on another. I was always
taught it's a bad idea to do that anyway - tagging is for trunking, and
both end should be either all tagged or all untagged. Mixing makes it
confusing.

>
>>(That's sort of the whole point of VLANS)
>
>
> Sort of.

Well, yes, sort of. It's one of the more common uses. Before I had a
layer 3 switch I did that all the time - on a 24 port switch something
like 3 vlans, all ports not using any tags. And then throw a "router on
a stick" in by having one port being a tagged member of all 3 vlans,
connected to a router also using tagging to allow it to route between
the 3. Three networks, 1 switch, 1 router.

Pretty standard stuff.

Never understood why so many also use it for prioritizing when diffserv
is so much more flexible (at least it is on my nortel and netgear stuff)

>

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

Manfred Kwiatkowski wrote:
> In article <111n0g6gucqa1de@news.supernews.com>,
> "T. Sean Weintz" <strap@hanh-ct.org> writes:
>
>>Manfred Kwiatkowski wrote:
>>
>>>In article <1MidnQA6RdSgzobfRVn-ow@speakeasy.net>,
>>> Jonathan Sturges <nobody@nowhere.com> writes:
>>>
>>>
>>>> ... Am I correct to assume that ports defined in
>>>>an untagged VLAN are partitioned off from other ports, into their own
>>>>broadcast domain? What will the switch do with packets destined for a
>>>>host not in the untagged VLAN? Will it forward?
>>>
>>>
>>>It will establish a VLAN correspondance for every packet and
>>>then forward the packet accordingly.
>>
>>No. It will drop pacekets intended for other VLANS.
>
>
> And what does this have to do with the untagged VLAN of a port?
> There may be several tagged VLANs defined on this port.
> In addition, forwarding of unknown VLANs may be set for this port.
> Thus, "other" VLANs is totally meaningless in this context.

Looking over this again, my original assertion stands. I have never seen
a switch that will do anything with an untagged packet other than set it
to the vlan ID matching the PVID number that the port is configured
with. So the packet comes in, and the switch assigns it to the vlan that
the port has it's pvid set to. If the destination mac address is not on
that vlan, the packet drops. End of story. No matter haow many tagged
and untagged vlans the prt belongs to, any incoming untagged packet
packet will always be assigned to the PVID vlan.

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <111uvod80n8d374@news.supernews.com>,
"T. Sean Weintz" <strap@hanh-ct.org> wrote:

> I have never seen
> a switch that will do anything with an untagged packet other than set it
> to the vlan ID matching the PVID number that the port is configured
> with. So the packet comes in, and the switch assigns it to the vlan that
> the port has it's pvid set to. If the destination mac address is not on
> that vlan, the packet drops. End of story. No matter haow many tagged
> and untagged vlans the prt belongs to, any incoming untagged packet
> packet will always be assigned to the PVID vlan.

This is true only when using *port-based* VLAN assignment. Many switches
can assign a frame to a VLAN based on MAC source address, or even IP
network (subnet) information. Thus, the assigned VLAN is not always the
PVID of the arrival port. It is possible that you have never worked with
some of the more sophisticated switches that can parse frame contents to
assign VLANs "implicitly," rather than through tag information.


--
Rich Seifert Networks and Communications Consulting
21885 Bear Creek Way
(408) 395-5700 Los Gatos, CA 95033
(408) 228-0803 FAX

Send replies to: usenet at richseifert dot com

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

Rich Seifert wrote:

>
> This is true only when using *port-based* VLAN assignment. Many switches
> can assign a frame to a VLAN based on MAC source address, or even IP
> network (subnet) information. Thus, the assigned VLAN is not always the
> PVID of the arrival port. It is possible that you have never worked with
> some of the more sophisticated switches that can parse frame contents to
> assign VLANs "implicitly," rather than through tag information.
>

Yes. Your assumption that I have never worked with the more
"sophistiacted" switches is correct.

What brands/models CAN do this? Could you give me just a few examples?

I am in the process of spec'ing new switches here, and that info would
be invaluable.

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <111t52md8ef3sfa@news.supernews.com>,
sean <sean@snerts-r-us.org> writes:
>Manfred Kwiatkowski wrote:
>
>> In article <111n0g6gucqa1de@news.supernews.com>,
>> "T. Sean Weintz" <strap@hanh-ct.org> writes:
>>
>>>Manfred Kwiatkowski wrote:
>>>
>>>>In article <1MidnQA6RdSgzobfRVn-ow@speakeasy.net>,
>>>> Jonathan Sturges <nobody@nowhere.com> writes:
>>>>
>>>>
>>>>> ... Am I correct to assume that ports defined in
>>>>>an untagged VLAN are partitioned off from other ports, into their own
>>>>>broadcast domain? What will the switch do with packets destined for a
>>>>>host not in the untagged VLAN? Will it forward?
>>>>
>>>>
>>>>It will establish a VLAN correspondance for every packet and
>>>>then forward the packet accordingly.
>>>
>>>No. It will drop pacekets intended for other VLANS.
>>
>>
>> And what does this have to do with the untagged VLAN of a port?
>> There may be several tagged VLANs defined on this port.
>> In addition, forwarding of unknown VLANs may be set for this port.
>> Thus, "other" VLANs is totally meaningless in this context.
>
>Yes. My bad. He said ports defined in an untagged vlan. I thought he had
>said ports that were not tagged, implying they aren't also members of
>any tagged vlans. ...

This is probably what he thought he said.
But this comes from the term " untagged VLAN" that 3COM uses as
a port characteristic and thus makes people think that being
"untagged" is something special or even has a relation to the
"untaggedness" of other port. With 3COM, even the expression
"untagged VLAN of a port" ist misleading, as the SuperStack
allows port mebership as tagged and untagged at the same time (sic!)

> ... Some switches don't allow that anyway (my baystack
>450's are a good example of a fairly common non-low end switch that fits
>that description) - port must be tagged member of all vlans it belongs
>to or an untagged member of all vlans it belongs to. Can't be tagged on
>one vlan it is a member of and not tagged on another. I was always
>taught it's a bad idea to do that anyway - tagging is for trunking, and
>both end should be either all tagged or all untagged. Mixing makes it
>confusing.

Not at all. Confusing are the brain damaged configuration options
and restrictions of most switches as well as implicit definitions.
Some switches only allow trunk xor access as your 450, some even
force the default VLAN on trunks, some only allow the default VLAN
untagged and some only allow configuration via the default vlan.
>
>>>(That's sort of the whole point of VLANS)

>Never understood why so many also use it for prioritizing when diffserv
>is so much more flexible (at least it is on my nortel and netgear stuff)

You can use any bit in a packet the way you like if both sides
of the link (are able to) interpret it in similar ways.

--
Manfred Kwiatkowski kwiatkowski@zrz.tu-berlin.de

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <111uvod80n8d374@news.supernews.com>,
"T. Sean Weintz" <strap@hanh-ct.org> writes:
>Manfred Kwiatkowski wrote:
>> In article <111n0g6gucqa1de@news.supernews.com>,
>> "T. Sean Weintz" <strap@hanh-ct.org> writes:
>>
>>>Manfred Kwiatkowski wrote:
>>>
>>>>In article <1MidnQA6RdSgzobfRVn-ow@speakeasy.net>,
>>>> Jonathan Sturges <nobody@nowhere.com> writes:
>>>>
>>>>
>>>>> ... Am I correct to assume that ports defined in
>>>>>an untagged VLAN are partitioned off from other ports, into their own
>>>>>broadcast domain? What will the switch do with packets destined for a
>>>>>host not in the untagged VLAN? Will it forward?
>>>>
>>>>
>>>>It will establish a VLAN correspondance for every packet and
>>>>then forward the packet accordingly.
>>>
>>>No. It will drop pacekets intended for other VLANS.
>>
>>
>> And what does this have to do with the untagged VLAN of a port?
>> There may be several tagged VLANs defined on this port.
>> In addition, forwarding of unknown VLANs may be set for this port.
>> Thus, "other" VLANs is totally meaningless in this context.
>
>Looking over this again, my original assertion stands. I have never seen
>a switch that will do anything with an untagged packet other than set it
>to the vlan ID matching the PVID number that the port is configured
>with. So the packet comes in, and the switch assigns it to the vlan that
>the port has it's pvid set to. If the destination mac address is not on
>that vlan, the packet drops. End of story. No matter haow many tagged
>and untagged vlans the prt belongs to, any incoming untagged packet
>packet will always be assigned to the PVID vlan.

Come on, using an untagged packet on a port with the PVID set to
"untagged" is most unsuited to back up your point. Short of security
settings the packet will be flodded to the subset of all ports belonging
to that VLAN. Normal behavior of a bridge.

Playing my own advocatus diaboli:
If the switch cannot establish a VLAN correspondance, because the
packet does not belong to any of the VLANs allowed at ingress
it will be forwarded to the bit bucket, i.e. dropped.
This I should have made more clear.
Nevertheless, this has nothing to do with a tag.

--
Manfred Kwiatkowski kwiatkowski@zrz.tu-berlin.de

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <111v5rri8uj4i96@news.supernews.com>,
T. Sean Weintz <strap@hanh-ct.org> wrote:
:Rich Seifert wrote:
:> Many switches
:> can assign a frame to a VLAN based on MAC source address, or even IP
:> network (subnet) information.

:What brands/models CAN do this? Could you give me just a few examples?

As an example, the Nortel Networks Baystack 4x0 series can assign
VLANs according to frame protocol -- e.g., IPX 802.2, IPX 802.3,
NETBUI, Appletalk, IP.

As another example, Cisco's C2950 series are quite close to being routers,
and other members of the same family, the C3550 and C3750, -are-
effectively routers, complete with Policy Based Routing, Private VLANs,
Virtual Router Facility, VLAN tunnelling, QoS with policers and rate
limiting, and many other features.

The Nortel Baystack 5510 series are effectively routers as well, with
advanced QoS features, but without policy based routing in current
software releases. They are also about 1/3 the price per port of the
Cisco 3750's.

If I recall correctly, the HP Procurve switches are layer 3 switches
that can do some vlan classification. They have had QoS for some time,
and can now do rate limiting as well -- but the QoS is quite rigid
compared to Cisco's.


These days, there is a very wide range of pricing on switches, dependant
upon the nominal port speeds, the actual sustainable throughput, the
number of layers of inspection, managability, QoS flexibility, routing
flexibility, stackability, cluster management, security features,
quality of technical support...

You really have to know what you are looking for in a switch now.
They are *not* "basically all the same" anymore... but you might have to
do a fair bit of digging to figure out what the differences really are
and why those differences are important.
--
Feep if you love VT-52's.

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

Walter Roberson wrote:
> In article <111v5rri8uj4i96@news.supernews.com>,
> T. Sean Weintz <strap@hanh-ct.org> wrote:
> :Rich Seifert wrote:
> :> Many switches
> :> can assign a frame to a VLAN based on MAC source address, or even IP
> :> network (subnet) information.
>
> :What brands/models CAN do this? Could you give me just a few examples?
>
> As an example, the Nortel Networks Baystack 4x0 series can assign
> VLANs according to frame protocol -- e.g., IPX 802.2, IPX 802.3,
> NETBUI, Appletalk, IP.

Quite aware of that. I have a bunch of BS450's here.

>
> As another example, Cisco's C2950 series are quite close to being routers,
> and other members of the same family, the C3550 and C3750, -are-
> effectively routers, complete with Policy Based Routing, Private VLANs,
> Virtual Router Facility, VLAN tunnelling, QoS with policers and rate
> limiting, and many other features.
>
> The Nortel Baystack 5510 series are effectively routers as well, with
> advanced QoS features, but without policy based routing in current
> software releases. They are also about 1/3 the price per port of the
> Cisco 3750's.
<snip>
Yes. You and I have discussed layer 3 switches a number of times. WE
once had a brief discussion on the Netgear (shudder! layer 3 gig
switches. JUNK IMO - stupid bugs like not doing OSPF LSA checksums
right, etc)

What I was wondering is if you, the honorable Mr. Siefert, or any of the
other folks here that are more knowledgeable than I could point me to a
switch that does Mac address based vlans. That just souinds like it
could be SO incredibly usefull. Esp if you can use wilcard mac address
to force specific type of addresses on to certain vlans (like say IP
phones all from the same vendor...)

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <11276tphurhmg3e@news.supernews.com>,
T. Sean Weintz <strap@hanh-ct.org> wrote:
:What I was wondering is if you, the honorable Mr. Siefert, or any of the
ther folks here that are more knowledgeable than I could point me to a
:switch that does Mac address based vlans.

Neither of these might be what you are looking for, but two
possibilities are:

- 802.1X with a RADIUS server
- a Cisco switch such as the 2950 configured for VMPS
http://www.cisco.com/en/US/products/hw/switches/ps628/products_configuration_guide_chapter09186a00802c305f.html#wp1217230

:That just souinds like it
:could be SO incredibly usefull. Esp if you can use wilcard mac address
:to force specific type of addresses on to certain vlans (like say IP
hones all from the same vendor...)

Also, for at least some purposes, something like the 2950 "voice vlan" might
be useful.
http://www.cisco.com/en/US/products/hw/switches/ps628/products_configuration_guide_chapter09186a00802c3031.html


--
'ignorandus (Latin): "deserving not to be known"'
-- Journal of Self-Referentialism