WINDOWS 2000 TROUBLE SHOOTING TCP/I P phần 8 pdf

492 Chapter 9 • Troubleshooting Remote Access in a Windows 2000 TCP/IP Network
To check the status of the ports, select the remote access server in the
right pane of the RRAS console and double-click Ports in the right panel.
You will see a display similar to Figure 9.12, informing you which ports
are active and which are inactive.
Figure 9.12 Check the status of the remote server ports for activity.
Ensure there are sufficient IP addresses in the static address pool of
addresses assigned by RRAS to dial-in clients if the server is configured
with a static address pool.
To add addresses to the static pool, right-click the server name in the
left pane of the RRAS console, select Properties, select the IP tab, and
click A
DD.
Inability to Aggregate the Bandwidth of Multiple
Telephone Lines
If you have multiple telephone lines (for instance, two ISDN channels) and are
unable to aggregate the bandwidth of the two lines, check the following:
■
Ensure that your ISDN adapter supports multiple lines, or that
you have two functional modems, each attached to a separate
working telephone line.
91_tcpip_09.qx 2/25/00 11:13 AM Page 492
Troubleshooting Remote Access in a Windows 2000 TCP/IP Network • Chapter 9 493
■
Ensure that the Remote Access Server’s PPP options are
configured to support multilink.
On the Remote Access Server, PPP configuration options are set in the
RRAS console’s Properties sheet for the remote access server, as shown in
Figure 9.13.
Figure 9.13 Windows 2000 RRAS allows you to configure PPP options on the
remote server.

Here, you can select the following PPP options to be used by the server:
■
Select whether multilink connections are allowed. Multilink is a
way of aggregating two or more phone lines for greater
bandwidth.
■
If multilink is enabled, you can select whether to use the
Bandwidth Allocation Protocols (BAP and BACP) to allow
multilink to adapt to changing bandwidth demands.
■
Choose to enable the Link Control Protocol (LCP) extensions. For
information about LCP options, see RFC 1661.
■
Enable software compression for greater throughput.
91_tcpip_09.qx 2/25/00 11:13 AM Page 493
494 Chapter 9 • Troubleshooting Remote Access in a Windows 2000 TCP/IP Network
Inability to Access the Entire Network
If the client is able to establish a remote connection but cannot access
the resources of any computer other than the remote server, ensure that
IP routing has been enabled on the server. Check the Enable IP Routing
check box on the IP Properties sheet for the server (refer back to Figure
9.11 to see this Properties sheet).
Also, check to see that packet filtering has not been configured to pre-
vent TCP/IP packets from being sent.
If a static address pool has been configured instead of using DHCP,
ensure that the routes to the address range(s) of the static IP address
pool can be reached by the hosts and routers on the network. You may
have to add routes to your routers via a static routing entry, or use a
dynamic routing protocol like RIP or OSPF.
If you have set up the remote access server to use DHCP for IP address

allocation, and the DHCP server is not available, APIPA addresses
(169.254.0.1 through 169.254.255.254) will be used. Unless your network
computers are using addresses from this range, the remote clients will not
be able to communicate over IP with them.
Client Configuration Problems
Although there is much more that can be misconfigured on the server, if
only one client is having connection problems, and there is no physical
reason (bad cable, NIC, etc.), chances are good that the client machine is
not configured properly to make the remote connection.
Inability to Establish a Remote Connection
■
Ensure that the client is configured to use the same
authentication method as the remote server.
■
Ensure that the client is configured to use the same encryption
strength as the remote server.
To check (and change) the authentication method on the client
machine, right-click the connection name after clicking Start | Settings |
Network and Dial-up Connections, and select Properties. On the Security
tab, choose A
DVANCED, and you will see a dialog box similar to the one in
Figure 9.14.
NOTE
91_tcpip_09.qx 2/25/00 11:13 AM Page 494
Troubleshooting Remote Access in a Windows 2000 TCP/IP Network • Chapter 9 495
The client and server must both use a common authentication and
encryption method.
■
Ensure that the user account is configured to allow dial-in
access. To do so, from the Active Directory Users and Computers

