Network Design Strategies

This chapter is from the book

Upgrading and Repairing Networks, 5th Edition

Learn More Buy

This chapter is from the book

This chapter is from the book 

Upgrading and Repairing Networks, 5th Edition

Learn More Buy

Many types of networks were discussed in Chapter 1, "A Short History of Computer Networking," from ARPANET to TCP/IP. And in Chapter 2, "Overview of Network Topologies," you learned about the various topologies you can employ when designing and creating a local area network (LAN), and we also looked at some scenarios in which several networks were connected to form a wide area network (WAN). In this chapter, we will look at another aspect of creating a network: the network's logical and physical design. The physical aspects of your LAN will depend on the underlying physical transport technology—Ethernet or Token-Ring, for example, or possibly ATM, which is supported as a LAN protocol in products such as Windows 2000/XP, Windows Server 2003, and Linux. Depending on which technology you use, there will be one or more LAN topologies from which to choose.

Before you can begin to design a physical network, however, you first must determine your needs. What services must you provide to your user community? What are the resources you'll need? If you have to compromise, what will it take to satisfy the most users or to provide the more important services? You then will have to take into account network protocols, applications, network speed, and, most important, network security issues; each of these figures into a network's logical design. Another important factor your management will probably force you to consider is cost—you can't forget the budget. These factors make up the logical design for your network. You first should decide what you need and what it will take to provide for those needs.

If you are creating a new network and purchasing new applications, you will probably spend most of your time considering the licensing and other financial costs (training users, network personnel, and so on). If you are upgrading older applications, several other factors come into consideration. Many applications that were coded using COBOL, BASIC, FORTRAN, and other languages that helped jumpstart the computer age may have built-in network functionality based on older proprietary network protocols. If this is the case with your network, you have to consider several things. What will it cost to update thousands of lines of code (or more) to more modern versions of the same programming language? What will it cost to upgrade these programs to newer object-oriented languages? To save money, can you upgrade part of your network and use gateway hardware/software to connect to older network components?

Because of the costs associated with coding applications that were created many years ago, and the expenses that will be required to update them to modern programming languages, you may be forced to maintain legacy applications for a few years while replacement applications are designed and created. You may find a packaged application that can be used to replace older programs. This problem will apply mostly to proprietary computer architectures, instead of Windows or Unix platforms. If you can simply make minor changes and compile the source code so that it will run on a newer operating system, your costs will be much less than if you have to re-create the applications your users need from scratch. Another cost associated with upgrading to new programs is training users and help-desk personnel.

Planning a Logical Network Design

When you plan a logical network design, you can start from one of two places. You can design and install a new network from scratch, or you can upgrade an existing network. Either way, you should gather information about several important factors before you begin the logical design. For example, depending on the services that will be provided to clients, you might need to analyze the possible traffic patterns that might result from your plan. Locate potential bottlenecks and, where possible, alleviate them by providing multiple paths to resources or by putting up servers that provide replicas of important data so that load balancing can be provided. The following are other factors to consider:

• Who are the clients? What are their actual needs? How have you determined these needs—from user complaints or from help-desk statistics? Is this data reliable?
• What kinds of services will you provide on the network? Are they limited in scope? Will any involve configuring a firewall between LANs? And if so, that still doesn't account for configuring a firewall to enable access to the Internet.
• Will you need to allow an Internet connection for just your internal network's users, or will use you need to allow outside vendors access to your network? One example that comes to mind is the Internet Printing Protocol (see Chapter 24, "Overview of the TCP/IP Protocol Suite"). What will it cost to evaluate what kind of services user groups need to access from the Internet? Will you need to allow all users to use email—both within the internal network and through the firewall on the Internet? The same goes for what sites users will be allowed to access using a network browser and other network applications. Will you have users who work from home and require dial-in or VPN access through the Internet?

