Networking SupplementIs It Time To Switch?

In the early
eighties, we began with single LANs, e.g. Ethernet and Token Ring, each creating its own
unique computing ”island”. As we moved through the eighties, there was a need to expand
and interconnect these ”islands”, which brought us to the paradigm of extended or bridged
LANs. With the proliferation of TCP/IP networks and the requirement to logically separate
or ”firewall” physically connected networks, the nineties brought us to the routed network

Routed networks enable the network manager
to isolate broadcast domains and limit broad-cast LAN traffic to the segment it was
intended for and minimize traffic over costly packet-switched or circuit-switched phone
lines. As we move into the late nineties, one of the current paradigm shifts is to
switched Virtual LANs (VLANs) and, looking beyond, interconnecting those switched VLANs
into switched virtual networks.

Switched VLANs can be characterized as
implementations of traditional LAN protocols within a limited broadcast domain. This gives
network managers more control over bandwidth utilization via microsegmentation and network
management without the performance impact created by routed networks. As each of these
paradigm shifts occurred, there were also shifts in the ways that networks were designed
and managed.

Moving to switched virtual networks will
undoubtedly be the most difficult of these paradigm shifts for network managers to
integrate into their legacy networks. According to a recent report from META Group Inc.,
they expect users to spend $ 1.5 B in 1997, up from approximately $ 250 M spent in 1994 to
plan, design, and manage the move to this latest network paradigm.

Is It Time To Switch?
Switched networks are differentiated from the traditional shared network technologies in
several ways. The most obvious of these is that the network traffic is limited to small
number of users assigned to a port on a switch device. These users experience little or no
contention for access to the network and there are few, if any, collisions detected.

This allows for the actual network
bandwidth available to the user to be closer to the maximum allowed by that particular
technology (e.g. 10 Mbps for Ethernet, 100 Mbps for FDDI etc.). Quite often, these switch
ports may also support full-duplex transmission which will double the basic bandwidth
available to the user (e.g. 20 Mbps for Ethernet).

To support new applications which require
multimedia messages to be carried over the LAN, generally 6-8 Mbps of network bandwidth is
needed. Therefore, the need for many users to migrate to newer or higher speed network
technology, such as ATM or Gigabit Ethernet, is delayed or eliminated completely by
instead migrating the network infrastructure to the switched implementation of the
traditional shared technology.

Having a small number of users assigned to
a particular switch port also allows the network manager to monitor the network
requirements of individual users and make changes to the configurations based on the
policies set by the operations manager. Since no new technologies are being introduced to
the network infrastructure, retraining of management and support personnel is not

This allows the new network to be
implemented quickly with minimal changes seen by the network managers or users, except for
increased performance. Switching also allows the legacy LAN to scale the number of users
it can support to much higher levels than when used in a shared environment. Since
multiple point-to-point network ”conversations” can occur simultaneously in switched LANs
the aggregate throughput of the LAN will move up to the Gigabit per second range, while
the end users may still be using the lower cost, lower speed legacy network interface
cards. These are just some of the advantages and differences of switching which are giving
network managers reasons to explore the concept of switched network technologies.

The Three Classes Of VLANs
Adding the concept of a VLAN into the switching paradigm begins to add some design and
management complexity to networks which were fairly simple in the past. There are three
types of VLAN which are being supported by vendors today. They are: Class 1 or Port
Switching VLANs, Class 2 or MAC layer VLANs, and Class 3 or Virtual Subnet VLANs Class 1
VLANs allow the network manager to assign a user to a port and then assign the port to
group a set of ports on a switch or multiple switch devices into a single broadcast domain
(VLAN). This type of VLAN might be used to dedicate certain ports to provide secure access
to dial-in/out facilities. Class 2 VLANs dynamically group a set of end stations logically
into a single broadcast domain across multiple switch devices based on MAC layer

As a user moves his PC from floor to floor
or building to building, he remains in the same VLAN with no further intervention from the
network manager required. As servers are centralized to improve management and security,
Class 2 VLANs can easily link workgroup clients to the appropriate server resources.

Class 3 VLANs dynamically group a set of
stations logically into a single broadcast domain based on a common network layer (i.e.
subnet) address. These are useful for protocols, such as IP, that bind the network layer
address to a device via manual configuration or via an address server. The types of VLANs
which are supported in products vary by vendor and interoperability between vendors is not

A standard is needed to allow VLANs to
exist across multiple switch devices. If a VLAN exists within a switch, the switch
management can manage the information regarding membership in a VLAN. Once a VLAN
traverses multiple switches, a method to identify the VLAN, which the packet belongs to,
must be defined. Today, ATM LAN Emulation (LANE) can be used as a standard method for
mapping a VLAN to a specific Virtual Circuit (VC).

