Lesson 9: Understanding Virtual LANs

What Is a VLAN? | VLAN Technologies

Membership by Port

Let’s look at the first method for determining or assigning VLAN membership:

Port-based — In this case, the port is assigned to a specific VLAN independent of the user or system attached to the port. This VLAN assignment is typically done by the network administrator and is not dynamic. In other words, the port cannot be automatically changed to another VLAN without the personal supervision and processing of the network administrator.
This approach is quite simple and fast, in that no complex lookup tables are required to achieve this VLAN segregation. If this port-to-VLAN association is done via ASICs, the performance is very good.
This approach is also very easy to manage, and a Graphical user Interface, or GUI, illustrating the VLAN-to-port association is normally intuitive for most users.
As in other VLAN approaches, the packets within this port-based method do not leak into other VLAN domains on the network. The port is assigned to one and only one VLAN at any time, and no other packets from other VLANs will “bleed” into or out of this port.

Membership by MAC Addresses

The other methods for determining VLAN membership provide more flexibility and are more “user-centric” than the port-based model. However, these methods are conducted with software in the switch and require more processing power and resources within the switches and the network. These solutions require a packet-by-packet lookup method that decreases the overall performance of the switch. (Software solutions do not run as fast as hardware/ASIC-based solutions.)
In the MAC-based model, the VLAN assignment is linked to the physical media address or MAC address of the system accessing the network. This approach provides enhanced security benefits of the more “open” port-based approach, because all MAC addresses are unique.
From an administrative aspect, the MAC-based approach requires slightly more work, because a VLAN membership table must be created for all of the users within each VLAN on the network. As a user attaches to a switch, the switch must verify and confirm the MAC address with a central/main table and place it into the proper VLAN.
The network address and user ID approaches are also more flexible than the port-based approach, but they also require even more overhead than the MAC-based method, because tables must exist throughout the network for all the relevant network protocols, subnets, and user addresses. With the user ID method, another large configuration/policy table must exist containing all authorized user login IDs. Within both of these methods, the switches typically do not have enough resources (CPU, memory) to accommodate such large tables. Therefore, these tables must exist within servers located elsewhere in the network. Additionally, the latencies resulting from the lookup process would be more significant in these approaches.
From an administrative aspect, the network and user ID-based approaches require more resources (memory and bandwidth) to use distributed tables on several switches or servers throughout the network. These two approaches also require slightly more bandwidth to share this information between switches and servers.

Multiple VLANs per Port

When addressing these various methods for implementing VLANs, customers always question the use of multiple VLANs per switch port. Can this be done? Does this make sense?
The means for implementing this type of design is based on using shared hubs off of switch ports. Members using the hub belong to different VLANs, and thus, the switch port must also support multiple VLANs.
While this method does offer the flexibility of having VLANs completely port independent, this method also violates one of the general principle of implementing VLANs: broadcast containment. An incoming broadcast on any VLAN would be sent to all hub ports — even though they may belong to a different VLAN. The switch, hub, and all endstations will have to process this broadcast even if it belongs to a different VLAN. This “bleeding” of VLAN information does not provide true segmentation nor does it effectively use resources.

<<Back [1] [2] [3] [4] [5] [6] Next>>