• Can your users tolerate a little downtime now and then due to network problems, or is it necessary to provide a high-availability network? Will you need clustered servers to provide for a high degree of uptime, or do your users' applications not suffer from a temporary loss of the use of a server? To provide for maximum uptime, can you afford to build redundancy into your network? For example, Chapter 2 discusses redundant topologies that can be used to prevent a single point of failure from making the network (and its resources) unavailable. Chapter 11, "Network Attached Storage and Storage Area Networks," describes methods you can use to mirror data at geographically distant locations.
• In an existing network, will you keep the current protocol or upgrade to a different protocol standard? If you create a network from scratch, what factors should affect your network protocol decision? Ethernet is the most popular LAN technology in the world today. TCP/IP is the most popular protocol suite that runs on Ethernet. Yet there are cases in which other technologies have their niches. Consider the implications (such as support costs and security) to maintain older, proprietary protocols.

Who Are Your Clients?

This seems like a very simple question. However, I'm not saying, "What are your clients' names and how well do you know their children?" I am referring instead to your knowledge of the job descriptions for the users on the network. You need to assess work patterns for various departments so that you can appropriately place servers, high-bandwidth links, and other such things in the appropriate physical location of the network. If most of the network traffic you expect to see will come from the engineering department, you'll need to provide that department with a large data pipe. In Chapter 4, "Upgrading Strategies and Project Management," you'll find more information about surveying the user community to come up with a plan that places resources where they are needed.

What Kinds of Services or Applications Will the Network Offer?

Of course, everyone knows that the most important function of a network today is to support multiuser gaming. Seriously, though, you need to make a list of the kinds of applications currently in use, as well as a list of those requested by users. Each application should have a written risk assessment document that points out potential security problems, if any. Typical network applications today include FTP, telnet, and, of course, browsing the Web. There are "secure" versions of these applications and there are versions that leave a door wide open into your network. Whatever list of applications you chose to support over the network, keep in mind two things:

• Is the application safe? Most applications today come in secure versions or can be used with a proxy server to help minimize the possibility of abuse. Yet, as we all have seen, even the largest corporations are targets at times, and those companies have the staff that should be able to prevent these things from happening. Because proxy servers are an important component of firewalls, this subject is covered in greater detail in Chapter 45. If you want a secure network, this is highly recommended reading!
• Does one application overlap another? Every user has his or her favorite application. Some people like one word processor, whereas others prefer a different one. But when dealing with applications or application suites (such as Microsoft Office), you'll find it better to make a decision and stick with a single product if it can satisfy the needs of your users. They might not like it, and training might be necessary, but supporting multiple applications that do the same thing wastes money and leads to confusion.

A commonly overlooked method for getting data files out of a network and onto the Internet is to simply send the files as an attachment to an email. So if you think you've blocked file transfers by disabling FTP access through the firewall, this example should show that you really do need to do a thorough evaluation of any new application or service you will allow on the network. New applications should be justified with facts that show why they are needed. If an existing application can be used to accomplish the same goal, why do you need another application? Should you retire the older application and use a newer one? Pay attention to the details. And don't forget to test new applications to ensure that they perform as expected. The same goes for older applications—will they work on the new or upgraded network?

Lastly, do you monitor network usage? Do you want to permit users to spend their days browsing the Net, or checking personal email while at work? Many companies have policies that apply to using the telephone for personal business. Do you overlook this situation when giving users email capability? Are you preventing access to sites that are obviously not business-related?

What Degree of Reliability Do I Require for Each Network Link?

Just how much downtime is acceptable? For most users, the answer would be zero. Important components of your network, such as file servers, should have fault tolerance built in from the bottom up. In large servers, you'll find dual-redundant power supplies (each connected to a separate UPS), and disk arrays set up using RAID techniques to provide for data integrity in the event that a disk goes south. If a link between two offices needs to be up 100% of the time, you should plan for multiple links between the two sites to provide a backup capability. In this case, you also can justify the cost of the extra link by using load balancing so that network response time is improved. And, if you are using multiple links to remote sites, it's always a good idea to have more than a single path to the site. At one site this author worked at, there were redundant power lines bringing electricity into the site—side-by-side. If a tree falls, will it bring down one or both of those power lines?

