To create an Ethernet LAN, a network engineer starts by planning. They consider the requirements, create a design, buy the switches, contract to install cables, and configure the switches to use the right features.

The CCNA Routing and Switching exams focus on skills like understanding how LANs work, configuring different switch features, verifying that those features work correctly, and finding the root cause of the problem when a feature is not working correctly.

The first skill you need to learn before doing all the configuration, verification, and troubleshooting tasks is to learn how to access and use the user interface of the switch, called the command-line interface (CLI).

This lesson begins that process by showing the basics of how to access the switch’s CLI. These skills include how to access the CLI and how to issue verification commands to check on the status of the LAN. This lesson also includes the processes of how to configure the switch and how to save that configuration.

Cisco uses the concept of a command-line interface (CLI) with its router products and most of its Catalyst LAN switch products.

The CLI is a text-based interface in which the user, typically a network engineer, enters a text command and presses Enter. 

Pressing Enter sends the command to the switch, which tells the device to do something. The switch does what the command says, and in some cases, the switch replies with some messages stating the results of the command.

Cisco Catalyst switches also support other methods to both monitor and configure a switch.

For example, a switch can provide a web interface, so that an engineer can open a web browser to connect to a web server running in the switch. Switches also can be controlled and operated using network management software.

This material discusses only Cisco Catalyst enterprise-class switches, and in particular, how to use the Cisco CLI to monitor and control these switches.

This first major section of the lesson first examines these Catalyst switches in more detail, and then explains how a network engineer can get access to the CLI to issue commands.

Within the Cisco Catalyst brand of LAN switches, Cisco produces a wide variety of switch series or families.

Each switch series includes several specific models of switches that have similar features, similar price-versus-performance trade-offs, and similar internal components.

For example, the Cisco 2960-X series of switches. Cisco positions the 2960-X series (family) of switches as full-featured, low-cost wiring closet switches for enterprises. That means that you would expect to use 2960-X switches as access switches in a typical campus LAN design.

Figure 1 shows a photo of 10 different models from the 2960-X switch model series from Cisco.

Each switch series includes several models, with a mix of features.

For example, some of the switches have 48 RJ-45 unshielded twisted-pair (UTP) 10/100/1000 ports, meaning that these ports can autonegotiate the use of 10BASE-T (10 Mbps), 100BASE-T (100 Mbps), or 1000BASE-T (1 Gbps) Ethernet.

Like any other piece of computer hardware, Cisco switches need some kind of operating system software.

Cisco calls this OS the Internetwork Operating System (IOS).

Cisco IOS Software for Catalyst switches implements and controls logic and functions performed by a Cisco switch.

Besides controlling the switch’s performance and behavior, Cisco IOS also defines an interface for humans called the CLI.

The Cisco IOS CLI allows the user to use a terminal emulation program, which accepts text entered by the user. When the user presses Enter, the terminal emulator sends that text to the switch. The switch processes the text as if it is a command, does what the command says, and sends text back to the terminal emulator.

The switch CLI can be accessed through three popular methods—the console, Telnet, and Secure Shell (SSH).

Two of these methods (Telnet and SSH) use the IP network in which the switch resides to reach the switch. The console is a physical port built specifically to allow access to the CLI.

Figure 2 depicts the options.

Console access requires both a physical connection between a PC (or other user device) and the switch’s console port, as well as some software on the PC.

Telnet and SSH require software on the user’s device, but they rely on the existing TCP/IP network to transmit data.

The next few topics detail how to connect the console and set up the software for each method to access the CLI.

Cabling the Console Connection

The physical console connection, both old and new, uses three main components: the physical console port on the switch, a physical serial port on the PC, and a cable that works with the console and serial ports.

However, the physical cabling details have changed slowly over time, mainly because of advances and changes with serial interfaces on PC hardware.

For this next topic, the text looks at three cases: newer connectors on both the PC and the switch, older connectors on both, and a third case with the newer (USB) connector on the PC but with an older connector on the switch.

More modern PC and switch hardware use a familiar standard USB cable for the console connection. Cisco has been including USB ports as console ports in newer routers and switches as well.

All you have to do is look at the switch to make sure you have the correct style of USB cable end to match the USB console port. In the simplest form, you can use any USB port on the PC, with a USB cable, connected to the USB console port on the switch or router, as shown on the far right side of Figure 3.

Older console connections use a PC serial port that pre-dates USB, a UTP cable, and an RJ-45 console port on the switch, as shown on the left side of Figure 3.

The PC serial port typically has a D-shell connector (roughly rectangular) with nine pins (often called a DB-9). The console port looks like any Ethernet RJ-45 port (but is typically colored in blue and with the word “console” beside it on the switch).

The cabling for this older-style console connection can be simple or require some effort, depending on what cable you use. You can use the purpose-built console cable that ships with new Cisco switches and routers and not think about the details.

However, you can make your own cable with a standard serial cable (with a connector that matches the PC), a standard RJ-45 to DB-9 converter plug, and a UTP cable.

However, the UTP cable does not use the same pinouts as Ethernet; instead, the cable uses rollover cable pinouts rather than any of the standard Ethernet cabling pinouts.

The rollover pinout uses eight wires, rolling the wire at pin 1 to pin 8, pin 2 to pin 7, pin 3 to pin 6, and so on.

As it turns out, USB ports became common on PCs before Cisco began commonly using USB for its console ports. So, you also have to be ready to use a PC that has only a USB port and not an old serial port, but a router or switch that has the older RJ-45 console port (and no USB console port).

The center of Figure 3 shows that case. To connect such a PC to a router or switch console, you need a USB converter that converts from the older console cable to a USB connector, and a rollover UTP cable, as shown in the middle of Figure 3.

NOTE: When using the USB options, you typically also need to install a software driver so that your PC’s OS knows that the device on the other end of the USB connection is the console of a Cisco device. Also, you can easily find photos of these cables and components online, with searches like “cisco console cable,” “cisco usb console cable,” or “console cable converter.”

The newer 2960-X series, for instance, supports both the older RJ-45 console port and a USB console port.

Figure 4 points to the two console ports; you would use only one or the other. Note that the USB console port uses a mini-B port rather than the more commonly seen rectangular standard USB port.

After the PC is physically connected to the console port, a terminal emulator software package must be installed and configured on the PC.

The terminal emulator software treats all data as text. It accepts the text typed by the user and sends it over the console connection to the switch. Similarly, any bits coming into the PC over the console connection are displayed as text for the user to read.

The emulator must be configured to use the PC’s serial port to match the settings on the switch’s console port settings. The default console port settings on a switch are as follows.

Note that the last three parameters are referred to collectively as 8N1:

• 9600 bits/second
• No hardware flow control
• 8-bit ASCII
• No parity bits
• 1 stop bit

Figure 5 shows one such terminal emulator. The image shows the window created by the emulator software in the background, with some output of a show command. 

The foreground, in the upper left, shows a settings window that lists the default console settings as listed just before this paragraph.

Accessing the CLI with Telnet and SSH

For many years, terminal emulator applications have supported far more than the ability to communicate over a serial port to a local device (like a switch’s console).

Terminal emulators support a variety of TCP/IP applications as well, including Telnet and SSH.

Telnet and SSH both allow the user to connect to another device’s CLI, but instead of connecting through a console cable to the console port, the traffic flows over the same IP network that the networking devices are helping to create.

Telnet uses the concept of a Telnet client (the terminal application) and a Telnet server (the switch in this case). A Telnet client, the device that sits in front of the user, accepts keyboard input and sends those commands to the Telnet server.

The Telnet server accepts the text, interprets the text as a command, and replies back. Telnet is a TCP-based application layer protocol that uses well-known port 23.

Cisco Catalyst switches enable a Telnet server by default, but switches need a few more configuration settings before you can successfully use Telnet to connect to a switch. Chapter 8 covers switch configuration to support Telnet and SSH in detail.

Using Telnet in a lab today makes sense, but Telnet poses a significant security risk in production networks. Telnet sends all data (including any username and password for login to the switch) as clear-text data. SSH gives us a much better option.

Think of SSH as the much more secure Telnet cousin. Outwardly, you still open a terminal emulator, connect to the switch’s IP address, and see the switch CLI, no matter whether you use Telnet or SSH.

The differences exist behind the scenes: SSH encrypts the contents of all messages, including the passwords, avoiding the possibility of someone capturing packets in the network and stealing the password to network devices. Like Telnet, SSH uses TCP, just using well-known port 22 instead of Telnet’s 23.

User and Enable (Privileged) Modes

All three CLI access methods covered so far (console, Telnet, and SSH) place the user in an area of the CLI called user EXEC mode.

User EXEC mode, sometimes also called user mode, allows the user to look around but not break anything.

The “EXEC mode” part of the name refers to the fact that in this mode, when you enter a command, the switch executes the command and then displays messages that describe the command’s results.

Password Security for CLI Access from the Console

Cisco IOS supports a more powerful EXEC mode called enable mode (also known as privileged mode or privileged EXEC mode).

Enable mode gets its name from the enable command, which moves the user from user mode to enable mode, as shown in Figure 6. 

The other name for this mode, privileged mode, refers to the fact that powerful (or privileged) commands can be executed there. For example, you can use the reload command, which tells the switch to reinitialize or reboot Cisco IOS, only from enable mode.

NOTE: If the command prompt lists the hostname followed by a >, the user is in user mode; if it is the hostname followed by the #, the user is in enable mode.

Example 1 demonstrates the differences between user and enable modes. 

The example shows the output that you could see in a terminal emulator window, for instance, when connecting from the console.

In this case, the user sits at the user mode prompt (“Certskills1>”) and tries the reload command.

The reload command tells the switch to reinitialize or reboot Cisco IOS, so IOS allows this powerful command to be used only from enable mode.

IOS rejects the reload command when used in user mode. Then the user moves to enable mode—also called privileged mode—(using the enable EXEC command).

At that point, IOS accepts the reload command now that the user is in enable mode.

NOTE: 
The commands that can be used in either user (EXEC) mode or enable (EXEC) mode are called EXEC commands.

This example is the first instance of this lesson showing you the output from the CLI, so it is worth noting a few conventions.

The bold text represents what the user typed, and the nonbold text is what the switch sent back to the terminal emulator.

Also, the typed passwords do not show up on the screen for security purposes.

Finally, note that this switch has been preconfigured with a hostname of Certskills1, so the command prompt on the left shows that hostname on each line.

Password Security for CLI Access from the Console

A Cisco switch, with default settings, remains relatively secure when locked inside a wiring closet, because by default, a switch allows console access only.

By default, the console requires no password at all, and no password to reach enable mode for users that happened to connect from the console.

The reason is that if you have access to the physical console port of the switch, you already have pretty much complete control over the switch.

You could literally get out your screwdriver and walk off with it, or you could unplug the power, or follow well-published procedures to go through password recovery to break into the CLI and then configure anything you want to configure.

However, many people go ahead and set up simple password protection for console users.

Simple passwords can be configured at two points in the login process from the console: when the user connects from the console, and when any user moves to enable mode (using the enable EXEC command).

You may have noticed that back in Example 1, the user saw a password prompt at both points.

Example 2 shows the additional configuration commands that were configured prior to collecting the output in Example 1. The output holds an excerpt from the EXEC command show running-config, which lists the current configuration in the switch.

Working from top to bottom, note that the first configuration command listed by the show running-config command sets the switch’s hostname to Certskills1.

You might have noticed that the command prompts in Example 1 all began with Certskills1, and that’s why the command prompt begins with the hostname of the switch.

Next, note that the lines with a ! in them are comment lines, both in the text of this book and in the real switch CLI.

The enable secret love configuration command defines the password that all users must use to reach enable mode. So, no matter whether a user connects from the console, Telnet, or SSH, they would use password love when prompted for a password after typing the enable EXEC command.

Finally, the last three lines configure the console password. The first line (line console 0) is the command that identifies the console, basically meaning “these next commands apply to the console only.” The login command tells IOS to perform simple password checking (at the console).

Remember, by default, the switch does not ask for a password for console users. Finally, the password faith command defines the password the console user must type when prompted.

This example just scratches the surface of the kinds of security configuration you might choose to configure on a switch, but it does give you enough detail to configure switches in your lab and get started.

Note that there will be lesson that shows the configuration steps to add support for Telnet and SSH (including password security).

If you printed the Cisco IOS Command Reference documents, you would end up with a stack of paper several feet tall.

No one should expect to memorize all the commands—and no one does. You can use several very easy, convenient tools to help remember commands and save time typing.

As you progress through your Cisco certifications, the exams will cover progressively more commands. However, you should know the methods of getting command help.

Table 1 summarizes command-recall help options available at the CLI. 

Note that, in the first column, command represents any command. Likewise, parm represents a command’s parameter.

For example, the third row lists command ?, which means that commands such as show ? and copy ? would list help for the show and copy commands, respectively.

When you enter the ?, the Cisco IOS CLI reacts immediately; that is, you don’t need to press the Enter key or any other keys.

The device running Cisco IOS also redisplays what you entered before the ? to save you some keystrokes. If you press Enter immediately after the ?, Cisco IOS tries to execute the command with only the parameters you have entered so far.

The information supplied by using help depends on the CLI mode. For example, when ? is entered in user mode, the commands allowed in user mode are displayed, but commands available only in enable mode (not in user mode) are not displayed.