administrative tool on a domain controller, expand the domain
in the left pane of the console and right-click the user’s name in
the right pane. Select Properties, and then select the Dial-in tab,
shown in Figure 9.15.
The Allow Access radio button must be checked for the user account
to be able to make a remote connection.
The user Properties Dial-in sheet also allows you to configure callback
security requirements, assign a static IP address for remote connections, or
apply static routes.
Figure 9.14 The authentication method and encryption are set in Advanced
Security settings.
NOTE
91_tcpip_09.qx 2/25/00 11:13 AM Page 495
496 Chapter 9 • Troubleshooting Remote Access in a Windows 2000 TCP/IP Network
Troubleshooting Remote Access Policy Problems
Remote access policies consist of conditions and parameters placed on
the incoming connection. Windows 2000 allows you to set policies to con-
trol client access based on such things as day of the week or time of the
day, group membership, connection type (VPN or dial-in), and set limits
on duration of connection, idle time after which the connection is discon-
nected, and security parameters. Figure 9.16 shows some of the limita-
tions that can be placed on dial-in access.
When a user attempts to make a remote connection, the characteris-
tics of the connection attempt are compared with the authentication
information, user dial-in properties, and remote access policies.
When the connection attempt doesn’t match any of the remote access
policies, access will be denied. Multiple remote access policies can be in
place, but this makes troubleshooting connection denials more complex.
Figure 9.15 Remote access permission must be granted in the user Properties
sheet.

91_tcpip_09.qx 2/25/00 11:13 AM Page 496
Troubleshooting Remote Access in a Windows 2000 TCP/IP Network • Chapter 9 497
Determining Which Multiple Policy
Is Causing the Problem
Microsoft recommends that one way to verify which policy is causing the
denial is to create a new remote access policy called Troubleshooter and
configure it to grant remote access permission for all days/times. Then,
move this policy to the top of the list so it will be processed first. If the
connection is denied, the problem is either with the Troubleshooter test
policy itself, or more likely, with the user account’s dial-in Properties set-
tings.
If the connection succeeds, move the test policy down one level and
attempt to connect again. If this connection fails, the problem is most
likely with the policy just above the Troubleshooter policy. If it succeeds,
keep moving the test policy down the hierarchy until a connection is
denied, and then examine the properties of the policy that is causing the
denial.
Figure 9.16 Remote access policies let you place restrictions on dial-in access.
91_tcpip_09.qx 2/25/00 11:13 AM Page 497
498 Chapter 9 • Troubleshooting Remote Access in a Windows 2000 TCP/IP Network
Troubleshooting NAT
and ICS Configuration Problems
Windows 2000 makes it easy to share a single public IP address for
access to the Internet by using Internet Connection Sharing (ICS) on a
Windows 2000 Professional computer or a choice of ICS or Network
Address Translation (NAT) on a Windows 2000 Server.
The Difference between ICS and NAT
ICS is available on both Windows 2000 Professional and Server, while
NAT is only available on the Server family of operating systems. This
statement in itself could be a little confusing, since ICS actually is a form

of NAT. You can think of Internet Connection Sharing as NAT Lite—it
uses NAT to map internal network IP addresses and ports to a single
external IP address, but it is not as flexible and configurable as the full-
fledged form of NAT that comes with Windows 2000 Server.
Common NAT Configuration Problems
If you are having problems with the NAT computer not properly perform-
ing translation, so that packets don’t get delivered to the internal comput-
er (NAT client) for which they are intended, check the configuration of the
NAT interfaces. The NAT routing protocol must have both public and pri-
vate interfaces. To check this, in the RRAS console, under the server
name, expand IP Routing and select Network Address Translation. You
should see a public and a private interface listed, as shown in Figure
9.17.
The public interface connects to the ISP, and the private interface con-
nects to the LAN. Ensure that the public interface is configured for
address translation, as shown in Figure 9.18. Right-click the interface
name and select Properties.
The radio button for “Public interface connected to the Internet” must
be selected. You should also check the Translate TCP/UDP headers check
box to allow NAT clients to send and receive data through the interface.
Now, ensure that the private interface is also properly configured.
Right-click the private interface’s name, and select Properties. The same
configuration box will appear, only in this case the “Private interface con-
nected to private network” radio button should be checked.
91_tcpip_09.qx 2/25/00 11:13 AM Page 498
Troubleshooting Remote Access in a Windows 2000 TCP/IP Network • Chapter 9 499
Which Connection Sharing Solution
Is Right for My Network?
If you have a small network that needs access to the Internet, and
only one public IP address, Windows 2000 Server gives you the

