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

occa-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 enterprisenetworks, and one that is versatile, easy to

This is where you configure the maximum amount of disk space thelog can occupy, and what should occur when the limit is reached Youcan also clear the log here, with the click of a button.

You can also filter the events in a specified log When you archive thelog, 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 inyour “diagnosis” and plan a “cure” for the problem

Perhaps the most important tool for a network troubleshooter is agood protocol analyzer To really learn what’s going on with the network,you have to examine the packets themselves This requires not only thatyou have a good analyzer, but that you learn how to use it

There are many types available, from stand-alone and handhelddevices to software-only solutions

Microsoft’s Network Monitor (often referred to as ”NetMon”) is a goodtool for analyzing Windows-based networks A big advantage is that abasic 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 sentfrom 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 NetworkMonitor, which is part of Microsoft’s System Management Server

In Chapter 4, we will discuss in detail how to use NetMon and othernetwork 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 largeamount of information gathered from your investigative sources (results

of monitoring and analysis equipment, users’ answers to questions, andyour own personal observations), determine which bits are relevant andwhich can be discarded (in any thorough investigation, there will always

be much more “data” than useful “information”), and use the rest to puttogether the pieces of the puzzle and solve the mystery

NOTE

One of your objectives during this phase is to look for patterns Hasthis problem occurred here before? Do the “symptoms” match somethingyou’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 andpick out the key facts.

Organizing and Analyzing the InformationThis step may be done on paper, on screen, or in your head, but it isimportant that you sort through all the random facts and numbers you’vegathered to determine which facts support which theories (and whichwould tend to negate which theories, too) In its simplest form, theprocess 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 amixed-mode domain)

Figure 3.12 The Microsoft Network Monitor included with

Windows 2000 Server

Given that information, what are some scenarios that could cause theproblem? 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 upand running You’ve eliminated one possibility Another is that

BIGSERVER’s network card has malfunctioned, a cable has loosened, orsomething else has caused the server to become disconnected from thenetwork

You continue your investigation by trying to access BIGSERVER fromyour own workstation You are able to ping the server with no problemusing its IP address You have eliminated another possibility: you nowknow that BIGSERVER is connected to the network And since you canping 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 userdidn’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, anddecided that it must be specific to the complaining user’s workstation.You go to that computer, which is running NT Workstation, and questionthe 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 isunable 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 tions, but don’t know whether it’s a browse issue, a name resolutionissue, or a TCP/IP connectivity issue

configura-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 workingproperly because you were able to ping from your own workstation Now you open a command prompt, attempting to ping BIGSERVER andreproduce the problem When you type “ping 192.168.1.2” at the commandline, you receive the message shown in Figure 3.13

This error indicates that something is wrong with the TCP/IP stack.

You get the same message when you attempt to ping the loopbackaddress, 127.0.0.1 That convinces you that TCP/IP is not working Youopen the local area connection’s Properties box and discover that TCP/IP

is not installed on the machine Upon further questioning, the user tellsyou that he uninstalled the protocol from “another connection.” He points

to the connection icon for the VPN, assuring you that he didn’t changeanything on the local area connection

You sigh and explain that uninstalling the protocol from one tion removes it from all of them that use that network card, and you rein-stall and reconfigure TCP/IP BIGSERVER magically reappears The userasks you why he was still able to “see” the other servers, and you showhim that the NetBEUI protocol was still installed after he removedTCP/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 wasNetBEUI, they had no common protocol over which they could communi-cate

connec-You go back to your station to reassess the company’s practice ofallowing users to be administrators of their own workstations

Setting PrioritiesSince 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.

Prioritizing the Problems

In categorizing problems, priorities are usually set based on one of twocriteria (or a combination of both):

■ Productivity factors

■ Political factorsThe first is easy to understand, and prioritizing problems based on theireffect on productivity is fairly easy to do It’s obvious that, in general:

1 Problems that affect the entire network are higher priority thanthose that affect only a few users

2 Problems that affect mission-critical activities (such as on-timedelivery of time-sensitive material) are higher priority than thosethat affect less urgent activities (such as routine archiving ofdata)

3 Problems that are ongoing and worsen with time are higherpriority 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 talkedabout or even acknowledged In fact, the “unwritten rules” may be indirect 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 processingdocuments is clearly a higher priority than a problem that prevents oneuser from surfing the Web However, if that one user happens to be theCEO, 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 beapplicable

Prioritizing the Solutions