Another technology that can be used to provide an extra layer of redundancy, as well as high-speed access to storage devices, is the Storage Area Network (SAN). A SAN is a network that is separate from the LAN and contains only storage devices and servers that need to access those devices. Because the network bandwidth is not shared with LAN users, multiple servers can access the same storage. If one server fails, other servers can be configured to provide redundant access to the data. Also, the same RAID and other redundancy techniques used for storage devices that are directly attached to a server (such as the SCSI hardware and protocols) can be used on a SAN.

The old saying "If it ain't broke, don't fix it" doesn't apply to networks. You should always be proactively looking for potential single points of failure and doing something to fix them. By building redundancy into the network design at the start, you'll save yourself a lot of grief in the future.

Chapter 5 can give you more suggestions about using clustering, backups, uninterruptible power supplies, and other techniques that can keep the network up and running.

Choosing a LAN Protocol

Today the de facto protocol of choice has to be TCP/IP. However, other protocols have their place in some vertical markets. In this book, we talk about NetWare. NetWare has been around so long that you might find you have no choice when designing an upgrade but to keep using IPX/SPX, depending on the applications your network uses. However, even NetWare has moved toward using TCP/IP as the underlying protocol. This is basically the case for version 5.x and 6.x of NetWare. Older NetWare networks should upgrade, if possible, to one of these newer versions. If you will be connecting the network to the Internet, TCP/IP will be a necessity. Even if you don't expect to have an Internet connection, you'll find that choosing TCP/IP is a more practical choice today because most applications work with it and there is a large market of trained professionals who can be hired to manage a network built on TCP/IP. NetWare 6.x provides backward compatibility with IPX/SPX for the most part, but newer features such as the iPrint—which uses the Internet Printing Protocol—require TCP/IP.

In addition to transport protocols such as TCP/IP and IPX/SPX, you must consider application protocols that can be used on the network. For example, to simplify administering configuration information for a large number of computers, you might want to use the Dynamic Host Configuration Protocol (DHCP), which is discussed in Chapter 28, "BOOTP and Dynamic Host Configuration Protocol (DHCP)." If you want to provide a central name resolution service, you might choose the Domain Name Service (DNS), which is covered in Chapter 29, "Network Name Resolution." If you are going to operate a Windows network that has pre–Windows 2000/XP clients, you might need to use the Windows Internet Naming Service (WINS) for backward compatibility.

So when thinking about a network protocol, remember that it's not just one protocol you need to worry about. After you've decided which protocols are necessary, research the security implications of each.

It's Virtually Universal: TCP/IP

For all practical purposes, the standard LAN protocol today is TCP/IP. This is partly due to the rapid growth of the Internet, and the necessity of most businesses of having a Web presence, as well as the large number of vendors that have adopted this protocol suite. If your LAN is still using an older proprietary network protocol, you should seriously consider what it would take to upgrade to TCP/IP. Currently, TCP/IP version 4 is the most widely used protocol. In the future you can expect that the next version (IPv6) will start to find its way from the core of the Internet out to the edge, where your network resides. While technologies such as Network Address Translation (NAT) are widely employed to remedy the problem associated with the limited address space provided by IPv4, IPv6 will enable a much larger address space. Combine that with Network Address Translation, and the long-term bets are going to be on IPv6, or possibly some of the features that are part of IPv6. In addition to giving you a larger address space, IPv6 includes other important features. Those that will affect your network the most are security mechanisms, which will only become more important as Internet commerce continues to grow.

