Mac address and VLAns

Mac address and VLAns

NewsGroups | Search | Tools
 comp.dcom.lans.ethernet  Post an article  get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content  add this group's latest topics to your Google content  YahooMyWeb Yahoo!  Google Google  Windows Live Favorites Windows Live  del.icio.us del.icio.us  digg digg  Add to Netscape Netscape
Subject Author Date
Mac address and VLAns vicky 06-17-2008
Posted by vicky on June 17, 2008, 1:27 am
If you were  Registered and logged in, you could reply and use other advanced thread options
Hi,

Plz explain ...

A single mac address is able to be a member of multiple vlans.



VIkrant

Posted by Walter Roberson on June 17, 2008, 8:09 am

> Plz explain ...

> A single mac address is able to be a member of multiple vlans.

MAC addresses need not be globally unique: they only have to be
unique within the broadcast domain. Broadcast domains can be
physically seperated (different segments), or can use different
protocols, or can be logically seperated (different VLANs.)



Posted by Rich Seifert on June 17, 2008, 11:05 am
In article

> Hi,
>
> Plz explain ...
>
> A single mac address is able to be a member of multiple vlans.
>

A MAC address is not a "member" of a VLAN. It is *frames* (not MAC
addresses, ports, IP addresses, or anything else) that are associated
with particular VLANs. The rules for associating frames with VLANs can
be based on almost any characteristic of the frame, such as:

-the switch port on which the frame arrived (port-based VLAN)
-the MAC source address in the frame (MAC address-based VLAN)
-the IP subnet identifier within the frame (IP subnet-based VLAN)
-the TCP/UDP port number within the frame (application-based VLAN), etc.

While many people may *think* they are associating a port (or a MAC
address) with a VLAN, they are really specifying a VLAN-association rule
that is based on switch port (or MAC address); the distinction is
subtle, but important, particularly when end stations are VLAN-aware,
and perform the association themselves.

Consider a multi-homed VLAN-aware end station (e.g., a server) that
associates frames with VLANs based on IP subnet identifiers. Since that
station has multiple IP addresses (that's what multi-homed means), it
will emit frames carrying different VLAN IDs, depending on the subnet to
which the frame is directed. However, that station may have the same MAC
address on all subnets (sidebar: I never said that the server had
multiple physical interfaces, and even if it did, it is permissible to
assign the same MAC address to multiple interfaces that are not on the
same LAN). Thus, this is a device that, according to *your* model, has a
MAC address that is a "member" of multiple VLANs. This dichotomy
disappears when one realizes that it is the *frames* that are associated
with the VLANs, and each frame is associated with one (and only one)
VLAN.

If you don't like the multi-homed station example, the same phenomenon
arises in the case of a single-homed station that associates VLAN IDs
based on application streams; e.g., a video delivery server (think:
Intranet multicast delivery of training videos) that assigns a VLAN to
each video stream so that bandwidth can be conserved within an
enterprise. Another example is a VoIP conference-call server,
associating each conference call (multicast) to a VLAN.

There is a complete explanation of this in Chapter 11 of "The Switch
Book."


--
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

Posted by vicky on June 20, 2008, 12:04 am
wrote:
> In article
>
> > Hi,
>
> > =A0 =A0 =A0 =A0Plz explain =A0...
>
> > =A0 =A0 =A0 =A0 A single mac address is able to be a member of multiple=
vlans.
>
> A MAC address is not a "member" of a VLAN. It is *frames* (not MAC
> addresses, ports, IP addresses, or anything else) that are associated
> with particular VLANs. The rules for associating frames with VLANs can
> be based on almost any characteristic of the frame, such as:
>
> -the switch port on which the frame arrived (port-based VLAN)
> -the MAC source address in the frame (MAC address-based VLAN)
> -the IP subnet identifier within the frame (IP subnet-based VLAN)
> -the TCP/UDP port number within the frame (application-based VLAN), etc.
>
> While many people may *think* they are associating a port (or a MAC
> address) with a VLAN, they are really specifying a VLAN-association rule
> that is based on switch port (or MAC address); the distinction is
> subtle, but important, particularly when end stations are VLAN-aware,
> and perform the association themselves.
>
> Consider a multi-homed VLAN-aware end station (e.g., a server) that
> associates frames with VLANs based on IP subnet identifiers. Since that
> station has multiple IP addresses (that's what multi-homed means), it
> will emit frames carrying different VLAN IDs, depending on the subnet to
> which the frame is directed. However, that station may have the same MAC
> address on all subnets (sidebar: I never said that the server had
> multiple physical interfaces, and even if it did, it is permissible to
> assign the same MAC address to multiple interfaces that are not on the
> same LAN). Thus, this is a device that, according to *your* model, has a
> MAC address that is a "member" of multiple VLANs. This dichotomy
> disappears when one realizes that it is the *frames* that are associated
> with the VLANs, and each frame is associated with one (and only one)
> VLAN.
>
> If you don't like the multi-homed station example, the same phenomenon
> arises in the case of a single-homed station that associates VLAN IDs
> based on application streams; e.g., a video delivery server (think:
> Intranet multicast delivery of training videos) that assigns a VLAN to
> each video stream so that bandwidth can be conserved within an
> enterprise. Another example is a VoIP conference-call server,
> associating each conference call (multicast) to a VLAN.
>
> There is a complete explanation of this in Chapter 11 of "The Switch
> Book."
>
> --
> Rich Seifert =A0 =A0 =A0 =A0 =A0 =A0 =A0Networks and Communications Consu=
lting
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 21885 Bear Creek Way
> (408) 395-5700 =A0 =A0 =A0 =A0 =A0 =A0Los Gatos, CA 95033
> (408) 228-0803 FAX
>
> Send replies to: usenet at richseifert dot com

------------------------------------------------------------------

Sir ...

As u mentioned about a book .... The Switch Book...
can u plz ... give a full detail of this book (publication, writer
etc)
so that it is easy for me to find it at book stores....

Vikrant.

Posted by jpd on June 20, 2008, 1:30 am
On Thu, 19 Jun 2008 21:04:01 -0700 (PDT),
> Sir ...
>
> As u mentioned about a book .... The Switch Book...
> can u plz ... give a full detail of this book (publication, writer
> etc)
> so that it is easy for me to find it at book stores....
>
> Vikrant.

For example, see here:

http://www.amazon.com/Switch-Book-Complete-Switching-Technology/dp/0471345865

Finding this cost me less than 10 seconds, even without using the
knowledge who the author is (which anyone regularly reading this group
knows). I don't know about you, but that is less than the time it took
me to write this followup posting.


--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
This message was originally posted on Usenet in plain text.
Any other representation, additions, or changes do not have my
consent and may be a violation of international copyright law.

Similar ThreadsPosted
MAC address of an IPv6 address April 10, 2007, 4:42 pm
Valid mac address February 7, 2006, 8:21 pm
Change MAC address June 20, 2007, 7:19 am
MAC destination address July 19, 2007, 12:06 am
Change IP and MAC address December 10, 2007, 4:59 am
Multicast MAC and Unicast IP Address August 18, 2005, 4:54 pm
Knowledge of destination MAC address July 18, 2007, 7:54 am
assigning MAC address to a VLAN March 14, 2008, 4:58 am
Source MAC address per IP packet June 15, 2008, 3:02 pm
trace laptop via hardware address July 27, 2005, 8:47 am

other useful resources:
The Federal Communications Commission (FCC)
Telecommunications Industry Association
Electronic and Software Security Products and Services
International Telecommunication Union

Custom CGI Perl and PHP programming by 1-Script.com

Contact Us | Privacy Policy
The site map in XML format XML site map