Your Network's Traffic Cops

Understand how hubs, switches, and routers direct traffic on your network.

• By Bill Heldman
• April 01, 2002

This month we'll dig into the switches, hubs and routers, interesting boxes (but not dreadfully complicated, at least in basic installations) that act as the traffic cops for your network. If you understand why you'd choose switches over hubs, when you need a router, and how all of these devices hook together and talk to one another, you'll be a long way down the road toward a thorough understanding of networks as a whole.

Switches and Hubs
As a general rule of thumb, the patch panel isn't where you'll connect computing gear. All users and most servers will connect to switches or hubs. The wiring coming in from an office is connected to the rear of the patch panel. Then a patch cable is run from that port to a port on the switch or hub; see the double-dashed lines in Figure 1. In the figure, you can also see that the switches connect by a special port called the uplink port to another switch (the dotted lines). Switches that are connected in this fashion are called stacked switches. Routers usually connect to a port on the same switches and hubs as the servers and users. The idea is that all computing devices eventually connect to a port on your switches or hubs. Users simply have a longer way to go before they connect up to a switch or hub.

Figure 1. Server A is connected to an Ethernet port on a switch in the MDF. Server B is connected to a fiber port on the same switch. Server C is connected to a fiber port on a switch in the IDF. The two switches in the IDF are connected to one another by a jumper cable on the uplink ports. Incoming wiring from offices passes into the patch panel. Patch cables then run from the patch panel jacks to the switches. In this way users can communicate with the servers. Switch ports can be mixed and set for various data transfer rates. Servers are connected to the backbone.

Troubleshooting methodologies
There are a lot of places for something to go wrong when you consider the connectivity a user has with a server. The data has to pass from the user's computer to the NIC, through a patch panel to the wall jack, through the cabling running from the back of the wall jack to the back of the patch panel at an IDF or MDF, out the front of the patch panel to a patch cable connected to a switch or hub, through the switch's fabric and out through a patch cable to the server. There are many places for failure and we haven't even mentioned the cabling between an IDF and MDF! You can also see how any one of these connections, if they're weak or failing, might introduce some erratic behavior in a user's computing experience. When troubleshooting erratic behavior on a single user workstation, start with the NIC, testing the TCP/IP software, and work outward. You may have to sniff the network or bring in a cabling expert to pinpoint the exact difficulty. NICs that fail sometimes become chatty, putting out excessive packets on the network and using up a lot of bandwidth in the process. (Note: Windows NT Network Monitor software, now called System Monitor in Windows 2000, can help you find chatty NICs.)

Why test the TCP/IP software? Because often a user can't communicate due to incorrectly configured TCP/IP components. Start troubleshooting by seeing if you can ping the loopback adapter (127.0.0.1), a failsafe that tells you simply that the TCP/IP software is working correctly. Next, see if you can ping your host's IP address, then ping a host adjacent to the one you're on and finally try to ping a host across the backbone. Be sure to attempt your pings by name and by IP address so that you validate your name-server configurations. I can't tell you how often I've run into problems that center around invalid name-server configurations—remember that Windows software prefers either NetBIOS or DNS names as its preferred path for locating hosts. Your erratic problem may not be hardware at all—just a simple TCP/IP configuration. Looks like hardware, smells like hardware, turns out to be software. D'oh!

Hubs—why you don't want them
Hubs are older devices that are dumb. What we mean by that is that they don't have any intelligence built into them to effectively manage the traffic between several computing devices (stations). Hubs simply relay the data from one place to the other. You might think of hubs as stop signs that assist with the management of traffic, but they really don't have any capacity to interfere with traffic flow. This isn't a tight analogy, but it gives you a sense of the lack of capability in hubs.

All data flowing from various stations into and out of a device such as a hub is scrunched together so that the packets flow in an even line. When we describe this process we use a more technical term than "scrunch"—we say that the data is multiplexed, or more tersely muxed. Figure 2 shows this in more graphic detail.

Figure 2. Hubs mux, therefore they are dumb.

So hubs do muxing pretty well. But the problem is that they don't really care about one station over another. If station A needs to transmit a lot of data and it gets to the plate first, station B has to wait for the hub to give it an opening and mux it out the door to its destination. In other words, hubs don't intelligently manage the data. They simply lack the brains for it. Additionally you can't define things such as Quality of Service (QoS) circuits to give preferential treatment to one station or kind of data over another or set up virtual pools of ports like you can in switches. A hub is simply a pass-through point for the data. The data is brought in and muxed out.

Hubs are fine in small environments such as a Small Office Home Office (SOHO) environment, where you have a half-dozen computers and you're not into heavily intense processing. But in a corporate environment of any size, hubs aren't practical and will, at some juncture, begin to bog down the network. Job One for an admin in a new position is to assess the hub/switch infrastructure and get the hubs out of the picture, especially if they're older, slower 10Base-T jobs that have been in operation a while. (Recall from last column's conversation that 10Base-T means the data is able to flow at a maximum of 10 million bits—not bytes!—per second; not a tremendously fast data transfer rate in today's high-speed data economy.)