choice of using ICS or NAT to provide Internet access to the entire
network through a single computer’s Internet connection.
Either of these solutions will save the cost of additional phone
lines, modems, and ISP accounts for connecting additional comput-
ers to the Net, as well as the time and work involved in setting them
all up for Internet access and the difficulty of maintaining and mon-
itoring their access.
Which one, then, should you use to connect your network? ICS
and NAT work in a similar fashion, but NAT is the more sophisticat-
ed of the two. ICS is configured by right-clicking the connection’s
icon in Network and Dial-up Connections and selecting Sharing. It is
quick and easy to configure and suitable for many small, simple net-
works. ICS assumes that this is the only computer on the network
that is connected to the Internet, and it sets up all the internal net-
work addresses. By selecting Enable Internet Connection Sharing for
this Connection, you make the computer an ICS host. This computer
will assign IP addresses to its ICS clients as a DHCP allocator.
ICS is appropriate if you don’t have DNS servers, DHCP servers,
Windows 2000 domain controllers, or systems using static IP
addresses. That limits its use to small peer-to-peer networks.
For larger or more complex networks, sharing of an Internet con-
nection can be accomplished via NAT, which is configured as part of
RRAS. To use it, you must install and configure the Routing and
Remote Access Service (if it is not already installed). NAT requires
more configuration by the administrator, but also allows you to spec-
ify or change the IP address range assigned to NAT clients, and can
be used on Windows 2000 domain networks or those connected to
gateways or routers.
So, if you have a small peer-to-peer workgroup among which you
wish to share an Internet connection, and don’t need control over

the IP address range, ICS will be the simplest solution. In most busi-
ness networks, you will need the more sophisticated features of NAT.
For Managers
91_tcpip_09.qx 2/25/00 11:13 AM Page 499
500 Chapter 9 • Troubleshooting Remote Access in a Windows 2000 TCP/IP Network
Incorrect Public Address Range
Another problem that can occur with NAT configuration is incorrect con-
figuration of the public addresses when you have multiple public IP
addresses.
Ensure that the addresses are entered in the Properties sheet of the
public interface, under the Address Pool tab. All addresses entered here
should be addresses that were assigned to you by your ISP.
NAT can provide address translation using multiple public IP addresses; ICS
cannot.
Incompatible Application Programs
The packets of some programs will not work through NAT. If a program
runs from the NAT host computer but you cannot run it from a NAT
client, it may be because the program uses a protocol that is not translat-
able by NAT. Windows 2000 NAT includes NAT editors for the following
common protocols: FTP, ICMP, PPTP, and NetBIOS over TCP/IP.
Additionally, some protocols such as HTTP do not require a NAT editor.
Figure 9.17 NAT requires both a public and a private interface.
NOTE
91_tcpip_09.qx 2/25/00 11:13 AM Page 500
Troubleshooting Remote Access in a Windows 2000 TCP/IP Network • Chapter 9 501
A related problem, and a major limitation of NAT, is the inability to use it
with IPSec for host-to-host security (sometimes called end-to-end). This is
because IPSec hides the IP headers required by NAT for translation. You can,
however, use NAT if you are using IPSec for a gateway-to-gateway solution.
Other NAT Problems

If none of the solutions just discussed uncovers the culprit, ensure that
IP packet filtering is not configured to prevent sending and receiving IP
traffic. If the problem is related to name resolution, ensure that NAT
name resolution has been enabled on the private interface. Troubleshoot
Internet name resolution problems as outlined in Chapter 7,
“Troubleshooting Windows 2000 DNS Problems.”
Figure 9.18 The public interface must be configured for address translation.
NOTE
91_tcpip_09.qx 2/25/00 11:13 AM Page 501
502 Chapter 9 • Troubleshooting Remote Access in a Windows 2000 TCP/IP Network
Troubleshooting VPN Connectivity Problems
Virtual Private Networking (VPN) is a popular solution for those who need
a secure, yet inexpensive way to connect from a remote computer to a
LAN when dialing in directly either isn’t possible or is costly due to long
distance charges. Using encapsulation and encryption, a VPN allows you
to establish a private “tunnel” through a public network such as the
Internet, using the client’s and server’s Internet connections.
A detailed explanation of how VPN works is beyond the scope of this book,
but if you are interested in the basic “how-to’s” of setting up a VPN, see
“Managing Windows 2000 Network Services,” published by Syngress.
The Tunneling Protocols
Windows 2000 supports VPN connections using either Point-to-Point
Tunneling Protocol (PPTP) or Layer 2 Tunneling Protocol (L2TP).
PPTP: Point-to-Point Tunneling Protocol
PPTP is an industry standard tunneling protocol. It was in Windows NT
4.0 and is also supported in Windows 2000. PPTP is an extension of the
Point-to-Point Protocol (PPP) and uses the authentication, compression,
and encryption mechanisms of PPP.
L2TP: Layer 2 Tunneling Protocol
The Layer Two Tunneling Protocol (L2TP) supports multiprotocol VPNs

