Sorry, I was trying to make a puzzle with the words, instead  I did a lot of noise in 
the line, looks like I have to improve my language!

Peter Van Oene wrote:

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

_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to