The primary problems with cabling stem from data getting garbled in transit. The higher-level networking systems all have provisions for detecting errors, but the end result is that packets whose data is garbled are discarded, never reaching their destination. Whenever this happens, the packet has to be retransmitted, and usually there is a significant delay while the two systems wait for the packet to arrive and finally realize that it didn't. This delay manifests as 'lag' -- significantly slow data transmission. A packet loss of only ten percent (one packet in ten) will slow a T1 line down to the effective speed of an old 14.4K modem.

100 megabit ethernet is a different story. Everything must meet Category 5 specifications. A certain wiring pattern should be used when wiring everything from wall jacks to patch panels to patch cables. If all these specifications are not met, then data can be garbled with all the resulting problems.

What has happened in many networks is that over time, the older 10 megabit network cards have been replaced with 100 megabit cards, and the older ten megabit hubs have been replaced with 10/100 hubs or switches. By default, these devices will run at 100 megabit if both ends support it. However, if the cabling in between them isn't up to the task, it results in garbled data. Most companies have migrated gradually to 100 megabit without even necessarily realizing it, just because the newer devices support that standard.

Paradoxically, 100 megabit over bad cabling can actually be slower in terms of real performance than 10 megabit. The speed gained from the faster networking standard can be more than offset by the packet loss within the cabling. It presents a huge performance problem on the network, and can result in intermittent network-wide failures, slow performance, and periodic downtime.

Use the ping command from an MS-DOS prompt. You can use the -l parameter to set the packet size, and the -t parameter to tell it to send pings until you press Ctrl-C to interrupt it. For example, to send pings until you interrupt it with a 512-byte packet size, use this format:

The address you choose to ping should be that of a server, a router, or something else with a stable, high-bandwidth connection. Watch it over the course of about fifty or a hundred pings. You want to watch for 'Request timed out.' messages. Cabling problems will manifest as statistical noise. In other words, the larger the packet size, the more likely a packet is to have some corruption in it and be discarded. The reason for this is simple: if a typist makes one mistake per one thousand keys hit, there's more likely to be an error in a ten page document than in a two paragraph memo.

If you get *no* packets received, try a smaller packet size. If you don't specify the -l parameter, then you'll get the smallest possible packet size. On a properly-functioning local area network, you should see almost no packet loss (maybe one in ten thousand, tops), no matter what the packet size. If you get no packets through even at the smallest size, then it's important to check all the other aspects of the network -- don't immediately blame cabling.

If there's a sharp cutoff point -- as in, packet sizes of 1500 bytes work fine, but 1501 bytes result in zero packets getting through, then it may be a configuration error on the client or the server. MTU settings can be important, if those have been tampered with (some of these 'Internet Accelerator' packages adjust the MTU settings on the system to provide the illusion of more speed).

Over Ethernet, in a local area network, you should see no packets lost except maybe the first one. The first packet will sometimes be lost due to "ARP delay" -- time that is spent looking for the receiving system on the network. However, after the first packet in a ping test, you should see zero packets lost. If you see more than that, there is a problem.

Put another way, cabling problems tend to be highly random in their nature. This isn't always the case, but when things consistently fail, that usually points to some other culprit, unless the cabling is so bad that it is totally nonfunctional.

It always surprises me how many patch cables are sold or provided with network devices that are not Category 5. Many times, when you purchase a router or a cable modem, they provide a cable that is designed to work only at ten megabits. Since the device is only a ten megabit device, this is fine. However, very often, the cable gets used for some other purpose, such as connecting a workstation.

Try a different patch cable if the first one fails. It's a good idea to have a known good patch cable on hand to use to swap out and test to see if the cable might be bad.

A correctly wired patch cable should be wired in one of two valid sequences, which are shown below. Any other sequence does not meet Category 5 specifications. In addition, the conductors should go all of the way to the front of the cable box, and the outside jacket should be held by the crimp at the rear of the connector.

Hold the cable so the front of the connector is facing away from you, and the clip is on the bottom. The pins are numbered from 1 to 8 going left to right.

Only the green and orange pairs are actually used (Pins 1, 2, 3, and 6). The other pairs are not used and are not rated to carry data at 100 megabits. If a cable doesn't meet these specifications, don't use it. Either of the two listed standards is fine, so long as both ends use the same standard. If they use different standards, then the result is a crossover cable, which has applications as well.

Diagnosing cabling problems is usually a matter of trying to route around the problem to locate where it is. Unless your organization is large, it's not cost-effective to purchase a full cable-tester for your building. In addition, they take time to learn to use, which can be part of the problem with renting them.

Enter-Networks has a relationship with American Fiber and Cabling for Kansas City area businesses. American Fiber and Cabling will visit your location and perform a free cable diagnostic to determine if there are problems that require resolution. Please contact us to schedule time for this. It can be valuable to catch these problems now, rather than after the increasing demands of the newer operating systems cause these problems to manifest as intermittent bugs.

