Table of Contents
While there are probably hundreds of network topologies that have
been used over recent years, we'll boil them down to three. By
clicking on the type of network closest to what you have now or
plan to build, you can get to the appropriate discussion of network
design. It is probably wise, however, to read the discussions
for all three, because some of the concepts developed in detail
for the smaller networks also apply to the larger ones.
Small, single segment networks.
Usually
100 or fewer users. The common topologies are
Ethernet
and
Token-Ring
. The network usually has
no more than t
wo or three servers.
Medium-sized, collapsed backbone networks.
Usually 1,000 or fewer users. Common topologies are Ethernet and
Token-Ring. A single
router
, or just a couple
routers, sit as the backbone of the network and provide connectivity
for the network. The network usually has ten or so servers.
Large, high-speed connected networks.
Usually
more than 1,000 users and often involving more than one building
or a number of floors of a large office building. Desktop connectivity
is still with Ethernet and Token-Ring, backbone is most often
FDDI
. Routers sit on the high-speed backbone
and provide connectivity to attached Ethernet and Token-Ring segments.
Figure One:
A Small Ethernet LAN
The first step to consider is whether most of the traffic on your
LAN is directed at only a few machines on the network. In other
words, is your network's traffic mostly client/server? If so,
it makes sense to get the servers onto a bigger pipe than the
workstations. If most of your traffic is peer-to-peer, then high-speed
server links won't help that much.
So how do you tell? If you don't have a network analyzer, figuring
out where your traffic is going can be a trick. Almost all small
networks today are client/server networks. If your servers store
user files, applications or both, then it is likely that most
of the traffic on your network is from your servers. However,
if you are using Windows for Workgroups, or some other peer-to-peer
NOS for file sharing, then the traffic on you network will be
much more peer to peer (some other operating systems might be:
Unix, MacOS 7 or higher, LANtastic or Windows95).
In the peer-to-peer network,
you need to make sure that your network
really is the bottleneck. It takes some kind of analyzer to tell,
but it's probably worth either getting a basic software-only analyzer
or renting a hardware analyzer for a day or two. On peer-to-peer
networks, it is usually the case that most files of interest reside
locally on each machine on the network. The result is that network
traffic tends to be light. If, on the other hand, you've got some
bandwidth intensive peer-to-peer application, like video conferencing,
you may indeed need more bandwidth in your network.
Peer-to-peer Ethernet and Token-Ring switches can be found, however,
they are becoming more rare. The upside to these switches is that
they are fairly cheap and tend to operate with very low latencies.
They often don't offer sophisticated management options and don't
support enhancements like
virtual LANs.
These
switches are usually fixed-configuration devices and support anywhere
from six to 25 ports per switch.
Depending upon the network architecture that you adopt, the internal
architecture of the
switch
may make a
difference to you. If you plan to connect just one station per
switch port, the internal buffer architecture of the switching
isn't all that critical. You'll want to make certain that each
port can buffer a good number of packets. Something on the order
of 64 KB per port is in order.
However, if you will connect a number of stations per port, the
buffer architecture itself can make a difference. A shared memory
architecture, at least on switching hubs with 25 or fewer ports,
can allow the switch to allocate more buffers to busy ports. Some
hubs also employ mechanisms for throttling back stations that
are sending too much data. On an Ethernet switch,
collisions
are simulated. On Token-Ring switches, the
token
may held for as long as possible.
The goal is not to drop packets. Dropped packets will be very
noticeable to end users as some protocols can take as long as
two seconds to time out before retransmitting a packet. Significantly
less than one percent of packets should be dropped, otherwise
you'll get complaints from end users.
Figure Two:
A small, switched, client/server LAN
Possibly some of the best products on the market are intended
for small client/server-oriented networks or work groups. These
switches have one or two high-speed ports - typically FDDI, ATM
or Fast Ethernet and anywhere from eight to 100 ports. To get
to the 100-port level, you'll have to go with a slotted hub. Fixed-configuration
units usually top out at about 25 ports. Prices here can be extremely
competitive and prices well below $500 per port should be expected.
In fact, some switching hubs may be priced lower than $200 per
port making them competitive with high end non-switching hubs.
The choice between
FDDI
,
ATM
and Fast Ethernet can be a tough one. FDDI is the oldest and most
proven technology. It is also expensive and somewhat tricky to
implement in a switching hub. The problem is that FDDI and Ethernet
have a different maximum transmission unit (MTU). In fact, FDDI's
MTU is 4,500 bytes or three times that of Ethernet at 1,514 bytes.
There are various methods for negotiating the proper packet size
to use between stations and just the fact that this negotiation
must take place makes FDDI's use more complicated.
TCP/IP is particularly tricky since the protocol relies on the
device that connects an FDDI and Ethernet network to fragment
packets down to their proper size. IP fragmentation is complicated
and it implies that the switch must know something about
TCP/IP.
Building knowledge of higher level protocols into the switch just
makes it more expensive. On the other hand, it is well known that
FDDI is an extremely efficient transport, easily delivering up
to 98% of its rated bandwidth.
Fast Ethernet is the new kid on the block, but the case for its
use is compelling. The technology has become cheap to implement
and it doesn't suffer from the MTU problems that make FDDI expensive
to implement. Also compelling is the fact that Fast Ethernet can
fairly easily be implemented as a full duplex technology. Don't
expect to see 200 Mbps flowing across your fast Ethernet pipe,
that just isn't the way client/server works. However, it is reasonable
to expect a total throughput of more than 100 Mbps.
Fast Ethernet can deliver efficient bandwidth, and by using fiber
optics, it can deliver it to distances up to 1.24 miles [two kilometers],
just like FDDI. Fast Ethernet does not have FDDI's built in fault
tolerance or link management features, however, these are probably
not that critical for smaller networks. So, in terms of performance
and price, Fast Ethernet is hard to beat, and Fast Ethernet to
Ethernet switches are most often the best way to introduce additional
bandwidth into a small network.
ATM is the up-and-coming technology, but the question is whether
it is appropriate for small networks. In general, ATM is probably
not a good choice for a small network. It is expensive and really
excels as a backbone technology for a large internetwork. It is
more costly than FDDI and far most costly than Fast Ethernet.
It is also a work in progress. Part of the reason that the cost
of ATM remains high is that all of the standards needed to fully
realize ATM's potential aren't yet finished. Companies can not
yet dedicate silicon to ATM and those that do risk producing chips
and hardware that may not conform with all standards.
Figure
Three:
A Collapsed-Backbone Design
If you're like most in this segment of the market (100 to 1,000
users), you bought a couple
routers
five
years ago or so and have been adding to them and upgrading them
all along. They work and your network is fairly reliable because
of them. So the question is, should you continue or should you
rearchitect?
As it turns out, even if you need more ports and more performance,
you can get it out of today's routers. Router vendors have felt
the heat from switch vendors and while they aren't selling their
hardware at bargain basement prices, they are offering substantially
better hardware at about the same price as the previous generation
of hardware. Of course you still have to fork over that substantial
chunk of change for a new router - but at least it will not be
substantially more than you've been paying.
Depending on the vendor, the hardware you buy will be third or
fourth generation of the product. That means a couple of things
- first, that the router will probably be a stable product and
will probably deliver two to five times the performance and port
density of the previous generation. These products tend to be
evolutionary rather than revolutionary.
While two to five times the performance is nothing to be taken
lightly, it may or may not get you by. It really depends on what
is planned for your users at the desktop. If you are anticipating
lots of high-end systems at the desktop and the possibility of
multimedia applications, a simple router upgrade may not do the
trick.
On the other hand, if your users are unlikely to be running multimedia
applications or commonly making huge file transfers a simple upgrade
may be just the ticket. After all, you already know how to manage
it and you probably have found ways to allocate addresses and
balance usa
ge. There's a lot to be said for sticking with the
system you know.
Many networks in this category are ready for a little revolution.
Powerful desktop computers and servers that can deliver new applications
change the performance requirements of networks in a way that
make routers inappropriate. Further, a simple router upgrade does
nothing to improve the manageability or flexibility of your network.
Routers
, by their nature, associate network
segments with individual ports on the router.
Switches
offer the ability to assign ports to virtual LANs (VLANs) under
software control. Just fire up your switch management software
and move ports to whichever virtual LAN is appropriate. Some vendors
have taken this a step further, associating a user's physical
network address with a virtual LAN. This allows notebook computer
users to plug in to the network anywhere and automatically be
configured on their virtual LAN. It's a pretty powerful idea,
the only drawback being that each switch port can only accommodate
one station at a time. With switch port prices coming down as
low as $200 per port, this may not be out of the question.
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 thou
gh. It is usually
not possible to move traffic from a station on one VLAN to a station
on a different VLAN. In this way, the VLAN is like a fire wall
requiring some sort of routing technology to move traffic between
the VLANs.
It may seem silly to force traffic between stations that could
be 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.
Switching hubs with VLAN support can go anywhere in the network.
The approach we favor is to use a switching hub at the back of
your network in conjunction with a router to route between VLANs.
(Shown in figure below) This approach will improve network performance
and give you the flexibility to assign VLANs within software.
No more going to the wiring closet to move users between networks.
Figure Four:
A Router with Virtual LANs
The down side to this approach is that you will probably have
to reassign network addresses to properly build the new network.
This generally isn't that big of a problem with AppleTalk and
NetWare/IPX, however, it can be quite an undertaking if you need
to do it with TCP/IP. If you have to reassign IP numbers, do yourself
a favor and start assigning them from a central server either
by reverse ARP, BOOTP or DHCP. If you need to move users between
VLANs, changing their IP number will then be as easy as editing
an address table. That's a lot better than having to visit the
users' office.
In order to get the benefit of VLANs, you really need to reduce
the number of
segments
within your network.
A new VLAN should only be needed if there is a good administrative
reason to segregate traffic. For example, you may want a VLAN
for divisions within your corpora
tion (for example, one VLAN each
for Engineering, Marketing, Finance, HR and so on). Again, the
biggest impact is likely to be on your IP number scheme as you
may have to change the subnet mask that you use in order to accomplish
this.
Changing the IP subnet mask isn't a problem either unless you
have control over only part of your IP network. Then it can cause
real problems as getting differing IP subnet addresses to work
can be a problem. In this case, it may be necessary to a VLAN
to support a long subnet mask.
Regardless of how you reconstruct your network, give serious thought
to putting the server on its own port and preferably its own high-speed
port. It just makes sense that if you have many clients on their
own ports that the servers should be off on their own higher-speed
ports. Fast Ethernet is a great, low cost way to connect servers
into the network. Many switches have FDDI ports, and there is
nothing wrong with
FDDI
(see FDDI discussion
in
Small Networks segment
). However, any
advantage to FDDI is negated by its price tag. Individual switched
FDDI ports generally run in the $4,000 to $10,000 range.
The exception to the FDDI rule, of course, is for networks that
already use FDDI. This is usually pretty rare or fairly limited
in collapsed backbone networks, so it may be justified to replace
existing FDDI or buy one FDDI port to which existing FDDI gear
can be attached.
The diagram above shows a router connected to each VLAN by standard
Ethernet or Token-Ring connections. Your existing router can be
used for this and if you create just a few large VLANs, your existing
router should be able to accommodate the traffic between VLANs.
This is a great way to leverage your existing investment in your
router and if you have WAN connections through it, you'll maintain
that conn
ectivity.
It may be difficult to connect all of your VLANs back to your
router, particularly if you decide to use more than one switch
in your network. Although methods are currently proprietary, some
vendors are beginning to offer VLAN trunking (running many VLANs
over one connection). The diagram below shows this.
Figure Five:
Virtual LANs Routed Via Trunk Lines
Figure Six:
ATM and LAN Emulation
About the only nonproprietary way to get trunking is to go to
ATM
and use LAN Emulation to develop your virtual
LANs. Using LAN Emulation and Ethernet to ATM edge switches an
existing network can handle trunking and all of the VLAN concepts
that we have talked about so far in a nonproprietary way. A warning
is in order here: LAN Emulation is only now being tested for interoperability
and it is almost assured that a single vendor solution will still
work better than a mixed solution, but at least there is hope
in the short term. It will be a while before non-ATM methods for
carrying VLAN information are standardized.
The other significant advantage to use ATM and LAN Emulation is
that servers can easily reside on more than one LAN. The virtual
circuit mechanism that ATM uses to set up data paths can easily
be used to get a server onto a number of LANs. At least today,
there is no way to get servers onto multiple proprietary VLANs
short of using multiple interface cards.
Figure Seven:
Large LAN with FDDI Backbone
The first thing to do on large networks is to find the bottlenecks.
There are two common bottlenecks on large internetworks. The backbone
itself ma
y be a bottleneck. It takes a pretty busy network to
max out an
FDDI
ring, but it does happen and
with ever-increasing regularity. The other common bottlenecks
are older routers on the network. Especially if you have added
a lot of rules and filter to your network.
If you've already invested in some sort of high-speed backbone,
it's probably FDDI and you've probably sunk a lot of money into
it. Dumping that investment and going to another architecture
is a tough call. A number of vendors have come out with FDDI switching
solutions that allow you to maintain your current investment in
FDDI. The problem is that these solutions are expensive ($4,000
to $10,000 per port) and they typically don't offer you any more
flexibility in managing and changing your network.
As a quick fix, there is nothing wrong with using FDDI switching,
however
ATM
is now becoming a reasonable solution
for adding flexibility and bandwidth into a network. The discussion
above with regard to
LAN Emulation and ATM
applies equally well to large internetworks. The market is now
seeing a number of switches boasting total bandwidth of 10 Gbps
and more.
These switches are made specifically for the large internetwork.
The concern, of course, is the scalability of the LAN Emulation.
The pipe between a backbone switch and a router is typically only
155 Mbps. This may not be sufficient for very large networks.
Further, if it takes a number of hops to get to the router at
the back of the network, overall latency may become a problem.
The industry realizes this and has proposed MPOA (MultiProtocol
Over ATM).
While we don't propose that you attempt to buy
and implement MPOA today, it is an interesting concept. The idea
is to get routing tables to the edge switches in the network and
to let them make routing decisions based on precalculated tables.
This basically turns your entire switched infrastructur
e into
one big logical router.
Figure Eight:
Multiprotocol Over ATM
The route server at the back of the network would use link state
protocols to develop a map of the network and then apply any rules
and access controls to build the routing tables that the switches
would use to make routing decisions.
Don't look for usable MPOA solutions before 1997, but keep the
model in mind. It is the most flexible and expandable model to
be envisioned for ATM that still uses current connectionless protocols.
Table of Contents
October 15, 1995
Print This Page
E-mail this URL