Also, help is available in configuration mode, which is the mode used to configure the switch. In fact, configuration mode has many different subconfiguration modes, as explained in the section “Configuration Submodes and Contexts,” later in this chapter.

So, you can get help for the commands available in each configuration submode as well.

Cisco IOS stores the commands that you enter in a history buffer, storing ten commands by default. The CLI allows you to move backward and forward in the historical list of commands and then edit the command before reissuing it.

These key sequences can help you use the CLI more quickly on the exams.

Table 2 lists the commands used to manipulate previously entered commands.

By far, the single most popular Cisco IOS command is the show command.

The show command has a large variety of options, and with those options, you can find the status of almost every feature of Cisco IOS.

Essentially, the show command lists the currently known facts about the switch’s operational status. The only work the switch does in reaction to show commands is to find the current status and list the information in messages sent to the user.

For example, consider the output from the show mac address-table dynamic command listed in Example 3. 

This show command, issued from user mode, lists the table the switch uses to make forwarding decisions. A switch’s MAC address table basically lists the data a switch uses to do its primary job.

The debug command also tells the user details about the operation of the switch. However, while the show command lists status information at one instant of time—more like a photograph—the debug command acts more like a live video camera feed.

Once you issue a debug command, IOS remembers, issuing messages that any switch user can choose to see. The console sees these messages by default.

Most of the commands used throughout this book to verify operation of switches and routers are show commands.

You will want to configure every switch in an Enterprise network, even though the switches will forward traffic even with default configuration.

This section covers the basic configuration processes, including the concept of a configuration file and the locations in which the configuration files can be stored.

Although this section focuses on the configuration process, and not on the configuration commands themselves, you should know all the commands covered in this chapter for the exams, in addition to the configuration processes.

Configuration mode is another mode for the Cisco CLI, similar to user mode and privileged mode. User mode lets you issue non-disruptive commands and displays some information.

Privileged mode supports a superset of commands compared to user mode, including commands that might disrupt switch operations.

However, none of the commands in user or privileged mode changes the switch’s configuration. Configuration mode accepts configuration commands—commands that tell the switch the details of what to do and how to do it.

Figure 7 illustrates the relationships among configuration mode, user EXEC mode, and privileged EXEC mode.

Commands entered in configuration mode update the active configuration file. These changes to the configuration occur immediately each time you press the Enter key at the end of a command. Be careful when you enter a configuration command!

Configuration mode itself contains a multitude of commands. To help organize the configuration, IOS groups some kinds of configuration commands together.

To do that, when using configuration mode, you move from the initial mode—global configuration mode—into subcommand modes. Context-setting commands move you from one configuration subcommand mode, or context, to another.

These context-setting commands tell the switch the topic about which you will enter the next few configuration commands.

More importantly, the context tells the switch the topic you care about right now, so when you use the ? to get help, the switch gives you help about that topic only.

NOTE: Context-setting is not a Cisco term. It is just a description used here to help make sense of configuration mode.

The best way to learn about configuration submodes is to use them, but first, take a look at these upcoming examples.

For instance, the interface command is one of the most commonly used context-setting configuration commands.

For example, the CLI user could enter interface configuration mode by entering the interface FastEthernet 0/1 configuration command. Asking for help in interface configuration mode displays only commands that are useful when configuring Ethernet interfaces.

Commands used in this context are called subcommands—or, in this specific case, interface subcommands. 

When you begin practicing with the CLI with real equipment (or simulation), the navigation between modes can become natural. For now, consider Example 4, which shows the following:

• Movement from enable mode to global configuration mode by using the configure terminal EXEC command.
• Using a hostname Fred global configuration command to configure the switch’s name.
• Movement from global configuration mode to console line configuration mode (using the line console 0 command).
• Setting the console’s simple password to hope (using the password hope line subcommand).
• Movement from console configuration mode to interface configuration mode (using the interface type number command).
• Setting the speed to 100 Mbps for interface Fa0/1 (using the speed 100 interface subcommand).
• Movement from interface configuration mode back to global configuration mode (using the exit command).

The text inside parentheses in the command prompt identifies the configuration mode. For example, the first command prompt after you enter configuration mode lists (config), meaning global configuration mode.

After the line console 0 command, the text expands to (config-line), meaning line configuration mode. Each time the command prompt changes within config mode, you have moved to another configuration mode.

Table 3 shows the most common command prompts in configuration mode, the names of those modes, and the context-setting commands used to reach those modes.

You should practice until you become comfortable moving between the different configuration modes, back to enable mode, and then back into the configuration modes.

However, you can learn these skills just doing labs about the topics in later lessons. 

For now, Figure 8 shows most of the navigation between global configuration mode and the four configuration submodes listed in Table 3.

NOTE: You can also move directly from one configuration submode to another, without first using the exit command to move back to global configuration mode. Just use the commands listed in bold in the center of the figure.

You really should stop and try navigating around these configuration modes.

No set rules exist for what commands are global commands or subcommands.

Generally, however, when multiple instances of a parameter can be set in a single switch, the command used to set the parameter is likely a configuration subcommand.

Items that are set once for the entire switch are likely global commands. For example, the hostname command is a global command because there is only one hostname per switch. 

Conversely, the speed command is an interface subcommand that applies to each switch interface that can run at different speeds, so it is a subcommand, applying to the particular interface under which it is configured.

When you configure a switch, it needs to use the configuration. It also needs to be able to retain the configuration in case the switch loses power.

Cisco switches contain random-access memory (RAM) to store data while Cisco IOS is using it, but RAM loses its contents when the switch loses power or is reloaded. 

To store information that must be retained when the switch loses power or is reloaded, Cisco switches use several types of more permanent memory, none of which has any moving parts.

By avoiding components with moving parts (such as traditional disk drives), switches can maintain better uptime and availability.

The following list details the four main types of memory found in Cisco switches, as well as the most common use of each type:

• RAM: Sometimes called DRAM, for dynamic random-access memory, RAM is used by the switch just as it is used by any other computer: for working storage. The running (active) configuration file is stored here.
• Image Flash memory: Either a chip inside the switch or a removable memory card, flash memory stores fully functional Cisco IOS images and is the default location where the switch gets its Cisco IOS at boot time. Flash memory also can be used to store any other files, including backup copies of configuration files.
• ROM: Read-only memory (ROM) stores a bootstrap (or boothelper) program that is loaded when the switch first powers on. This bootstrap program then finds the full Cisco IOS image and manages the process of loading Cisco IOS into RAM, at which point Cisco IOS takes over operation of the switch.
• NVRAM: Nonvolatile RAM (NVRAM) stores the initial or startup configuration file that is used when the switch is first powered on and when the switch is reloaded.

Figure 9 summarizes this same information in a briefer and more convenient form for memorization and study.

Cisco IOS stores the collection of configuration commands in a configuration file. In fact, switches use multiple configuration files—one file for the initial configuration used when powering on, and another configuration file for the active, currently used running configuration as stored in RAM. ​

Table 4 lists the names of these two files, their purpose, and their storage location.

Essentially, when you use configuration mode, you change only the running-config file. This means that the configuration example earlier in this chapter (Example 4) updates only the running-config file. 

However, if the switch lost power right after that example, all that configuration would be lost. If you want to keep that configuration, you have to copy the running-config file into NVRAM, overwriting the old startup-config file.

Example 5 demonstrates that commands used in configuration mode change only the running configuration in RAM. The example shows the following concepts and steps:

• Step 1. The example begins with both the running and startup-config having the same hostname, per the hostname hannah command.
• Step 2. The hostname is changed in configuration mode using the hostname jessie command.
• Step 3. The show running-config and show startup-config commands show the fact that the hostnames are now different, with the hostname jessie command found only in the running-config.

The configuration process updates the running-config file, which is lost if the router loses power or is reloaded.

Clearly, IOS needs to provide us a way to copy the running configuration so that it will not be lost, so it will be used the next time the switch reloads or powers on.

For instance, Example 5 ended with a different running configuration (with the hostname jessie command) versus the startup configuration.

In short, the EXEC command copy running-config startup-config backs up the running-config to the startup-config file. This command overwrites the current startup-config file with what is currently in the running-configuration file.

In addition, in lab, you may want to just get rid of all existing configuration and start over with a clean configuration. To do that, you can erase the startup-config file using three different commands:

write erase
erase startup-config
erase nvram:

Once the startup-config file is erased, you can reload or power off/on the switch, and it will boot with the now-empty startup configuration.

Note that Cisco IOS does not have a command that erases the contents of the running-config file. To clear out the running-config file, simply erase the startup-config file, and then reload the switch, and the running-config will be empty at the end of the process.

NOTE: Cisco uses the term reload to refer to what most PC operating systems call rebooting or restarting. In each case, it is a re-initialization of the software. The reload EXEC command causes a switch to reload.

The TCP/IP network layer (Layer 3) defines how to deliver IP packets over the entire trip, from the original device that creates the packet to the device that needs to receive the packet.

That process requires cooperation among several different jobs and concepts on a number of devices.

• IP routing: The process of hosts and routers forwarding IP packets (Layer 3 protocol data units [PDU]), while relying on the underlying LANs and WANs to forward the bits.
• IP addressing: Addresses used to identify a packet’s source and destination host computer. Addressing rules also organize addresses into groups, which greatly assists the routing process.
• IP routing protocol: A protocol that aids routers by dynamically learning about the IP address groups so that a router knows where to route IP packets so that they go to the right destination host.
• Other utilities: The network layer also relies on other utilities. For TCP/IP, these utilities include Domain Name System (DNS), Address Resolution Protocol (ARP), and ping.

Note that all these functions have variations both for the well-established IP version 4 (IPv4) and for the emerging newer IP version 6 (IPv6). 

Many protocol models have existed over the years, but today the TCP/IP model dominates.

And at the network layer of TCP/IP, two options exist for the main protocol around which all other network layer functions revolve: IP version 4 (IPv4) and IP version 6 (IPv6).

Both IPv4 and IPv6 define the same kinds of network layer functions, but with different details.

IP focuses on the job of routing data, in the form of IP packets, from the source host to the destination host.

IP does not concern itself with the physical transmission of data, instead relying on the lower TCP/IP layers to do the physical transmission of the data.

Instead, IP concerns itself with the logical details, rather than physical details, of delivering data.

In particular, the network layer specifies how packets travel end to end over a TCP/IP network, even when the packet crosses many different types of LAN and WAN links.

Routers and end-user computers (called hosts in a TCP/IP network) work together to perform IP routing.

The host operating system (OS) has TCP/IP software, including the software that implements the network layer.

Hosts use that software to choose where to send IP packets, often to a nearby router. Those routers make choices of where to send the IP packet next.

Together, the hosts and routers deliver the IP packet to the correct destination, as shown in the example in the diagram below.

The IP packet, created by PC1, goes from the top of the figure all the way to PC2 at the bottom of the figure.

NOTE: The term path selection is sometimes used to refer to the routing process shown in previous diagram. At other times, it refers to routing protocols, specifically how routing protocols select the best route among the competing routes to the same destination.

Host Forwarding Logic: Send the Packet to the Default Router

In prior diagram, PC1 does some basic analysis, and then chooses to send the IP packet to the router so that the router will forward the packet.

PC1 analyzes the destination address and realizes that PC2’s address (168.1.1.1) is not on the same LAN as PC1.

So PC1’s logic tells it to send the packet to a device whose job it is to know where to route data: a nearby router, on the same LAN, called PC1’s default router.

To send the IP packet to the default router, the sender sends a data-link frame across the medium to the nearby router; this frame includes the packet in the data portion of the frame.

That frame uses data link layer (Layer 2) addressing in the data-link header to ensure that the nearby router receives the frame.

NOTE: The default router is also referred to as the default gateway.

R1 and R2’s Logic: Routing Data Across the Network

All routers use the same general process to route the packet.

Each router keeps an IP routing table. This table lists IP address groupings, called IP networks and IP subnets.

When a router receives a packet, it compares the packet’s destination IP address to the entries in the routing table and makes a match. This matching entry also lists directions that tell the router where to forward the packet next.

In the above diagram, R1 would have matched the destination address (168.1.1.1) to a routing table entry, which in turn told R1 to send the packet to R2 next.

Similarly, R2 would have matched a routing table entry that told R2 to send the packet, over an Ethernet over MPLS (EoMPLS) link, to R3 next.

The routing concept works a little like driving down the freeway when approaching a big interchange. You look up and see signs for nearby towns, telling you which exits to take to go to each town.

Similarly, the router looks at the IP routing table (the equivalent of the road signs) and directs each packet over the correct next LAN or WAN link (the equivalent of a road).

R3’s Logic: Delivering Data to the End Destination

The final router in the path, R3, uses almost the same logic as R1 and R2, but with one minor difference. R3 needs to forward the packet directly to PC2, not to some other router. 

While the network layer routing logic ignores the physical transmission details, the bits still have to be transmitted.

To do that work, the network layer logic in a host or router must hand off the packet to the data link layer protocols, which, in turn, ask the physical layer to actually send the data.

The data link layer adds the appropriate header and trailer to the packet, creating a frame, before sending the frames over each physical network.

The routing process forwards the network layer packet from end to end through the network, while each data-link frame only takes a smaller part of the trip.

Each successive data link layer frame moves the packet to the next device that thinks about network layer logic.

