Ubuntu Server 18.04 – Managing network interfaces

How to install and create applications with Docker Compose

Assuming our server’s hardware has been properly detected, we’ll have one or more network interfaces available for us to use. We can view information regarding these interfaces and manage them with the ip command. For example, we can use ip addr show to view our currently assigned IP address:

ip addr show
Viewing IP information with the ip addr show command

If for some reason you’re not fond of typing, you can shorten this command all the way down to simply ip a. The output will be the same in either case. From the output, we can see several useful tidbits, such as the IP address for each device (if it has one), as well as its MAC address.

Using the ip command, we can also manage the state of an interface. We can bring a device down (remove its IP assignment and prevent it from connecting to networks), and then back up again:

sudo ip link set enp0s3 down 
sudo ip link set enp0s3 up 

In that example, I’m simply toggling the state for interface enp0s3. First, I’m bringing it down, and then I’m bringing it back up again.

Bringing interfaces up and down is all well and good, but what’s up with that naming convention? The convention used in Ubuntu 18.04 may seem a bit strange for those of you that have grown accustomed to the scheme used in earlier versions, which utilized network interface names such as eth0, wlan0, and so on. Since Ubuntu is based on Debian, it has adopted the new naming convention that was introduced starting with Debian 9.0.

The new naming convention has been put in place in order to make interface naming more predictable. While you may argue that names such as eth0 may be easier to memorize than say enp0s3, the change helps the name stay persistent between boots. When you add new network interfaces to a Linux system, there’s always the possibility that other interface names may change as well. For example, if you have an older Linux installation on a server with single network card (eth0) and you add a second (which then becomes eth1), your configuration may break if the names were to get switched during the next boot. Imagine for a moment that one interface is connected to the internet and another connected to a switch (basically, you have an internet gateway). If the interfaces came up in the wrong order, internet access would be disrupted for your entire office, due to the fact that the firewall rules you’ve written are being applied to the wrong interfaces. Definitely not a pleasant experience!

In the past, previous versions of Ubuntu (as well as Debian, and even CentOS), have opted to use udev to make the names stick in order to work around this issue. This is no longer necessary nowadays, but I figured I’d mention it here just in case you end up working on a server with an older installation. These older servers would achieve stickiness with interface names from configuration stored in the following file:


This file existed on older versions of some popular Linux distributions (including Ubuntu), as a workaround to this problem. This file contains some information that identifies specific qualities of the network interface, so that with each boot, it will always come up with the same name. Therefore, the card you recognize as eth0 will always be eth0. If you have an older version of Ubuntu Server in use, you should be able to see this file for yourself. Here’s some sample output of this file on one of my older installations:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="01:22:4e:a5:f2:ec", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" 

As you can see, it’s using the MAC address of the card to identify it with eth0. But this becomes a small problem if I want to take an image of this machine and
re-deploy it onto another server. This is a common practice—we administrators rarely start over from scratch if we don’t have to, and if another server is similar enough to a new server’s desired purpose, cloning it will be an option. However, when we restore the image onto another server, the /etc/udev/rules.d/70-persistent-net-rules file will come along for the ride. We’ll more than likely find that the new server’s first network interface will have a designation of eth1, even if we only have one interface. This is because the file already designated a device as eth0 (it’s referencing a device that’s not present in the system), so we would need to correct this file ourselves in order to reclaim eth0. We would do that by editing the rules file, deleting the line that contains the card that’s not on the system, and then changing the device designation on the remaining line back to eth0.

The new naming scheme is effective as of systemd v197 and later (in case you didn’t already know, systemd is the underlying framework utilized in Ubuntu for managing processes and various resources). For the most part, the new naming convention references the physical location of the network card on your system’s bus. Therefore, the name it receives cannot change unless you were to actually remove the network card and place it in a different slot on the system’s board, or change the position of the virtual network device in your hypervisor. If your machine does include a /etc/udev/rules.d/70-persistent-net-rules file, it will be honored and the old naming convention will be used instead. This is due to the fact that you may have upgraded to a newer version of your distribution (which features the new naming scheme, whereas your previous version didn’t), so that your network devices will retain their names, thereby minimizing disruption when moving to a newer release.

As a quick overview of how the network names break down, en is for Ethernet, and wl is for wireless. Therefore, we know that the example interface I mentioned earlier (enp0s3) references a wired card. The p references which bus is being used, so p0 refers to the system’s first bus (the numbering starts at 0). Next, we have s3, which references PCI slot 3. Putting it together, enp0s3 references a wired network interface card on the system’s first bus, placed in PCI slot 3. The exact details of the new naming specification are beyond the scope of this chapter (and could even be a chapter of its own!), but hopefully this gives you a general idea of how the new naming convention breaks down. There’s much more documentation online if you’re interested in the nitty-gritty details. The important point here is that since the new naming scheme is based on where the card is physically located, it’s much less likely to change abruptly. In fact, it can’t change, as long as you don’t physically switch the positions of your network cards inside the case.

Getting back to managing our interfaces, another command worth discussion is ifconfig. The ifconfig command is part of the net-tools suite of utilities, which has been deprecated (for the most part). Its replacement is the iproute2 suite of utilities, which includes the ip command we’ve already discussed. In summary, this basically means you should be using commands from the iproute2 suite, instead of commands such as ifconfig. The problem, though, is that most administrators nowadays still use ifconfig, with no sign of it slowing down. In fact, the net-tools suite has been recommended for deprecation for years now, and just about every Linux distribution shipping today still has this suite installed by default. Those that don’t, offer it as an additional package you can install. In the case of Ubuntu Server 18.04, net-tools commands such as ifconfig are alive and well. However, this package may no longer be included by default sometime in the future, so if you find that you have to install it manually, you’ll know why.

The reason commands such as ifconfig have a tendency to stick around so long after they’ve been deprecated usually comes down to the change is hard mentality, but quite a few scripts and programs out there are still using ifconfig, and therefore it’s worth discussing here. Even if you immediately stop using ifconfig, and move to ip from now on, you’ll still encounter this command on your travels, so you may as well know a few examples. Knowing the older commands will also help you if you find yourself on an older server.

First, when executed by itself with no options, ifconfig will print information regarding your interfaces like we did with ip addr show earlier. That seems pretty simple.

If you are unable to use ifconfig to view interface information using a normal user, try using the fully qualified command (include the full path):


The /sbin directory may or may not be in your $PATH (a set of directories your shell looks within for commands), so if your system doesn’t recognize ifconfig, use the fully qualified command instead:

Viewing interface information with the ifconfig command

Secondly, just like with the ip commands we practiced earlier, we can also bring an interface down or up with ifconfig as well:

sudo ifconfig enp0s3 down 
sudo ifconfig enp0s3 up 

There are, of course, other options and variations of ip and ifconfig, so feel free to look up the main pages for either if you want more information. For the purposes of this section, the main thing is to remember how to view your current IP assignments, as well as how to bring an interface up or down.

Comments are closed.