that allow remote users to access corporate networks securely across the
Internet. It is similar to PPTP in that it can be used for tunneled end-to-
end Internet connections through the Internet or other remote access
media. However, unlike PPTP, L2TP doesn’t depend on vendor-specific
encryption technologies to establish a fully secured and successful imple-
mentation. L2TP utilizes the benefits of IPSec, and will likely eventually
replace PPTP as the “tunneling protocol of choice.”
Troubleshooting VPN Connections
Troubleshooting a remote VPN connection is similar to troubleshooting
other remote access connections, with a bit of added complexity.
NOTE
91_tcpip_09.qx 2/25/00 11:13 AM Page 502
Troubleshooting Remote Access in a Windows 2000 TCP/IP Network • Chapter 9 503
Inability to Connect to the Remote Access Server
There are many causes for this problem. As usual, you should begin with
the most basic and simplest possibilities:
■
Ensure that the RRAS service is started on the VPN server.
■
Ensure that RRAS is installed and enabled on the VPN server.
■
Ensure that PPTP or L2TP ports are enabled for inbound remote
access traffic.
■
Ensure that LAN protocol(s) used by the VPN client are enabled
on the VPN server.
■
Ensure that all PPTP or L2TP ports are not already in use.
■
Ensure that the VPN client and server are configured with a

common authentication method and a common encryption
method.
■
Ensure that the user account has the proper dial-in permissions
granted.
■
Ensure that remote access policies are not causing a denial of
the connection.
As you can see, most of these problems are related to the same config-
uration considerations we discussed earlier concerning general RRAS
troubleshooting.
Summary
In this chapter, we have provided some basic information about how
Windows 2000’s Routing and Remote Access Services, hand-in-hand with
the dial-up networking component, make it easy for users to connect to a
remote server and for administrators to provide dial-in access to those on
their networks.
We looked at the differences between a remote access connection to
the company network and participating as a local (cabled) node on the
network, and concluded that the only practical difference is the speed of
the connection. Data transfer speed is limited to the media over which the
connection is made, and we saw that typical wide area networking links
provide for speeds from 56 Kbps or less (analog modems) to about 6 Mbps
(high-speed ADSL).
We examined the differences between remote access and remote con-
trol, and learned that the latter is usually used by administrators to take
over control of the server from a remote location. This is often done to
troubleshoot problems or administer the server services when the admin-
istrator is offsite. We saw that remote access is used to connect to the
91_tcpip_09.qx 2/25/00 11:13 AM Page 503

504 Chapter 9 • Troubleshooting Remote Access in a Windows 2000 TCP/IP Network
network and access shared files, print to shared printers, or otherwise
participate as another node on the network.
We then discussed the elements of different available wide area net-
working technologies over which our remote access sessions can be
established. We provided an overview of remote networking using the ana-
log phone lines on the Public Switched Telephone Network (PSTN).
We then looked at a faster and “cleaner” technology, Integrated
Services Digital Network (ISDN). We learned that ISDN is usually provi-
sioned in one of two forms: Basic Rate ISDN (BRI), which provides two 64
Kbps data channels, and Primary Rate ISDN (PRI), which provides for up
to 23 64 Kbps data channels for a total throughput of 1.544 Mbps.
Next we talked about the newest “kid on the block,” Asymmetric
Digital Subscriber Line (ADSL), and how its cost advantage and “always
on” technology make it a popular alternative to ISDN—if your location is
within 17,500 feet of a telephone company Central Office (CO).
After that, we looked at how Windows 2000 supports connection to an
X.25 network, which uses a Packet Assembler/Disassembler (PAD) and
provides for data transfer over a public packet switched network.
Then we discussed the WAN protocols used for remote access net-
working: SLIP and PPP.
We learned that SLIP is used on some UNIX servers, but Windows
2000, like NT 4.0, supports only PPP for dial-in connections.
We talked about the four steps involved in making a PPP connection:
configuration, authentication, callback (optional), and configuration. Then
we moved on to some specific tips for troubleshooting PPP problems,
which include authentication failures, inadequate link/line quality, loss of
carrier, and timeouts.
We looked at how to configure a dial-up connection to use PPP, and
we gained an understanding of encapsulation, the method by which