There is one very important reason you should consider TCP/IP as a LAN protocol: There are more trained professionals knowledgeable in TCP/IP than any other LAN protocol at this time. It is interesting to note that in Windows NT 3.51, the default network protocol was Microsoft's implementation of IPX/SPX (NWLink). In Windows NT 4.0 (and successive operating systems, from Windows 2000, XP, and Server 2003), the default network protocol is TCP/IP.

If your network is composed of several operating systems, from Windows to NetWare to Unix and Linux, then the bottom line is that TCP/IP is the lowest common denominator that will allow the easiest connectivity and interaction between all of these. Even Microsoft's now-legacy NetBIOS/NetBEUI protocols have been adapted to run over TCP/IP.

Novell's NetWare Version 6.5

NetWare was perhaps the first attempt at seriously providing a LAN protocol that was easy to use. The basic file and print services offered by early versions of NetWare were much better than other solutions available at that time. After it became established in the business community, NetWare became the network solution of choice in many business environments that used the PC. Microsoft countered this success with its LANManager products, which were also marketed by other vendors in their own way, such as the Pathworks solution from Digital Equipment Corporation.

Today NetWare is a totally revamped solution to LAN connectivity. It provides many new features that are addressed to specifically make use of the Internet, and allow mobile users to connect to their home networks, as well as to enable NetWare users to make connections to outside networks. For example, the iPrint feature enables NetWare users to print to a printer on a remote network. For example, instead of sending a catalog that may be out of date in a month or so, you can use iPrint to periodically send specific information relevant to each customer, by printing it directly to the customer's printer.

And NetWare's iFolder allows mobile users to synchronize data stored on remote computers (such as a laptop computer) with the data stored on the company's network. Microsoft and other vendors offer similar features. However, the point to remember is that if you already are a NetWare user, you don't have to throw out your existing investment and move to a Microsoft network, or even a Unix/Linux environment. NetWare has changed as the market has changed, and you might find it less expensive to upgrade to NetWare 6.5 than to migrate to another platform. The bottom line involves not just the cost of migrating to another operating system, but the costs involved with retraining your network administrative personnel in new technology.

Because NetWare 6.5 is so tightly integrated with the IP protocol, and also offers backward compatibility with IPX/SPX, admins for existing NetWare networks should consider upgrading to NetWare 6.5 as well as considering other options.

If you want to move to Linux, Novell makes it easy by incorporating an enhanced version of NetWare 6.5 and SuSE Linux into its Novell Open Enterprise Server. Open Enterprise Server supports both Linux and NetWare-specific software and features, enabling you to move to Linux gradually.

Other LAN/WAN Protocols

The distinction between LAN and WAN (wide area networking) protocols is beginning to blur. Ethernet was once considered to be a LAN protocol. As time has passed, other technologies, such as Token-Ring, have become minor players in the LAN world. Yet the opposite is true of Ethernet. It has grown from a modest specification endorsed by Intel, DEC, and other vendors, such that it now can be considered a WAN protocol. The capabilities introduced by current LAN technologies are beginning to erode the differences between a LAN and a MAN (metropolitan area network). When the fourth edition of this book was published, Gigabit Ethernet was starting to fall into the inexpensive range of network topologies. That trend has continued and now 10Gigabit Ethernet (10GbE) is frequently being used in enterprise data centers. Today you may be using 100BASE-T for connecting client computers to the network, and Gigabit Ethernet to connect network segments via the network backbone. In some cases your network might even be exclusively based on 10GbE.

What does this mean to a network administrator today? With 10Gigabit Ethernet, you can use TCP/IP not only to create a local area network backbone, but to extend that reach to a metropolitan area network. And because TCP/IP is so intertwined with Ethernet, you can achieve an end-to-end MAN link that uses TCP/IP over faster Ethernet connections. Instead of employing more expensive solutions, such as SONET, you can now connect branch offices in the same geographical area using just TCP/IP.

You may not have to worry about installing expensive equipment used by SONET and other typical MAN protocols. Still, for the long haul—for example, between different cities—other protocols such as ATM and Frame Relay will come into play.