In my experience, there exist some bridge table variations from vendor to vendor that
might impact on your unicast forwarding idea. I'm not positive what Cisco does and
maybe someone can comment, but I have seen many implementations that build separate
MAC - Interface tables per VLAN, thus fully isolation traffic from one VLAN to the
other(s).
In theory, VLAN technology should involve complete separation of traffic from VLAN to
VLAN and not simply isolation of all 1's broadcasts. I expect this is exactly the
case in most vendors implementations but never really tried to verify it. Keep in
mind that again, VLAN technology was not solely designed for IP networks.
To you point below, the 802.1d compliant switch is a layer 2 device and does not
decode layer 3 headers and thus it doesn't matter what addresses (be they IP or
otherwise) you assign to whatever devices you chose to attach to it. As far as
documentation goes, I haven't seen much outside of 802.1q document ion which exists I
believe as a subset of a revised 802.1d spec out of the IEEE. The basic functionality
to me isn't reflective of something one would need a document for, given RFC's and
such are designed to enable multi vendor inter operability among other things.
-pete
*********** REPLY SEPARATOR ***********
On 1/17/2001 at 1:33 PM Bob Vance wrote:
>And, I suppose (more idle speculation, Bob??) ...
>
>If you had two sets of devices and no need for communication between
>those sets, you could theoretically create 2 VLANs with addresses all
>within the same subnet (ignoring any possible restrictions in a
>particular piece of switch code).
>
>Even then, you *would* be able even to talk TCP/IP between those VLANs,
>if unicasts were forwarded by the switch outside the VLAN (and you were
>willing to create manual, permanent ARP entries where needed) --
>but, they're not. BTW, is this a CISCO-specific implementation
>or are there VLAN RFCs that prescribe necessary behavior.
>
>
>-------------------------------------------------
>Tks | <mailto:[EMAIL PROTECTED]>
>BV | <mailto:[EMAIL PROTECTED]>
>Sr. Technical Consultant, SBM, A Gates/Arrow Co.
>Vox 770-623-3430 11455 Lakefield Dr.
>Fax 770-623-3429 Duluth, GA 30097-1511
>=================================================
>
>
>
>
>
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
>Peter Van Oene
>Sent: Wednesday, January 17, 2001 12:26 PM
>To: [EMAIL PROTECTED]
>Subject: RE: why is routing needed with VLANs
>
>
>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.
>
>
>_________________________________
>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]
