Linux networking fundamentals

This page opens the Networking module of the Linux course. It gives you the mental model shared by every lesson that follows: an interface carries an IP address, a routing table decides where packets leave, a DNS resolver translates names into addresses. You leave this page able to read the network state of a server, to pick the configuration tool that matches your distribution, and to know which lesson holds the exact procedure you need. The detailed configuration commands live in the dedicated lessons, not here.

What you will learn

• Read the network state of a server with ip and spot the interface that carries the traffic.
• Tell apart the four essential building blocks: interface, address, default route, DNS.
• Choose between static addressing and DHCP according to the role of the machine.
• Identify the configuration tool actually in place: systemd-networkd, Netplan or NetworkManager.
• Apply a network change with the right command for the distribution, without cutting your SSH session.
• Place each lesson of the module and what it covers.

The lessons of the module, in order

The module follows a deliberate progression: first observe with ip, then configure persistently with the tool of your distribution, then diagnose when nothing answers any more, transfer files between machines, and finally run two everyday network services: time and load balancing. Follow this order if you are starting out: each lesson assumes the previous one. If you are looking for a precise procedure, go straight to the matching lesson, grouped below by use.

Observe, then configure. The ip lesson teaches you to read and change interfaces, addresses, routes and neighbours from the command line, without making anything persistent. Persistence depends on the distribution: Netplan in YAML on Ubuntu Server, NetworkManager with nmcli on RHEL and its derivatives. The bond and bridge lesson adds a redundant interface and a bridge for your VMs, with a proven failover.

Diagnose. Diagnose a network problem walks up the chain interface, address, route, DNS and service, starting from the observed symptom.

Transfer files. Three tools, three uses, all on top of SSH: SCP for a one-off copy, SFTP for an interactive session, rsync for the differential transfer of backups and large volumes.

Run two network services. chrony keeps the right time on every server, over NTP as well as encrypted NTS, and HAProxy puts a single entry point in front of several servers, with failover.

You really are starting from scratch

If the words IP address, port or gateway do not mean much to you yet, start with the lesson Networking basics on Linux of the Fundamentals module, then Test network connectivity. This module picks up one level higher: configuring, not discovering.

The four building blocks to identify on a server

Before changing anything, you need to know what is already in place. All Linux connectivity rests on four elements, and a network incident almost always comes from one of them. An interface (the network card, physical or virtual) carries one or more IP addresses with their subnet mask. The routing table holds at least a default route to the gateway, without which nothing leaves the local network. The DNS resolver translates names into addresses. Remember this order: it is the order of the diagnosis.

Interface names

Every network card has a name, and that name depends on the convention in force on the machine. The old eth0, eth1 followed the order of hardware detection, which made the name unstable across reboots. systemd's predictable names (enp0s3, ens33) derive from the position on the PCI bus and no longer move. Wireless interfaces show up as wlan0 or wlp3s0. Never hard-code eth0 in a script without checking the real name on the target machine.

The ip a command prints the full inventory, interfaces and addresses together:

ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1280 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:4f:bf:53 brd ff:ff:ff:ff:ff:ff
    altname enx00155d4fbf53
    inet 172.19.104.109/20 brd 172.19.111.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::215:5dff:fe4f:bf53/64 scope link
       valid_lft forever preferred_lft forever

Three pieces of information matter in this output. The UP state signals that the link is active; a DOWN interface alone explains a total outage. The inet address gives the IPv4 and its mask (/20 here, that is 255.255.240.0). scope global marks a routable address, as opposed to the scope host of the lo loopback. Every option of the command is detailed in the lesson ip.

Address, route and DNS

An address alone is not enough to reach the Internet. You also need a default route, which you check with ip r: the default via line must point to the gateway of your subnet. Finally you need working DNS resolution, otherwise IP addresses answer but no domain name resolves: the server answers ping on an IP, and yet no update and no API call gets through.

ip r                      # Is there a default route?
ping -c 3 192.168.1.1     # Does the gateway answer?
dig +short debian.org     # Does DNS resolve a name?
ss -tulpn                 # Which services listen, on which ports?

These four commands are your first diagnostic reflex, in this order. If ip r shows no default route, there is no point looking further on the DNS side. If ping works on the IP but dig returns nothing, the problem is strictly DNS. The complete method, including the cases where the packet leaves but never comes back, is covered in Diagnose a network problem.

Static or DHCP: decide before configuring

An interface receives its settings either automatically through DHCP (Dynamic Host Configuration Protocol), or manually as static. This choice is not cosmetic: it determines how your server can be reached, and therefore the reliability of your DNS records, your filtering rules and your SSH access. A server whose address changes with each DHCP lease is a server you end up losing.

Use case	Recommendation
Production server (web, DNS, database)	Static IP
User workstation, laptop	DHCP
Test VM, disposable environment	DHCP (static if the service is exposed)
Machine reached over SSH from outside	Fixed IP

Swipe to see more

With a static address, always check that the chosen address is excluded from the DHCP pool or reserved on the DHCP server. Without this precaution, the server will one day hand out the same address to another machine, and you will get an intermittent address conflict, one of the most painful outages to diagnose because it only appears when a lease is renewed.