TCP/IP or other LAN protocol packets are wrapped inside the PPP or SLIP
protocol headers.
Next we saw how we could use Network Monitor and PPP trace logging
for gathering information about a PPP connection.
We then focused on troubleshooting configuration problems. We
looked at common configuration problems involving the remote access
server, including inability to establish a remote connection, inability to
aggregate the bandwidth of multiple phone lines, and the inability to
access the rest of the network even though a connection with the server is
established.
After that, we looked at client configuration problems, and the impor-
tance of ensuring that the remote client uses the same authentication
and encryption methods as the remote server.
91_tcpip_09.qx 2/25/00 11:13 AM Page 504
Troubleshooting Remote Access in a Windows 2000 TCP/IP Network • Chapter 9 505
We talked about remote access policies, and some of the common
problems that arise in using them. We also learned a method of determin-
ing which of multiple policies is causing a connection denial problem, by
creating a test policy and manipulating its position in the order of appli-
cation.
Next we looked at Internet Connection Sharing (ICS) and Network
Address Translation (NAT), and discussed common configuration and
implementation problems that can occur when you share an Internet con-
nection with a network through one ICS/NAT host. We learned that ICS is
configured through Network and Dialup Connections, while NAT is config-
ured via the RRAS console. We also found out that NAT requires both a
public interface (connected to the ISP) and a private interface (connected
to the LAN), and that each must be configured according to its role. We
discussed the ramifications of entering the wrong public IP address range
in NAT properties, incompatible application programs whose protocols

cannot be translated, and the importance of ensuring that IP packet filter-
ing is not configured to prevent IP traffic from getting through.
Finally, we took a brief look at virtual private networking (VPN), the
two tunneling protocols supported by Windows 2000 (PPTP and L2TP),
and how to troubleshoot VPN connectivity problems.
Remote access gets easier to configure with each new Microsoft oper-
ating system, but there are still many things that can go wrong with a
remote connection. These problems benefit from a methodical, organized
approach to troubleshooting—keeping in mind that a remote access con-
nection in many ways is no different from a cabled network connection,
except for the added layer of the WAN link used to achieve it.
FAQs
Q: How can I use caller ID with RRAS to enhance dial-in security?
A: If the phone system(s) used by the caller and the remote access server
support the caller ID feature, you can use the caller ID feature when
you set dial-in security. You can specify the phone number from
which the user must dial in. If the user calls from a different phone
number, the connection will not be successful. Be careful in using this
feature, because if you do configure dial-in security with a specified
caller ID phone number for the user and the system does not support
caller ID, the connection will be denied. Note that if the connection is
a VPN connection, the caller ID number will be the IP address of the
client.
91_tcpip_09.qx 2/25/00 11:13 AM Page 505
506 Chapter 9 • Troubleshooting Remote Access in a Windows 2000 TCP/IP Network
Q: Does Windows 2000 work with modem-pooling equipment?
A
: Yes, as long as the modem-pooling device generates and accepts
command strings equivalent to one of the supported modem types
listed in the Install New Modem wizard. In that case, you connect the

equipment to the COM ports and configure the ports for remote access
using RRAS. Microsoft recommends that you configure modem-pooling
devices to behave like a Hayes-compatible modem since that is a
commonly used standard.
Q: Does the Windows 2000 remote access server support callback
security on an X.25 network?
A: No, Microsoft advises that callback is not currently supported on X.25
connections.
Q: In what way is Windows 2000’s remote access component more
configurable in terms of security than Windows NT 4.0?
A: In NT 4.0, a user’s authorization to dial in to the network was
dependent on one simple check box to grant dial-in permission to
user, set in User Manager or the Remote Access Administrative Tool.
Windows 2000 allows you to grant or deny remote access to a user in
the user’s property sheet in Active Directory Users and Computers,
and also allows you to further restrict dial-in permissions based on
remote access policies, which can be applied to members of specific
groups, to specific connection types, and other more broad-based
criteria.
Q: What is BAP, and how does it work?
A: The Bandwidth Allocation Protocol (BAP) is used to increase the
efficient use of the network bandwidth by adding or dropping
additional links according to changes in traffic flow, on a dynamic
basis. To do this, BAP works in conjunction with Multilink PPP in
Windows 2000. BAP policies can be set through the remote access
policy feature to make it easy for administrators to control connection
costs and still provide for optimum bandwidth for users.
Q: What are NAT editors, and why might I need one?
A: NAT editors are software components that are added to NAT in order
to make modifications to the IP packet beyond the translation of the IP