Another interesting point to consider with hubs is that each port generally has the same data transfer rate as all the others. Not only that, but the uplink port—the place at which the hub connects to the network—is usually also set for the same speed. You don't have to be Einstein to figure out that if you have six or seven fast machines connected to 10Base-T ports on an eight-port hub with the output directed out another 10Base-T port, you've basically got a Southern California traffic jam. It's a simple matter of understanding the bit flow.

A term you should be familiar with as you shop for these devices is port density. Hubs and switches are sold by the number of ports that they have (typically in increments of four or eight). The port density of an eight-port hub is seven—because the uplink port utilizes one of the eight available. If you have six machines connected, your port density is exhausted—it's almost time to purchase a new device. Port density is something that good admins will actively monitor in their IDFs and MDF. Nothing is worse than to have a new employee arrive at an office in a wing of your building only for you to realize that you're out of ports and can't hook up the computer!

Also note that hub/switch vendors typically advertise their wares on a per-port basis. It sounds more reasonable if a vendor can quote you "Under $99 a port" than "This switch costs $2,999". When pricing out gear, calculate the per-port price to make sure you're not getting raked.

Switches, better but more expensive
Switches, on the other hand, have a processor, code and a management user interface (UI) built into them that can handle the intelligent management of traffic between computing devices. This internal management of traffic is a wonderful thing that greatly increases the overall performance of the network. (If the Internet's networks were still using hubs, it would be a very slow Internet indeed!) However, there's a price to pay for using switches instead of hubs. You can see this for yourself by going to your neighborhood computer store and pricing a little four- or eight-port hub for your house. You'll find that you can obtain one for under $20. The same number of ports in a switch, on the other hand, will cost close to $100. You're paying for the intelligence that manages the switch's connections—generally onboard RISC processors. The same is true for corporate-class switches and hubs. Plan on paying roughly an order of magnitude more for a switch than for a hub of the same number of ports—i.e., a 24-port hub might cost $300 whereas a 24-port switch may cost anywhere from $1,500 to $3,000. Where hubs are stop signs, switches are regular stoplights.

Another facet of switch technology that you may be interested in involves buying a big chassis box, then adding the modules that you require as your needs grow. This is interesting in the following way: Suppose that you have a fiber-optic backbone on your network running at the gigabit Ethernet data transfer rate (1000Base-T). You desire for your larger busier servers to utilize the fiber backbone and your smaller servers and your users to connect with Ethernet cable. Further, you want to give some of your power users the ability to connect at 100Base-T, while the rest of your user community will connect at 10Base-T (not a big deal for the average user who is simply utilizing the Internet and e-mail).

This problem is easily solved with chassis-based switch cabinets that allow you to purchase and slide in various modules that fit your needs. You might buy a four-port fiber-optic module for your servers and two 24-port modules for your users. The ports on the switches can be adjusted to accommodate 10/100 or 1000Base-T (we'll talk about auto-negotiation in just a moment) so you can really get into the tuning of your network in very explicit ways.

Sounds good, right? Well, be ready buck-o, because the price tag on these units goes from a few thousand to tens of thousands of dollars. The UI doesn't change much and the switches are really easy to configure and manage, but the chassis overhead heavily drives up the cost. In some cases you can also add redundant switch engines and power supplies so that you have built-in fault-tolerance in your cabinets. When you purchase chassis-based switches, you choose from an a la carte menu. Be prepared to get an education in differences between fiber-optic jacks, backbone connections and so forth. You can get in over your head very quickly.

Auto-negotiation—the worst invention in networking
Both Network Interface Cards (NICs) and switch ports have the ability to detect the speed of their current connection. We call this auto-negotiation. The NIC says "Hey! I need to send data, what speed should I send at?" The switch gets the message and says "Send at 10Base-T" or "Send at 100Base-T" or whatever. There's an added twist to this because the two can negotiate whether they're going to talk one at a time (half-duplex) similar to a cell-phone call, or they can carry on a two-way conversation (full-duplex), as with a regular telephone call. So you have a myriad of choices a gigabit-rated NIC and switch port can choose from:

• 10Base-T half-duplex
• 10Base-T full-duplex
• 100Base-T half-duplex
• 100Base-T full-duplex
• 1000Base-T half-duplex
• 1000Base-T full-duplex

What's your poison?
My problem with auto-negotiation is that for some reason, especially in Windows networking, the two (switch port and NIC) seem to want to negotiate to the least common denominator. If you've got sluggish servers or workstations, chances are very good the NIC has detected 10-half while the port is trying to talk at 100-full or some other goofy configuration. I've seen all kinds of negotiations and they always create data transfer speed issues with client computers.

The secret? It's all about management. You have to be diligent about setting the NIC software in your client computers and servers for a given speed, then make sure that you set the switch ports to match. You'll help yourself in more ways than you realize by simply being proactive about the management of the negotiation between your hosts and their associated ports. For example, suppose that you have a 24-port switch whose ports are all rated for 10/100Base-T. You have 12 users. It's no big deal to make sure that the bottom half of the switch (the ports are all numbered so you know which ports you're adjusting) is set for 10Base-T Full. Then, hook up your user computers to the bottom half of the switch and go into each computer's NIC software to make sure it's negotiating at 10 Full. You've matched the NIC to the port and you'll have a much happier network, trust me.

Note that NetWare servers (at least pre-NW 6) don't have the ability for admins to go in and adjust the data transfer rate. Our NetWare 5.1 servers where I work are set for 100 Half and cannot be changed. Recently we found that the switch ports they were connected to were auto-negotiating and—go figure—they negotiated at 100 Full. As soon as we changed the switch ports to match the 100 Half settings on the Netware boxes we had instantly happier servers.

Tip: If you have a Netware/Windows shop, you're not doing yourself any infrastructure favors by hosting the IPX protocol. Get it off of your network as soon as possible and get to a completely native TCP/IP environment. You'll be happy you did because it will cure a myriad of sluggish network ills. More on that next time.

Layer 2 versus Layer 3 Switches
Some of today's switches have the ability to be not only switches (which operate at the Data Link layer, or layer 2, of the OSI model) but also as routers operating at the Network layer (layer 3), where conventional hardware routers operate. By getting into layer 3 switches, as they're called, you get out of the hardware router business, but add complexity to the overall design of the switch fabric because now the switch is not only handling the switching of data, but also routing it out the door to other destinations.

For more information on the OSI model, go to www.webopedia.com and key in OSI. You'll get all the information and links you need.

Virtual Local Area Networks (VLANs)
Another element that switches bring to the table are VLANs. If you go through your CCNA training (see below) you'll get a hefty dose of what VLANs are all about. Essentially the idea is that you want to segment your traffic in a way that matches the logical usage of your network. You might have a group of HR and financial folks that need to talk to an ERP server all day long. This is a great use for VLAN technology—the switches afford you a way to lump users together into a common unit that's independent in the switch fabric from others, thus presenting a faster user experience. VLANs can traverse switches—for example, you can have ports 8-16 of one switch and ports 4-12 of another all belong to a single VLAN.

Remember this: VLANs must go through a router or layer 3 switch to talk to other VLANs. No router, no inter-VLAN dialog.

While relatively easy to set up and manage, VLANs are definitely an advanced networking topic and well out of the purview of junior admins. But know that they exist and that your troubleshooting must take them into account.

Routers
Routers examine packets and make a decision about which direction to send them in. Sounds simple, huh? It can get deep very quickly.

You can turn Windows NT/2000 Servers into routers. Windows 2000 especially is good at being a router. However, the art of internetworking as it's called, i.e. management of routers, is usually left to specialized individuals who never touch servers and who usually insist on hardware devices to do the routing. You'd use Windows 2000 routers only in smaller installations or specialized cases.

Routing can become incredibly complicated when you consider the intermixing of different WAN protocols and associated hardware coupled with the capabilities of the router, so it's not a topic that's usually discussed in mixed context with server administration.

That being said, let me say this about that. Lots of server admins desire in their heart to get their Cisco Certified Internetwork Expert (CCIE) certification. This is the holy grail of all network certifications and is extremely difficult to obtain. Why do admins want it? I believe it's because they've heard that CCIEs make six-figure salaries and they have sexy jet-set jobs as router jocks.

True. But they also work 24/7/60-60, are on constant call-out, think nothing of spending 10-12 days straight in router closets, rarely see their families and generally get burned amazingly fast. I've known router weenies (don't tell them I called them that) who worked four straight days over Thanksgiving weekend getting some new routers going—grabbing some shut-eye in a cubicle while their partner continue configuring the blasted routers! It is a terrible job and really worth much more than six figures. Just an observance from your uncle Bill.

Whew! There is a lot to know when you start getting into switches, hubs and routers—the traffic cops of the network. They're really fun cool boxes to work with and you shouldn't be afraid of them. But you should get into an education about the technology before you try to implement it. There is no better way to do this than pick up a switch for your home network and mess around with it a little. In fact, you might be able to find a used 3COM SuperStack 3000 or similar device from Cisco, Bay (Nortel) or other vendor that you could pick up for a song, then practice setting it up, breaking it down, and reconfiguring the whole mess yet again.

Next month we talk about another huge subject—protocols and their import on the whole network infrastructure. Remember that the infrastructure, like a highway, is there for the data that traverses it, so it's important that you adequately manage the protocols going across it in order to assure that your data gets where it needs to go as quickly as possible.