The CompTIA Network+ certification challenges you to understand virtually every aspect of networking—not a small task. Networking professionals use one of two methods to conceptualize the many parts of a network: the Open Systems Interconnection (OSI) seven-layer model and the Transmission Control Protocol/Internet Protocol (TCP/IP) model.

These models provide two tools that make them essential for networking techs. First, the OSI and TCP/IP models provide powerful mental tools for diagnosing problems. Understanding the models enables a tech to determine quickly at what layer a problem can occur and helps him or her zero in on a solution without wasting a lot of time on false leads. Second, these models provide a common language techs use to describe specific network functions. Figure 1-1 shows product information for a Cisco-branded advanced networking device. Note the use of the terms “L3” and “layer 7.” These terms directly reference the OSI seven-layer model. Techs who understand the OSI model understand what those numbers mean, giving them a quick understanding of what the device provides to a network.

Figure 1-1 Using OSI terminology in device documentation

This chapter looks first at models in general and how models help conceptualize and troubleshoot networks. The chapter then explores both the OSI seven-layer model and the TCP/IP model to see how they help clarify network architecture for techs.

Cisco and Certifications

Cisco Systems, Inc. is famous for making many of the “boxes” that interconnect networks all over the world. It’s not too far of a stretch to say that Cisco helps power a huge portion of the Internet. These boxes are complicated to configure, requiring a high degree of technical knowledge.

To address this need, Cisco offers a series of certifications. The entry-level certification, for example, is the Cisco Certified Entry Networking Technician (CCENT). The next step is the Cisco Certified Network Associate (CCNA) Routing and Switching.

Go to Cisco’s certification Web site and compare the objectives for the two certifications with what you learned about CompTIA Network+ in the “Introduction” of this book. Ask yourself this question: could you study for CCENT or CCNA R&S and CompTIA Network+ simultaneously?

Historical/Conceptual

Working with Models

Networking is hard. It takes a lot of pieces, both hardware and software, all working incredibly quickly and in perfect harmony, to get anything done. Just making Google appear in your Web browser requires millions of hours in research, development, and manufacturing to create the many pieces to successfully connect your system to a server somewhere in Googleland and to enable them to communicate. Whenever we encounter highly complex technologies, we need to simplify the overall process by breaking it into discrete, simple, individual processes. We do this using a network model.

Biography of a Model

What does the word “model” mean to you? Does the word make you think of a beautiful woman walking down a catwalk at a fashion show or some hunky guy showing off the latest style of blue jeans on a huge billboard? Maybe it makes you think of a plastic model airplane? What about those computer models that try to predict weather? We use the term “model” in a number of ways, but each use shares certain common themes.

All models are a simplified representation of the real thing. The human model ignores the many different types of body shapes, using only a single “optimal” figure. The model airplane lacks functional engines or the internal framework, and the computerized weather model might disregard subtle differences in wind temperatures or geology (Figure 1-2).

Figure 1-2 Types of models (images from left to right courtesy of NOAA, Mike Schinkel, and Michael Smyer)

Additionally, a model must have at least all the major functions of the real item, but what constitutes a major rather than a minor function is open to opinion. Figure 1-3 shows a different level of detail for a model. Does it contain all the major components of an airplane? There’s room for argument that perhaps the model should have landing gear to go along with the propeller, wings, and tail.

Figure 1-3 Simple model airplane

Network Models

Network models face similar challenges. What functions define all networks? What details can you omit without rendering the model inaccurate? Does the model retain its usefulness when describing a network that does not employ all the layers?

In the early days of networking, different manufacturers made unique types of networks that functioned well. Part of the reason they worked was that every network manufacturer made everything. Back then, a single manufacturer provided everything for a customer when the customer purchased a network solution: all the hardware and all the software in one complete and expensive package. Although these networks worked fine as stand-alone networks, the proprietary nature of the hardware and software made it difficult—to put it mildly—to connect networks of multiple manufacturers. To interconnect networks and therefore improve the networking industry, someone needed to create a guide, a model, that described the functions of a network. Using this model, the people who made hardware and software could work together to make networks that worked together well.

Two models tend to stand out: the OSI model and the TCP/IP model. The OSI model is covered on the CompTIA Network+ exam. The TCP/IP model is not on the exam but it is common and important and you should know it. Let’s look at both.

NOTE  The International Organization for Standardization (ISO) created the OSI seven-layer model. ISO may look like a misspelled acronym, but it’s actually a word, derived from the Greek word isos, which means “equal.” The International Organization for Standardization sets standards that promote equality among network designers and manufacturers, thus ISO.

The best way to learn the OSI and TCP/IP models is to see them in action. For this reason, I’ll introduce you to a small network that needs to copy a file from one computer to another. This example goes through each of the OSI and TCP/IP layers needed to copy that file, and I explain each step and why it is necessary. By the end of the chapter, you should have a definite handle on using either of these models as a tool to conceptualize networks. You’ll continue to build on this knowledge throughout the book and turn your OSI and TCP/IP model knowledge into a powerful troubleshooting tool.

The OSI Seven-Layer Model in Action

Each layer in the OSI seven-layer model defines an important function in computer networking, and the protocols that operate at that layer offer solutions to those functions. Protocols are sets of clearly defined rules, regulations, standards, and procedures that enable hardware and software developers to make devices and applications that function properly at a particular layer. The OSI seven-layer model encourages modular design in networking, meaning that each layer has as little to do with the operation of other layers as possible. Think of it as an automobile assembly line. The guy painting the car doesn’t care about the gal putting doors on the car—he expects the assembly line process to make sure the cars he paints have doors. Each layer on the model trusts that the other layers on the model do their jobs.

The OSI seven layers are

•  Layer 7 Application

•  Layer 6 Presentation

•  Layer 5 Session

•  Layer 4 Transport

•  Layer 3 Network

•  Layer 2 Data Link

•  Layer 1 Physical

The OSI seven layers are not laws of physics—anybody who wants to design a network can do it any way he or she wants. Although many protocols fit neatly into one of the seven layers, others do not.

EXAM TIP  Be sure to memorize both the name and the number of each OSI layer. Network techs use OSI terms such as “Layer 4” and “Transport layer” synonymously. Students have long used mnemonics for memorizing such lists. One of my favorites for the OSI seven-layer model is “Please Do Not Throw Sausage Pizza Away.” Yum! Another great mnemonic that helps students to memorize the layers from the top down is “All People Seem To Need Data Processing.” Go with what works for you.