In short, the network layer thinks about the bigger view of the goal, like “Send this packet to the specified next device...,” while the data link layer thinks about the specifics, like “Encapsulate the packet in a data-link frame and transmit it.”

The diagram below points out the key encapsulation logic on each device.

Because the routers build new data-link headers and trailers, and because the new headers contain data-link addresses, the PCs and routers must have some way to decide what data-link addresses to use.

An example of how the router determines which data-link address to use is the IP Address Resolution Protocol (ARP). ARP dynamically learns the data-link address of an IP host connected to a LAN.

For example, at the last step, at the bottom of above diagram, Router R3 would use ARP once to learn PC2’s MAC address before sending any packets to PC2.

Routing as covered so far has two main concepts:

• The process of routing forwards Layer 3 packets, also called Layer 3 protocol data units (L3 PDU), based on the destination Layer 3 address in the packet.
• The routing process uses the data link layer to encapsulate the Layer 3 packets into Layer 2 frames for transmission across each successive data link.

IP defines network layer addresses that identify any host or router interface that connects to a TCP/IP network.

The idea basically works like a postal address: Any interface that expects to receive IP packets needs an IP address, just like you need a postal address before receiving mail from the postal service.

TCP/IP groups IP addresses together so that IP addresses used on the same physical network are part of the same group.

IP calls these address groups an IP network or an IP subnet.

Using that same postal service analogy, each IP network and IP subnet works like a postal code (or ZIP code). All nearby postal addresses are in the same postal code (ZIP code), while all nearby IP addresses must be in the same IP network or IP subnet.

IP defines specific rules about which IP address should be in the same IP network or IP subnet.

Numerically, the addresses in the same group have the same value in the first part of the addresses.

For example, the previous diagrams could have used the following conventions:

• Hosts on the top Ethernet: Addresses start with 10
• Hosts on the R1-R2 serial link: Addresses start with 168.10
• Hosts on the R2-R3 EoMPLS link: Addresses start with 168.11
• Hosts on the bottom Ethernet: Addresses start with 168.1

To make routing more efficient, network layer protocols group addresses, both by their location and by the actual address values. A router can list one routing table entry for each IP network or subnet, instead of one entry for every single IP address.

The routing process also makes use of a 20-byteIPv4 header, as shown in below diagram. 

The header lists a 32-bit source IP address, as well as a 32-bit destination IP address. 

For routing logic to work on both hosts and routers, each needs to know something about the TCP/IP internetwork.

Hosts need to know the IP address of their default router so that hosts can send packets to remote destinations.

Routers, however, need to know routes so that routers know how to forward packets to each and every IP network and IP subnet.

Although a network engineer could configure (type) all the required routes, on every router, most network engineers instead simply enable a routing protocol on all routers.

If you enable the same routing protocol on all the routers in a TCP/IP internetwork, with the correct settings, the routers will send routing protocol messages to each other.

As a result, all the routers will learn routes for all the IP networks and subnets in the TCP/IP internetwork.

Diagram below shows an example.

In this case, IP network 168.1.0.0, which consists of all addresses that begin with 168.1, sits on the Ethernet at the bottom of the diagram. 

R3, knowing this fact, sends a routing protocol message to R2 (Step 1).

R2 learns a route for network 168.1.0.0 as a result, as shown on the left.

At Step 2, R2 turns around and sends a routing protocol message to R1 so that R1 now has a route for that same IP network (168.1.0.0).

One of the most important concept in your CCNA study is the understanding of IP addresses, their formats, the grouping concepts, how to subdivide groups into subnets, how to interpret the documentation for existing networks’ IP addressing, and so on.

Simply put, you had better know addressing and subnetting!

If a device wants to communicate using TCP/IP, it needs an IP address.

When the device has an IP address and the appropriate software and hardware, it can send and receive IP packets.

Any device that has at least one interface with an IP address can send and receive IP packets and is called an IP host.

IP addresses consist of a 32-bit number, usually written in dotted-decimal notation (DDN).

The “decimal” part of the term comes from the fact that each byte (8 bits) of the 32-bit IP address is shown as its decimal equivalent.

The four resulting decimal numbers are written in sequence, with “dots,” or decimal points, separating the numbers—hence the name dotted-decimal.

For example, 168.1.1.1 is an IP address written in dotted-decimal form; the actual binary version is 10101000 00000001 00000001 00000001.

Each DDN has four decimal octets, separated by periods. The term octet is just a vendor-neutral term for byte.

Because each octet represents an 8-bit binary number, the range of decimal numbers in each octet is between 0 and 255, inclusive.

For example, the IP address of 168.1.1.1 has a first octet of 168, the second octet of 1, and so on.

Finally, note that each network interface uses a unique IP address. Most people tend to think that their computer has an IP address, but actually their computer’s network card has an IP address.

For example, if your laptop has both an Ethernet network interface card (NIC) and a wireless NIC, with both working at the same time, both will have an IP address.

Similarly, routers, which typically have many network interfaces that forward IP packets, have an IP address for each interface.

The original specifications for TCP/IP grouped IP addresses into sets of consecutive addresses called IP networks.

The addresses in a single IP network have the same numeric value in the first part of all addresses in the network.

The diagram below shows a simple internetwork that has three separate IP networks.

The diagram lists a network identifier (network ID) for each network, as well as a text description of the DDN values in each network. 

For example, the hosts in the Ethernet LAN on the far left use IP addresses that begin with a first octet of 8; the network ID happens to be 8.0.0.0.

As another example, the serial link between R1 and R2 consists of only two interfaces—a serial interface on each router—and uses an IP address that begins with the three octets 199.1.1.

The above diagram also provides a good figure with which to discuss two important facts about how IPv4 groups IP addresses:

• All IP addresses in the same group must not be separated from each other by a router.
• IP addresses separated from each other by a router must be in different groups.

Take the first of the two rules, and look at hosts A and B on the left.

Hosts A and B are in the same IP network and have IP addresses that begin with 8.

Per the first rule, hosts A and B cannot be separated from each other by a router (and they are indeed not separated from each other by a router).

Next, take the second of the two rules and add host C to the discussion. Host C is separated from host A by at least one router, so host C cannot be in the same IP network as host A. Host C’s address cannot begin with 8.

Likewise, IP routing relies on all addresses in one IP network or IP subnet being in the same location, specifically on a single instance of a LAN or WAN data link. Otherwise, the routers might deliver IP packets to the wrong locations.

For any TCP/IP internetwork, each LAN and WAN link will use either an IP network or an IP subnet. 

Class A, B, and C IP Networks

The IPv4 address space includes all possible combinations of numbers for a 32-bit IPv4 address.

Literally 232 different values exist with a 32-bit number, for more than 4 billion different numbers.

With DDN values, these numbers include all combinations of the values 0 through 255 in all four octets: 0.0.0.0, 0.0.0.1, 0.0.0.2, and all the way up to 255.255.255.255.

IP standards first subdivide the entire address space into classes, as identified by the value of the first octet.

• Class A gets roughly half of the IPv4 address space, with all DDN numbers that begin with 1–126.. 
• Class B gets one-fourth of the address space, with all DDN numbers that begin with 128–191 inclusive.
• Class C gets one-eighth of the address space, with all numbers that begin with 192–223.

See diagram below for details.

The diagram also notes the purpose for the five address classes.

• Classes A, B, and C define unicast IP addresses, meaning that the address identifies a single host interface. 
• Class D defines multicast addresses, used to send one packet to multiple hosts.
• Class E originally defined experimental addresses but are now reserved for future use.

IPv4 standards also subdivide the Class A, B, and C unicast classes into predefined IP networks.

Each IP network makes up a subset of the DDN values inside the class.

IPv4 uses three classes of unicast addresses so that the IP networks in each class can be different sizes, and therefore meet different needs.

Class A networks each support a very large number of IP addresses (more than 16 million host addresses per IP network).

However, because each Class A network is so large, Class A holds only 126 Class A networks.

Class B defines IP networks that have 65,534 addresses per network, but with space for more than 16,000 such networks.

Class C defines much smaller IP networks, with 254 addresses each.

See the diagram below for details.

The diagram shows a visual perspective, as well as the literal numbers, for all the Class A, B, and C IPv4 networks in the entire world. It shows clouds for IP networks.

It, of course, does not show one cloud for every possible network, but shows the general idea, with a small number of large clouds for Class A and a large number of small clouds for Class C.

The Actual Class A, B, and C IP Networks

The previous diagram shows the number of Class A, B, and C IP networks in the entire world.

Eventually, you need to actually pick and use some of these IP networks to build a working TCP/IP internetwork, so you need to be able to answer the question: What are the specific IP networks?

First, you must be able to identify each network briefly using a network identifier (network ID).

The network ID is just one reserved DDN value per network that identifies the IP network. (The network ID cannot be used by a host as an IP address.)

For example, the table shows the network IDs that match the given diagram.

NOTE: Many people use the term network ID, but others use the terms network number and network address. Be ready to use all three terms.

So, what are the actual Class A, B, and C IP networks, and what are their network IDs?

First, consider the Class A networks. As learned, only 126 Class A networks exist. 

As it turns out, they consist of all addresses that begin with 1, all addresses that begin with 2, all addresses that begin with 3, and so on, up through the 126th such network of “all addresses that begin with 126.”

The table below lists a few of these networks.

Class B networks have a first octet value between 128 and 191, inclusive, but in a single Class B network, the addresses have the same value in the first two octets.

For example, our previous diagram uses Class B network 130.4.0.0. The DDN value 130.4.0.0 must be in Class B, because the first octet is between 128 and 191, inclusive.

However, the first two octets define the addresses in a single Class B network.

Table below lists some sample IPv4 Class B networks.

Class C networks can also be easily identified, with a first octet value between 192 and 223, inclusive.

With Class C networks and addresses, the first three octets define the group, with addresses in one Class C network having the same value in the first three octets.

Table below shows some samples.

Listing all the Class A, B, and C networks would of course take too much space.

Table below summarizes the first octet values that identify the class and summarizes the range of Class A, B, and C network numbers available in the entire IPv4 address space.

NOTE: The term classful IP network refers to any Class A, B, or C network, because it is defined by Class A, B, and C rules.

Like IP addressing, IP subnetting is also one of the most important topics that a Network Engineer needs to master.

Subnetting defines methods of further subdividing the IPv4 address space into groups that are smaller than a single IP network.

IP subnetting defines a flexible way for anyone to take a single Class A, B, or C IP network and further subdivide it into even smaller groups of consecutive IP addresses.

In fact, the name subnet is just shorthand for subdivided network. Then, in each location where you used to use an entire Class A, B, or C network, you can use a smaller subnet, wasting fewer IP addresses.

To make it clear how an internetwork can use both classful IPv4 networks as well as subnets of classful IPv4 networks, the next two diagrams show the same internetwork, one with classful networks only and one with subnets only. The first diagram uses five Class B networks with no subnetting.

The design in 1st diagram below requires five groups of IP addresses, each of which is a Class B network in this example.

Specifically, the three LANs each use a single Class B network, and the two serial links each use a Class B network.

It wastes many IP addresses, because each Class B network has 216 – 2 host addresses—far more than you will ever need for each LAN and WAN link.

For example, the Ethernet on the left uses an entire Class B network, which supports 65,534 IP addresses that begin with 150.1.

However, a single LAN seldom grows past a few hundred devices, so many of the IP addresses in Class B network 150.1.0.0 would be wasted. Even more waste occurs on the point-to-point serial links, which need only two IP addresses.

The 2nd diagram illustrates a more common design today, one that uses basic subnetting. As in the previous diagram, it needs five groups of addresses.

However, in this case, the figure uses five subnets of Class B network 150.9.0.0.

Subnetting allows the network engineer for the TCP/IP internetwork to choose to use a longer part of the addresses that must have the same value.

Subnetting allows quite a bit of flexibility, but 2nd diagram above shows one of the simplest forms of subnetting.

In this case, each subnet includes the addresses that begin with the same value in the first three octets, as follows:

• One group of the 254 addresses that begin with 150.9.1
• One group of the 254 addresses that begin with 150.9.2
• One group of the 254 addresses that begin with 150.9.3
• One group of the 254 addresses that begin with 150.9.4
• One group of the 254 addresses that begin with 150.9.5

As a result of using subnetting, the network engineer has saved many IP addresses.

First, only a small part of Class B network 150.9.0.0 has been used so far. Each subnet has 254 addresses, which should be plenty of addresses for each LAN, and more than enough for the WAN links.

In summary, you now know some of the details of IP addressing, with a focus on how it relates to routing. Each host and router interface will have an IP address.

However, the IP addresses will not be randomly chosen but will instead be grouped together to aid the routing process.

The groups of addresses can be an entire Class A, B, or C network number or it can be a subnet.

Hosts actually use some simple routing logic when choosing where to send a packet. If you assume that the design uses subnets (which is typical), this two-step logic is as follows:

• Step 1. If the destination IP address is in the same IP subnet as I am, send the packet directly to that destination host.
• Step 2. Otherwise, send the packet to my default gateway, also known as a default router. (This router has an interface on the same subnet as the host.)

For example, consider the diagram below and focus on the Ethernet LAN on the left.

When PC1 sends an IP packet to PC11 (150.9.1.11), PC1 first considers some match related to subnetting.