address in the IP header, TCP port in the TCP header, and UDP port in
91_tcpip_09.qx 2/25/00 11:13 AM Page 506
Troubleshooting Remote Access in a Windows 2000 TCP/IP Network • Chapter 9 507
the UDP header. This additional translation is required with certain
protocols that store the IP address, TCP port, or UDP port in the
payload (for instance, FTP). Windows 2000 includes NAT editors
already built-in for FTP, ICMP, and PPTP. Windows 2000 doesn’t
include editors to translate SNMP, LDAP, Microsoft COM, or RPC.
91_tcpip_09.qx 2/25/00 11:13 AM Page 507
91_tcpip_09.qx 2/25/00 11:13 AM Page 508
Troubleshooting
Windows 2000
Connectivity Problems
at the Network
Interface Level
Solutions in this chapter:
■
NICs
■
Cable
■
Hubs and Repeaters
■
Bridges
Chapter 10
509
91_tcpip_10.qx 2/25/00 11:15 AM Page 509
510 Chapter 10 •Troubleshooting Windows 2000 Connectivity Problems at the Network Interface Level
Introduction
Now that we have discussed some of the protocols and services related to

TCP/IP, and know how to use the built-in utilities and add-on monitoring
and troubleshooting tools, we’ll take a look at connectivity problems from
the ground up—or perhaps we should say “from the bottom up.” That’s
the bottom of the OSI and DoD networking models we’re referring to, of
course. You’ll recall that the Network Interface layer in the DoD model is
roughly equivalent to the Physical and Data Link layers of OSI. In this
chapter, we will examine some of the things that can go wrong at this
level, and how to address them.
The Network Interface layer involves physical problems—network
interface cards (NICs), cable, and network connectivity devices such as
hubs, repeaters, and bridges. The differences between these various
Network Interface layer devices, and how they compare to higher layer
devices such as Layer 3 switches, routers, and gateways, is sometimes a
source of confusion even for IT professionals. For that reason, we will look
at how the various connectivity devices work, and some of the reasons
they don’t always work properly. Because the DoD Network Interface layer
also encompasses the OSI Data Link layer, it also involves software driv-
ers for the hardware. We will discuss the importance of updated and
properly configured NIC drivers in making it possible for the TCP/IP pro-
tocol suite (or any other) to send data across the network.
We will not spend a lot of time discussing the details of how to install
and configure networking hardware. In this chapter, we will be pointing
out those areas in which Network Interface layer problems, such as those
related to physical devices or software drivers, can affect TCP/IP connec-
tivity and even mimic protocol configuration problems.
Problems with
Network Interface Card Configuration
Configuration of the NIC at the physical level is the first step in achieving
a TCP/IP connection. Although an improperly configured card is not a
protocol-specific issue, it may be mistaken for one, and much time can be

lost in trying to troubleshoot TCP/IP when the problem lies elsewhere.
Thus, it is important for an administrator to know how to determine
when the connection is failing due to a lower-level problem.
One easy way to determine that the problem lies in the lower layers is
to attempt to establish a connection using a different protocol. If your
computer is unable to communicate with others on the network using
TCP/IP, but can make the connection when NetBEUI or NWLink is
91_tcpip_10.qx 2/25/00 11:15 AM Page 510
Troubleshooting Windows 2000 Connectivity Problems at the Network Interface Level • Chapter 10 511
installed on the machines, you know to start troubleshooting the protocol
configuration. If you still have no luck in making a connection with other
network transport protocols, it is likely that you have a problem with the
hardware or the hardware drivers. This simple test can save you much
time and effort.
The Role of the NIC
The NIC (also sometimes called the network adapter, or just the network
card) plays an essential role in TCP/IP and other network communica-
tions. The NIC is the device that physically joins the computer and the
cable or other network media, but its function is more complex than that.
The data cannot just flow through the network card and out onto the
cable (or from the cable through the NIC into the computer’s memory)
because the form in which the computer processes the data is different
from the format necessary to send it out over the cable.
The NIC must convert outgoing data from a parallel format, in which
bits of information are sent in multiple lines or paths, as takes place
inside the computer, to serial format, where the bits move in “single file”
on the cable.
Network cards also have memory chips, called buffers, in which infor-
mation is stored so that if the data comes in or goes out too quickly, it
can “rest” there while the bottleneck clears and there is room for it to