Now that you know the names of the layers, let’s see what each layer does. The best way to understand the OSI layers is to see them in action. Let’s see them at work at the fictional company of MHTechEd, Inc.

NOTE  This section is a conceptual overview of the hardware and software functions of a network. Your network may have different hardware or software, but it will share the same functions.

Welcome to MHTechEd!

Mike’s High-Tech Educational Supply Store and Post Office, or MHTechEd for short, has a small network of PCs running Windows, a situation typical of many small businesses today. Windows runs just fine on a PC unconnected to a network, but it also comes with all the network software it needs to connect to a network. All the computers in the MHTechEd network are connected by special network cabling.

As in most offices, virtually everyone at MHTechEd has his or her own PC. Figure 1-4 shows two workers, Janelle and Dana, who handle all the administrative functions at MHTechEd. Because of the kinds of work they do, these two often need to exchange data between their two PCs. At the moment, Janelle has just completed a new employee handbook in Microsoft Word, and she wants Dana to check it for accuracy. Janelle could transfer a copy of the file to Dana’s computer by the tried-and-true Sneakernet method—saving the file on a flash drive and walking it over to her—but thanks to the wonders of computer networking, she doesn’t even have to turn around in her chair. Let’s watch in detail each piece of the process that gives Dana direct access to Janelle’s computer, so she can copy the Word document from Janelle’s system to her own.

Figure 1-4 Janelle and Dana, hard at work

Long before Janelle ever saved the Word document on her system—when the systems were first installed—someone who knew what they were doing set up and configured all the systems at MHTechEd to be part of a common network. All this setup activity resulted in multiple layers of hardware and software that can work together behind the scenes to get that Word document from Janelle’s system to Dana’s. Let’s examine the different pieces of the network, and then return to the process of Dana grabbing that Word document.

Test Specific

Let’s Get Physical—Network Hardware and Layers 1–2

Clearly the network needs a physical channel through which it can move bits of data between systems. Most networks use a cable like the one shown in Figure 1-5. This cable, known in the networking industry as unshielded twisted pair (UTP), usually contains four pairs of wires that can transmit and receive data.

Figure 1-5 UTP cabling

Another key piece of hardware the network uses is a special box-like device that handles the flow of data from each computer to every other computer (Figure 1-6). This box is often tucked away in a closet or an equipment room. (The technology of the central box has changed over time. For now, let’s just call it the “central box.” I’ll get to variations in a bit.) Each system on the network has its own cable that runs to the central box. Think of the box as being like one of those old-time telephone switchboards, where operators created connections between persons who called in wanting to reach other telephone users.

Figure 1-6 Typical central box

Layer 1 of the OSI model defines the method of moving data between computers, so the cabling and central box are part of the Physical layer (Layer 1). Anything that moves data from one system to another, such as copper cabling, fiber optics, even radio waves, is part of the OSI Physical layer. Layer 1 doesn’t care what data goes through; it just moves the data from one system to another system. Figure 1-7 shows the MHTechEd network in the OSI seven-layer model thus far. Note that each system has the full range of layers, so data from Janelle’s computer can flow to Dana’s computer. (I’ll cover what a “hub” is shortly.)

Figure 1-7 The network so far, with the Physical layer hardware installed

The real magic of a network starts with the network interface card, or NIC (pronounced “nick”), which serves as the interface between the PC and the network. While NICs come in a wide array of shapes and sizes, the ones at MHTechEd look like Figure 1-8.

Figure 1-8 Typical NIC

On older systems, a NIC truly was a separate card that snapped into a handy expansion slot, which is why they were called network interface cards. Even though they’re now built into the motherboard, they are still called NICs.

When installed in a PC, the NIC looks like Figure 1-9. Note the cable running from the back of the NIC into the wall; inside that wall is another cable running all the way back to the central box.

Figure 1-9 NIC with cable connecting the PC to the wall jack

Cabling and central boxes define the Physical layer of the network, and NICs provide the interface to the PC. Figure 1-10 shows a diagram of the network cabling system. I’ll build on this diagram as I delve deeper into the network process.

Figure 1-10 The MHTechEd network

You might be tempted to categorize the NIC as part of the Physical layer at this point, and you’d have a valid argument. The NIC clearly is necessary for the physical connection to take place. Many authors put the NIC in OSI Layer 2, the Data Link layer, though, so clearly something else is happening inside the NIC. Let’s take a closer look.

The NIC

To understand networks, you must understand how NICs work. The network must provide a mechanism that gives each system a unique identifier—like a telephone number—so data is delivered to the right system. That’s one of the NIC’s most important jobs. Inside every NIC, burned onto some type of ROM chip, is special firmware containing a unique identifier with a 48-bit value called the media access control address, or MAC address.

No two NICs ever share the same MAC address—ever. Any company that makes NICs must contact the Institute of Electrical and Electronics Engineers (IEEE) and request a block of MAC addresses, which the company then burns into the ROMs on its NICs. Many NIC makers also print the MAC address on the surface of each NIC, as shown in Figure 1-11. Note that the NIC shown here displays the MAC address in hexadecimal notation. Count the number of hex characters—because each hex character represents 4 bits, it takes 12 hex characters to represent 48 bits. MAC addresses are always written in hex.

Figure 1-11 MAC address

Hexadecimal Aside

A hexadecimal numbering system uses base 16 for representing numbers—that would be 0–15 (in base 10 values). Contrast this with the more common decimal numbering system, numbered 0–9. Just as with decimal, people who work with hexadecimal need a single character to represent each number for the 16 values. Using 0–9 makes sense, but then hex is represented in letter form for the values 10–15 (A, B, C, D, E, F).

Hexadecimal works great with binary. Four bits provide the values of 0–15. 0001, for example, is the value 1; 1000 in binary is 8; 1111 is 15. When we work with MAC addresses, it’s far easier to break each 4-bit section of the 48-bit address and translate that into hex. Humans work better that way!

Back to MAC Addresses

