WINDOWS 2000 TROUBLE SHOOTING TCP/I P phần 3 docx

122 Chapter 3 • Windows 2000 TCP/IP Troubleshooting Guidelines
This is where you configure the maximum amount of disk space the
log can occupy, and what should occur when the limit is reached. You
can also clear the log here, with the click of a button.
You can also filter the events in a specified log. When you archive the
log, however, the entire log will be saved regardless of filtering.
You must be an administrator in order to set logging options.
Tools of the Trade
Chapter 4 will look in detail at some of the tools you can use to assist in
your “diagnosis” and plan a “cure” for the problem.
Perhaps the most important tool for a network troubleshooter is a
good protocol analyzer. To really learn what’s going on with the network,
you have to examine the packets themselves. This requires not only that
you have a good analyzer, but that you learn how to use it.
There are many types available, from stand-alone and handheld
devices to software-only solutions.
Microsoft’s Network Monitor (often referred to as ”NetMon”) is a good
tool for analyzing Windows-based networks. A big advantage is that a
basic version of NetMon is included with the Windows 2000 Server oper-
ating systems (see Figure 3.12).
This free version of NetMon will only capture packets that are sent
from or to the server on which it is installed. If you want to capture pack-
ets for the entire network, you need the enhanced version of Network
Monitor, which is part of Microsoft’s System Management Server.
In Chapter 4, we will discuss in detail how to use NetMon and other
network analysis tools.
When we have finally gathered as much data as possible, we can move
on to the next phase in the troubleshooting process.
The Problem Isolation Phase
This is the Diagnostic, or Analysis phase. This is where you take the large
amount of information gathered from your investigative sources (results

of monitoring and analysis equipment, users’ answers to questions, and
your own personal observations), determine which bits are relevant and
which can be discarded (in any thorough investigation, there will always
be much more “data” than useful “information”), and use the rest to put
together the pieces of the puzzle and solve the mystery.
NOTE
91_03.qx 2/25/00 10:59 AM Page 122
Windows 2000 TCP/IP Troubleshooting Guidelines • Chapter 3 123
One of your objectives during this phase is to look for patterns. Has
this problem occurred here before? Do the “symptoms” match something
you’ve heard about or read about? The first step in analyzing the informa-
tion is to organize it in a fashion that will allow you to notice trends and
pick out the key facts.
Organizing and Analyzing the Information
This step may be done on paper, on screen, or in your head, but it is
important that you sort through all the random facts and numbers you’ve
gathered to determine which facts support which theories (and which
would tend to negate which theories, too). In its simplest form, the
process would work like this:
Your user reports that the network file server, BIGSERVER, is “gone”
from the network. (BIGSERVER is a Windows 2000 member server in a
mixed-mode domain).
Figure 3.12 The Microsoft Network Monitor included with
Windows 2000 Server.
91_03.qx 2/25/00 10:59 AM Page 123
124 Chapter 3 • Windows 2000 TCP/IP Troubleshooting Guidelines
Given that information, what are some scenarios that could cause the
problem? It’s possible, although unlikely, that BIGSERVER has crashed.
Since the machine itself sits a few feet away from your own workstation,
you use your visual observation skills to confirm that BIGSERVER is up

and running. You’ve eliminated one possibility. Another is that
BIGSERVER’s network card has malfunctioned, a cable has loosened, or
something else has caused the server to become disconnected from the
network.
You continue your investigation by trying to access BIGSERVER from
your own workstation. You are able to ping the server with no problem
using its IP address. You have eliminated another possibility: you now
know that BIGSERVER is connected to the network. And since you can
ping him successfully, you know his TCP/IP configuration is okay.
You now consider the possibility of a name resolution problem.
Perhaps the network’s DNS server is down. You try pinging BIGSERVER
by name, and get a response. The DNS server is working properly.
Could the problem be with the network’s browser service? You check
“My Network Places” and find that BIGSERVER is listed in the domain.
Perhaps there’s a problem with NetBIOS name resolution. The user
didn’t say what application he was using that made BIGSERVER disap-
pear, so maybe its not a host name problem, but a NetBIOS name prob-
lem. You double-click BIGSERVER in the My Network Places windows,
and you see all of BIGSERVER’s network shares.
At this point, you’ve narrowed the problem down considerably, and
decided that it must be specific to the complaining user’s workstation.
You go to that computer, which is running NT Workstation, and question
the user further. What exactly does he mean when he says BIGSERVER is
“gone?”
The user tells you that he has tried to FTP to BIGSERVER and is
unable to do so. He also opens up My Network Places and clicks on
BIGSERVER’s name. Nothing happens.
At this point you suspect a problem with the workstation’s configura-
tions, but don’t know whether it’s a browse issue, a name resolution
issue, or a TCP/IP connectivity issue.

