Your Network's Traffic Cops
Understand how hubs, switches, and routers direct traffic on your network.
- By Bill Heldman
we talked about the cabling in your building and the MDF and
IDFs. Remember that great admins know a heck of a lot more about their
network than just the server farmyour goal should be to fully understand
your network's components, something we collectively call the infrastructure.
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.
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 configurationsremember
that Windows software prefers either NetBIOS or DNS names as its preferred
path for locating hosts. Your erratic problem may not be hardware at alljust
a simple TCP/IP configuration. Looks like hardware, smells like hardware,
turns out to be software. D'oh!
Hubswhy 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 bitsnot bytes!per
second; not a tremendously fast data transfer rate in today's high-speed
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 portthe place at which the hub connects to the networkis
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 sevenbecause the uplink port utilizes one of the eight available.
If you have six machines connected, your port density is exhaustedit'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
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 connectionsgenerally
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 portsi.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-negotiationthe 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
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,
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
andgo figurethey 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 technologythe
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 switchesfor 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 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 goinggrabbing
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.
Understand This Stuff
|The CompTIA Network+ test will go a long
way in the switch and hub area of your education. However,
I would also recommend checking into Cisco's Certified
Network Asssociate (CCNA) certification. While the certification
is Cisco-centric (i.e. you'll have to learn what the latest
Cisco switchgear models are) all aspects of switching
in general are thoroughly covered and you'll be well prepared
to understand switching, regardless of the vendor. Sybex,
my publisher (www.sybex.com),
offers a complete line of Cisco certification study products,
including an e-virtual trainer that simulates the switch
and router configuration screens of various Cisco products.
(Check out www.bestbookbuys.com
for the very best in pricing for these and other materials.)
You can also get gobs of Cisco certification information
and news from TCPmag.com
Whew! There is a lot to know when you start getting into switches,
hubs and routersthe 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 subjectprotocols 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.