1、問題

傳統上，Linux中的網路介面被列舉為eth[0123…]，但是這些名稱不一定對應於機箱上的實際標籤。
具有多個網路介面卡的現代伺服器平臺可能會遇到這些介面的不確定性和違反直覺的命名。
這影響到板載網絡卡(LOM)和外接的網路介面卡(PCIe獨立網絡卡)。
在Red Hat Enterprise Linux中，udev支援許多不同的命名方案。
預設值是根據韌體、拓撲和位置資訊分配固定名稱。
這樣做的好處是，這些名稱是完全自動的、完全可預測的，即使新增或刪除了硬體，它們仍然是固定的(不需要重新列舉)，
而且壞掉的硬體可以無縫地替換。缺點是，它們有時比傳統使用的eth0或wlan0名稱更難讀。例如:enp5s0。

2、 引出

為什麼需要網絡卡一致性命名規則呢，簡單一句話解釋就是伺服器通常有多塊網絡卡，有板載整合的，同
時也有插在PCIe插槽的，例如一臺伺服器，除了板載網絡卡外，還安裝有兩張PCIe介面的4口千兆網絡卡和兩張雙口的10Gb光口網絡卡，
這樣加上板載的4個千兆網口，這臺伺服器現在一共有16個網路埠，
如果以傳統方式命名網絡卡，名稱混亂的問題對於管理員使用者來說都是一件頭疼的事情。
因為傳統的Linux系統的命名往往不一定準確對應網絡卡介面的物理順序。
比如eth0有可能不是第一塊網絡卡的第一個網口，有可能對應的是第二塊網絡卡的某一個網口，這樣就會造成混亂。
為解決這類問題，就需要網絡卡一致性命名規則。

3、Centos7中命名方案層次結構

預設情況下，systemd將使用以下策略為介面命名，以應用支援的命名方案:
● Scheme1
如果韌體或BIOS提供的索引號(例如:eno1)適用且可用，則應用包含韌體或BIOS的名稱， 否則退回
到Scheme2。
● Scheme2
包含韌體或BIOS提供的PCI Express熱插拔插槽索引號(例如:ens1)的名稱，如果韌體或BIOS提供的
資訊是可用的，則應用這些名稱，否則將回到Scheme3。
● Scheme3
包含硬體聯結器的物理位置的名稱(例如:enp2s0)，如果適用，將被應用，否則在所有其他情況下直
接回到Scheme5。
● Scheme4
包含介面MAC地址的名稱(例如:enx78e7d1ea46da)，預設情況下不使用，但如果使用者選擇，則可用。
● Scheme5
如果所有其他方法都失敗，則使用傳統的不可預測核心命名方案(例如:eth0)。

上面概述的這個策略是預設的。如果系統啟用了biosdevname，就會使用它。注意，啟用biosdevname
需要將biosdevname=1作為核心命令列引數傳遞，除非在戴爾系統中，在戴爾系統中，只要安裝了bios
devname，就預設使用biosdevname。如果使用者添加了更改核心裝置名稱的udev規則，那麼這些規則將
具有優先順序。

4、systemd裝置重新命名過程

1、在/usr/lib/udev/rules.d/60-net.rules中有一條規則指示udev助手實用程式/lib/udev/rename_
device檢視所有/etc/sysconfig/network-scripts/ifcfg字尾檔案。如果它發現一個帶有HWADDR條目
的ifcfg檔案與一個介面的MAC地址匹配，它將該介面重新命名為DEVICE指令在ifcfg檔案中給出的名稱。

2、在/usr/lib/udev/rules.d/71-biosdevname.rules中指示biosdevname根據其命名策略重新命名介面，
前提是在前面的步驟中沒有重新命名介面，安裝了biosdevname，並且在引導命令列上沒有將biosdevname
=0作為核心命令給出。

3、在/lib/udev/rules.d/75-net-description.rules中的規則指示udev通過檢查網路介面裝置來填充
內部udev裝置屬性值id_net_name_board、ID_NET_NAME_SLOT、ID_NET_NAME_PATH、ID_NET_NAME_MAC
。注意，有些裝置屬性可能是未定義的。