You ask if he tried to ping BIGSERVER and he replies that he did,
using the server’s IP address, but received “some kind of error message.”
Now you’re hot on the trail of the problem! You know it’s not a name reso-
lution problem, since that wouldn’t affect your ability to ping by IP
address. You know the server’s IP address is configured and working
properly because you were able to ping from your own workstation.
Now you open a command prompt, attempting to ping BIGSERVER and
reproduce the problem. When you type “ping 192.168.1.2” at the command
line, you receive the message shown in Figure 3.13.
91_03.qx 2/25/00 10:59 AM Page 124
Windows 2000 TCP/IP Troubleshooting Guidelines • Chapter 3 125
This error indicates that something is wrong with the TCP/IP stack.
You get the same message when you attempt to ping the loopback
address, 127.0.0.1. That convinces you that TCP/IP is not working. You
open the local area connection’s Properties box and discover that TCP/IP
is not installed on the machine. Upon further questioning, the user tells
you that he uninstalled the protocol from “another connection.” He points
to the connection icon for the VPN, assuring you that he didn’t change
anything on the local area connection.
You sigh and explain that uninstalling the protocol from one connec-
tion removes it from all of them that use that network card, and you rein-
stall and reconfigure TCP/IP. BIGSERVER magically reappears. The user
asks you why he was still able to “see” the other servers, and you show
him that the NetBEUI protocol was still installed after he removed
TCP/IP. The servers he was still able to connect to were on his local net-
work segment and were running NetBEUI. Since BIGSERVER’s only net-
working protocol is TCP/IP and the workstation’s only protocol was
NetBEUI, they had no common protocol over which they could communi-
cate.
You go back to your station to reassess the company’s practice of

allowing users to be administrators of their own workstations.
Setting Priorities
Since troubles tend to come in threes (or even bigger “gangs”), an impor-
tant step in troubleshooting is to first prioritize the problems themselves,
and then prioritize the factors that affect your efforts to solve them.
Figure 3.13 Ping error message.
91_03.qx 2/25/00 10:59 AM Page 125
126 Chapter 3 • Windows 2000 TCP/IP Troubleshooting Guidelines
Prioritizing the Problems
In categorizing problems, priorities are usually set based on one of two
criteria (or a combination of both):
■
Productivity factors
■
Political factors
The first is easy to understand, and prioritizing problems based on their
effect on productivity is fairly easy to do. It’s obvious that, in general:
1. Problems that affect the entire network are higher priority than
those that affect only a few users.
2. Problems that affect mission-critical activities (such as on-time
delivery of time-sensitive material) are higher priority than those
that affect less urgent activities (such as routine archiving of
data).
3. Problems that are ongoing and worsen with time are higher
priority than those that occur only occasionally and then clear
up on their own.
The second prioritization factor is a bit subtler, and may not be talked
about or even acknowledged. In fact, the “unwritten rules” may be in
direct conflict with the company’s stated policies. Every organization has
its “pecking order” and its internal politics. It might seem that a problem

affecting a whole department of clerks’ ability to access word processing
documents is clearly a higher priority than a problem that prevents one
user from surfing the Web. However, if that one user happens to be the
CEO, who is addicted to his daily dose of online stock market reports and
is in the throes of withdrawal, logical methods of prioritizing may not be
applicable.
Prioritizing the Solutions
When developing possible solutions, you will want to decide what factors
are most important to your company in general, and in this particular
instance. Factors to consider:
Cost. Don’t forget that the immediate monetary outlay to
implement the solution doesn’t tell the whole story in terms of total
cost. You must also consider ongoing associated costs, and
intangibles, just as the time of those who will do the work and the
time lost by those who are unable to work while the network is
down.
Time. This is closely related to cost, and is a potentially high cost
due to loss in productivity. Sometimes the (seemingly) more
91_03.qx 2/25/00 10:59 AM Page 126
Windows 2000 TCP/IP Troubleshooting Guidelines • Chapter 3 127
expensive solution, if it fixes the problem more quickly, is more
cost-effective in the long run.
Longevity. Do you need a long-lasting solution that will solve the
problem permanently, or are you planning to reconfigure the entire
network and install all new equipment three months from now and
you only need a “fix” that will last until then?
Performance. If a more expensive solution also improves overall
performance at the same time it fixes the problem, it may be well
worth the extra expense. Sometimes problems present perfect
upgrade opportunities.