Use of other media to interconnect switches
in VLAN implementations are proprietary and many permit only limited multi-hub VLANs.
Cisco has in fact defined three methods for VLAN trunking between switches, ISL for fast
Ethernet, IEEE 802.10 for FDDI, and LANE for ATM. In this case, managing a network which
contains more than one of these technologies can become very cumbersome.

The solution to this is obviously a
standard. A working group has been set up by IEEE (802.1q) to determine a standard way for
defining Class 1 VLANs in a multivendor environment. The standard is today very near
completion, although still in draft status. 802.1q defines a frame tagging format and
technique as the way to identify members of the same VLAN when crossing multiple switches.

At recent interoperability tests, VLANs
from multiple vendors, running the current implementation of the 802.1q draft standard,
have demonstrated port-based VLANs running across multiple switches. There is some
question as to whether or not MAC and protocol-based VLANs will achieve standardization,
due to major technical barriers as well as the potential leapfrog of those VLANs by Layer
3 switching.

While the standard for defining VLANs is
not yet available, it hasn”t stopped vendors from developing proprietary VLAN schemes.
Examples of this are SecureFast from Cabletron and InterSwitch Link (ISL) from Cisco. At
the lowest level are the port-based VLANs. These are generally implemented in desktop or
stackable switches.

These switches provide dedicated bandwidth
to a workstation or PC running bandwidth-intensive applications. The switch may also have
one or two links to high-speed servers or backbones. These switches usually have limited
filtering and management capability and are price-per-port sensitive. They are most likely
find their way into engineering firms, research and development organizations, and small
firms that require dedicated bandwidth to the desktop. Some vendors which supply these
desktop switches are Digital, Cisco, and 3Com.

The next level of switching requires
workgroup switches. These address the need to increase performance between several LAN
segments and to create further segmentation of existing shared LANs. The alternative is to
use costly router ports. These switches generally provide up to four ports of connectivity
to high-speed servers or a collapsed backbone while consolidating traffic from hubs or
desktop switches.

They may read far enough in to the packet
header to determine the type of network protocol being used and filter based on MAC
addresses while using network layer addresses to provide firewall and broadcast
containment. Products are available from most network vendors, including Digital, 3Com,
Cisco, Newbridge (UB Networks), and IBM.

The third type of network switch is the
backbone switch. These switches provide connectivity between corporate resources. Backbone
switches are multilayer switches that function at both the data link and network layers.
Due to their deployment as collapsed backbones or backbone interconnect devices, they
generally have more fault tolerance and hot-swap capabilities.

More sophisticated management, often
integrated directly into the switch, is also a common feature of a backbone switch. Again,
this feature is essential for moving into the switched virtual environment in the future.
Whereas the desktop and possibly the workgroup switches may only support one or two
network technologies, the backbone switches generally support multiple, integrated

