Novell is now a part of Micro Focus

The Role of the Physical Network in Network Installation and Optimization

Articles and Tips: article

BOB ROSS
President, LAN Utilities, L.L.C.
Pleasant Grove,UT

01 Feb 1997


When installing and optimizing networks, most people overlook the physical components, which can have a great impact on performance. Learn how to install a network like a bricklayer lays bricks: one course at a time, checking to make sure everything works before moving on to the next step.

Introduction

The importance of the physical network to successful network operation often goes unrecognized when network managers install and optimize networks. To be sure, network managers pay attention to physical network components as they run wiring, install network interface cards, and connect workstations and servers via hubs and routers. But how many network managers test basic network connectivity-whether two machines can simply send signals over the wire-before they load high-level client and server software? Ensuring that the physical network functions properly before complicating the picture with higher level components can help you avoid wasted time troubleshooting problems after the network is completely installed.

Likewise, testing the physical network to ensure it is running optimally can dramatically improve network efficiency. Optimizing the network requires a tool that can test communication between nodes (workstations, servers, network-connected printers, and so on), test the network cabling, identify what frame types are in use, determine which devices use what frame type, identify which configuration (NET.CFG) file is in use, and show the actual configuration of the network software. Physical network management software can give you this information by providing immediate feedback on the status of the physical and upper layers of the network.

Knowing the physical network and how it relates to network performance is crucial to successful network installation and optimization. This AppNote presents an engineered approach to network installation, discusses how to optimize the physical network, and provides several examples of physical network optimization. This is the second in a series of articles on physical network management, also known as cable plant management.

An Engineered Method for Network Installation

Two methods exist for installing networks: (1) the traditional or "put it all together and see what happens" method; and (2) the engineered or "bricklayer" method. The first method is the most common, and although it has been used for years to install networks, this approach does not always produce a successful installation on the first try. The second method is relatively new and takes advantage of sound engineering principles and physical network management software to ensure a successful installation every time.

The Traditional Installation Method

The "put it all together and see what happens" method is simple: take the computers out of the boxes, install the network interface cards, connect the network cabling, install the NetWare server, and boot the server. Then go to each workstation, install the NetWare client software, boot the client, and hope the message "You are attached to server xxxx" appears on the screen as the NetWare client loads.

If this message doesn't appear or the screen reads "File server not found" (the exact wording depends on the client version), you have to try to figure out what isn't working-a difficult process since you don't have a baseline to troubleshoot from. You might check what frame types are in use, see if the cables are connected properly, or look at the hub to see if the lights are on, but these actions are only random attempts to solve the problem.

The traditional method is neither quick nor efficient. To draw an analogy, image a car maker in Detroit gathering all of the components that make up a car and quickly putting them together without checking any of the steps along the way. Only after the car is pushed off the assembly line do they try the ignition to see if the car runs. If the car fails to start, they would have no idea what the problem was. Is the starter functional? Is the ignition switch faulty? Are all the wires connected properly? This method of manufacturing cars is obviously absurd, but most networks are installed this way.

The "Bricklayer" Installation Method

Instead of throwing everything together, hoping it works, finding out it doesn't, and then searching blindly for the reason why, network installers would save enormous amounts of time if they used what I call the "bricklayer" approach. A bricklayer carefully lays one course of bricks at a time, checking each layer to make sure the bricks are level and positioned correctly. In similar fashion, the network installer should proceed methodically, testing at several points in the process to ensure that all components are functioning normally before moving on to the next stage. This method is based on sound engineering processes and ensures that when the network finally is installed and ready to be turned on, it will run properly and efficiently.

The "bricklayer" or engineered method of network installation comprises four basic "courses" or steps:

  1. Ensure that the networking hardware and software configurations match.

  2. Test basic network connectivity.

  3. Identify the frame types in use and configure accordingly.

  4. Stress test the physical network to identify potential trouble spots.

As you complete each of these processes, you test the network to determine if all computers can talk to each other. This way, you can more easily identify problems and correct them as you go. For example, ensuring that the hardware and software configurations on all computers match, before you cable the computers together, provides a baseline to work from if the computers fail to communicate at the next stage. In other words, after you cable the computers together, if two of the stations can't talk to each other, you know that the fault must lie somewhere in the cabling stage. You've already ruled out mismatched hardware and software configurations because you tested that part of the installation before moving to the next step.