Taking Corrective Measures
Sometimes there will be several available solutions; which one you imple-
ment will depend on many factors, including the priorities you’ve set. In
some cases, the decision will be determined by budgetary restrictions. For
instance, if too many users log on the domain at the same time when
they start work each morning and cause a network slowdown, one solu-
tion is to buy additional servers to act as domain controllers. Another,
less expensive answer might be to stagger the times at which employees’
workdays begin in 15-minute increments.
In other cases, performance or time is the top priority, regardless of
cost.
One Change at a Time
Remember the third commandment: Only implement one change at a
time and assess the effects of that change before trying something else.
This will save you much grief in the long run.
Order of Implementation
It makes sense to try the easiest solutions, the least time-consuming
ones, the less expensive ones, and the least invasive ones first. If a
patient complains of a minor headache, a doctor is likely to have him try
taking a couple of aspirin to see if that relieves the symptom, rather than
starting out with a more drastic treatment, like brain surgery.
Monitoring Results
The last official step in troubleshooting is to assess the results of
your actions, determine whether your “fix” worked, whether it was
91_03.qx 2/25/00 10:59 AM Page 127
128 Chapter 3 • Windows 2000 TCP/IP Troubleshooting Guidelines
only a temporary workaround or actually solved the problem, and what
can be done to prevent the problem from recurring in the future.
The assessment and follow-up stage should also include developing a
succinct summarization of the problem and solution, which may be dis-

seminated to any or all of the following:
Superiors within the company: If the problem had significant or
ongoing impact on the operation of the network, you may need to
submit a report to your supervisors or management personnel.
The affected user(s): One way to prevent problems in the future is
to make them a learning experience for the users (as well as for
you). Educate the users about what happened, inform them of
anything they can do to prevent it from happening, or failing that,
the best course of action for them to take if it does happen.
The hardware or software vendor(s): If the problem indicates a
failure of network hardware or a bug in a software component, you
may want to notify the vendor. Submitting a formal report makes it
more likely the problem and its solutions may be incorporated into
the vendor’s own documentation, such as the Microsoft Knowledge
Base.
Your permanent records: Don’t forget to record the details in your
log or journal, so that if the problem arises again—even if you’ve
been promoted to a high-level upper-management jet-setting
position and are not on hand when it happens—all the information
will be there and time won’t be spent researching or engaging in
the same trial-and-error experimentation all over again.
Using Forms and Check lists
Forms serve a useful purpose by helping you to organize your information
at the same time you’re collecting it. A form that incorporates check lists
can serve as a guideline for your queries, and helps ensure that you don’t
forget something important. It can also speed up the troubleshooting
process. Finally, the form itself can serve as the permanent record of
what happened and how it was addressed.
You can develop your own forms that contain fields specific to your
company and its network, using the following sample form as a starting

point.
91_03.qx 2/25/00 10:59 AM Page 128
Windows 2000 TCP/IP Troubleshooting Guidelines • Chapter 3 129
Network Troubleshooting Information Form
Date: Time:
Person reporting problem:
Name/location of computer displaying problem:
Briefly describe the nature of the problem as specifically as possible:
History–former occurrences of this problem:
Exactly what was being done on the computer when the problem
occurred?
What programs and processes were running when the problem
occurred?
What error messages (if any) were displayed?
Was the computer restarted?
❏ restarted by operator ❏ automatic restart
If the computer was restarted, did it boot into the operating
system normally?
If no, describe any problems, freezes, error messages, or unusual
behavior upon reboot.
Operating system:
Version
Domain/workgroup:
91_03.qx 2/25/00 10:59 AM Page 129
130 Chapter 3 • Windows 2000 TCP/IP Troubleshooting Guidelines
Network Protocols installed (in order of binding):
Network connectivity check:
❏ Network accessible via browse list
❏ Can connect to other computers via UNC path
❏ Can ping loopback

❏ Can ping local host
❏ Can ping another computer on same segment
❏ Can ping near side of router
❏ Can ping far side of router
❏ Can ping host on a remote segment
Error messages encountered in PING attempts:
TCP/IP Configuration check list:
❏ DHCP client
❏ IP address
❏ Subnet mask
❏ Default gateway
❏ DNS primary
Secondary
❏ WINS primary
Secondary
❏ Advanced TCP/IP settings:
❏ MAC address
❏ Protocol Analysis: Tool Used
Results:
Hardware/Physical environment check list:
❏ NIC
❏ Hub(s)
❏ Router(s)
❏ Cables
❏ Power
❏ Temperature
❏ Humidity
❏ EMI/RFI/ESD
91_03.qx 2/25/00 10:59 AM Page 130
Windows 2000 TCP/IP Troubleshooting Guidelines • Chapter 3 131

