In my previous article on VLANs, I introduced the basics, benefits, and setup of virtual local area networks to segregate broadcast domain traffic. In this installment, I’ll concentrate on VLAN tagging as a means of intra-communication on a physical LAN with multiple VLANs. Although the development of VLAN tagging was heralded by Cisco, we look at the basics with some examples of Hewlett Packard’s VLANs and terminology.
In most networks where VLANs are in use, there are usually instances where traffic on segmented VLAN broadcast domains need to communicate with shared resources. Examples include switch-to-switch links, servers, and Internet resources. VLANs could be intra-connected with routers external to the switches, but this is often impractical. VLAN tagging was developed as an Intra Switch Link protocol (802.1Q is the open standard) at Cisco to solve the issues. VLAN tagging can assist in connecting or bridging traffic flow boundaries by inserting a VLAN ID into the packet traffic.
By tagging packets with the VLAN ID, managed switches can then forward packets across multiple switches and help those packets find appropriate VLAN ports that are tagged for use by a particular VLAN. We can visualize this VLAN tagging traffic in the diagram show below.
VLAN Tagging Across Switch Links
In this example, two VLANs labeled “red” and “blue” are set up with PCs in each VLAN on two different HP ProCruve switches. The link between the two switches must carry traffic for both the “red” and “blue” VLANs. This is done by tagging the Ethernet frames with an ID of either the “red” or “blue” VLANs. Ethernet frames with a “red” tag will only be seen by switch ports that are tagged “red” and the same hold true for the “blue” VLAN.
Perhaps the network requires that both the “red” and “blue” VLANs must access a particular server. In this example, it is possible to purchase and install network interface cards that support VLAN tagging under the 802.1Q protocol. Then the server could be connected to an 802.1Q port on the switch and this would allow the server to be made part of multiple VLANs at the same time. Client PCs and devices from both the “red” and “blue” broadcast domains could then access the server without an external router.
While this may seem like a ideal solution, it must be remembered that the server would now see all traffic from these VLANs, which could negatively impact performance. So, while VLANs have many benefits, careful consideration of services, resources, and design in network VLANs must be added to plans. The external router alternative mentioned in the reading above may facilitate better routing of traffic and keep server performance to a more acceptable level.
That closes out the second article on VLANs for 2009. In future articles in the new year, we will focus on other networking topics including VLAN Trunking Protocol (VTP) and the use of routers to protect portions of networks with sensitive data.
Subscribe via RSS