Actually not. Collision domains have a layer 1 scope (assuming CSMA/CD media), and
broadcast domains a layer 2 scope.
*********** REPLY SEPARATOR ***********
On 1/18/2001 at 9:39 AM Lowell Sharrah wrote:
>are we talking about the difference between collision domains and broadcast domains?
>
>>>> "Peter Van Oene" <[EMAIL PROTECTED]> 01/18/01 09:07AM >>>
>To me, there is no concept of a layer three VLAN. If you chose to route IP, you need
>a router, whether you have dynamic or statically configured broadcast scopes is fully
>irrelevant. If you are talking about dynamic VLAN membership based on IP address (or
>protocol for that matter), then I will agree that some level of layer 3 and
>potentially above awareness is required to identify the address or protocol.
>However, any such application that I have seen (mostly Xylan) performed this at the
>switch level.
>
>Given most networks are running DHCP, or moving in that direction, VLAN's that
>determined membership based on IP address would be a challenging thing to accomplish.
>
>
>*********** REPLY SEPARATOR ***********
>
>On 1/18/2001 at 9:21 AM Ruben Arias wrote:
>
>>VLANs can be defined by MAC address or IP address.
>>When MAC address is used, you have a layer 2 VLAN, when IP address is used you have
>a layer 3 VLAN and a router is needed.
>>Layer 2 VLANs mostly used for filtering (never done, I supose is a hard work to
>mantain)
>>
>>
>>Peter Van Oene wrote:
>>
>>> Just for clarity, VLAN's are a layer 2 concept and IP is of course a layer 3
>(please do not start with the "but what layer is arp again" :)
>>>
>>> Despite subnets and VLAN's generally happening on a 1:1 basis in a lot of
>theoretical and practical discussions, the two concepts are totally unrelated and
>altogether unaware of each others presence. An IP host will not detect a node is on
>another VLAN and hence send to the gateway, it will detect a node is on another
>subnet. It doesn' t really care if the node is in the same broadcast domain or
>halfway around the world, if its not on the network, its sent via the gateway. This
>is very strict behavior. Nodes on different IP subnets do not communicate directly
>in any case without the use of an intermediary, layer 3 device.
>>>
>>> VLANs as a concept are of trivial complexity. VLAN membership, particularly
>dynamic membership along with protocols like 802.1q, ISL, PVST etc that leverage and
>support VLANs do offer some element of challenge and opportunity for best practise
>designs.
>>>
>>> I just felt that the line between VLANs (broadcast domains) and IP subnets was
>getting somewhat blurry when it really shouldn't be.
>>>
>>> *********** REPLY SEPARATOR ***********
>>>
>>> On 1/16/2001 at 10:19 AM Curtis Call wrote:
>>>
>>> >Keep in mind that seperate VLANs will be seperate subnets. Which means
>>> >that by default a host will encapsulate any IP packet destined for a
>>> >different VLAN within an ethernet packet with a destination MAC address of
>>> >the default gateway. So a layer 2 switch will never get the chance to try
>>> >and "switch" between VLANs since everytime a host needs to get to a
>>> >different VLAN (subnet) it will just send a packet to the router which is
>>> >on the same VLAN in order for it to be routed.
>>> >
>>> >
>>> >
>>> >
>>> >>-----Original Message-----
>>> >>From: Bob Vance [mailto:[EMAIL PROTECTED]]
>>> >>Sent: Tuesday, January 16, 2001 8:35 AM
>>> >>To: CISCO_GroupStudy List (E-mail)
>>> >>Subject: why is routing needed with VLANs
>>> >>
>>> >>
>>> >>OK.
>>> >>I must be brain dead, today.
>>> >> (and, yes, Chuck, I *have* had my morning dose of Diet Coke :)
>>> >> and, yes, I know, "What's so special about 'today' "?
>>> >> )
>>> >>As far I can understand it so far, about the only benefit that I see
>>> >>from VLANs is reducing the size of broadcast domains.
>>> >>
>>> >>Suppose that I have a switch in the closet with one big flat address
>>> >>space (well, it couldn't be that big with only one switch, now, could
>>> >>it ?>). Then someone says,
>>> >> "You know, we're getting a lot of blah-blah broadcast traffic.
>>> >> Let's VLAN.
>>> >> "
>>> >>OK, fine. We VLAN and put whatever services in each VLAN that are
>>> >>required to handle the broadcasts (e.g., DHCP service). So, now the
>>> >>switch doesn't send broadcasts outside a particular VLAN.
>>> >>
>>> >>But, what's so magic about a VLAN that the switch also decides not to
>>> >>send unicasts outside a VLAN. Before the VLANs, the switch maintained
>>> >>a MAC table and knew which port to go out to get to any unicast address
>>> >>in the entire space. So, why can't it continue to do that after we
>>> >>arbitrarily implement some constraint on broadcast addresses?
>>> >>It seems to me that the same, exact MAC table, with an additional VLAN
>>> >>field would not require that restriction. If it's a broadcast, send =
>>> >>the
>>> >>packet only out ports with a VLAN-id that matches the source port's
>>> >>VLAN-id. If it's a unicast, handle it just like we used to.
>>> >>
>>> >>
>>> >>Similarly, even if we have 5 switches, I just don't see the requirement
>>> >>that we (as switch-code designers) must block unicasts and resort to a
>>> >>routing requirement.
>>> >>
>>> >>Even with 500 switches ... well, let's not get ridiculous :)
>>> >>
>>> >>
>>> >>I feel that there is a simple point that I've overlooked, so I will
>>> >>continue to RTFM while I await your responses.>)
>>> >>
>>> >>
>>> >>-------------------------------------------------
>>> >>Tks=A0=A0=A0 =A0=A0=A0 | <mailto:[EMAIL PROTECTED]>
>>> >>BV=A0=A0=A0 =A0=A0=A0=A0 | <mailto:[EMAIL PROTECTED]>
>>> >>Sr. Technical=A0Consultant,=A0 SBM, A Gates/Arrow Co.
>>> >>Vox 770-623-3430=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A011455 Lakefield Dr.
>>> >>Fax 770-623-3429=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Duluth, GA 30097-1511
>>> >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>>> >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>>> >>=3D
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>_________________________________
>>> >>FAQ, list archives, and subscription info:
>>> >>http://www.groupstudy.com/list/cisco.html
>>> >>Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>>> >>
>>> >>_________________________________
>>> >>FAQ, list archives, and subscription info:
>>> >>http://www.groupstudy.com/list/cisco.html
>>> >>Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>>> >
>>> >_________________________________
>>> >FAQ, list archives, and subscription info:
>http://www.groupstudy.com/list/cisco.html
>>> >Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>>>
>>> ---
>>> Peter A. van Oene
>>> Juniper Networks Inc.
>>>
>>> _________________________________
>>> FAQ, list archives, and subscription info:
>http://www.groupstudy.com/list/cisco.html
>>> Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>>
>>_________________________________
>>FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
>>Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>
>
>---
>Peter A. van Oene
>Juniper Networks Inc.
>
>_________________________________
>FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
>Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
---
Peter A. van Oene
Juniper Networks Inc.
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