Antivirus: Updated
Virus check run:
Event Logs: significant entries:
Narrative (in chronological order, describe your response to the
problem):
Diagnosis:
Solution:
Recommended follow-up:
Summary
In this chapter, we covered some general principles of troubleshooting
and problem-solving and discussed ways of applying them to our jobs as
network support professionals.
We discussed the Ten Commandments of Troubleshooting:
1. Know thy network.
2. Use the tools of the trade.
3. Take it one change at a time.
4. Isolate the problem.
5. Recreate the problem.
6. Don’t overlook the obvious.
7. Try the easy way first.
91_03.qx 2/25/00 10:59 AM Page 131
132 Chapter 3 • Windows 2000 TCP/IP Troubleshooting Guidelines
8. Document what you do.
9. Practice the art of patience.
10. Seek help from others.
We discussed the many sources of troubleshooting documentation
available for Windows 2000 administrators, both from Microsoft and from
third parties. We looked at the new and vastly improved Help file system,
and the printed material, online books, and utilities included in the
Microsoft Resource Kits. We talked about MS Press publications, and how

to use both the Web-based and the CD versions of TechNet.
We also looked at the many newsgroups and mailing lists, hosted by
Microsoft and others, that allow Windows 2000 administrators and users
to share their experiences and pool their knowledge. Then we talked
about how to use the World Wide Web as a troubleshooting resource,
including ways of conducting an effective search and how to sort through
this huge global repository of information.
We examined a couple of widely popular problem-solving models, the
Differential Diagnosis model used in medicine and the SARA (Scan,
Analyze, Respond, Assess) model that has become a standard in modern
law enforcement agencies. We discussed the steps involved in the prob-
lem-solving process, and how to apply the principles to network trou-
bleshooting.
We broke each step down into its basic components:
1. Information gathering
2. Problem isolation
3. Taking corrective measures
4. Monitoring results.
We looked at some of the useful troubleshooting tools built into or
included with Windows 2000, such as the System, Application, and
Security logs, and the basic Network Monitor software.
Finally, we discussed the ways in which forms and check lists can
speed up the troubleshooting process and increase our efficiency, and
provided a sample form that network administrators can customize for
use in their own companies.
91_03.qx 2/25/00 10:59 AM Page 132
FAQs
Q: Why is it important to follow a model or set of steps in
troubleshooting?
A: Adopting a problem-solving model and proceeding through the steps

in a methodical manner, in the same order each time, offers several
advantages:
■
It forces you to organize your thoughts.
■
It guides you in asking questions and gathering information.
■
It prevents you from forgetting important steps.
Q: How and why should I attempt to reproduce the problem?
A: You should attempt to reproduce the same problem on the same
machine and on a different machine. This will help you determine
whether the problem is user-specific, machine-specific, or a
networkwide problem.
Q: What are some troubleshooting resources provided by Microsoft for
Windows 2000 and its components?
A: Help files and readme files, online documentation on the Microsoft
Web site (white papers, TechNet and the Knowledge Base, Resource
Link), the Resource Kits, other MS Press publications, and finally
public and private newsgroups.
Q: What are the four basic steps common to all problem-solving models?
A: Information gathering (also called Scanning or Examination); problem
isolation (also referred to as Analysis or Diagnosis); taking corrective
measures (also called Response or Treatment); and monitoring results
(also known as Assessment or Follow-up).
Q: What is a protocol analyzer and why do I need one?
A: A protocol analyzer is a software tool or dedicated hardware device
that actually examines the contents of the packets that travel over the
network. Windows 2000 includes a “light” version of the Network
Monitor software. The fully functional version, which can capture
packets not only from the machine on which it’s installed but also

those sent to and from other machines on the network, is part of
Microsoft’s Systems Management Server.
Windows 2000 TCP/IP Troubleshooting Guidelines • Chapter 3 133
91_03.qx 2/25/00 10:59 AM Page 133
91_03.qx 2/25/00 10:59 AM Page 134
Windows 2000
TCP/IP Internals
Solutions in this chapter:
■
Windows 2000 Enhancements to the
TCP/IP Stack
■
Windows 2000 TCP/IP Architecture
■
IP in Windows 2000
■
TCP and UDP in Windows 2000
■
IPSec
■
TCP/IP Registry Settings
Chapter 4
135
91_tcpip_04.qx 2/25/00 10:57 AM Page 135
136 Chapter 4 • Windows 2000 TCP/IP Internals
Introduction
Microsoft has rewritten and enhanced its TCP/IP stack on several occa-
sions. The protocols that were extensively redesigned for NT 3.5 have
evolved with each improvement to the corporate operating system, and
many new and exciting features have been added in the Windows 2000

