Table of Contents
Understanding Linux Networking at a Practical Level
This chapter gives you enough networking knowledge to be productive as a Linux admin: how IP works, how Linux participates in a network, and which tools and files you will use all the time. Detailed topics like “IP addressing”, “Subnets and routing”, and the named tools will each have their own chapters, so here we stay at the “big picture + day‑to‑day admin view”.
What “networking” means for a Linux system
On a Linux machine, “the network” basically means three things:
- Interfaces — the “ports” the system uses to talk to other machines
Examples: - Physical:
eth0,enp3s0,wlp2s0(wired/wireless) - Virtual:
lo(loopback),docker0,tun0,tap0,br0, VLANs likeeth0.10 - Addresses and routes — where packets should go, and how to get there
- IP addresses:
192.168.1.10,10.0.0.5,2001:db8::1 - Default gateway: “send non-local traffic here”
- Routing table: rules like “for 10.0.0.0/24, use this interface/gateway”
- Name resolution and services — usable names and listening servers
- DNS: turning
example.cominto an IP - Local name files:
/etc/hosts - Services: daemons listening on ports (web, SSH, database, etc.)
Most everyday network tasks on Linux are about:
- Checking “do we have an IP, gateway, DNS?”
- Verifying “can we reach X?”
- Diagnosing “where does it break: local config, path, or remote side?”
The basic networking model on Linux
Linux implements a standard TCP/IP stack, so the concepts are the same across platforms. As a sysadmin, you generally think in three layers:
- Link layer (L2) – physical & local network:
- Uses MAC addresses
- Ethernet, Wi-Fi, VLANs, bridges, switches
- Internet layer (L3) – IP and routing:
- IPv4: addresses like
192.168.0.10 - IPv6: addresses like
2001:db8::1 - Routing decisions: which next hop to use
- Transport layer (L4) – TCP/UDP ports:
- TCP: reliable (used by HTTP, SSH, etc.)
- UDP: best-effort (DNS, many streaming protocols)
- Ports:
22(SSH),80(HTTP),443(HTTPS), etc.
Linux tools let you inspect and manipulate each part: link (interfaces), IP addressing/routing, and ports/connections.
Network interface naming and states
Historically, network interfaces were named eth0, eth1, etc. Modern systems often use predictable names like enp3s0 or wlp2s0. Some key points:
- Common interface types
lo— loopback; every Linux system has this; always127.0.0.1and::1en…— Ethernet (wired)wl…— Wireless LAN (Wi‑Fi)br…— bridges (used in virtualization, containers)tun…/tap…— VPN or other tunnel interfacesvlanoreth0.10— VLAN tagged interfaces- Basic states
- UP / DOWN: whether the interface is enabled in the OS
- carrier: whether a physical link is detected (for wired)
- configured: has IP addresses / routes been assigned?
Network managers (like NetworkManager, systemd-networkd, or classic ifupdown) typically handle bringing interfaces up/down and assigning IPs via DHCP or static configuration.
DHCP vs static configuration (conceptual view)
Linux interfaces usually get their IP configuration in one of two ways:
- DHCP (dynamic):
- The system asks a DHCP server for:
- IP address
- Gateway (router)
- DNS servers
- Very common on desktops, laptops, simple servers behind routers.
- Static IP:
- IP address, subnet mask/prefix, gateway, and DNS are manually configured.
- Common on servers and infrastructure devices where IP must not change.
As an admin, you should be able to answer:
- “Is this interface using DHCP or static?”
- “Which config mechanism manages it?” (NetworkManager,
systemd-networkd, distro-specific scripts, etc.) - “Where is the configuration stored?” (varies by distro; covered later in
Editing network configuration files).
Name resolution basics: how Linux finds hosts
When you type ping example.com, Linux must turn that name into an IP.
The typical resolution order is:
- Check
/etc/hostsfor static entries. - Ask a DNS resolver (IP configured via DHCP or static config).
- Possibly other methods (like mDNS, LDAP, etc.) depending on
/etc/nsswitch.conf.
Important files you will rely on:
/etc/hosts– local static hostname-to-address mapping./etc/resolv.conf– usually contains DNS server addresses and search domains./etc/nsswitch.conf– controls the name service lookup order (files, DNS, etc.).
Modern systems may have a local stub resolver (e.g. systemd-resolved) that dynamically manages /etc/resolv.conf, so changes to that file may be overwritten unless you configure the resolver itself.
Common network services and ports
As a Linux admin, you regularly care about which services are:
- Listening: “Is the daemon bound to the right IP/port?”
- Reachable: “Can clients connect from the expected networks?”
You do not have to memorize all ports, but you should know some common ones:
- SSH: TCP
22 - HTTP: TCP
80 - HTTPS: TCP
443 - DNS: UDP
53(and TCP53for some queries) - SMTP (mail): TCP
25 - MySQL/MariaDB: TCP
3306 - PostgreSQL: TCP
5432
Network tools (like ss) show you which processes listen on which ports; firewalls may allow/deny specific ports.
Typical troubleshooting workflow on Linux
Most network problems can be narrowed down by checking a few predictable things. A common, platform-agnostic workflow:
- Check link/interface status
- Is the interface UP?
- Is the cable plugged in / Wi‑Fi connected?
- Check IP configuration
- Does the interface have an IP?
- Is the subnet correct?
- Is there a default route (gateway)?
- Check name resolution
- Can you reach the target by IP?
- Does DNS resolve the hostname?
- Check path and reachability
- Can you ping the gateway and remote host?
- Is something along the route dropping packets?
- Check ports and firewalls
- Is the remote port listening?
- Is a local or remote firewall blocking?
In later sections you will see which Linux tools (ip, ss, ping, etc.) help with which step.
Core network tools on Linux (high-level view)
Each of these tools will have its own detailed coverage later; here is how they fit in conceptually:
ip(from theiproute2suite)- The modern, all-in-one tool for:
- Viewing and configuring interfaces
- Assigning IP addresses
- Inspecting and changing routes
- Replaces many older
ifconfig/route/netstatuses. ss- Shows sockets: which ports are listening, which connections exist, and which process owns them.
ping- Tests basic reachability to another host using ICMP echo requests.
- Good for “is there a network path?” but not for checking ports/services.
traceroute/tracepath- Show the path packets take across routers between your host and a target.
- Useful when the problem is “somewhere in the middle”.
dig/host/nslookup- DNS query tools:
- Check what IP a name resolves to
- Ask specific DNS servers
- Debug DNS issues.
curl/wget- HTTP/HTTPS and other protocol clients, useful to:
- Verify that a web service is responding correctly
- Fetch files from URLs.
nmtui/nmcli/systemd-networkdtools- Distro- and stack-specific tools for configuring interfaces.
- Used to manage permanent network settings rather than quick temporary changes.
You rarely need to use all of them for a single issue; choice depends on what you are diagnosing.
Local vs remote problems
When something “doesn’t work” from your Linux box, it helps to quickly decide:
- Local problem:
- No IP on interface
- Wrong gateway or DNS configuration
- Local firewall rules blocking
- Service not listening or misconfigured locally
- Remote/path problem:
- Remote host down or firewall enabled
- Network path broken between routers
- DNS records at the server side wrong
- Load balancer or proxy misconfiguration
Your goals as an admin:
- Confirm if your Linux box is correctly configured.
- Gather enough information (routes, traces, logs) to talk to whoever owns the remote side or the network infrastructure, if needed.
Security considerations in networking
You will see dedicated security topics later, but even basic networking work has some essential security aspects:
- Exposed services:
- Only run services you actually need.
- Bind them to appropriate interfaces (e.g. only localhost for internal-only services).
- Firewalls:
- Always consider host-level firewalls (e.g.
ufw,firewalld, rawiptables/nftables). - Network connectivity may look fine but still be blocked at the firewall.
- Plain vs encrypted protocols:
- Prefer encrypted protocols (SSH instead of Telnet, HTTPS instead of HTTP) when crossing untrusted networks.
- Access control:
- For servers, restrict which IPs or networks can connect to sensitive services where possible.
How networking ties into other admin tasks
Networking is interwoven with many other topics you’ll cover later:
- Service management:
- A service may “fail” because the network it depends on isn’t ready or reachable.
- Logs:
- Many connection problems show up in logs (
/var/logorjournalctl). - Storage and backup:
- Network filesystems (NFS, Samba) and backup targets rely on solid networking.
- Security and monitoring:
- Intrusion detection, firewalls, and monitoring tools all rely on correct network setup.
Understanding the fundamentals in this chapter will make those later topics much easier to follow.