VLANs and Broadcast Domains

team lib

A technology plagued by confusion and lack of standards holds plenty of promise.

One primary difference between connection-oriented networks, such as ATM, and connectionless or shared medium networks, such as Ethernet and Token Ring, is the ease with which you can perform a broadcast on connectionless networks. On Ethernet and Token Ring networks, every frame is visible to all the end nodes on a segment or ring, even though normal network interface controller behavior is to ignore all the frames not intended for its own consumption. Thus, any frame flagged as a broadcast (which is typically done by making the destination field all 1s) can reach every destination on the segment or ring at once, with no special effort.

Broadcasts perform a number of behind-the-scenes, yet indispensable , network functions. When you turn on a NetWare/IntranetWare client machine, it broadcasts a Get Nearest Directory Server or Get Nearest Server packet to connect to the network and ultimately log in. Whenever an IP host or router needs to find the physical destination of an IP address, it generates an Address Resolution Protocol (ARP) broadcast packet, which asks something like, "Will the node with IP address x please send me your MAC address, so I can address this packet to you?" (These addresses are stored in an ARP cache for a couple of hours or so subsequent traffic may not require broadcasts.)

NetBIOS-based nodes maintain a list of addresses of other nodes they can reach; these lists are populated by periodic broadcasts that say, in effect, "Everybody tell me your name and address now." NetWare servers generally broadcast Service Advertising Protocol (SAP) packets that alert other nodes to the presence of file and print services. Routers advise each other of the availability of routes by broadcasting RIP (Routing Information Protocol), OSPF (Open Shortest Path First), or BGP (Border Gateway Protocol) packets. The AppleTalk Chooser constantly fires off broadcasts to find printers and servers. AppleTalk performs name resolution by broadcasting Name Binding Protocol (NBP) packets. In a recent sample I took on a subnet that has AppleTalk, NetWare, and IP traffic, but no NetBIOS or LAT traffic, the traffic at times consisted of more than 7 percent broadcasts.

Early LAN protocols especially those like NetBIOS and AppleTalk, which were designed to be simple to set up and use, even when some connected machines were turned off part of the time, tended to make heavy use of broadcasts. With plenty of available throughput on the LAN, even relatively heavy broadcast traffic didn't pose a problem. TCP/IP, designed for wide area connectivity, where every bit/sec of throughput costs real money, is much more parsimonious with broadcasts than traditional LAN protocols are. (ARP broadcasts are limited to a particular subnetthey don't typically traverse a WAN link.) When people began to interconnect NetWare networks over wide area links, Novell's IPX was criticized for excessive broadcasts. Novell responded by delivering the NetWare Link Services Protocol (NLSP), which replaces RIP broadcasts with more efficient, less frequent NLSP broadcasts, and by introducing Novell Directory Services (NDS), which can eliminate much of the demand for SAP packets. In Windows NT networks, a Windows Internet Name Service (WINS) server can provide one of the functions performed by NDS: eliminating the need for name resolution broadcasts that request NetBIOS names over TCP/IP networks.

On a single-segment Ethernet network, the broadcast domain (all the nodes a broadcast frame can reach) is the same as the collision domainall the nodes that must wait for each other to be silent before transmitting data. (A single Token Ring is also a broadcast domain.) However, multiple Ethernet segments connected via a switch or bridge form an extended broadcast domain made up of multiple collision domains. Bridges forward broadcasts out to every port, and they also forward frames with unknown destinations to every port. So traffic local to a collision domain is invisible to the rest of the broadcast domain, while broadcasts and frames with unknown destinations are flooded to every other node on the broadcast domain. Theoretically, thousands of nodes could be connected by bridging multiple collision domains. Just because you can do it doesn't make it a good idea, though.

There are two good reasons to avoid large, flat networks. The first is to provide the ability to administer the network effectively. In particular, it's often important to treat some network users differently than others. In terms of overall network performance, you may want to connect a group of users who all use a particular protocol, such as AppleTalk, to the rest of the network via a router rather than a bridge or switch. This approach keeps AppleTalk broadcasts from absorbing bandwidth over the entire network. As another example, a group of users with high-performance requirementsvideo conferencing users, for instancemight best be isolated from others. There may be security considerations that dictate special treatment for a specific set of nodes.

The second reason that large, completely flat networks become unworkable results from broadcast traffic itself. To a varying extent, depending on particular protocols, broadcast traffic can increase geometrically with additional nodes, while unicast traffic increases arithmetically. Segmenting networks with switches can extend indefinitely the bandwidth available for unicast messages, but at some point the broadcast traffic will swamp the whole networka phenomenon that won't necessarily occur gradually. Instead, there may be some sort of cascading event where a high level of broadcasts generates even more broadcasts and there is a broadcast storm , which may require shutting down large sections of the network in order to regain control.