The obvious question at this point is how to test the network at each stage. The bricklayer approach relies on physical network management software to accomplish the testing at the completion of each stage. Physical network management software can:

  • Identify and help resolve differences in hardware and software configurations

  • Identify connectivity problems in network wiring or antennas

  • Analyze different media types

  • Determine what frame types are in use on the network

  • Identify what devices are using what frame type

  • Identify weak spots that could cause a network failure under load


For more information about LANengineer,visit the Web site at:

http://www.lanengineer.com

or contact:

L'Image Enterprises, L.L.C. 17853 Santiago Blvd. #107-342 Villa Park, CA 92667800-720-5557714-637-6577714-637-7557 fax

As I mentioned in my previous AppNote, I use LANengineer as my physical network management tool. This software helps me test the network at every point in the installation procedure. I use it to identify and solve problems that would stop the network from running before I finish installing the network.

Steps for a Bricklayer Installation

Outlined below are the typical steps or "courses" I go through when I use the bricklayer approach to install networks.

Course 1: Ensure Matching Hardware and Software Configurations. Remove several computers from their boxes, insert the network interface cards, and install the networking software. You only need to install the low-level part of the client software (the LSL, LAN driver, and IPX protocol stack) at this stage; however, it does no harm to install all of the networking software while you are at it.

Next, use your physical network management software (LANengineer, for example) to see if the networking software and hardware configurations match. Double-check all IRQ, I/O port, and memory address settings. You should also make sure the correct NET.CFG file is being read for configuration information. (See the heading "Checking the NET.CFG File" later in this AppNote for more information.)

Course 2: Test Network Connectivity. After you've made sure that the networking software and hardware configurations match on the computers, cable them together. Use your physical network management software to see if the computers can "see" each other over the cable. Remember that the higher level parts of the NetWare client and server software are not being used: this communication is taking place without the use of NetWare Core Protocols and other high-level components. You are simply testing whether the wire or wireless media is successfully connecting the computers at the physical level. For example, you are testing to see if a simple signal can go from one network card across the media to the next network card.

You can test the robustness of the physical network by using your physical network management software to tell you if connectivity functions or fails as you wiggle the cables, move connectors, change hub ports, move the wiring, and so on. The confidence you gain in the network's stability through this type of testing is very important. It gives you an assurance that the physical network will continue to function later when the network is actually in use (and wires are moved, hub ports shifted, and so forth).

To test these same connections with the traditional installation approach, you would have to reboot the computer and wait for the "You are attached to server xxxx" message to appear on the screen as the NetWare client loads. Not only does this process take far too long, it doesn't tell you if wiggling cables would cause the connection to break and recover. As discussed in the previous AppNote on physical network management, most network software is programmed with fault tolerance and ignores these failures until a certain number of back­to­back failures occur (generally 15). The traditional approach focuses only on a successful initial installation; it ignores intermittent communication problems that affect performance, as well as potential physical network failures down the road. The bricklayer approach, on the other hand, is proactive, allowing you to identify and correct potential problems before they actually occur.

After performing the above tests on the physical network, install the remainder of the NetWare server and client software (if you have not already done so) and boot the computers. Because you have already tested the physical connections, you know that the server and clients can communicate at the physical level. If a client won't talk to a server at this point, you don't have to scratch your head and guess why-you've already eliminated a host of possibilities with your physical network testing.

If you have other servers and clients to add to the network, you can install them using the first two steps of the bricklayer method and be confident that they, too, will be able to communicate.

Course 3: Identify Frame Types. After all the servers and clients are running, use your physical network management software to identify exactly which frame types are being used and what devices are using them. It is important to understand how frame types affect network operation and performance. Later in this article I will discuss what frame types are, how they work, and how they can negatively impact network performance. For now, it is sufficient to say that the issues I will discuss regarding frame types are best resolved at installation.

Course 4: Stress Test the Physical Network. After you have completely installed the network, from checking hardware and software configurations to testing the physical cabling and identifying the frame types in use, you should use your physical network management software to stress test the network. Stress testing sends a micro-burst of traffic over every network card, cable segment, and hub to check the health of the network. As explained in the first AppNote in this series, stress testing the physical network on a regular basis will help you proactively identify and solve problems that could impact network performance and eventually cause a network failure.

The bricklayer method of network installation relies on sound engineering processes and physical network management software for its success. It can also be used to debug your network when you encounter problems later. You can return to the first "course of bricks" and work your way back up to the final course to identify and solve the problem.

