Networking Concepts: OSI & TCP/IP Models

Why This Matters

You are on a call with the network team. The application is down. Someone says, "It's a Layer 3 issue -- routing is broken." Someone else says, "No, I think it's Layer 7 -- the application is returning 503s." A third person asks, "Have you checked Layer 2? Maybe it's an ARP problem."

If you do not know what these layers mean, you are lost in this conversation. And that conversation is happening in real-time while a production service is down.

The OSI and TCP/IP networking models are not academic abstractions. They are the shared vocabulary that every systems administrator, network engineer, and DevOps engineer uses to diagnose problems, communicate precisely, and isolate faults. When you understand the layers, you can systematically eliminate possibilities: "The physical link is up, the IP address is correct, the port is open -- so the problem must be at the application layer."

This chapter gives you that vocabulary and that systematic thinking.

Try This Right Now

Let us trace a network request through the layers, right now, on your machine:

# See your network interfaces (Layer 2 - Data Link)
ip link show

# See your IP addresses (Layer 3 - Network)
ip addr show

# Check if you can reach a host (Layer 3 - Network)
ping -c 3 8.8.8.8

# See the path packets take (Layer 3 - Network)
tracepath 8.8.8.8

# Check if a TCP port is reachable (Layer 4 - Transport)
ss -tlnp

# Make an HTTP request (Layer 7 - Application)
curl -I https://example.com

Each of these commands operates at a different layer of the network stack. By the end of this chapter, you will understand exactly why.

The OSI Model: Seven Layers of Networking

The Open Systems Interconnection (OSI) model breaks network communication into seven layers. Each layer has a specific job, and each layer provides services to the layer above it while relying on the layer below it.

+---------------------------------------------------------------+
|                    THE OSI MODEL                              |
+---------------------------------------------------------------+
|                                                               |
|  Layer 7  APPLICATION    HTTP, DNS, SSH, FTP, SMTP            |
|           -------------------------------------------------   |
|  Layer 6  PRESENTATION   Encryption, compression, encoding   |
|           -------------------------------------------------   |
|  Layer 5  SESSION        Connection management, sessions     |
|           -------------------------------------------------   |
|  Layer 4  TRANSPORT      TCP, UDP -- ports, reliability      |
|           -------------------------------------------------   |
|  Layer 3  NETWORK        IP -- addressing, routing           |
|           -------------------------------------------------   |
|  Layer 2  DATA LINK      Ethernet, MAC addresses, switches   |
|           -------------------------------------------------   |
|  Layer 1  PHYSICAL       Cables, radio waves, voltage        |
|                                                               |
+---------------------------------------------------------------+

A common mnemonic to remember the layers from bottom to top:

Please Do Not Throw Sausage Pizza Away

(Physical, Data Link, Network, Transport, Session, Presentation, Application)

Or from top to bottom:

All People Seem To Need Data Processing

Layer by Layer: What Each Layer Does

Layer 1: Physical

What it does: Transmits raw bits over a physical medium.

What it includes: Ethernet cables (Cat5e, Cat6), fiber optic cables, Wi-Fi radio waves, voltage levels, pin layouts, signal timing.

Troubleshooting at this layer:

• Is the cable plugged in?
• Is the link light on the switch/NIC green?
• Is the network interface up?

# Check if the physical link is detected
ip link show eth0

# Look for "state UP" or "state DOWN"
# A "NO-CARRIER" state means no cable/link detected

# Check interface statistics for physical errors
ip -s link show eth0
# Look for: errors, dropped, overruns, carrier errors

Real-world analogy: Layer 1 is the road. It does not care what vehicles are on it -- it just provides the physical surface for things to travel on.

Layer 2: Data Link

What it does: Handles communication between devices on the same local network (LAN). Uses MAC (Media Access Control) addresses -- the hardware address burned into every network card.

Key concepts:

• MAC addresses (e.g., 00:1A:2B:3C:4D:5E) -- 48-bit hardware addresses
• Ethernet frames -- the unit of data at this layer
• Switches -- Layer 2 devices that forward frames based on MAC addresses
• ARP -- translates IP addresses to MAC addresses

# See your MAC addresses
ip link show

# See the ARP cache (IP-to-MAC mappings your system knows about)
ip neigh show

# Example output:
# 192.168.1.1 dev eth0 lladdr aa:bb:cc:dd:ee:ff REACHABLE

Real-world analogy: Layer 2 is the local postal system within a building. It uses apartment numbers (MAC addresses) to deliver mail within the building, but it cannot deliver to another building.

Layer 3: Network

What it does: Handles communication between different networks. Uses IP addresses for logical addressing and routing to determine the path packets take.

Key concepts:

• IP addresses (e.g., 192.168.1.100 for IPv4, 2001:db8::1 for IPv6)
• Packets -- the unit of data at this layer
• Routers -- Layer 3 devices that forward packets between networks
• Routing tables -- rules that determine where to send packets

# See your IP addresses
ip addr show

# See the routing table
ip route show

# Test Layer 3 connectivity
ping -c 3 192.168.1.1

# Trace the route to a destination
tracepath 8.8.8.8

Real-world analogy: Layer 3 is the national postal system. It uses street addresses (IP addresses) and knows how to route mail between cities (networks) using sorting facilities (routers).

Layer 4: Transport

What it does: Provides end-to-end communication between applications. Adds the concept of ports, which identify specific services on a host.

Key protocols:

• TCP (Transmission Control Protocol) -- reliable, ordered, connection-oriented
• UDP (User Datagram Protocol) -- fast, connectionless, no guarantee of delivery

# See active TCP connections and listening ports
ss -tlnp

# See active UDP sockets
ss -ulnp

# Check if a specific port is reachable
# (If nmap is installed)
nmap -p 443 example.com

Real-world analogy: Layer 4 is the postal service's handling options. TCP is like registered mail with tracking and delivery confirmation. UDP is like dropping a postcard in the mailbox -- fast, but you do not know if it arrived.

Layer 5: Session

What it does: Manages sessions (ongoing conversations) between applications. Handles setup, maintenance, and teardown of communication sessions.

What it includes: Session establishment, synchronization, authentication tokens, RPC (Remote Procedure Calls).

In practice, this layer is often merged with Layers 6 and 7 in modern implementations. You will rarely hear someone say "it's a Layer 5 problem."

Layer 6: Presentation

What it does: Translates data formats between the network and the application. Handles encryption, compression, and character encoding.

What it includes: SSL/TLS encryption, data serialization (JSON, XML), character sets (ASCII, UTF-8), image format conversion.

# TLS operates at this layer
# Check the TLS certificate of a site
openssl s_client -connect example.com:443 < /dev/null 2>/dev/null | \
    openssl x509 -noout -subject -dates

Layer 7: Application

What it does: The layer closest to the user. Provides network services directly to applications.

Key protocols: HTTP/HTTPS, DNS, SSH, FTP, SMTP, IMAP, SNMP, LDAP.

# HTTP request (Layer 7)
curl -v https://example.com

# DNS query (Layer 7)
dig example.com

# SSH connection (Layer 7)
ssh user@server

Real-world analogy: Layer 7 is the actual content of the letter. Layers 1-6 got the letter to you. Layer 7 is you reading it and understanding the message.

Think About It: When you type https://example.com in a browser, which layers are involved? (Answer: all of them. Layer 7 = HTTP, Layer 6 = TLS encryption, Layer 4 = TCP connection to port 443, Layer 3 = IP routing, Layer 2 = Ethernet frame to gateway, Layer 1 = electrical signals on the wire.)

The TCP/IP Model: Four Layers

The OSI model is a theoretical reference. The TCP/IP model is what the internet actually runs on. It condenses seven layers into four practical layers:

+-----------------------------------------------+
|       OSI MODEL          TCP/IP MODEL          |
+-----------------------------------------------+
|                                                |
|  7  Application  \                             |
|  6  Presentation  >  APPLICATION               |
|  5  Session      /                             |
|                                                |
|  4  Transport       TRANSPORT                  |
|                                                |
|  3  Network          INTERNET                  |
|                                                |
|  2  Data Link   \                              |
|  1  Physical     >   NETWORK ACCESS            |
|                                                |
+-----------------------------------------------+

TCP/IP Layers Explained

Application Layer -- Combines OSI Layers 5, 6, and 7. This is where protocols like HTTP, DNS, SSH, and SMTP live. The application handles its own session management and data formatting.

Transport Layer -- Same as OSI Layer 4. TCP and UDP operate here, providing port-based multiplexing and (in TCP's case) reliable delivery.

Internet Layer -- Same as OSI Layer 3. IP operates here, providing logical addressing and routing between networks.

Network Access Layer -- Combines OSI Layers 1 and 2. Handles the physical transmission of data and the local network delivery using hardware addresses.

Why Two Models?

The OSI model is great for understanding concepts and discussing problems. It gives you precise language (Layer 2, Layer 3, etc.).

The TCP/IP model is great for understanding implementation. It reflects how the internet protocol suite is actually built and how the Linux kernel's networking stack is organized.

In practice, people use OSI layer numbers (Layer 2, Layer 3, Layer 7) in conversation, but the software follows the TCP/IP model.

Data Encapsulation: How Data Flows Through Layers

When you send data over a network, each layer wraps the data from the layer above with its own header (and sometimes a trailer). This process is called encapsulation.

When data is received, each layer strips its header and passes the payload up to the next layer. This is decapsulation.

SENDING (Encapsulation - each layer adds a header):

+---------------------------------------------------+
|  Application Layer                                 |
|  +----------------------------------------------+ |
|  |              DATA                             | |
|  +----------------------------------------------+ |
|            |                                       |
|            v                                       |
|  Transport Layer                                   |
|  +----------------------------------------------+ |
|  | TCP/UDP |           DATA                      | |
|  | Header  |                                     | |
|  +----------------------------------------------+ |
|            |                                       |
|            v                                       |
|  Internet Layer                                    |
|  +----------------------------------------------+ |
|  | IP     | TCP/UDP |        DATA                | |
|  | Header | Header  |                            | |
|  +----------------------------------------------+ |
|            |                                       |
|            v                                       |
|  Network Access Layer                              |
|  +----------------------------------------------+ |
|  | Eth  | IP     | TCP/UDP |  DATA  | Eth       | |
|  | Hdr  | Header | Header  |       | Trailer   | |
|  +----------------------------------------------+ |
|                                                    |
|  Transmitted as bits on the wire                   |
+---------------------------------------------------+

The Names Change at Each Layer

This naming matters when reading documentation and communicating with colleagues. "We're dropping packets" means a Layer 3 problem. "We're dropping frames" means a Layer 2 problem.

Practical Troubleshooting with Layers

The power of the layered model is systematic troubleshooting. Start from the bottom and work up:

+---------------------------------------------------------------+
|          TROUBLESHOOTING CHECKLIST BY LAYER                   |
+---------------------------------------------------------------+
|                                                               |
|  Layer 1 - Physical                                           |
|    [ ] Is the cable/link connected?                           |
|    [ ] ip link show -- is the interface UP?                   |
|    [ ] Any errors in ip -s link show?                         |
|                                                               |
|  Layer 2 - Data Link                                          |
|    [ ] Can you see MAC addresses? ip neigh show               |
|    [ ] Is ARP resolving? arping -c 3 <gateway>                |
|    [ ] Check switch port (if you have access)                 |
|                                                               |
|  Layer 3 - Network                                            |
|    [ ] Is IP address configured? ip addr show                 |
|    [ ] Can you ping the gateway? ping <gateway>               |
|    [ ] Can you ping the destination? ping <target>            |
|    [ ] Is routing correct? ip route show                      |
|    [ ] tracepath to find where packets stop                   |
|                                                               |
|  Layer 4 - Transport                                          |
|    [ ] Is the service listening? ss -tlnp                     |
|    [ ] Can you connect to the port? nc -zv <host> <port>      |
|    [ ] Firewall blocking? iptables -L -n / nft list ruleset   |
|                                                               |
|  Layer 7 - Application                                        |
|    [ ] Does the service respond? curl -v http://host:port     |
|    [ ] Check application logs                                 |
|    [ ] Is DNS resolving? dig <hostname>                       |
|    [ ] Is TLS working? openssl s_client -connect host:443     |
|                                                               |
+---------------------------------------------------------------+

Hands-On: Layer-by-Layer Troubleshooting

Let us walk through a real troubleshooting scenario. Imagine a web server is unreachable.

# Step 1: Layer 1 -- Is the interface up?
ip link show
# Look for "state UP"

# Step 2: Layer 2 -- Can we reach the local network?
ip neigh show
# Do we have ARP entries for the gateway?

# Step 3: Layer 3 -- Can we reach the gateway and beyond?
ip route show
# What is the default gateway?

ping -c 3 $(ip route show default | awk '{print $3}')
# Can we ping the gateway?

ping -c 3 8.8.8.8
# Can we reach the internet?

# Step 4: Layer 4 -- Is the port open?
ss -tlnp | grep ':80'
# Is anything listening on port 80?

# Step 5: Layer 7 -- Does the application respond?
curl -v http://localhost:80
# What does the application return?

If ping 8.8.8.8 works but ping google.com fails, the problem is DNS (Layer 7 in OSI, Application layer in TCP/IP), not routing (Layer 3).

If ping works but curl fails, the problem is at Layer 4 (port not open, firewall) or Layer 7 (application not running or misconfigured).

Think About It: You can ping a server by IP address but cannot connect to its web page. At which layers could the problem exist? (Layer 4: port blocked by firewall or service not running. Layer 7: application error, TLS certificate issue, etc.)

Protocols at Each Layer

Here is a reference mapping common protocols to their OSI layers:

Distro Note: The tools for each layer are the same across distributions. However, some minimal images may not include tools like tracepath, nmap, or curl by default. Install them as needed: sudo apt install iputils-ping traceroute nmap curl (Debian/Ubuntu) or sudo dnf install iputils traceroute nmap curl (Fedora/RHEL).

How the Linux Kernel Implements the Network Stack

The Linux kernel implements the TCP/IP model directly. Understanding this helps you know where to look when troubleshooting:

+---------------------------------------------------------------+
|  USER SPACE                                                   |
|  +-------------------+  +-------------------+                 |
|  | curl / nginx /    |  | Application       |                 |
|  | your application  |  | (uses sockets)    |                 |
|  +--------+----------+  +--------+----------+                 |
|           |                       |                            |
|           v     SYSTEM CALLS      v                            |
|  =========================================                    |
|  KERNEL SPACE                                                 |
|  +---------------------------------------------------+       |
|  | Socket Layer                                       |       |
|  | (connects userspace to the network stack)          |       |
|  +---------------------------------------------------+       |
|  +---------------------------------------------------+       |
|  | Transport Layer (TCP / UDP)                        |       |
|  | /proc/sys/net/ipv4/tcp_*  -- tuning parameters     |       |
|  +---------------------------------------------------+       |
|  +---------------------------------------------------+       |
|  | Network Layer (IP, routing, netfilter/iptables)    |       |
|  | /proc/sys/net/ipv4/ip_forward -- routing toggle    |       |
|  +---------------------------------------------------+       |
|  +---------------------------------------------------+       |
|  | Device Drivers (Ethernet, Wi-Fi)                   |       |
|  | /sys/class/net/  -- device information              |       |
|  +---------------------------------------------------+       |
|  =========================================                    |
|  HARDWARE (NIC)                                               |
+---------------------------------------------------------------+

# See kernel network parameters
sysctl -a | grep net.ipv4 | head -20

# Check if IP forwarding is enabled (routing)
cat /proc/sys/net/ipv4/ip_forward
# 0 = disabled, 1 = enabled

# See network device info
ls /sys/class/net/

Debug This

A web application running on 192.168.1.50:8080 is unreachable from a client at 192.168.1.100. Walk through the layers to find the problem.

# Layer 1: Is the interface up?
ip link show eth0
# Output: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP>  state UP
# Layer 1 is fine.

# Layer 2: Can we resolve the MAC address?
arping -c 1 192.168.1.50
# Output: Unicast reply from 192.168.1.50 [aa:bb:cc:dd:ee:ff]
# Layer 2 is fine.

# Layer 3: Can we ping the host?
ping -c 3 192.168.1.50
# Output: 3 packets transmitted, 3 received, 0% packet loss
# Layer 3 is fine.

# Layer 4: Is the port open?
nc -zv 192.168.1.50 8080
# Output: Connection refused
# Layer 4 PROBLEM -- nothing is listening on port 8080

Diagnosis: Layers 1-3 are all functional. The problem is at Layer 4 -- the application is not listening on port 8080. Possible causes: the application crashed, it is bound to localhost only, or it is running on a different port.

# On the server (192.168.1.50), check what is listening:
ss -tlnp | grep 8080
# (no output -- nothing on 8080)

ss -tlnp | grep python
# Output: LISTEN  0  5  127.0.0.1:8000  users:(("python3",pid=1234))

The app is running on port 8000 (not 8080) and bound to 127.0.0.1 (not all interfaces). Two problems, both at Layer 4/7. Fix the application configuration to listen on 0.0.0.0:8080.

What Just Happened?

+------------------------------------------------------------------+
|                        CHAPTER RECAP                              |
+------------------------------------------------------------------+
|                                                                   |
|  The OSI model has 7 layers; the TCP/IP model has 4.            |
|                                                                   |
|  OSI (bottom to top): Physical, Data Link, Network,             |
|    Transport, Session, Presentation, Application.               |
|                                                                   |
|  TCP/IP: Network Access, Internet, Transport, Application.      |
|                                                                   |
|  DATA ENCAPSULATION: each layer wraps data with its header.     |
|    Application: Data -> Transport: Segment -> Network: Packet   |
|    -> Data Link: Frame -> Physical: Bits                        |
|                                                                   |
|  TROUBLESHOOTING: Start at Layer 1 and work up.                 |
|    L1: Link up? | L2: ARP? | L3: Ping? Route?                  |
|    L4: Port open? | L7: App responding?                         |
|                                                                   |
|  Know the layers to COMMUNICATE precisely with your team.       |
|                                                                   |
+------------------------------------------------------------------+

Try This

1. Layer Identification: For each of the following scenarios, identify which OSI layer is most likely the source of the problem:

   • A server's Ethernet cable was unplugged
   • DNS resolution fails but pinging IP addresses works
   • A firewall is blocking port 443
   • A website returns a 500 Internal Server Error
   • A Wi-Fi adapter is not detected by the system

2. Trace a Request: Run curl -v https://example.com and identify which layers are involved at each stage of the output (DNS resolution, TCP connection, TLS handshake, HTTP request/response).

3. Layer-by-Layer Check: Pick a remote server you have access to. Walk through the troubleshooting checklist above, running each command and documenting the output.

4. Packet Capture: If you have tcpdump installed, capture some traffic and identify the Layer 2 (MAC), Layer 3 (IP), and Layer 4 (TCP/UDP port) information:

   sudo tcpdump -i any -c 10 -nn
   

5. Bonus Challenge: Draw your own network diagram showing how a packet travels from your machine to google.com. Include every device and every layer transition. How many Layer 3 hops does tracepath google.com show?