VLAN-tagging
Lutz Worch
Given is a HP ProCurve2424M-Switch.
Port 1 is Member of A_VLAN (Intel Etherexpress 100+ with 802.1IQ enabled )
Port 2 is Member of B_VLAN (unknown NIC)
Port 3 is Member of A_VLAN an Member of B_VLAN (Intel Etherexpress 100+ with 802.1IQ enabled)
With the following VLAN-Configuration it is not possible to get connection between Port 1 and Port 1
and Port 3, but have contact between Port 2 and Port 3:
Port A_VLAN B_VLAN
1 untagged no
2 no untagged
3 tagged untagged
With the following VLAN-Configuration port 1 and port 3 are connected, but there is no connection
between port 2 and port 3:
Port A_VLAN B_VLAN
1 untagged no
2 no untagged
3 untagged tagged
The HP-Hotline says, that the NICs are not 802.1IQ-compatible. But the Intel-Etherexpress are
configured as 802.1IQ enabled, so they have to be connected in the first cconfiguration! I dont know
what to do know ...
Any hints?
Lutz Worch
--
Charmantes Nächtle noch .....
Rainer Nagel
On Fri, 31 Aug 2001 20:43:17 +0200,
Lutz Worch <lwo...@gmx.net> wrote:
> With the following VLAN-Configuration it is not possible to get connection between Port 1 and Port 1
> and Port 3, but have contact between Port 2 and Port 3:
>
> Port A_VLAN B_VLAN
> 1 untagged no
> 2 no untagged
> 3 tagged untagged
>
> With the following VLAN-Configuration port 1 and port 3 are connected, but there is no connection
> between port 2 and port 3:
>
> Port A_VLAN B_VLAN
> 1 untagged no
> 2 no untagged
> 3 untagged tagged
Try to tag both VLAN's on Port 3.
Or tell the NIC that the untagged VLAN is untagged.
Ciao
--
Rainer Nagel
Rainer...@tashrah.com
Duesseldorfer Linux User Group - http://www.dlug.de
Lutz Worch
Rainer Nagel wrote:
> > With the following VLAN-Configuration it is not possible to get connection between Port 1 and Port 1
> > and Port 3, but have contact between Port 2 and Port 3:
> >
> > Port A_VLAN B_VLAN
> > 1 untagged no
> > 2 no untagged
> > 3 tagged untagged
> >
> > With the following VLAN-Configuration port 1 and port 3 are connected, but there is no connection
> > between port 2 and port 3:
> >
> > Port A_VLAN B_VLAN
> > 1 untagged no
> > 2 no untagged
> > 3 untagged tagged
>
> Try to tag both VLAN's on Port 3.
The same result.
> Or tell the NIC that the untagged VLAN is untagged.
How that? I really can tell the NIC on wich VLAN it is connected and wich of them are tagged or
untagged?? I saw only the possibility in the W9x-configuration to tell the NIC (eepro100+) to
understand tagging information. I will see on Monday.
(I'm a newbie in VLAN-technologie)
Bye Lutz
Denis Jedig
> With the following VLAN-Configuration port 1 and port 3 are connected, but there is no connection
> between port 2 and port 3:
>
> Port A_VLAN B_VLAN
> 1 untagged no
> 2 no untagged
> 3 untagged tagged
You'll have to make all outbound traffic at port 3 tagged, the traffic at
the ports 1 & 2 has to be made untagged. I just wonder, why you can
configure the procurve to tag the traffic coming from B_VLAN but remove the
tag from A_VLAN at the same time on the same switch port - that's quite weird.
Furthermore, you'll have to tell your NIC's drivers, that it is member of
_both_ VLANs - B_VLAN as well as A_VLAN. As far as I know, the normal
EtherExpress drivers are only capable of taking just one VLAN ID, thus,
making the interface listening to a single VLAN only. With the Intel
EtherExpress 100+ Server Adapter and its drivers (As far as I can see, the
only difference between those 2 NICs _are_ the drivers) you can specify more
than one VLAN ID - creating virtual interfaces (one interface for each of
the specified VLANs) in that way.
> The HP-Hotline says, that the NICs are not 802.1IQ-compatible. But the Intel-Etherexpress are
> configured as 802.1IQ enabled, so they have to be connected in the first cconfiguration! I dont know
> what to do know ...
BTW, the proper standards name is 802.1q. There is another standard that
deals with VLAN and priority tagging - 802.1p - those 2 are related, so
you'll mostly find something like "802.1p/q VLAN" listed in technical
specifications.
> Lutz Worch
Denis
Rainer Nagel
On Sat, 01 Sep 2001 15:41:09 +0200,
Denis Jedig <denis...@knuut.de> wrote:
> You'll have to make all outbound traffic at port 3 tagged, the traffic at
> the ports 1 & 2 has to be made untagged. I just wonder, why you can
> configure the procurve to tag the traffic coming from B_VLAN but remove the
> tag from A_VLAN at the same time on the same switch port - that's quite weird.
That is the special feature of the "native VLAN". IMHO it is specified
in the 802.1Q standard that packets belonging to the native VLAN will
be untagged.
It is a nice way to shoot yourself in the foot :-/
Rainer Nagel
On Sat, 01 Sep 2001 13:21:44 +0200,
Lutz Worch <lwo...@gmx.net> wrote:
>> Try to tag both VLAN's on Port 3.
>
> The same result.
Try sniffing with ethereal (www.ethereal.com, there is a windows binary)
and see, which packets arive and how they are tagged.
>> Or tell the NIC that the untagged VLAN is untagged.
>
> How that? I really can tell the NIC on wich VLAN it is connected and
> wich of them are tagged or untagged?? I saw only the possibility in
> the W9x-configuration to tell the NIC (eepro100+) to understand tag-
> ging information.
There is the concept of a native VLAN which packets are not tagged.
Maybe the driver has an option to set this.
If not, try to tag both VLANS on the switch and tell the driver both
VLAN's binding an IP on erery VLAN (2 IP's).
Rich Seifert
Rainer...@tashrah.com wrote:
>
> On Sat, 01 Sep 2001 15:41:09 +0200,
> Denis Jedig <denis...@knuut.de> wrote:
>
> > You'll have to make all outbound traffic at port 3 tagged, the traffic at
> > the ports 1 & 2 has to be made untagged. I just wonder, why you can
> > configure the procurve to tag the traffic coming from B_VLAN but remove the
> > tag from A_VLAN at the same time on the same switch port - that's quite
weird.
>
> That is the special feature of the "native VLAN". IMHO it is specified
> in the 802.1Q standard that packets belonging to the native VLAN will
> be untagged.
> It is a nice way to shoot yourself in the foot :-/
>
There is no concept of a "native VLAN" in 802.1Q. The standard simply
specifies that, for a given VLAN on a given port, frames will be either
all-tagged, or all-untagged. Obviously, when a port carries frames for
multiple VLANs, it is possible that the frames from one VLAN may be tagged,
and those of another be untagged. That is, frame tagging is not on a
port-basis, but a port-and-VLAN basis. This is not a "Bad Thing (TM)", but
simply the best way to provide for interoperability and consistency of VLAN
operation.
--
Rich Seifert Networks and Communications Consulting
ri...@richseifert.com 21885 Bear Creek Way
(408) 395-5700 Los Gatos, CA 95033
(408) 395-1966 FAX
Denis Jedig
> and those of another be untagged. That is, frame tagging is not on a
> port-basis, but a port-and-VLAN basis. This is not a "Bad Thing (TM)", but
> simply the best way to provide for interoperability and consistency of VLAN
> operation.
Rich, thanks for the clarification. Now I also can see the use of that
feature in a mixed (non-VLAN-aware, VLAN-aware and VLAN-capable components)
environment.
Denis
Lutz Worch
Rainer Nagel wrote:
> If not, try to tag both VLANS on the switch and tell the driver both
> VLAN's binding an IP on erery VLAN (2 IP's).
I will see the possibilities tomorrow.
The situation now is:
Only the A_VLAN has an IP-Adress 192.168.1.201. I assigned this during
the first installation when only the A_VLAN exist, to have access to the
switch
The B_VLAN is switched (during the enabling of the B-VLAN) to DHCP/Bootp
and the dhcp-Server distributs 192.168.1.x-Adresses. I tried to give a
192.168.1.x-adress manual to the B-VLAN, but its not possibel in the
configuration! I guess, that here is somthing wrong. The computers in
the A_VLAN and the B_VLAN has 192.168.1.x adresses (netmask
255.255.255.0).
A_VLAN means DEFAULT_VLAN
B_VLAN means verwalt_vlan
VLAN IP Config IP Address Subnet Mask
Gateway
------------ + ---------- --------------- ---------------
---------------
DEFAULT_VLAN | Manual 192.168.1.201 255.255.255.0
192.168.1.5
verwalt_vlan | DHCP/Bootp
I dont know whether its important but I show you other configuration
parts:
VLAN IGMP Enabled Forward with High Priority
------------ ------------ --------------------------
DEFAULT_VLAN No No
verwalt_vlan No No
VLAN ABC Enabled IP RIP Control Auto Gateway IPX RIP/SAP
Control
------------ + ----------- -------------- ------------
-------------------
DEFAULT_VLAN | Disabled
verwalt_vlan | Disabled
Sorry for this questions but I'm only a teacher who tried to seperate
the office-LAN from the students-LAN. Both should be connected to a
Printer-Server.
Lutz Worch
>
> Lutz Worch wrote:
>
> > With the following VLAN-Configuration port 1 and port 3 are connected, but there is no connection
> > between port 2 and port 3:
> >
> > Port A_VLAN B_VLAN
> > 1 untagged no
> > 2 no untagged
> > 3 untagged tagged
>
> You'll have to make all outbound traffic at port 3 tagged, the traffic at
> the ports 1 & 2 has to be made untagged. I just wonder, why you can
> configure the procurve to tag the traffic coming from B_VLAN but remove the
> tag from A_VLAN at the same time on the same switch port - that's quite weird.
I can _not_ configure A_VLAN _and_ B_VLAN both to be untagged on port
3. It is possible to make both VLANs tagged.
> Furthermore, you'll have to tell your NIC's drivers, that it is member of
> _both_ VLANs - B_VLAN as well as A_VLAN. As far as I know, the normal
> EtherExpress drivers are only capable of taking just one VLAN ID, thus,
> making the interface listening to a single VLAN only. With the Intel
The decription to the adapter:
The requirements for effectively using IEEE 802.1p tagging are:
- The other device receiving and routing 802.1p tagged packets must
support 802.1p.
- The adapters an these device must support 802.1p (adapter using the
Intel 82558 or later Ethernet controller). All PRO/10+ adapters support
802.1p. Pro/100B adapters do not.
- If you're setting VLANs and packet tagging on the same adapter, the
'802.1p/802.1Q Tagging' must be 'Enabled' (so did I) on the Intel PROSet
Advanced Setting tab.
> EtherExpress 100+ Server Adapter and its drivers (As far as I can see, the
> only difference between those 2 NICs _are_ the drivers) you can specify more
> than one VLAN ID - creating virtual interfaces (one interface for each of
> the specified VLANs) in that way.
bye
Lutz
Jim Morrison
Denis Jedig wrote:
>
>
> Rich, thanks for the clarification. Now I also can see the use of that
> feature in a mixed (non-VLAN-aware, VLAN-aware and VLAN-capable components)
> environment.
>
>
However you must be careful, a non-VLAN-aware network will see VLAN-aware packets
as corrupt and through them out.
Jim
Rich Seifert
Minor points:
-It's not the "network" that is VLAN-aware, it is the individual stations
on a given segment.
-A VLAN-unaware station does not consider a VLAN-tagged frame as being
"corrupt"; it simply encapsuates a protocol that the device does not
understand. The result is the same, i.e. the station discards the frame,
but the implication is different from a CRC error which indeed indicates a
"corrupted" frame. From the end station's perspective, there is no
difference between a VLAN-tagged frame, and a frame for a protocol not
supported by the station (e.g., a DECnet packet to a station that has only
an IP protocol stack).
-It is the responsibility of the tagging/untagging device (e.g., the
switch) to send frames in the appropriate format for a given segment/VLAN.
Unless EVERY station on the segment understands VLAN-tagging, the switch
must be set to send frames untagged for the given VLAN.
Lutz Worch
Rainer Nagel wrote:
> Try to tag both VLAN's on Port 3.
> Or tell the NIC that the untagged VLAN is untagged.
In the configurationfield there is no chance to tell the NIC anything
from any VLAN(-ID). I only can click the "802.1p/801.2Q Tagging"
"Enabled" or "Disabled" in the advanced settings.
I have to look whether its really a EEPro100+ in the slot and not a
eepro100b.
Bye
Lutz
Tony Dal Santo
> In article <slrn9p1ts6.oa...@dragon.angor.de>,
> Rainer...@tashrah.com wrote:
>>
>> That is the special feature of the "native VLAN". IMHO it is specified
>> in the 802.1Q standard that packets belonging to the native VLAN will
>> be untagged.
>> It is a nice way to shoot yourself in the foot :-/
>>
> There is no concept of a "native VLAN" in 802.1Q.
I'm guessing they are referring to the PVID assigned to the port.
> That is, frame tagging is not on a port-basis, but a port-and-VLAN basis.
You're describing whether or not frames are tagged on the way out. On
the way in, there is only 1 PVID. And if the PVID is being used
(meaning frames are arriving without tags), odds are that frames need
to be sent without tags as well for this VLAN. Maybe this is the
"native VLAN" being described.
BTW, I'd like to take a poll. For most circumstances, ports are members
of only one VLAN. Would you expect adding a port to a VLAN should also
set the PVID of that port to that VLAN, or should setting the port PVID
be a separate step? The problem is that if it is separate and the user
forgets it, it can be quite confusing. But if one step, how should it
be handled if a port is a member of multiple VLANs?
Thanks,
Tony
Rich Seifert
> Rich Seifert <ri...@richseifert.com> wrote:
> > That is, frame tagging is not on a port-basis, but a port-and-VLAN basis.
>
> You're describing whether or not frames are tagged on the way out. On
> the way in, there is only 1 PVID.
So what?
> And if the PVID is being used
> (meaning frames are arriving without tags),
You seem to imply that any frame that arrives without a tag MUST be
assigned to the PVID (the default VLAN for a given port). This is simply
not true. A frame can be assigned to any VLAN, regardless of whether it is
tagged or not upon reception. The VLAN association rules configured in the
switch determine the VLAN assignment. These rules may be based on MAC
addresses, IP subnets, protocol types, or anything you like. It is only if
none of the association rules apply to a given frame that the PVID comes
into play.
> odds are that frames need
> to be sent without tags as well for this VLAN. Maybe this is the
> "native VLAN" being described.
>
I simply don't grok the concept of a "native VLAN" at all. The term seems
to imply some (unstated) assumption that I am not making.
>
> BTW, I'd like to take a poll. For most circumstances, ports are members
> of only one VLAN.
I have not found this to be generally true. This implies that only a
port-based VLAN association rule is in effect, which is a rather weak use
of VLANs (albeit a common one).
> Would you expect adding a port to a VLAN should also
> set the PVID of that port to that VLAN, or should setting the port PVID
> be a separate step?
If you accept the idea that port-based VLANs are the only rule in effect,
then it doesn't matter what the PVID is. Remember, the PVID only comes into
play if none of the VLAN association rules apply to a given frame. If you
are using port-based VLAN mapping, then that rule applies to 100% of the
arriving untagged frames, and the PVID never takes effect.
You can look at it another (and possibly simpler) way. The idea of
port-based VLAN association can be considered the situation in which there
are NO VLAN association rules at all, and the PVID is used for 100% of
arriving untagged frames. In this case, "adding a port to a VLAN" means
setting the PVID to the VLAN desired. From an external viewpoint, there is
no difference between the two schemes above.
> The problem is that if it is separate and the user
> forgets it, it can be quite confusing.
It won't be confusing at all, since it has no effect.
> But if one step, how should it
> be handled if a port is a member of multiple VLANs?
>
In pure port-based VLANs, a given port cannot be a member of multiple
VLANs, or some serious problems arise. For all VLANs to which the port
"belongs" other than the PVID, there will be an asymmetrical VLAN
arrangement. Received frames will all be assigned to the PVID, and may not
be propagated to ports belonging to other VLANs to which that port
"belongs". Only the PVID VLAN will behave symmetrically.
M.C. van den Bovenkamp
Jim Morrison wrote:
> However you must be careful, a non-VLAN-aware network will see VLAN-aware packets
> as corrupt and through them out.
Actually, it won't. To a VLAN-unaware bridge, a VLAN-tagged frame will
look like a normal frame with ethertype 0x8100. The one problem you
might have is with frames longer than 1518 bytes (with the 4-byte 802.1Q
tag, frames can be up to 1522 bytes in lenght).
Regards,
Marco.
Tony Dal Santo
> > Would you expect adding a port to a VLAN should also
> > set the PVID of that port to that VLAN, or should setting the port PVID
> > be a separate step?
>
> If you accept the idea that port-based VLANs are the only rule in effect,
> then it doesn't matter what the PVID is.
I don't get this. If port 1 is a member of VLAN 5, yet the PVID of
port 1 is set to something other than 5, then the frame will be
classified as belonging to the "wrong" VLAN. If ingress filtering is
enabled, the frame will be discarded. Doesn't this make the PVID
"matter"?
> Remember, the PVID only comes into
> play if none of the VLAN association rules apply to a given frame. If you
> are using port-based VLAN mapping, then that rule applies to 100% of the
> arriving untagged frames, and the PVID never takes effect.
Huh? Isn't applying the port-based VLAN mapping (ala PVID) having the
PVID "take effect"?
> You can look at it another (and possibly simpler) way. The idea of
> port-based VLAN association can be considered the situation in which there
> are NO VLAN association rules at all, and the PVID is used for 100% of
> arriving untagged frames. In this case, "adding a port to a VLAN" means
> setting the PVID to the VLAN desired. From an external viewpoint, there is
> no difference between the two schemes above.
Ah, now I see where you are coming from (which was the heart of my
initial question/issue). I'm not comfortable making that assumption
(adding port to VLAN == setting PVID), and don't see any justification
for it in the spec. Certainly the MIB allows these activies (adding
port v.s. setting PVID) to be distinct.
> In pure port-based VLANs, a given port cannot be a member of multiple
> VLANs, or some serious problems arise. For all VLANs to which the port
> "belongs" other than the PVID, there will be an asymmetrical VLAN
> arrangement. Received frames will all be assigned to the PVID, and may not
> be propagated to ports belonging to other VLANs to which that port
> "belongs". Only the PVID VLAN will behave symmetrically.
I don't see the problem. Imagine the following scario:
+--------------+
| V1 | V2 | V3 |
+--+----+----+-+
| | |
eng | mkt
srv
VLAN 1 has engineering, VLAN 3 has marketing, and VLAN 2 is a server
for both VLANs. Ideally, the server would send tagged frames
indicating the desired VLAN. But if the server lacks this capibility,
overlapping VLANs can be used. In this case, V1 has eng + srv, V3 has
mkt + srv, and V2 would be eng + mkt + srv. The PVIDs would match the
the VLAN.
The main difficulty with this scheme is the FDB. As entries are
learned on V1 (and V3), they are also added to the FDB as being on V2
(allowing the server to send to those stations without flooding). The
server's MAC is in the FDB on VLANs 1-3. These extra FDB entries can
be done statically, or as an "overlap aware" learning process.
Finally, back to my question. If the PVID is automatically set when
the port is added to the VLAN, it causes problems when eng and mkt
ports are added (overlapped) to V2, and the admin would have to go
back and manually restore them to their previous settings.
Tony
Rich Seifert
(Tony Dal Santo) wrote:
> ri...@richseifert.com (Rich Seifert) wrote in message
> > If you accept the idea that port-based VLANs are the only rule in effect,
> > then it doesn't matter what the PVID is.
>
> I don't get this. If port 1 is a member of VLAN 5, yet the PVID of
> port 1 is set to something other than 5, then the frame will be
> classified as belonging to the "wrong" VLAN. If ingress filtering is
> enabled, the frame will be discarded. Doesn't this make the PVID
> "matter"?
>
No. If (as in your example), "Port 1 is a member of VLAN 5", then untagged
frames arriving on port 1 will be assigned to VLAN 5; that is the meaning
of the statement "Port 1 is a member of VLAN 5". The PVID is the VLAN to
which untagged frames are assigned when no other assignment rule is in
effect. However, if "Port 1 is a member of VLAN 5", then there is always an
assignment rule in effect, and the PVID is moot.
> > Remember, the PVID only comes into
> > play if none of the VLAN association rules apply to a given frame. If you
> > are using port-based VLAN mapping, then that rule applies to 100% of the
> > arriving untagged frames, and the PVID never takes effect.
>
> Huh? Isn't applying the port-based VLAN mapping (ala PVID) having the
> PVID "take effect"?
>
No. The PVID becomes moot by assigning a port to a VLAN.
>
> > In pure port-based VLANs, a given port cannot be a member of multiple
> > VLANs, or some serious problems arise. For all VLANs to which the port
> > "belongs" other than the PVID, there will be an asymmetrical VLAN
> > arrangement. Received frames will all be assigned to the PVID, and may not
> > be propagated to ports belonging to other VLANs to which that port
> > "belongs". Only the PVID VLAN will behave symmetrically.
>
> I don't see the problem. Imagine the following scario:
>
> +--------------+
> | V1 | V2 | V3 |
> +--+----+----+-+
> | | |
> eng | mkt
> srv
>
> VLAN 1 has engineering, VLAN 3 has marketing, and VLAN 2 is a server
> for both VLANs. Ideally, the server would send tagged frames
> indicating the desired VLAN. But if the server lacks this capibility,
> overlapping VLANs can be used. In this case, V1 has eng + srv, V3 has
> mkt + srv, and V2 would be eng + mkt + srv. The PVIDs would match the
> the VLAN.
>
A pure Layer 2 switch will not forward frames between VLANs, so the
situation you depict above will not work. You will require a router between
V1/V3 and their server on V2.
What you *can* do is to have the port connected to the server use
tagged-frames exclusively, and therefore you can send frames belonging to
both V1 and V2 on that port. Of course, the server needs to be VLAN-aware,
and the switch needs to be tag-capable. Note that there is no V3 when using
this model.
A more complex method that does not require frame tagging is to
differentiate between V1 and V3 through the use of MAC-address-based VLAN
assignment; for example all of the stations in engineering would belong to
V1 and all in marketing to V3, regardless of their port connections. The
server could belong to both V1 and V3. The switch would need to be able to
direct frames according to the addresses. The problem here is when the
server sends a multicast (e.g., a SAP advertisement); it is not clear to
which VLAN it should propagate.
Tony Dal Santo
> > I don't get this. If port 1 is a member of VLAN 5, yet the PVID of
> > port 1 is set to something other than 5, then the frame will be
> > classified as belonging to the "wrong" VLAN.
>
> No. If (as in your example), "Port 1 is a member of VLAN 5", then untagged
> frames arriving on port 1 will be assigned to VLAN 5; that is the meaning
> of the statement "Port 1 is a member of VLAN 5".
I (not surprisingly) see it a different way. I see port VLAN
membership being determined by all those fancy set operations. In
particular 8.11.9 part d:
The untagged set is equal to the set of Ports for which the Port Map
in the Static VLAN Registration Entry indicates that frames are to be
transmitted untagged.
How frames are classified does not determine a port's VLAN membership.
A frame could be assigned to a VLAN to which the receiving port does
not even belong.
> The PVID is the VLAN to
> which untagged frames are assigned when no other assignment rule is in
> effect.
Agreed (wow.. we found SOMETHING!)
> However, if "Port 1 is a member of VLAN 5", then there is always an
> assignment rule in effect, and the PVID is moot.
Disagree. Again, VLAN membership is not related to "assignment
rules".
> No. The PVID becomes moot by assigning a port to a VLAN.
I can't find this connection in the spec. Do you have a particular
section in mind?
> > > In pure port-based VLANs, a given port cannot be a member of multiple
> > > VLANs,
> > I don't see the problem. Imagine the following scario:
> >
> > +--------------+
> > | V1 | V2 | V3 |
> > +--+----+----+-+
> > | | |
> > eng | mkt
> > srv
> >
> > VLAN 1 has engineering, VLAN 3 has marketing, and VLAN 2 is a server
> > for both VLANs. Ideally, the server would send tagged frames
> > indicating the desired VLAN. But if the server lacks this capibility,
> > overlapping VLANs can be used. In this case, V1 has eng + srv, V3 has
> > mkt + srv, and V2 would be eng + mkt + srv. The PVIDs would match the
> > the VLAN.
>
> A pure Layer 2 switch will not forward frames between VLANs, so the
> situation you depict above will not work. You will require a router between
> V1/V3 and their server on V2.
No. In this case, a port belongs to multiple VLANs. Packets do not
cross VLAN boundaries. Maybe the picture was misleading. Say ports
1-8 are engineering, port 9 is the server, and 10-16 are marketing.
VLAN 1 has ports 1-9, VLAN 2 has ports 1-16, and VLAN 3 has ports
10-16. VLANs 1&3 cannot exchange packets. However, the server can
communicate with all stations. Broadcasts on VLAN 1 are contained to
ports 1-9, VLAN 3 to ports 10-16, and VLAN 2 broadcasts go to all
ports. Would you say this configuration is "illegal" or won't work
with port based VLANs (i.e. no tags)?
The note in section 8.11.2 talks about multiple untagged VLANs per
port on egress, as does the PICS proforma (23f.5).
Also, would you make the claim that the administrator is unable to
change the PVID on a port, or is it that the very act of changing it
changes the VLAN membership? Because 12.10.1.2 talks about setting
the PVID, but the VLAN isn't an input or output. And certainly 8.4.4
doesn't seem to place any restrictions (other than non-zero, reserved,
and range).
> What you *can* do is to have the port connected to the server use
> tagged-frames exclusively, and therefore you can send frames belonging to
> both V1 and V2 on that port.
Agreed. I mentioned that first thing ("Ideally...."). Though I
wonder what process the server would use to determine the tag. Any
idea how well this is supported in the real world (other than just
stuffing in a static tag)?
Sorry to be giving you such shit Rich, but either I've got a
fundamental misunderstanding about VLANs, or we are seriously
miscommunicating.
Thanks,
Tony
Rich Seifert
> ri...@richseifert.com (Rich Seifert) wrote in message
news:<rich-ya02306004...@nntp.ix.netcom.com>...
>
> > > I don't get this. If port 1 is a member of VLAN 5, yet the PVID of
> > > port 1 is set to something other than 5, then the frame will be
> > > classified as belonging to the "wrong" VLAN.
> >
> > No. If (as in your example), "Port 1 is a member of VLAN 5", then untagged
> > frames arriving on port 1 will be assigned to VLAN 5; that is the meaning
> > of the statement "Port 1 is a member of VLAN 5".
>
Note that I am using "Port x is a member of VLAN n" here (your words, not
mine) to mean "Port x is in the member-set of VLAN n". See below for the
distinction.
>
> How frames are classified does not determine a port's VLAN membership.
> A frame could be assigned to a VLAN to which the receiving port does
> not even belong.
>
You seem to be equating the concept of a port being assigned to a VLAN in a
purely-port-based-VLAN switch with the concept of a switch port being in
the member-set for a given VLAN. The latter concept can result in
differences from the former when some VLAN-assignment rule *other than
port-based* is in effect. From your original post, I gathered that the
switch in question could ONLY do port-based VLANs. If so, then assigning a
port to a VLAN places the port in the member-set for that VLAN. Said
another way, the member-set for a VLAN is exactly the same as the set of
ports assigned to that VLAN. Given this situation, the PVID becomes moot,
as I discussed earlier.
Now, if you have some other type of VLAN assignment rule in effect (e.g.,
MAC address-based), *along with* a port-based assignment in the event of
no-match for the MAC address, then I understand your confusion. In this
case, a port may be in the member-set for a number of VLANs (based on MAC
address mappings). There will also be a VLAN assignment for the port-based
rule; this latter assignment corresponds to the PVID.
If a frame arrives on a port, first the MAC-address mapping is checked; if
a match is found, the frame is assigned to the appropriate VLAN. I agree
that the port on which the frame arrived may NOT be in the member set of
the VLAN so assigned (a so-called asymmetrical VLAN). If an address match
is not found, the frame is assigned to the port-based VLAN associated with
that port (the PVID).
> > The PVID is the VLAN to
> > which untagged frames are assigned when no other assignment rule is in
> > effect.
>
> Agreed (wow.. we found SOMETHING!)
>
> > However, if "Port 1 is a member of VLAN 5", then there is always an
> > assignment rule in effect, and the PVID is moot.
>
> Disagree. Again, VLAN membership is not related to "assignment
> rules".
>
VLAN membership is *precisely* the assignment rules. Note that "ports" do
not belong to VLANs; *frames* belong to VLANs, and are assigned by the
assignment rules. Ports may be in the member-sets of VLANs (which is NOT
the same as belonging to a VLAN); the member-set is the set of ports
through which it is possible to reach all end stations running applications
that need to see frames for the VLAN in question.
> > > Imagine the following scario:
> > >
> > > +--------------+
> > > | V1 | V2 | V3 |
> > > +--+----+----+-+
> > > | | |
> > > eng | mkt
> > > srv
> > >
> > > VLAN 1 has engineering, VLAN 3 has marketing, and VLAN 2 is a server
> > > for both VLANs. Ideally, the server would send tagged frames
> > > indicating the desired VLAN. But if the server lacks this capibility,
> > > overlapping VLANs can be used. In this case, V1 has eng + srv, V3 has
> > > mkt + srv, and V2 would be eng + mkt + srv. The PVIDs would match the
> > > the VLAN.
> >
> > A pure Layer 2 switch will not forward frames between VLANs, so the
> > situation you depict above will not work. You will require a router between
> > V1/V3 and their server on V2.
>
> No. In this case, a port belongs to multiple VLANs. Packets do not
> cross VLAN boundaries. Maybe the picture was misleading. Say ports
> 1-8 are engineering, port 9 is the server, and 10-16 are marketing.
> VLAN 1 has ports 1-9, VLAN 2 has ports 1-16, and VLAN 3 has ports
> 10-16. VLANs 1&3 cannot exchange packets. However, the server can
> communicate with all stations. Broadcasts on VLAN 1 are contained to
> ports 1-9, VLAN 3 to ports 10-16, and VLAN 2 broadcasts go to all
> ports. Would you say this configuration is "illegal" or won't work
> with port based VLANs (i.e. no tags)?
>
If there are no tags, then how does the switch "know" which multicast
frames emitted by the server belong to VLAN 1 and which belong to VLAN 2?
Without this knowledge, there is no way to know to which ports to propagate
the frames.
> > What you *can* do is to have the port connected to the server use
> > tagged-frames exclusively, and therefore you can send frames belonging to
> > both V1 and V2 on that port.
>
> Agreed. I mentioned that first thing ("Ideally...."). Though I
> wonder what process the server would use to determine the tag.
It depends on what rules are being used for VLAN assignment. It could be
protocol-based, application-based, subnet-based, etc.
Tony Dal Santo
> In article <6586b36c.01092...@posting.google.com>, t...@pt.com
> (Tony Dal Santo) wrote:
> Note that I am using "Port x is a member of VLAN n" here (your words, not
> mine) to mean "Port x is in the member-set of VLAN n". See below for the
> distinction.
Yes by "is a member" I mean in the member-set.
> > How frames are classified does not determine a port's VLAN membership.
> > A frame could be assigned to a VLAN to which the receiving port does
> > not even belong.
> >
>
> You seem to be equating the concept of a port being assigned to a VLAN in a
> purely-port-based-VLAN switch with the concept of a switch port being in
> the member-set for a given VLAN. The latter concept can result in
> differences from the former when some VLAN-assignment rule *other than
> port-based* is in effect.
> From your original post, I gathered that the
> switch in question could ONLY do port-based VLANs.
This is correct. We are just talking port-based VLANs.
> If so, then assigning a
> port to a VLAN places the port in the member-set for that VLAN. Said
> another way, the member-set for a VLAN is exactly the same as the set of
> ports assigned to that VLAN.
Agreed.
> Given this situation, the PVID becomes moot, as I discussed earlier.
I didn't get it then, I don't get it now. If the port is in the
member-sets of multiple VLANs, the PVID is the ONLY thing that
determines how the frames (not ports) are associated with VLANs. Or do
you still maintain that an untagged port cannot be in the member-set
of multiple VLANs?
> Now, if you have some other type of VLAN assignment rule in effect ...
> <snip>
> There will also be a VLAN assignment for the port-based
> rule; this latter assignment corresponds to the PVID.
Again, I see no relation between VLAN membership, and any tie to the
PVID. Now I certainly agree that in most situations, the PVID will
match the VLAN to which member-set it belongs. But what I am saying is
I don't see anywhere that this is required. The administrator is free
to change the PVID to another value, and this change will cause
incoming frames to be associated with the VLAN matching the PVID. What
member-set(s) the port is a member of has no input.
I'm guessing your response will be that changing the PVID would also
change to which member-set the port belongs. If so, can you show it to
me in the spec?
> If an address match
> is not found, the frame is assigned to the port-based VLAN associated with
> that port (the PVID).
Yes, the PVID. Not the port. Would you say the logic goes something
like this:
for all VLANs
if <recv-port> is in member-set of VLAN <v>
then associate <frame> with <v>
I'd say it goes like:
associated <frame> with <port PVID>
And that the port MIGHT NOT be in the member-set of the VLAN that
matches the PVID.
> > Disagree. Again, VLAN membership is not related to "assignment
> > rules".
By this, I mean ports in VLAN member-sets.
> VLAN membership is *precisely* the assignment rules. Note that "ports" do
> not belong to VLANs; *frames* belong to VLANs, and are assigned by the
> assignment rules.
With this I agree. And the PVID is the input to (this particular)
assigning rule, not the port number, nor the VLAN member-sets.
> Ports may be in the member-sets of VLANs (which is NOT
> the same as belonging to a VLAN); the member-set is the set of ports
> through which it is possible to reach all end stations running applications
> that need to see frames for the VLAN in question.
I can pretty much agree with this as well.
> > Say ports
> > 1-8 are engineering, port 9 is the server, and 10-16 are marketing.
> > VLAN 1 has ports 1-9, VLAN 2 has ports 1-16, and VLAN 3 has ports
> > 10-16. VLANs 1&3 cannot exchange packets. However, the server can
> > communicate with all stations. Broadcasts on VLAN 1 are contained to
> > ports 1-9, VLAN 3 to ports 10-16, and VLAN 2 broadcasts go to all
> > ports. Would you say this configuration is "illegal" or won't work
> > with port based VLANs (i.e. no tags)?
>
> If there are no tags, then how does the switch "know" which multicast
> frames emitted by the server belong to VLAN 1 and which belong to VLAN 2?
> Without this knowledge, there is no way to know to which ports to propagate
> the frames.
All frames received on port 2 belong to VLAN 2 (via the PVID). The
port member-set (and untagged set) for VLAN 2 is used to determine the
egress ports. In this case, the untagged set is ports 1-16. For
multicasts received on port 1, the untagged set for VLAN 1 is ports
1-9. Port 10 (VLAN 3) would use ports 9-16. Where is the difficulty?
Tony
Rich Seifert
> ri...@richseifert.com (Rich Seifert) wrote in message
news:<rich-ya02306004...@nntp.ix.netcom.com>...
> > In article <6586b36c.01092...@posting.google.com>, t...@pt.com
> > (Tony Dal Santo) wrote:
> This is correct. We are just talking port-based VLANs.
>
> > If so, then assigning a
> > port to a VLAN places the port in the member-set for that VLAN. Said
> > another way, the member-set for a VLAN is exactly the same as the set of
> > ports assigned to that VLAN.
>
> Agreed.
>
> > Given this situation, the PVID becomes moot, as I discussed earlier.
>
> I didn't get it then, I don't get it now. If the port is in the
> member-sets of multiple VLANs, the PVID is the ONLY thing that
> determines how the frames (not ports) are associated with VLANs.
OK, now I see where we diverged. You are talking about having a single port
in the member-set of multiple VLANs, all port-based. I was (unjustifiably)
assuming disjoint VLAN member-sets.
Yes, if a port is in the member-set of multiple VLANs, it is the PVID that
determines the VLAN association for a received, untagged frame.
> Or do
> you still maintain that an untagged port cannot be in the member-set
> of multiple VLANs?
>
I don't think that I asserted that claim, but I don't find a lot of use for
overlapping port-based VLANs using untagged frames. As you note, some
undesirable asymmetries are created; all received frames are assigned to a
single VLAN, while transmitted frames can come from multiple VLANs.
> Now I certainly agree that in most situations, the PVID will
> match the VLAN to which member-set it belongs.
It would be pretty strange if it didn't. That would imply a total
asymmetry, where the VLAN assignment of all received frames was never the
VLAN assignment of any transmitted frames. I am hard pressed to conceive of
an application environment that would benefit from this arrangement.
> But what I am saying is
> I don't see anywhere that this is required.
Of course it is not *required*. The standard does not *require* that you
build a useful network configuration, nor does it ensure that all possible
configurations that comply with the standard will be useful. The
configuration should be appropriate for the application environment. I am
simply at a loss to conceive of an application environment that results in
the PVID/member-set assignments that we were discussing.
> The administrator is free
> to change the PVID to another value, and this change will cause
> incoming frames to be associated with the VLAN matching the PVID. What
> member-set(s) the port is a member of has no input.
>
It does if you want your network to work properly for the application in
question.
> I'm guessing your response will be that changing the PVID would also
> change to which member-set the port belongs. If so, can you show it to
> me in the spec?
>
Of course this isn't in the standard, any more than changing one's car
engine from gasoline to diesel will automatically change the fuel in the
tank. However, most applications (and car shops) would consider this a
generally prudent course of action.
Tony Dal Santo
> In article <6586b36c.01092...@posting.google.com>, t...@pt.com
> (Tony Dal Santo) wrote:
> OK, now I see where we diverged. You are talking about having a single port
> in the member-set of multiple VLANs, all port-based. I was (unjustifiably)
> assuming disjoint VLAN member-sets.
At last we're on the same page!
> Yes, if a port is in the member-set of multiple VLANs, it is the PVID that
> determines the VLAN association for a received, untagged frame.
I'd say that (for port based VLANs) the PVID always determins the VLAN
association. No matter if the the port is in the member-sets of 1, 2
or N VLANs. This way you don't have a special case. As far as I can
tell, the spec seems to read this way as well.
>> Or do
>> you still maintain that an untagged port cannot be in the member-set
>> of multiple VLANs?
> I don't think that I asserted that claim,
Message-ID: <rich-ya02306004...@news.megapathdsl.net>
In pure port-based VLANs, a given port cannot be a member of multiple
VLANs, or some serious problems arise. For all VLANs to which the port
"belongs" other than the PVID, there will be an asymmetrical VLAN
arrangement. Received frames will all be assigned to the PVID, and may not
be propagated to ports belonging to other VLANs to which that port
"belongs". Only the PVID VLAN will behave symmetrically.
Maybe by "cannot" you meant shouldn't. Though I still don't see the
"serious problems".
> but I don't find a lot of use for
> overlapping port-based VLANs using untagged frames.
What about the example of a single (VLAN unaware) server for multiple
VLANs? How else can you accomplish this? Even multiple NICs don't really
help, unless you want to subnet everything and do layer 3 routing (if
you can). Also overlapping VLANs work very well for "dumb" devices
like network printers.
> As you note, some undesirable asymmetries are created;
I don't see them as "undesirable asymmetries". That is the feature
letting me share some resources, yet keeping others separate.
> all received frames are assigned to a
> single VLAN, while transmitted frames can come from multiple VLANs.
I'm not sure I understand this concern (who is transmitting, the
host or switch), and what does it mean to "come from mulitple VLANs"?
How does this differ from tag aware devices that send frames beloning
to multiple VLANs on the same port?
In my example, ports 1-9 are the engineering VLAN 1, ports 9-16 are
marketing VLAN 3, and ports 1-16 are server VLAN 2.
All frames received on ports 1-8 (from engineering hosts) are classified
as belonging to VLAN 1. It doesn't matter if they are going to other
engineering hosts or the server.
All frames received on port 9 (from server) belong to VLAN 2. So
engineering hosts send on VLAN 1, and receive on VLANs 1&2. The server
sends on VLAN 2, and receives on VLANs 1&3 (and 2). Broadcasts & floods
are all contained to the proper VLAN. Where's the problem?
So, if you can see the usefulness of overlapping VLANs, this leads
to my original question. How should the PVID of a port be set? Should
it be set automatically when a port is assigned to the VLAN? What
if it is in the member-set of multiple VLANs? Which PVID then? And in
the example, if port 9 is removed from VLAN 2, should the PVID remain
set to 2, or should it be "automatically" changed to 1 or 3?
This is pretty much a user interface question, and I was wondering
what behavior the experts on the list expect from similar equipment.
Do network admins ever manually assign PVIDs?
Thanks,
Tony
Rich Seifert
>
> > Yes, if a port is in the member-set of multiple VLANs, it is the PVID that
> > determines the VLAN association for a received, untagged frame.
>
> I'd say that (for port based VLANs) the PVID always determins the VLAN
> association.
No. The PVID is used ONLY for untagged frames. Tagged frames are trusted to
carry the proper VLAN association in the tag.
> > but I don't find a lot of use for
> > overlapping port-based VLANs using untagged frames.
>
> What about the example of a single (VLAN unaware) server for multiple
> VLANs? How else can you accomplish this?
You can't really get complete traffic isolation in this scenario; it's an
asymmetrical arrangement. Traffic emanating within the subset VLAN will
stay within the subset, but multicasts emanating from the server (superset
VLAN) cannot be segregated into the appropriate subset VLAN, since they are
untagged.
> > all received frames are assigned to a
> > single VLAN, while transmitted frames can come from multiple VLANs.
>
> I'm not sure I understand this concern (who is transmitting, the
> host or switch), and what does it mean to "come from mulitple VLANs"?
> How does this differ from tag aware devices that send frames beloning
> to multiple VLANs on the same port?
The difference is that, with tag-aware devices, I can keep the VLANs
separate. As shown above, this is not possible with overlapping VLANs using
untagged frames.
>
> In my example, ports 1-9 are the engineering VLAN 1, ports 9-16 are
> marketing VLAN 3, and ports 1-16 are server VLAN 2.
>
This configuration presumes that EVERYONE (engineering and marketing) want
to hear EVERYTHING emanating from the server (multicasts in particular).
This is a very narrow, special case. It precludes server-based applications
that use multicast within a given department.
It also requires that the subset VLANs be *proper subsets*; consider the
havoc if the subset VLANs are not completely contained within the "server
VLAN". (Do a Venn diagram...)
Let's look at this from a Network Layer perspective (assuming IP): Is there
(a) one IP subnet for the whole thing, (b) one subnet for engineering and
one for marketing, or (c) one for engineering, one for marketing, and one
for the server?
Clearly, (c) cannot work at all, since it would require that the clients
and server (who are in different subnets) intercommunicate without the
presence of a router.
(b) could work, but it requires that the server use different source IP
addresses when communicating with the engineering dept. and the marketing
dept. Again, multicasts emanating from the server become problematic, since
they will propagate to both client VLANs, regardless of which subnet they
are associated with.
(a) is problematic, in that it creates a subnet across which there is
imperfect connectivity. Protocols such as ARP assume that all stations on a
subnet can hear/talk to all other stations. With a segregated subnet, it
becomes possible to assign the same IP address to separate devices (in each
department), with the clients unable to detect the condition (ARP'ing
yourself will not get a response).
> All frames received on ports 1-8 (from engineering hosts) are classified
> as belonging to VLAN 1. It doesn't matter if they are going to other
> engineering hosts or the server.
>
> All frames received on port 9 (from server) belong to VLAN 2. So
> engineering hosts send on VLAN 1, and receive on VLANs 1&2. The server
> sends on VLAN 2, and receives on VLANs 1&3 (and 2). Broadcasts & floods
> are all contained to the proper VLAN. Where's the problem?
>
Again, you presume that multicasts and unknown-unicasts should be heard by
all parties in all departments. This is a special case, and not generally
true.
Anoop Ghanwani
what is spelled out in the 802.1Q specification as the case for
"Shared VLAN Learning" (SVL) where all VLANs share the same filtering
database (as opposed to "Independent VLAN Learning" (IVL) where each
VLAN uses a separate database).
Here's how you would have to set things up to get this to work:
Ports 1-8: (engineering)
PVID = VLAN 1
VLAN member set = {VLAN 1, VLAN 2}
Port 9: (the server port)
PVID = VLAN 2
VLAN member set = {VLAN 1, VLAN 2, VLAN 3}
Ports 10-16: (marketing)
PVID = VLAN 3
VLAN member set = {VLAN 2, VLAN3}
The PVIDs are significant only if the traffic received at
the port is untagged.
In this case, traffic from either engineering or marketing gets
to the server. Broadcast traffic from the server gets to everybody.
Unicast traffic from the server will get to the right client based
on MAC address, because learning is shared across all VLANs.
At the time that the standard was being developed, 3Com was big on SVL,
Cisco was big on IVL. Some vendors (such as Extreme) decided to
do both and leave it as a user-configurable option.
If using IP, in order to make this work you would have to
have the engineering in one subnet, marketing on a different
subnet, and the server on a subnet with a shorter mask such
that it encompasses both the engineering and marketing subnets.
As to your question about assignment of PVIDs, I don't see
a way other than to assign it manually.
-Anoop
Tony Dal Santo <t...@pt.com> wrote in message news:<gxpv7.32$bE1.1238@client>...
Albert Manfredi
> It's interesting that you ask about this problem. This is exactly
> what is spelled out in the 802.1Q specification as the case for
> "Shared VLAN Learning" (SVL) where all VLANs share the same
filtering
> database (as opposed to "Independent VLAN Learning" (IVL) where
each
> VLAN uses a separate database).
>
> Here's how you would have to set things up to get this to work:
> Ports 1-8: (engineering)
> PVID = VLAN 1
> VLAN member set = {VLAN 1, VLAN 2}
>
> Port 9: (the server port)
> PVID = VLAN 2
> VLAN member set = {VLAN 1, VLAN 2, VLAN 3}
>
> Ports 10-16: (marketing)
> PVID = VLAN 3
> VLAN member set = {VLAN 2, VLAN3}
>
> The PVIDs are significant only if the traffic received at
> the port is untagged.
>
> In this case, traffic from either engineering or marketing gets
> to the server. Broadcast traffic from the server gets to
everybody.
Everything seemed fine until the last sentence. Is it unavoidable
for broadcasts from the server to get to all VLANs? Wouldn't a
tagged broadcast frame only be sent to the Ethernet ports that
support that VID?
Here's a quote from IEEE 802.1Q:
"8.14.1 End stations
[ ... ]
"The broadcast address and other group MAC Addresses apply to the
use of the MAC Service provided by a Bridged LAN as a whole. In the
absence of explicit filters configured via management as Static
Filtering Entries, or via GMRP as Group Registration Entries (8.11,
Clause 12, and ISO/IEC 15802-3, Clause 10), frames with such
destination addresses are relayed throughout the Bridged LAN."
This seems to leave open the possibility that even broadcast frames
can be filtered.
> If using IP, in order to make this work you would have to
> have the engineering in one subnet, marketing on a different
> subnet, and the server on a subnet with a shorter mask such
> that it encompasses both the engineering and marketing subnets.
Yes, so let's say the server is connected to a router via a VLAN
trunk. The frames are all tagged. If that server needs to ARP a
particular IP subnet, which is reachable over this VLAN trunk, the
server ought to know what VLAN ID to include in frames for that IP
subnet, and ARP broadcasts ought to be able to be tagged
appropriately and only affect the hosts of that single IP subnet.
No?
Anoop Ghanwani
I agree with your analysis. The difference is in the network design.
In your case, "engineering" is on VLAN 1, "marketing" is on VLAN 2,
and the server is either on VLAN 1 or VLAN 2 -- it's intelligent
enough to know which to choose. In practice, with a single interface
on the server, this would be very hard, if not impossible without
changing the software in the server.
In the example that I cited, "engineering" is on VLAN 1, "marketing"
is on VLAN 2, and the server is on VLAN 3 which is defined such that
it encompasses both VLAN 1 and VLAN 2. In this case, the server
need not even be capable of tagging traffic. To the casual observer,
it may seem that traffic is leaking across VLANs, but in fact,
"engineering's" traffic will never end up on "marketing's" VLAN
and vice versa. That the server traffic ends up on both is an
artifact of the network design. And this is usually OK, because it's
typically a client that initiates a conversation with a server,
not vice versa.
-Anoop
Rich Seifert
an...@alumni.duke.edu (Anoop Ghanwani) wrote:
> That the server traffic ends up on both is an
> artifact of the network design. And this is usually OK, because it's
> typically a client that initiates a conversation with a server,
> not vice versa.
>
Except that clients often learn about the existence of a service
application by listening to some form of service advertisement, sent as a
multicast by the server. If all server multicasts propagate to both client
VLANs, then both client sets will know about all such service applications;
it will not be possible to provide distinct sets of services for distinct
sets of clients. It's all or nothing.
Anoop Ghanwani
and VLAN 3 in my response. Below is the response edited
to correct that mistake. -Anoop
an...@alumni.duke.edu (Anoop Ghanwani) wrote in message news:<50bde0e6.01102...@posting.google.com>...
> In your case, "engineering" is on VLAN 1, "marketing" is on VLAN 3,
> and the server is either on VLAN 1 or VLAN 3 -- it's intelligent
> enough to know which to choose. In practice, with a single interface
> on the server, this would be very hard, if not impossible without
> changing the software in the server.
>
> In the example that I cited, "engineering" is on VLAN 1, "marketing"
> is on VLAN 3, and the server is on VLAN 2 which is defined such that
> it encompasses both VLAN 1 and VLAN 3. In this case, the server
Tony Dal Santo
> In article <50bde0e6.01102...@posting.google.com>,
> an...@alumni.duke.edu (Anoop Ghanwani) wrote:
>> That the server traffic ends up on both is an
>> artifact of the network design.
> Except that clients often learn about the existence of a service
> application by listening to some form of service advertisement, sent as a
> multicast by the server. If all server multicasts propagate to both client
> VLANs, then both client sets will know about all such service applications;
> it will not be possible to provide distinct sets of services for distinct
> sets of clients. It's all or nothing.
Yes, this is true. However, part of this discussion was questioning
the value of a single untagged port belonging to multiple VLANs (i.e.
overlapping VLANs). From a previous post by Rich:
[...] but I don't find a lot of use for overlapping port-based
VLANs using untagged frames.
I think the example provided does show the value. Granted, it doesn't
do everything that can be done via tagging (e.g. your example of
multicasts), but it does show a useful real-world example.
I'll go a step further. Given that the server cannot do tagging, I
don't see a significantly better alternative. And even if the server
can tag (from a previous post between Rich and myself):
> > Though I wonder what process the server would use to determine the tag.
> It depends on what rules are being used for VLAN assignment. It could be
> protocol-based, application-based, subnet-based, etc.
I question whether this level of sophisitication exists on servers, or
how feasible it is. Besides, I expect many of the boundaries between
VLANs are more geographic/political, than protocol/application. Are
there any readers of this group that can share any real-world experiences
on tag aware servers?
In order to allow sophisticated server tagging, I expect that servers
will end up querying the switches to get the necessary information. At
least until the clients also become VLAN/tag aware, and can dynamically
join VLANs.
Tony
Rich Seifert
>
> In order to allow sophisticated server tagging, I expect that servers
> will end up querying the switches to get the necessary information.
That is really a bass-ackwards way of doing things. I agree that
*currently*, many switches have sophisticated frame-parsing mechanisms (aka
"classification engines") that can deduce the VLAN association from a
frame's contents. The reason for providing such capability within switches
is that the end stations are not currently VLAN-aware, and cannot do the
tagging themselves.
What you appear to suggest is that: (a) the end stations should continue to
send "blindly" to the switches, (b) the switches should parse the frames to
determine what it was that the end station sent, and (c) the switches
should inform the end stations of what it was that they sent so that, (d)
the end stations can then apply the appropriate VLAN tag. This seems odd,
at best, since the end stations ALREADY KNOW what they sent; there is no
good reason to have the switch decode the frame to tell the end station
what it already knows.
What is needed are APIs within the server that allow tag selection as a
function of application, protocol type, etc. I agree that these do not
exist today (at least not widely), nor are there applications that are
written to take advantage of such services. I discuss these issues and my
view of the future of VLANs in Chapter 11 of "The Switch Book".
Jerry Mendes
Good luck with your quest, Don Quixote. :)
-- Jerry Mendes, Principal Consultant Voice: (415) 381-5500 DataComm Insights FAX: (415) 381-5502 150 Seminary Drive Email: men...@nospam.datacomm-insights.com Mill Valley, California 94941 http://www.datacomm-insights.com