implementation.
The focus in Windows 2000 has been on creating a TCP/IP stack that
is scalable, in keeping with Windows 2000’s intended use in enterprise
networks, and one that is versatile, easy to administer, and performs well.
Windows 2000 still supports the features that made the Windows NT
TCP/IP stack easy to work with, such as IP routing and Internet Group
Management Protocol (IGMP), version 2, which supports IP multicasting.
Microsoft has also added new features to make Windows 2000 their most
TCP/IP-friendly operating system yet. TCP/IP is the native network/trans-
port protocol for Windows 2000 and is installed by default when you
install the operating system.
RFC Compliance
The Windows 2000 implementation of Microsoft TCP/IP supports a large
number of RFCs (Requests for Comments) that define various aspects of
how the protocols work. RFCs are used to describe Internet standards,
and go through a formal approval process before being adopted.
Microsoft states that Windows 2000 TCP/IP supports the following
RFCs:
768 User Datagram Protocol (UDP)
783 Trivial File Transfer Protocol (TFTP)
791 Internet Protocol (IP)
792 Internet Control Message Protocol (ICMP)
793 Transmission Control Protocol (TCP)
816 Fault Isolation and Recovery
826 Address Resolution Protocol (ARP)
854 Telnet Protocol (TELNET)
862 Echo Protocol (ECHO)
863 Discard Protocol (DISCARD)
864 Character Generator Protocol (CHARGEN)
865 Quote of the Day Protocol (QUOTE)

867 Daytime Protocol (DAYTIME)
894 IP over Ethernet
91_tcpip_04.qx 2/25/00 10:57 AM Page 136
Windows 2000 TCP/IP Internals • Chapter 4 137
919, 922
IP Broadcast Datagrams (broadcasting with subnets)
950 Internet Standard Subnetting Procedure
959 File Transfer Protocol (FTP)
1001, 1002
NetBIOS Service Protocols
1009 Requirements for Internet Gateways
1034, 1035
Domain Name System (DNS)
1042 IP over Token Ring
1055 Transmission of IP over Serial Lines (IP-SLIP)
1112 Internet Group Management Protocol (IGMP)
1122, 1123
Host Requirements (communications and applications)
1134 Point-to-Point Protocol (PPP)
1144 Compressing TCP/IP Headers for Low-Speed Serial Links
1157 Simple Network Management Protocol (SNMP)
1179 Line Printer Daemon Protocol
1188 IP over FDDI
1191 Path MTU Discovery
1201 IP over ARCNET
1231 IEEE 802.5 Token Ring MIB (MIB-II)
1256 ICMP Router Discovery Messages
1323 TCP Extensions for High Performance
1332 PPP Internet Protocol Control Protocol (IPCP)
1334 PPP Authentication Protocols

1518 An Architecture for IP Address Allocation with CIDR
1519 Classless Inter-Domain Routing (CIDR): An Address
Assignment and Aggregation Strategy
1533 DHCP Options and BOOTP Vendor Extensions
1534 Interoperation Between DHCP and BOOTP
1541 Dynamic Host Configuration Protocol (DHCP)
1542 Clarifications and Extensions for the Bootstrap Protocol
1547 Requirements for Point-to-Point Protocol (PPP)
1548 Point-to-Point Protocol (PPP)
1549 PPP in High-level Data Link Control (HDLC) Framing
1552 PPP Internetwork Packet Exchange Control Protocol (IPXCP)
91_tcpip_04.qx 2/25/00 10:57 AM Page 137
138 Chapter 4 • Windows 2000 TCP/IP Internals
1825 Security Architecture for the Internet Protocol
1826 IP Authentication Header (AH)
1827 IP Encapsulating Security Payload (ESP)
1828 IP Authentication using Keyed MD5
1829 ESP DES-CBC Transform
1851 The ESP Triple DES-CBC Transform
1852 IP Authentication using Keyed SHA
2014 HMAC: Keyed Hashing for Message Authentication
2085 HMAC-MD5 IP Authentication with Replay Prevention
2136 Dynamic Updates in the Domain Name System (DNS UPDATE)
2205 Resource ReSerVation Protocol (RSVP), Version 1 Functional
Specification
2236 Internet Group Management Protocol, Version 2
New standards are, of course, being approved on an ongoing basis,
and we can expect Microsoft to incorporate new RFC specifications into
the TCP/IP stack with subsequent updates.
In this chapter, we will examine more closely some of the RFCs listed

and how they are implemented in Windows 2000. Of special interest are
RFC 1323, TCP Extensions for High Performance, which discusses scala-
ble TCP window sizes; and 1519, which addresses Classless Inter-Domain
Routing (CIDR).
We will also look at the architecture of the Windows 2000 TCP/IP
stack, and how the boundary layers function with the TCP/IP protocols.
We will examine the internals of IP, TCP, and UDP, and then we’ll look at
one of Windows 2000’s most interesting new features: IP Security. Finally,
we’ll talk about how to solve connectivity problems and enhance perform-
ance by making changes to Windows 2000 Registry.
Enhancements to the TCP/IP Stack in
Windows 2000
The most important enhancements that Microsoft has made to the
TCP/IP protocol stack in Windows 2000 have to do with increasing per-
formance. We will look at the operating system’s support for the following,
and how you can use these changes to benefit your TCP/IP network:
■
RFC 1323 TCP extensions: scalable TCP window size and
timestamping
■
Selective Acknowledgments (also called SACK) in accordance
with RFC 2018
91_tcpip_04.qx 2/25/00 10:57 AM Page 138
Windows 2000 TCP/IP Internals • Chapter 4 139
■
Support for IP over ATM (Asynchronous Transfer Mode) as
detailed in RFC 1577
■
TCP Fast Retransmit
■