The MAC address in Figure 1-11 is 004005-607D49, although in print, we represent the MAC address as 00–40–05–60–7D–49. The first six digits, in this example 00–40–05, represent the number of the NIC manufacturer. Once the IEEE issues those six hex digits to a manufacturer—referred to as the Organizationally Unique Identifier (OUI)—no other manufacturer may use them. The last six digits, in this example 60–7D–49, are the manufacturer’s unique serial number for that NIC; this portion of the MAC is often referred to as the device ID.

Would you like to see the MAC address for your NIC? If you have a Windows system, type ipconfig /all from a command prompt to display the MAC address (Figure 1-12). Note that ipconfig calls the MAC address the physical address, which is an important distinction, as you’ll see a bit later in the chapter. (For macOS, type ifconfig from a terminal; for Linux, type ip a from a terminal to get similar results.)

Figure 1-12 Output from ipconfig /all

MAC-48 and EUI-48

The IEEE forms MAC addresses from a numbering name space originally called MAC-48, which simply means that the MAC address will be 48 bits, with the first 24 bits defining the OUI, just as described here. The current term for this numbering name space is EUI-48. EUI stands for Extended Unique Identifier. (IEEE apparently went with the new term because they could trademark it.)

Most techs just call them MAC addresses, as you should, but you might see MAC-48 or EUI-48 on the CompTIA Network+ exam.

Okay, so every NIC in the world has a unique MAC address, but how is it used? Ah, that’s where the fun begins! Recall that computer data is binary, which means it’s made up of streams of ones and zeroes. NICs send and receive this binary data as pulses of electricity, light, or radio waves. The NICs that use electricity to send and receive data were the originals, so let’s consider that type of NIC. The specific process by which a NIC uses electricity to send and receive data is exceedingly complicated but, luckily for you, not necessary to understand. Instead, just think of a charge on the wire as a one and no charge as a zero. A chunk of data moving in pulses across a wire might look something like Figure 1-13.

Figure 1-13 Data moving along a wire

If you put an oscilloscope on the wire to measure voltage, you’d see something like Figure 1-14. An oscilloscope is a powerful tool that enables you to see electrical pulses.

Figure 1-14 Oscilloscope of data

Now, remembering that the pulses represent binary data, visualize instead a string of ones and zeroes moving across the wire (Figure 1-15).

Figure 1-15 Data as ones and zeroes

Once you understand how data moves along the wire, the next question is, how does the network get the right data to the right system? All networks transmit data by breaking whatever is moving across the Physical layer (files, print jobs, Web pages, and so forth) into discrete chunks called frames. A frame is basically a container for a chunk of data moving across a network. A frame encapsulates—puts a wrapper around—information and data for easier transmission. (More on this later in the chapter.) The NIC creates and sends, as well as receives and reads, these frames.

NOTE  The unit of data specified by a protocol at each layer of the OSI seven-layer model is called a protocol data unit (PDU). A frame is the PDU for Layer 2.

I like to visualize an imaginary table inside every NIC that acts as a frame creation and reading station. I see frames as those pneumatic canisters you see when you go to a drive-in teller at a bank. A little guy inside the network card—named Nick, of course—builds these pneumatic canisters (the frames) on the table and then shoots them out on the wire to the central box (Figure 1-16).

Figure 1-16 Inside the NIC

NOTE  Different frame types are used in different networks. All NICs on the same network must use the same frame type, or they will not be able to communicate with other NICs.

Here’s where the MAC address becomes important. Figure 1-17 shows a representation of a generic frame, a simplified version of the most common wired network technology, called Ethernet. (Chapter 3 covers Ethernet in great detail. For now just go with the frame described here as a generic wired thing.)

Figure 1-17 Generic frame

Even though a frame is a string of ones and zeroes, we often draw frames as a series of rectangles, each rectangle representing a part of the string of ones and zeroes. You will see this type of frame representation used quite often, so you should become comfortable with it (even though I still prefer to see frames as pneumatic canisters).

Note that the frame begins with the MAC address of the NIC to which the data is to be sent, followed by the MAC address of the sending NIC. Next comes the Type field, which indicates what’s encapsulated in the frame. Then comes the Data field that contains what’s encapsulated, followed by a special bit of checking information called the frame check sequence (FCS). The FCS uses a type of binary math called a cyclic redundancy check (CRC) that the receiving NIC uses to verify that the data arrived intact.

You can think of a frame in a different way as having three sections. The header (MAC addresses and Type) starts, followed by the payload (whatever is encapsulated in the frame); this is followed by the trailer (the FCS).

So, what’s inside the data part of the frame? You neither know nor care. The data may be a part of a file, a piece of a print job, or part of a Web page. NICs aren’t concerned with content! The NIC simply takes whatever data is passed to it via its device driver and addresses it for the correct system. Special software will take care of what data gets sent and what happens to that data when it arrives. This is the beauty of imagining frames as little pneumatic canisters (Figure 1-18). A canister can carry anything from dirt to diamonds—the NIC doesn’t care one bit (pardon the pun).

Figure 1-18 Frame as a canister

Like a canister, a frame can hold only a certain amount of data. Different types of networks use different sizes of frames, but the frames used in most wired networks hold at most 1500 bytes of data. This raises a new question: what happens when the data to be sent is larger than the frame size? Well, the sending system’s software must chop the data up into nice, frame-sized chunks, which it then hands to the NIC for sending. As the receiving system begins to accept the incoming frames, the receiving system’s software recombines the data chunks as they come in from the network. I’ll show how this disassembling and reassembling is done in a moment—first, let’s see how the frames get to the right system!

Into the Central Box

When a system sends a frame out on the network, the frame goes into the central box. What happens next depends on the technology of the central box.

In the early days of networking, the central box was called a hub. A hub was a dumb device, essentially just a repeater. When it received a frame, the hub made an exact copy of that frame, sending a copy of the original frame out of all connected ports except the port on which the message originated.

The interesting part of this process was when the copy of the frame came into all the other systems. I like to visualize a frame sliding onto the receiving NIC’s “frame assembly table,” where the electronics of the NIC inspected it. (This doesn’t exist; use your imagination!) Here’s where the magic took place: only the NIC to which the frame was addressed would process that frame—the other NICs simply dropped it when they saw that it was not addressed to their MAC address. This is important to appreciate: with a hub, every frame sent on a network was received by every NIC, but only the NIC with the matching MAC address would process that frame (Figure 1-19).

