Planning and Modifying a Network Topology

In this section, we cover ways to plan and modify a network topology. Why is this important? If you need to add on to or alter your network topology, you need to focus on the following areas before you do:

• You need to plan the physical placement of your network resources.

• You need to identify network protocols to be used.

Planning Physical Placement of Network Resources

Plan and modify a network topology.

• Plan the physical placement of network resources.

Now that you are familiar with how to plan a TCP/IP network, let's look at where you may want to place devices on a network. Before we get into the exact details you need to know, let's talk about why planning the placement is so important in the first place.

First, you should know how a network is laid out before you deploy it. You should know what you want a network to look like before you even contemplate ordering gear to populate it. This step is important because you must consider many factors before implementation. These factors include the following:

• Do you want redundancy and high availability?

• Do you want security?

• Where will the application flows be generated from?

• How do you stop or contain bottlenecks from occurring?

Looking at these questions before you plan anything is critical because you may change your mind during the implementation. It is possible that before you are even done rolling it out you will find something you would have done differently or better. Long story short, you need to plan physical placement of resources before you deploy them, and the best way to do this is to use a topology map.

Now you can answer the questions that you posed to yourself. Let's look at each in detail:

• Do you want redundancy and high availability ? When you design a network, you have to think about device failure. This chapter describes how to place network devices where they belong as well as how to design them properly. If you consider all the situations that can happen on a network, you surely should consider some redundancy in your network solution. You should look at all points of failure; for example, if something fails, you could be down and off the network for several hours, so you must consider if that's okay for your business. Always get managers' approvals as well because the redundant hardware may cost extra; however, the expense is worthwhile if you have to keep your network up and running all the time with minimal downtime. Examples of redundancy can be anything from redundant servers in a cluster, redundant routers for a default gateway, all the way to redundant power supplies in devices in case of failure. Today, you can order just about anything redundant for failure.

• Do you want security ? You have to plan your security infrastructure well in advance. The security infrastructure includes routers and switches, firewalls, proxy servers, even the Windows Server 2003 system you will deploy. Consider their placement in the network with an eye on security because where you place them (whether on a perimeter network or a VLAN) can actually increase or decrease the security on their network.

• Where will the application flows be generated from ? You have to consider where you will place your resources on your network. If you have a file server, a print server, two domain controllers, a WINS server, a DNS server, and a DHCP server to populate your network, where does it make the most sense to locate them? In other words, you would want a server farm segment with a high-speed backbone (perhaps gigabit Ethernet) with high-speed connections to the Internet or remote sites. You would want to make sure that your user LAN segment is also able to reach this backbone with little trouble. (Later in the chapter, we describe network monitoring and ways you locate problems with this type of solution.)

• How do you stop or contain bottlenecks from occurring ? You can follow the existing rules, one of which is called the 80/20 rule. In this rule, you make sure that 80% of your clients are closest to your network resources (such as email, file and print, and so on) and only 20% of the other clients have to cross over a network router or other device to reach those resources. In other words, you must make sure that you design your network so that you have the fastest possible paths to all resources needed; if you do not, bottlenecks may occur. Bottlenecks also may occur if you mismatch your network speeds. For example, say you use 10BaseT rather than 100BaseTX so that you have Fast Ethernet on your user LAN but only a 10Mbps connection to the Internet; this could create a bottleneck.

Selecting Network Protocols

Plan and modify a network topology.

• Identify network protocols to be used.

Now that you know how to place devices on your network, let's look at what protocols to use. Besides TCP/IP, we also mentioned other protocols earlier in this chapter. Here, we discuss routing and routed protocols and when or why to choose them. We also describe how to manage the protocols you are using, as well as why you may or may not want to use them.

When you want to plan for protocols besides TCP/IP (which we have covered throughout this chapter), you may need to consider the following protocols in your network infrastructure:

• IPX/SPX

• SNA

• NetBIOS/NetBEUI

We cover only these three because the point behind the whole objective is not to be an expert in any other protocol but TCP/IP, but to be able to recognize a need for other protocols in your network infrastructure, how to identify them, and how to plan for them.

IPX/SPX

IPX/SPX, which stands for Internetwork Packet Exchange/Sequence Packet Exchange , is similar to TCP/IP. You can think of IP mapping to IPX and TCP mapping to SPX. These protocols perform similar operations. IPX/SPX was originally created and used extensively by Novell with its NetWare platform of network operating systems. Although IPX/SPX was a great protocol, TCP/IP became the protocol of the Internet. To avoid missing out on the Internet revolution, all NOS vendors chose to develop TCP/IP into all their solutions moving forward, leaving in other protocols such as IPX/SPX only for backward compatibility. Novell NetWare version 5.0 was the first version to be shipped with a real version of TCP/IP, whereas the older versions of NetWare (versions 4.x and earlier) used add-on packs and NetWare IP (NWIP).

Because IPX/SPX was more readily adopted into the earlier network system platforms, Novell NetWare versions 4.x and earlier and some Novell Directory Services (NDS) functions did not work without IPX/SPX installed. Wherever you work in the field, you may run into older systems on a network running NetWare 4.x and earlier; therefore, IPX/SPX will be running as well. Consequently, you, the Microsoft Certified Professional, need to know how and when to deploy IPX/SPX into or out of your network if necessary.

SNA

Systems Network Architecture (SNA) is an old but still widely used protocol. Developed by IBM, SNA is a protocol suite that runs on most mainframes used today. Microsoft professionals who know only Microsoft may be shocked to learn that in today's networks they most likely will be confronted with some form of mainframe and may also be responsible for network connectivity to it.

SNA Server was an older Microsoft Backoffice product that helped Windows users connect to and print on an IBM mainframe via the SNA protocol. This solution has since been renamed Host Integration Server (HIS) 2000. Again, it is important that you understand that SNA may exist in your network and that you need to know how to work with it.

NetBIOS

Another old protocol, the Network Basic Input/Output System (NetBIOS) is a session layer communications service used by client and server applications in IBM-based token-ring and PC LAN Ethernet-based networks. NetBIOS is really just a way for application programming interface “based communications to take place. This means that higher-level services can run over lower-level protocols such as IP. This process is known as NetBIOS over TCP / IP (NBT) . The NetBIOS service contains three main sections: the name , session, and datagram services.

Why do you need to know about such a protocol? You will be using NetBIOS names if you have older systems running WINS because they are not on DNS, which would require a Windows 2000 (or newer ) network. Older systems rely on NetBIOS, so until you can upgrade all your systems, you will have to use it.