One configuration tool per machine

There is no universal network configuration tool on Linux. Three mechanisms share the field, and the golden rule is that only one of them drives a given interface. Letting NetworkManager and systemd-networkd coexist on the same card guarantees a configuration that "comes back on its own" after a reboot.

systemd-networkd is the network component of systemd. Declarative, light, with no graphical dependency, it reads .network and .netdev files in /etc/systemd/network/. It is the engine that actually applies the configuration on an Ubuntu Server, even if you never write its files directly.

Netplan is Ubuntu's YAML layer. You write a file in /etc/netplan/, and Netplan generates the configuration for the underlying engine (networkd on servers, NetworkManager on desktops). A minimal static IP example:

network:
  version: 2
  ethernets:
    eth0:
      addresses:
        - 192.168.1.10/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses: [1.1.1.1, 8.8.8.8]

The default route is declared in a routes: block. The old gateway4: key has been deprecated since Netplan 0.103: it still works but prints a warning (gateway4 has been deprecated, use default routes instead) at every netplan generate or netplan apply, and it will eventually disappear. If you copy a tutorial that uses it, migrate it. File permissions, the automatic rollback and the bond and VLAN cases are covered in Configure the network with Netplan.

NetworkManager is the default manager of RHEL and its derivatives, and of Fedora and Ubuntu Desktop workstations. It reasons in connections (named profiles), not in flat files, and is driven with nmcli on the command line or nmtui in a text interface. It is also the tool expected at the RHCSA exam. Creating profiles, static IP and persistence after reboot are detailed in Configure the network with NetworkManager.

Tool	Where you find it	When to prefer it
systemd-networkd	Ubuntu Server, minimal cloud images	Servers, containers, scripted configuration
Netplan	Ubuntu (layer on top of networkd)	Any recent Ubuntu machine
NetworkManager	RHEL, Rocky, Fedora, workstations	RHEL/RHCSA, Wi-Fi, VPN, multiple profiles

Swipe to see more

Apply a change without locking yourself out

This is where many tutorials go wrong. The command systemctl restart networking is not generic: the networking.service unit belongs to ifupdown, Debian's historical stack with /etc/network/interfaces. It does not exist on a recent Ubuntu Server (Netplan and systemd-networkd), nor on RHEL (NetworkManager). Running it on those systems simply returns Unit networking.service not found. The right command depends on the tool that drives the interface.

Distribution / stack	Apply the configuration
Ubuntu (Netplan)	sudo netplan apply
Ubuntu / minimal images (systemd-networkd alone)	sudo systemctl restart systemd-networkd
RHEL, Rocky, Fedora (NetworkManager)	sudo nmcli connection reload then sudo nmcli connection up enp1s0
RHEL, as a last resort	sudo systemctl restart NetworkManager
Debian with ifupdown (/etc/network/interfaces)	sudo systemctl restart networking

Swipe to see more

On RHEL, prefer nmcli connection up to a full restart of NetworkManager: reloading a profile touches a single interface, while restarting the service reapplies everything, including what you did not mean to change. On Ubuntu, sudo netplan try applies the configuration then rolls it back automatically after 120 seconds (the --timeout default) unless you confirm: this is the safety net that saves you when you work remotely over SSH on the only interface of the machine.

The classic trap of remote configuration

A wrong address or gateway applied over SSH cuts your own session, and you have no way back without a physical console or a cloud console. Before any remote change, make sure you have a fallback access, or use an automatic rollback mechanism such as netplan try.

What this module does not cover

A module should state its limits. The networking module stops at configuring and diagnosing connectivity: it does not cover firewall filtering, even though ufw, firewalld and nftables are skills expected at the LFCS and the RHCSA.

The topic is not missing from the course, though: it belongs to the Secure module, which gives it four lessons. Introduction to Linux firewalls sets the mental model, UFW covers Debian and Ubuntu, firewalld covers RHEL and its derivatives, and nftables shows the engine underneath. VLANs and advanced routing (several tables, policy routing) are not covered in this module either; link aggregation (bonding) and the bridge, on the other hand, have their own lesson.

Key points

• Connectivity rests on four building blocks: an UP interface, an IP address with its mask, a default route, DNS resolution. Diagnose them in that order.
• ip a, ip r, ping, dig and ss -tulpn locate the failing block before you open a configuration file.
• Static for servers, DHCP for workstations. A static IP must always be excluded from the DHCP pool, otherwise an address conflict is guaranteed.
• One tool drives an interface: systemd-networkd, Netplan or NetworkManager. Mixing them produces configurations that come back after a reboot.
• In Netplan, the default route goes in a routes: block; the gateway4: key is deprecated.
• systemctl restart networking only exists on Debian with ifupdown. On Ubuntu it is netplan apply; on RHEL, nmcli connection up.
• Over SSH, a failed network configuration cuts your session: use netplan try or keep a fallback console.
• The module does not cover the firewall: ufw, firewalld and nftables are worked on in the Secure module of the course.

×

See in the glossary →