问题现象

Linux操作系统中使用自定义规则/etc/udev/rules.d/70-persistent-net.rules重命名网卡名不生效

 

问题分析1-openibd触发网卡驱动重新加载

1.dmesg中可以看到同一个网卡设备会被重命名多次，最后一次是启动50s左右。通过dmesg -T可以进一步确定组后一次时间为10月31日 21:54:48秒左右

 

2.查看openibd系统服务，在21:54:41 unload了驱动，21:54:49又重新load了驱动，与最后一次网卡重命名时间接近。

 

3.查看openibd的代码，会检查openibd服务启动前加载（通过initramfs加载）的驱动版本与当前系统中（/lib/modules/)下的驱动版本是否一致，若不一致则会调用stop先卸载旧版本驱动；

 

4.进一步确认initramfs中的驱动版本，查看initramfs最后修改时间和kenrel rpm包安装的时间，两者时间基本接近，再查看驱动rpm包安装时间，可以确认驱动安装后没有更新initramfs

 

 

5.查看驱动包的安装脚本可以进一步确认，驱动安装时检查发行版是否为Orcale，只有Oracle发行版的时候才会执行dracut

 

问题分析2-MLNX定制规则

通过上述分析，我们可以解释第三次网卡重命名的原因，但是无法解释前两次重命名的原因，以及为什么第三次重命名时最后的网卡名称是enp2s0f0这种形式，而不是自定义规则中指定的ethnx这种形式。我们先分析后面一个问题，第三次重命名为什么不是ethnx这种形式

 

通过查阅相关资料，我们找到了udev的一种测试网卡规则的方法，通过如下命令可以测试udev规则:

udevadm --debug test --action=add /sys/class/net/enp2s0f0

 

上述命令中--debug是设置为debug模式，这样有更多的日志输出，--action=add表示模拟设备添加操作，/sys/class/net/enp2s0f0表示要测试的设备的sysfs路径，可以修改为其他网卡设备。

 

下述日志是我们对enp133s0f0设备测试的日志，可以看到有两条规则给出了网卡名称，分别是70-persistent-net.rules和82-net-setup-link.rules，其中70号规则是我们指定的规则，而82号规则是MNLX OFED驱动安装的规则。

......

enp133s0f0: /etc/udev/rules.d/70-persistent-net.rules:1 NAME 'ethn0'

.....

enp133s0f0: /usr/lib/udev/rules.d/82-net-setup-link.rules:10 Importing properties from results of '/etc/infiniband/vf-net-link-name.sh p0'

enp133s0f0: Starting '/etc/infiniband/vf-net-link-name.sh p0'

Successfully forked off '(spawn)' as PID 2451173.

enp133s0f0: '/etc/infiniband/vf-net-link-name.sh p0'(out) 'NAME=enp133s0f0'

enp133s0f0: Process '/etc/infiniband/vf-net-link-name.sh p0' succeeded.

 

基于udev重命名网卡规则的机制，按照lexical order排序，最终网卡被重命名后的名称就变成了82号规则指定的enp133s0f0这种形式。这里遗留一个问题是我们是通过规则测试来确认网卡重命名过程的，实际82号规则生效的原理没有进一步分析，下文分析initramfs中内核自带的5.0驱动下82号规则不生效时会略有涉及，但是详细的分析还需要进一步研究。

 

到此我们基本确定了网卡重命名不生效的原因，也找到了解决方法，即删除MLNX OFED安装的82号规则文件。对应规则文件删除是否会带来其他影响，我们可以通过MLNX OFED的Release notes了解，链接为https://docs.nvidia.com/networking/display/MLNXENv561035/Changes+and+New+Features

其中有一个change提到在MLNX OFED 5.6之后的版本82号规则将不再安装到udev的规则目录（/etc/udev/rules.d/和/usr/lib/udev/rules.d/)，而是放到了/usr/share/doc目录，用户有需要的时候可以再拷贝到指定目录。

 

问题分析3：initramfs

