If I understand your question correctly....here's a response....
A router operates at Layer 3 while all the switching you are discussing =
is
happening at Layer 2. In order for a switch to forward packets to any =
VLAN
it would have to also re-write the packet so that he destination =
workstation
or server can answer properly and know where to send it's response. =
This is
essentially what happens in MLS or Layer 3 switching. The switch can
forward packets based on the Vlan Id tag all it wants but the packet =
has to
makes sense to the endpoint in order for a complete conversation to =
take
place.
Am I close??
-----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]