Ethernet is the most common local area network standard in use today by far. It's a very simple protocol. In essence, there are two rules. Listen on the wire to see if anyone else is transmitting. If so, don't transmit. If you hear a gap, it's okay to try to talk -- but if you hear somebody else start to talk at the same time, both of you should shut up and wait a random amount of time before trying again. When two systems both start to talk at once, it's called a collision. Some collisions are normal on an Ethernet network; unless they get excessive, they won't interfere with the transmission of data.

A hub is little more, in most cases, than an electronic 'pass-through' device. Signals come into one port and get sent out through all the other ports. In essence, everything plugged into a hub can be considered to be 'on the same wire'. What this means is that all the machines share a collision domain -- that is, data from one system can cause a collision with that from another system. When two hubs are chained together, everything connected to both hubs is a single collision domain. In addition, the network bandwidth is 'shared'. If you have a 100 megabit hub, then that 100 megabits is a total amount of bandwidth available to everything on the hub. If one system is using 50 megabits, then that leaves only 50 for the other systems to use.

It's also not allowed to chain more than three hubs together in sequence. If you have more than three hubs, there should be one system designated as the 'central' hub, and other hubs should be connected to that one. Otherwise there is the possibility that data from one system won't be visible to another system, which can cause network-wide problems.

A switch offers multiple advantages over a hub, especially in certain networking architectures.

• Traffic Control. Instead of rebroadcasting everything, it has the ability to be selective. If it sees a packet destined for your server, it doesn't automatically rebroadcast it to all the other workstations on the network. Instead, it learns where various devices are on the network and routes traffic appropriately.
• Better Bandwidth Usage. Instead of that 100 megabits being shared between all systems, each system can communicate at its full peak bandwidth.
• Better Security. One common trick hackers may use, especially on very 'open' networks, is to hack one system on the network and install a 'packet sniffer' that looks for traffic on the network that might represent passwords or other sensitive information. It then captures this information for the hacker to use. A switch helps defeat this by only sending a host packets which are destined for it.
• Full-Duplex. With a hub, packets sent by a server can potentially cause a collision with packets being sent to that server. Effectively, that 100 megabits is split between sending and receiving. Full duplex mode allows the two operations to be independent of one another, so that a server could transmit 100 megabits and receive 100 megabits.
• Fault Tolerance. A switch is usually much better about detecting 'jabber' conditions on network cards -- a situation where the card gets stuck into transmit mode and jams up the network with gibberish. It's fairly infrequent with today's network cards, but a switch will handle it much better if it happens.
• Managability. Some of the higher-end switches enable you to segment traffic, combine ports together into 'channels', control traffic flow, monitor traffic flow, and perform other tasks related to network management. While smaller networks aren't quite so dependent on these features, they can be invaluable in larger networks.

Switches are most valuable in networks where there are a large number of different destinations for traffic. If you have a single server and a relatively small Internet connection, and very little inter-workstation or network printer traffic, then a switch won't help all that much. It will still help, of course, but it won't provide the dramatic increase in performance that you would see on a network with multiple servers.

Switches are generally more expensive than hubs. Managed switches are especially expensive, often costing as much as $50 to $100 per port. Hubs are generally cheaper. However, for small networks, you can use switches with limited management capabilities to gain many of the advantages of switching without the high-end situations for as little as $10 to $25 per port -- not that much more than hubs.

While there are definite advantages to going 'switch to the desktop' -- that is, having every port in the network be connected to a switch -- this is sometimes not cost effective. Another model that works well is the 'hybrid switch' model. In this design, a central switch is set up, and then hubs are chained off of that. High bandwidth, central devices like servers and routers are connected directly to the switch, and then hubs are hung off the remaining switch ports to service the workstations. This model provides a very good cost/performance trade-off, permitting many of the advantages of switching to be used at a lower cost.

When purchasing a switch or a hub, make sure it supports both 10 and 100 megabits. Nearly all devices today should support that standard. If you have any ten megabit hubs left in your network, get rid of them. If they aren't auto-sensing, then they are an accident waiting to happen once the bandwidth exceeds a certain amount. The only time they will be acceptable is if they are plugged directly into a 10/100 switch and their bandwidth usage is minimal.

Current computer systems, in order to speed up operations, store updates that need to be done to the hard drive in memory for a period of time before writing them. This 'write-caching' helps it perform fewer writes, because often when one change is made, other similar changes follow closely. However, if the system goes down unexpectedly during this process, some writes may be made while others are not. The result is an inconsistent state. For example, one index migh say a record exists, while the another does not. This sort of problem is often difficult to resolve; it can require a full database rebuild, which can take hours, during which time the system will be offline.

It's highly important to provide power backup for any mission critical systems -- enough power to allow for orderly shutdown. Servers that are left online all the time should also have software installed to permit them to shut down in the event of a power failure. This simple expedient can save large amounts of money later. Even a small UPS, though, can prevent small power outages of a few seconds to a few minutes from causing a system crash.