The Need for Optimization

While installing a network using the bricklayer approach will ensure a successfully operating network from the start, the network may not be optimized to leverage its full potential. To use another analogy: imagine that you've just bought a high-priced, high-performance sports car. You can't wait to take it out on the open road and run it through its paces. Unfortunately, the car's carburetor is not adjusted to the elevation where you live and its top speed is cut by 35 mph. You paid for a high­performance machine, but to achieve top speed, you have to adjust the carburetor for your environment. The same is true of LANs. You paid for high-performance capability on your network, but in order for the LAN to run at top speed, it needs to be optimized to your environment.

Networks usually don't run at their potential speed because administrators lack adequate information on the LAN's actual performance. Administrators may not be aware of degraded network performance simply because users have never experienced the network running at its full potential speed and therefore don't complain about network speed. When users do complain about network slow-downs, lack of information about the problem or incorrect information may lead network administrators to chalk it up to the users' perception rather than investigating for potential problems. Consequently, administrators rarely investigate degraded network performance because the network still works.

Physical network management software can identify areas of the physical network that may impact network performance, including testing the hardware used to connect servers and workstations. However, physical network (hardware) failures are not the only things that impact LAN performance. Improperly configured NetWare clients and servers can also cause performance problems. Even if you ensured that hardware and software configurations matched when you installed your network using the bricklayer approach, those configurations can change over time.

The best way to check the configuration of a NetWare client or server after installation is to get the actual configuration that the software is using. Never assume you know what the configuration is until you have actually checked the software configuration. Two important areas to check in NetWare networks are the NET.CFG file and frame types.

Checking the NET.CFG File

Since Novell introduced the Open Data­Link Interface (ODI) several years ago, NetWare software components have been configured using a file called NET.CFG (NETwork ConFiGuration). The NET.CFG file contains all the configuration information for the software components on a Novell network; it is divided into sections that contain the configurable parameters for each NetWare component listed in the file (protocol stack, LAN Driver, LSL, NetWare Requester, and so on).

Unfortunately, simply looking at a NET.CFG file may not give you the software's actual configuration. There are several possible reasons why you could end up with an unexpected configuration:

  • NetWare ignores any misspelled lines in the NET.CFG file. For example, mistyping "Preferred Server=xxxx" with one "r" instead of two ("Prefered Server=xxxx") causes the NetWare Requester to ignore the line.

  • Multiple NET.CFG files can be another source of trouble. It is not uncommon for a network administrator to edit a NET.CFG file that NetWare is not actually using. When this happens, the changes made to the unused NET.CFG file are not implemented, which can be very confusing.

  • Even though NetWare client software displays some configuration information when it loads, it usually goes by too fast to be useful.

Using physical network management software eliminates these problems because it can identify the software's actual configuration as well as the specific NET.CFG file that is in use. So, for example, using information gathered by the physical network management software, you could delete any unused NET.CFG files to avoid future confusion.

For more information on ODI, see "Communication Basics and Open Data­Link Interface Technology", NetWare Application Notes, November 1992, p. 51.

For more information on the NET.CFG file, see the NET.CFG chapter in the NetWare Workstation for DOS and Windows manual (NetWare 3.12), the NetWare Client for DOS and Windows User Guide (NetWare 4.1), the NetWare Client for DOS and Windows Technical Reference (NetWare 4.1), and "NET.CFG Parameters for the NetWare DOS Requester 1.1", Novell Application Notes, June 1994, p. 1.

Frame Types: An Overview

The number of frame types in use can also impact network connectivity and performance. Frame types are largely misunderstood, but they are essentially the "languages" the networking software uses when it talks on the physical wiring. To communicate, workstations and servers must speak the same language (use the same frame type). If they don't, the machines will ignore each other.

The possible frame types vary depending on the media type; I will limit this discussion to frame types used on an Ethernet network running the IPX protocol. However, this discussion also applies to any protocol (IPX, TCP/IP, and so on) running over any media type with its particular frame type.

The Problem with Multiple Frame Types. If you use Ethernet, the networking software can use four different frame types to communicate:

  • Ethernet 802.3

  • Ethernet 802.2

  • Ethernet 802.2 SNAP

  • Ethernet II (or EII, pronounced ee-too)