When developing possible solutions, you will want to decide what factorsare most important to your company in general, and in this particularinstance 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 totalcost You must also consider ongoing associated costs, and

intangibles, just as the time of those who will do the work and thetime lost by those who are unable to work while the network isdown

Time This is closely related to cost, and is a potentially high cost

due to loss in productivity Sometimes the (seemingly) more

expensive solution, if it fixes the problem more quickly, is morecost-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 entirenetwork and install all new equipment three months from now andyou 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 wellworth the extra expense Sometimes problems present perfectupgrade opportunities

Taking Corrective Measures

Sometimes there will be several available solutions; which one you ment will depend on many factors, including the priorities you’ve set Insome cases, the decision will be determined by budgetary restrictions Forinstance, if too many users log on the domain at the same time whenthey 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

imple-In other cases, performance or time is the top priority, regardless ofcost

One Change at a TimeRemember the third commandment: Only implement one change at atime 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-consumingones, the less expensive ones, and the least invasive ones first If apatient complains of a minor headache, a doctor is likely to have him trytaking a couple of aspirin to see if that relieves the symptom, rather thanstarting out with a more drastic treatment, like brain surgery

Monitoring Results

The last official step in troubleshooting is to assess the results ofyour actions, determine whether your “fix” worked, whether it was

only a temporary workaround or actually solved the problem, and whatcan be done to prevent the problem from recurring in the future.

The assessment and follow-up stage should also include developing asuccinct 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 tosubmit 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 foryou) Educate the users about what happened, inform them ofanything 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, youmay want to notify the vendor Submitting a formal report makes itmore likely the problem and its solutions may be incorporated intothe vendor’s own documentation, such as the Microsoft KnowledgeBase

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’vebeen promoted to a high-level upper-management jet-settingposition and are not on hand when it happens—all the informationwill be there and time won’t be spent researching or engaging inthe 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 listscan serve as a guideline for your queries, and helps ensure that you don’tforget something important It can also speed up the troubleshootingprocess Finally, the form itself can serve as the permanent record ofwhat happened and how it was addressed

You can develop your own forms that contain fields specific to yourcompany and its network, using the following sample form as a startingpoint

Network Troubleshooting Information Form

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:

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:

❏ Advanced TCP/IP settings:

Antivirus: Updated Virus check run:

Event Logs: significant entries:

Narrative (in chronological order, describe your response to the problem):

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

8 Document what you do.

9 Practice the art of patience

10 Seek help from others

We discussed the many sources of troubleshooting documentationavailable for Windows 2000 administrators, both from Microsoft and fromthird parties We looked at the new and vastly improved Help file system,and the printed material, online books, and utilities included in theMicrosoft 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 byMicrosoft and others, that allow Windows 2000 administrators and users

to share their experiences and pool their knowledge Then we talkedabout how to use the World Wide Web as a troubleshooting resource,including ways of conducting an effective search and how to sort throughthis huge global repository of information

We examined a couple of widely popular problem-solving models, theDifferential Diagnosis model used in medicine and the SARA (Scan,

Analyze, Respond, Assess) model that has become a standard in modernlaw 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:

Finally, we discussed the ways in which forms and check lists canspeed up the troubleshooting process and increase our efficiency, andprovided a sample form that network administrators can customize foruse in their own companies

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 severaladvantages:

■ 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 determinewhether the problem is user-specific, machine-specific, or anetworkwide 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, ResourceLink), the Resource Kits, other MS Press publications, and finallypublic 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 correctivemeasures (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 thenetwork Windows 2000 includes a “light” version of the NetworkMonitor software The fully functional version, which can capturepackets not only from the machine on which it’s installed but alsothose sent to and from other machines on the network, is part ofMicrosoft’s Systems Management Server

Windows 2000 TCP/IP Internals

Solutions in this chapter:

Microsoft has rewritten and enhanced its TCP/IP stack on several sions The protocols that were extensively redesigned for NT 3.5 haveevolved with each improvement to the corporate operating system, andmany new and exciting features have been added in the Windows 2000implementation

occa-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 enterprisenetworks, and one that is versatile, easy to administer, and performs well.Windows 2000 still supports the features that made the Windows NTTCP/IP stack easy to work with, such as IP routing and Internet GroupManagement Protocol (IGMP), version 2, which supports IP multicasting.Microsoft has also added new features to make Windows 2000 their mostTCP/IP-friendly operating system yet TCP/IP is the native network/trans-port protocol for Windows 2000 and is installed by default when youinstall the operating system

RFC Compliance

The Windows 2000 implementation of Microsoft TCP/IP supports a largenumber of RFCs (Requests for Comments) that define various aspects ofhow 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 followingRFCs:

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

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)

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 2New standards are, of course, being approved on an ongoing basis,and we can expect Microsoft to incorporate new RFC specifications intothe TCP/IP stack with subsequent updates

