Table of Contents
Understanding Network Configuration on Linux
Linux systems store their network configuration in text files. These files are read by different networking tools and services at boot time or when a network service is restarted. The exact files and formats depend on your distribution and which networking framework it uses.
This chapter focuses on how to edit those configuration files in a few common environments and how to apply changes safely.
Network Configuration Approaches by Distribution
Modern Linux systems typically use one of three broad approaches for persistent network configuration.
Traditional distributions like Debian, Ubuntu Server (older releases), and classic RHEL or CentOS use distribution specific plain text files that are read by ifupdown or the Red Hat network scripts.
Newer distributions prefer higher level managers such as NetworkManager or systemd-networkd. These also use files, but usually in structured formats and stored under specific directories.
To work correctly, you must know which framework your system actually uses. On desktop systems NetworkManager is usually in charge. On servers, systemd-networkd or legacy scripts are more common, but not guaranteed. Tools from the Networking tools chapter such as ip and ss report the current state but do not tell you directly how that state was configured.
You can usually identify the active framework like this. If NetworkManager.service is active in systemctl, NetworkManager is in control. If systemd-networkd.service is active, systemd-networkd manages interfaces. If neither is active and you see services like networking.service or network.service, you likely use legacy scripts.
The rest of this chapter describes how configuration files look for each of the major schemes and how to safely edit them.
Debian and Ubuntu: `/etc/network/interfaces`
On classic Debian systems and some Ubuntu Server installations, persistent network settings are stored in /etc/network/interfaces and in files that it includes. This file describes network interfaces by name, and for each interface you define the addressing method and options.
You will see lines such as:
# Loopback interface
auto lo
iface lo inet loopback
# Primary network interface
auto eth0
iface eth0 inet dhcp
The line auto eth0 means the interface eth0 should be brought up at boot. The line iface eth0 inet dhcp says that eth0 uses IPv4 (inet) with DHCP.
A static IPv4 configuration typically looks like this.
auto eth0
iface eth0 inet static
address 192.168.1.50
netmask 255.255.255.0
gateway 192.168.1.1
The indentation is conventional but not technically required. What matters are the keywords such as address, netmask, and gateway. DNS servers are usually set in a separate file, /etc/resolv.conf, but on modern systems this file may be generated by a resolver service so you often configure DNS through that service instead.
On Debian based systems /etc/network/interfaces can also include additional files, for example:
source /etc/network/interfaces.d/*
In this case configurations for different interfaces may be split into small files in /etc/network/interfaces.d/. When you want to add or change an interface, check both the main file and any included directory.
After editing /etc/network/interfaces, you normally apply changes by restarting the networking service:
sudo systemctl restart networking
On heavily used servers this can temporarily disrupt all networking, not just the interface you changed. A more careful approach is to use ifdown and ifup on an individual interface, but do not use these until you understand how they interact with your setup.
Red Hat, CentOS, Fedora (legacy scripts): `/etc/sysconfig/network-scripts`
On classic Red Hat family systems that still use the old network scripts, each interface has its own configuration file under /etc/sysconfig/network-scripts/. Files are named ifcfg-NAME, where NAME is the interface name as used by the kernel.
An example for an interface called eth0 using DHCP looks like:
DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
Here BOOTPROTO controls the addressing method. Common values are dhcp for client addressing and none or static for manually configured addresses. ONBOOT=yes means the interface is brought up at boot time.
A static configuration for the same interface might look like:
DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
IPADDR=192.168.1.50
PREFIX=24
GATEWAY=192.168.1.1
DNS1=192.168.1.10
DNS2=8.8.8.8
IPv4 prefix length here serves the same purpose as the traditional netmask. For example PREFIX=24 corresponds to a netmask of 255.255.255.0.
DNS settings are stored alongside interface configuration in these files, but on some systems a separate resolver configuration generator may override or supplement them.
When you edit an ifcfg- file, you apply the change by restarting the network service:
sudo systemctl restart networkOn systems that still carry these scripts but use NetworkManager on top, the files are often read by NetworkManager itself rather than by the old service. In that case the method for applying changes is different, as described in the NetworkManager section.
NetworkManager: Keyfiles and Connection Profiles
For both desktop and many server systems today, NetworkManager manages network interfaces. Instead of configuring interfaces directly in /etc/network/interfaces or /etc/sysconfig/network-scripts, NetworkManager uses connection profiles.
Profiles are stored in keyfile format, usually under /etc/NetworkManager/system-connections/. Each file contains sections such as [connection], [ipv4], and [ipv6]. They are ordinary text files but permissions are restricted because they can include secrets like Wi Fi passwords.
An IPv4 DHCP configuration may look like this in a keyfile:
[connection]
id=Example Ethernet
uuid=3c4e6a90-12ab-4e8d-9f74-76bde0f8da2c
type=ethernet
interface-name=enp0s3
[ipv4]
method=auto
[ipv6]
method=ignore
The [connection] section names the profile and binds it to an interface. The [ipv4] section uses method=auto for DHCP. For static addressing the same section might look like this:
[ipv4]
method=manual
addresses=192.168.1.50/24
gateway=192.168.1.1
dns=192.168.1.10;8.8.8.8;Multiple addresses and DNS servers are separated by semicolons. When editing by hand, keep the syntax exact, because NetworkManager parses these lines and will ignore invalid values.
Do not manually edit NetworkManager keyfiles while the connection is active without understanding how NetworkManager reloads them. Prefer to use its command line tool nmcli or graphical tools, then inspect the generated keyfiles to learn the format.
If you do edit a keyfile directly, you can ask NetworkManager to reload its connection definitions and then bring the connection up again, for example by using nmcli to down and up that connection or by restarting the NetworkManager service with systemctl. The exact commands are part of tool usage, not file editing, so they are covered elsewhere.
systemd-networkd: `.network` and `.netdev` Files
Some modern Linux systems use systemd-networkd for network management. This service reads configuration from .network and .netdev files, usually placed under /etc/systemd/network/. These files use an .ini like format similar to other systemd configuration files.
A simple DHCP configuration for an Ethernet interface called enp0s3 might look like:
[Match]
Name=enp0s3
[Network]
DHCP=yes
The [Match] section says which interface the file applies to. The [Network] section defines the addressing behavior. For static IPv4 addressing, a configuration may look as follows.
[Match]
Name=enp0s3
[Network]
Address=192.168.1.50/24
Gateway=192.168.1.1
DNS=192.168.1.10 8.8.8.8
Multiple DNS servers are separated by spaces. If you need more detailed addressing control, you can add an [Address] section with a specific Address= line and optional Broadcast= or Scope= entries.
Changes in /etc/systemd/network/ are not applied automatically. After editing a file, you should instruct systemd-networkd to reload its configuration. One safe pattern is to daemon-reload and then restart systemd-networkd using systemctl. Because that temporarily affects all managed interfaces, consider maintenance windows for servers.
On systems that use systemd-resolved, DNS client behavior is controlled separately. In this case, the DNS= entries in .network files are passed to the resolver service, which then generates or overrides the contents of /etc/resolv.conf.
DNS Resolver Configuration Files
Historically, DNS resolvers on Unix like systems were configured directly in /etc/resolv.conf. This file listed resolver options and nameservers, for example:
search example.com
nameserver 192.168.1.10
nameserver 8.8.8.8
However, many modern Linux systems do not want you to edit /etc/resolv.conf directly. Instead, it is often a symbolic link managed by a resolver service such as systemd-resolved or by NetworkManager or another tool.
If /etc/resolv.conf is a symbolic link, inspect where it points. On systems using systemd-resolved, it normally links to a file under /run/systemd/resolve/ or /usr/lib/systemd/resolve/. On those systems your configuration entry point is not /etc/resolv.conf itself but some other file or interface provided by the resolver.
Because of this, persistent DNS configuration is usually done alongside interface settings, inside:
/etc/network/interfaces on Debian style systems where you might use lines like dns-nameservers.
ifcfg- files with DNS1, DNS2 in Red Hat style legacy scripts.
NetworkManager keyfiles with a dns line in the [ipv4] or [ipv6] sections.
systemd-networkd .network files with DNS= and related entries.
When you edit these, the relevant service regenerates /etc/resolv.conf or its equivalent. If you override /etc/resolv.conf manually on a system that tries to manage it, your change may be overwritten on the next reboot or interface update.
General Editing and Safety Practices
Because network configuration mistakes can lock you out of a remote system, editing network configuration files requires caution.
Before you touch a configuration file, create a backup. For example, copy /etc/network/interfaces to a .bak file in the same directory. The same applies to ifcfg- files, keyfiles, and .network files. If something goes wrong, you can restore the backup using your text editor or a file copy.
On a remote server accessed over SSH, keep an active session open when restarting networking. Avoid making multiple unrelated changes at once. Modify a single interface, apply the change, and verify connectivity using tools from the Networking tools chapter such as ping and ip. This way, if you lose access, you know exactly which change caused the problem.
It is also common to schedule a forced reboot in the near future before applying risky network changes. If you break networking but the SSH session remains temporarily, you can cancel the scheduled reboot after confirming that everything works. If you lose the connection permanently, the reboot can reset the machine into a boot state that may recover connectivity, for example by falling back to different configuration.
Always keep a known working configuration backup before editing network files, especially on remote systems. Apply and test changes gradually, and assume any mistake in these files can disconnect you from the system.
Finally, be aware that on some distributions multiple tools can fight over network configuration. If your distribution uses NetworkManager by default and you manually edit legacy scripts or systemd-networkd files, those changes may be ignored. Conversely, if you disable a manager without adjusting its configuration, the underlying scripts may be incomplete. Before editing any file, confirm which service actually manages networking and follow the configuration method that matches that service.