July 1, 1997

Tutorial Index
by Steve Steinke

Lesson 107: VLANs and

Broadcast Domains
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 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 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

1 of 5
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 per sec of
throughput costs real money, is much more parsimonious with
broadcasts than traditional LAN protocols are. (ARP
broadcasts are limited to a particular subnet-they 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 domain-all 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

2 of 5
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
requirements-video conferencing users, for instance-might
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 network-a 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

3 of 5
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 a network where 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.

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 segment-one with multiple
nodes-all 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

4 of 5
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 broadcasts-it 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.

Copyright © 1997 Miller Freeman Inc., a United News & Media company.

5 of 5