Linux Networking Overview

Networking is one of those Linux topics where a few commands can hide a surprisingly large system underneath them. When you run ip addr, connect to a server, resolve a hostname, or make an HTTP request with curl, several layers of Linux networking are working together.

Before looking at individual commands, it is worth building the map first. Once you understand how an application turns data into packets, how those packets move through the kernel, and how Linux decides where to send them, the commands in the rest of this section stop looking like unrelated utilities.

What Does “Linux Networking” Actually Mean?

When we say a Linux machine is “connected to the network”, several different things are involved.

The machine needs:

• a network interface through which packets can enter and leave
• an IP address so it can participate in an IP network
• a routing table so Linux knows where packets should go
• a way to resolve names such as example.com
• transport protocols such as TCP or UDP
• sockets through which applications communicate
• a kernel networking stack that processes the packets between applications and interfaces

These pieces have different jobs.

A useful first picture is:

Application
    │
    │ socket
    ▼
TCP / UDP
    │
    ▼
    IP
    │
    ▼
Routing
    │
    ▼
Network Interface
    │
    ▼
Network

That diagram is deliberately simplified. The important idea is that an application normally does not manipulate Ethernet frames or network hardware directly.

The application asks the kernel to communicate.

The Linux kernel handles the networking work underneath it.

Where Does The Kernel Fit?

Suppose you run a program that connects to a web server.

The program might conceptually say:

Connect to 93.184.216.34 on TCP port 443

The application does not need to know how the Ethernet frame is constructed or which physical interface should carry it.

Instead, it uses the socket interface provided by the operating system.

The simplified path looks like this:

Application
    │
    │ socket API
    ▼
Linux Kernel
    │
    ├── TCP
    ├── IP
    ├── Routing
    └── Network interface
             │
             ▼
          Network

The kernel is the central piece connecting applications to the actual network.

This is why later commands such as ip, ss, and tools such as curl are useful in different ways. Some interact with or inspect kernel networking state; others are applications that use the networking facilities provided by the kernel.

How Does A Packet Leave The Machine?

Let’s follow a simple example.

Imagine your Linux machine has:

IP address: 192.168.1.20
Default gateway: 192.168.1.1

You run a program that wants to communicate with:

93.184.216.34

The destination is not on the local 192.168.1.0/24 network.

Linux therefore needs to send the packet through the default gateway.

The simplified flow is:

Application
    │
    ▼
Socket
    │
    ▼
   TCP
    │
    ▼
IP packet
    │
    ▼
Routing table
    │
    │ destination is outside local network
    ▼
Default gateway
    │
    ▼
Network interface
    │
    ▼
Physical / wireless network

The important decision happens at routing.

Kernel looks at the destination IP address and its routing table to determine where the packet should go next.

We will examine that properly in the Routing topic.

What Happens When A Packet Comes Into The Machine?

The direction reverses when another machine sends data to you.

Conceptually:

Network
    │
    ▼
Network interface
    │
    ▼
Linux kernel
    │
    ├── IP
    ├── TCP / UDP
    └── socket lookup
          │
          ▼
       Application

The network interface receives the incoming frame.

The kernel processes it through the networking stack.

Eventually, if the packet belongs to a socket owned by an application, the kernel makes the data available to that application.

So networking is not only:

application → network

It is equally:

network → kernel → application

This distinction becomes particularly important when debugging. A service can be running perfectly while the network traffic never reaches the machine, or the traffic can reach the machine while no application is listening on the destination port.

A More Complete Mental Model

Now we can put the major pieces together:

    flowchart TB
    A["Application"] --> S["Socket"]
    S --> T["TCP / UDP"]
    T --> IP["IP"]
    IP --> R["Routing"]
    R --> I["Network Interface"]
    I --> N["Network"]

    N --> I
    I --> R
    R --> IP
    IP --> T
    T --> S
    S --> A
  

The top-to-bottom direction represents outgoing traffic.

The bottom-to-top direction represents incoming traffic.

This is not meant to describe every internal kernel operation. Real Linux networking contains additional layers and processing paths. It is a working mental model that is accurate enough for the administration tasks in this course.

What Is A Network Interface?

A network interface is the Linux representation of a connection to a network.

It might represent:

• a physical Ethernet adapter
• a wireless adapter
• a virtual Ethernet device
• a loopback interface
• another virtual or specialized network device

You will commonly see names such as:

lo
enp3s0
eth0
wlan0
wlp2s0

The exact naming depends on the system and its configuration.

For example:

lo

is the loopback interface. It allows a machine to communicate with itself.

An Ethernet or Wi-Fi interface provides connectivity to an external network.

The important point is that an interface is not the same thing as an IP address.

Think of them as separate pieces:

Network Interface
        │
        └── can have one or more IP addresses

We’ll inspect both with ip in the next topic.

Where Does An IP Address Fit?

An IP address identifies an endpoint at the IP layer.

For example:

192.168.1.20

The interface provides the network connection, while the IP configuration gives that interface an address that can participate in an IP network.

A simplified view is:

Linux machine
┌─────────────────────────────┐
│                             │
│  Application                │
│       │                     │
│     Socket                  │
│       │                     │
│   Linux kernel              │
│       │                     │
│  Network interface          │
│       │                     │
│  192.168.1.20               │
│                             │
└────────────┬────────────────┘
             │
           Network

Later, when you run:

ip addr

you are asking Linux to show you the addresses configured on its interfaces.

When you run:

ip link

you are primarily looking at the interfaces themselves and their link state.

The distinction will become important when troubleshooting.