A NetWare workstation running IPX can use only one frame type. NetWare servers, on the other hand, can use one or more frame types for the IPX protocol. The more workstations you have that use different frame types for IPX, the more frame types you will have to load on your server in order for the workstations to communicate with each other. The server acts as the translator between two IPX devices (workstations, servers, network-connected printers, and so on) using different frame types.

To translate, the NetWare IPX router in the server treats each different frame type from each workstation as if it were on a different logical LAN segment, even if it is really the same physical wire. This is how NetWare allow multiple frame types to traverse the same network. The NetWare router translates incoming packets to the correct frame type for the destination workstation and then sends them out on the same wire to that workstation.

To illustrate how this works, imagine four ambassadors in a room at the United Nations. Each speaks only his or her native language. Without a translator, no one can understand anyone and there is no communication. With a translator in the room, one ambassador speaks, and the translator relays the message in each of the other three languages. The ambassadors can now communicate, but the process takes four times as long as if they all spoke the same language.

This is similar to what happens on an IPX network with all four Ethernet frame types loaded on the server and bound to. An IPX packet arriving at a NetWare server or router may have to be retransmitted on the same wire up to three more times. A packet that is directly addressed to a specific node is not translated itno other frame types. However, broadcast packets (including much of the traffic that occurs quite frequently on a Novell network: RIP and SAP packets, Get Nearest Server requests, Router Information requests, and so forth) are always translated into all frame types currently in use. This process consumes up to four times more bandwidth than if every node used the same frame type and only that frame type was loaded on the server.

The problem is worse with more than one server on the network. Two servers, each running IPX and using all four Ethernet frame types, will echo a single broadcast packet as many as 12 extra times. This creates a significant performance hit with the network running only 1/13 as fast as if only one frame type was in use. The problem gets worse exponentially as you add more servers. With three servers, each having all four Ethernet frame types loaded and bound to IPX, network traffic can increase as much as 48 times! This same problem exists for any protocol stack that is used, not just IPX.

A Bit of Frame Type History. Originally, the Ethernet 802.3 frame type was the default for Ethernet Novell networks running IPX. Before ODI was introduced, the frame type was so hard to change that almost all installations used this default frame type.

With the introduction of NetWare 3.12, NetWare 4.0, and Personal NetWare 1.0, Novell changed the default Ethernet frame type for IPX to Ethernet 802.2. A major reason for this change was that the Ethernet 802.3 frame type does not have a field that specifies the upper layer protocol used in the packet. Hence, with 802.3 frames a NetWare server must make an educated guess about which protocol stack to send the packet to. To help the server make its educated guess, Novell has always put a 0xFFFF in the checksum field at the beginning of IPX packets. The problem with this use of the checksum field is that, if you are using Ethernet 802.3, you cannot use security features like packet signing that rely on checksumming. In fact, when Ethernet 802.3 is used in a multiprotocol environment, it can cause servers to ABEND every once in a while-not a good thing. The best way to avoid this problem is to not use Ethernet 802.3 unless you absolutely have to, and then only when you are running just IPX on your network.

To ease the migration from Ethernet 802.3 to Ethernet 802.2, Novell had the server installation software load both frame types for IPX by default. This way, old workstations and servers using 802.3 frames would be able to talk to new servers (by being translated to 802.2), while new workstations and servers using 802.2 would be able to talk to old servers (by being translated to 802.3) via the new server's router. While this scheme works rather well to make the frame type transition smoother, it impacts performance because of the increased traffic due to multiple frame types on the network.

For more information on Ethernet frame types and NetWare, see "Migrating Ethernet Frame Types from 802.3 Raw to IEEE 802.2", NetWare Application Notes, September 1993, p. 71.

Optimizing Frame Type Usage

Obviously, minimizing the number of frame types you use with each protocol stack will decrease the amount of traffic on the network and thus increase performance. However, one problem with keeping the number of frame types to a minimum is that certain devices and workstation clients default to auto-detecting the frame type. Windows 95 and Windows NT are two such clients. HP LaserJet 4si printers and other printers and print servers that directly connect to the network also auto-detect the frame type in use by looking at the network and locking onto the first frame type they see.

This auto-detection feature is great for the manufacturer and for the user because you can put the device on the network, turn it on, and it works. Unfortunately, the auto­detected frame type may not be the optimal one for your network and, as we have seen, supporting an extra frame type can result in large amounts of needless network traffic. To control the number of frame types on your network, you should turn off auto-detection on these devices and set the frame type manually.