In this chapter, we will examine more closely some of the RFCs listedand how they are implemented in Windows 2000 Of special interest areRFC 1323, TCP Extensions for High Performance, which discusses scala-ble TCP window sizes; and 1519, which addresses Classless Inter-DomainRouting (CIDR)

We will also look at the architecture of the Windows 2000 TCP/IPstack, 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 atone 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 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:

per-■ RFC 1323 TCP extensions: scalable TCP window size andtimestamping

■ Selective Acknowledgments (also called SACK) in accordancewith RFC 2018

■ Support for IP over ATM (Asynchronous Transfer Mode) asdetailed in RFC 1577

■ TCP Fast Retransmit

■ Quality of Service (QoS)

■ Resource Reservation Protocol (often referred to as RSVP)

RFC 2226, “Instructions to Authors,” contains information onhow to write and format a draft (called an Internet Draft, or I-D) TheInternet 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 lishes a master list of RFCs, and is also responsible for final editing ofthe documents The RFC editor’s homepage is located at www.rfc-editor.org/

pub-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

RFC 1323: TCP Extensions for High Performance

RFC 1323, which is available on the Web for you to view at

http://freesoft.org/CIE/RFC/1323/index.htm, discusses the tions for extensions to TCP, the connection-oriented Transport layer pro-tocol, which will give better performance over high-speed links ScalableTCP windows, which allow for much larger packets than in the past, andTCP timestamps options are two RFC 1323 features supported by

specifica-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, themethod 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 bebuffered during a TCP communication

A buffer is a holding place in memory for data, which allows a device orprocess to operate at different speeds or with different rules or prioritieswithout one being “held back” by the other

To really understand how sliding windows work, we must look at theprocess of establishing a TCP communication with another computer

For more information about the RFC submission and approvalprocess, see RFC 2026 at ftp://ftp.isi.edu/in-notes/rfc2026.txt

The RFC editor also provides a search engine at tor.org/rfcsearch.html, where you can search the master RFC data-base, download the entire collection of RFCs, and vote for yourfavorite RFC

www.rfc-edi-TIP

NOTE

The Three-Way Handshake

Computers using TCP to communicate have both a Send window and aReceive 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 clientcomputer initiates the communication with the server (the computerwhose 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 theserver along with the port number the client is requesting toconnect 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 numbergenerated by the server itself The ACK acknowledges the client’sSYN request, and the server’s SYN indicates the intent to

establish a session with the client The client and servermachines 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’sISN plus 1 When both machines have acknowledged eachother’s requests by returning ACK messages, the handshake hasbeen successfully completed and a connection is establishedbetween 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 sion with the server The client sends a SYN segment that includes an ISN

ses-of 8261457 and the port number 25, which is the well-known port forSimple 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

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 itsown 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 plete and the two are ready to “talk.”

com-In case the concept is still a little muddy, here’s an analogy to helpyou understand the process: If you want to establish a one-to-one session(conversation) over the telephone with your best friend to tell him thatyou just got a big promotion and pay raise, you would not just dial up hisnumber and then announce, “I got the Regional Manager job!” as soon assomeone picked up on the other end Instead, when the telephone wasanswered with “Hello?” you would ask, “Is this Jeff?”

Jeff would then send you an acknowledgment: “Yes,” and a request ofhis own, “Mutt, is that you?”

Once you replied in the affirmative, acknowledging Jeff’s message, thereal “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

ACK message

Connection Established!

Server

One point to remember is that TCP options are sent only in SYN ments, thus the final step in the handshake (the ACK from the client forthe server’s SYN message).

seg-A similar process occurs when the connection is terminated (sometimesreferred 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 beterminated for each direction separately The client and server must eachinitiate a sequence to close the flow of data originating from its side Therequest to close the connection is called a FIN message The process workslike 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 clientresponds with an ACK back to the server This is sometimes called “four-waydisconnect.” Unlike the opening of the session, the server’s FIN is a separatetransmission 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 ofthe 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’sReceive window)

The destination computer first “advertises” a window size, and thesending computer adjusts its window size to match and sends the data Ifthe receiving computer is not able to process the data as quickly as theother computer sends it, the receiver will acknowledge the data and thenreduce its window size, which signals the sender that it still has data inthe 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 limitshow much data the sending computer can transmit before it has to stopand wait for an acknowledgment from the destination computer In otherwords, the Receive window size (on the destination computer) refers to theamount of data that is buffered

NOTE

One change in Windows 2000 is default window sizes, which havebeen increased for better performance Here’s how the process works:

1 A Maximum Segment Size (MSS) is negotiated between thesending and receiving computers during the three-wayhandshake that establishes the connection The MaximumSegment Size is the maximum number of bytes that can be sentper TCP transmission (a unit of data that is acknowledged) Ingeneral, a larger MSS will result in faster performance—up tothe point that fragmentation (breaking up of the segment)occurs

2 TCP adjusts its Receive window size, instead of using a coded default size This is based on even increments of the MSS

hard-The default segment size is 536 bytes This is the size used if there is noMSS set in the TCP options in the SYN message The MSS can only be aslarge as the Maximum Transfer Unit (MTU) for the sending networkinterface 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 itwould be 1024 in most Ethernet-based TCP communications

When a Windows 2000 computer sends a request for a TCP tion to another computer, it advertises a 16K Receive window Then, whenthe connection is made, that size gets rounded upward to an even incre-ment of the MSS This means that on an Ethernet network, the windowwill ordinarily be 17,520 bytes, because that is 16K rounded upward to

connec-12 1460-byte segments

You can adjust the size of the Receive window to a particular value byediting 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 puter does not send back an acknowledgment for it), it will be sent again.That’s why TCP is considered a reliable communication protocol