Quality of Service (QoS)
■
Resource Reservation Protocol (often referred to as RSVP)
■
IPSecurity (IPSec)
■
The Network Driver Interface Specification, version 5.0
How an RFC Becomes
an Internet Standard
RFCs are submitted by any interested party and assigned an RFC num-
ber. Not all RFCs describe standards, but if a document is to become
a standard, it goes through three stages:
Proposed Standard
Draft Standard
Internet Standard
RFC 2226, “Instructions to Authors,” contains information on
how to write and format a draft (called an Internet Draft, or I-D). The
Internet Engineering Steering Group (IESG) then reviews the docu-
ment, which is a part of the Internet Engineering Task Force (IETF).
The IETF’s working groups (WGs) create a large number of the I-Ds.
For more detailed information, see www.ietf.org/home.html.
After review and approval, the document is edited and published.
The RFC editor, employed by the Internet Society, maintains and pub-
lishes a master list of RFCs, and is also responsible for final editing of
the documents. The RFC editor’s homepage is located at www.rfc-
editor.org/.
Technical experts and/or an appointed task force classify each RFC
as one of the following:
Required Status—Must be implemented.
Recommended Status—Encouraged.

Elective Status—May be implemented, but not required.
Limited Use Status—Not intended for general implementation.
Not Recommended Status—Implementation is discouraged.
For IT Professionals
Continued
91_tcpip_04.qx 2/25/00 10:57 AM Page 139
140 Chapter 4 • Windows 2000 TCP/IP Internals
RFC 1323: TCP Extensions for High Performance
RFC 1323, which is available on the Web for you to view at
discusses the specifica-
tions for extensions to TCP, the connection-oriented Transport layer pro-
tocol, which will give better performance over high-speed links. Scalable
TCP windows, which allow for much larger packets than in the past, and
TCP timestamps options are two RFC 1323 features supported by
Windows 2000 that we will look at more closely.
You may notice that at this layer, the packets or “chunks” of data are often
called segments. TCP doesn’t recognize messages as complete units; it
sends a group of bytes, not a complete “message.”
Scalable TCP Window Size
NT administrators are familiar with the concept of sliding windows, the
method used by the TCP protocol to control the flow of data. The sliding
“window,” which is really a buffer, is the amount of data that can be
buffered during a TCP communication.
A buffer is a holding place in memory for data, which allows a device or
process to operate at different speeds or with different rules or priorities
without one being “held back” by the other.
To really understand how sliding windows work, we must look at the
process of establishing a TCP communication with another computer.
For more information about the RFC submission and approval
process, see RFC 2026 at />The RFC editor also provides a search engine at www.rfc-edi-

tor.org/rfcsearch.html, where you can search the master RFC data-
base, download the entire collection of RFCs, and vote for your
favorite RFC.
TIP
NOTE
91_tcpip_04.qx 2/25/00 10:57 AM Page 140
Windows 2000 TCP/IP Internals • Chapter 4 141
The Three-Way Handshake
Computers using TCP to communicate have both a Send window and a
Receive window. At the beginning of a TCP communication, the protocol
uses a three-way handshake to establish the session between the two
computers. Because TCP (unlike its Transport layer “sibling,” UDP) is
connection-oriented, a session, or direct one-to-one communication link,
must be created prior to the sending and receiving of data. The client
computer initiates the communication with the server (the computer
whose resources it wants to access).
The “handshake” includes the following steps:
1. Sending of a SYN (synchronization request) segment by the
client machine. An initial sequence number, sometimes just
referred to as the ISN, is generated by the client and sent to the
server along with the port number the client is requesting to
connect to on the server.
2. Sending of an ACK message and a SYN message back to the
client from the server. The ACK segment is the client’s original
ISN plus 1, and the server’s SYN is an unrelated number
generated by the server itself. The ACK acknowledges the client’s
SYN request, and the server’s SYN indicates the intent to
establish a session with the client. The client and server
machines must synchronize one another’s sequence numbers.
3. Sending of an ACK from the client back to the server,