PC1 concludes that PC11’s IP address is in the same subnet as PC1, so PC1 ignores its default router (Core, 150.9.1.1), sending the packet directly to PC11, as shown in Step 1 of the diagram.

Alternatively, when PC1 sends a packet to PC2 (150.9.4.10), PC1 does the same kind of subnetting math, and realizes that PC2 is not on the same subnet as PC1.

So, PC1 forwards the packet (Step 2) to its default gateway, 150.9.1.1, which then routes the packet to PC2.

A Summary of Router Forwarding Logic

First, when a router receives a data-link frame addressed to that router’s data-link address, the router needs to think about processing the contents of the frame.

When such a frame arrives, the router uses the following logic on the data-link frame:

• Step 1. Use the data-link Frame Check Sequence (FCS) field to ensure that the frame had no errors; if errors occurred, discard the frame.
• Step 2. Assuming that the frame was not discarded at Step 1, discard the old data-link header and trailer, leaving the IP packet.
• Step 3. Compare the IP packet’s destination IP address to the routing table, and find the route that best matches the destination address. This route identifies the outgoing interface of the router, and possibly the next-hop router IP address.
• Step 4. Encapsulate the IP packet inside a new data-link header and trailer, appropriate for the outgoing interface, and forward the frame.

With these steps, each router forwards the packet to the next location, inside a data-link frame.

With each router repeating this process, the packet reaches its final destination.

While the router does all the steps in the list, Step 3 is the main routing or forwarding step.

The packet has a destination IP address in the header, whereas the routing table lists slightly different numbers, typically a list of networks and subnets.

To match a routing table entry, the router thinks like this:

• Network numbers and subnet numbers represent a group of addresses that begin with the same prefix.
• Think about those numbers as groups of addresses. 
• In which of the groups does this packet’s destination address reside?

The next example shows specific examples of matching the routing table.

A Detailed Routing Example

The routing example uses the diagram below.

In this example, all routers happen to use the Open Shortest Path First (OSPF) routing protocol, and all routers know routes for all subnets.

In particular, PC2, at the bottom, sits in subnet 150.150.4.0, which consists of all addresses that begin with 150.150.4.

In the example, PC1 sends an IP packet to 150.150.4.10, PC2’s IP address.

NOTE: Note that the routers all know in this case that “subnet 150.150.4.0” means “all addresses that begin with 150.150.4.”

The following list explains the forwarding logic at each step in the diagram above.

(Note that the text refers to Steps 1, 2, 3, and 4 of the routing logic shown in the previous section -- A Summary of Router Forwarding Logic)

• Step A 
  • PC1 sends the packet to its default router.
  • PC1 first builds the IP packet, with a destination address of PC2’s IP address (150.150.4.10).
  • PC1 needs to send the packet to R1 (PC1’s default router) because the destination address is on a different subnet.
  • PC1 places the IP packet into an Ethernet frame, with a destination Ethernet address of R1’s Ethernet address.
  • PC1 sends the frame on to the Ethernet. (Note that the figure omits the data-link trailers.)
• Step B
  • R1 processes the incoming frame and forwards the packet to R2.
  • Because the incoming Ethernet frame has a destination MAC of R1’s Ethernet MAC, R1 copies the frame off the Ethernet for processing.
  • R1 checks the frame’s FCS, and no errors have occurred (Step 1).
  • R1 then discards the Ethernet header and trailer (Step 2).
  • Next, R1 compares the packet’s destination address (150.150.4.10) to the routing table and finds the entry for subnet 150.150.4.0—which includes addresses 150.150.4.0 through 150.150.4.255 (Step 3).
  • Because the destination address is in this group, R1 forwards the packet out interface Serial0 to next-hop Router R2 (150.150.2.7) after encapsulating the packet in a High-Level Data Link Control (HDLC) frame (Step 4).
• Step C
  • R2 processes the incoming frame and forwards the packet to R3.
  • R2 repeats the same general process as R1 when R2 receives the HDLC frame.
  • R2 checks the FCS field and finds that no errors occurred (Step 1).
  • R2 then discards the HDLC header and trailer (Step 2).
  • Next, R2 finds its route for subnet 150.150.4.0—which includes the address range 150.150.4.0–150.150.4.255—and realizes that the packet’s destination address 150.150.4.10 matches that route (Step 3).
  • Finally, R2 sends the packet out interface Fast Ethernet 0/0 to next-hop router 150.150.3.1 (R3) after encapsulating the packet in an Ethernet header (Step 4).
• Step D
  • R3 processes the incoming frame and forwards the packet to PC2.
  • Like R1 and R2, R3 checks the FCS, discards the old data-link header and trailer, and matches its own route for subnet 150.150.4.0.
  • R3’s routing table entry for 150.150.4.0 shows that the outgoing interface is R3’s Ethernet interface, but there is no next-hop router because R3 is connected directly to subnet 150.150.4.0.
  • All R3 has to do is encapsulate the packet inside a new Ethernet header and trailer, with a destination Ethernet address of PC2’s MAC address, and forward the frame.

The routing (forwarding) process depends heavily on having an accurate and up-to-date IP routing table on each router.

Goals of a routing protocol, regardless of how the routing protocol works

• To dynamically learn and fill the routing table with a route to each subnet in the internetwork.
• If more than one route to a subnet is available, to place the best route in the routing table.
• To notice when routes in the table are no longer valid, and to remove them from the routing table.
• If a route is removed from the routing table and another route through another neighboring router is available, to add the route to the routing table. (Many people view this goal and the preceding one as a single goal.)
• To work quickly when adding new routes or replacing lost routes. (The time between losing the route and finding a working replacement route is called convergence time.)
• To prevent routing loops.

Routing protocols all use some similar ideas to allow routers to learn routing information from each other.

Of course, each routing protocol works differently; otherwise, you would not need more than one routing protocol.

However, many routing protocols use the same general steps for learning routes:

• Step 1. Each router, independent of the routing protocol, adds a route to its routing table for each subnet directly connected to the router.
• Step 2. Each router’s routing protocol tells its neighbors about the routes in its routing table, including the directly connected routes and routes learned from other routers.
• Step 3. After learning a new route from a neighbor, the router’s routing protocol adds a route to its IP routing table, with the next-hop router of that route typically being the neighbor from which the route was learned.

For example, consider below diagram which is similar to previous one, but now with a focus on how the three routers each learned about subnet 150.150.4.0.

Note that routing protocols do more work than is implied in the figure; this figure just focuses on how the routers learn about subnet 150.150.4.0.

Follow items A through F shown in the diagram to see how each router learns its route to 150.150.4.0.

​(Note that the text refers to Steps 1, 2, 3, and 4 of the routing logic shown in the previous section -- A Summary of Router Forwarding Logic)

• Step A
  • Subnet 150.150.4.0 exists as a subnet at the bottom of the diagram, connected to Router R3.
• Step B
  • R3 adds a connected route for 150.150.4.0 to its IP routing table (Step 1); this happens without help from the routing protocol.
• Step C
  • R3 sends a routing protocol message, called a routing update, to R2, causing R2 to learn about subnet 150.150.4.0 (Step 2).
• Step D
  • R2 adds a route for subnet 150.150.4.0 to its routing table (Step 3).
• Step E
  • R2 sends a similar routing update to R1, causing R1 to learn about subnet 150.150.4.0 (Step 2).
• Step F
  • R1 adds a route for subnet 150.150.4.0 to its routing table (Step 3).
  • The route lists R1’s own Serial0 as the outgoing interface and R2 as the next-hop router IP address (150.150.2.7).

The TCP/IP network layer defines many functions beyond the function defined by the IPv4 protocol.

Sure, IPv4 plays a huge role in networking today, defining IP addressing and IP routing.

However, other protocols and standards, defined in other Requests For Comments (RFC), play an important role for network layer functions as well.

For example, routing protocols like Open Shortest Path First (OSPF) exist as separate protocols, defined in separate RFCs.

This section introduces three other network layer features that should be helpful and give some perspective and make sense on future discussions. 

The three topics are:

• Domain Name System (DNS)
• Address Resolution Protocol (ARP)
• Ping

Can you imagine a world in which every time you used an application, you had to think about the other computer and refer to it by IP address?

Instead of using easy names like google.com or facebook.com, you would have to remember and type IP addresses, like 74.125.225.5.

Certainly, that would not be user friendly and could drive some people away from using computers at all.

Thankfully, TCP/IP defines a way to use hostnames to identify other computers.

The user either never thinks about the other computer or refers to the other computer by name. Then, protocols dynamically discover all the necessary information to allow communications based on that name.

For example, when you open a web browser and type in the hostname www.google.com, your computer does not send an IP packet with destination IP address www.google.com; it sends an IP packet to an IP address used by the web server for Google.

TCP/IP needs a way to let a computer find the IP address used by the listed hostname, and that method uses the Domain Name System (DNS).

Enterprises use the DNS process to resolve names into the matching IP address, as shown in the example in diagram below. 

In this case, PC11, on the left, needs to connect to a server named Server1.

At some point, the user either types in the name Server1 or some application on PC11 refers to that server by name.

At Step 1, PC11 sends a DNS message—a DNS query—to the DNS server.

At Step 2, the DNS server sends back a DNS reply that lists Server1’s IP address.

At Step 3, PC11 can now send an IP packet to destination address 10.1.2.3, the address used by Server1.

Note that the example in above diagram shows a cloud for the TCP/IP network because the details of the network, including routers, do not matter to the name resolution process.

Routers treat the DNS messages just like any other IP packet, routing them based on the destination IP address.

For example, at Step 1 in the figure, the DNS query will list the DNS server’s IP address as the destination address, which any routers will use to forward the packet.

Finally, DNS defines much more than just a few messages. DNS defines protocols, as well as standards for the text names used throughout the world, and a worldwide set of distributed DNS servers.

The domain names that people use every day when web browsing, which look like www.example.com, follow the DNS naming standards.

Also, no single DNS server knows all the names and matching IP addresses, but the information is distributed across many DNS servers.

So, the DNS servers of the world work together, forwarding queries to each other, until the server that knows the answer supplies the desired IP address information.

IP routing logic requires that hosts and routers encapsulate IP packets inside data link layer frames.

In previous diagrams and examples, it shows how every router de-encapsulates each IP packet and encapsulates the IP packet inside a new data-link frame.

On Ethernet LANs, whenever a host or router needs to encapsulate an IP packet in a new Ethernet frame, the host or router knows all the important facts to build that header—except for the destination MAC address.

The host knows the IP address of the next device, either another host IP address or the default router IP address.

A router knows the IP route used for forwarding the IP packet, which lists the next router’s IP address.

However, the hosts and routers do not know those neighboring devices’ MAC addresses beforehand.

TCP/IP defines the Address Resolution Protocol (ARP) as the method by which any host or router on a LAN can dynamically learn the MAC address of another IP host or router on the same LAN.

ARP defines a protocol that includes the ARP Request, which is a message that asks the simple request “if this is your IP address, please reply with your MAC address.”

ARP also defines the ARP Reply message, which indeed lists both the original IP address and the matching MAC address.

The diagram below shows the ARP Request on the left as a LAN broadcast, so all hosts receive the frame.

On the right, at Step 2, host PC2 sends back an ARP Reply, identifying PC2’s MAC address.

The text beside each message shows the contents inside the ARP message itself, which lets PC2 learn R3’s IP address and matching MAC address, and R3 learn PC2’s IP address and matching MAC address.

Note that hosts remember the ARP results, keeping the information in their ARP cache or ARP table.

A host or router only needs to use ARP occasionally, to build the ARP cache the first time.

Each time a host or router needs to send a packet encapsulated in an Ethernet frame, it first checks its ARP cache for the correct IP address and matching MAC address.

Hosts and routers will let ARP cache entries time out to clean up the table, so occasional ARP Requests can be seen.

NOTE: You can see the contents of the ARP cache on most PC operating systems by using the arp -a command from a command prompt.

After you have implemented a TCP/IP internetwork, you need a way to test basic IP connectivity without relying on any applications to be working.

The primary tool for testing basic network connectivity is the ping command.

Ping (Packet Internet Groper) uses the Internet Control Message Protocol (ICMP), sending a message called an ICMP echo request to another IP address.

The computer with that IP address should reply with an ICMP echo reply. If that works, you successfully have tested the IP network.

In other words, you know that the network can deliver a packet from one host to the other and back.

ICMP does not rely on any application, so it really just tests basic IP connectivity—Layers 1, 2, and 3 of the OSI model.

Diagram below outlines the basic process.

Note that while the ping command uses ICMP, ICMP does much more. 

ICMP defines many messages that devices can use to help manage and control the IP network. More of ICMP in future discussions.

Let's start with the basics of networking.

Because networks require all the devices to follow the rules, this part starts with a discussion of networking models, which gives you a big-picture view of the networking rules.

You can think of a networking model as you think of a set of architectural plans for building a house. A lot of different people work on building your house, such as framers, electricians, bricklayers, painters, and so on.

The blueprint helps ensure that all the different pieces of the house work together as a whole.

Similarly, the people who make networking products, and the people who use those products to build their own computer networks, follow a particular networking model.

That networking model defines rules about how each part of the network should work, as well as how the parts should work together, so that the entire network functions correctly.

