WORKSHOPS: INFRASTRUCTURE

Virtual LANs: Dispelling The Myths

by Art Wittmann

Computer networking and the job of maintaining those networks may be one of the more complicated, yet tedious, jobs ever invented. On one hand, you're expected to know and understand the intricacies of TCP/IP, IPX, Windows NT, Unix and NetWare. Yet, you spend a fair amount of time rummaging around in wiring closets trying to get cabling cross-connects right.

Of course, the reason that you're messing with all this has to do with optimizing the performance of your network and maintaining all of the security and access restrictions that have grown up over the life of your network. As time goes by, keeping up with the adds, changes and moves can be a full-time job--maybe for a number of people. There has to be a better way, right?

Of course there is! There virtually always is, and in this case it's the much-hyped virtual LAN support present in many of the hubs on the market today. In this workshop, we'll talk about what virtual LANs (VLANs) are, how they can be used, and how they fit into a typical network.

Where Did VLANs Come From? A few years ago, vendors started to put more than one packet channel on the backplanes of their routers. In the earliest versions, a choice could be made at the board level as to which channel to use. Typically there were three or four of these channels, and a single hub could therefore support three or four LAN segments within a single box. This was a good step because it meant that less equipment was needed in the wiring closet and changes were a fairly simple matter of moving a connector from one board to another.

The solution was far from optimal though. Some boards would be completely populated while others only supported a few connections. Swapping boards with various port densities and reconfiguring hubs were the result. A better solution was to bring the flexibility of choosing a LAN down to the port level rather than the board level. A further optimization was to make the LAN setting software selectable. A number of vendors did incorporate software-selectable settings in their products for both Token-Ring and Ethernet.

Along came switches, which originally were nothing more than multiport bridges. They represented a big step forward in bandwidth, but lacked the management flexibility of their software-configurable hub siblings. So, with a switching hub, we had lots more bandwidth, but we were back to configuring the network manually to accommodate moves, changes and adds.

The obvious thing to do was to combine the two technologies--and the result is virtual LANs. They are virtual in the sense that no physical wire or backplane necessarily defines the LAN. Because of the switching technology, a virtual LAN has many times the bandwidth of a regular LAN. Because of the software configurability, administration is reasonable, particularly when compared with old fixed configuration hubs or early switching hubs.

What Happens in a Virtual LAN? The concept of a virtual LAN is straight forward enough, but what really happens to network traffic? After all, in a switched environment, traffic should only be seen by the source and destination nodes (or segments) anyway.

The exception here is for broadcasts and multicasts. They must be seen by all stations on the virtual LAN. In fact, a virtual LAN might just as well be called a broadcast zone. On some networks, broadcasts may be a big enough problem that just breaking the network into broadcast zones would be enough.

Virtual LANs usually go one step further. Moving traffic from a station on one VLAN to a station on a different VLAN is usually not possible. In this way, the VLAN is like a firewall requiring some sort of routing technology to move traffic between the VLANs.

It may seem silly to force traffic between stations that could remain on the same switch to go through a router somewhere at the back of the network. That fact hasn't escaped the bright folks that write ATM specifications in particular. If you've heard of MultiProtocol Over ATM, or MPOA, it addresses exactly this problem, as do some non-ATM techniques championed most notably by Cisco and Alantec. Here, routing tables and traffic distribution rules are forwarded to the end switches by a route server that calculates the tables and rules that must be followed.

Not So Fast, Mr. Wizard! In fact, management is so reasonable, it's downright convenient and easy, at least on a per-hub basis. The problem comes in connecting a number of switches into a network of virtual LANs. Proprietary techniques are all well and good inside a hub, but coming up with a standard way to set up a virtual LAN that extended throughout a network would be better.

No standard currently exists for disseminating virtual LAN information between hubs, and in fact, only a handful of vendors have proprietary techniques to do the job. Cisco has proposed using an existing standard, specifically the 802.10 LAN security standard, as a way to move such information through the network. Reception to the seemingly proprietary idea within the vendor community has been fairly lukewarm. However, Cisco may have the clout to make a de facto standard work.

Are You a Good Switch or a Bad Switch? In practice, the presence of a standard may or may not be something to be concerned about. Bandwidth is introduced into a network either by adding switch ports or by adding router ports. If you use routers, you're used to creating relatively small LAN segments where the number of stations on the segment is more or less determined by the amount of bandwidth available to the segment and the amount of bandwidth that each station consumes. This is not the right mode of thought for setting up virtual LANs in a switched environment.

Virtual LANs are an administrative creation and therefore new ones should be created only when they are necessary to meet some administrative goal, such as separating different departments' networks. Remember, too, that once you've created your virtual LANs, you'll still have to use a router (either an external router or one provided within your switching hub) to get traffic between virtual LANs. If you've designed your virtual LANs correctly, there will be comparatively little traffic flowing between them. For example, most of the data that might move between departments is probably going to be e-mail. This is fairly insignificant when compared with the client/server traffic that is likely to flow within the virtual LAN.

Proprietary standards within a workgroup are probably just fine--how many times are you likely to mix vendor's products at that level? In most corporations, the answer is: Seldom, but we'd still like to have a standard. That standard will probably not be a true standard unless ATM and its accompanying LAN Emulation specification are used. Other attempts like Cisco's may garner some support, but be careful of the hype--recycling standards is not the preferred method for supporting new technologies.

Art Wittmann is a senior editor of Network Computing. He can be reached via the Internet at wittmann@engr.wisc.edu.

Troubleshooting Virtual Lans

October 15, 1995