Linux Administration
Linux Networking Basics
In this lesson
Linux networking is the foundation of everything a server does for its users — serving web requests, accepting SSH connections, querying databases, and communicating with external APIs all depend on correctly configured network interfaces, routing tables, and DNS resolution. Understanding how Linux represents and manages network connectivity is essential for every administrator, whether managing a single server or a fleet of hundreds.
Network Interfaces and the ip Command
Every network connection on a Linux system is represented as a network interface — a virtual or physical device with a name, a MAC address, and one or more IP addresses. The ip command is the modern tool for managing all aspects of network interfaces, replacing the deprecated ifconfig.
Fig 1 — A physical network interface and the loopback interface
# Show all network interfaces with addresses — the primary view
ip addr show
ip a # shorthand
# Show a specific interface
ip addr show eth0
# Show interface link state, speed, and statistics
ip link show
ip -s link show eth0
# Bring an interface up or down
sudo ip link set eth0 up
sudo ip link set eth0 down
# Add a secondary IP address to an interface (temporary — lost on reboot)
sudo ip addr add 192.168.1.20/24 dev eth0
# Remove an IP address
sudo ip addr del 192.168.1.20/24 dev eth0
# List all interfaces briefly
ip -br addr showWhat just happened? ip -br addr gave a compact one-line summary per interface. The UNKNOWN state on lo is expected — loopback has no physical link layer to report. The dynamic flag on eth0's IPv4 address means it was assigned by DHCP — a server running critical services should have a static IP or a DHCP reservation to prevent the address changing unexpectedly.
IP Addressing and CIDR Notation
Every interface on a network needs an IP address and a subnet mask that defines which other addresses are on the same local network. CIDR notation (Classless Inter-Domain Routing) expresses both in a single compact form — the address followed by a slash and the number of network bits. Understanding CIDR is prerequisite knowledge for every firewall rule, routing decision, and DNS configuration.
Fig 2 — CIDR notation: network portion, host portion, prefix length, and common subnet sizes
Routing — How Packets Find Their Destination
When a Linux system sends a packet, it consults its routing table to decide where to send it. If the destination IP is on a directly connected subnet, the packet goes directly. Otherwise it is sent to a default gateway — a router that knows how to forward it further. Understanding and managing routing tables is fundamental to diagnosing connectivity problems.
Analogy: The routing table is like a set of postal sorting rules. When a letter arrives, the sorter checks: "Is this address in my local delivery area?" — if yes, deliver directly. "Is it somewhere else?" — send it to the central hub (default gateway) which handles everything else. The most specific matching rule always wins.
# Show the routing table — the primary routing view
ip route show
ip r # shorthand
# Show route for a specific destination — which interface and gateway would be used
ip route get 8.8.8.8
ip route get 192.168.1.50
# Add a static route (temporary — lost on reboot)
sudo ip route add 10.10.0.0/16 via 192.168.1.1 dev eth0
# Add a default gateway
sudo ip route add default via 192.168.1.1
# Delete a route
sudo ip route del 10.10.0.0/16
# Show the ARP table — IP to MAC address mappings on the local network
ip neigh show
arp -nWhat just happened? The routing table has three entries. The default route catches all traffic that doesn't match anything more specific, sending it via the gateway at 192.168.1.1. The 192.168.1.0/24 route (added by the kernel automatically) means local subnet traffic goes directly. ip route get showed exactly which path each destination would take — 8.8.8.8 goes via the gateway, 192.168.1.50 goes direct.
DNS Resolution
DNS (Domain Name System) translates human-readable names like api.example.com into IP addresses. Linux resolves names through a chain: local /etc/hosts entries first, then the DNS resolvers configured in /etc/resolv.conf, with the order controlled by /etc/nsswitch.conf.
Checked first. Static mappings — override DNS for specific names. Useful for local development, blocking domains, and testing.
Configured in /etc/resolv.conf. On modern systems this file is managed by systemd-resolved or NetworkManager — do not edit it directly.
/etc/nsswitch.conf defines the order. The line hosts: files dns means check /etc/hosts first, then DNS.
# Look up a hostname — the standard dig command
dig api.example.com
dig api.example.com A # only A records
dig api.example.com MX # mail records
# Quick hostname lookup
host api.example.com
nslookup api.example.com
# Look up using a specific DNS server (bypass system resolver)
dig @8.8.8.8 api.example.com
# Show what DNS servers are configured
cat /etc/resolv.conf
resolvectl status # systemd-resolved systems
# Show the resolution order
grep "^hosts" /etc/nsswitch.conf
# View and edit /etc/hosts
cat /etc/hosts
echo "127.0.0.1 myapp.local" | sudo tee -a /etc/hosts
# Flush the DNS cache (systemd-resolved)
sudo resolvectl flush-caches
sudo systemd-resolve --flush-caches # older aliasWhat just happened? On modern Ubuntu/Debian systems, /etc/resolv.conf points to 127.0.0.53 — the local stub resolver run by systemd-resolved. The actual upstream DNS servers (8.8.8.8, 8.8.4.4) are managed by resolvectl. The nsswitch.conf line explains why /etc/hosts entries always win over DNS — files comes before dns.
Persistent Network Configuration
Changes made with ip commands are temporary — they vanish on reboot. Permanent network configuration on modern Linux is handled by one of three systems depending on the distribution: Netplan (Ubuntu 18.04+), NetworkManager (desktop and RHEL), or systemd-networkd (minimal servers and containers).
Netplan (Ubuntu 18.04+)
YAML configuration files in /etc/netplan/. Netplan generates the actual config for either NetworkManager or systemd-networkd as the backend renderer.
network:
version: 2
ethernets:
eth0:
addresses: [192.168.1.10/24]
routes:
- to: default
via: 192.168.1.1
nameservers:
addresses: [8.8.8.8, 8.8.4.4]
NetworkManager (RHEL / desktop)
Connection profiles stored in /etc/NetworkManager/system-connections/. Managed with nmcli on servers or the GUI on desktops.
# nmcli commands
nmcli connection show
nmcli con mod eth0 \
ipv4.addresses 192.168.1.10/24 \
ipv4.gateway 192.168.1.1 \
ipv4.method manual
nmcli con up eth0
# ── Netplan (Ubuntu) ──────────────────────────────────────────────
# Show current Netplan configuration
cat /etc/netplan/01-netcfg.yaml
# Validate and test a Netplan config (apply for 120s, auto-revert if not confirmed)
sudo netplan try
# Apply Netplan configuration permanently
sudo netplan apply
# ── NetworkManager (RHEL/Rocky) ───────────────────────────────────
# List all connection profiles
nmcli connection show
# Show details of a specific connection
nmcli connection show eth0
# Set a static IP on a connection
sudo nmcli con mod "eth0" \
ipv4.method manual \
ipv4.addresses "192.168.1.10/24" \
ipv4.gateway "192.168.1.1" \
ipv4.dns "8.8.8.8 8.8.4.4"
sudo nmcli con up "eth0"
# ── Both systems ──────────────────────────────────────────────────
# Restart networking entirely (use with caution on remote systems)
sudo systemctl restart NetworkManager # RHEL
sudo netplan apply # UbuntuWhat just happened? netplan try is a safety net built into Netplan — it applies the new configuration but automatically reverts after 120 seconds unless you press Enter to confirm. This means a misconfigured network change on a remote server cannot permanently lock you out: the old configuration is restored on timeout. Always use netplan try over netplan apply when making connectivity changes on a server you access remotely.
Basic Network Diagnostics
When connectivity fails, a systematic layer-by-layer approach isolates the problem quickly. The OSI model maps naturally to Linux commands — check the physical link, then the IP layer, then routing, then DNS, then the application. Each tool confirms one layer is working before moving to the next.
Layer 1/2 — Is the interface up and connected?
Check that the interface is UP and has a carrier (physical link). Look for LOWER_UP in the flags — this means the physical link is active.
ip link show eth0 # look for UP and LOWER_UP in the flags
Layer 3 — Does the interface have an IP address?
No IP means either DHCP failed or static config is missing. Ping the loopback to confirm the IP stack itself is functional.
ip addr show eth0
ping -c 3 127.0.0.1
Layer 3 — Can you reach the gateway?
Ping the default gateway. If this fails, the problem is local — wrong gateway IP, firewall blocking ICMP, or a routing issue on the local network.
ip route show | grep default # find gateway IP
ping -c 3 192.168.1.1
Layer 3 — Can you reach a public IP?
Ping a known public IP directly. If this works but DNS fails, the network is fine but DNS is broken. If this fails, routing or NAT beyond the gateway is the issue.
ping -c 3 8.8.8.8
Layer 7 — Does DNS resolution work?
Only reach this step after IP connectivity is confirmed. If ping 8.8.8.8 works but ping google.com does not, the problem is DNS — not network.
dig google.com +short
ping -c 3 google.com
# Trace the path to a destination — each hop shown with latency
traceroute 8.8.8.8
tracepath 8.8.8.8 # no root required
# Test TCP connectivity to a specific port (without curl)
nc -zv 192.168.1.50 443 # -z = scan, -v = verbose
timeout 5 bash -c 'cat < /dev/null > /dev/tcp/192.168.1.50/443' && echo "open"
# Show all active network connections
ss -tunp
# Watch network traffic on an interface (requires tcpdump)
sudo tcpdump -i eth0 -n host 8.8.8.8
sudo tcpdump -i eth0 port 443 -nWhat just happened? traceroute mapped the path to 8.8.8.8 hop by hop — the * * * at hop 3 means that router is dropping ICMP probes (common behaviour), but traffic is still flowing through it as shown by hop 4 responding. nc -zv confirmed that TCP port 443 on the target server is open and accepting connections — a quick TCP-level health check that does not require making an actual HTTP request.
Never Edit /etc/resolv.conf Directly on systemd-resolved Systems
On modern Ubuntu and RHEL systems, /etc/resolv.conf is a symlink managed by systemd-resolved or NetworkManager. Any changes you write directly to it will be silently overwritten the next time the network reconfigures — usually within seconds or on the next reboot. Configure DNS through resolvectl dns, Netplan's nameservers: field, or nmcli con mod ipv4.dns depending on your network stack.
Lesson Checklist
ip addr, ip route, and ip link instead of the deprecated ifconfig and route
ip route get to determine which path a packet would take to any destination
/etc/hosts first, then the resolver — and I use resolvectl or Netplan to configure DNS, not by editing /etc/resolv.conf directly
netplan try rather than netplan apply when making network changes on remote servers, to get automatic rollback on misconfiguration
Teacher's Note
The single most common connectivity mistake is confusing a DNS failure with a network failure. The five-layer diagnostic approach makes this immediately visible: if ping 8.8.8.8 succeeds but ping google.com fails, the network is fine — the problem is DNS. Knowing this distinction saves enormous debugging time and prevents the common mistake of restarting networking services when only a DNS reconfiguration is needed.
Practice Questions
1. A server running Ubuntu 24.04 cannot reach the internet. ip addr show eth0 shows the interface is UP with IP 192.168.1.50/24. Write out the exact sequence of diagnostic commands you would run, in order, to identify whether the problem is the gateway, routing, or DNS — explaining what each command tells you.
2. You need to set a static IP address of 10.0.1.100/24 with gateway 10.0.1.1 and DNS 8.8.8.8 on an Ubuntu 24.04 server's eth0 interface, surviving reboots. Write the complete Netplan YAML configuration and the command to safely apply it without risking permanent lockout.
3. Explain what the subnet 10.0.0.0/8 means in terms of how many hosts it can contain, and how many usable addresses are available in a /24 subnet. Why would a production server typically be given an address from a private range rather than a public IP directly?
Lesson Quiz
1. You run sudo ip addr add 10.0.0.5/24 dev eth0. What happens to this configuration after the next reboot?
2. ping 8.8.8.8 succeeds but ping google.com fails with "Name or service not known". What is the problem?
3. Why should you use netplan try rather than netplan apply when making network changes on a remote server?
Up Next
Lesson 27 — Network Configuration & Troubleshooting
Advanced network configuration, bonding, VLANs, and systematic troubleshooting with tcpdump and ss