Transmission Control Protocol/Internet Protocol (TCP/IP). TCP/IP is the most pervasively used networking model in the history of networking.

You can find support for TCP/IP on practically every computer operating system (OS) in existence today, from mobile phones to mainframe computers.

Every network built using Cisco products today supports TCP/IP.

TCP/IP is compared to a second networking model, called the Open Systems Interconnection (OSI) reference model.

Historically, OSI was the first large effort to create a vendor-neutral networking model. Because of that timing, many of the terms used in networking today come from the OSI model.

So, you are new to networking. Like many people, your perspective about networks might be that of a user of the network, as opposed to the network engineer who builds networks.

For some, your view of networking might be based on how you use the Internet, from home, using a high-speed Internet connection like digital subscriber line (DSL) or cable TV, as shown in the diagram below.

The top part of the figure shows a typical high-speed cable Internet user.

The PC connects to a cable modem using an Ethernet cable. The cable modem then connects to a cable TV (CATV) outlet in the wall using a round coaxial cable—the same kind of cable used to connect your TV to the CATV wall outlet.

Because cable Internet services provide service continuously, the user can just sit down at the PC and start sending email, browsing websites, making Internet phone calls, and using other tools and applications.

The lower part of the figure uses two different technologies.

First, the tablet computer uses wireless technology that goes by the name wireless local-area network (wireless LAN), or Wi-Fi, instead of using an Ethernet cable. In this example, the router uses a different technology, DSL, to communicate with the Internet.

Both home-based networks and networks built for use by a company make use of similar networking technologies. The Information Technology (IT) world refers to a network created by one corporation, or enterprise, for the purpose of allowing its employees to communicate, as an enterprise network.

The smaller networks at home, when used for business purposes, often go by the name small office/home office (SOHO) networks.

Users of enterprise networks have some idea about the enterprise network at their company or school. People realize that they use a network for many tasks.

PC users might realize that their PC connects through an Ethernet cable to a matching wall outlet, as shown at the top of diagram below. Those same users might use wireless LANs with their laptop when going to a meeting in the conference room as well. The diagram shows these two end-user perspectives on an enterprise network.

NOTE: In networking diagrams, a cloud represents a part of a network whose details are not important to the purpose of the diagram. In this case, the above diagram ignores the details of how to create an enterprise network.

Some users might not even have a concept of the network at all.

Instead, these users just enjoy the functions of the network—the ability to post messages to social media sites, make phone calls, search for information on the Internet, listen to music, and download countless apps to their phones—without caring about how it works or how their favorite device connects to the network.

In the building business, much work happens before you nail the first boards together. The process starts with some planning, an understanding of how to build a house, and some architectural blueprints of how to build that specific house.

Similarly, the journey toward building any computer network does not begin by installing devices and cables, but instead by looking at the architectural plans for those modern networks: the TCP/IP model.

A networking model, sometimes also called either a networking architecture or networking blueprint, refers to a comprehensive set of documents.

Individually, each document describes one small function required for a network; collectively, these documents define everything that should happen for a computer network to work.

Some documents define a protocol, which is a set of logical rules that devices must follow to communicate.

Other documents define some physical requirements for networking. For example, a document could define the voltage and current levels used on a particular cable when transmitting data.

You can think of a networking model as you think of an architectural blueprint for building a house.

Sure, you can build a house without the blueprint.

However, the blueprint can ensure that the house has the right foundation and structure so that it will not fall down, and it has the correct hidden spaces to accommodate the plumbing, electrical, gas, and so on.

Also, the many different people that build the house using the blueprint—such as framers, electricians, bricklayers, painters, and so on—know that if they follow the blueprint, their part of the work should not cause problems for the other workers.

Similarly, you could build your own network—write your own software, build your own networking cards, and so on—to create a network.

However, it is much easier to simply buy and use products that already conform to some well-known networking model or blueprint.

Because the networking product vendors build their products with some networking model in mind, their products should work well together.

Today, the world of computer networking uses one networking model: TCP/IP.

However, the world has not always been so simple.

Once upon a time, networking protocols didn’t exist, including TCP/IP.

Vendors created the first networking protocols; these protocols supported only that vendor’s computers.

For example, IBM published its Systems Network Architecture (SNA) networking model in 1974.

Other vendors also created their own proprietary networking models.

As a result, if your company bought computers from three vendors, network engineers often had to create three different networks based on the networking models created by each company, and then somehow connect those networks, making the combined networks much more complex.

The left side of the diagram below shows the general idea of what a company’s enterprise network might have looked like back in the 1980s, before TCP/IP became common in enterprise internetworks.

Although vendor-defined proprietary networking models often worked well, having an open, vendor-neutral networking model would aid competition and reduce complexity.

The International Organization for Standardization (ISO) took on the task to create such a model, starting as early as the late 1970s, beginning work on what would become known as the Open Systems Interconnection (OSI) networking model.

ISO had a noble goal for the OSI model: to standardize data networking protocols to allow communication among all computers across the entire planet.

ISO worked toward this ambitious and noble goal, with participants from most of the technologically developed nations on Earth participating in the process.

A second, less-formal effort to create an open, vendor-neutral, public networking model sprouted forth from a U.S. Department of Defense (DoD) contract.

Researchers at various universities volunteered to help further develop the protocols surrounding the original DoD work. These efforts resulted in a competing open networking model called TCP/IP.

During the 1990s, companies began adding OSI, TCP/IP, or both to their enterprise networks. However, by the end of the 1990s, TCP/IP had become the common choice, and OSI fell away.

The center part of diagram above shows the general idea behind enterprise networks in that decade—still with networks built upon multiple networking models but including TCP/IP.

Here in the twenty-first century, TCP/IP dominates.

Proprietary networking models still exist, but they have mostly been discarded in favor of TCP/IP.

The OSI model, whose development suffered in part because of a slower formal standardization process as compared with TCP/IP, never succeeded in the marketplace.

And TCP/IP, the networking model originally created almost entirely by a bunch of volunteers, has become the most prolific network model ever, as shown on the right side of diagram above.

The TCP/IP model both defines and references a large collection of protocols that allow computers to communicate.

To define a protocol, TCP/IP uses documents called Requests For Comments (RFC). (You can find these RFCs using any online search engine.)

The TCP/IP model also avoids repeating work already done by some other standards body or vendor consortium by simply referring to standards or protocols created by those groups.

For example, the Institute of Electrical and Electronic Engineers (IEEE) defines Ethernet LANs; the TCP/IP model does not define Ethernet in RFCs, but refers to IEEE Ethernet as an option.

An easy comparison can be made between telephones and computers that use TCP/IP. You go to the store and buy a phone from one of a dozen different vendors.

When you get home and plug in the phone to the same cable in which your old phone was connected, the new phone works.

The phone vendors know the standards for phones in their country and build their phones to match those standards.

Similarly, when you buy a new computer today, it implements the TCP/IP model to the point that you can usually take the computer out of the box, plug in all the right cables, turn it on, and it connects to the network. You can use a web browser to connect to your favorite website.

How?

Well, the OS on the computer implements parts of the TCP/IP model.

The Ethernet card, or wireless LAN card, built in to the computer implements some LAN standards referenced by the TCP/IP model.

In short, the vendors that created the hardware and software implemented TCP/IP.

To help people understand a networking model, each model breaks the functions into a small number of categories called layers.

Each layer includes protocols and standards that relate to that category of functions. TCP/IP actually has two alternative models, as shown in the diagram below.

The model on the left shows the original TCP/IP model listed in RFC 1122, which breaks TCP/IP into four layers.

The top two layers focus more on the applications that need to send and receive data.

The bottom layer focuses on how to transmit bits over each individual link, with the Internet layer focusing on delivering data over the entire path from the original sending computer to the final destination computer.

The TCP/IP model on the right shows the more common terms and layers used when people talk about TCP/IP today.

It expands the original model’s link layer into two separate layers: data link and physical (similar to the lower two layers of the OSI model). Also, many people commonly use the word “Network” instead of “Internet” for one layer.

NOTE: The original TCP/IP model’s link layer has also been referred to as the network access and network interface layer.

Many of you will have already heard of several TCP/IP protocols, like the examples listed in the table below.

TCP/IP application layer protocols provide services to the application software running on a computer.

The application layer does not define the application itself, but it defines services that applications need.

For example, application protocol HTTP defines how web browsers can pull the contents of a web page from a web server. In short, the application layer provides an interface between software running on a computer and the network itself.

Arguably, the most popular TCP/IP application today is the web browser. Many major software vendors either have already changed or are changing their application software to support access from a web browser.

And thankfully, using a web browser is easy: You start a web browser on your computer and select a website by typing the name of the website, and the web page appears.

HTTP Overview

What really happens to allow that web page to appear on your web browser?

Imagine that Bob opens his browser. His browser has been configured to automatically ask for web server Larry’s default web page, or home page. The general logic looks like the diagram below.

So, what really happened?

Bob’s initial request actually asks Larry to send his home page back to Bob.

Larry’s web server software has been configured to know that the default web page is contained in a file called home.htm.

Bob receives the file from Larry and displays the contents of the file in Bob’s web browser window.

HTTP Protocol Mechanisms

Taking a closer look, this example shows how applications on each endpoint computer—specifically, the web browser application and web server application—use a TCP/IP application layer protocol.

To make the request for a web page and return the contents of the web page, the applications use the Hypertext Transfer Protocol (HTTP).

HTTP did not exist until Tim Berners-Lee created the first web browser and web server in the early 1990s.

Berners-Lee gave HTTP functionality to ask for the contents of web pages, specifically by giving the web browser the ability to request files from the server and giving the server a way to return the content of those files.

The overall logic matches what was shown in above diagram.

Diagram below shows the same idea, but with details specific to HTTP.

NOTE: The full version of most web addresses—also called Uniform Resource Locators (URL) or Universal Resource Identifiers (URI)—begins with the letters http, which means that HTTP is used to transfer the web pages.

To get the web page from Larry, at Step 1, Bob sends a message with an HTTP header.

Generally, protocols use headers as a place to put information used by that protocol. This HTTP header includes the request to “get” a file.

The request typically contains the name of the file (home.htm, in this case), or if no filename is mentioned, the web server assumes that Bob wants the default web page.

Step 2 in the diagram above shows the response from web server Larry. The message begins with an HTTP header, with a return code (200), which means something as simple as “OK” returned in the header.

HTTP also defines other return codes so that the server can tell the browser whether the request worked.

(Here is another example: If you ever looked for a web page that was not found, and then received an HTTP 404 “not found” error, you received an HTTP return code of 404.)

The second message also includes the first part of the requested file.

Step 3 in the diagram shows another message from web server Larry to web browser Bob, but this time without an HTTP header.

HTTP transfers the data by sending multiple messages, each with a part of the file. Rather than wasting space by sending repeated HTTP headers that list the same information, these additional messages simply omit the header.

Although many TCP/IP application layer protocols exist, the TCP/IP transport layer includes a smaller number of protocols.

The two most commonly used transport layer protocols are the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP).

Transport layer protocols provide services to the application layer protocols that reside one layer higher in the TCP/IP model.

How does a transport layer protocol provide a service to a higher-layer protocol? 

TCP Error Recovery Basics

To appreciate what the transport layer protocols do, you must think about the layer above the transport layer, the application layer.

Why?

Well, each layer provides a service to the layer above it, like the error-recovery service provided to application layer protocols by TCP.

For example, in the previous diagram, Bob and Larry used HTTP to transfer the home page from web server Larry to Bob’s web browser.

But what would have happened if Bob’s HTTP GET request had been lost in transit through the TCP/IP network?

Or, what would have happened if Larry’s response, which included the contents of the home page, had been lost?

Well, as you might expect, in either case, the page would not have shown up in Bob’s browser.

TCP/IP needs a mechanism to guarantee delivery of data across a network. Because many application layer protocols probably want a way to guarantee delivery of data across a network, the creators of TCP included an error-recovery feature.

To recover from errors, TCP uses the concept of acknowledgments.

The diagram below outlines the basic idea behind how TCP notices lost data and asks the sender to try again.

Diagram above shows web server Larry sending a web page to web browser Bob, using three separate messages.

The TCP header shows a sequence number (SEQ) with each message.

In this example, the network has a problem, and the network fails to deliver the TCP message (called a segment) with sequence number 2.

When Bob receives messages with sequence numbers 1 and 3, but does not receive a message with sequence number 2, Bob realizes that message 2 was lost.

That realization by Bob’s TCP logic causes Bob to send a TCP segment back to Larry, asking Larry to send message 2 again.

Same-Layer and Adjacent-Layer Interactions

The example in above diagram also demonstrates a function called adjacent-layer interaction, which refers to the concepts of how adjacent layers in a networking model, on the same computer, work together.

In this example, the higher-layer protocol (HTTP) wants error recovery, and the higher layer uses the next lower-layer protocol (TCP) to perform the service of error recovery; the lower layer provides a service to the layer above it.

The diagram also shows an example of a similar function called same-layer interaction.

When a particular layer on one computer wants to communicate with the same layer on another computer, the two computers use headers to hold the information that they want to communicate.

For example, Larry set the sequence numbers to 1, 2, and 3 so that Bob could notice when some of the data did not arrive.

Larry’s TCP process created that TCP header with the sequence number; Bob’s TCP process received and reacted to the TCP segments.

