Switching to Switches
Articles and Tips:
01 Jun 1998
Editor's Note: The "Technically Speaking" column answers your technical questions, focusing on issues that affect network administrators. To submit a question for a future column, please send an e-mail message to firstname.lastname@example.org, or fax the question to 1-801-228-4576.
A network administrator recently asked me the following question: I just installed a switch on my company's network to improve performance, but the network actually seems slower. What's wrong?
Although switches have become a popular way to increase bandwidth and improve performance, they are not a panacea: On some networks, installing a switch may not improve performance at all. In fact, sometimes performance may even get worse. This article explains what a switch does and when you should install a switch on your company's network to improve performance.
HOW DOES A SWITCH WORK?
A switch forwards packets by establishing logical connections between network nodes. A switch divides a network into segments and provides each segment with dedicated bandwidth, thereby increasing the bandwidth that is available to nodes.
A switch's internal, shared medium--also called the switching fabric--is a high-speed circuit that can often reach speeds of more than 40 Gbit/s. When a node transmits a packet, the switch intelligently allocates part of its available bandwidth to create a dedicated, private connection between the transmission port and the destination port. Because the switch creates a private connection between ports, a node directly connected to a switch port does not have to wait for another node's transmission to end before transmitting its own packets. In addition, a switch can perform packet translation, allowing networks using different protocols (such as Ethernet, Token Ring, and FDDI) to communicate without a router.
A switch uses one of two processes to forward packets:
As soon as a cut-through switch reads a packet's destination media access control (MAC) address, the switch begins to forward the packet to this address. In other words, the switch begins to forward the packet before receiving the end of the packet. Although a cut-through switch improves performance, this switch can propagate errors from one segment to another. Because a cut-through switch begins to forward a packet before receiving the end of the packet, this switch cannot verify the packet's checksum to detect errors.
A store-and-forward switch, on the other hand, receives and stores the entire packet before forwarding this packet to the packet's destination MAC address. Because a store-and-forward switch waits to receive the entire packet, this switch can verify that the packet is complete and that the packet's checksum matches its contents.
WHEN SHOULD YOU USE A SWITCH?
Before you install a switch on your company's network, you should analyze the network design, the amount of network traffic, and the applications running on the network. A switch is best suited for networks that have the following characteristics:
A large amount of data packet traffic (such as client-based database applications, client-server lookups, and the manipulation of large graphics files)
Multiple source and destination nodes
Network saturation issues (such as a large amount of multicast or broadcast packets)
Data Packet Traffic
By implementing a switch, you can reduce the amount of data packet traffic on a segment. For example, if your company's network contained 150 nodes and you divided the network into six segments with 25 nodes each, a node would compete for bandwidth with only 24 nodes instead of 149 nodes. As a result, the switch would increase the amount of available bandwidth on each segment.
Multiple Source and Destination Nodes
If multiple source nodes are sending packets to multiple destination nodes, implementing a switch can increase performance. For example, suppose that your company's network included several servers, each of which provided different network services, such as file and print services or database services. If you connected each server to a port on the switch, the servers would have equal access to other segments.
To further improve performance, you could load balance network services among the servers. For example, if all users logged in to one server to access applications and another server to access an e-mail program, a switch might not significantly improve performance. But if you installed both the applications and the e-mail program on each server, you could have an equal number of users log in to each server. In this case, a switch could dramatically improve performance.
Network saturation occurs when a segment becomes so overloaded with traffic that users notice performance has slowed down. You can eliminate network saturation in several ways, including the following:
Using a faster network technology (such as moving from Ethernet to Fast Ethernet)
Changing the network protocol (such as moving from Fast Ethernet, which is a collision-detection protocol, to FDDI, which is a deterministic, token-passing protocol)
Dividing the network into multiple segments that have less traffic
If you decide to install a switch to eliminate network saturation, you must carefully evaluate the network design before you create multiple segments. Because a switch aggregates traffic, the segment between a switch and a server can become saturated if nodes are sending a lot of packets to the server. To prevent the segment from becoming saturated, you must properly "size" the segment between the switch and the server. That is, you must ensure that both the switch itself and the network interface board in the server can adequately handle the throughput on the network. Otherwise, the switch or the server can actually become a bottleneck.
You can begin by determining the number and the type of workstation connections to the switch. For example, suppose that your company's network included one 10 Mbit/s segment and that you wanted to add a switch and create three additional 10 Mbit/s segments for the workstations. This solution would provide aggregate throughput of 30 Mbit/s to the workstations, with an average data load of 10 Mbit/s (assuming that all segments were running at an average of 30 percent utilization). One Ethernet network interface board running in full-duplex mode to the switch could handle this throughput, providing a 20 Mbit/s segment between the switch and the server.
On the other hand, if you created six 10 Mbit/s segments for the workstations, you would want to use at least a 100 Mbit/s protocol between the switch and the server. You would then install either a Fast Ethernet, FDDI, or ATM network interface board in the server and use a switch with a 100 Mbit/s port. If you created ten 10 Mbit/s segments, you would want to use a 100 Mbit/s protocol that can operate in full-duplex mode (Fast Ethernet or FDDI).
WHY WOULD A SWITCH NOT IMPROVE PERFORMANCE?
There are several reasons that performance might not improve--or might even become worse--after you install a switch on your company's network:
First, the nodes on the network may not be generating enough traffic to warrant a switch. For example, suppose that your company's network included one server and 20 nodes and that users mainly accessed word-processing and spreadsheet applications. In this case, replacing a hub with a switch would probably not improve performance, simply because users are not generating enough traffic.
Second, the source nodes may be sending packets to the same destination nodes. For example, suppose that your company's network included one server and 150 nodes and that users accessed a database application, as well as word-processing and spreadsheet applications. As mentioned earlier, because a switch establishes private connections between the transmission port and the destination port, the switch can transmit multiple packets at one time, thus improving performance. However, if multiple source nodes are sending packets to the same destination node (the server, in this example), a switch will not improve performance because the switch can establish only one active private connection per port.
For example, suppose that you installed a switch on your company's network and that you divided the network into seven segments: one segment for the server and six segments for the workstations. If the server were the main destination node, you simply would have changed the point of contention from one segment containing both the server and the workstations to the new segment containing only the server. Now the other six segments would have to contend with each other to send packets to the server segment.
Regardless of how fast a segment is, only one packet can be transmitted across the segment at a time. If the segment is saturated, therefore, installing a 100 Mbit/s port (Fast Ethernet, FDDI, or ATM) in the switch will not significantly improve performance.
Third, a server may be causing performance problems. For example, suppose that your company's network had a large amount of traffic, indicating a bottleneck. After you installed a switch, however, performance did not improve. In this case, the bottleneck could be the server itself. For example, the network interface board, the bus, or the disk channel could be saturated.
To determine whether performance problems are caused by the network or the server, you could use a protocol analyzer (such as Novell's LANalyzer for Windows) to monitor traffic on the wire, and you could check the server statistics. If traffic is minimal but the server statistics indicate network saturation, the performance problems are obviously caused by the server.
A switch is not a one-size-fits-all solution, as some people claim. Rather, a switch benefits networks that have enough traffic to justify creating multiple segments and that have multiple source nodes communicating with multiple destination nodes. On the other hand, a switch does not benefit low-utilization networks containing only one server. In fact, a switch may impose a significant performance hit in these cases.
So before you decide that a switch is the solution to all of your company's performance problems, do some homework: Find existing bottlenecks, and determine whether a switch will actually improve performance. And don't take a vendor's performance statistics for a particular switch at face value. You should always ask to evaluate a switch on your company's network before you purchase the switch, and you should get a performance guarantee. That way, if the switch doesn't improve performance, you can return it.
Mickey Applebaum has worked with NetWare for more than 14 years. Mickey provides technical support on the Internet for The Forums. (http://theforums.com).
NetWare Connection,June 1998, pp.33-34
* Originally published in Novell Connection Magazine
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.