With all these enhanced features, the price
per port is much higher than on either of the other two switch types and management
becomes more complex. Products in this space are supplied by Fore Systems, Xylan,
Cabletron, Bay Networks, Digital, and Cisco. Generally, most enterprise networks will
contain a mixture of all three types of switches, implementing the various classes of
VLANs on an as-needed basis. (For how a typical switched virtual network might look like
in the future.

Impact On Network Management
As the switches become an integral part of any network, we see the need for some basic
RMON capability being added to switches to provide on-board performance monitoring. This
element becomes key when looking at designing and managing switched VLANs. Correct
placement of switches can be determined by analyzing traffic patterns between end-users
and servers.

With the advent of web browsers and servers
in corporate networks, the old 80-20 rule which assumes that 80 percent of traffic will
remain on the LAN while 20 percent must be routed over the backbone, can no longer hold.
This makes the understanding of traffic patterns more critical than ever before. Optimal
performance will be attained when switching can remain either in the switch device or
within a multi-switch VLAN configuration.

By not doing so, you run the risk of
creating network bottlenecks at either the switch-backbone interconnect or at very highly
accessed shared resources, such as servers or printers. If traffic studies aren”t
performed before installing multiple switches, clients may be talking to servers which
reside on a different switch than the client. This requires the majority of the traffic to
cross out of the switch and on to the shared backbone, moving the bottleneck now from the
client access media to the backbone and server segments. By doing a traffic analysis
before implementing the switched network and assignment of VLANs, these bottlenecks will
be eliminated by proper deployment of the switches and utilization of the appropriate
backbone interconnect technology.

Ongoing use of RMON and other traffic
monitoring tools should be used to routinely assess traffic patterns so that potential
bottlenecks may be avoided. As VLANs are added to existing switch-based networks, the
analysis, planning, design, and management of the switched networks will increase in
complexity as users begin their implementation of virtual workgroups on top of switched

To provide enterprise-wise connectivity
between multiple VLANs routing is required. Vendors are taking one of two approaches to
providing this routing between VLANs. One approach is to use a centralized or traditional
router. This requires all messages which need to travel between VLANs to be passed through
a central point. This central router can become a single point of failure and a point of
congestion in the network.

If this central router fails, it would
cause a major outage in the network. To build redundancy into the network would require
having a standby router in place in case of failure to the primary router. This can
increase the complexity in management of the network and also increase the overall price
of the network infrastructure.

The alternate approach is to implement
distributed routing. Distributed routing separates the data forwarding function from the
route determination function. A distributed connection management algorithm is used to
determine the various routes between switches in the network. This information is then
stored in each of the switches and updated if a reconfiguration of the network occurs due
to loss of a path or switch.

The data can then be routed locally without
further intervention of the route determination algorithm. Distributed routing provides a
high degree of robustness in the network and high performance since the need to transport
all data messages to a central router is eliminated. Overall performance in the network
can increase up to 60 percent by utilizing a distributed routing approach rather than a
centralized routing approach. While many vendors initially supported the centralized
routing approach, more and more of them are moving toward the distributed routing

Despite their benefits, VLANs exhibit the
same scaling limitations as their predecessors, the extended or bridged LANs. As
endstations are being grouped into a single, limited broadcast domain, the requirements
for large number of users or geographically dispersed users cannot be met. As the numbers
of VLANs increase, so do the management complexities and performance problems.

Moving to VLANs will also play havoc with
network security as parameters are no longer tied to physical LAN segments. Performance
issues come in to play when stations within the same VLAN have different subnet numbers
and all traffic between them must first travel to the nearest router to communicate. This
means that the stations will have to communicate via the higher overhead routing protocols
rather than through high-speed switching.

To avoid this, careful planning must be
done to coordinate VLAN boundaries with subnet addressing. Issues also exist with the
NetWare IPX protocol on servers. IPX requires each Network Interface Card (NIC) to have
its own subnet ID, so IPX automatically assigns a unique subnet number to the stations on
each LAN. Since in VLANs a subnet may span many physical segments, these NICs will think
they are all on the physical LAN.

In this case, subnet addressing can”t be
resolved and the network will come to a screeching stop. IPX and IP can also cause
problems when a server”s segment is allowed to exist in more than one VLAN at the same
time. Having a server in more than one VLAN simultaneously is attractive in that the
server can be accessed by many clients in various VLANs at the same time at switching
speeds. Implementing the correct products and planning the IPX and IP address spaces will
be mandatory to implementing VLANs and VNETs.

A New Approach to Network Management
(Policy-based Management) VNETs will face major changes in the design and management
practices of today. Endstations may belong to multiple VLANs, with security requirements
for each. Clients may need to access multiple servers, which may or may not reside in the
same VLAN. Protocols such as IP and IPX which bind network address to physical or MAC
addresses will need to modify the way they will handle having multiple network interface
cards residing in multiple subnets.

Users may move between different VLANs
depending on their project. All of these issues require a new style of management, known
as policy-based management. Policy-based management will be one of the highest values
offered by VLANs. This type of management will define membership in a service-defined VLAN
or workgroup.

Policy will be set by the network manager
based on a variety of service requirements that are applied to a given VLAN, such as a
specific amount of bandwidth, workgroup or project membership, access to specific
databases etc. In addition to service level, security policy can be assigned to a VLAN
membership, allowing access from only specific locations, e.g. office, home etc.

Once the policies have been defined, a VLAN
member may be associated with a policy or set of policies and be given all of the
associated rights of that policy with a simple ”click” of the mouse. When a VLAN member no
longer requires these rights, the policy may be removed and a new policy can be associated
with that member. The general model of a policy-based management function is to store the
policies in a central repository and add management intelligence to the network
infrastructure devices, such as switches and routers.

With this model, policies may be set and
stored centrally, while enforcement of the policies can occur in a distributed fashion.
Policy-based management is a powerful concept which will truly enable the potential
associated with virtual networks.

Next Steps To Switched VLAN

We have seen that there is more to implementing switched VLANs than purchasing switches
with such capabilities. Careful planning and design of the placement of switches,
protocols to implement, and management policies are more important today than ever before.
While switching and VLANs are powerful tools for the network manager, the management
issues increase with the complexity of the environment.

The best strategy may be to implement your
network in stages, installing switches where needed to enhance performance. Waiting for
the VLAN standards to be completed and full policy-based management to be available will
simplify your implementation and ensure interoperability between vendors. Only when
policy-based management products and switched VLAN standards are available will true VNETs
become viable for the average enterprise network manager.

Director of Network Technologies,
Digital Equipment Corp.

Leave a Reply

Your email address will not be published. Required fields are marked *