There are very few computers that are not connected to a network of some kind these days. Connecting your Linux computer to a network can be pretty straightforward – except when it is not. In this article I will discuss the main network configuration files for Red Hat based Linux distributions. I will also take a look at the two network startup functions, the venerable “network” startup and the controversial NetworkManager.
Most computers have only one Network Interface Card (NIC) while others may have several. Laptops usually have a NIC for a wired connection and a NIC for a wireless connection. Many laptops also have a WiMax connection for use with a cellular network. Some Linux desktop or tower computers have multiple wired NIC cards and are used as inexpensive routers for internal networks; such is the case with a couple of my own systems.
Interface configuration files
The interface configuration files contain the configuration details for the network interface. If there is more than one NIC there will be one of these files for each NIC. Configuration of the NICs for each network connection is accomplished with files in the /etc/sysconfig/network-scripts directory. Each NIC has an interface configuration file named ifcfg-<NIC name>X, where X is the number of the NIC, starting with zero or 1 depending upon the naming convention in use.
Most of the other files in the /etc/sysconfig/network-scripts directory are scripts used to start, stop and perform various network configuration activities.
Each interface configuration file is bound to a specific physical NIC by the MAC address of the NIC.
NIC naming conventions
The naming conventions for NICs used to be simple, uncomplicated, and, I thought, easy. Using ethX made sense to me and was easy to type. It also did not require extra steps to figure out what long and obscure name belonged to a NIC. Unfortunately, adding a new NIC could force the renaming of existing ones, causing issues with startup configuration of all the NICs. That has all changed – more than once.
After a short stint with some very long and unintelligible NIC names that apparently made some sense to a small group of programmers, we now have a third set of naming conventions which seems only marginally better. Names like eno1 and enp0s3 are found on
Names like ethX are still used by CentOS 6.X. The newest naming conventions are used by RHEL 7, CentOS 7, and more recent releases of Fedora. The NIC naming convention for RHEL 6 and CentOS6 is described here, and that for RHEL 7 and CentOS7 along with current versions of Fedora are located here.
Interface Configuration File examples
The content of a typical network interface configuration file is shown below. This interface configuration file, ifcfg-eth0, defines a static IP address configuration for a CentOS 6 server installation.
# Intel Corporation 82566DC-2 Gigabit Network Connection DEVICE=eth0 HWADDR=00:16:76:02:BA:DB ONBOOT=yes IPADDR=192.168.0.10 BROADCAST=192.168.0.255 NETMASK=255.255.255.0 NETWORK=192.168.0.0 SEARCH=”example.com” BOOTPROTO=static GATEWAY=192.168.0.254 DNS1=192.168.0.254 DNS2=22.214.171.124 TYPE=Ethernet USERCTL=no IPV6INIT=no
This file specifies two DNS entries for this network, and all the other data necessary to provide a complete configuration for this interface. It also is configured so that non-root users cannot start and stop the interface and it starts the interface on boot.
The following interface configuration file, ifcfg-eno1, provides a DHCP configuration for a desktop workstation.
TYPE=Ethernet BOOTPROTO=dhcp DEFROUTE=yes IPV4_FAILURE_FATAL=no IPV6INIT=no IPV6_AUTOCONF=no IPV6_DEFROUTE=no IPV6_FAILURE_FATAL=no NAME=eno1 UUID=a67804ff-177a-4efb-959d-c3f98ba0947e ONBOOT=yes HWADDR=E8:40:F2:3D:0E:A8 IPV6_PEERDNS=no IPV6_PEERROUTES=no
In this second interface configuration file example, the DHCP entries, IP address, the search domain, and all other network information are not defined because they are supplied by the DHCP server. Configuration items like the DNS servers can be overridden in the interface configuration file by adding DNS1 and DNS2 lines like the ones in the previous example.
In both interface configuration files, the HWADDR line specifies the MAC address of the physical NIC. This binds the physical NIC to the interface configuration file. You will need to change the MAC address in the file if you replace the NIC for some reason. The ONBOOT line specifies that the interface is to be activated at startup time. If this line were changed to “no” the interface would have to be activated either manually or by NetworkManager when a user logs into the desktop, because it would not be activated automatically during startup time.
The USERCTL line specifies that non-privileged users cannot manage the interface; that is they cannot turn it on and off. Setting this parameter to “yes” would allow regular users to activate and deactivate the interface.
Notice that the lines in the interface configuration files are not sequence sensitive and work just fine in any order. By convention the option names are in uppercase and the values are in lowercase. Option values can be enclosed in quotes but that is not necessary unless the value is more than a single word or number.
There are many configuration options for the interface configuration files. These are some of the more common ones you will encounter.
- DEVICE: The logical name of the device, such as eth0 or enp0s2.
- HWADDR: The MAC address of the NIC that is bound to the file such as 00:16:76:02:BA:DB
- ONBOOT: Start the network on this device when the host boots. Options are yes/no. This is typically set to “no” and the network does not start until a user logs in to the desktop. If you need the network to start when no one is logged in, set this to “yes”.
- IPADDR: The IP Address assigned to this NIC such as 192.168.0.10
- BROADCAST: The broadcast address for this network such as 192.168.0.255
- NETMASK: The netmask for this subnet such as the class C mask 255.255.255.0
- NETWORK: The network ID for this subnet such as the class C ID 192.168.0.0
- SEARCH: The DNS domain name to search when doing lookups on unqualified hostnames such as “example.com”
- BOOTPROTO: The boot protocol for this interface. Options are static, DHCP, bootp, none. The “none” option defaults to static.
- GATEWAY: The network router or default gateway for this subnet, such as 192.168.0.254
- ETHTOOL_OPTS: This option can be used to set specific interface configuration items for the NIC such as speed, duplex state, and autonegotiation state. Because this option can have several independent values, the values should be enclosed in a single set of quotes, such as: “autoneg off speed 100 duplex full”.
- DNS1: The primary DNS server, such as 192.168.0.254, which is a server on the local network. The DNS servers specified here are added to the /etc/resolv.conf file when using the Network Manager or if the peerdns directive is set to yes, otherwise the DNS servers must be added to that file manually and are ignored here.
- DNS2: The secondary DNS server such as 126.96.36.199, which is one of the free Google DNS servers. Note that a tertiary DNS server is not supported in the interface configuration files, although a third may be configured in a non-volatile resolv.conf file.
- TYPE: Type of network, usually Ethernet. The only other value I have ever seen here was Token Ring but that is now mostly irrelevant.
- PEERDNS: The yes option indicates that /etc/resolv.conf is to be modified by inserting the DNS server entries specified by DNS1 and DNS2 options in this file. “No” means do not alter the resolv.conf file. “Yes” is the default when DHCP is specified in the BOOTPROTO line.
- USERCTL: Specifies whether non-privileged users may start and stop this interface. Options are yes/no.
- IPV6INIT: Specifies whether IPV6 protocols are applied to this interface. Options are yes/no.
If the DHCP option is specified, many of the other options are ignored. The only required options besides BOOTPROTO would be ONBOOT and HWADDR. Other options that you might find useful that are not ignored are the DNS and PEERDNS options if you want to override the DNS entries supplied by the DHCP server.
The network file
There is one old and now deprecated file you might encounter. The network file usually contains only a single comment line for current releases of Fedora, RHEL, and CentOS. It is located in /etc/sysconfig and was used in the past to enable or disable networking. It was also used to set the networking host name as shown in the following example.
This file has been present but unused in Fedora since release 19. It is still used in RHEL/CentOS 6.x but no longer in RHEL/CentOS 7.x. The network hostname is now set in the /etc/hostname file.
Other network files
The /etc/sysconfig/network-files directory contains many other files, all of which are usually executable BASH scripts rather than configuration files. This is, to me at least, one of the bothersome exceptions to the Linux Filesystem Hierarchical Standard (FHS) which explicitly states that only configuration files and not executable files are to be located in the /etc tree.
The only other network configuration file you might find in /etc/sysconfig/network-files is the route-<interface> file. If you want to set up static routes on a multi-homed system, you would create a route file for each interface. For example, the following file would be named route-eth0 and would contain information defining routes to entire networks or specific hosts.
default 192.168.2.1 dev eth0 10.10.10.0/24 via 192.168.0.1 dev eth0 192.168.1.0/24 via 192.168.0.1 dev eth0 192.168.96.11 via 192.168.97.1 192.168.15.100 via 192.168.15.32 192.168.96.12 via 192.168.97.1 192.168.97.100 via 192.168.97.1
The use of this file is very uncommon in Linux unless you are using the host as a router with some complex routing needs. Therefore the details of this routing configuration are beyond the scope of this article.
With the advent of wireless networks and mobile devices, reconfiguring the network interfaces for each new wireless network became very complicated and time-consuming, which is not a good thing for people who are less technical. It could also be a problem when adding a new NIC to a server or other host with multiple network interfaces.
The old “network” service was used by default on Red Hat based distributions up until 2004 to manage network startup and stop tasks. A SystemV start script used static configuration files, as described above, to start the wired or wireless network at boot time or with a simple command like service network start command from the command line. This service is still available although the commands are redirected through systemd.
The network service is unable to monitor pluggable devices or changing wireless networks so it cannot be used easily on laptops or netbook style computers.
There were also issues with configuring wired networks with laptops, and servers or desktops with multiple NICs. I would encounter problems when replacing a defective NIC in a host with multiple NICs. Many times the NIC name would change during the system startup.
Red Hat introduced the Network Manager in 2004 as a way to simplify and automate network configuration and connections, especially wireless connections. The intent is to prevent the user from having to manually configure each new wireless network before using it.
Although it would seem to make network management better and easier for non-technical users, it requires some adjustment by the Linux administrator because many of the configuration functions we have been familiar with are now handled by a new layer of configuration files and scripts. This means that the standard configuration files that we modify in order to manually manage networking are subject to being overwritten by the Network Manager every time the network is restarted, including every reboot.
The udev daemon is a kernel device manager which is supposed to provide consistent and persistent device naming for all devices including network devices and removable mass storage devices. It is also used to match network device names, i.e., eth0 or eno1, for example, to the MAC address on the NIC.
How it Works – Sort of
The udev device manager detects when a new device has been added to the system, such as a new NIC, and creates a rule to identify and name it if one does not already exist. The details of how this works have changed in more recent versions of Fedora, CentOS and RHEL. The current device naming procedure is described in detail in the RHEL 7 Networking Guide along with a description of how the names are derived.
The current strategy is to use the contents of the interface configuration files to generate the rules. However, if an interface configuration file does not exist, plugging in a new device or connecting with a new wireless network causes udev to notify NetworkManager of the new device or wireless connectrion. NetworkManager then creates the new interface configuration file.
The udev daemon creates an entry for each NIC installed in the system in the network rules file. The Network Manager uses these entries, along with information in the interface configuration files in the /etc/sysconfig/network-scripts/ directory to initialize each NIC.
It is possible to use the older network service and disable the NetworkManager. There are plenty of web sites that describe how to disable the NetworkManager and return to using the network service, including this one, so I won’t go into those details here.
I personally recommend against returning to the older network service because, once I understood how NetworkManager and udev work together provide a consistent naming scheme and automatic configuration for both existing and new devices, it all made sense and made managing network interfaces easier. In my opinion, NetworkManager is actually the best of both worlds.
As always with Linux, the decision of which service to use is your choice.