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]