Figure 1-19 Incoming frame!

Later networks replaced the hub with a smarter device called a switch. Switches, as you’ll see in much more detail as we go deeper into networking, filter traffic by MAC address. Rather than sending all incoming frames to all network devices connected to it, a switch sends the frame only to the interface associated with the destination MAC address.

FCS in Depth

All FCSs are only 4 bytes long, yet the wired frame carries at most 1500 bytes of data. How can 4 bytes tell you if all 1500 bytes in the data are correct? That’s the magic of the math of the CRC. Without going into the grinding details, think of the CRC as just the remainder of a division problem. (Remember learning remainders from division back in elementary school?) The NIC sending the frame does a little math to make the CRC. Using binary arithmetic, it works a division problem on the data using a divisor called a key. The result of this division is the CRC. When the frame gets to the receiving NIC, it divides the data by the same key. If the receiving NIC’s answer is the same as the CRC, it knows the data is good; if it’s not good, the frame is dropped.

Getting the Data on the Line

The process of getting data onto the wire and then picking that data off the wire is amazingly complicated. For instance, what would happen to keep two NICs from speaking at the same time? Because all the data sent by one NIC is read by every other NIC on the network, only one system could speak at a time in early wired networks. Networks use frames to restrict the amount of data a NIC can send at once, giving all NICs a chance to send data over the network in a reasonable span of time. Dealing with this and many other issues requires sophisticated electronics, but the NICs handle these issues completely on their own without our help. Thankfully, the folks who design NICs worry about all these details, so we don’t have to!

Getting to Know You

Using the MAC address is a great way to move data around, but this process raises an important question. How does a sending NIC know the MAC address of the NIC to which it’s sending the data? In most cases, the sending system already knows the destination MAC address because the NICs had probably communicated earlier, and each system stores that data. If it doesn’t already know the MAC address, a NIC may send a broadcast onto the network to ask for it. The MAC address of FF-FF-FF-FF-FF-FF is the Layer 2 broadcast address—if a NIC sends a frame using the broadcast address, every single NIC on the network will process that frame. That broadcast frame’s data will contain a request for a system’s MAC address. Without knowing the MAC address to begin with, the requesting computer will use an IP address to pick the target computer out of the crowd. The system with the MAC address your system is seeking will read the request in the broadcast frame and respond with its MAC address. (See “IP—Playing on Layer 3, the Network Layer” later in this chapter for more on IP addresses and packets.)

The Complete Frame Movement

Now that you’ve seen all the pieces used to send and receive frames, let’s put these pieces together and see how a frame gets from one system to another. The basic send/receive process is as follows.

First, the sending system’s operating system hands some data to its NIC. The NIC builds a frame to transport that data to the receiving NIC (Figure 1-20).

Figure 1-20 Building the frame

After the NIC creates the frame, it adds the FCS, and then dumps it and the data into the frame (Figure 1-21).

Figure 1-21 Adding the data and FCS to the frame

Next, the NIC puts both the destination MAC address and its own MAC address onto the frame. It then sends the frame through the cable to the network (Figure 1-22).

Figure 1-22 Sending the frame

NOTE  Any frame addressed specifically to another device’s MAC address is called a unicast frame. The one-to-one addressing scheme is called unicast addressing; you’ll see it in other layers as well as Layer 2.

The frame propagates down the wire into the central box. The switch sends unicast frames to the destination address and sends broadcast frames to every system on the network. The NIC receives the frame (Figure 1-23). The NIC strips off all the framing information and sends the data to the software—the operating system—for processing. The receiving NIC doesn’t care what the software does with the data; its job stops the moment it passes on the data to the software.

Figure 1-23 Reading an incoming frame

Any device that deals with a MAC address is part of the OSI Data Link layer, or Layer 2 of the OSI model. Let’s update the OSI model to include details about the Data Link layer (Figure 1-24).

Figure 1-24 Layer 1 and Layer 2 are now properly applied to the network.

Note that the cabling and hubs are in the Physical layer. Switches handle traffic using MAC addresses, so they operate at Layer 2. That’s the way modern wired networks work. The NIC is in the Data Link layer and the Physical layer.

The Two Aspects of NICs

Consider how data moves in and out of a NIC. On one end, frames move into and out of the NIC’s network cable connection. On the other end, data moves back and forth between the NIC and the network operating system software. The many steps a NIC performs to keep this data moving—sending and receiving frames over the wire, creating outgoing frames, reading incoming frames, and attaching MAC addresses—are classically broken down into two distinct jobs.

The first job is called the Logical Link Control (LLC). The LLC is the aspect of the NIC that talks to the system’s operating system (usually via device drivers). The LLC handles multiple network protocols and provides flow control.

EXAM TIP  The CompTIA Network+ exam tests you on the details of the OSI seven-layer model, so remember that the Data Link layer is the only layer that has sublayers.

The second job is called the Media Access Control (MAC), which creates and addresses the frame. It adds the NIC’s own MAC address and attaches MAC addresses to the frames. Recall that each frame the NIC creates must include both the sender’s and recipient’s MAC addresses. The MAC sublayer adds or checks the FCS. The MAC also ensures that the frames, now complete with their MAC addresses, are then sent along the network cabling. Figure 1-25 shows the Data Link layer in detail.

Figure 1-25 LLC and MAC, the two parts of the Data Link layer

NIC and Layers

Most networking materials that describe the OSI seven-layer model put NICs squarely into the Data Link layer of the model. It’s at the MAC sublayer, after all, that data gets encapsulated into a frame, destination and source MAC addresses get added to that frame, and error checking occurs. What bothers most students with placing NICs solely in the Data Link layer is the obvious other duty of the NIC—putting the ones and zeroes on the network cable for wired networks and in the air for wireless networks. How much more physical can you get?

Many teachers will finesse this issue by defining the Physical layer in its logical sense—that it defines the rules for the ones and zeroes—and then ignore the fact that the data sent on the cable has to come from something. The first question when you hear a statement like that—at least to me—is, “What component does the sending?” It’s the NIC, of course, the only device capable of sending and receiving the physical signal.

Network cards, therefore, operate at both Layer 2 and Layer 1 of the OSI seven-layer model. If cornered to answer one or the other, however, go with the more common answer, Layer 2.