pass onto the cable or up into the computer’s components.
Types of NICs
Of course, it is essential that you ensure that the NIC installed in the
computer is the proper type for both the media and architecture used by
your network. For instance, Ethernet and Token Ring require different
types of NICs. This is because of the different ways in which the media
access methods function. And, of course, the card must have the proper
connector for the cable type being used. These are basic, relatively
straightforward issues, but don’t overlook them when troubleshooting
connectivity problems.
Be sure to check the Windows 2000 Hardware Compatibility List (HCL) to
ensure that your card is supported. The list can be accessed from the
Microsoft Web site at www.microsoft.com/hcl. Although devices not listed
may still work with Windows 2000, if your card is on the list you can be
confident that it has been tested and is compatible with the operating
system.
NOTE
91_tcpip_10.qx 2/25/00 11:15 AM Page 511
512 Chapter 10 •Troubleshooting Windows 2000 Connectivity Problems at the Network Interface Level
Driver Issues
Like other hardware devices, the NIC requires a software driver to provide
the interface between the operating system and the card. Be sure the
driver that is designated for your specific model of NIC is installed, and
that it is the latest incarnation. Experienced administrators know that
simply installing an updated NIC driver can solve countless connection
problems.
Windows 2000 supports a large number of common brands and models of
NICs, and the drivers are included on the Windows 2000 CD. However,
these may not be the latest versions. Always check the manufacturer’s Web
site for a download area where you can obtain the latest drivers.

Since Windows 2000, unlike NT 4.0, is a plug-and-play operating sys-
tem, supported cards are more likely to be automatically detected and the
drivers installed from the Windows 2000 installation files (or you will be
prompted to supply the disk or network location). Be cautioned again,
however, that the drivers installed by the operating system may be out-
dated.
Windows NT did have the capability to detect some network cards with its
limited plug-and-play capability.
Updating Drivers
NIC drivers (and drivers for other hardware devices) can be updated
through the Device Manager. To do so, click Start | Settings | Control
Panel | System. Select the Hardware tab and click D
EVICE MANAGER. The
list of installed devices will be displayed, as shown in Figure 10.1.
You can select the card you wish to configure or update and double-
click it, then select the Driver tab. This interface makes it easy for you to
update the files, as shown in Figure 10.2, and also makes available useful
information about the resources being used by the device, any conflicts,
and troubleshooting tools.
A handy feature is the Hardware Troubleshooter, which can be
accessed from the General tab.
NOTE
NOTE
91_tcpip_10.qx 2/25/00 11:15 AM Page 512
Troubleshooting Windows 2000 Connectivity Problems at the Network Interface Level • Chapter 10 513
Figure 10.1 Use Device Manager to configure and update drivers for the NIC.
Figure 10.2 The properties sheet for the device provides valuable information
about the driver.
91_tcpip_10.qx 2/25/00 11:15 AM Page 513
514 Chapter 10 •Troubleshooting Windows 2000 Connectivity Problems at the Network Interface Level

In order to access the Device Manager and install or update device drivers,
you must be logged on to an account with the appropriate permissions. Be
aware that network policy settings (Group Policy, IPSec, and other security
settings) may also prevent you from performing these tasks.
Problems with Cable
and Other Network Media
Another type of problem that can mimic TCP/IP protocol configuration
problems is damaged, defective or improperly installed cable or other net-
work media. Broken or shorted cables can be detected with a cable tester
or TDR (time domain reflectometer). Some of the more sophisticated (and
more expensive) LAN testers will even pinpoint the exact location of the
break.
As a network administrator, you may have other personnel who han-
dle hardware and cabling. It is important, however, that you are able to
recognize the symptoms of Physical layer problems so that you will know
when to call in the technicians, rather than spend your time attempting
to “fix what isn’t broken.”
Damage to the media is not the only factor when considering Physical
layer problems.
All network architectures—for example, Ethernet, Token Ring,
AppleTalk—include specifications that must be met concerning network-
ing equipment and media. If those rules are ignored, connectivity may be
lost completely, or you may experience intermittent problems.
Common areas of noncompliance, which can result in difficulties in
establishing or maintaining a connection, include cable type and grade,
and the limitations on the allowable segment length for various
network/cable types.
Network Cable Specifications
Be sure that the cabling for your network meets specifications for the par-
ticular architecture. For instance, a 10Base2 network requires not just