com-NOTE

NOTE

TCP must provide some method of controlling the “flow” of data 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

trans-a sending computer thtrans-at deluges it with dtrans-attrans-a ftrans-aster thtrans-an it ctrans-an 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 fromthe 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) ifdata is “piling up” in the receiver’s buffer If the buffer overflows, data will belost 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 theoutflow at the beginning of the line corresponds to the amount of time ittakes the worker at each station to perform his or her task on each objectbefore it moves on

In the TCP communication process, the “window” is those bytes of datathat could be considered active That is, they’re ready to be sent, or theyhave been sent and are awaiting acknowledgment As acknowledgments arereceived, 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 Internetworklayer, where addressing and routing takes place There, the TCP segmentsare 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 resendingthe packet

is received before the time set in the retransmit timer expires, the sendingcomputer will send the unacknowledged bytes again

The Receive window moves as the acknowledgments are received Thebytes 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 acknowledgmentthe instant it receives a packet The ACK can be delayed for up to 200milliseconds If the packets that are missing from the sequence aren’treceived before the delayed-ACK timer expires, an acknowledgment will besent for the first packet but not the rest of the packets received Thismeans that if the retransmit timer is not set to a value greater than thedelayed-ACK timer, there will be unnecessary retransmitting of packets.Here is an example of how it works: If packets 1 and 3 are receivedbut 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 forpacket 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 thenetwork Larger TCP windows will increase network performance on a fastlink In Windows NT, an acknowledgment is sent after every two

sequenced packets are received With Windows 2000, with RFC 1323options enabled, the window size is scalable and larger windows can beutilized to increase network performance on a high-bandwidth link This

Figure 4.2 How the TCP windows “slide” as bytes are sent, received, and

speeds up the transfer of data on networks that are built on fast mediaand can take advantage of the feature.

The delayed ACK timer is set and used by the destination computer The

sending computer uses something called a retransmission timer when it is

anticipating an ACK At the time it sends the TCP segment, the sendingcomputer starts a retransmit timer based on the Roundtrip Time (RTT) This

is not a set time, but varies depending on the speed of the connection andother factors If no ACK is sent back before the retransmit timer expires, thedata will be re-sent With all of these safeguards in place to ensure thatevery segment sent arrives at the destination computer, you can begin tosee why TCP is called a “reliable” protocol

How Flow Control Works

For best performance, a large number of unacknowledged packets would

be allowed to remain outstanding—as long as the number is not so largethat some packets are dropped by the routers because of the overcrowd-ing When packets are dropped, they will be re-sent, increasing the overalltraffic on the network and resulting in a performance hit TCP handlesthis by starting with a smaller window size, then if no packets are lost,increasing the size until there is some loss of packets detected, and “scal-ing back” the size of the Send window to balance speed of transfer withamount of available bandwidth