Beyond the Single Wire—Network Software and Layers 3–7

Getting data from one system to another in a simple network (defined as one in which all the computers connect to one switch) takes relatively little effort on the part of the NICs. But one problem with simple networks is that computers need to broadcast to get MAC addresses. It works for small networks, but what happens when the network gets big, like the size of the entire Internet? Can you imagine millions of computers all broadcasting? No data could get through.

Equally important, data flows over the Internet using many technologies, not just Ethernet. These technologies don’t know what to do with Ethernet MAC addresses. When networks get large, you can’t use the MAC addresses anymore.

Large networks need a logical addressing method, like a postal code or telephone numbering scheme, that ignores the hardware and enables you to break up the entire large network into smaller networks called subnets. Figure 1-26 shows two ways to set up a network. On the left, all the computers connect to a single switch. On the right, however, the LAN is separated into two five-computer subnets.

Figure 1-26 LLC and MAC, the two parts of the Data Link layer

To move past the physical MAC addresses and start using logical addressing requires some special software called a network protocol. Network protocols exist in every operating system. A network protocol not only has to create unique identifiers for each system, but also must create a set of communication rules for issues like how to handle data chopped up into multiple packets and how to ensure those packets get from one subnet to another. Let’s take a moment to learn a bit about the most famous network protocol—TCP/IP—and its unique universal addressing system.

EXAM TIP  MAC addresses are also known as physical addresses.

To be accurate, TCP/IP is really several network protocols designed to work together—better known as a protocol suite—but two protocols, TCP and IP, do so much work that the folks who invented all these protocols named the whole thing TCP/IP. TCP stands for Transmission Control Protocol, and IP stands for Internet Protocol. IP is the network protocol I need to discuss first; rest assured, however, I’ll cover TCP in plenty of detail later.

IP—Playing on Layer 3, the Network Layer

At the Network layer, Layer 3, containers called packets get created and addressed so they can go from one network to another. The Internet Protocol is the primary logical addressing protocol for TCP/IP. IP makes sure that a piece of data gets to where it needs to go on the network. It does this by giving each device on the network a unique numeric identifier called an IP address. An IP address is known as a logical address to distinguish it from the physical address, the MAC address of the NIC.

NOTE  A packet is the PDU for Layer 3.

IP uses a rather unique dotted decimal notation (sometimes referred to as a dotted-octet numbering system) based on four 8-bit numbers. Each 8-bit number ranges from 0 to 255, and the four numbers are separated by periods. (If you don’t see how 8-bit numbers can range from 0 to 255, don’t worry—by the end of this book, you’ll understand these numbering conventions in more detail than you ever believed possible!) A typical IP address might look like this:

192.168.4.232

NOTE  TCP/IP dominates networking today, and although it might be fun to imagine that it had humble beginnings in someone’s garage lab, that’s not the case. In the early 1970s, two researchers at the U.S. Defense Advanced Research Projects Agency (DARPA), Bob Kahn and Vint Cerf, worked out the basic parameters of what would become TCP/IP. TCP/IP offered amazing robustness in its design and eventual implementation. Government research at its most profound and world shaping!

No two systems on the same network share the same IP address; if two machines accidentally receive the same address, unintended side effects may occur. These IP addresses don’t just magically appear—they must be configured by the network administrator.

What makes logical addressing powerful is another magic box—called a router—that connects each of the subnets, as in Figure 1-26, earlier. Routers use the IP address, not the MAC address, to forward data. This enables networks to connect across data lines that don’t use Ethernet, like the telephone network. Each network type (such as Ethernet, SONET, and others that we’ll discuss later in the book) uses a unique frame. Figure 1-27 shows a typical router.

Figure 1-27 Typical small router

In a TCP/IP network, each system has two unique identifiers: the MAC address and the IP address. The MAC address (the physical address) is literally burned into the chips on the NIC, whereas the IP address (the logical address) is simply stored in the system’s software. MAC addresses come with the NIC, so you don’t configure MAC addresses, whereas you must configure IP addresses using software. Figure 1-28 shows the MHTechEd network diagram again, this time with the MAC and IP addresses displayed for each system.

Figure 1-28 MHTechEd addressing

NOTE  Try to avoid using redundant expressions. Even though many techs will say “IP protocol,” for example, you know that “IP” stands for “Internet Protocol.” It wouldn’t be right to say “Internet Protocol protocol” in English, so it doesn’t work in network speak either. (Also, don’t say “NIC card” for the same reason!)

Packets Within Frames

For a TCP/IP network to send data successfully, the data must be wrapped up in two distinct containers. A frame of some type enables the data to move from one device to another. Inside that frame are both an IP-specific container that enables routers to determine where to send data—regardless of the physical connection type—and the data itself. In TCP/IP, that inner container is the packet.

Figure 1-29 shows a typical IP packet; notice the similarity to the frames you saw earlier.

Figure 1-29 IP packet

NOTE  This is a highly simplified IP packet. I am not including lots of little parts of the IP packet in this diagram because they are not important to what you need to understand right now—but don’t worry, you’ll see them later in the book!

But IP packets don’t leave their PC home without any clothes on! Each IP packet is handed to the NIC, which then encloses the IP packet in a regular frame, creating, in essence, a packet within a frame. I like to visualize the packet as an envelope, with the envelope in the pneumatic canister frame, as depicted in Figure 1-30. A more conventional drawing would look like Figure 1-31.

Figure 1-30 IP packet in a frame (as a canister)

Figure 1-31 IP packet in a frame

When you send data from one computer to another on a TCP/IP network such as the Internet, that data can go through many routers before it reaches its destination. Each router strips off the incoming frame, determines where to send the data according to the IP address in the packet, creates a new frame, and then sends the packet within a frame on its merry way. The new frame type will be the appropriate technology for whatever connection technology connects to the next router. That could be a cable or DSL network connection, for example (Figure 1-32). The IP packet, on the other hand, remains unchanged.

Figure 1-32 Router removing network frame and adding one for the outgoing connection

Once the packet reaches the destination subnet’s router, that router will strip off the incoming frame—no matter what type—look at the destination IP address, and then add a frame with the appropriate destination MAC address that matches the destination IP address.

