Configuring Network Interface Controllers (NIC)

Last Updated on 04/07/2017 by dboth

Each network interface controller (NIC) on your computer provides a physical connection to your network. Most computers have only one NIC while others may have several. Laptops usually have a NIC for a wired connection and a NIC for a wireless connection. Some laptops may also have a NIC for a WiMax connection. 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.

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.

NIC Configuration Files

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-ethX, where X is the number of the NIC, starting with zero (0). All of the other files in this 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.

Typical Interface Configuration File

A typical network interface configuration file is shown below. This file defines a static IP address of, with a broadcast address of, and a gateway of with a netmask of

# Intel Corporation 82566DC-2 Gigabit Network Connection

The HWADDR line specifies the MAC address of the physical NIC. You will need to change the MAC if you replace the NIC for some reason. This file specifies two DNS entries for this network.

The ONBOOT line specifies that the interface is to be activated at boot time. If this line were changed to “no” the interface would have to be activated manually as it would not be activated automatically at boot 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.

This file specifies two DNS entries for this network, and all the other data necessary to provide a complete configuration for this interface.

The following interface configuration file, ifcfg-eno1, provides a DHCP configuration for a desktop workstation.


This host’s IP address, netmask, gateway, and DNS server addresses are not defined in this file because they are provided 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.

Configuration Options

There are many configuration options for the interface configuration files. The more common ones are described here.

  • DEVICE:  The logical name of the device, such as eth0.
  • HWADDR:  The MAC address of the NIC such as 00:16:76:02:BA:DB
  • ONBOOT:  Start the network on this device. Options are yes/no.
  • IPADDR:  The IP Address assigned to this NIC such as
  • BROADCAST: The broadcast address for this network such as
  • NETMASK: The netmask for this subnet such as the class C mask
  • NETWORK: The network ID for this subnet such as the class C ID
  • SEARCH: The DNS domain name to search when doing lookups on unqualified hostnames such as ””
  • BOOTPROTO: The boot protocol  for this interface. Options are static, DHCP, bootp, none.
  • GATEWAY: The network router or default gateway for this subnet, such as
  • DNS1: The primary DNS server, such as 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 Note that a tertiary DNS server is not supported.
  • TYPE: Type of network such as Ethernet.
  • 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 desirable are the DNS and PEERDNS options if you do not want 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 dev eth0 via dev eth0 via dev eth0 via via via via

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.

Network Startup

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 network service

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.

The NetworkManager service

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.

Admins’ choice

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.


Leave a Reply