What Is Routing Doing?

Knowing the destination IP is not enough.

Suppose your machine needs to send a packet to:

8.8.8.8

There may be several possible network interfaces or routes available.

Linux needs an answer to:

Which path should this packet take?

That is the job of the routing table.

A simplified routing table might contain:

Destination       Next Hop              Interface
192.168.1.0/24    directly connected    enp3s0
0.0.0.0/0         192.168.1.1           enp3s0

The first route says:

Destinations in 192.168.1.0/24 are directly reachable through this interface.

The second is the default route:

For destinations that don’t match a more specific route, send the packet to 192.168.1.1.

You will inspect this with:

ip route

and later build a small Linux router so this isn’t just a theoretical table.

Where Does DNS Fit?

There is another problem.

Humans usually work with names:

example.com

Networks ultimately need an IP address:

93.184.216.34

DNS provides the mechanism for translating names into network addresses.

A simplified application flow is:

Application
    │
    │ "What is example.com?"
    ▼
DNS resolver
    │
    ▼
DNS server
    │
    ▼
IP address
    │
    ▼
Application connects

DNS is therefore related to networking, but it is not the same thing as routing.

This distinction matters during troubleshooting.

For example:

DNS works
    ≠
Network connectivity works

You can successfully resolve a hostname while being unable to connect to the resulting IP address.

Likewise, a service can be reachable by IP while its hostname fails to resolve.

We’ll investigate this separately in the DNS Resolution topic.

Where Do Ports And Sockets Fit?

An IP address identifies the network endpoint, but a machine can run many network applications at the same time.

For example:

192.168.1.20:22
192.168.1.20:80
192.168.1.20:443
192.168.1.20:5432

The IP address identifies the machine.

The port identifies the service endpoint.

A process creates a socket to communicate through the network, and that socket can be associated with an address and port.

Conceptually:

IP address
    +
Port
    │
    ▼
Network endpoint
    │
    ▼
Socket
    │
    ▼
Application process

Later, we will create a tiny Python TCP listener and inspect it with ss and nc.

The goal isn’t to build a production server. It is to make the relationship between:

process → socket → port → network

visible.

Putting The Whole Picture Together

At this point, you can think about Linux networking as several connected layers:

    flowchart TB
    APP["Application<br/>curl / Python / browser"] --> SOCK["Socket"]
    SOCK --> TRANS["Transport<br/>TCP / UDP"]
    TRANS --> NET["Network Layer<br/>IP"]
    NET --> ROUTE["Routing Table"]
    ROUTE --> IFACE["Network Interface"]
    IFACE --> LINK["Local Network / Wi-Fi / Ethernet"]
    LINK --> OTHER["Other Hosts / Internet"]
  

And on the way back:

Other host
    ↓
Network interface
    ↓
IP
    ↓
TCP / UDP
    ↓
Socket
    ↓
Application

Each layer answers a different question:

Don’t treat this table as a set of isolated definitions. The important thing is how the pieces cooperate.

A Simple Packet Walk

Imagine you run (if you don’t know curl it fetches example.com here):

curl https://example.com

A simplified version of what happens is:

curl
  │
  │ needs example.com
  ▼
DNS resolution
  │
  ▼
IP address
  │
  ▼
Create/use socket
  │
  ▼
TCP connection to port 443
  │
  ▼
Linux routing decision
  │
  ▼
Network interface
  │
  ▼
Network
  │
  ▼
Remote server

The response comes back through the reverse path:

Remote server
      │
      ▼
Network
      │
      ▼
Network interface
      │
      ▼
Linux kernel
      │
      ▼
TCP
      │
      ▼
Socket
      │
      ▼
curl

This is why a simple command such as curl can actually exercise many different parts of Linux networking.

It isn’t just “a command that talks to a website.”

It is an application using the Linux networking stack.

What Happens If One Piece Is Broken?

This layered view is especially useful when something doesn’t work.

Suppose:

curl https://example.com

fails.

That doesn’t immediately tell you what is broken.

Possibilities include:

DNS problem
    ↓
hostname cannot be resolved

Routing problem
    ↓
packet has no usable route

Interface problem
    ↓
machine cannot reach the network

Port / service problem
    ↓
remote endpoint isn't accepting the connection

TCP problem
    ↓
connection cannot be established

HTTP problem
    ↓
connection works but the request/response has a problem

The debugging lesson later in this section will turn this into a practical troubleshooting method.

For now, the important habit is:

Don’t treat “the network is down” as one problem. Identify which layer is failing.

What You Should Remember

Linux networking is a collection of cooperating pieces rather than one single subsystem you interact with through one command.

The most useful mental model for this course is:

Application
    ↓
Socket
    ↓
TCP / UDP
    ↓
IP
    ↓
Routing
    ↓
Network Interface
    ↓
Network

And for incoming traffic:

Network
    ↓
Network Interface
    ↓
IP
    ↓
TCP / UDP
    ↓
Socket
    ↓
Application

DNS sits alongside this flow to translate names into addresses, while the routing table determines where IP traffic should go.

Once this picture is clear, the individual commands become much easier to understand. ip addr shows the addressing side, ip route shows the routing side, ss shows sockets and connections, curl uses the stack to communicate with remote services, and the debugging tools help you determine which part of the path is failing.

What’s Next

Now that the overall path is clear, we’ll start at the point where Linux actually connects to the network: interfaces and IP addresses.

You’ll use ip link to inspect interfaces and ip addr to examine their addresses, then connect the output back to the networking model you’ve just built.