NOTE  Not all networks are Ethernet networks (although all wired networks at home or work always use Ethernet). Ethernet may dominate, but IP packets fit in all sorts of other connectivity options. Cable modems, for example, use a type of frame called DOCSIS. The beauty of IP packets is that they can travel unchanged in many frame types. For more about these technologies, check out Chapter 13, “Remote Connectivity.”

The receiving NIC strips away the Ethernet frame and passes the remaining packet off to the software. The networking software built into your operating system handles all the rest of the work. The NIC’s driver software is the interconnection between the hardware and the software. The NIC driver knows how to communicate with the NIC to send and receive frames, but it can’t do anything with the packet. Instead, the NIC driver hands the packet off to other services that know how to deal with all the separate packets and turn them into Web pages, e-mail messages, files, and so forth.

Segmentation and Reassembly—Layer 4, the Transport Layer

Because most chunks of data are much larger than a single packet, they must be chopped up before they can be sent across a network. When a serving computer receives a request for some data, it must be able to chop the requested data into chunks that will fit into a packet (and eventually into the NIC’s frame), organize the packets for the benefit of the receiving system, and hand them to the NIC for sending. This is called segmentation. The receiving system does the reassembly of the packets. It must recognize a series of incoming packets as one data transmission, reassemble the packets correctly based on information included in the packets by the sending system, and verify that all the packets for that piece of data arrived in good shape.

This part is relatively simple—the transport protocol breaks up the data into chunks called segments or datagrams (depending on the specific transport protocol used) and gives each segment some type of sequence number. (Datagrams are simpler and don’t get sequence numbers.)

I like to compare this sequencing process to the one that my favorite international shipping company uses. I receive boxes from UPS almost every day; in fact, some days I receive many, many boxes from UPS. To make sure I get all the boxes for one shipment, UPS puts a numbering system, like the one shown in Figure 1-33, on the label of each box. A computer sending data on a network does the same thing. Embedded into the data of each packet containing a segment is a sequencing number. By reading the sequencing numbers, the receiving system knows both the total number of segments and how to put them back together.

Figure 1-33 Labeling the boxes

The MHTechEd network just keeps getting more and more complex, doesn’t it? And the Word document still hasn’t been copied, has it? Don’t worry; you’re almost there—just a few more pieces to go!

Layer 4, the Transport layer of the OSI seven-layer model, has a big job: it’s the segmentation/reassembly software. As part of its job, the Transport layer also initializes requests for packets that weren’t received in good order (Figure 1-34).

Figure 1-34 OSI updated

NOTE  A lot of things happen on a TCP/IP network at the Transport layer. I’m simplifying here because the TCP/IP model does a way better job describing what happens with each TCP/IP-specific Transport layer protocol than does the OSI model.

Talking on a Network—Layer 5, the Session Layer

Now that you understand that the system uses software to segment and reassemble data packets, what’s next? In a network, any one system may be talking to many other systems at any given moment. For example, Janelle’s PC has a printer used by all the MHTechEd systems, so there’s a better than average chance that, as Dana tries to access the Word document, another system will be sending a print job to Janelle’s PC (Figure 1-35).

Figure 1-35 Handling multiple inputs

Janelle’s system must direct these incoming files, print jobs, Web pages, and so on, to the right programs (Figure 1-36). Additionally, the operating system must enable one system to make a connection to another system to verify that the other system can handle whatever operation the initiating system wants to perform. If Bill’s system wants to send a print job to Janelle’s printer, it first contacts Janelle’s system to ensure that it is ready to handle the print job. The session software handles this part of networking, connecting applications to applications.

Figure 1-36 Each request becomes a session.

Layer 5, the Session layer of the OSI seven-layer model, handles all the sessions for a system (Figure 1-37). The Session layer initiates sessions, accepts incoming sessions, and opens and closes existing sessions.

Figure 1-37 OSI updated

Translation—Layer 6, the Presentation Layer

The Presentation layer translates data from lower layers into a format usable by the Application layer, and vice versa (Figure 1-38). This manifests in several ways and isn’t necessarily clear cut. The messiness comes into play because TCP/IP networks don’t necessarily map directly to the OSI model.

Figure 1-38 OSI updated

A number of protocols function on more than one OSI layer and can include Layer 6, Presentation. The encryption protocols used in e-commerce, SSL/TLS, for example, seem to initiate at Layer 5, then encrypt and decrypt at Layer 6. But even one of the authors of SSL disputes that SSL/TLS should even be included in any OSI chart! It makes for some confusion. Modern network discussions, therefore, work better using the TCP/IP model where the OSI Layers 5 through 7 are lumped together as the Application layer. We’ll get there shortly.

Network Applications—Layer 7, the Application Layer

The last and most visible part of any network is the software applications that use it. If you want to copy a file residing on another system in your network, you need an application like Network in Windows 10 that enables you to access files on remote systems. If you want to view Web pages, you need a Web browser like Google Chrome or Mozilla Firefox. The people who use a network experience it through an application. A user who knows nothing about all the other parts of a network may still know how to open an e-mail application to retrieve mail (Figure 1-39).

Figure 1-39 Network applications at work

Applications may include additional functions, such as encryption, user authentication, and tools to control the look of the data. But these functions are specific to the given applications. In other words, if you want to put a password on your Word document, you must use the password functions in Word to do so.

The Application layer is Layer 7 in the OSI seven-layer model. Keep in mind that the Application layer doesn’t refer to the applications themselves. It refers to the code built into all operating systems that enables network-aware applications. All operating systems have Application Programming Interfaces (APIs) that programmers can use to make their programs network aware (Figure 1-40). An API, in general, provides a standard way for programmers to enhance or extend an application’s capabilities.

Figure 1-40 OSI updated

Encapsulation and De-Encapsulation

The term encapsulation encompasses the entire process of preparing data to go onto a network. This includes all the steps from the application to the Application, Presentation, Session, Transport, Network, and Data Link layers. Each layer adds more information so that the data gets to the correct recipient and the recipient knows what to do with the data.

The receiving computer reverses the process, stripping all the extra header information out as the data goes up the stack. This reverse process is called de-encapsulation.

The Transport layer creates a segment or datagram and hands it down to the Network layer. (See “The Transport Layer” later in this chapter for more details.) That layer adds IP information, encapsulating the segment or datagram. The Data Link layer wraps all that goodness up, encapsulating the packet in a frame for delivery over the network.