thin coaxial cable, but a particular type of thin coax: RG-58 A/U (the
cable grade is usually indicated on the side of the cable itself). Don’t try
WARNING
91_tcpip_10.qx 2/25/00 11:15 AM Page 514
Troubleshooting Windows 2000 Connectivity Problems at the Network Interface Level • Chapter 10 515
to substitute something else that is “close” or looks similar; you will be
setting yourself up for connectivity problems if you do.
It is not an unknown occurrence for a cable technician (or perhaps
more likely, a net admin with little hardware experience) to attempt to
replace a broken or bad length of thin coax cable with RG-58 U or even
RG-59 (the cable used for cable TV). Therefore, in checking the Physical
layer for the source of a connectivity problem, ascertain not only that the
cable is connected and appears to be undamaged, but that the cable type
meets specifications.
Another example of improper cable type would be substituting catego-
ry 3 twisted pair for cat 5, when running a 100 Mbps (100BaseT) net-
work.
Cable type is generally indicated on the cable itself. If it is not, you can
identify the cable type by counting the wire pairs or measuring the ohm
rating.
Cable Length Issues
You undoubtedly are also aware that because of the susceptibility of cop-
per cabling to attenuation, or signal loss over distance, network specifica-
tions place limits on the acceptable length of a segment of cable,
depending on the architecture and cable type.
A cable segment is generally defined as the length of cable between
repeaters. A repeater (or other connectivity devices that perform boosting
of the signal) allows you to increase the distance of your network. We will
discuss these devices in the next section of this chapter.
Violating the length specifications may be tempting, especially if you

only need to go “a tiny bit further” in order to get the cable to a specific
office or other location. You might get away with it—the cable does not
just automatically stop working when you exceed the specified distance.
But going beyond these limitations can cause you to have connectivity
problems that you might easily mistake for software/protocol problems
when the real trouble is at the physical level.
Table 10.1 shows common network/cable types and the maximum
cable segment length for acceptable performance.
NOTE
91_tcpip_10.qx 2/25/00 11:15 AM Page 515
516 Chapter 10 •Troubleshooting Windows 2000 Connectivity Problems at the Network Interface Level
The Role of Network Connectivity Devices
We call them “network connectivity devices” for the obvious reason: They
are used to connect networks (also called network segments or subnets).
But why are there so many different types, and how do we know when to
use which on our TCP/IP networks?
Let’s first think about the characteristics of the TCP/IP suite. One of
its strong suits—in fact, the number-one reason it is the protocol of
choice for so many networks today, as well as the protocol of the global
Internet—is its routing capability. Routing refers to transferring data from
one network or subnetwork to another. Thus, it makes sense that connec-
tivity devices are common in TCP/IP networks.
Usually the type of device we associate with an internetwork is the router,
which works at the DoD’s Internetwork layer (Network layer in the OSI model).
We will briefly discuss routers in this chapter, in the context of how they differ
from the Network Interface layer devices, and we will devote an entire chapter
(Chapter 11, “Troubleshooting Windows 2000 Connectivity Problems at the
Internetwork Level”) to routing problems and other Internetwork layer trou-
bleshooting. But we also should remember that there are other, lower-level
devices that can be used for such purposes as:

■
Extending the distance limitations of network cable
■
Connecting network segments that use different media types (for
instance, thin coax and UTP)
■
Segmenting the network to reduce traffic without dividing the
network into separate IP subnets
Although a large percentage of network connectivity problems occur at
the Network Interface level, it is often overlooked in the troubleshooting
process. That is, until you discover, after spending an entire afternoon
completely reconfiguring both your server and your client, that your
inability to connect or your loss of data packets was caused by a physical
problem with your repeater or bridge.
Network Type Cable Type Distance Limitation per Segment
10Base2 RG-58 A/U
Thin coax
10Base5 RG-8 or RG-11
Thick coax
10BaseT
100BaseTX
185 meters (607 feet)
500 meters (1640 feet)
Category 5 UTP 100 meters (328 feet)
Table 10.1 Cable Length Limitations
91_tcpip_10.qx 2/25/00 11:15 AM Page 516