4、在/usr/lib/udev/rules.d/80-net-name-slot.rules中有一條規則指示udev重新命名介面(前提是在
第1步或第2步中沒有重新命名介面)和核心引數net。根據以下優先順序:id_net_name_board、ID_NET_NAME
_SLOT、ID_NET_NAME_PATH，沒有指定ifnames=0。如果其中一個未設定，則它將進入列表中的下一個。
如果沒有設定這些引數，則不會重新命名介面。

步驟2實際執行的是biosdevname的policy
步驟3和4實際執行的是Scheme1、2、3

5、傳統的不可預測的核心命名方案

核心引數（net.ifnames=0 biosdevname=0）
同一臺伺服器和相同的作業系統，兩次安裝過程中，網絡卡裝置的順序並不相同。
這種變化是不可預知的且沒有規律可尋。

核心引數檔案：/boot/efi/EFI/centos/grub.cfg

6、可預測的網路介面裝置名稱

net.ifnames的命名規範為: 裝置型別+裝置位置+數字可預測的網路介面裝置名稱。預設核心引數
(biosdevname=0，net.ifnames=1)

修改核心引數檔案：/boot/efi/EFI/centos/grub.cfg，之後重啟reboot。

[root@simon network-scripts]# ifconfig
enp182s0f0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 00:00:00:00:07:14  txqueuelen 1000  (Ethernet)
        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

enp182s0f1: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 00:00:00:00:07:15  txqueuelen 1000  (Ethernet)
        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

enp182s0f2: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 00:00:00:00:07:16  txqueuelen 1000  (Ethernet)
        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

enp182s0f3: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 00:00:00:00:07:17  txqueuelen 1000  (Ethernet)
        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

enp7s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.100.57  netmask 255.255.255.0  broadcast 192.168.100.255
        inet6 fe80::5c96:a206:c19d:f82b  prefixlen 64  scopeid 0x20<link>
        ether 00:a2:c9:00:00:00  txqueuelen 1000  (Ethernet)
        RX packets 272  bytes 23333 (22.7 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 72  bytes 18771 (18.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device memory 0xaae00000-aae7ffff

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Local Loopback)
        RX packets 480  bytes 38976 (38.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 480  bytes 38976 (38.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

7、使用傳統命名方式時產生網絡卡亂序和漂移的問題

許多使用者還是習慣使用傳統的網絡卡命名方式，比如在安裝系統時使用核心引數(biosdevname=0，
net.ifnames=0)。根據RedHat官方文件，如果禁用systemd可預測介面命名(net.ifnames)和biosde
vname命名方案，則網路介面將繼續使用核心最初給出的不可預測且可能不一致的ethX名稱。核心在
啟動時列舉網路裝置時總是使用ethX命名約定。由於並行化，核心介面列舉的順序在重新引導時可
能會有所不同。Red Hat Enterprise Linux依賴於systemd可預測介面命名方案或biosdevname命名方
案，以可預測的方式將核心不可預測的ethX介面重新命名為在重新引導時始終一致的名稱。

Red Hat Enterprise Linux沒有提供一致應用ethX命名約定的方法，除非在非常特殊的情況下。
udev規則將介面設定為特定的名稱，如果請求的名稱已經被其他介面使用，則該規則將失敗。這包
括/usr/lib/udev/rules.d/60-net.rules檔案提供的功能。核心在啟動時列舉網路裝置時使用ethX
命名約定。在不同的重新引導中，ethx名稱是不一致的，因此它們是不可預測的。因此，嘗試使用
udev將介面重新命名為ethX名稱或重新排列核心給出的不可預測的ethX名稱將失敗。使用ethX名稱可
以正確地用於以下場景:
● 系統只有一個網路介面。
● 當用於Red Hat Enterprise Linux 7虛擬機器來賓中的virtio nic時。

參考引用：

KClouder（Linux, Virtualization, Management, OpenSource & Networking）

https://www.kclouder.cn/centos-consistent-networkdevice-naming/

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/ch-consistent_network_device_naming