The TCP/IP Model

The OSI model was developed as a reaction to a world of hundreds, if not thousands, of different protocols made by different manufacturers that needed to play together. ISO declared the OSI seven-layer model as the tool for manufacturers of networking equipment to find common ground between multiple protocols, enabling them to create standards for interoperability of networking software and hardware.

The OSI model is extremely popular and very well known to all networking techs. Today’s world, however, is a TCP/IP world. The complexity of the OSI model doesn’t always make sense in a world with one protocol suite. Given its dominance, the aptly named TCP/IP model shares some popularity with the venerable OSI model.

The TCP/IP model consists of four layers:

•  Application

•  Transport

•  Internet

•  Link/Network Interface

It’s important to appreciate that the TCP/IP model doesn’t have a standards body to define the layers. Because of this, there are a surprising number of variations on the TCP/IP model.

A great example of this lack of standardization is the Link layer. Without a standardizing body, we can’t even agree on the name. While “Link layer” is extremely common, the term “Network Interface layer” is equally popular. A good tech knows both of these terms and understands that they are interchangeable. Notice also that, unlike the OSI model, the TCP/IP model does not identify each layer with a number.

The version I use is concise, having only four layers, and many important companies, like Cisco and Microsoft, use it as well. The TCP/IP model gives each protocol in the TCP/IP protocol suite a clear home in one of the four layers.

The clarity of the TCP/IP model shows the flaws in the OSI model. The OSI model couldn’t perfectly describe all the TCP/IP protocols.

The TCP/IP model fixes this ambiguity, at least for TCP/IP. Because of its tight protocol-to-layer integration, the TCP/IP model is a descriptive model, whereas the OSI seven-layer model is a prescriptive model.

The Link Layer

The TCP/IP model lumps together the OSI model’s Layer 1 and Layer 2 into a single layer called the Link layer (or Network Interface layer), as seen in Figure 1-41. It’s not that the Physical and Data Link layers are unimportant to TCP/IP, but the TCP/IP protocol suite really begins at Layer 3 of the OSI model. In essence, TCP/IP techs count on other techs to handle the physical connections in their networks. All of the pieces that you learned in the OSI model (cabling, physical addresses, NICs, and switches) sit squarely in the Link layer.

Figure 1-41 TCP/IP Link layer compared to OSI Layers 1 and 2

A nice way to separate layers in the TCP/IP model is to think about packets and frames. Any part of the network that deals with complete frames is in the Link layer. The moment the frame information is stripped away from an IP packet, we move out of the Link layer and into the Internet layer.

The Internet Layer

The Internet layer should really be called the “IP packet” layer (Figure 1-42). Any device or protocol that deals with pure IP packets—getting an IP packet to its destination—sits in the Internet layer. IP addressing itself is also part of the Internet layer, as are routers and the magic they perform to get IP packets to the next router. IP packets are created at this layer.

Figure 1-42 TCP/IP Internet layer compared to OSI Layer 3

The Internet layer doesn’t care about the type of data an IP packet carries, nor does it care whether the data gets there in good order or not. Those jobs are for the next layer: the Transport layer.

The Transport Layer

The Transport layer combines features of the OSI Transport and Session layers with a dash of Application layer just for flavor (Figure 1-43). While the TCP/IP model is certainly involved with the segmentation and reassembly of data, it also defines other functions, such as connection-oriented and connectionless communication.

Figure 1-43 TCP/IP Transport layer compared to OSI Layers 4, 5, and part of 7

Connection-Oriented vs. Connectionless Communication

Some protocols, like the Internet Message Access Protocol (IMAP) used for sending e-mail messages, require that the e-mail client and server verify that they have a good connection before a message is sent (Figure 1-44). This makes sense because you don’t want your e-mail message to be a corrupted mess when it arrives.

Figure 1-44 Connection between e-mail client and server

Alternatively, a number of TCP/IP protocols simply send data without first waiting to verify that the receiving system is ready (Figure 1-45). When using Voice over IP (VoIP), for example, the call is made without verifying first whether another device is there.

Figure 1-45 Connectionless communication

The connection-oriented protocol is Transmission Control Protocol (TCP). The connectionless protocol is User Datagram Protocol (UDP).

NOTE  Chapter 6, “TCP/IP Basics,” covers TCP, UDP, and all sorts of other protocols in detail.

Everything you can do on the Internet, from Web browsing to Skype phone calls to playing World of Warcraft, is predetermined to be either connection-oriented or connectionless. It’s simply a matter of knowing your applications.

Segments Within Packets

To see the Transport layer in action, strip away the IP addresses from an IP packet. What’s left is a chunk of data in yet another container called a TCP segment. TCP segments have many other fields that ensure the data gets to its destination in good order. These fields have names such as Destination port, Source port, Checksum, Flags, and Acknowledgement. Figure 1-46 shows a typical (although simplified) TCP segment.

Figure 1-46 TCP segment

Chapter 6 goes into more detail on TCP segments, but let’s look at Destination and Source ports as an example. You saw physical ports earlier in the chapter, but this use of the word “port” means something completely different. In this context, a port—a number between 1 and 65,536—is a logical value assigned to specific applications or services. A quick example will make this clear. Many TCP segments come into any computer. The computer needs some way to determine which TCP segments go to which applications. A Web server, for example, sees a lot of traffic, but it “listens” or looks for TCP segments with the Destination port number 80, grabs those segments, and processes them. Equally, every TCP segment contains a second port number—the Source port—so the client knows what to do with returning information.

Data comes from the Application layer. The Transport layer breaks that data into chunks, adding port numbers and sequence numbers, creating the TCP segment. The Transport layer then hands the TCP segment to the Internet layer, which, in turn, creates the IP packet.

Although a lot of traffic on a TCP/IP network uses TCP at the Transport layer, like Yoda said in The Empire Strikes Back, “There is another,” and that’s UDP. UDP also gets data from the Application layer and adds port and length numbers plus a checksum to create a container called a UDP datagram. A UDP datagram lacks most of the extra fields found in TCP segments, simply because UDP doesn’t care if the receiving computer gets its data. Figure 1-47 shows a UDP datagram.

Figure 1-47 UDP datagram

Sessions

