Changing Ethernet Device Names in EL7 and Fedora 15+
|
AN!Wiki :: How To :: Changing Ethernet Device Names in EL7 and Fedora 15+ |
 |
Warning: The topic includes RHEL v7, which has not be released. It may well prove that the methods described here will not work with the final release of Red Hat Enterprise Linux version 7. Best guesses on how things will work inform this tutorial and may prove wrong. |
Traditionally in Linux, network devices were given the name ethX, where X was a digit starting at 0 and incremented up. The drawback to this was that there was no consistent or deterministic way to know which physical network ports would get which ethX name. To address this, Fedora 15 (and other distributions) began using a new tool called biosdevname which names each network device based on where it is found in the system. The result is that, usually, you can predict the name of a given physical interface.
This tutorial will show you how to change these device names to anything you would like. This tutorial is not meant to advocate against the new network naming. However, there are cases ranging from simple familiarity to application compatibility that might make you want to use different network device names. For those cases, this tutorial hopes to help you.
Assumptions
This tutorial makes a few assumption which may not apply to your system. Please adjust accordingly.
This tutorial assumes you have six network cards;
- p1p1
- p1p2
- p2p1
- p2p2
- p4p1
- p4p2
We will rename these to;
- bcn1
- bcn2
- sn1
- sn2
- ifn1
- ifn2
The reason for these names is that, in my case, I wish to give names to interfaces that reflect their purpose in my servers. Specifically, I need three bonded networks; BCN, SN and IFN in my clusters. You can just as easily use eth0 to eth5 or any other name that suits your purposes.
This tutorial also assumes that you have a minimal install and that the system is designed to be a server. As such, NetworkManager is removed and the network daemon will be used. No attempt was made to test if the method of renaming network devices shown here works with NetworkManager.
Overview
We will need to take the following steps;
- Identify the network device names assigned to each interface.
- Generate the /etc/udev/rules.d/70-persistent-net.rules file.
- Unplug and plug back in each network interface to create the map of current to desired names.
- Rename and edit the /etc/sysconfig/network-scripts/ifcfg-X files to reflect the desired names.
- Edit the /etc/udev/rules.d/70-persistent-net.rules file to create the MAC address to device name maps.
- Restart the machine to make the changes take effect.
Identify Interfaces
To start, you want to see what the names your system has already given to the network interfaces. This can be done with iptables -a, which reports all network cards, regardless if they are started or not.
ifconfig -a
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 16436
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 0 (Local Loopback)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
p1p1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::21b:21ff:fe72:99ab prefixlen 64 scopeid 0x20<link>
ether 00:1b:21:72:99:ab txqueuelen 1000 (Ethernet)
RX packets 2103 bytes 198150 (193.5 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3 bytes 270 (270.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 16 memory 0xf7ec0000-f7ee0000
p1p2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::2e0:81ff:fecb:80 prefixlen 64 scopeid 0x20<link>
ether 00:e0:81:cb:00:80 txqueuelen 1000 (Ethernet)
RX packets 2102 bytes 197804 (193.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3 bytes 270 (270.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 17 memory 0xf7b00000-f7b20000
p2p1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.255.0.151 netmask 255.255.0.0 broadcast 10.255.255.255
inet6 fe80::21b:21ff:febf:6c87 prefixlen 64 scopeid 0x20<link>
ether 00:1b:21:bf:6c:87 txqueuelen 1000 (Ethernet)
RX packets 2179 bytes 208690 (203.7 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 76 bytes 14361 (14.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 17 memory 0xf7dc0000-f7de0000
p2p2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::2e0:81ff:fecb:81 prefixlen 64 scopeid 0x20<link>
ether 00:e0:81:cb:00:81 txqueuelen 1000 (Ethernet)
RX packets 2102 bytes 197804 (193.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3 bytes 270 (270.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 18 memory 0xf7a00000-f7a20000
p4p1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::21b:21ff:febf:7002 prefixlen 64 scopeid 0x20<link>
ether 00:1b:21:bf:70:02 txqueuelen 1000 (Ethernet)
RX packets 2103 bytes 198150 (193.5 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3 bytes 270 (270.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 19 memory 0xf7cc0000-f7ce0000
p4p2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::21b:21ff:fe72:9692 prefixlen 64 scopeid 0x20<link>
ether 00:1b:21:72:96:92 txqueuelen 1000 (Ethernet)
RX packets 2101 bytes 197740 (193.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3 bytes 270 (270.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 16 memory 0xf79c0000-f79e0000
So I see the six network cards named pXpY. You might have emX, ethX or similar. The current names themselves doesn't matter too much, so long as you see all of your cards.
Mapping Current Names to Desired Names
So now that we know which cards you have, we need to sort out which name maps to which device. There are several ways you can do this;
- Sorting out the Consistent Network Device Names to physical interfaces. I find this to be an imperfect art.
- Use ethtool -p <dev> and watch to see which port's light blinks. This requires driver support and a clear view of the network cards.
- Watch the system log and unplug each cable to see what device is reported as having disconnected. This isn't the most elegant, but it is the method I prefer and which we will use here.
Before we proceed, let me give some background on what is happening behind the scenes.
In my case, I have three networks, each bonded across two interfaces, each link going to a separate switch (switch 1 and switch 2). I want to name these devices after their purpose;
- Back-Channel Network; bcn1 and bcn2
- Storage Network; sn1 and sn2
- Internet-Facing Network; ifn1 and ifn2
Before I started, I figured out which physical port I wanted to use for a given network and link. You will obviously have your own plan and it will likely differ from the one shown here. This is no problem at all. So long as you know what name you want to give each physical interface, you are ready to go.
I start by creating a list of interfaces names I want. Then, as I pull each cable, I mark the current name beside the desired name.
Initial List
So here is the list of desired names that I start with;
| Current Name | Desired Name |
|---|---|
| bcn1 | |
| bcn2 | |
| sn1 | |
| sn2 | |
| ifn1 | |
| ifn2 |
Now I will start watching the system log. In a terminal, run;
tail -f -n 0 /var/log/messages
This will watch for changes in the system log and print them to the screen. Let's start by pulling the first cable. In my case, I am pulling the network cable which I want to be named bcn1 (the "back-channel network link to switch number 1).
A moment or so after unplugging the cable, you will see something like this;
Oct 7 17:30:51 an-c04n02 kernel: [ 9368.605187] e1000e: p2p2 NIC Link is Down
Oct 7 17:30:51 an-c04n02 NetworkManager[547]: <info> (p2p2): carrier now OFF (device state 30)
Oct 7 17:30:51 an-c04n02 NetworkManager[547]: <info> (p2p2): device state change: disconnected -> unavailable (reason 'carrier-changed') [30 20 40]
Oct 7 17:30:51 an-c04n02 NetworkManager[547]: <info> (p2p2): deactivating device (reason 'carrier-changed') [40]
Oct 7 17:30:51 an-c04n02 NetworkManager[547]: <info> Policy set 'Boot Disk' (p2p1) as default for IPv4 routing and DNS.
Oct 7 17:30:51 an-c04n02 NetworkManager[547]: <info> Policy set 'Boot Disk' (p2p1) as default for IPv4 routing and DNS.
The line <info> (p2p2): carrier now OFF tells me that the device with the current name p2p2 was just unplugged. Now I know that the I want to change the device p2p1 to be bcn1. So I plug it back in and then I update my list;
| Current Name | Desired Name |
|---|---|
| p2p2 | bcn1 |
| bcn2 | |
| sn1 | |
| sn2 | |
| ifn1 | |
| ifn2 |
Now I unplug the device I want to be called bcn2;
Oct 7 17:43:14 an-c04n02 kernel: [10111.686371] e1000e: p2p1 NIC Link is Down
Oct 7 17:43:14 an-c04n02 NetworkManager[547]: <info> (p2p1): carrier now OFF (device state 100, deferring action for 4 seconds)
Here I see that the device I want to rename is p2p1, so I plug the cable back in and again update my list;
| Current Name | Desired Name |
|---|---|
| p2p2 | bcn1 |
| p2p1 | bcn2 |
| sn1 | |
| sn2 | |
| ifn1 | |
| ifn2 |
I repeat this for the next four cables. Once done, I have;
| Current Name | Desired Name |
|---|---|
| p2p2 | bcn1 |
| p2p1 | bcn2 |
| p1p2 | sn1 |
| p4p1 | sn2 |
| p1p1 | ifn1 |
| p4p2 | ifn2 |
There, now I know the existing device name and the name I wish to give it.
Writing The udev Rules File
The way we're going to create the actual MAC address to device name mapping will be via udev rules. Specifically, we're going to edit or create the /etc/udev/rules.d/70-persistent-net.rules. As of Fedora 17, this file is no longer created, so you will need to create it yourself. I've written a little script to do this;
#!/usr/bin/perl
use strict;
use warnings;
use IO::Handle;
my $conf = {};
# Read the 'ifconfig -a'
my $dev = "";
my $mac = "";
my $fh = IO::Handle->new();
my $sc = "ifconfig -a";
open ($fh, "$sc 2>&1 |") or die "Failed to call: [$sc], error: $!\n";
while (<$fh>)
{
chomp;
my $line = $_;
if ($line =~ /^(\S+):/)
{
$dev = $1;
next if $dev eq "lo";
$mac = "";
next;
}
if ($line =~ /ether (.*?) /)
{
$mac = $1;
next if not $dev;
$conf->{$dev} = $mac;
}
}
foreach my $dev (sort {$a cmp $b} keys %{$conf})
{
my $say_dev = lc($dev);
my $say_mac = lc($conf->{$dev});
print "\n# Added by 'write_udev' for detected device '$dev'.\n";
print "SUBSYSTEM==\"net\", ACTION==\"add\", DRIVERS==\"?*\", ATTR{address}==\"$say_mac\", NAME=\"$say_dev\"\n";
}
You can download and run this and it will print a skeleton udev file. If the output looks good, re-run it again and pipe the output to the 70-persistent-net.rules file.
Download it;
cd ~
wget -c https://alteeve.ca/files/write_udev
--2012-10-07 21:25:19-- https://alteeve.ca/files/write_udev
Resolving alteeve.ca... 64.34.141.3
Connecting to alteeve.ca|64.34.141.3|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 768 [text/plain]
Saving to: `write_udev'
100%[====================================================>] 768 --.-K/s in 0s
2012-10-07 21:25:19 (11.5 MB/s) - `write_udev' saved [768/768]
Then you can run it;
chmod 755 write_udev
./write_udev
# Added by 'write_udev' for detected device 'p1p1'.
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1b:21:72:99:ab", NAME="p1p1"
# Added by 'write_udev' for detected device 'p1p2'.
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:e0:81:cb:00:80", NAME="p1p2"
# Added by 'write_udev' for detected device 'p2p1'.
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1b:21:bf:6c:87", NAME="p2p1"
# Added by 'write_udev' for detected device 'p2p2'.
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:e0:81:cb:00:81", NAME="p2p2"
# Added by 'write_udev' for detected device 'p4p1'.
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1b:21:bf:70:02", NAME="p4p1"
# Added by 'write_udev' for detected device 'p4p2'.
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1b:21:72:96:92", NAME="p4p2"
What we see above are the rules telling the system that the network device with the specified MAC address is to be given the given name. We are not changing the names yet. That will come in the next step.
If the output looks good to you, re-run the program, but this time we will redirect the output to the 70-persistent-net.rules file.
./write_udev > /etc/udev/rules.d/70-persistent-net.rules
cat /etc/udev/rules.d/70-persistent-net.rules
# Added by 'write_udev' for detected device 'p1p1'.
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1b:21:72:99:ab", NAME="p1p1"
# Added by 'write_udev' for detected device 'p1p2'.
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:e0:81:cb:00:80", NAME="p1p2"
# Added by 'write_udev' for detected device 'p2p1'.
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1b:21:bf:6c:87", NAME="p2p1"
# Added by 'write_udev' for detected device 'p2p2'.
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:e0:81:cb:00:81", NAME="p2p2"
# Added by 'write_udev' for detected device 'p4p1'.
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1b:21:bf:70:02", NAME="p4p1"
# Added by 'write_udev' for detected device 'p4p2'.
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1b:21:72:96:92", NAME="p4p2"
If you are more comfortable writing this file yourself, instead of downloading some stranger's program, you can copy the output above, replace the ATTR{address}=="xx:xx:xx:xx:xx:xx" value with the MAC addresses shown in the output from the earlier ifconfig -a and setting the device names you wish.
 |
Note: The MAC address values must be in lower-case. |
Changing The Device Names
Now that we have our skeleton /etc/udev/rules.d/70-persistent-net.rules and our rename table, we can change the device names.
I like to always make a backup of any file before I edit it;
cp /etc/udev/rules.d/70-persistent-net.rules ~/
Now we will edit our newly created /etc/udev/rules.d/70-persistent-net.rules file and change the NAME="..." values according to our table. In my case, the new file will look like this;
vim /etc/udev/rules.d/70-persistent-net.rules
# Added by 'write_udev' for detected device 'p1p1'.
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1b:21:72:99:ab", NAME="ifn1"
# Added by 'write_udev' for detected device 'p1p2'.
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:e0:81:cb:00:80", NAME="sn1"
# Added by 'write_udev' for detected device 'p2p1'.
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1b:21:bf:6c:87", NAME="bcn2"
# Added by 'write_udev' for detected device 'p2p2'.
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:e0:81:cb:00:81", NAME="bcn1"
# Added by 'write_udev' for detected device 'p4p1'.
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1b:21:bf:70:02", NAME="sn2"
# Added by 'write_udev' for detected device 'p4p2'.
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1b:21:72:96:92", NAME="ifn2"
The changes are easier to see in a diff;
diff -u /etc/udev/rules.d/70-persistent-net.rules /root/70-persistent-net.rules
--- /etc/udev/rules.d/70-persistent-net.rules 2012-10-07 21:40:38.041922729 -0400
+++ /root/70-persistent-net.rules 2012-10-07 21:35:36.085919304 -0400
@@ -1,18 +1,18 @@
# Added by 'write_udev' for detected device 'p1p1'.
-SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1b:21:72:99:ab", NAME="ifn1"
+SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1b:21:72:99:ab", NAME="p1p1"
# Added by 'write_udev' for detected device 'p1p2'.
-SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:e0:81:cb:00:80", NAME="sn1"
+SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:e0:81:cb:00:80", NAME="p1p2"
# Added by 'write_udev' for detected device 'p2p1'.
-SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1b:21:bf:6c:87", NAME="bcn2"
+SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1b:21:bf:6c:87", NAME="p2p1"
# Added by 'write_udev' for detected device 'p2p2'.
-SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:e0:81:cb:00:81", NAME="bcn1"
+SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:e0:81:cb:00:81", NAME="p2p2"
# Added by 'write_udev' for detected device 'p4p1'.
-SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1b:21:bf:70:02", NAME="sn2"
+SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1b:21:bf:70:02", NAME="p4p1"
# Added by 'write_udev' for detected device 'p4p2'.
-SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1b:21:72:96:92", NAME="ifn2"
+SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1b:21:72:96:92", NAME="p4p2"
Now, next time we reboot, the system will use the given names for the specified MAC addresses!
We're not quite done yet, though.
Writing The Configuration Files
|
Warning: From this point on, losing your network access is quite likely. Be sure to have physical access to your system before proceeding. |
Up until now, we've focused on the names of the devices. Now we need to tell the operating system how to configure each device. To do this, we need to edit or create a /etc/sysconfig/network-scripts/ifcfg-<dev> file for each network card, where <dev> matches the device's new name we just gave it.
In theory, there should be a corresponding /etc/sysconfig/network-scripts/ifcfg-<dev> file for each of the existing network devices. However, I find that often that this is not the case. This doesn't really matter though, because we're going to write fresh configuration files. If you already have a given configuration file, you can rename it if you want. How the file comes into existence is less important. What matters is that there is a configuration file for each device.
First, I prune out old configs;
cd /etc/sysconfig/network-scripts/
rm -f rm -f ifcfg-{e*,p*}
Now I create six configuration files, one for each network. How you configure these will largely depend on what your goal is. For the sake of this tutorial, I will set ifn1 to dhcp and the rest of the interfaces to none. The Fedora 17 documentation covers the various arguments and they values well.
First up, my two BCN interfaces;
vim /etc/sysconfig/network-scripts/ifcfg-bcn1
# Back-Channel Network - Link 1
DEVICE="bcn1"
NM_CONTROLLED="no"
BOOTPROTO="none"
ONBOOT="yes"
vim /etc/sysconfig/network-scripts/ifcfg-bcn2
# Back-Channel Network - Link 2
DEVICE="bcn2"
NM_CONTROLLED="no"
BOOTPROTO="none"
ONBOOT="yes"
Next, my two SN interfaces;
vim /etc/sysconfig/network-scripts/ifcfg-sn1
# Storage Network - Link 1
DEVICE="sn1"
NM_CONTROLLED="no"
BOOTPROTO="none"
ONBOOT="yes"
vim /etc/sysconfig/network-scripts/ifcfg-bcn2
# Storage Network - Link 2
DEVICE="sn2"
NM_CONTROLLED="no"
BOOTPROTO="none"
ONBOOT="yes"
Finally, the two IFN links. As mentioned above, the first one is set to BOOTPROTO="dhcp".
vim /etc/sysconfig/network-scripts/ifcfg-ifn1
# Internet-Facing Network - Link 1
DEVICE="ifn1"
NM_CONTROLLED="no"
BOOTPROTO="dhcp"
ONBOOT="yes"
vim /etc/sysconfig/network-scripts/ifcfg-bcn2
# Internet-Facing Network - Link 1
DEVICE="ifn1"
NM_CONTROLLED="no"
BOOTPROTO="none"
ONBOOT="yes"
Done. One step to go!
Switching to Static network
Traditionally, the network daemon was used. However, this daemon is not very flexible, so moving a computer between networks is difficult. To address this, recent Fedora and Red Hat distributions switched to the more user friendly NetworkManager daemon. This tool is much more flexible, allowing for the automatic detection of new wired and wireless networks and re-configuring the computer's networking to suite.
In servers though, this is not usually a good thing. Servers rarely move around and consistency is preferred. So the first thing we will do is to remove NetworkManager and switch back to using the older, more static network daemon.
Switching NetworkManager For The network Daemon
First, tell the machine to start the network daemon on boot.
chkconfig network on
chkconfig --list network
Note: This output shows SysV services only and does not include native
systemd services. SysV configuration data might be overridden by native
systemd configuration.
network 0:off 1:off 2:on 3:on 4:on 5:on 6:off
Now, we will disable and then uninstall NetworkManager.
systemctl stop NetworkManager.service
systemctl disable NetworkManager.service
rm '/etc/systemd/system/multi-user.target.wants/NetworkManager.service'
rm '/etc/systemd/system/dbus-org.freedesktop.NetworkManager.service'
yum remove NetworkManager
Loaded plugins: langpacks, presto, refresh-packagekit
Resolving Dependencies
--> Running transaction check
---> Package NetworkManager.x86_64 1:0.9.4.0-9.git20120521.fc17 will be erased
--> Finished Dependency Resolution
Dependencies Resolved
================================================================================
Package Arch Version Repository Size
================================================================================
Removing:
NetworkManager x86_64 1:0.9.4.0-9.git20120521.fc17 @updates 6.8 M
Transaction Summary
================================================================================
Remove 1 Package
Installed size: 6.8 M
Is this ok [y/N]: y
Downloading Packages:
Running Transaction Check
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Erasing : 1:NetworkManager-0.9.4.0-9.git20120521.fc17.x86_64 1/1
Verifying : 1:NetworkManager-0.9.4.0-9.git20120521.fc17.x86_64 1/1
Removed:
NetworkManager.x86_64 1:0.9.4.0-9.git20120521.fc17
Complete!
Applying The Changes
We've changed how the kernel views the hardware, so we need to now reboot the system to make the changes take effect.
reboot
Once the system boots back up, we should see that all the network cards have been renamed.
ifconfig -a
bcn1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::2e0:81ff:fecb:81 prefixlen 64 scopeid 0x20<link>
ether 00:e0:81:cb:00:81 txqueuelen 1000 (Ethernet)
RX packets 83 bytes 7958 (7.7 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 8 bytes 680 (680.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 18 memory 0xf7a00000-f7a20000
bcn2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::21b:21ff:febf:6c87 prefixlen 64 scopeid 0x20<link>
ether 00:1b:21:bf:6c:87 txqueuelen 1000 (Ethernet)
RX packets 82 bytes 7862 (7.6 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 7 bytes 606 (606.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 17 memory 0xf7dc0000-f7de0000
ifn1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.255.0.23 netmask 255.255.0.0 broadcast 10.255.255.255
inet6 fe80::21b:21ff:fe72:99ab prefixlen 64 scopeid 0x20<link>
ether 00:1b:21:72:99:ab txqueuelen 1000 (Ethernet)
RX packets 181 bytes 19221 (18.7 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 115 bytes 18154 (17.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 16 memory 0xf7ec0000-f7ee0000
ifn2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::21b:21ff:fe72:9692 prefixlen 64 scopeid 0x20<link>
ether 00:1b:21:72:96:92 txqueuelen 1000 (Ethernet)
RX packets 55 bytes 5248 (5.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 6 bytes 492 (492.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 16 memory 0xf79c0000-f79e0000
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 16436
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 0 (Local Loopback)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
sn1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::2e0:81ff:fecb:80 prefixlen 64 scopeid 0x20<link>
ether 00:e0:81:cb:00:80 txqueuelen 1000 (Ethernet)
RX packets 55 bytes 5248 (5.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 6 bytes 492 (492.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 17 memory 0xf7b00000-f7b20000
sn2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::21b:21ff:febf:7002 prefixlen 64 scopeid 0x20<link>
ether 00:1b:21:bf:70:02 txqueuelen 1000 (Ethernet)
RX packets 55 bytes 5248 (5.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 6 bytes 492 (492.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 19 memory 0xf7cc0000-f7ce0000
To test, I will again tail the system log and pull each cable. If everything worked, the proper interface should report going down.
I'll start with bcn1;
tail -f -n 0 /var/log/messages
Unplug the cable;
Oct 7 23:18:24 an-c04n02 kernel: [ 274.021561] e1000e: bcn1 NIC Link is Down
Excellent! All the others should show the proper named interface going down. If so, we're done!
| Any questions, feedback, advice, complaints or meanderings are welcome. | |||
| Alteeve's Niche! | Enterprise Support: Alteeve Support |
Community Support | |
| © Alteeve's Niche! Inc. 1997-2024 | Anvil! "Intelligent Availability®" Platform | ||
| legal stuff: All info is provided "As-Is". Do not use anything here unless you are willing and able to take responsibility for your own actions. | |||