At first, the Send window size will be set to equal one MaximumSegment Size If an acknowledgment is received, the next transmissionwill be equal to two MSS, and will be increased by one MSS per acknowl-edged segment, each time the transmission is acknowledged So, if thetwo MSS transmission is acknowledged, the next will be four MSS, and so

on As long as the acknowledgments keep coming back and the windowdoes not exceed the maximum allowed window size (set in the Registry’sTcpWindowSize parameter as we will discuss a little later in this chapter),the process will continue As you can see, the size of the window increas-

es exponentially This goes on until the maximum window threshold isreached

When that happens, the window will continue to grow as long asacknowledgments are received, but it will grow at a linear rate instead of

an exponential one After the threshold is reached, the window will

NOTE

increase by one in each RTT for which a whole window’s worth of

acknowledgements is received

At some point, the transmission rate becomes so fast that the linkbecomes congested somewhere along the way and a timeout will finallyoccur The sender will not receive the acknowledgment before the timerexpires, and when this happens, TCP will adjust the threshold value toone-half the size of the window at that time The window size itself will bereset to one MSS The sending computer will start over again with theprocess of increasing the window size as acknowledgments are received,and the whole process will repeat itself

Negotiating Scaling Factors

Windows 2000 supports scalable TCP windows, in accordance with RFC

1323 By “scalable,” we mean the window size can be larger on networksthat use high-speed links; thus, TCP windows can adjust to best fit theparticular network’s needs When this support is implemented, the TCPprotocol can negotiate a scaling factor during the three-way handshake.The Window Scale option is sent in the SYN segment, and tells the receiv-ing computer that the sending computer will support scaling

This does not automatically mean window scaling will occur Thereceiving computer must also return a Window Scale option in its SYNsegment Window scaling is enabled only if both computers send WindowScale options—scaling is an all-or-nothing proposition (i.e., scaling iseither enabled in both directions or not at all)

The Window Scale option can be sent in the SYN segment sent by acomputer that is originating a TCP connection It can be sent in theacknowledgment segment returned by the receiving computer that includesits own SYN bit, but only if the original SYN segment it is responding toincluded a Window Scale option

Finding the Scale Factor

To find out what the scale factor is, you can examine the packets thatcreated the connection (the three-way handshake) in Network Monitor or

a similar protocol analysis tool This will appear as “TCP Option Type =Window Scale” with the option length and the scale factor shown after

If the TcpWindowSize value in the Registry, which sets the limit on themaximum TCP Receive window size that will be offered, is specified as

NOTE

more than 64K, Windows 2000 will normally use window scaling (unlessyou specifically disable it) This setting is found at:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interface

\<network interface name>

See Figure 4.3 for an illustration of the new Registry value

Figure 4.3 Create a new DWORD type value and set it to the number of bytes to

specify the maximum TCP Receive window size

Remember that this setting should be an even increment of the MSS,

as discussed previously

This setting controls only the specific network interface selected Youcan also set a global value, for all interfaces, by creating a value calledGlobalMaxTcpWindowSize However, if an interface has a specific setting,

it will override the global one

Even if a value of more than 64K is set, it will only be used when necting to another system that also is capable of and configured to sup-port the RFC 1323 options

con-This parameter is not visible by default You must create it The value is ofthe REG_DWORD type, and the value should be entered as a number inbytes

TIP

Disabling Scaling in Windows 2000

To disable scaling, you must create and set the value for another Registrykey, Tcp1323Opts

As with the TcpWindowSize key, you must use a Registry Editor such

as regedt32 and navigate to the same Tcp\Parameters subkey Create anew REG_DWORD value called Tcp1323Opts and set the value to 0 or 2,according to the following:

0 = disables both RFC 1323 options (window scaling and timestamping)

1 = enables window scaling only

2 = enables timestamping only

3 = enables both RFC 1323 options

If you disable window scaling, the maximum TCP window size will belimited to 64K

Timestamping is especially useful when TCP connections are usinglarge windows, to help TCP determine the RTT This information is need-

ed so the protocol can adjust timeout times for the retransmission timer,which optimizes

The reason timestamping is more important in communications thatuse the large window size is because the traditional way of measuring theRTT, which involves sampling of only one packet per window, gives a rea-sonable approximation when the window size is small, but the more pack-ets there are in the buffer, the larger the margin of error becomes

Consequently, a more accurate method of measurement is needed

How Timestamping Works

Using the RFC 1323 option of timestamping, the sending computer puts atimestamp in the header of the TCP packets This header is 10 bytes longand includes a 1-byte field designating the “kind,” (that is, showing thatthis header is a timestamp), a 1-byte field showing length, and two 4-bytetimestamp fields: Timestamp Value (which shows the present value indi-cated by the sending computer’s clock at the time of sending) and

Timestamp Echo Reply (the value indicated by the receiving computer’sclock when it sends the acknowledgment) See Figure 4.4 for an illustra-tion of the TCP timestamps option header.

Figure 4.4 A TCP header showing the fields used to indicate the timestamp

Valid only if the TCP segment

is an ACK

Present value shown by sender's clock

Present value shown by receiver's clock

In Figure 4.4, the first field with the value of 8 tells us this is a stamp header; the second field shows a value of 10, indicating the totallength of the header; and the next two fields show us the values of thesender’s and receiver’s clocks, respectively The value of the receiver’sclock is shown only in an ACK message

time-The receiving computer reflects the timestamps back when it sends anacknowledgment The sending computer can then subtract the value in itsoriginal header from the value in the acknowledgment segment, and thisprovides an accurate RTT for every ACK The timestamp values are

obtained from a virtual clock referred to as the timestamp clock.

RFC 1323 specifies that timestamping should always be used when largewindow sizes (more than 64K) are used, and timestamps should be sentand echoed in both directions

TIP

If a large window size is used, ensuring that timestamping is enabledwill solve TCP instability problems caused by inaccurate RTT estimates,

which can lead to a condition called congestion collapse This occurs

when there are a great many undelivered packets on a busy TCP/IP work, and connections timeout

net-Timestamping is enabled in Windows 2000 by default, although it can

be disabled as shown by setting the Registry value Tcp1323Opts to 0 or 1

RFC 2018: SACK (Selective Acknowledgment)

Selective Acknowledgment, also called SACK, is another feature that will

enhance performance when large window sizes are used With Windows

2000, Microsoft introduces support for this feature, which is discussed inRFC 2018 As with timestamping, SACK uses TCP headers, which aresent in a SYN segment

In standard TCP transmission, if several packets are lost from onewindow’s worth of data, the sending computer only finds out about onelost packet per RTT This means the lost packets will be slow to be

retransmitted Alternately, if the sender is aggressive about resending, itmay resend packets that have actually been received and don’t need to beretransmitted, thus adding unnecessary network traffic

The purpose of the SACK option is to send additional acknowledgmentinformation in a SACK option that is included in a segment from thereceiving computer, about dropped packets or out-of-sequence packets.This information tells the sending computer exactly which packets werereceived and which are missing When the connection is established, a

“SACK permitted” option must be included in the SYN message to enablethis feature

The benefit of SACK is that it allows the sending machine to resendonly the data that was not received, and avoids congesting the networkwith unnecessary retransmittal of packets that were already received IfSACK has been enabled in the SYN message, SACK options will be includ-

ed in all ACKs that don’t acknowledge the highest sequence number that

is in the receiving computer’s buffer This situation indicates that datahas been lost or was received out of sequence, and the receiving computer

is missing some segments

You will recall that normally, this situation causes both the missingsegment and those following it to be retransmitted SACK is called

“Selective” because it allows the sending computer to retransmit only theselected segments that were not received

SACK is enabled by default in Windows 2000 It can, however, be abled by editing the Tcpip\Parameters\SackOpts value in the Registry

dis-This is a DWORD Boolean value type, which is set to 0 to disable SACKsupport or 1 to enable it.

SACK can be very useful in solving performance slowdowns caused bylost packets or duplicate sending of packets on connections using largeTCP windows

NOTE

The SACK header can be sent only on SYN (synchronization) segments You

should never find it on non-SYN segments

RFC 1577: IP over ATMAnother new feature in Windows 2000 is its support for the standards setforth in RFC 1577, which discusses operation of the Internet Protocol (IP)

on a network based on Asynchronous Transfer Mode (ATM) technology

ATM has several advantages, including its ability to work well on veryhigh-speed networks, and its flexibility, allowing the client to control theaccuracy and speed of the data transfer Other characteristics of ATMinclude:

■ Connection-oriented transmission Ethernet and Token Ring

are connectionless technologies that depend on protocols in thehigher layers to provide synchronization, acknowledgment, etc

■ No inherent limits on speed of transmission As speed

increases in an Ethernet network, maximum segment lengthdecreases, thereby effectively placing a cap on realisticattainable speeds that may be higher or lower depending on themedia used

■ Quality of service The end points in an ATM communication

negotiate a “contract” that specifies a guaranteed quality ofservice; this is not done in traditional technologies such asEthernet and Token Ring

Because of the high bandwidth that is possible using ATM, it isemerging as a popular technology However, ATM networks differ frommore traditional LAN technologies, like Ethernet, in that ATM is a non-broadcast technology This presents a challenge in regard to physicaladdress resolution In a broadcast-based network, clients use ARP broad-casts to resolve IP addresses to the physical addresses (called MAC

addresses in Ethernet and Token Ring networks)

When IP is run over ATM technology, there must be some means ofresolving those IP addresses to ATM (physical) addresses The solution is

to set up an Address Resolution server (or ARP server) with special ARPserver software, to which clients connect by being configured with theATM address of the server This works a little like WINS does in resolving

IP addresses to NetBIOS names in that when a client computer comesonline, it connects to its ARP server and sends its IP address and ATMaddress to be entered into the server’s database Then, when the clientwants to connect to another ARP client, it can query the ARP server forthe other client’s ATM address

NOTE

ATM switching technology provides a dedicated connection, breaking up data

into fixed-length packets that are called cells and are always exactly 53 bytes.

ATM uses digital signaling and can achieve high transmission speeds (currently155.520 Mbps or 622.080 Mbps; however up to 10 Gbps is possible)

Windows 2000 supports this means of address resolution, andWindows 2000 machines can be configured as ATM ARP clients or ATMARP servers via the Registry The ARP client parameters are found in thenetwork interface’s TCP/IP parameters By editing the values in the

AtmArpC subkey, you can specify such settings as the timeout for ATMaddress resolution, maximum number of resolution attempts, how longthe client will wait after a negative response from the ARP server beforetrying again, and other specifications

To edit this value, use a Registry editing tool to set the parameters inthe Registry at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\<interface name>\AtmArpC

ATM is implemented via hardware, as a replacement for Ethernet orToken Ring, and the components in an ATM network must support ATM.This makes ATM expensive, which is the primary reason it has not yetbeen implemented more widely

ATM can use LANE (LAN emulation) software to provide support fortraditional LAN applications and protocols LANE causes the ATM network

to appear as an Ethernet LAN to the higher-level protocols and applications.This is a way to increase performance of TCP/IP, but doesn’t give you thefull benefits of ATM, such as Quality of Service guarantees

NOTE

RFC 2001: TCP Fast RetransmitYou will remember that the TCP protocol is connection-oriented anddepends on an acknowledgment from the receiving computer to verify thatall packets arrived at their destination—if no ACK is received, the computerthat originally sent the data will retransmit it At the time the packet ishanded down to the IP protocol at the Network layer, a retransmissiontimer is started, and when the time expires, if no ACK has come back,TCP resends that packet However, this can lead to long periods in which

no data is transmitted because TCP is waiting for the retransmissiontimer to expire

Windows 2000 supports a feature called fast retransmit, discussed in

RFC 2001, which allows TCP to resend the data before the specifiedretransmission time has expired Here’s how and why that happens:

If a packet arrives at the destination computer with an out-of-ordersequence number (for instance, the next expected packet would be num-ber 7, but the computer receives number 8), the receiver will send anACK for the missing packet number 7, as well as for the packet number 8that was received If number 9 then arrives next, the receiving computersends another ACK for number 7 as well as for packet 9 This continues

as long as higher-sequenced packets arrive and number 7 is still missing,

and the acknowledgments are called Duplicate ACKs.

Normally, of course, only one ACK is sent per packet So when thecomputer that originally sent the data starts receiving multiple acknowl-edgments for packet number 7, this tells it that packet 7 must have beenlost Then, the sending computer will resend packet number 7, even if theretransmission timer has not yet expired for that packet See Figure 4.5for a graphical representation of how this works

Of course, fast retransmit doesn’t replace the use of retransmissiontimers; it merely supplements them, enhancing TCP performance

TCP on the sending side has no way of knowing whether a duplicate ACKwas sent because of a lost segment or if the segments just got out of order

To resend in the latter case would add to network congestion, so TCP waitsuntil several duplicate ACKs have been received

In Windows 2000’s implementation of TCP, the maximum number ofduplicate acknowledgments is set to 3 by default (as specified in RFC 2001),

so whenever a sending computer receives the third ACK for the samesequence number, and that number is lower than the number of the packet

it last sent, it will retransmit the packet that is “missing in action.”

You can change this value by specifying a different number in theTcpMaxDupAcks value in the Tcpip\parameters Registry key

NOTE

It is estimated that on the average network, fast retransmit canimprove throughput by up to 20 percent Remember that in order for it towork, both the sending and receiving computers must support this fea-ture.

RFCs 2211 and 2212: Quality of Service

QoS, or Quality of Service, is another feature supported by Windows 2000that was not supported by NT 4.0 A way that network applications canreserve bandwidth between the client and server is by using an extension

to the Winsock API called General Quality of Service, or GQOS What itdoes is provide an application interface to the Resource ReservationProtocol (RSVP), which is discussed in the next section

Together, QoS and RSVP are used by the application to deliver a flow

of data from client to server, with the assurance that necessary width will be available Obviously, this is useful for high-bandwidth appli-cations such as video or high-quality audio

band-If a certain amount of bandwidth is necessary to maintain quality that

is acceptable (for instance, if you need to be able to rely on having 1.5

Figure 4.5 With fast retransmit, a packet is resent after three duplicate ACKS

ACK 6 ACK 8

packet 9

packet 10 ACK 9 ACK 7

ACK 10 ACK 7

packet 7

Mbps in order to transmit video that is not jerky or otherwise tory), the application can send a “flow specification” both for sending andreceiving at the time it is initialized This can be specified as “guaran-teed,” or a lower level of assurance such as “best effort.” The specifica-tions are sent to GQOS, which then works in conjunction with RSVP tomake a “reservation.”

unsatisfac-RFC 2211 discusses controlled-load service, and specifications forguaranteed QoS are addressed in RFC 2212 Clients that request controlled-load service provide an estimate of the amount of data traffic they willgenerate Acceptance of a request for controlled-load service is defined toimply a commitment by the network element to provide the requestor withservice closely equivalent to that provided to uncontrolled (best-effort)traffic under lightly-loaded conditions

RFC 2205: Resource Reservation ProtocolAfter the flow specification parameters, which include latency limits, delayvariations, and peak bandwidth, go to GQOS, RSVP is invoked via an APIcall It sends special “path messages” to the destination IP address (theone to which the data will be sent) These messages signal the routersalong the path, and they assess their available resources and decidewhether they can accept the “reservation.” If all routers respond positive-

ly, the application is assured of having the needed bandwidth for the nection

con-RSVP functions as an Internet control protocol (like ICMP) It is alsosimilar to a routing protocol in that it executes in the background

However, it is not a routing protocol itself, but works in conjunction withrouting protocols The routing protocols specify where the packets go,while RSVP only addresses the QoS of the packets RSVP resides on top

of IP, and will work with both IPv4 and IPv6 It also works with both cast and multicast transmissions

uni-An RSVP request reserves bandwidth resources in only one direction

NOTE

NOTE

The Internet Protocol Security protocol (IPSec) is yet another of Windows2000’s new features, and one that Microsoft has made a big “sellingpoint” for the new operating system Security has become a major con-cern for more and more network professionals, as once-private networkshave become joined by their connections to the global Internet It isbeyond the scope of this chapter to fully discuss the intricacies of IPSec,

but for more information, see the book Configuring Windows 2000 Server

Security, published by Syngress Media.

Microsoft provides a great deal of documentation for the Windows 2000implementation of IPSec An excellent general overview is available in the

Internet Protocol Security technical notes article published in TechNet Also

see the Windows 2000 Server Resource Kit for further information

Purpose and Uses of IPSec

The purpose of IPSec is to protect an IP-based network from ping, IP spoofing, denial of service and other “hack attacks.” IPSec offersprotection of individual IP packets, and provides a general first line ofdefense against security breaches It is especially useful with virtual pri-vate networking protocols (Point-to-Point Tunneling Protocol and LayerTwo Tunneling Protocol, supported by Windows 2000), allowing for end-to-end security

eavesdrop-End-to-end security methods are those in which it is necessary only for the

“endpoint” computers (the machine from which the data originates andthe final destination computer) to be aware of and support the IPSecprotocols The assumption is that the link connecting the two is not secure,thus the sender and receiver both handle security at their ends The

advantage of this is that IPSec can be implemented in a variety of scenarioswithout the requirement that systems along the data path be IPSec-

enabled

TIP

NOTE