Guide to TCP/IP, Third Edition

1-4188-3755-5

Chapter 1 Solutions

Answers to Review Questions

1. a, b, c, d

2. c

3. b, c, d

4. d

5. a

6. c

7. c, a, e

8. False

9. d, b, c, g, f, e, a

10. a, b, c, d

11. a, b

12. a, c, d

13. a

14. b, c

15. b, c

16. c, d

17. c

18. b

19. True

20. c

21. d

22. a, b, c, d

23. b

24. a, c

25. a, b, c, d

Guide to TCP/IP, Third Edition

1-4188-3755-5

Hands-on Projects Discussion

Projects 1-1 and 1-2

Because many of the labs in this course require the use of a protocol analyzer, these two Hands-on Projects set the

stage for much of what is to follow throughout the rest of the projects in this book. For that reason, it’s important

to make sure that the software installs and runs properly. If students encounter any difficulties, be sure to offer

assistance, or get help from a qualified network technician. If the protocol analyzer won’t work, make sure the

network interface card (NIC) in the computer can indeed run in promiscuous mode. (If the NIC won’t make that

switch, the software won’t work, period.)

Projects 1-3 and 1-4

In these projects, the students explore the capabilities of the protocol analyzer. First, they perform basic protocol

analyzer tasks, such as capturing basic packet traffic and observing basic display and analysis capabilities on the

trace buffer, including a list of active nodes, a list of protocols observed to be in use, and a list of conversations

observed on the network while data capture is underway. The students also explore the various interface controls

for this software to help them better understand how a protocol analyzer works and what it can do. These projects

are intended to familiarize students with the controls of this important network diagnostic and analysis tool so that

they can use it properly to perform specific tasks in later projects. Make sure they spend the time necessary to

become comfortable with the interface, and familiar with the program’s capabilities.

Projects 1-5 and 1-6

In the final projects for this chapter, students learn to perform basic tasks that are absolutely necessary to

understanding how to use a protocol analyzer on the job (or at least, on a real network). In Hands-on Project 1-5,

students define a basic protocol filter to learn how to invoke pre-defined filters that limit the amount of data that

the protocol analyzer captures and stores. Because the protocol analyzer can capture data only until the trace buffer

is full (or older data must be overwritten with newer data to keep going), students must learn how to reduce the

amount of data they capture to the precise focus of their inquiries or interests. In Hands-on Project 1-6, students

examine the contents of captured packets, as decoded and displayed by the protocol analyzer software. This gives

students their first looks into the precise data structures and organizations that ultimately define what TCP/IP is

and how it works. Students build on this foundation, and learn how to read more into such decodes throughout the

rest of this course.

Guide to TCP/IP, Third Edition

1-4188-3755-5

Case Projects Discussion

Case 1

The correct answer to this question is “at the hub.” On a hub-based network, such as the one described in this Case

Project, all network traffic must transit through the hub as it’s transmitted by any single machine, and then

forwarded to all other machines. Because the hub is the center of this particular networking environment, it’s the

best place to attach the protocol analyzer.

From our experience, based on the scenario described, what’s probably happening is that everyone is attempting to

log on at more or less the same time, and the server is probably choking on downloading all 11 user profiles, logon

scripts, and other startup information, all at once. If the hub itself is congested, one solution is to install a second

hub and a second NIC in the server, then divide the users into two groups—a group of five and a group of six—to

more evenly balance the load between the groups. If the server is overloaded, it may be necessary to beef up that

machine, or add another machine (if the cost can be justified) to balance the load that way.

The simplest solution, however, is to encourage users to arrive at staggered intervals so that all users are not

attempting to log on at the same exact moment!

Case 2

There is a clear surfeit of arguments the students can make here, but any two or three of the following perfectly

correct assertions should do the trick:

1. NetWare 5 (and higher) supports native use of TCP/IP (IPX/SPX is no longer necessary on NetWare 5

networks, and the implementation does not rely on tunneling, as did the NetWare 4 implementation). If

they upgrade to NetWare 5 or higher, they can leave most of the network intact, and still use only

TCP/IP.

2. It’s always harder to manage multiple protocols, and harder to access Internet resources through a

gateway, rather than directly. Switching to TCP/IP does away with IPX/SPX, and makes it more

straightforward for users to access Internet resources.

3. TCP/IP end-to-end permits the use of advanced security features and protocols, such as IP Security

(IPSec), and more advanced virtual private network (VPN) solutions. This can offer a better way to tie

sites together, as well as use the Internet to ferry data between Internet Service Providers (ISPs), rather

than require direct links between sites. Also, TCP/IP-based remote access solutions for traveling staff or

salespeople may work better than IPX/SPX-based alternatives.

4. TCP/IP is inherently better suited for long-haul communications than most other protocols.

5. TCP/IP communications are more robust and reliable than most other forms; a switch to IP-based services

can improve efficiency and reliability in intersite communications.

6. TCP/IP works on nearly every computer platform known to man; IPX/SPX remains primarily a PC-only

phenomenon. Switching to TCP/IP makes it easier to introduce and use Macintosh, UNIX, or Linux

machines, as well as other platforms.

Case 3

One obvious method is to check the protocols list in a protocol analyzer that’s set up to run for a day or longer on

the network during normal load and activity conditions. Even if administrators do not capture much data, the

statistics analysis will compile a list of all the TCP/IP protocols it observes in use on the network. By carefully

reviewing this list, and augmenting it with any other protocols that are only seldom used, administrators can easily

build a minimal protocol list for their UNIX machines with ease.