The table below summarizes the key points about how adjacent layers work together on a single computer and how one layer on one computer works with the same networking layer on another computer.

The application layer includes many protocols. The transport layer includes fewer protocols, most notably, TCP and UDP.

The TCP/IP network layer includes a small number of protocols, but only one major protocol: the Internet Protocol (IP).

In fact, the name TCP/IP is simply the names of the two most common protocols (TCP and IP) separated by a /.

IP provides several features, most importantly, addressing and routing. 

Internet Protocol and the Postal Service

Imagine that you just wrote two letters: one to a friend on the other side of the country and one to a friend on the other side of town.

You addressed the envelopes and put on the stamps, so both are ready to give to the postal service. Is there much difference in how you treat each letter?

Not really.

Typically, you would just put them in the same mailbox and expect the postal service to deliver both letters.

The postal service, however, must think about each letter separately, and then make a decision of where to send each letter so that it is delivered.

For the letter sent across town, the people in the local post office probably just need to put the letter on another truck.

For the letter that needs to go across the country, the postal service sends the letter to another post office, then another, and so on, until the letter gets delivered across the country. At each post office, the postal service must process the letter and choose where to send it next.

To make it all work, the postal service has regular routes for small trucks, large trucks, planes, boats, and so on, to move letters between postal service sites.

The service must be able to receive and forward the letters, and it must make good decisions about where to send each letter next, as shown in the diagram below.

Still thinking about the postal service, consider the difference between the person sending the letter and the work that the postal service does.

The person sending the letters expects that the postal service will deliver the letter most of the time. However, the person sending the letter does not need to know the details of exactly what path the letters take. 

In contrast, the postal service does not create the letter, but it accepts the letter from the customer. Then, the postal service must know the details about addresses and postal codes that group addresses into larger groups, and it must have the ability to deliver the letters.

The TCP/IP application and transport layers act like the person sending letters through the postal service.

 These upper layers work the same way regardless of whether the endpoint host computers are on the same LAN or are separated by the entire Internet.

To send a message, these upper layers ask the layer below them, the network layer, to deliver the message.

The lower layers of the TCP/IP model act more like the postal service to deliver those messages to the correct destinations.

To do so, these lower layers must understand the underlying physical network because they must choose how to best deliver the data from one host to another.

So, what does this all matter to networking?

Well, the network layer of the TCP/IP networking model, primarily defined by the Internet Protocol (IP), works much like the postal service.

IP defines that each host computer should have a different IP address, just as the postal service defines addressing that allows unique addresses for each house, apartment, and business.

Similarly, IP defines the process of routing so that devices called routers can work like the post office, forwarding packets of data so that they are delivered to the correct destinations.

Just as the postal service created the necessary infrastructure to deliver letters—post offices, sorting machines, trucks, planes, and personnel—the network layer defines the details of how a network infrastructure should be created so that the network can deliver data to all computers in the network.

NOTE: TCP/IP defines two versions of IP: IP version 4 (IPv4) and IP version 6 (IPv6). The world still mostly uses IPv4

Internet Protocol Addressing Basics

IP defines addresses for several important reasons.

First, each device that uses TCP/IP—each TCP/IP host—needs a unique address so that it can be identified in the network.

IP also defines how to group addresses together, just like the postal system groups addresses based on postal codes (or ZIP codes).

To understand the basics, examine the diagram below, which shows the familiar web server Larry and web browser Bob; but now, instead of ignoring the network between these two computers, part of the network infrastructure is included.

First, note that the diagram above shows some sample IP addresses. Each IP address has four numbers, separated by periods.

In this case, Larry uses IP address 1.1.1.1, and Bob uses 2.2.2.2. This style of number is called a dotted-decimal notation (DDN).

The diagram also shows three groups of addresses.

In this example, all IP addresses that begin with 1 must be on the upper left, as shown in shorthand in the figure as 1.__.__.__.

All addresses that begin with 2 must be on the right, as shown in shorthand as 2.__.__.__.

Finally, all IP addresses that begin with 3 must be at the bottom of the diagram.

In addition, the diagram introduces icons that represent IP routers.

Routers are networking devices that connect the parts of the TCP/IP network together for the purpose of routing (forwarding) IP packets to the correct destination.

Routers do the equivalent of the work done by each post office site: They receive IP packets on various physical interfaces, make decisions based on the IP address included with the packet, and then physically forward the packet out some other network interface.

IP Routing Basics

The TCP/IP network layer, using the IP protocol, provides a service of forwarding IP packets from one device to another.

Any device with an IP address can connect to the TCP/IP network and send packets. This section shows a basic IP routing example for perspective.

NOTE: The term IP host refers to any device, regardless of size or power, that has an IP address and connects to any TCP/IP network.

The diagram below repeats the familiar case in which web server Larry wants to send part of a web page to Bob, but now with details related to IP.

On the lower left, note that server Larry has the familiar application data, HTTP header, and TCP header ready to send.

In addition, the message now contains an IP header. The IP header includes a source IP address of Larry’s IP address (1.1.1.1) and a destination IP address of Bob’s IP address (2.2.2.2).

Step 1, begins with Larry being ready to send an IP packet.

Larry’s IP process chooses to send the packet to some router—a nearby router on the same LAN—with the expectation that the router will know how to forward the packet.

(This logic is much like you or me sending all our letters by putting them in a nearby mailbox.)

Larry doesn’t need to know anything more about the topology or the other routers.

At Step 2, Router R1 receives the IP packet, and R1’s IP process makes a decision.

R1 looks at the destination address (2.2.2.2), compares that address to its known IP routes, and chooses to forward the packet to Router R2.

This process of forwarding the IP packet is called IP routing (or simply routing).

At Step 3, Router R2 repeats the same kind of logic used by Router R1.

R2’s IP process will compare the packet’s destination IP address (2.2.2.2) to R2’s known IP routes and make a choice to forward the packet to the right, on to Bob.

The TCP/IP model’s original link layer defines the protocols and hardware required to deliver data across some physical network.

The term link refers to the physical connections, or links, between two devices and the protocols used to control those links.

Just like every layer in any networking model, the TCP/IP link layer provides services to the layer above it in the model.

When a host’s or router’s IP process chooses to send an IP packet to another router or host, that host or router then uses link-layer details to send that packet to the next host/router.

Because each layer provides a service to the layer above it, take a moment to think about the IP logic related to above diagram.

In that example, host Larry’s IP logic chooses to send the IP packet to a nearby router (R1), with no mention of the underlying Ethernet.

The Ethernet network, which implements link-layer protocols, must then be used to deliver that packet from host Larry over to router R1.

The diagram below shows four steps of what occurs at the link layer to allow Larry to send the IP packet to R1.

NOTE: Above diagram depicts the Ethernet as a series of lines. Networking diagrams often use this convention when drawing Ethernet LANs, in cases where the actual LAN cabling and LAN devices are not important to some discussion, as is the case here. The LAN would have cables and devices, like LAN switches, which are not shown.

The diagram shows four steps.

The first two occur on Larry, and the last two occur on Router R1, as follows:

• Step 1. Larry encapsulates the IP packet between an Ethernet header and Ethernet trailer, creating an Ethernet frame.
• Step 2. Larry physically transmits the bits of this Ethernet frame, using electricity flowing over the Ethernet cabling.
• Step 3. Router R1 physically receives the electrical signal over a cable, and re-creates the same bits by interpreting the meaning of the electrical signals.
• Step 4. Router R1 de-encapsulates the IP packet from the Ethernet frame by removing and discarding the Ethernet header and trailer.

By the end of this process, the link-layer processes on Larry and R1 have worked together to deliver the packet from Larry to Router R1.

NOTE: Protocols define both headers and trailers for the same general reason, but headers exist at the beginning of the message and trailers exist at the end.

The link layer includes a large number of protocols and standards.

For example, the link layer includes all the variations of Ethernet protocols, along with several other LAN standards that were more popular in decades past.

The link layer includes wide-area network (WAN) standards for different physical media, which differ significantly compared to LAN standards because of the longer distances involved in transmitting the data.

This layer also includes the popular WAN standards that add headers and trailers as shown generally in the diagram—protocols such as the Point-to-Point Protocol (PPP) and Frame Relay. 

In short, the TCP/IP link layer includes two distinct functions:

• functions related to the physical transmission of the data 
• the protocols and rules that control the use of the physical media

The five-layer TCP/IP model simply splits out the link layer into two layers (data link and physical) to match this logic.

Comparing the Original and Modern TCP/IP Models

The original TCP/IP model defined a single layer—the link layer—below the Internet layer.

The functions defined in the original link layer can be broken into two major categories:

• functions related directly to the physical transmission of data
• funstions indirectly related to the physical transmission of data

For example, in the four steps shown in the above diagram, Steps 2 and 3 were specific to sending the data, but Steps 1 and 4—encapsulation and de-encapsulation—were only indirectly related.

Today, most documents use a more modern version of the TCP/IP model, as shown in below. 

Comparing the two, the upper layers are identical, except a name change from Internet to Network.

The lower layers differ in that the single link layer in the original model is split into two layers to match the division of physical transmission details from the other functions. 

Data Encapsulation Terminology

As you can see from the explanations of how HTTP, TCP, IP, and Ethernet do their jobs, each layer adds its own header (and for data-link protocols, also a trailer) to the data supplied by the higher layer.

The term encapsulation refers to the process of putting headers (and sometimes trailers) around some data.

The process by which a TCP/IP host sends data can be viewed as a five-step process.

The first four steps relate to the encapsulation performed by the four TCP/IP layers, and the last step is the actual physical transmission of the data by the host.

In fact, if you use the five-layer TCP/IP model, one step corresponds to the role of each layer.

The steps are summarized in the following list:

• Step 1. Create and encapsulate the application data with any required application layer headers. For example, the HTTP OK message can be returned in an HTTP header, followed by part of the contents of a web page.
• Step 2. Encapsulate the data supplied by the application layer inside a transport layer header. For end-user applications, a TCP or UDP header is typically used.
• Step 3. Encapsulate the data supplied by the transport layer inside a network layer (IP) header. IP defines the IP addresses that uniquely identify each computer.
• Step 4. Encapsulate the data supplied by the network layer inside a data link layer header and trailer. This layer uses both a header and a trailer.
• Step 5. Transmit the bits. The physical layer encodes a signal onto the medium to transmit the frame.

The numbers in the diagram below correspond to the five steps in this list, graphically showing the same concepts. Note that because the application layer often does not need to add a header, the figure does not show a specific application layer header.

Names of TCP/IP Messages

Finally, take particular care to remember the terms segment, packet, and frame and the meaning of each.

Each term refers to the headers (and possibly trailers) defined by a particular layer and the data encapsulated following that header.

Each term, however, refers to a different layer: segment for the transport layer, packet for the network layer, and frame for the link layer.

The diagram below shows each layer along with the associated term.

The letters LH and LT stand for link header and link trailer, respectively, and refer to the data link layer header and trailer.

The diagram also shows the encapsulated data as simply “data.”

When focusing on the work done by a particular layer, the encapsulated data typically is unimportant.

For example, an IP packet can indeed have a TCP header after the IP header, an HTTP header after the TCP header, and data for a web page after the HTTP header.

However, when discussing IP, you probably just care about the IP header, so everything after the IP header is just called data.

So, when drawing IP packets, everything after the IP header is typically shown simply as data.

At one point in the history of the OSI model, many people thought that OSI would win the battle of the networking models discussed earlier.

If that had occurred, instead of running TCP/IP on every computer in the world, those computers would be running with OSI.

However, OSI did not win that battle.

In fact, OSI no longer exists as a networking model that could be used instead of TCP/IP, although some of the original protocols referenced by the OSI model still exist.

So, why OSI? Terminology.

During those years in which many people thought the OSI model would become commonplace in the world of networking (mostly in the late 1980s and early 1990s), many vendors and protocol documents started using terminology from the OSI model.

That terminology remains today.

So, while you will never need to work with a computer that uses OSI, to understand modern networking terminology, you need to understand something about OSI.

The OSI model has many similarities to the TCP/IP model from a basic conceptual perspective. It has (seven) layers, and each layer defines a set of typical networking functions.

As with TCP/IP, the OSI layers each refer to multiple protocols and standards that implement the functions specified by each layer.

In other cases, just as for TCP/IP, the OSI committees did not create new protocols or standards, but instead referenced other protocols that were already defined.

For example, the IEEE defines Ethernet standards, so the OSI committees did not waste time specifying a new type of Ethernet; it simply referred to the IEEE Ethernet standards.

Today, the OSI model can be used as a standard of comparison to other networking models.

Below diagram compares the seven-layer OSI model with both the four-layer and five-layer TCP/IP models.

Even today, networking documents often describe TCP/IP protocols and standards by referencing OSI layers, both by layer number and layer name.

For example, a common description of a LAN switch is “Layer 2 switch,” with “Layer 2” referring to OSI layer 2.

Because OSI did have a well-defined set of functions associated with each of its seven layers, if you know those functions, you can understand what people mean when they refer to a product or function by its OSI layer.

For another example, TCP/IP’s original Internet layer, as implemented mainly by IP, equates most directly to the OSI network layer.

So, most people say that IP is a network layer protocol, or a Layer 3 protocol, using OSI terminology and numbers for the layer.