You can use your physical network management software to identify the different frame types running on your network and which devices are using what frame types. With this information, you can eliminate unwanted frame types and increase network performance dramatically.

Some Problem-Solving Scenarios

To illustrate the impact physical network management software can have on network installation and optimization, here are several examples of how I have used LANengineer to solve network problems.

Problems with Physical Network Components

Physical network management software can identify problems with physical components that would normally go undetected by network software because of its built-in fault tolerance. For example, a lab wired with 10BaseT Ethernet and UTP cable worked under a normal load but seemed to run slowly at times. When I used LANengineer to test the cabling, I discovered a bad crimp on one of the connectors. When I recrimped the connector and retested the network, the cable tested fine and the network began running at optimal speed again.

In another instance, a Novell network wired with Ethernet 10Base2 coaxial cable ran very slowly and workstations periodically lost their connection with the server. It turned out that the installers had used poor quality wire and connectors. As a result, the network was acting like an echo chamber, causing heavy network traffic and dramatically decreasing performance. LANengineer diagnosed the problem and identified specific trouble spots on the network. After I fixed a broken T­connector and replaced a segment of cable, the network ran at its optimal speed for the first time. The results astonished the users, as network performance increased over ten times what it was before.

Besides diagnosing current hardware problems, physical network management software can proactively identify problems with physical devices that could cause future network failures. For example, a recent LAN Times article described a situation where a network administrator found a bad network card in one of his workstations. The card was causing the server to ABEND whenever the user saved a particular file because the workstation was sending a corrupted packet to the file server. However, the corruption only occurred when the network card was under particularly high load. Had the administrator used physical network management software, he could have regularly stress tested his network with microbursts of high load to identify such hardware problems that only appear under high load.

Auto Detection and Default Frame Types

On several occasions I have seen networks where auto-detection of frame types caused problems when new NetWare servers were installed. In one case, a customer had all devices using a single frame type: Ethernet 802.2. They had an HP LaserJet Plus printer that was directly connected to the network and printing from a queue on an existing NetWare server. Then a new NetWare 4.1 server was installed with its default frame types (Ethernet 802.2 and Ethernet 802.3). When the printer was turned on, it auto-detected an 802.3 packet from the new 4.1 server and locked in on that frame type. From then on, every time the printer looked in the queue on the old file server, an Ethernet 802.3 packet had to go to the new 4.1 server, be translated into Ethernet 802.2, and be sent to the old server. To print anything, each print job packet had to go to the new server, be translated into 802.3, and then be resent to the printer. Since all this activity took place on the same LAN segment, it cut the network speed in half.

On networks where this has happened, I have used LANengineer to identify the problem and then removed the 802.3 frame type from the new server, leaving only the 802.2 frame type left on the network. When the printer was restarted, it auto-detected the single 802.2 frame type and the network ran at full speed again.

Software that can identify the frame types in use on a network is highly useful for network optimization. During a LANengineer demo, I mentioned this fact to the network administrator I was working with. He claimed that Ethernet 802.2 was the only frame type in use on his network, but I ran LANengineer anyway. To his surprise, the software showed that all four Ethernet frame types were in use. He asked which devices were using the other three frame types, and the software identified the exact stations that were using each of the four frame types. Even though this administrator was sure he didn't have a performance problem on his network, the physical network management software allowed him to identify a previously unknown problem and dramatically improve the network's performance.

Conclusion

Although the physical network is often neglected after the initial network installation, it plays a key role in successful network installation and optimization. Using physical network management software in combination with sound engineering principles will result in installations that work on the first try and provide confidence in the stability of the physical network. This type of management software can also locate the source of poor network performance and provide the information network administrators need to optimize the system. By proactively managing the physical network, administrators can save precious time and unlock the potential of their networks.

For More Information

For more information on tuning and optimizing NetWare, refer to the following sources:

  • "NetWare v3.11 Server Tuning and Optimization", NetWare Application Notes, June 1992, p. 1.

  • "NetWare 4.0 Performance Tuning and Optimization: Part 1", NetWare Application Notes, May 1993, p. 1.

  • "NetWare 4.0 Performance Tuning and Optimization: Part 2", NetWare Application Notes, June 1993, p. 1.

  • Liebing, Edward, Beyond the Basics: Maintaining and Optimizing NetWare 3 Servers (1995, 7L Press, ISBN # 0-9645751-0-8). Call 800-394-3998 or 801­342­3457 to order.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates