Senior Acquisitions Editor: Kenyon Brown Development Editor: Kim Wimpsett

Chapter 3

Introduction to TCP/IP

THE FOLLOWING ICND1 EXAM TOPICS ARE

COVERED IN THIS CHAPTER:

Network Fundamentals

1.1 Compare and contrast OSI and TCP/IP models

1.2 Compare and contrast TCP and UDP protocols

1.7 Apply troubleshooting methodologies to resolve problems

1.7.a Perform fault isolation and document

1.7.b Resolve or escalate

1.7.c Verify and monitor resolution

1.9 Compare and contrast IPv4 address types

1.9.a Unicast

1.9.b Broadcast

1.9.c Multicast

1.10 Describe the need for private IPv4 addressing

The Transmission Control Protocol/Internet

Protocol (TCP/IP) suite was designed and implemented by the

Department of Defense (DoD) to ensure and preserve data integrity as

well as maintain communications in the event of catastrophic war. So it

follows that if designed and implemented correctly, a TCP/IP network

can be a secure, dependable and resilient one. In this chapter, I’ll cover

the protocols of TCP/IP, and throughout this book, you’ll learn how to

create a solid TCP/IP network with Cisco routers and switches.

We’ll begin by exploring the DoD’s version of TCP/IP, then compare that

version and its protocols with the OSI reference model that we discussed

earlier.

Once you understand the protocols and processes used at the various

levels of the DoD model, we’ll take the next logical step by delving into

the world of IP addressing and the different classes of IP addresses used

in networks today.

Subnetting is so vital, it will be covered in its own chapter,

Chapter 4, “Easy Subnetting.”

Because having a good grasp of the various IPv4 address types is critical

to understanding IP addressing, subnetting, and variable length subnet

masks (VLSMs), we’ll explore these key topics in detail, ending this

chapter by discussing the various types of IPv4 addresses that you’ll need

to have down for the exam.

I’m not going to cover Internet Protocol version 6 in this chapter because

we’ll get into that later, in Chapter 14, “Internet Protocol Version 6

(IPv6).” And just so you know, you’ll simply see Internet Protocol version

4 written as just IP, rarely as IPv4.

To find up-to-the-minute updates for this chapter, please see

www.lammle.com/ccna

or the book’s web page via

www.sybex.com/go/ccna

.

Introducing TCP/IP

TCP/IP is at the very core of all things networking, so I really want to

ensure that you have a comprehensive and functional command of it. I’ll

start by giving you the whole TCP/IP backstory, including its inception,

and then move on to describe the important technical goals as defined by

its original architects. And of course I’ll include how TCP/IP compares to

the theoretical OSI model.

A Brief History of TCP/IP

TCP first came on the scene way back in 1973, and in 1978, it was divided

into two distinct protocols: TCP and IP. Later, in 1983, TCP/IP replaced

the Network Control Protocol (NCP) and was authorized as the official

means of data transport for anything connecting to ARPAnet, the

Internet’s ancestor. The DoD’s Advanced Research Projects Agency

(ARPA) created this ancient network way back in 1957 in a cold war

reaction to the Soviet’s launching of Sputnik. Also in 1983, ARPA was

redubbed DARPA and divided into ARPAnet and MILNET until both

were finally dissolved in 1990.

It may be counterintuitive, but most of the development work on TCP/IP

happened at UC Berkeley in Northern California, where a group of

scientists were simultaneously working on the Berkeley version of UNIX,

which soon became known as the Berkeley Software Distribution (BSD)

series of UNIX versions. Of course, because TCP/IP worked so well, it

was packaged into subsequent releases of BSD Unix and offered to other

universities and institutions if they bought the distribution tape. So

basically, BSD Unix bundled with TCP/IP began as shareware in the

world of academia. As a result, it became the foundation for the

tremendous success and unprecedented growth of today’s Internet as well

as smaller, private and corporate intranets.

As usual, what started as a small group of TCP/IP aficionados evolved,

and as it did, the US government created a program to test any new

published standards and make sure they passed certain criteria. This was

to protect TCP/IP’s integrity and to ensure that no developer changed

anything too dramatically or added any proprietary features. It’s this very

quality—this open-systems approach to the TCP/IP family of protocols—

that sealed its popularity because this quality guarantees a solid

connection between myriad hardware and software platforms with no

strings attached.

TCP/IP and the DoD Model

The DoD model is basically a condensed version of the OSI model that

comprises four instead of seven layers:

Process/Application layer

Host-to-Host layer or Transport layer

Internet layer

Network Access layer or Link layer

Figure 3.1

offers a comparison of the DoD model and the OSI reference

model. As you can see, the two are similar in concept, but each has a

different number of layers with different names. Cisco may at times use

different names for the same layer, such as both “Host-to-Host” and

Transport” at the layer above the Internet layer, as well as “Network

Access” and “Link” used to describe the bottom layer.

FIGURE 3.1

The DoD and OSI models

When the different protocols in the IP stack are discussed, the

layers of the OSI and DoD models are interchangeable. In other

words, be prepared for the exam objectives to call the Host-to-Host

layer the Transport layer!

A vast array of protocols join forces at the DoD model’s

Process/Application layer. These processes integrate the various

activities and duties spanning the focus of the OSI’s corresponding top

three layers (Application, Presentation, and Session). We’ll focus on a few

of the most important applications found in the CCNA objectives. In

short, the Process/Application layer defines protocols for node-to-node

application communication and controls user-interface specifications.

The Host-to-Host layer or Transport layer parallels the functions of the

OSI’s Transport layer, defining protocols for setting up the level of

transmission service for applications. It tackles issues like creating

reliable end-to-end communication and ensuring the error-free delivery

of data. It handles packet sequencing and maintains data integrity.

The Internet layer corresponds to the OSI’s Network layer, designating

the protocols relating to the logical transmission of packets over the

entire network. It takes care of the addressing of hosts by giving them an

IP (Internet Protocol) address and handles the routing of packets among

multiple networks.

At the bottom of the DoD model, the Network Access layer or Link layer

implements the data exchange between the host and the network. The

equivalent of the Data Link and Physical layers of the OSI model, the

Network Access layer oversees hardware addressing and defines

protocols for the physical transmission of data. The reason TCP/IP

became so popular is because there were no set physical layer

specifications, so it could run on any existing or future physical network!

The DoD and OSI models are alike in design and concept and have

similar functions in similar layers.

Figure 3.2

shows the TCP/IP protocol

suite and how its protocols relate to the DoD model layers.

FIGURE 3.2

The TCP/IP protocol suite

In the following sections, we will look at the different protocols in more

detail, beginning with those found at the Process/Application layer.

The Process/Application Layer Protocols

Coming up, I’ll describe the different applications and services typically

used in IP networks, and although there are many more protocols defined

here, we’ll focus in on the protocols most relevant to the CCNA objectives.

Here’s a list of the protocols and applications we’ll cover in this section:

Telnet

SSH

FTP

TFTP

SNMP

HTTP

HTTPS

NTP

DNS

DHCP/BootP

APIPA

Telnet

Telnet was one of the first Internet standards, developed in 1969, and is

the chameleon of protocols—its specialty is terminal emulation. It allows

a user on a remote client machine, called the Telnet client, to access the

resources of another machine, the Telnet server, in order to access a

command-line interface. Telnet achieves this by pulling a fast one on the

Telnet server and making the client machine appear as though it were a

terminal directly attached to the local network. This projection is actually

a software image—a virtual terminal that can interact with the chosen

remote host. A drawback is that there are no encryption techniques

available within the Telnet protocol, so everything must be sent in clear

text, including passwords!

Figure 3.3

shows an example of a Telnet client

trying to connect to a Telnet server.

FIGURE 3.3

Telnet

These emulated terminals are of the text-mode type and can execute

defined procedures such as displaying menus that give users the

opportunity to choose options and access the applications on the duped

server. Users begin a Telnet session by running the Telnet client software

and then logging into the Telnet server. Telnet uses an 8-bit, byte-

oriented data connection over TCP, which makes it very thorough. It’s

still in use today because it is so simple and easy to use, with very low

overhead, but again, with everything sent in clear text, it’s not

recommended in production.

Secure Shell (SSH)

Secure Shell (SSH) protocol sets up a secure session that’s similar to

Telnet over a standard TCP/IP connection and is employed for doing

things like logging into systems, running programs on remote systems,

and moving files from one system to another. And it does all of this while

maintaining an encrypted connection.

Figure 3.4

shows a SSH client

trying to connect to a SSH server. The client must send the data

encrypted!

You can think of it as the new-generation protocol that’s now used in

place of the antiquated and very unused

rsh

and

rlogin

—even Telnet.

File Transfer Protocol (FTP)

File Transfer Protocol (FTP) actually lets us transfer files, and it can

accomplish this between any two machines using it. But FTP isn’t just a

protocol; it’s also a program. Operating as a protocol, FTP is used by

applications. As a program, it’s employed by users to perform file tasks by

hand. FTP also allows for access to both directories and files and can

accomplish certain types of directory operations, such as relocating into

different ones (

Figure 3.5

).

FIGURE 3.4

Secure Shell

FIGURE 3.5

FTP

But accessing a host through FTP is only the first step. Users must then

be subjected to an authentication login that’s usually secured with

passwords and usernames implemented by system administrators to

restrict access. You can get around this somewhat by adopting the

username anonymous, but you’ll be limited in what you’ll be able to

access.

Even when employed by users manually as a program, FTP’s functions

are limited to listing and manipulating directories, typing file contents,

and copying files between hosts. It can’t execute remote files as programs.

Trivial File Transfer Protocol (TFTP)

Trivial File Transfer Protocol (TFTP) is the stripped-down, stock version

of FTP, but it’s the protocol of choice if you know exactly what you want

and where to find it because it’s fast and so easy to use!

But TFTP doesn’t offer the abundance of functions that FTP does because

it has no directory-browsing abilities, meaning that it can only send and

receive files (

Figure 3.6

). Still, it’s heavily used for managing file systems

on Cisco devices, as I’ll show you in Chapter 7, “Managing a Cisco

Internetwork.”

FIGURE 3.6

TFTP

This compact little protocol also skimps in the data department, sending

much smaller blocks of data than FTP. Also, there’s no authentication as

with FTP, so it’s even more insecure, and few sites support it because of

the inherent security risks.

When Should You Use FTP?

Let’s say everyone at your San Francisco office needs a 50 GB file

emailed to them right away. What do you do? Many email servers

would reject that email due to size limits (a lot of ISPs don’t allow files

larger than 5 MB or 10 MB to be emailed), and even if there are no

size limits on the server, it would still take a while to send this huge

file. FTP to the rescue!

If you need to give someone a large file or you need to get a large file

from someone, FTP is a nice choice. To use FTP, you would need to

set up an FTP server on the Internet so that the files can be shared.

Besides resolving size issues, FTP is faster than email. In addition,

because it uses TCP and is connection-oriented, if the session dies,

FTP can sometimes start up where it left off. Try that with your email

client!

Simple Network Management Protocol (SNMP)

Simple Network Management Protocol (SNMP) collects and manipulates

valuable network information, as you can see in

Figure 3.7

. It gathers

data by polling the devices on the network from a network management

station (NMS) at fixed or random intervals, requiring them to disclose

certain information, or even asking for certain information from the

device. In addition, network devices can inform the NMS station about

problems as they occur so the network administrator is alerted.

FIGURE 3.7

SNMP

When all is well, SNMP receives something called a baseline—a report

delimiting the operational traits of a healthy network. This protocol can

also stand as a watchdog over the network, quickly notifying managers of

any sudden turn of events. These network watchdogs are called agents,

and when aberrations occur, agents send an alert called a trap to the

management station.

SNMP Versions 1, 2, and 3

SNMP versions 1 and 2 are pretty much obsolete. This doesn’t mean

you won’t see them in a network now and then, but you’ll only come

across v1 rarely, if ever. SNMPv2 provided improvements, especially

in performance. But one of the best additions was called GETBULK,

which allowed a host to retrieve a large amount of data at once. Even

so, v2 never really caught on in the networking world and SNMPv3 is

now the standard. Unlike v1, which used only UDP, v3 uses both TCP

and UDP and added even more security, message integrity,

authentication, and encryption.

Hypertext Transfer Protocol (HTTP)

All those snappy websites comprising a mélange of graphics, text, links,

ads, and so on rely on the Hypertext Transfer Protocol (HTTP) to make it

all possible (

Figure 3.8

). It’s used to manage communications between

web browsers and web servers and opens the right resource when you

click a link, wherever that resource may actually reside.

FIGURE 3.8

HTTP

In order for a browser to display a web page, it must find the exact server

that has the right web page, plus the exact details that identify the

information requested. This information must be then be sent back to the

browser. Nowadays, it’s highly doubtful that a web server would have

only one page to display!

Your browser can understand what you need when you enter a Uniform

Resource Locator (URL), which we usually refer to as a web address, such

as, for example,

http://www.lammle.com/forum

and

http://www.lammle.com/blog

.

So basically, each URL defines the protocol used to transfer data, the

name of the server, and the particular web page on that server.

Hypertext Transfer Protocol Secure (HTTPS)

Hypertext Transfer Protocol Secure (HTTPS) is also known as Secure

Hypertext Transfer Protocol. It uses Secure Sockets Layer (SSL).

Sometimes you’ll see it referred to as SHTTP or S-HTTP, which were

slightly different protocols, but since Microsoft supported HTTPS, it

became the de facto standard for securing web communication. But no

matter—as indicated, it’s a secure version of HTTP that arms you with a

whole bunch of security tools for keeping transactions between a web

browser and a server secure.

It’s what your browser needs to fill out forms, sign in, authenticate, and

encrypt an HTTP message when you do things online like make a

reservation, access your bank, or buy something.

Network Time Protocol (NTP)

Kudos to Professor David Mills of the University of Delaware for coming

up with this handy protocol that’s used to synchronize the clocks on our

computers to one standard time source (typically, an atomic clock).

Network Time Protocol (NTP) works by synchronizing devices to ensure

that all computers on a given network agree on the time (

Figure 3.9

).

This may sound pretty simple, but it’s very important because so many of

the transactions done today are time and date stamped. Think about

databases—a server can get messed up pretty badly and even crash if it’s

out of sync with the machines connected to it by even mere seconds! You

can’t have a transaction entered by a machine at, say, 1:50 a.m. when the

server records that transaction as having occurred at 1:45 a.m. So

basically, NTP works to prevent a “back to the future sans DeLorean”

scenario from bringing down the network—very important indeed!

FIGURE 3.9

NTP

I’ll tell you a lot more about NTP in Chapter 7, including how to configure

this protocol in a Cisco environment.

Domain Name Service (DNS)

Domain Name Service (DNS) resolves hostnames—specifically, Internet

names, such as

www.lammle.com

. But you don’t have to actually use

DNS. You just type in the IP address of any device you want to

communicate with and find the IP address of a URL by using the Ping

program. For example,

>ping

www.cisco.com

will return the IP address

resolved by DNS.

An IP address identifies hosts on a network and the Internet as well, but

DNS was designed to make our lives easier. Think about this: What would

happen if you wanted to move your web page to a different service

provider? The IP address would change and no one would know what the

new one is. DNS allows you to use a domain name to specify an IP

address. You can change the IP address as often as you want and no one

will know the difference.

To resolve a DNS address from a host, you’d typically type in the URL

from your favorite browser, which would hand the data to the Application

layer interface to be transmitted on the network. The application would

look up the DNS address and send a UDP request to your DNS server to

resolve the name (

Figure 3.10

).

If your first DNS server doesn’t know the answer to the query, then the

DNS server forwards a TCP request to its root DNS server. Once the

query is resolved, the answer is transmitted back to the originating host,

which means the host can now request the information from the correct

web server.

DNS is used to resolve a fully qualified domain name (FQDN)—for

example,

www.lammle.com

or

todd.lammle.com

. An FQDN is a hierarchy

that can logically locate a system based on its domain identifier.

If you want to resolve the name todd, you either must type in the FQDN

of

todd.lammle.com

or have a device such as a PC or router add the suffix

for you. For example, on a Cisco router, you can use the command

ip

domain-name lammle.com

to append each request with the

lammle.com

domain. If you don’t do that, you’ll have to type in the FQDN to get DNS

to resolve the name.

FIGURE 3.10

DNS

An important thing to remember about DNS is that if you can

ping a device with an IP address but cannot use its FQDN, then you

might have some type of DNS configuration failure.

Dynamic Host Configuration Protocol (DHCP)/Bootstrap Protocol

(BootP)

Dynamic Host Configuration Protocol (DHCP) assigns IP addresses to

hosts. It allows for easier administration and works well in small to very

large network environments. Many types of hardware can be used as a

DHCP server, including a Cisco router.

DHCP differs from BootP in that BootP assigns an IP address to a host

but the host’s hardware address must be entered manually in a BootP

table. You can think of DHCP as a dynamic BootP. But remember that

BootP is also used to send an operating system that a host can boot from.

DHCP can’t do that.

But there’s still a lot of information a DHCP server can provide to a host

when the host is requesting an IP address from the DHCP server. Here’s a

list of the most common types of information a DHCP server can provide:

IP address

Subnet mask

Domain name

Default gateway (routers)

DNS server address

WINS server address

A client that sends out a DHCP Discover message in order to receive an

IP address sends out a broadcast at both layer 2 and layer 3.

The layer 2 broadcast is all Fs in hex, which looks like this:

ff:ff:ff:ff:ff:ff.

The layer 3 broadcast is 255.255.255.255, which means all networks

and all hosts.

DHCP is connectionless, which means it uses User Datagram Protocol

(UDP) at the Transport layer, also known as the Host-to-Host layer,

which we’ll talk about later.

Seeing is believing, so here’s an example of output from my analyzer

showing the layer 2 and layer 3 broadcasts:

Ethernet II, Src: 0.0.0.0 (00:0b:db:99:d3:5e),Dst:

Broadcast(ff:ff:ff:ff:ff:ff)

Internet Protocol, Src: 0.0.0.0 (0.0.0.0),Dst:

255.255.255.255(255.255.255.255)

The Data Link and Network layers are both sending out “all hands”

broadcasts saying, “Help—I don’t know my IP address!”

DHCP will be discussed in more detail, including

configuration on a Cisco router and switch, in Chapter 7, “Managing a

Cisco Internetwork,” and Chapter 9, “IP Routing.”

Figure 3.11

shows the process of a client/server relationship using a

DHCP connection.