irp demo
Request Noction IRP Demo

Request a personalized demo/review session of our Intelligent Routing Platform

irp trial
Start Noction IRP Trial

Evaluate Noction IRP, and see how it meets your network optimization challenges

nfa demo
Noction Flow Analyzer Demo

Schedule a one-on-one demonstration of our network traffic analysis product

nfa trial
Free Noction Flow Analyzer Trial

Test drive NFA today with your own fully featured 30-day free trial

Interface Names and Descriptions Best Practices and Configuration

Interface Names and Descriptions ConfigurationThe name of a network interface is a string that is generated based on the interface attributes. This is a predictable naming scheme used in OS Linux that overcomes the shortcomings of the legacy “ethX” naming scheme.We will use the enp0s3 device to clarify the predictable interface naming scheme in Linux. The “en” stands for Ethernet, “p0” is a bus number of the Ethernet card and “s3” is a slot number. The two-character prefix “en” identifies the type of the interface. For example, the prefix “en” is for Ethernet card type, “wl” for Wireless cards, “sl” for serial lines etc.

The legacy interface naming scheme causes problems when there are multiple NICs on a computer because the interfaces are named based on the order in which the Linux kernel finds them during boot. If an interface is removed or added, the previously added interfaces may change names. Therefore, it is no longer recommended to use it, even though the latest Linux distributions still support it.

Fortunately, Linux allows us to create our own interface naming scheme, which, when properly maintained, helps greatly during network monitoring and troubleshooting. It gives administrators the freedom to choose an interface name based on criteria, such as what type of interface it is, where it is located and connected, or what it is used for. This makes interfaces much easier and faster to identify during network monitoring and troubleshooting.

Interface names/descriptions can be obtained from NetFlow starting with v9 (Cisco), NetStream (Huawei), and IPFIX. It should be emphasized that the name and description specify the interface on which the Flow exporter captures packets. The generated flows are then exported to the Flow Analyzer.

NetFlow v9 defines the IF_NAME field type (value 82), which is the abbreviated name of the interface, e.g., “FE0/1”, and the IF_DESC field (value 83), which is the full interface name, e.g., “FastEthernet 0/1” (Figure 1). Similarly, IANA defines element IDs 82 and 83 for IPFIX, which are InterfaceName and InterfaceDescription. Again, the first field is a short name uniquely describing the interface and the second field represents the interface description.

Cisco NetFlow v9

Figure 1 – Cisco NetFlow v9 Fields IF_NAME and IF_DESC

We will illustrate the importance of custom interface naming using the network infrastructure shown in Figure 2. The IPFIX exporter, which in this scenario is nProbe, captures packets on the interface eth0 connected to SPAN port configured on the switch in DMZ. The flows are exported from nProbe to Noction Flow Analyzer (NFA).

Network Infrastructure

Figure 2 – Network Infrastructure with Flow Exporter and Analyzer

Nprobe is started from Linux CLI with the following parameters:

– n: collector address
– i: interface where packets are captured
– V: flow export version: 10 – IPFIX, 9 (v9), 5 (v5)
– T: flow template definition. NetFlow V9 and IPFIX flows have a custom format that can be specified at runtime using this option.
-t: maximum flow lifetime
-d: maximum flow idle lifetime
-l: maximum queue timeout.

The parameter %INTERFACE_NAME instructs nProbe to include interface name in exported IPFIX flows (Figure 3). However, the name says nothing about where the packets are being captured. Therefore, we create our own naming scheme by renaming the interface eth0 to dmz0. At first glance, it will be clear that the port on which nProbe captures packets is connected to dmz network.

IfName Identification Value in IPFIX Flow

Figure 3 – The First Flow with Interface Name eth0

1. Renaming Network Interface eth0 to dmz0 on Debian 10 Linux

Many Linux distributions support renaming interfaces to user-chosen names for example internet0, dmz0, lan0 according to their physical locations or MAC addresses as part of their networking scripts. For that, we will create a .link file in the directory /etc/systemd/network/, which chooses an explicit name dmz0 for the interface eth0.

The link file contains a [Match] section, which determines if a given link file may be applied to a given device, as well as a [Link] section specifying how the device should be configured.

NOTE: If the exporter has multiple interfaces to be renamed, a separate link file must be created for each interface.

In the next section, we place a match condition in the link file based on either the physical location of the interface or its MAC address. Both options work well, choose the one you prefer more.

1.1 Getting Physical Location of Device eth0

Udev is the device manager for the Linux 2.6 kernel and later which allows us to identify devices based on their properties, like vendor ID and device ID. It is part of systemd and thus installed by default.

We will use the command udevadm to get the path ID of the device eth0. The Path_ID is a unique identifier of the device which consists of the PCI domain, the bus number, the device number and the PCI device function.

$ sudo udevadm info /sys/class/net/eth0 | grep ID_PATH


Figure 4 – Getting ID_PATH for Device eth0

We can break the device string “0000:00:03.0” down as following:

0000 – PCI domain (each domain can contain up to 256 PCI buses)
00 – Bus number the device is attached to
03 – Device number
0 – PCI device function

1.2 Getting MAC Address of Device eth0

We need to obtain the MAC address of the interface eth0 (Figure 5), so we can create a Match condition based on the MAC address.

$ ip link show dev eth0

MAC Address eth0 interface

Figure 5 – Checking MAC Address of Interface eth0

1.3 Creating Link File

Link files encode configuration for matching network and must have the extension .link, otherwise, they are ignored. Let’s create a link file with a Match condition and Link section that links a new device named dmz0 to the eth0 interface based on the physical location.

$ sudo vi /etc/systemd/network/



In case we want to create a Match condition based on the MAC address of interface eth0, change the above configuration as follows:



1.4 Updating Network Configuration

The interface eth0 will be changed to dmz0 after a reboot, so we need to update the network configuration to use the new interface name. Edit the /etc/network/interfaces file, and change all instances of the eth0 interface to the new name – dmz0.

The sed command replaces all the occurrences of the keyword eth0 with dmz0:

$ sudo sed -i 's/eth0/dmz0/g' /etc/network/interfaces

As the next step, we will check if the interface eth0 has been changed to dmz0 (Figure 6):

$ cat /etc/network/interfaces

Network Configuration Changed

Figure 6 – Network Configuration Changed

Reboot Debian and verify that the new network interface name dmz0 is in use (Figure 7):

$ ip link show dev dmz0

Interface dmz0 is in use

Figure 7 – Interface dmz0 is in use

Now we can run nProbe with the same parameters as before; however, we need to replace eth0 with dmz0 after the -i parameter.

The exported IPFIX flows now contain updated interface name -dmz0 (Figure 8).

Interface eth0

Figure 8 – Updated IfName Identification Value in IPFIX Flow


InterfaceName and InterfaceDescription are fields within IPFIX flow that provide information about the abbreviated and the full name of the interface on which the flow exporter captures packets.

For this reason, it is important to name the interface so that it is immediately clear where the interface is connected, which then helps in network monitoring and troubleshooting. However, both the exporter and the flow analyzer must support these features.

The interface name and description identification via NetFlow, IPFIX, and NetStream is supported in Noction Flow Analyzer starting with v 21.11. This capability is especially helpful at times when the use of SNMP isn’t the best option or is simply not possible.

Boost BGP Performance

Automate BGP Routing optimization with Noction IRP

bgp demo


You May Also Like

ACK and NACK in Networking

ACK and NACK in Networking

In networking, communication between devices relies on the efficient exchange of data packets. Among the essential...