Virtual local area network
Virtual Local Area Networks (VLAN or virtual LAN) allow multiple logical local area networks (LAN) to exist within a single physical LAN. In other words, the LANs are defined in software rather than hardware.
Consider the following example where two VLANs are created with a VLAN capable switch. By default, all ports on the same switch usually belong to the same LAN environment. This means there is a single broadcast domain. Dividing the switch into multiple VLANs entails allocating ports to a VLAN or some kind of identifier for that group of ports. In our example, let’s allocate ports 1–6 to VLAN 1 and ports 7–12 to VLAN 2. In this current configuration, devices attached to ports 1–6 can communicate with each other, and devices attached to ports 7–12 can communicate with each other, but there is no way for any device on ports 1–6 to communicate with any device on ports 7–12. For example, traffic received on port 2 will be retransmitted out ports with membership in VLAN 1 (i.e., ports 1 and 3–6). We have now created two separate broadcast domains. In effect, the switch is acting as if it were two separate switches.
VLAN membership can be assigned by port, MAC address, Layer 3 protocol, or Layer 3 subnet. We are defining a community of interest by trying to associate devices that can communicate in a way that reduces the traffic per LAN. Each of these techniques creates a VLAN and also provides extra granularity in deciding VLAN membership.
VLAN Membership by Port
VLAN membership by port is the simplest and most common deployment of VLAN technology and can be assigned manually or automatically. Manual per port VLAN membership requires a network administrator to assign individual ports to predefined VLANs within the network. This can be done via a network management station using a graphical user interface (GUI) interface or by consoling into each VLAN capable device and using that device’s command line interface. Automatic allocation of ports into VLANs requires that the devices decide port allocation. This can be done based upon network load or users’ IDs.
With automatic allocation, ports can only have membership in a single VLAN. Automatic allocation is often used to facilitate additions, moves, and changes within a network. When a user moves, he or she plugs into the nearest network port which the network administrator assigns to the user’s original VLAN. This saves repatching and provisioning of new equipment in the wiring closet. Repeater ports and switch ports on VLAN capable devices can be allocated in this manner.
VLAN Membership by MAC Address
Managing VLAN membership by MAC address is often unwieldy and time consuming, and it is not often implemented. Devices are assigned to VLANs according to their MAC address, which means devices track MAC addresses to decide membership. This is normally only seen in VLAN capable switches.
Regardless of where on the network a device plugs in, the network assigns that device to the preconfigured VLAN, so mobile users can use the same Layer 3 address and access the same resources regardless of where on the infrastructure they are. This also affords the network an added degree of security as devices that are not recognized will not be admitted to a VLAN. The trouble with VLAN membership by MAC addresses is that the network administrator needs to build and maintain a list of every MAC address in the network and VLAN membership. Every time a new device is added or a network interface card (NIC) is replaced, the VLAN table needs to be updated. Some schemes allow the administrator to get a “snapshot” of MAC addresses on the network to save having to visit every device and record the address. This does not help in the ongoing table maintenance, which is now critical to the correct operation of the network.
VLAN Membership by Protocol
Managing VLAN membership by protocol is rapidly becoming obsolete as [IP] continues to dominate at Layer 3 and systematically displace all other alternatives. Where multiple protocols continue to exist, it is possible to have the switch assign ports to VLANs based on the type of Layer 3 protocol it sees arriving on that port. Thus IP devices would be made members of the IP-based VLAN while devices using another protocols, such as Novell's legacy Internetwork Packet Exchange (IPX) protocol, would be assigned to a different VLAN. This makes sense as IP devices do not need to see IPX traffic and vice versa.
Why stop at Layer 3? It is possible to define VLANs per application. Devices using the World Wide Web (WWW) would have membership to one VLAN and devices using Lotus Notes would have membership to another. This implies that devices running multiple protocols or multiple applications would belong to many VLANs. This significantly affects the size of the devices’ VLAN membership tables as each device is likely to have multiple entries. Asking a device to look further into a datagram for information on VLAN membership can significantly impact its performance.
Management of protocol-based VLANs is simple in that once the rules are set, VLAN membership is automated. However, VLAN membership by protocol tends to be difficult to troubleshoot (especially when membership is application-dependent) and is often more trouble than it is worth.
VLAN Membership by Subnet
Implementing VLAN membership by subnet is based upon a device’s understanding of IP subnets. By listening to routing updates and looking at the source IP address of a device, the boundaries of the VLAN can be determined. Devices are then allocated to a VLAN based upon their IP Network Identifier (NETID) address. This implementation does not lend itself to other protocols that dynamically assign addresses to devices as they connect to the network (e.g., Internetwork Packet Exchange (IPX) and IP’s Dynamic Host Configuration Protocol (DHCP)).
Typically switches that implement this technology will do so for IP. Other protocols will be statically mapped. Unroutable protocols will be allocated based upon the Layer 2 protocol ID field. Subnet-based VLANs can have issues with quiet stations (i.e., VLAN membership is not determined for a port until the device communicates something).
The advantages of VLAN membership by subnet implementation are that it is automatic and requires little configuration.
When separate devices are required to support connectivity for a common set of VLANs, those VLANs need to be connected together. This can be a relatively inefficient process. For example, two switches supporting three VLANs each require connections between each switch per VLAN. This decreases the ports available for users on both switches. If there is a router (or server) connected to all VLANs, three router/server ports, as well as extra ports on the switch, would be required. This is an expensive option.
In addition to wasted ports, we have multiple links between the same two physical devices. If one VLAN is lightly utilized, the bandwidth on this link is not available for a heavily utilized VLAN to use, even though they connect the same two devices. Thus, we can’t share the links between VLANs to take advantage of the increased bandwidth between the devices. If one of these links fails, the other VLANs would survive (because they were not using that link), but the VLAN depending on that link would not, even though there is still a physical link between the devices. We could fix this by adding redundant connections per VLAN, but this exacerbates the port wastage and lack of load sharing issue even further.
VLAN trunking allows connected devices to share a common link to transport data for separate VLANs. Essentially we are statistically multiplexing VLANs across a common link. This approach has two benefits. It reduces the number of ports required to connect devices together to support multiple common VLANs, and bandwidth not used by one VLAN is available for another to use. It makes sense that this common link needs to be of high capacity or it would create a bottleneck. Thus, VLAN trunking technology is only available at speeds greater than 100 Mbps.
Using the same link for multiple VLANs means we need some way of identifying where the VLAN data comes from so that the other end of the trunk link can forward the frame appropriately within the correct VLAN. This is done by getting the transmitting switch at one end of the trunk link tagging the frame before it is sent across the link. The switch at the other end removes the tag before forwarding it further.
VLAN Trunking Standards
IEEE 802.1q and Cisco ISL (InterSwitch Link) are two ways to tag a frame across a trunked link.
The standard for trunking is 802.1q encapsulation. 802.1q is supported by most switch, router, and network interface card (NIC) vendors to allow trunking between these devices.
Cisco ISL was developed by Cisco, but Cisco has partnered with other vendors to make trunking over ISL possible between Cisco switches and servers. For example, Compaq and Intel produce NICs with driver support for ISL.
Products often support multiple trunking techniques to support a migration from prestandard implementations to standards-based implementations.
|<mp3>http://podcast.hill-vt.com/podsnacks/2007q1/vlan.mp3%7Cdownload</mp3> | Virtual LAN|