Recent disruptions to two undersea internet cables in the Baltic Sea have yet again...
Interface Names and Descriptions Best Practices and Configuration
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.
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).
Figure 2 – Network Infrastructure with Flow Exporter and Analyzer
Nprobe is started from Linux CLI with the following parameters:
$ sudo nprobe -i eth0 -V 10 -n 10.0.0.1:2055 -T="%SAMPLING_INTERVAL %IN_BYTES %IN_PKTS %IPV4_SRC_ADDR %IPV4_DST_ADDR %IPV4_NEXT_HOP %L4_SRC_PORT %L4_DST_PORT %SRC_VLAN %DOT1Q_SRC_VLAN %SRC_TOS %TCP_FLAGS %PROTOCOL %IP_PROTOCOL_VERSION %DIRECTION %FLOW_START_MILLISECONDS %FLOW_END_MILLISECONDS %IN_SRC_MAC %OUT_DST_MAC %ICMP_TYPE %BIFLOW_DIRECTION %L7_PROTO_NAME %INTERFACE_NAME" -t 60 -d 15 -l 60
– 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.
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:
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
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/10-rename-eth0.link
[Match]
Path=pci-0000:00:03.0
[Link]
Name=dmz0
In case we want to create a Match condition based on the MAC address of interface eth0, change the above configuration as follows:
[Match]
MACAddress=08:00:27:84:13:f2
[Link]
Name=dmz0
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
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
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).
Figure 8 – Updated IfName Identification Value in IPFIX Flow
Conclusion
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
SUBSCRIBE TO NEWSLETTER
You May Also Like
From Idle to Established: BGP states, BGP ports and TCP interactions
Understanding BGP states is essential to grasp how BGP operates. Similar to interior gateway protocols (IGPs) like...
ACK and NACK in Networking
In networking, communication between devices relies on the efficient exchange of data packets. Among the essential...
BGP and asymmetric routing
What is asymmetric routing? Asymmetric routing is a network communication scenario where the forward and reverse paths...