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]