The VLAN Arrives

As switches have become cheap and easy tools for segmenting flat networks, vendors have looked for ways for network managers to contain broadcasts without having to install routers on every segment. Virtual LANs, or VLANs, can best be thought of as logical broadcast domains, as opposed to the "physical" broadcast domains we have been discussing. Without VLANs, the traditional way to break up flat networks is to insert a router between the subnets you want to define. The IP addressing scheme supports subnetting in a way that many sites have managed to make work, though it would be hard to claim this method is flexible or easy to grasp. (NetWare networks are somewhat easier to configure as subnets because file servers with multiple network interfaces are routers by default.)

Beyond the protocols are the issues of router setup and configuration. Routers are difficult to administer, and it's easier than it ought to be to make catastrophic, or at least thoroughly frustrating, mistakes. Router ports are also substantially more expensive than switch ports with the same throughput. The basic idea of a VLAN is to allow an organization to customize broadcast domains according to its needs instead of accepting the limitations that come with Network layer protocols and with using routers to accomplish segmentation.

For instance, consider the network in the figure. Each switch has a 100Mbits/sec uplink to an IntranetWare server and multiple 10Mbits/sec ports connected to individual workstations, some of which are IPX and others of which are AppleTalk. The switches are connected with a 100Mbits/sec link. By default, this configuration constitutes a flat network: All the AppleTalk broadcasts are sent to the IPX nodes and all the IPX broadcasts are sent to the AppleTalk nodes. However, if all the AppleTalk nodes (along with the servers) are defined as VLAN 1 and all the IPX nodes (along with the servers) are defined as VLAN 2, then the broadcasts of each protocol will be segregated on their own VLAN.

click to expand
A Practical VLAN: The two VLANs in this diagram have been defined to prevent AppleTalk broadcasts on the Macintosh hosts from congesting the IPX-based VLAN, and vice versa. One server is a member of both VLANs. If the link to the shared server is a high-speed one, it will be less likely to become a bottleneck.

Defining The VLAN

VLANs can be segmented in several different ways, which is one of the reasons they can be confusing. The simplest way is to assign specific ports on a switch to VLANs. If an assigned switch port is connected to a shared segmentone with multiple nodesall those nodes will be part of the VLAN, along with the nodes on other ports assigned to that VLAN. This VLAN segmentation is basically a matter of electronically isolating the ports of each VLAN. Within a given vendor's product line, port-based VLANs can often span multiple switches. However, interoperability across vendor boundaries awaits the adoption of the IEEE 802.1Q standard, which defines a tag field that identifies a frame as a member of a particular VLAN. If VLANs are defined only by port, they typically can't overlap. This is unfortunate because permitting workstations or servers to be members of multiple VLANs is one of the most promising features of the technology.

The second way VLANs can be segmented is by MAC address. In this method, switches maintain tables of MAC addresses with their VLAN membership. With this form of membership, the nodes on a shared segment need not belong to the same VLAN. However, the fact that members of two VLANs reside in a single collision domain will diminish some of the traffic containment advantages of VLANs. Because MAC addresses are tightly associated with NICs, this Layer 2 VLAN definition has the advantage of portability. Wherever a workstation or laptop is plugged in across the switched network, the switches will recognize it as a member of the assigned VLAN.

VLANs can also be defined by their network or Layer 3 addresses. Many network managers, frustrated by the administrative overhead that comes with highly changeable networks configured with IP, could happily replace their existing subnet structure with VLANs. Vendors who support this form of VLAN definition generally offer tools that can automatically assign subnet members to particular VLANs. Once the node's VLAN membership is defined, the VLAN handles everything, even if the node is moved to a port connected to a different subnet or if the IP addresses need to be reassigned.

VLANs AND ATM

There is an interesting relationship between ATM LAN Emulation (LANE) and VLANs. Connection-oriented ATM doesn't have broadcastsit has to invent them from the ground up. Because LANE, which makes it possible for traditional LANs to communicate over ATM, has no preconceptions or baggage with respect to broadcasts, it can readily include hooks to VLANs. Thus, the members of an ATM-based emulated LAN can readily be assigned to VLANs defined for Ethernet, Token Ring, and FDDI, or to their own VLANs. In many respects, understanding and setting up an ATM-based VLAN is more straightforward than is the case with traditional networks.

This tutorial, number 107, by Steve Steinke, was originally published in the July 1997 issue of LAN Magazine/Network Magazine.

 
team lib


Network Tutorial
Lan Tutorial With Glossary of Terms: A Complete Introduction to Local Area Networks (Lan Networking Library)
ISBN: 0879303794
EAN: 2147483647
Year: 2003
Pages: 193

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net