Make your own free website on
CMPnet Click here to visit Toshiba.

 Site Guide
 Latest Updates
 '96-'98 Articles Index

 Search NWC:
 best match

 Technology Guides
 Wide Area Systems
 Network Management
 Collaborative Computing
 OSes & Services
 Servers & Peripherals

 On Our Site
 Network Design Manual
 Interactive Buyer's Guide
 Interactive Report Card
 Online News
 Real-World Labs
 E-Mail Poll
 Frezza's Forum
 Workgroup Computing
 ITpro Downloads
 Well-Connected Awards

Sponsored by:

 CMPnet 3-D Site Map

 Site Services
 Advisory Forum
 Network Computing Links
 Best Jobs USA
and Marketing

Visionary Articles

 Web Connection
 Industry White Papers
 Special Supplements

CMPnet Resources
 Site Map
 Ad Info

 Free E-mail
 Sign Up Now 

Get PointCast - free!

Designing-And Redesigning-Today's Local Area Network

by Art Wittmann

Table of Contents

Current Common Architectures

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.

The Small LAN

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).

The Peer-to-Peer Network

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.

Buffer Architecture

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.

Small Client-Server Networks

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.

Medium-Sized Networks and The Collapsed Backbone

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?

The Case For The Status Quo

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.

When Revolution Is Required

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.

What Happens In a Virtual LAN

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.

Servers On Their Own Ports

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.

Trunk Lines

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

ATM and LAN Emulation

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.

Big Networks

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 E-mail this URL