Of course, if you numbered the TCP/IP model, starting at the bottom, IP would be either Layer 2 or 3, depending on what version of the TCP/IP model you care to use.

However, even though IP is a TCP/IP protocol, everyone uses the OSI model layer names and numbers when describing IP or any other protocol for that matter.

The claim that a particular TCP/IP layer is similar to a particular OSI layer is a general comparison, but not a detailed comparison.

The comparison is a little like comparing a car to a truck: Both can get you from point A to point B, but they have many specific differences, like the truck having a truck bed in which to carry cargo.

Similarly, both the OSI and TCP/IP network layers define logical addressing and routing.

However, the addresses have a different size, and the routing logic even works differently.

So the comparison of OSI layers to other protocol models is a general comparison of major goals, and not a comparison of the specific methods.

Today, because most people happen to be much more familiar with TCP/IP functions than with OSI functions, one of the best ways to learn about the function of different OSI layers is to think about the functions in the TCP/IP model and to correlate those with the OSI model.

For the purposes of learning, you can think of five of the OSI layers as doing the same kinds of things as the matching five layers in the TCP/IP model.

For example, the application layer of each model defines protocols to be used directly by the applications, and the physical layer of each defines the electro-mechanical details of communicating over physical connections.

Table below briefly describes each OSI layer.

While the table below lists a sampling of the devices and protocols and their comparable OSI layers.

Note that many network devices must actually understand the protocols at multiple OSI layers, so the layer listed in the table actually refers to the highest layer that the device normally thinks about when performing its core work.

For example, routers need to think about Layer 3 concepts, but they must also support features at both Layers 1 and 2.

Besides remembering the basics of the features of each OSI layer, and some protocol and device example at each layer, you should also memorize the names of the layers.

You can simply memorize them, but some people like to use a mnemonic phrase to make memorization easier.

In the following phrases, the first letter of each word is the same as the first letter of an OSI layer name, in the order specified in parentheses:

• All People Seem To Need Data Processing (Layers 7 to 1)
• Please Do Not Take Sausage Pizzas Away (Layers 1 to 7)

While networking models use layers to help humans categorize and understand the many functions in a network, networking models use layers for many reasons.

For example, consider another postal service analogy.

A person writing a letter does not have to think about how the postal service will deliver a letter across the country.

The postal worker in the middle of the country does not have to worry about the contents of the letter.

Likewise, networking models that divide functions into different layers enable one software package or hardware device to implement functions from one layer, and assume that other software/hardware will perform the functions defined by the other layers.

The following list summarizes the benefits of layered protocol specifications:

• Less complex: Compared to not using a layered model, network models break the concepts into smaller parts.
• Standard interfaces: The standard interface definitions between each layer allow multiple vendors to create products that fill a particular role, with all the benefits of open competition.
• Easier to learn: Humans can more easily discuss and learn about the many details of a protocol specification.
• Easier to develop: Reduced complexity allows easier program changes and faster product development.
• Multivendor interoperability: Creating products to meet the same networking standards means that computers and networking gear from multiple vendors can work in the same network.
• Modular engineering: One vendor can write software that implements higher layers—for example, a web browser—and another vendor can write software that implements the lower layers—for example, Microsoft’s built-in TCP/IP software in its operating systems.

Like TCP/IP, each OSI layer asks for services from the next lower layer.

To provide the services, each layer makes use of a header and possibly a trailer. The lower layer encapsulates the higher layer’s data behind a header.

OSI uses a more generic term to refer to messages, rather than frame, packet, and segment. OSI uses the term protocol data unit (PDU).

A PDU represents the bits that include the headers and trailers for that layer, as well as the encapsulated data.

For example, an IP packet using OSI terminology, is a PDU, more specifically a Layer 3 PDU (abbreviated L3PDU) because IP is a Layer 3 protocol.

OSI simply refers to the Layer x PDU (LxPDU), with x referring to the number of the layer being discussed, as shown in the diagram below.

The OSI transport layer (Layer 4) defines several functions, the most important of which are error recovery and flow control.

Likewise, the TCP/IP transport layer protocols also implement these same types of features.

Note that both the OSI model and the TCP/IP model call this layer the transport layer.

But as usual, when referring to the TCP/IP model, the layer name and number are based on OSI, so any TCP/IP transport layer protocols are considered Layer 4 protocols.

The key difference between TCP and UDP is that TCP provides a wide variety of services to applications, whereas UDP does not.

For example, routers discard packets for many reasons, including bit errors, congestion, and instances in which no correct routes are known.

As you have learned already, most data-link protocols notice errors (a process called error detection) but then discard frames that have errors.

TCP provides retransmission (error recovery) and helps to avoid congestion (flow control), whereas UDP does not.

As a result, many application protocols choose to use TCP.

However, do not let UDP’s lack of services make you think that UDP is worse than TCP.

By providing fewer services, UDP needs fewer bytes in its header compared to TCP, resulting in fewer bytes of overhead in the network. UDP software does not slow down data transfer in cases where TCP can purposefully slow down. 

Also, some applications, notably today Voice over IP (VoIP) and video over IP, do not need error recovery, so they use UDP.

So, UDP also has an important place in TCP/IP networks today.

Table below lists the main features supported by TCP/UDP. Note that only the first item listed in the table is supported by UDP, whereas all items in the table are supported by TCP.

Each TCP/IP application typically chooses to use either TCP or UDP based on the application’s requirements.

For example, TCP provides error recovery, but to do so, it consumes more bandwidth and uses more processing cycles. 

UDP does not perform error recovery, but it takes less bandwidth and uses fewer processing cycles.

Regardless of which of these two TCP/IP transport layer protocols the application chooses to use, you should understand the basics of how each of these transport layer protocols works.

TCP, as defined in Request For Comments (RFC) 793, accomplishes the functions listed in table above through mechanisms at the endpoint computers.

TCP relies on IP for end-to-end delivery of the data, including routing issues. In other words, TCP performs only part of the functions necessary to deliver the data between applications.

Also, the role that it plays is directed toward providing services for the applications that sit at the endpoint computers.

Regardless of whether two computers are on the same Ethernet, or are separated by the entire Internet, TCP performs its functions the same way.

The diagram below shows the fields in the TCP header.

The message created by TCP that begins with the TCP header, followed by any application data, is called a TCP segment. Alternatively, the more generic term Layer 4 PDU, or L4PDU, can also be used.

Multiplexing Using TCP Port Numbers

TCP and UDP both use a concept called multiplexing. ​

Multiplexing by TCP and UDP involves the process of how a computer thinks when receiving data.

The computer might be running many applications, such as a web browser, an email package, or an Internet VoIP application (for example, Skype).

TCP and UDP multiplexing tells the receiving computer to which application to give the received data.

Some examples will help make the need for multiplexing obvious. The sample network consists of two PCs, labeled Hannah and Jessie. Hannah uses an application that she wrote to send advertisements that appear on Jessie’s screen.

The application sends a new ad to Jessie every 10 seconds. Hannah uses a second application, a wire-transfer application, to send Jessie some money.

Finally, Hannah uses a web browser to access the web server that runs on Jessie’s PC.

The ad application and wire-transfer application are imaginary, just for this example.

The web application works just like it would in real life.

The diagram shows the sample network, with Jessie running three applications:

• A UDP-based advertisement application
• A TCP-based wire-transfer application
• A TCP web server application

Jessie needs to know which application to give the data to, but all three packets are from the same Ethernet and IP address.

You might think that Jessie could look at whether the packet contains a UDP or TCP header, but as you see in the figure, two applications (wire transfer and web) are using TCP.

TCP and UDP solve this problem by using a port number field in the TCP or UDP header, respectively.

Each of Hannah’s TCP and UDP segments uses a different destination port number so that Jessie knows which application to give the data to.

The diagram below shows an example.

Multiplexing relies on a concept called a socket. A socket consists of three things:

• An IP address
• A transport protocol
• A port number

So, for a web server application on Jessie, the socket would be (10.1.1.2, TCP, port 80) because, by default, web servers use the well-known port 80.

When Hannah’s web browser connects to the web server, Hannah uses a socket as well—possibly one like this: (10.1.1.1, TCP, 1030).

Why 1030?

Well, Hannah just needs a port number that is unique on Hannah, so Hannah sees that port 1030 is available and uses it.

In fact, hosts typically allocate dynamic port numbers starting at 1024 because the ports below 1024 are reserved for well-known applications.

In diagram above, Hannah and Jessie use three applications at the same time—hence, three socket connections are open.

Because a socket on a single computer should be unique, a connection between two sockets should identify a unique connection between two computers.

This uniqueness means that you can use multiple applications at the same time, talking to applications running on the same or different computers.

Multiplexing, based on sockets, ensures that the data is delivered to the correct applications.

The diagram below shows the three socket connections between Hannah and Jessie.

Port numbers are a vital part of the socket concept. Well-known port numbers are used by servers; other port numbers are used by clients.

Applications that provide a service, such as FTP, Telnet, and web servers, open a socket using a well-known port and listen for connection requests.

Because these connection requests from clients are required to include both the source and destination port numbers, the port numbers used by the servers must be well-known.

Therefore, each service uses a specific well-known port number.

The well-known ports are listed at www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt.

On client machines, where the requests originate, any locally unused port number can be allocated.

The result is that each client on the same host uses a different port number, but a server uses the same port number for all connections.

For example, 100 web browsers on the same host computer could each connect to a web server, but the web server with 100 clients connected to it would have only one socket and, therefore, only one port number (port 80, in this case).

The server can tell which packets are sent from which of the 100 clients by looking at the source port of received TCP segments.

The server can send data to the correct web client (browser) by sending data to that same port number listed as a destination port.

The combination of source and destination sockets allows all participating hosts to distinguish between the data’s source and destination.

Although the example explains the concept using 100 TCP connections, the same port-numbering concept applies to UDP sessions in the same way.

Popular TCP/IP Applications

Some of the applications that can be used to help manage and control a network are:

• The World Wide Web (WWW) application exists through web browsers accessing the content available on web servers. Although it is often thought of as an end-user application, you can actually use WWW to manage a router or switch. You enable a web server function in the router or switch and use a browser to access the router or switch.
• The Domain Name System (DNS) allows users to use names to refer to computers, with DNS being used to find the corresponding IP addresses. DNS also uses a client/server model, with DNS servers being controlled by networking personnel and DNS client functions being part of most any device that uses TCP/IP today. The client simply asks the DNS server to supply the IP address that corresponds to a given name.
• Simple Network Management Protocol (SNMP) is an application layer protocol used specifically for network device management.
  • For example, Cisco supplies a large variety of network management products, many of them in the Cisco Prime network management software product family.
  • They can be used to query, compile, store, and display information about a network’s operation. To query the network devices, Cisco Prime software mainly uses SNMP protocols.
• Traditionally, to move files to and from a router or switch, Cisco used Trivial File Transfer Protocol (TFTP). TFTP defines a protocol for basic file transfer—hence the word trivial. Alternatively, routers and switches can use File Transfer Protocol (FTP), which is a much more functional protocol, to transfer files.
  • Both work well for moving files into and out of Cisco devices.
  • FTP allows many more features, making it a good choice for the general end-user population.
  • TFTP client and server applications are very simple, making them good tools as embedded parts of networking devices.

Some of these applications use TCP, and some use UDP.

For example, Simple Mail Transfer Protocol (SMTP) and Post Office Protocol version 3 (POP3), both used for transferring mail, require guaranteed delivery, so they use TCP.

Regardless of which transport layer protocol is used, applications use a well-known port number so that clients know which port to attempt to connect to.

The table below lists several popular applications and their well-known port numbers.

Connection Establishment and Termination

TCP connection establishment occurs before any of the other TCP features can begin their work.

Connection establishment refers to the process of initializing Sequence and Acknowledgment fields and agreeing on the port numbers used.

Diagram below shows an example of connection establishment flow.

This three-way connection establishment flow (also called a three-way handshake) must complete before data transfer can begin.

The connection exists between the two sockets, although the TCP header has no single socket field.

Of the three parts of a socket, the IP addresses are implied based on the source and destination IP addresses in the IP header.

TCP is implied because a TCP header is in use, as specified by the protocol field value in the IP header.

Therefore, the only parts of the socket that need to be encoded in the TCP header are the port numbers.

TCP signals connection establishment using 2 bits inside the flag fields of the TCP header.

Called the SYN and ACK flags, these bits have a particularly interesting meaning.

SYN means “synchronize the sequence numbers,” which is one necessary component in initialization for TCP.

Diagram below shows TCP connection termination.

This four-way termination sequence is straightforward and uses an additional flag, called the FIN bit. (FIN is short for “finished,” as you might guess.)

One interesting note: Before the device on the right sends the third TCP segment in the sequence, it notifies the application that the connection is coming down.

It then waits on an acknowledgment from the application before sending the third segment in the figure.

Just in case the application takes some time to reply, the PC on the right sends the second flow in the figure, acknowledging that the other PC wants to take down the connection. Otherwise, the PC on the left might resend the first segment repeatedly.

TCP establishes and terminates connections between the endpoints, whereas UDP does not.

Many protocols operate under these same concepts, so the terms connection-oriented and connectionless are used to refer to the general idea of each. More formally, these terms can be defined as follows:

• Connection-oriented protocol: A protocol that requires an exchange of messages before data transfer begins, or that has a required pre-established correlation between two endpoints.
• Connectionless protocol: A protocol that does not require an exchange of messages and that does not require a pre-established correlation between two endpoints.

Error Recovery and Reliability

TCP provides for reliable data transfer, which is also called reliability or error recovery.

To accomplish reliability, TCP numbers data bytes using the Sequence and Acknowledgment fields in the TCP header.

TCP achieves reliability in both directions, using the Sequence Number field of one direction combined with the Acknowledgment field in the opposite direction.

Diagram below shows an example of how the TCP sequence and acknowledgment fields allow the PC to send 3000 bytes of data to the server, with the server acknowledging receipt of the data.

The TCP segments in the figure occur in order, from top to bottom.

For simplicity’s sake, all messages happen to have 1000 bytes of data in the data portion of the TCP segment.

The first Sequence number is a nice round number (1000), again for simplicity’s sake.

The top of the figure shows three segments, with each sequence number being 1000 more than the previous, identifying the first of the 1000 bytes in the message. (That is, in this example, the first segment holds bytes 1000–1999; the second holds bytes 2000–2999; and the third holds bytes 3000–3999.)

The fourth TCP segment in the figure—the only one flowing back from the server to the web browser—acknowledges the receipt of all three segments.

How?

The acknowledgment value of 4000 means “I received all data with sequence numbers up through one less than 4000, so I am ready to receive your byte 4000 next.”

(Note that this convention of acknowledging by listing the next expected byte, rather than the number of the last byte received, is called forward acknowledgment.)

This first example does not recover from any errors, however; it simply shows the basics of how the sending host uses the sequence number field to identify the data, with the receiving host using forward acknowledgments to acknowledge the data.

The more interesting discussion revolves around how to use these same tools to do error recovery.

TCP uses the sequence and acknowledgment fields so that the receiving host can notice lost data, ask the sending host to resend, and then acknowledge that the re-sent data arrived.
Many variations exist for how TCP does error recovery.

Below diagram shows just one such example, with similar details compared to the previous diagram. The web browser again sends three TCP segments, again 1000 bytes each, again with easy-to-remember sequence numbers. However, in this example, the second TCP segment fails to cross the network.

The figure points out three sets of ideas behind how the two hosts think.

First, on the right, the server realizes that it did not receive all the data. The two received TCP segments contain bytes numbered 1000–1999 and 3000–3999.

Clearly, the server did not receive the bytes numbered in between. The server then decides to acknowledge all the data up to the lost data—that is, to send back a segment with the acknowledgment field equal to 2000.

The receipt of an acknowledgment that does not acknowledge all the data sent so far tells the sending host to resend the data.

The PC on the left may wait a few moments to make sure no other acknowledgments arrive (using a timer called the retransmission timer), but will soon decide that the server means “I really do need 2000 next—resend it.” The PC on the left does so, as shown in the fifth of the six TCP segments in the diagram.

Finally, note that the server can acknowledge not only the re-sent data, but any earlier data that had been received correctly.

In this case, the server received the re-sent second TCP segment (the data with sequence numbers 2000–2999), but the server had already received the third TCP segment (the data numbered 3000–3999).

The server’s next acknowledgment field acknowledges the data in both those segments, with an acknowledgment field of 4000.

Flow Control Using Windowing

TCP implements flow control by using a window concept that is applied to the amount of data that can be outstanding and awaiting acknowledgment at any one point in time.

The window concept lets the receiving host tell the sender how much data it can receive right now, giving the receiving host a way to make the sending host slow down or speed up.

The receiver can slide the window size up and down—called a sliding window or dynamic window—to change how much data the sending host can send.

The sliding window mechanism makes much more sense with an example.

The example, shown in diagram below, uses the same basic rules as the examples in the previous few diagrams. In this case, none of the TCP segments have errors, and the discussion begins one TCP segment earlier than in the previous two figures.

Begin with the first segment, sent by the server to the PC.

The Acknowledgment field should be familiar by now: it tells the PC that the server expects a segment with sequence number 1000 next.

The new field, the window field, is set to 3000. Because the segment flows to the PC, this value tells the PC that the PC can send no more than 3000 bytes over this connection before receiving an acknowledgment.

So, as shown on the left, the PC realizes it can send only 3000 bytes, and it stops sending, waiting on an acknowledgment, after sending three 1000-byte TCP segments.

Continuing the example, the server not only acknowledges receiving the data (without any loss), but the server decides to slide the window size a little higher.

Note that second message flowing right-to-left in the figure, this time with a window of 4000. Once the PC receives this TCP segment, the PC realizes it can send another 4000 bytes (a slightly larger window than the previous value).

Note that while the last few figures show examples for the purpose of explaining how the mechanisms work, the examples might give you the impression that TCP makes the hosts sit there and wait for acknowledgments a lot.

TCP does not want to make the sending host have to wait to send data.

For instance, if an acknowledgment is received before the window is exhausted, a new window begins, and the sender continues sending data until the current window is exhausted.

Often times, in a network that has few problems, few lost segments, and little congestion, the TCP windows stay relatively large with hosts seldom waiting to send.

UDP provides a service for applications to exchange messages.

Unlike TCP, UDP is connectionless and provides no reliability, no windowing, no reordering of the received data, and no segmentation of large chunks of data into the right size for transmission.

However, UDP provides some functions of TCP, such as data transfer and multiplexing using port numbers, and it does so with fewer bytes of overhead and less processing required than TCP.

UDP data transfer differs from TCP data transfer in that no reordering or recovery is accomplished.

Applications that use UDP are tolerant of the lost data, or they have some application mechanism to recover lost data.

For example, VoIP uses UDP because if a voice packet is lost, by the time the loss could be noticed and the packet retransmitted, too much delay would have occurred, and the voice would be unintelligible.

Also, DNS requests use UDP because the user will retry an operation if the DNS resolution fails.

As another example, the Network File System (NFS), a remote file system application, performs recovery with application layer code, so UDP features are acceptable to NFS.

Diagram below shows the UDP header format.

Most importantly, note that the header includes source and destination port fields, for the same purpose as TCP.

However, the UDP has only 8 bytes, in comparison to the 20-byte TCP header. UDP needs a shorter header than TCP simply because UDP has less work to do.

The whole goal of building an enterprise network, or connecting a small home or office network to the Internet, is to use applications such as web browsing, text messaging, email, file downloads, voice, and video.

The World Wide Web (WWW) consists of all the Internet-connected web servers in the world, plus all Internet-connected hosts with web browsers.

Web servers, which consist of web server software running on a computer, store information (in the form of web pages) that might be useful to different people.

A web browser, which is software installed on an end user’s computer, provides the means to connect to a web server and display the web pages stored on the web server.

NOTE: Although most people use the term web browser, or simply browser, web browsers are also called web clients, because they obtain a service from a web server.

For this process to work, several specific application layer functions must occur.

The user must somehow identify the server, the specific web page, and the protocol used to get the data from the server.

The client must find the server’s IP address, based on the server’s name, typically using DNS.

The client must request the web page, which actually consists of multiple separate files, and the server must send the files to the web browser.

Finally, for electronic commerce (e-commerce) applications, the transfer of data, particularly sensitive financial data, needs to be secure.

For a browser to display a web page, the browser must identify the server that has the web page, plus other information that identifies the particular web page.

Most web servers have many web pages.

For example, if you use a web browser to browse www.cisco.com and you click around that web page, you’ll see another web page.

Click again, and you’ll see another web page. In each case, the clicking action identifies the server’s IP address as well as the specific web page, with the details mostly hidden from you.

(These clickable items on a web page, which in turn bring you to another web page, are called links.)

The browser user can identify a web page when you click something on a web page or when you enter a Uniform Resource Identifier (URI) in the browser’s address area. Both options—clicking a link and typing a URI—refer to a URI, because when you click a link on a web page, that link actually refers to a URI.

In common speech, many people use the terms web address or the similar related term Universal Resource Locator (URL) instead of URI, but URI is indeed the correct formal term.

In fact, URL had been more commonly used than URI for more than a few years. However, the IETF (the group that defines TCP/IP), along with the W3C consortium (W3.org, a consortium that develops web standards) has made a concerted effort to standardize the use of URI as the general term. See RFC 7595 for some commentary to that effect.

From a practical perspective, the URIs used to connect to a web server include three key components, as noted in the diagram below. The diagram shows the formal names of the URI fields. More importantly to this discussion, note that the text before the :// identifies the protocol used to connect to the server, the text between the // and / identifies the server by name, and the text after the / identifies the web page.

In this case, the protocol is Hypertext Transfer Protocol (HTTP), the hostname is www.certskills.com, and the name of the web page is blog.

A host can use DNS to discover the IP address that corresponds to a particular hostname.

URIs typically list the name of the server—a name that can be used to dynamically learn the IP address used by that same server.

The web browser cannot send an IP packet to a destination name, but it can send a packet to a destination IP address.

So, before the browser can send a packet to the web server, the browser typically needs to resolve the name inside the URI to that name’s corresponding IP address.

To pull together several concepts, the diagram below shows the DNS process as initiated by a web browser, as well as some other related information.

From a basic perspective, the user enters the URI (in this case, http://www.cisco.com/go/learningnetwork), resolves the www.cisco.com name into the correct IP address, and starts sending packets to the web server.

The steps shown in the figure are as follows:

1. The user enters the URI, http://www.cisco.com/go/learningnetwork, into the browser’s address area.
2. The client sends a DNS request to the DNS server. Typically, the client learns the DNS server’s IP address through DHCP. Note that the DNS request uses a UDP header, with a destination port of the DNS well-known port of 53.
3. The DNS server sends a reply, listing IP address 198.133.219.25 as www.cisco.com’s IP address. Note also that the reply shows a destination IP address of 64.100.1.1, the client’s IP address. It also shows a UDP header, with source port 53; the source port is 53 because the data is sourced, or sent by, the DNS server.
4. The client begins the process of establishing a new TCP connection to the web server. Note that the destination IP address is the just-learned IP address of the web server. The packet includes a TCP header, because HTTP uses TCP. Also note that the destination TCP port is 80, the well-known port for HTTP. Finally, the SYN bit is shown, as a reminder that the TCP connection establishment process begins with a TCP segment with the SYN bit turned on (binary 1).

At this point in the process, the web browser is almost finished setting up a TCP connection to the web server. 

After a web client (browser) has created a TCP connection to a web server, the client can begin requesting the web page from the server.

Most often, the protocol used to transfer the web page is HTTP.

The HTTP application layer protocol, defined in RFC 7230, defines how files can be transferred between two computers.

HTTP was specifically created for the purpose of transferring files between web servers and web clients.

HTTP defines several commands and responses, with the most frequently used being the HTTP GET request.

To get a file from a web server, the client sends an HTTP GET request to the server, listing the filename.

If the server decides to send the file, the server sends an HTTP GET response, with a return code of 200 (meaning OK), along with the file’s contents.

NOTE: Many return codes exist for HTTP requests. For example, when the server does not have the requested file, it issues a return code of 404, which means “file not found.” Most web browsers do not show the specific numeric HTTP return codes, instead displaying a response such as “page not found” in reaction to receiving a return code of 404.

Web pages typically consist of multiple files, called objects.

Most web pages contain text as well as several graphical images, animated advertisements, and possibly voice or video.

Each of these components is stored as a different object (file) on the web server. To get them all, the web browser gets the first file.

This file can (and typically does) include references to other URIs, so the browser then also requests the other objects.

The diagram below shows the general idea, with the browser getting the first file and then two others.

In this case, after the web browser gets the first file—the one called “/go/ccna” in the URI—the browser reads and interprets that file.

Besides containing parts of the web page, the file refers to two other files, so the browser issues two additional HTTP get requests.

Note that, even though it isn’t shown in the figure, all these commands flow over one (or possibly more) TCP connection between the client and the server.

This means that TCP would provide error recovery, ensuring that the data was delivered.

The concept revolves around the process by which a host, when receiving any message over any network, can decide which of its many application programs should process the received data.

As an example, consider host A shown on the left side of diagram below. The host happens to have three different web browser windows open, each using a unique TCP port.

Host A also has an email client and a chat window open, both of which use TCP.

Both the email and chat applications use a unique TCP port number on host A as well (1027 and 1028) as shown in the diagram.

Transport layer protocols use the destination port number field in the TCP or UDP header to identify the receiving application.

For instance, if the destination TCP port value in below figure is 1024, host A will know that the data is meant for the first of the three web browser windows.

Before a receiving host can even examine the TCP or UDP header, and find the destination port field, it must first process the outer headers in the message.

If the incoming message is an Ethernet frame, that encapsulates an IPv4 packet, the headers look like the details in the above diagram.

The receiving host needs to look at multiple fields, one per header, to identify the next header or field in the received message.

For instance, host A uses an Ethernet NIC to connect to the network, so the received message is an Ethernet frame.

The Ethernet Type field identifies the type of header that follows the Ethernet header—in this case, with a value of hex 0800, an IPv4 header.

The IPv4 header has a similar field called the IP Protocol field. The IPv4 Protocol field has a standard list of values that identify the next header, with decimal 6 used for TCP and decimal 17 used for UDP.

In this case, the value of 6 identifies the TCP header that follows the IPv4 header. Once the receiving host realizes a TCP header exists, it can process the destination port field to determine which local application process should receive the data.