The TCP model makes the idea of a session easier to see as compared to the OSI model. Many operating systems represent a session using the combination of the IP address and port numbers for both sides of a TCP or UDP communication. You can see a Web browser’s session connecting to a Web server, for example, by running the netstat command that you ran earlier in the chapter. This time, run it as netstat -n. It’ll return many lines like this:

The numbers describe the session. A Web client with the IP of 192.168.4.34, using port number 45543, is in a TCP session with a Web server (we know it’s a Web server because port 80 is dedicated to Web servers) using IP address 11.12.13.123.

The Application Layer

The TCP/IP Application layer combines features of the top three layers of the OSI model (Figure 1-48). Every application, especially connection-oriented applications, must know how to initiate, control, and disconnect from a remote system. No single method exists for doing this. Each TCP/IP application uses its own method.

Figure 1-48 TCP/IP Application layer compared to OSI Layers 5–7

Although we can say that the OSI model’s Presentation layer fits inside the TCP/IP model’s Application layer, no application requires any particular form of presentation as seen in the OSI model. Standard formats are part and parcel with TCP/IP protocols. For example, all e-mail messages use an extremely strict format called MIME. All e-mail servers and clients read MIME without exception.

In the OSI model, we describe the API—the smarts that make applications network-aware—as being part of the Application layer. While this is still true for the TCP/IP model, all applications designed for TCP/IP are, by definition, network-aware. There is no such thing as a “TCP/IP word processor” or a “TCP/IP image editor” that requires the added ability to know how to talk to a network—all TCP/IP applications can talk to the network, as long as they are part of a network. And every TCP/IP application must be a part of a network to function: Web browsers, e-mail clients, multiplayer games, and so on.

Don’t think that the TCP/IP model is any simpler than the OSI model just because it only uses four layers. With the arguable exception of the Presentation layer, everything you saw in the OSI model is also found in the TCP/IP model (Figure 1-49).

Figure 1-49 OSI model and TCP/IP model side by side

Frames, Packets, and Segments/Datagrams, Oh My!

The TCP/IP model shows its power in its ability to describe what happens at each layer to the data that goes from one computer to another. The Application layer programs create the data. The Transport layer breaks the data into chunks, putting those chunks into TCP segments or UDP datagrams. The Internet layer adds the IP addressing and creates the IP packets. The Link layer wraps the IP packet into a frame, with the MAC address information and a frame check sequence (FCS). Now the data is ready to hit the wire (or airwaves, if you’re in a café). Figure 1-50 shows all this encapsulating goodness relative to the TCP/IP model.

Figure 1-50 Data encapsulation in TCP/IP

Knowing the layer at which each encapsulation takes place can assist in your troubleshooting. Table 1-1 shows the layers and the corresponding data structure.

Table 1-1 TCP/IP Model Layers and Corresponding Data Structures

SIM  Check out the “Network Models” Chapter 1 sim at totalsem.com/007. It’s an excellent Challenge! game.

The Tech’s Troubleshooting Tools

The OSI seven-layer model and TCP/IP model provide you with a way to conceptualize a network to determine what could cause a specific problem when the inevitable problems occur. Good techs always use a model to troubleshoot their networks.

If Jane can’t print to the networked printer, for example, a model can help solve the problem. If her NIC shows activity, then, using the OSI model, you can set aside both the Physical layer (Layer 1) and Data Link layer (Layer 2). If you’re a TCP/IP model tech, you can look at the same symptoms and eliminate the Link layer. In either case, you’ll find yourself moving up the layer ladder to the OSI model’s Network layer (Layer 3) or the TCP/IP model’s Internet layer. If her computer has a proper IP address, then you can set that layer aside too, and you can move on up to check other layers to solve the problem.

Understanding both the OSI and TCP/IP models is important. They are the primary diagnostic tools for troubleshooting networks and also the communication tools for talking with your fellow techs.

Chapter Review

Questions

1. Where does a hub send data?

A. Only to the receiving system

B. Only to the sending system

C. To all the systems connected to the hub

D. Only to the server

2. What uniquely identifies every NIC?

A. IP address

B. Media access control address

C. ISO number

D. Packet ID number

3. What Windows utility do you use to find the MAC address for a system?

A. ipconfig /all

B. ipcfg /all

C. ping

D. mac

4. A MAC address is known as a(n) _______________ address.

A. IP

B. logical

C. physical

D. OEM

5. A NIC sends data in discrete chunks called _______________.

A. segments

B. sections

C. frames

D. layers

6. Which MAC address begins a frame?

A. Receiving system

B. Sending system

C. Network

D. Router

7. A frame ends with a special bit called the frame check sequence (FCS). What does the FCS do?

A. Cycles data across the network

B. Verifies that the MAC addresses are correct

C. Verifies that the data arrived correctly

D. Verifies that the IP address is correct

8. Which of the following is an example of a MAC address?

A. 0–255

B. 00–50–56–A3–04–0C

C. SBY3M7

D. 192.168.4.13

9. Which layer of the TCP/IP model controls the segmentation and reassembly of data?

A. Application layer

B. Presentation layer

C. Session layer

D. Transport layer

10. Which layer of the OSI seven-layer model keeps track of a system’s connections to send the right response to the right computer?

A. Application layer

B. Presentation layer

C. Session layer

D. Transport layer

Answers

1. C. Data comes into a hub through one wire and is then sent out through all the other wires. A hub sends data to all the systems connected to it.

2. B. The unique identifier on a network interface card is called the media access control (MAC) address.

3. A. All versions of Windows use ipconfig /all from the command line to determine the MAC address.

4. C. The MAC address is a physical address.

5. C. Data is sent in discrete chunks called frames. Networks use frames to keep any one NIC from hogging the wire.

6. A. The frame begins with the MAC address of the receiving NIC, followed by the MAC address of the sending NIC, followed, in turn, by type of encapsulated data, the data, and FCS.

7. C. The data is followed by a special bit of checking information called the frame check sequence, which the receiving NIC uses to verify that the data arrived correctly.

8. B. A MAC address is a 48-bit value, and no two NICs ever share the same MAC address—ever. 00–50–56–A3–04–0C is a MAC address. Answer D (192.168.4.13) is an IP address.

9. D. The Transport layer controls the segmentation and reassembly of data.

10. C. The Session layer keeps track of a system’s connections to ensure that it sends the right response to the right computer.