acknowledging the server’s request for synchronization. This
ACK from the client is, as you might have guessed, the server’s
ISN plus 1. When both machines have acknowledged each
other’s requests by returning ACK messages, the handshake has
been successfully completed and a connection is established
between the two.
See Figure 4.1 for an illustration of how this process works.
For example, in Figure 4.1 the client wishes to establish an SMTP ses-
sion with the server. The client sends a SYN segment that includes an ISN
of 8261457 and the port number 25, which is the well-known port for
Simple Mail Transfer Protocol (SMTP).
The SYN segment’s TCP header will also contain the source port to be used
by the client, and TCP options such as the maximum segment length.
NOTE
91_tcpip_04.qx 2/25/00 10:57 AM Page 141
142 Chapter 4 • Windows 2000 TCP/IP Internals
In the second step, the server receives the SYN segment. It sends back
an ACK message of 8261458. It also sends its own SYN message, with its
own ISN of 2118922.
The client receives the ACK and SYN. It increments the server’s ISN by
1 and returns an ACK of 2118923. At that point, the handshake is com-
plete and the two are ready to “talk.”
In case the concept is still a little muddy, here’s an analogy to help
you understand the process: If you want to establish a one-to-one session
(conversation) over the telephone with your best friend to tell him that
you just got a big promotion and pay raise, you would not just dial up his
number and then announce, “I got the Regional Manager job!” as soon as
someone picked up on the other end. Instead, when the telephone was
answered with “Hello?” you would ask, “Is this Jeff?”
Jeff would then send you an acknowledgment: “Yes,” and a request of

his own, “Mutt, is that you?”
Once you replied in the affirmative, acknowledging Jeff’s message, the
real “session” would be established and you can now send your informa-
tion (“I got the job!”) over this “reliable connection.”
Figure 4.1 The TCP “three-way handshake” that establishes a communication
session.
Client Server
Client Server
Client
Step 1
Step 2
Step 3
SYN segment
SYN segment
ACK message
ACK message
Connection Established!
Server
91_tcpip_04.qx 2/25/00 10:57 AM Page 142
Windows 2000 TCP/IP Internals • Chapter 4 143
One point to remember is that TCP options are sent only in SYN seg-
ments, thus the final step in the handshake (the ACK from the client for
the server’s SYN message).
A similar process occurs when the connection is terminated (sometimes
referred to as session “tear down”). However, it actually requires the
sending of more packets to end the connection than are required to
establish it. Four packets must be sent in order to terminate the connection.
This is because it is a two-way (full duplex) connection and it must be
terminated for each direction separately. The client and server must each
initiate a sequence to close the flow of data originating from its side. The

request to close the connection is called a FIN message. The process works
like this: (1) The client sends a FIN to the server, (2) the server sends an ACK
to the client, (3) the server sends a FIN to the client, and (4) the client
responds with an ACK back to the server. This is sometimes called “four-way
disconnect.” Unlike the opening of the session, the server’s FIN is a separate
transmission that is not part of its ACK of the client’s FIN.
Window Size Negotiation
During the handshake, information is also sent to negotiate the size of
the TCP window, or buffer. The usual procedure is to set the Send win-
dow to the same size as the other computer’s Receive window (the excep-
tion is when the Send window is smaller than the other computer’s
Receive window).
The destination computer first “advertises” a window size, and the
sending computer adjusts its window size to match and sends the data. If
the receiving computer is not able to process the data as quickly as the
other computer sends it, the receiver will acknowledge the data and then
reduce its window size, which signals the sender that it still has data in
the buffer. Once the receiver “catches up,” it will advertise a larger win-
dow size again. Thus the TCP window size is dynamic, changing through-
out the session.
The size of the TCP Receive window on the destination computer limits
how much data the sending computer can transmit before it has to stop
and wait for an acknowledgment from the destination computer. In other
words, the Receive window size (on the destination computer) refers to the
amount of data that is buffered.
NOTE
91_tcpip_04.qx 2/25/00 10:57 AM Page 143
144 Chapter 4 • Windows 2000 TCP/IP Internals
One change in Windows 2000 is default window sizes, which have
been increased for better performance. Here’s how the process works:

