vLANs and the real world, do they relate

vLANs and the real world, do they relate?

By: Scott Bradner

Virtual local area networks (vLANs) seem to be very popular, at least with equipment vendors. I am not quite so sure that they are as popular with the people that actually build and manage real-world networks.

A virtual LAN has all the same basic characteristics that traditional physical LANs have. In IP terms a vLAN is a logical subnet with its own IP network address and is connected to other vLANs and to physical LANs using routers. A LAN, virtual or otherwise, is a broadcast domain, meaning that a packet with a link level destination MAC address of all bits on (the broadcast address) will be delivered to all nodes on the LAN. A LAN can also be treated as a security domain if the interconnecting routers are configured to implement packet level filtering to keep intruders out. In the absence of switches, LANs also define where a packet being sent from a node on the LAN will go. A packet will go to all nodes on the same LAN but unlike packets destined to the broadcast address the packet will be accepted only by the one node with the same MAC address and any nodes which have configured their interfaces to monitor all traffic. The addition of switches in a LAN changes things so that packets to MAC addresses other than the broadcast address only go to the correct host and other nodes can not intercept them.

Going virtual with LANs means that the LAN does not have to be tied to some physical underlying network topology. Nodes on the same Ethernet HUB can appear to be in different LANs and nodes in different buildings can look like they are on the same LAN for broadcast containment or security compartmentalization .

This ability to separate the physical network topology from the logical network topology was felt to be a great advantage particularly in organizations where there were a lot of "moves, adds and changes" (to use the telephone terminology). Someone could move from one office to another or even from an office in one building to an office in another building yet his PC could remain on the same LAN. With vLANs the network address of the PC would not have to change so the PC could be just plugged into the network after the move without having to reconfigure the PC or the network.

From this modest beginning vLANs have grown in the vendor's mind to be a necessity for all future networks. But I am not all that sure that the picture is quite so clear. Certainly current network designers and managers have not jumped onto the bandwagon. Over the last two years I have been doing series of seminars around the US dealing with various types of LAN technologies. One of the seminar series, done with Strategic Networks Consulting Inc., included a half dozen vendors who were asked to respond to sample network problems with their own solutions. Almost all of the solutions involved the use of extensive vLANs. During the seminars the attendees were asked how many had already implemented vLANs in their own network and how many had plans to do so. Overall less than 1% had actually implemented vLANs and only 5% to 10% had any plans to do so. There is a clear separation between the vendors expectations and the real world plans.

If the solution looks so good why have so few people adopted it? I expect that part of the problem has been the lack of generally available standards-compliant vLAN implementations. Almost everything currently on the market is proprietary and it is a bad idea to get locked into a proprietary solution to any problem, it sharply reduces your flexibility in future network designs and with the vendors. This is beginning to change. ATM vLAN standards are now well developed and a number of vendors have demonstrated interoperability with them. But ATM is having its own problems in the area of desktop support, Ethernet is outselling ATM by a very large factor and there is little reason to think that will change. Ethernet vLAN standards are still under development but are due soon. But I think there are other reasons that vLANs have not seen widespread adoption and will explore some of them after some more background.

There are a wide range of technologies that have been lumped under the term vLAN. The simplest case is the ability to configure an Ethernet hub or switch so that selected groups of ports are interconnected but are separate from other groups of ports - splitting the backplane into a number of pieces so that in effect there are a number of smaller hubs housed within one larger hub. We use this type of vLAN at Harvard. There are a number of places where we have more than one LAN in the same phone closet and instead of installing multiple physical hubs we install one hub and subdivide it using this type of vLAN. This does not involve any kind of tagging of the data packets on the Ethernets, it just says that hub ports 1,2, and 23 are on the same LAN and hub ports 3,4,and 21 are on a different LAN. In this case vLANs can not be extended between hubs except on parallel wires, one per vLAN.

A second type of vLAN involves adding tags to the data packets to indicate which vLAN they belong to. In this case vLANs can be extended between hubs on a shared wire. The tags are added by the edge devices, for example the hubs, based on configured parameters. This can be as simple as what physical port the packets came in on or it can be as complex as systems where the level-2 or level-3 address is examined by the edge device and the packet tagged based on, for example, what IP source address it contains. There are a number of proprietary versions of this techniques currently available on the market and the Ethernet standards committees are working on standard tagging methods. With this type of vLANs a router which understands the tagging scheme could route between multiple vLANs on the same Ethernet using a single interface.

A final type of vLAN makes use of virtual circuits. This is the type that has been standardized in the ATM world. Data packets are examined in the same way as with tagged Ethernet frames but the data is assigned to a separate set of ATM virtual circuits for each vLAN. Routers can be used to route between virtual circuits and thus between vLANs. An example of a virtual circuit based vLAN system is the ATM Forum's Multiprotocol over ATM (MPOA). In this case the edge devices make use of route servers in the network to figure out on what virtual circuit the data should be sent. MPOA has not quite been approved as a final specification by the ATM Forum but there are many vendors who have announced their intention to support MPOA when it has been approved..

So some of the problem with the acceptance of vLANs has to do with the state of the vLAN standards but I think there are other issues. LANs are normally constrained in some way by the physical world. A particular LAN will support one building or one floor in a building. But there are times when the logical topology of the network must be somewhat more complicated. Some set of users need to be isolated from another set for security reasons or because the two different sets of users make use of different servers. VLAN advocates say that the use of vLANs makes it easier to do this type of separation and it is true. But in many cases modern network architectures mean that it is not so easy to identify this type of sets of users. For example, many corporations are now beginning to centralize servers to make management easier. The cases where all that is done is that the existing servers are moved to a central location are ideal for vLANs. The users and their server can be isolated on one vLAN. This will keep the traffic isolated and secure. But if at the same time the corporation starts to consolidate the server functions into a few enterprise servers it gets far harder to identify sets of users. If everyone in the corporation must access the same server, even if it is for different functions, how do you separate the users?

You can have the server participate in the vLANs in those cases where different services are run on the same computer and have the different services respond on different vLANs. But where all of the functions are combined into one service, such as the web, vLANs provide no advantages over physical LANs or a flat, non-routed network.

It is my conclusion that the changing patterns of server implementation mean that the use of vLANs will be quite a bit less than what most of us once thought, even after the standards process catches up to the vendor's marketing material.