| Executive Summary:
“The network is down!” At some point in your IT career, you'll hear this phrase above the din of the office photocopiers. Rarely, if ever, does the actual physical network go down. But some problems can make it appear to your users that the network is in fact down.
The following four network annoyances typically will make your users shout the above phrase and leave you scratching your head. As you’ll see, when it comes to networking not everything is as it appears. Two of the situations give the illusion of a problem with the network, although the problem actually lies elsewhere. Let's look at these network annoyances and how you can fix them. |
“The network is down!” At some point in your IT
career, you’ll hear this phrase above the din
of the office photocopiers. Rarely, if ever, does
the actual physical network go down. However,
some problems can make it appear to
your users that the network is in fact down.
The following four network annoyances typically will make your
users shout the above phrase and leave you scratching your head.
As you’ll see, when it comes to networking, not everything is as it
appears. Two of these situations give the illusion of a problem with
the network, although the problem actually lies elsewhere. Let’s look
at these network annoyances and how to deal with them.
Mysterious Disconnections
You’re summoned to the cubicle of a user who lost network connectivity.
Windows shows the connection enabled but the cable
unplugged. With a sigh, you check the user’s Ethernet cable. It’s
connected. You swap it for a different cable, but it still doesn’t work.
In a fit of frustration, you move the cable in the wiring closet between
the patch panel and the Ethernet switch to a different switch port.
The connection is restored. What’s going on?
Many enterprise switches have built-in functionality that automatically
disables a port that appears to be behaving improperly. A
typical cause is a duplex mismatch. The reasoning behind the functionality
is that a disabled port is likely to be noticed immediately,
letting the administrator correct the problem that caused the port to
be automatically disabled in the first place.
In Cisco parlance, this functionality is known as error-disable or
errdisable. Other vendors might use different terminology.
The following five steps show how you can identify and fix this problem. I use examples
based on Cisco CatOS, though
similar functionality exists for
Cisco IOS. (To learn more about
enabling Cisco routers, see “9 Steps to Setting up a Cisco Router,”
InstantDoc ID 98740.)
1. Physically identify the switch port that you believe to be
error-disabled.
2. From enable mode, execute the command
show port <port number>
3. If the port is in fact error-disabled, the status will be listed as
errdisable.
4. Fix the problem that caused the port to become disabled.
(Make sure to check your duplex configuration and cabling).
5. To re-enable the port, from enable mode execute the command
set port enable <port number>
Functionality also exists so that you can set an error-disabled switch
port to automatically re-enable after a specified period of time. You can also enforce all causes of error-disabling or enforce particular
causes (such as automatically re-enabling for all reasons except
for a duplex mismatch). To set a switch port to be automatically
re-enabled, investigate the documentation for the set errdisabletimeout
command.
Routing Between VLANs
Many IT pros use VoIP or have it noted on their ever-growing to-do
list to set up. VoIP vendors typically recommend that a separate VLAN be created explicitly to separate data
traffic from voice traffic. This separation
primarily reduces the amount of broadcast
traffic that must be received by VoIP phones.
It also eases the enforcement of more stringent
Quality of Service (QoS) parameters in
an effort to make voice quality as good as
or better than that of a standard non-VoIP
telephone.
I often hear from folks who are in the
midst of setting up this separate VLAN or
who have just recently configured it. For
some, it’s the first VLAN they’ve ever configured.
They try to ping a device with an IP
address resident in the data VLAN, because
inter-VLAN connectivity is necessary in
most cases for Internet access and management
of the VoIP infrastructure from the
data VLAN. This ping fails. In fact, all communication
fails. The VLAN must not be set
up correctly, right?
No. The problem here is simple forgetfulness
of Networking 101 skills. Switching
occurs at Layer 2 of the OSI model, but IP is
at Layer 3—you can’t route IP packets without
a device that can perform this routing
function.
The first reaction I hear is “Oh no; now I
need to buy a router. I didn’t budget for that
in my VoIP plan.” Not to worry, a router isn’t
always necessary. Here are some alternatives.
Upgrade. You might have one or more
switches that can provide Layer-3 IP routing
or that can be upgraded to support it.
The higher you go on the switch vendor’s
food chain, the more likely this is the case.
If you’re investing in new switches that provide
Power over Ethernet (PoE) for a VoIP
deployment, it might be wise to spend the
extra money up front to ensure you have a
switch with Layer-3 functionality.
Use a small office/home office router.
Using a SOHO router might not be the
best idea from a scalability and support
standpoint, but at least it gets you up and
running.
Continued on page 2