1. A Maximum Segment Size (MSS) is negotiated between the
sending and receiving computers during the three-way
handshake that establishes the connection. The Maximum
Segment Size is the maximum number of bytes that can be sent
per TCP transmission (a unit of data that is acknowledged). In
general, a larger MSS will result in faster performance—up to
the point that fragmentation (breaking up of the segment)
occurs.
2. TCP adjusts its Receive window size, instead of using a hard-
coded default size. This is based on even increments of the MSS.
The default segment size is 536 bytes. This is the size used if there is no
MSS set in the TCP options in the SYN message. The MSS can only be as
large as the Maximum Transfer Unit (MTU) for the sending network
interface. If the network is an Ethernet network, the MTU would be up to
1460 bytes. Commonly, the MSS is expressed as a multiple of 512, so it
would be 1024 in most Ethernet-based TCP communications.
When a Windows 2000 computer sends a request for a TCP connec-
tion to another computer, it advertises a 16K Receive window. Then, when
the connection is made, that size gets rounded upward to an even incre-
ment of the MSS. This means that on an Ethernet network, the window
will ordinarily be 17,520 bytes, because that is 16K rounded upward to
12 1460-byte segments.
You can adjust the size of the Receive window to a particular value by
editing the Windows 2000 Registry.
How the Windows Work
In a TCP communication, each packet must be acknowledged. That way,
if a packet fails to arrive at its destination (and thus the receiving com-
puter does not send back an acknowledgment for it), it will be sent again.
That’s why TCP is considered a reliable communication protocol.
NOTE

NOTE
91_tcpip_04.qx 2/25/00 10:57 AM Page 144
Windows 2000 TCP/IP Internals • Chapter 4 145
TCP must provide some method of controlling the “flow” of data trans-
mission when multiple TCP connections have to share a busy link. Flow con-
trol is necessary so that the receiving computer doesn’t get “overwhelmed” by
a sending computer that deluges it with data faster than it can be processed,
or alternately, so that the receiver doesn’t sit around waiting for the data to
“trickle” in. Flow control is the process of matching the outflow of data from
the sending computer to the receiving computer’s inflow. This is done by set-
ting a limit on the number of packets that can be sent before acknowledg-
ment is required, which signals the sender to slow down (or stop and wait) if
data is “piling up” in the receiver’s buffer. If the buffer overflows, data will be
lost and must be retransmitted. Think of flow control as the effective man-
agement of the data flow between devices in a network so that the data can
be handled at an efficient pace.
A real-world example of flow control is the timing of the conveyor belt
in a factory that uses an assembly line. It must be adjusted so that the
outflow at the beginning of the line corresponds to the amount of time it
takes the worker at each station to perform his or her task on each object
before it moves on.
In the TCP communication process, the “window” is those bytes of data
that could be considered active. That is, they’re ready to be sent, or they
have been sent and are awaiting acknowledgment. As acknowledgments are
received, the window “slides” past those bytes, to send additional bytes.
See Figure 4.2 for an illustration of this concept.
A sequence number is added to the data in the Send window by TCP.
The data is passed “down” the protocol stack to IP in the Internetwork
layer, where addressing and routing takes place. There, the TCP segments
are encapsulated in IP datagrams.

A retransmit timer is added to each segment as it is sent. This indi-
cates how long TCP should wait for an acknowledgment before resending
the packet.
NOTE
The sliding window protocol determines how much data is being
transmitted based on actual bytes, rather than segments.
When the packets reach the destination computer and enter its
Receive window, they are put back into proper order based on the
sequence number. When an acknowledgment is received by the sending
computer, the Send window slides past those bytes. If no acknowledgment
is received before the time set in the retransmit timer expires, the sending
computer will send the unacknowledged bytes again.
91_tcpip_04.qx 2/25/00 10:57 AM Page 145
146 Chapter 4 • Windows 2000 TCP/IP Internals
The Receive window moves as the acknowledgments are received. The
bytes within the Send window do not, however, have to be sent immediately
A delayed-ACK timer is started when a destination computer gets the
packets out of sequence. TCP doesn’t always send an acknowledgment
the instant it receives a packet. The ACK can be delayed for up to 200
milliseconds. If the packets that are missing from the sequence aren’t
received before the delayed-ACK timer expires, an acknowledgment will be
sent for the first packet but not the rest of the packets received. This
means that if the retransmit timer is not set to a value greater than the
delayed-ACK timer, there will be unnecessary retransmitting of packets.
Here is an example of how it works: If packets 1 and 3 are received
but packet 2 is missing, TCP will wait, anticipating the arrival of packet 2.
If it does not arrive before the timer expires, TCP will send an ACK for
packet 1 only. If packet 2 still does not arrive, this may cause both pack-
ets 2 and 3 to be retransmitted.
As you can see, resending packets adds to the amount of traffic on the

network. Larger TCP windows will increase network performance on a fast
link. In Windows NT, an acknowledgment is sent after every two
sequenced packets are received. With Windows 2000, with RFC 1323
options enabled, the window size is scalable and larger windows can be
utilized to increase network performance on a high-bandwidth link. This
Figure 4.2 How the TCP windows “slide” as bytes are sent, received, and
acknowledged.
1 2 3 4 5 6 7
TCP sliding "window"
Send Window
Acknowledged
7 6 5 4 3 2 1
Receive Window
91_tcpip_04.qx 2/25/00 10:57 AM Page 146