虽然我们分析清楚了第三次网卡重命名的原因，和重命名为enp2s0f0这种格式的原因，也找到了解决问题的方法，但是前两次重命名的原因还是没有分析清楚。另外，我们在查看另外一台服务器日志的时候发现这台服务器的网卡只被重命名了两次。

 

1.通过日志时间和上文分析，我们确定最后一次重命名触发原因是openibd重新加载驱动触发设备的ADD事件，从而udev接收该事件后匹配规则进行重命名。这也是为什么最后一次重命名是renamed from ethX这种基本命名，而非是上一次重命名的名称。（如果是非加载驱动触发的udev事件，对于第一台服务器应该是renamed from ethnX，对于第二台服务器名称没有变化，不会发生重命名）

 

2.第二台服务器的第一次重命名时间与第一台服务器的第二次重命名时间基本一致，进一步查看日志/var/log/messages和对比dmesg日志，我们可以确定这次重命名是发生在systemd switch root之后，也就是从initramfs中退出，加载硬盘根分区。

 

3.进一步查看日志，可以看到在Switching root之前systemd会stop initramfs加载后启动的udevd，并在之后重新启动udevd，从而触发网卡重命名

 

 

4.到此我们可以确定第一台服务器第二次重命名和第二台服务器第一次重命名发生的原因，那么这里的问题就是为什么两台服务器最终重命名的结果不同（第一台服务器重命名成了ethnX这种70号规则指定的形式，而第二台服务器重命名成了enp2s0f0这中MLNX 82号规则指定的形式）。

 

5.经过对比，我们排除了这两台服务器规则文件不一致、驱动版本等原因，同时发现两台服务器的内核参数不一致，第二台服务器设置了ifname=0和biosname=0，但是经过实验也基本排除了这两个参数导致的影响（在实验机器上无论是否设置这两个参数不改变70号规则和82规则生效的结果，总是82号规则生效）。

 

6.进一步对比发现了另外一个差异，这两台服务器的initramfs不相同，具体的差异我们解压开initramfs后可以看到，第一台服务器中只有内核自带的0驱动，而第二台服务器则同时包含5.0和5.6两个版本驱动。经过了解是第二台服务器之前尝试安装过MLNX OFED 5.6，并通过dracut 命令更新了initramfs。

 

7.由此我们确定，在openibd重新加载根分区的OFED 5.4驱动之前，第一台服务器是使用的initramfs中的0驱动，而第二台服务器中使用的initramfs中的5.6驱动。由此问题可以基本确认5.0驱动时82号规则不会生效，而5.6驱动时82号规则生效并覆盖了70号规则给出的网卡名称。

8.因此，我们需要再看下82号规则的内容，如下图所示，同时通过上文的测试日志我们可以了解是规则中第10行的操作触发了重命名，而该规则的条件是phys_ports_name不为空。经过测试在1、5.4、5.6的OFED驱动中该属性有设置（可以通过cat sysfs对应的文件确定），可以推测内核自带的5.0驱动应该是没有设置（需要在使用5.0内核自带驱动的物理机pf上测试下，vf不会设置该值，因此无法在当前的虚拟机测试）。这里还遗留一个问题是5.4/5.6驱动的phys_switch_id同样是不为空的，但是却没有命中该规则，上面的udevadm测试日志可以确认。

 

9.到此为止，还剩最后一个问题待确认，就是为什么第一台服务器重命名了三次，而第二台服务器只重命名了二次。经过上文的分析，我们可以确定第一次重命名发生在initramfs阶段，经过查看解压后的initramfs，可以看到此时没有70号规则和82号规则，那么此时是否重命名就取决与内核参数ifnames。经过实验确定，net.ifnames=0且没有规则文件时会保留ethX这种基本命名，而net.ifnames=1则内核netdev模块会将网卡重命名为enp2s0f0这种形式。

 

 

问题总结：

最后，我们简单用一个启动流程图来总结下网卡可能发生重命名的阶段。